Functional Error Handling in Python by Moiz Merchant
Follow the journey of Moiz Merchant from Functional Scala to Scalaz to the destination of a tiny Pythonic library inspired by Scalaz.
How did this become? You'll find out in his interesting talk from LambdaConf 2018, future goals? You'll learn about those too.
Functional Error Handling in Python
I had the privilege of working on a functional Scala codebase a few years ago. During my 18-month adventure, I was introduced to error handling concepts from the depths of category theory. My first acquaintance was Option: value or no value, a container allowing me to deal with null values with a clean interface. Then came Try, slaying my utter disgust of exception abuse. Lastly, I stumbled onto Scalaz's \/ (a right-biased Either). What a wonderful world I had been introduced to, error handled managed in a sane and clean way. Life was good.
Fast-forward 3 years: back into the land of Python. My second assignment at the new gig was to implement a fixed-length parser for an incoming file format. Easy, I thought to myself. Reaching down into my tool belt, my hands came up empty. Huh? I no longer had the magical ninja weapons to tame my errors. Sadness filled me. Refusing to accept my fate, I became resolute on forging my own tools.
The result is a tiny Pythonic library (inspired by Scalaz), implementing Option, Try, and Either. My goal is to keep the code as close to idiomatic Python as possible while still implementing the code in a functional way. The code should integrate seamlessly into existing Python without looking out of place like many other implementations I ran into. Python's many functional faces made this all possible: using Python's generator comprehension to implement a Haskell-like do construct, class construction to implement a Try constructor which returned the proper child type of Success/Failure on exception, and various operators available to implement aliases for swap and getOrElse.
Future goals include expanding functional abstractions/implementations and thinking about the usefulness of high abstractions.