dry-python / dry-python/returns
Interest check: implement __bool__ for Result and Maybe
- Dominant language
- Python
- Stars
- 4.4k
- Forks
- 155
- Avg merge
- 2h 27m
- Merged PRs (30d)
- 22
Description
Long before I found Returns, I implemented my own Result monad from scratch. It was a lot of fun, and right now it coexists with Returns as the library it's a part of is being incrementally deprecated. At some point, I decided it would be nice if I could do things like this:
```python
result = some_function() # Result[S, F]
if result:
reveal_type(result) # Success[S]
else:
reveal_type(result) # Failure[F]
```
It's worked great. I have my own analogue to `is_successful`, but with `__bool__` I don't even have to import it. Also, it actually works better than my functions: my analogue is a pair of `TypeGuard` functions (`TypeIs` didn't exist yet), so even after narrowing the container type in the first `if`, the `else` would have no type information about the container. Cf., `__bool__(self) -> Literal[False]` and `__bool__(self) -> Literal[True]` make type narrowing work perfectly, and it _feels_ very pythonic, imo.
As I update more and more code to use Returns, instead, I find this to be the one thing about my library that I actually miss. There are a lot of cases where I _could_ reach for `match` for something as ergonomic, but most of the time I'm only interested in Success vs. Failure; `match` is overkill if I don't need to peak at the contained value.
The one drawback I anticipate to adding this feature would be the possibility of breaking any code that's relying on the default `object.__bool__` behavior to differentiate a `Failure` from eg. a `None`... but hopefully, anybody using this library would have their Optionals wrapped in a `Maybe` already?
Contributor guide
Assessment
This issue has not been assessed yet.