How about writting modern and proper Python first? Not to mention designing a decent API?<p>Let's examine the README example for a minute:<p><pre><code> 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
</code></pre>
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:<p>- one should probably never reach this part of the code if there is no user. But I'll indulge the author.<p>- don't put can_buy_stuff in an else close, what's the point?<p>- using type hints for no reason, but not other modern facilities like the walrus operator?<p>- do we really want users without a balance? Let's indulge this, but it seems a bad design.<p>- what's with all those unecessary conditional blocks?<p>- credit_amount should never be None. It's a Balance object, put a sane default value. But ok, indulging again.<p>So, you get down to:<p><pre><code> user: Optional[User]
can_buy_stuff = False
if user and (balance := user.get_balance()):
can_buy_stuff = (balance.credit_amount() or 0) > 0
</code></pre>
I don't think the solution the lib offers is superior:<p><pre><code> can_buy_stuff: Maybe[bool] = Maybe.from_value(user).map(
lambda real_user: real_user.get_balance(),
).map(
lambda balance: balance.credit_amount(),
).map(
lambda balance_credit: balance_credit > 0,
)
</code></pre>
And that's if we are using the rules of the README, which are not fair.<p>If we have a well designed API, and we use a function (more testable, and hey, are we doing FP or not ?), then:<p><pre><code> def can_buy_stuff(user: User):
if (balance := user.get_balance()):
return balance.credit_amount() > 0
return False
</code></pre>
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.<p>You could even that as a method or raise NoBalance depending of your case.<p>Bottom line, if you really feel that strongly about None, don't jump on the bazooka to kill this fly, go to <a href="https://discuss.python.org" rel="nofollow">https://discuss.python.org</a> and advocate for PEP 505 (None-aware operators): <a href="https://www.python.org/dev/peps/pep-0505/" rel="nofollow">https://www.python.org/dev/peps/pep-0505/</a><p>It's been deferred since 2015.<p>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.