BEbehnamoh·Feb 19, 2024Submission
Python Functional Programming with returns library (type-safety, monads, etc.)
12 points · Open discussiondry-python
returns
Python2020–2024
dry-python / returns
returns
Make your functions return something meaningful, typed, and safe!
7Distinct people
7Mentions
0Explicit recommenders
4.4KGitHub stars
What to know before exploring
What it is
Make your functions return something meaningful, typed, and safe!
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year7 dated mentions
Observed mentions: 2020-02-03 15:24:17 UTC to 2024-02-19 18:11:32 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
7 sourcesIt looks like a distinction without a difference. We can consider `None and f()` pattern as explicit syntax that unwraps objects as necessary without infecting other code.
Background: an object that either None or true in a boolean context (true unless overriden for custom objects).
Given such object, we can consider it in a virtual Maybe container/box.
When we want to use it, we have to unwrap it using `obj and obj.method()` syntax.
Then `obj.method()` is ordinary "unwrapped" call.
Just to remind you. Here's how "ergonomic" Maybe variant from the article look like:
# Type hint here is optional, it only helps the reader here:
discount_program: Maybe['DiscountProgram'] = Maybe.from_optional(
user,
).bind_optional( # This won't be called if `user is None`
lambda real_user: real_user.get_balance(),
).bind_optional( # Th
Read the rest
is won't be called if `real_user.get_balance()` is None
lambda balance: balance.credit_amount(),
).bind_optional( # And so on!
lambda credit: choose_discount(credit) if credit > 0 else None,
)
https://github.com/dry-python/returns#maybe-container
You can decide for yourself what is more readable: all these lambdas or the `None and f()` code.
I wholefully agree, the problem with this kind of repos is that Python already makes most patterns trivial. So you either create a trivial example that does not bring value or you introduce unnecessary abstractions for the sake of them.
I am always looking into these repos though because I am still interested in learning new Python tricks.
One of the repos that I found interesting recently is https://github.com/dry-python/returns
In Python-patterns – A collection of design patterns/idioms in PythonA similar "framework", very robust and used in production systems, is dry-python's one[0][1].
The approach taken is a bit different I think, since they rely heavily on `mypy` plugins to reach type safety and functional constructs otherwise impossible to get, without runtime inspections.
0: https://github.com/dry-python
1: https://github.com/dry-python/returns
In Show HN: Koda, a typesafe functional toolkit for PythonFunctional Programming in Python
145 points · Open discussionIt's hard to do logging well, but some logs are better than no logs for the purposes of visibility. When something goes wrong and you need to audit the event trail, you reach for logs. If you don't have visibility when things go wrong, the first thing you do is add them so you get visibility.
I was originally inclined to say this article was written by an amateur at best and at worst, an edgy contrarian with questionable intentions. It looks like the rather is somewhat the truth. The author is the author of the `returns` [1] python library, which aims to "make your functions return something meaningful, typed and safe" -- is this the end result? No logging?
Are we to live in some kind of statically typed utopia where users never do unexpected things, the domain model never changes on a dime, algorithms never have edge cases and software i
Read the rest
s all formally provable, easy to reason about, purely functional and stateless? I can almost assure you that management at any customer facing firm will disagree on whether logging is necessary or not, for reasons that are obvious for anyone who has ever talked to a customer in their life.
Not to wax philosophical and get overly personal for a second, but why does FP have this effect on some of its practitioners? Is what happens when you spend too much time in the cathedral of academia that you forget how eldritch monstrosities can be built and maintained in any style of code, with any sophistication of typing system or automated theorem prover or formal verification? That the problems often come in at the requirements level, and that much of the job of the engineer is honing, refining and disambiguating the requirements deeper than the business otherwise can? There is no escape at the code level, only at the organization level.
[1] https://github.com/dry-python/returns
Show HN: Dry-Python/returns 0.13 – typed Reader and IOResult monads
2 points · Open discussion