Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Interest check: implement __bool__ for Result and Maybe

Abierto
#2,394 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend

Línea de trabajo

El issue no especifica archivos ni pruebas concretos. Empieza localizando las implementaciones de Result y Maybe y sus pruebas existentes de narrowing de tipos; después, revisa cómo se distinguen Success y Failure. Done debe incluir el comportamiento acordado de bool para ambos tipos, cobertura para los tipos revelados y la consideración de la compatibilidad con las suposiciones existentes sobre los valores de verdad.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

Lenguaje dominante
Python
Estrellas
4.4k
Forks
154
Merge medio
3 h 5 min
PR fusionados (30 d)
22

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dry-python/returns

Todos los issues de dry-python/returns

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.