Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Interest check: implement __bool__ for Result and Maybe

Aperta
#2,394 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

L'issue non indica file o test specifici. Inizia individuando le implementazioni di Result e Maybe e i relativi test esistenti di narrowing dei tipi, quindi esamina come vengono distinti Success e Failure. Done deve includere il comportamento concordato di bool per entrambi i tipi, la copertura per i tipi rivelati e la considerazione della compatibilità con le assunzioni esistenti sulla veridicità.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
Python
Stelle
4.4k
Fork
154
Merge medio
3h 5m
PR unite (30g)
22

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dry-python/returns

Tutte le issue di dry-python/returns

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.