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

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

Aperta
#445 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Inizia dalla documentazione e dagli entry point relativi a IO menzionati nell’issue, in particolare unsafe_perform_io e la distinzione tra il codice Python sottoposto a wrapping e il codice Python standard. Chiarisci la motivazione per nascondere i contenuti di IO e documenta il confine supportato tra le operazioni sottoposte a wrapping con IO e il normale codice Python.

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

Descrizione

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

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.