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

Motivation behind not being able to get IO's content, and IO-wrapped interfacing with unwrapped (normal) code

Abierto
#445 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python
Área
backend

Línea de trabajo

Empieza por la documentación y los puntos de entrada relacionados con IO mencionados en el issue, especialmente unsafe_perform_io y la distinción entre el código Python envuelto y el código Python estándar. Aclara la justificación para ocultar el contenido de IO y documenta el límite compatible entre las operaciones envueltas en IO y el código Python ordinario.

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

Descripción

Hi! Question(s) on IO.

I am trying to write a little wrapper for some stateful operation (imagine I have to do IO from/to a file), and I found out that IO containers are designed to hide their content. It's impossible to get the value of, say, a successful read result (nothing like IOSuccess.unwrap()), unless one uses unsafe_perform_io.

What is the rationale behind this design? I am asking because I am not familiar with writing typed functional code, and I could not find a motivation in the documentation for why it shouldn't be possible to get the raw content of an IO container.

Second question related to interface between IO-wrapped code and normal "unsafe" code:

Let's say I am writing code A where want to mark and wrap all IO operations. Now, code A has to interface with standard python code B. What choices do I have to make them talk?

Do I have to unwrap all my operations with unsafe_perform_io, in case I want to do something simple like getting a string from my wrapped code? Do I have to rewrite code B by making it all safe and IO-wrapped, so that they can communicate with no "unsafe" bridge between them?

It seems that in such scenario I would end up with code pieces that are of "different colors" - using the usual async-vs-sync metaphore of incompatible red and blue code -, and I would be forced to make everything of the same color.

(Here "red code" = "python code written in railway style" and "blue code" = "standard procedural python code").

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.