Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
#445 2 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Documentação
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
python
Domínio
backend

Direção de pesquisa

Comece pela documentação e pelos pontos de entrada relacionados a IO mencionados na issue, especialmente unsafe_perform_io e a distinção entre código Python encapsulado e código Python padrão. Esclareça a justificativa para ocultar o conteúdo de IO e documente o limite compatível entre operações encapsuladas em IO e código Python comum.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Python
Estrelas
4.4k
Forks
154
Merge médio
3h 5min
PRs com merge (30d)
22

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de dry-python/returns

Todas as issues de dry-python/returns

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.