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

Allow returning `AnyOf` rather than `Any` for amiguous overloads.

Aberta
#2,196 4 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
30/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
python
Domínio
documentation

Direção de pesquisa

Comece pela etapa 5 da especificação de overload e pela definição de equivalent no glossário vinculada na issue. Analise o exemplo A[Any] e A[None] e determine se overloads ambíguos devem manter uma união em vez de se tornarem Any. Está concluído quando a especificação de typing tiver uma regra decidida e documentada para este caso e o exemplo refletir essa regra.

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

Descrição

topic: feature topic: typing spec

Currently, the typing spec for overloads, step 5, states that

Once this filtering process is applied for all arguments, examine the return types of the remaining overloads. If these return types include type variables, they should be replaced with their solved types. If the resulting return types for all remaining overloads are equivalent, proceed to step 6.

If the return types are not equivalent, overload matching is ambiguous. In this case, assume a return type of Any and stop.

However, couldn't this rule be relaxed to returning the union of the return type of all matching overloads? For instance, consider this example derived from a real world use case (numpy scalar ops)

from typing import Any, overload, assert_type

class A[T]:  # covariant
    def get(self) -> T: ...

@overload
def op(l: A[None], r: A[None]) -> A[None]: ...
@overload
def op(l: A[None], r: A[Any]) -> A[None]: ...
@overload
def op(l: A[Any], r: A[None]) -> A[None]: ...
@overload
def op(l: A[Any], r: A[Any]) -> A[Any]: ...

def test(x: A[None], y: A[Any]) -> None:
    assert_type(op(x, x), A[None])  # spec: ✅️ 
    assert_type(op(x, y), A[None])  # spec: ✅️
    assert_type(op(y, x), A[None])  # spec: ✅️
    assert_type(op(y, y), A[Any] | A[None])     # spec: ❌️ (expected Any)

According to the rule stated above, op(A[Any], A[Any]) should be inferred to as Any, because the overloads are ambious and A[Any] is not equivalent to A[None] as not all materializations of A[Any] can be assigned to A[None].

However inferring Any loses deducible information: we know that no matter what, the return type must be an A. So in principle the return type should be A[Any] | A[None], because if either the left argument or the right argument materializes to A[None], then we get A[None] and otherwise if they materialize to something else we get A[Any].

Linguagem predominante
Python
Estrelas
1.8k
Forks
302
Merge médio
23h
PRs com merge (30d)
8

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

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 python/typing

Todas as issues de python/typing

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.