Interest check: implement __bool__ for Result and Maybe
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Issue không nêu các tệp hoặc bài kiểm thử cụ thể. Hãy bắt đầu bằng việc xác định các phần triển khai của Result và Maybe cùng các bài kiểm thử narrowing kiểu hiện có của chúng, sau đó xem xét cách phân biệt Success và Failure. Done phải bao gồm hành vi bool đã thống nhất cho cả hai kiểu, coverage cho các kiểu được suy ra và việc xem xét khả năng tương thích với các giả định hiện có về truthiness.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
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:
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?
- Ngôn ngữ chính
- Python
- Star
- 4.4k
- Fork
- 154
- Merge trung bình
- 3 giờ 5 phút
- Pull request đã merge (30 ngày)
- 22
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của dry-python/returns
-
Composing 0-argument functions Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
dry-python/returns#2365 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
dry-python/returns#2355 · 1 bình luận ·
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
dry-python/returns#2295 · 4 bình luận · 1 reaction ·
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
dry-python/returns#2253 · 2 bình luận ·
-
Incorrect result type for `returns.curry.partial` with keyword arguments for positional parameters Đang mởbug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
dry-python/returns#2191 · 1 bình luận ·
Tất cả issue của dry-python/returns
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
stephrobert/dsoxlab#238 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
sublimehq/package_control#1780 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
nwg-piotr/nwg-displays#145 ·