dry-python / dry-python/returns

Interest check: implement __bool__ for Result and Maybe

Open
#2,394 0 comments 1 reaction 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.