Returns: Brings functional programming to Python land

I am by no means the best to judge functional programming implementations but I find the examples provided as pretty confusing. The parts where the library is supposed to make things better actually look worse to me. The original Python examples also looks like cherry picked code that was already not written very well.<p><pre><code> if user is not None: balance = user.get_balance() if balance is not None: credit = balance.credit_amount() if credit is not None and credit &gt; 0: discount_program = choose_discount(credit) </code></pre> I would probably write the python closer to this for readability. Don&#x27;t judge me too harshly I just rewrote this quickly.<p><pre><code> if user is None: return balance = user.get_balance() if balance is None: return credit = balance.credit_amount() if credit is not None and credit &gt; 0: discount_program = choose_discount(credit)</code></pre>

Whew! &lt;- The sigh of relief after reading comments here and realizing that I&#x27;m not the only one preferring the standard style of writing Python instead of this &quot;functional&quot;(??) style...<p>I get that Optional return values can force the programmer to handle errors without resorting to exceptions, but I can&#x27;t help but wonder whether the first example with all those `bind_optional` ... is just Objective-C&#x27;s nil messaging in fancy disguise...<p>FWIW in Objective C this is exactly what one writes (even if those functions can return nil):<p><pre><code> credit = user.get_balance().credit_amount() if credit &gt; 0: discount_program = choose_discount(credit) </code></pre> I&#x27;m not sure what&#x27;s so &quot;functional&quot; about it though.

Looks like this library is serious. Most of what I see can be written more succinctly using existing Python functionality:<p><pre><code> 1. Maybe -&gt; Optional[T] 2. Result -&gt; Union[SuccessT, FailureT] 3. Future, FutureResult -&gt; concurrent.futures.Future[T] 4. IO -&gt; don&#x27;t use this; none of the standard library I&#x2F;O supports it </code></pre> I do appreciate the use of &quot;container&quot; as a term instead of &quot;monad&quot;.<p>I also appreciate the typechecker enhancements being put forward by their custom plugins.

This seems like too much effort has been put into it for it to be a purely satirical exercise, but I really cannot see why anyone would prefer to use this within Python, rather than (say) reaching for a proper type-safe functional language and either using that directly, or calling out to it from Python code.<p>As a person who teaches functional programming at degree level, this is the kind of thing that would put people off FP before they even get in the door. It is obviously less ergonomic than standard Python, and the code you end up with is no safer or more abstracted than what you started with.<p>That said, if the authors really do think it&#x27;s a better way for programming in Python, and it works for them, then more power to &#x27;em.

Pretty hideous IYAM.<p>optional.py seems to address the same issue and with a slightly better approach (but still ugly).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Python-Optional&#x2F;optional.py">https:&#x2F;&#x2F;github.com&#x2F;Python-Optional&#x2F;optional.py</a>

My team has just spent 20 minutes trying to work out if this library is satire.<p>I love functional programming (use Elixir at work a fair amount), but almost every one of these examples is harder to read than than the equivalent &quot;classic&quot; Python (<a href="https:&#x2F;&#x2F;returns.readthedocs.io&#x2F;en&#x2F;latest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;returns.readthedocs.io&#x2F;en&#x2F;latest&#x2F;</a>).<p>Plus, if you&#x27;re going to write Python then deviating majorly from the normal approaches is going to require maintainers to learn a whole new way of doing things. Given the tools that Python provides, I don&#x27;t think that&#x27;s worth it for the benefit. Perhaps for some specific applications?

I don&#x27;t really disagree with other commenters saying that there are easier ways to read and write code in Python...<p>However:<p>- I think the response is excessively negative, there are some really great patterns in here<p>- I put most of the blame on the ugly &quot;design&quot; of the python language (and a lack of guardrails which takes away a lot of the value a library like this would otherwise provide)<p>- I can easily imagine this library, or an interface similar to it, being used on a large code base in a production&#x2F;commercial setting. I think people who can&#x27;t imagine that probably just don&#x27;t have a lot of imagination.

Ah great, I&#x27;ve been trying to make my Python look more like Scala!<p>In all honesty, Return&#x27;s docs call out how problematic if-else chaining is, and then proceeds to replace it with chained lambdas. How is that better?<p>I&#x27;d go as far as to say that we can avoid a lot of the null coercion stuff with proper encapsulation, but that is basically saying, &quot;We can solve Python&#x27;s FP challenges with better object design,&quot; and I understand how that may sound like nails on a chalkboard to some.<p>If this helps you write the kind of code you and your peers want and can understand, who am I to judge?

People in this thread seem to be conflating &quot;it&#x27;s less readable&quot; with &quot;it&#x27;s written in a dialect I&#x27;m not used to&quot;. The samples are perfectly readable to anyone who spent some time with a languages that offers similar functionality, other criticisms notwithstanding.

Why this constant desire in tech to make things more complicated instead of less? It drives me nuts.

Dupe of: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39432843">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39432843</a>

Python is just not made for FP, so any addition of FP into python makes it look even worse

None is the third-worst mistake in computer science, Maybe is the second-worst, the Result that can contain either a result or an exception is the worst.<p>I have debugged so much code that does the wrong thing with a Result (or other error handling). I will always remember the engineering manager who boasted about how we (1) did careful error handling with monads and (2) did code reviews. Oddly though I never got my code reviewed and I found so much code that silently dropped errors out of carelessness to believe there had never been code reviews. In my experience given a malfunctioning Scala class you can: (3) screw around with it for a few days or (4) write it in Java and have it working in an hour.<p>(A counter to this is that sometimes you do want to send a result-or-exception to some other part of the program that involves storing it somewhere and Result is really great for that… but please learn to get over any fear of exceptions you have and ignore the people who want to stigmatize them.)