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

Improve motivating example for Maybe

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

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
32/100
Tipo de issue
Documentação
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
python
Domínio
documentation

Direção de pesquisa

Comece localizando a seção da documentação que contém o exemplo atual de motivação para Maybe; nenhuma arquivo ou teste é indicado na issue. Compare o exemplo com as alternativas em Python mencionadas e esclareça o caso de uso pretendido. A tarefa estará concluída quando a documentação apresentar uma motivação convincente sem tratar retornos ambíguos de None como tratamento comum de erros.

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

Descrição

bug documentation

The current example motivating the use of Maybe is somewhat misleading because it solves a made-up problem:

Alleged original "python" code:

if user is not None:
     balance = user.get_balance()
     if balance is not None:
         credit = balance.credit_amount()
         if credit is not None and credit > 0:
             discount_program = choose_discount(credit)

Alleged "better" solution using Maybe:

discount_program: Maybe['DiscountProgram'] = Maybe.from_optional(
    user,
).bind_optional(  # This won't be called if `user is None`
    lambda real_user: real_user.get_balance(),
).bind_optional(  # This won't be called if `real_user.get_balance()` is None
    lambda balance: balance.credit_amount(),
).bind_optional(  # And so on!
    lambda credit: choose_discount(credit) if credit > 0 else None,
)

Usual python code solving this exact problem:

try:
    discount_program = choose_discount(user.get_balance().credit_amount())
except AttributeError:
    pass

The example is based on the very bad habit of signaling errors by return values, e.g. returning None.

No sane (python) developer would write a function that returns None in case of an error unless there is good reason for it, it is properly documented and returning None immediately and unambiguously tells the caller what went wrong. When exceptions occur, exceptions should be raised.

For example, credit_amount() returning None conveys no meaning at all. No credit? Credit amount == 0? Credit amount < 0? Raccoons taking over the world?

And even if one had to use flawed 3rd party code like this, there is a shorter and more concise version to handle this without Maybe.

I believe there is a legitimate use case for Maybe, but this is not it.

Linguagem predominante
Python
Estrelas
4.4k
Forks
155
Merge médio
2h 2min
PRs com merge (30d)
20

Preparar o ambiente

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.