dry-python / dry-python/returns

Interest check: implement __bool__ for Result and Maybe

Đang mở
#2,394 0 bình luận 1 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Python
Star
4.4k
Fork
155
Merge trung bình
2 giờ 27 phút
Pull request đã merge (30 ngày)
22

Mô tả

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?

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.