Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#445 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Documentation
Clarté
À clarifier
Activité
À l'abandon
Stack technique
python
Domaine
backend

Piste de recherche

Commencez par la documentation et les points d’entrée liés aux IO mentionnés dans l’issue, en particulier unsafe_perform_io et la distinction entre le code Python encapsulé et le code Python standard. Clarifiez la raison de masquer le contenu des IO et documentez la limite prise en charge entre les opérations encapsulées dans des IO et le code Python ordinaire.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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").

Langage dominant
Python
Étoiles
4.4k
Forks
154
Merge moyen
3 h 5 min
PR mergées (30 j)
22

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de dry-python/returns

Toutes les issues de dry-python/returns

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.