| 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: 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,
)
And that's if we are using the rules of the README, which are not fair.If we have a well designed API, and we use a function (more testable, and hey, are we doing FP or not ?), then: def can_buy_stuff(user: User):
if (balance := user.get_balance()):
return balance.credit_amount() > 0
return False
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. Bottom line, if you really feel that strongly about None, don't jump on the bazooka to kill this fly, go to https://discuss.python.org and advocate for PEP 505 (None-aware operators): https://www.python.org/dev/peps/pep-0505/ It's been deferred since 2015. 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. |