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

Offen

#445 erstellt am 01.7.2020 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 25/100

Issue-Typ: Dokumentation
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: python
Bereich: backend

Rechercherichtung

Beginne mit der im Issue erwähnten Dokumentation und den IO-bezogenen Einstiegspunkten, insbesondere unsafe_perform_io und der Unterscheidung zwischen gewrapptem und standardmäßigem Python-Code. Kläre die Gründe dafür, die IO-Inhalte zu verbergen, und dokumentiere die unterstützte Grenze zwischen IO-gewrappten Operationen und gewöhnlichem Python-Code.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache: Python
Sterne: 4.4k
Forks: 154
Ø Merge: 3 Std. 5 Min.
Gemergte PRs (30 T.): 22

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus dry-python/returns

Interest check: implement __bool__ for Result and Maybe Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100

dry-python/returns#2394 · 1 Reaktion · Erstellt am 04.5.2026
Composing 0-argument functions Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100

dry-python/returns#2365 · Erstellt am 02.4.2026
IOSuccess / IOFailure and match-case Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100

dry-python/returns#2355 · 1 Kommentar · Erstellt am 13.3.2026
Pyright type checker won't let me pattern match just `Success` and `Failure` for a function returning `Result` Offen

bug

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100

dry-python/returns#2295 · 4 Kommentare · 1 Reaktion · Erstellt am 06.11.2025
No type error detected when function with wrong type is used in the middle of a pipe Offen

bug

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100

dry-python/returns#2253 · 2 Kommentare · Erstellt am 16.9.2025

Alle Issues in dry-python/returns