I do hope Python keeps incorporating more of the "good stuff" from functional programming. List/dict/set comprehensions make code better - I can look at something and see very clearly that it's correct. Type hinting is a great compromise between beginner/quick scripting needs and offering a fully-baked type system. Type hints do a lot more than most people expect - you can create useful compound and custom types (like Tuple[Int, Str, Iterable]). If we can get some pattern matching in there I'm not sure what I'd do. Spend less time debugging test failures I guess. Not sure what I'd do with that time. Maybe see my family or learn how to bake pastry. Or finally clean the top of the stove. Or just write more Python in the same amount of time? I don't know. Pattern matching.
Python 3 threw away pattern matching in function heads; used to be able to deconstruct tuples. I had just discovered that feature in Python 2 when I realized 2 was about to go EOL, and upon porting my code I discovered the change.
This is neat. It reminds me of an silly project [0] I made a while back to implement do-notation in python. In OP's project you still end up with code that's basically this:
y = (Maybe(just=x) if x > 0 else Maybe()).bind(lambda a:
Maybe(just=x*a) .bind(lambda b:
Maybe.mreturn(a+b)))
It's functionally sound and standard, but ergonomically painful. I built a really fun horrible hack to allow you to write that instead as this:
with do(Maybe) as y:
a = Maybe(just=x) if x > 0 else Maybe()
b = Maybe(just=x*a)
mreturn(a+b)
It swaps out the assignment operator `=` in the `with do()` block for the monadic bind operation, which you might be used to seeing as `<-`.
You just need to use my @with_do_notation decorator, which just completely rewrites your function using the ast library wherever it finds a block of `with do(SomeClass) as variable:`. I was even able to write ergonomically nice parser combinators [1] that would actually work pretty well if python had tail call optimization.
You shouldn't use it but it was great fun and opened my eyes to the ways you can abuse python if you really wanted to. Using decorators to introspect and completely rewrite functions is a fun exercise.
Your example isn't using "y", so you should also be able to drop the " as y" part (unless the AST hack requires it for some reason).
Edit: Oh, nevermind - the "y" is how you access it after the with statement. Weird for python, but it makes sense given the rewritten version. I was thinking your version would have a non-rewritten "result = something" within the with block in a real use, but that's not what it's doing.
Heh, yup, it's part of the hackiness of it all. "with do(MyMonadClass) as my_variable: <some code>" equates to haskell's "myVariable = do <some code>". I can't remember why the MyMonadClass part was necessary. Maybe for the mreturn.
As a language purist this one is surprisingly well put together. Its impl suffers from legacy (py2 support in general, predating builtin dataclasses, staying in the shallow end of type annotations) but it really does what it does better enough than its host language to be worth giving attention to. Check it out.
I like strongly typed and functional programming. But I would rather use a "pythonic" approach to solve problems in python.
OFC there might be some cases where for example one of your dependency is python, and you still want to be able to write correct code. But in general, If you want types and functional constructs, IMO you should use something else.
If there was one thing I'd change with python to make it more 'functional' it would be having lambdas that weren't expression-only. I know it's not a functional feature because it's for stateful programming, but the lack of it disallows some nice stuff.
I agree with you that having more than a single expression in lambdas would be super nice. That being said, I don't think it's necessarily stateful to allow more than a single expression! If you don't reassign any variables, then it's equivalent to a single expression. For instance, something like this (using made up syntax for extended lambdas) isn't stateful:
lambda i:
square = i * i
if i < 0:
return -1 * square
else:
return square
A decent heuristic for whether an algorithm is stateful might be to check if you can map it pretty easily to something like Haskell. In this case, it's not hard to do at all:
\i ->
let square = i * i in
if x < 0 then -1 * x else x
Of course, it might be more natural for some programmers to write the Python code in a stateful way like this:
lambda i:
square = i * i
if i < 0:
square *= -1
return square
Yeah, this is a trivial example. I picked it specifically to show that multi-line lambdas don't have to be stateful, not as an example of a lambda that couldn't be written in one line.
very quick reply, and I've done this in other langs that allow procedures-done-as-lambdas, create your own control flow mechanisms with 'reasonable' syntax, something like
with_file("c:/blah/data.csv", lambda fl:
# do stuff with file variable fl
# other statements
# ...
)
The file is opened, the block of code of the lambda does its thing, the file is closed at the end, exception-safe.
Python can do this another way (with 'with' objects or something, and it's quite clean and neat, but that's quite recent IIRC), this simpler IMO. Have used this, it's called the loan pattern, in scala, vb.net and C#, and prob others.
The arbitrary restriction on lambdas blocks composability, which disallows useful tricks like this.
The issue with that is the lack of lexical scope. Lambdas have lexical scoping, def functions do not. To “fake” lexical scope, you have to use the nonlocal or global statements, which are gross and self-defeating.
The project cites this blog post[0] on the "anti-pattern" that is Python exceptions, and I honestly couldn't be turned off on this project anymore after reading it if this is the inspiration behind it.
The examples in the README and this blog post just give me huge "nope" vibes. Obviously Python could learn a lot more from functional programming, but this is the wrong way to go about a lot of it.
The example cited where they don't know what to return in their `divide` function if a division by zero occurs is nonsense.
The answer is simple: let the `DivsionByZero` exception raise! You don't have to return anything!
Better yet, you should have input cleansing/data validation before it gets to that point. The alternative presented in the blog post is absurd over-engineering.
How about writting modern and proper Python first? Not to mention designing a decent API?
Let's examine the README example for a minute:
user: Optional[User]
if user is not None:
balance = user.get_balance()
if balance is not None:
balance_credit = balance.credit_amount()
if balance_credit is not None and balance_credit > 0:
can_buy_stuff = True
else:
can_buy_stuff = False
I don't know if it's been deliberatly twisted, but that's not what I would called idiomatic or realistic for a Python program:
- one should probably never reach this part of the code if there is no user. But I'll indulge the author.
- don't put can_buy_stuff in an else close, what's the point?
- using type hints for no reason, but not other modern facilities like the walrus operator?
- do we really want users without a balance? Let's indulge this, but it seems a bad design.
- what's with all those unecessary conditional blocks?
- credit_amount should never be None. It's a Balance object, put a sane default value. But ok, indulging again.
So, you get down to:
user: Optional[User]
can_buy_stuff = False
if user and (balance := user.get_balance()):
can_buy_stuff = (balance.credit_amount() or 0) > 0
I don't think the solution the lib offers is superior:
Checking the user should not be part of this algo, credit_amount should be 0 if never set. We could even remove return False, I keep it because I like explicitness.
You could even that as a method or raise NoBalance depending of your case.
That doesn't mean we should not experiment with other paradigms in Python, and I do think this lib is an interesting experiment, but I don't find it conclusive.
For 'Maybe' an 'Result' specifically, I feel that Python builtins + mypy offer superior experience: easier, safer, and less dependencies with a similar level of verbosity.
For Maybe example: I think this 'functional' style with fmaps in Python is problematic, because lambdas can't be multiline. If you have sevearal lines of logic, you'd need an auxiliary helper def, and at this point it becomes as unreadable.
For Results: I think returning Union[Exception, Value] (where Value is the 'desired' type) and then using isinstance(result, Exception) is much cleaner.
- it can be statically checked with mypy to ensure the same level of type safety as Rust would have
- minimal performance impact
- no extra wrapping and unwrapping in the code. You can completely ignore mypy and error handling, until you're happy, then you harden your program by making sure it complies to mypy.
- no extra dependencies, third party code dealing with your library doesn't have to deal with your wrappers! If they don't check for error type, when Exception is encountered, the program will most likely terminate with AttributeError, which is a desirable behaviour in such situation.
- it's much easier to compose: propagating error with a decorator is neat, until you have some more sophisticated logic, e.g. for error aggregation
- the only downside is that you end up with occasional `if isinstance(result, Exception)...`.
I reviewed results library specifically here [0] and elaborate on different error handling techniques in Python, including the approach I described.
Lambdas can be multiline/multistep, but it's just as ugly as you'd expect. Maybe the most "pure" functional way to do it is to have multiple binds/applies/maps, so instead of something like `x=1; y=2; x + y` it's something like `1.apply(lambda x: 2.apply(lambda y: x + y)).` Still unreadable, but for different reasons. It's more about the grossness of using `xEmitter.map(lambda x: stuff with x in scope)` to bind x as a variable than it is about the inflexibility of lambdas.
I'm also a FP fanboy, and this concept doesn't quite convince me. I'm not sure a Maybe type really helps that much in a dynamically typed language. All the safety you get from using Maybes is worth Nothing (pun intended) when credit_amount could still return let's say Just a string, or raises an exception.
If this chain of calls supposedly handles Nones at any level, then .map is not the right method. It should be .flatMap (or .bind). Unless this is a magic .map that handles either X or Maybe[X] and even exceptions (just like JS promises). This flexibility may be convenient and I can appreciate its pythonicness, but it's not really in the spirit of typed FP.
It's a bad example. You can of course do more with lambdas in python. Maybe "lambda real_user: real_user.get_balance()+1" or "lambda some_junk, real_user: real_user.get_balance()" would have been better.
A part of me is happy to see these types of tools introduced to python, but another part makes me wonder why people continue to use python when they see the value of things like `Option`/`Maybe`'s, `Result`'s, instead of just using a language with the features included from the start.
In my experience, the initial ease and speed of development when using python doesn't nearly outweigh the medium to long-term costs of maintaining it and developing the codebase further - at least for codebases that are more than a simple tool or something like a django app. Writing things like go, rust, scala, java etc. isn't that much more difficult or slower, but it does require more up front planning and understanding of your problem domain.
I don't have the skills to pull it off completely, or maintain it, but I've often toyed with the idea of a language/DSL that superficially looks and behaves like Python, but transpires down into Rust or something.
Mostly just to see what a language that 'feels like' Python would be like with the addition of things like proper Option/Result's and a couple of other features (stronger typing?).
Python is all about the magic. Lambda expressions are a bit of a black box for me in Python, it would be nice if that was made more transparent, or perhaps a different function entirely
For many FP programmers, the lambdas are not nearly magic enough.
In Swift, you can do something like this :
reversedNames = names.sorted(by: { $0 > $1 } )
It's a closure expression, and is an anonymous block of code that will magically bind parameters passed to it to numbered variables.
So you see the position Python is in: it has to balance a bit of magic for the power user, and yet not too much for the casual user.
It's a very delicate exercice, and it receives a lot of critics for it.
An F# or Lisp dev comming to Python will complain that it's not expressive enough.
A geographer comming to Python will struggle reading advanced code.
Yet we have to catters to all of them, give the huge Python popularity and it's goal to be "the second best language for everything".
I think Guido did a very decent job at it, although he gets a lot of heat for it. People don't like to hear "no" when they ask for a poney.
And the lambda expression is one of the most controversial decisions. Beginners have a hard time with it, but professional coders may snap when they hear it's limited to one line.
can't say i'm a fan of the decorator to implement functional concepts. jut feels dirty. type hints in python are just as meh. feels like it's not taking advantage of pythons duck typing.
a version of try and either, with a decent do notation taking advantage of for comprehension...
https://github.com/papaver/pyfnz
A big reason to use IO as a value (which IMO is a better name than IO monad), is the same in all languages: reasoning about immutable values is easier than side effects. If we can take complex IO operations and use composition tools exactly the same as other immutable values, it’s very nice.
Of course, in my experience, this is so foreign to people who haven’t worked with it for a time it is very difficult to sell in small reply.
That's why a lot of functional language research is moving towards effect handlers, which could be explained in a nutshell as "coroutines, but for anything"
> But, having null checks here and there makes your code unreadable.
if user is not None:
balance = user.get_balance()
if balance is not None:
balance_credit = balance.credit_amount()
if balance_credit is not None and balance_credit > 0:
can_buy_stuff = True
else:
can_buy_stuff = False
Actually I think that's very readable
user: Optional[User]
can_buy_stuff: Maybe[bool] = Maybe.from_value(user).map( # type hint is not required
lambda real_user: real_user.get_balance(),
).map(
lambda balance: balance.credit_amount(),
).map(
lambda balance_credit: balance_credit > 0,
)
Much better, isn't it?
def can_buy_stuff(user):
if user is None:
return False
balance = user.get_balance()
if balance is None:
return False
balance_credit = balance.credit_amount()
if balance_credit is None:
return False
return balance_credit > 0
Edit: something like Swift's optionals and nil-coalescing syntax might make this easier to read:
Nice premise. But it makes the Python code look super complicated.
It overloads map() with a lambda function, to compose function pipelining.
Then, it introduces flow() as the new pipelining tool. But you have to use bind() on the last function call to return the value.
Interesting concepts, but unless Python incorporates this as a standard feature, then this will remain a fringe idea. And it will add significant load to the development and maintenance process of Python programs.
Admittedly, I like Elixir’s pipe forward concept |>
That makes it super simple to do functional composition, and it will automatically bind and return the last value.
Cool library, though.