Allow returning `AnyOf` rather than `Any` for amiguous overloads.
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Python
- Estrellas
- 1.8k
- Forks
- 302
- Merge medio
- 23 h
- PR fusionados (30 d)
- 8
Descripción
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].
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza con el paso 5 de la especificación de overloads y la definición del glosario de equivalent enlazada en el issue. Analiza el ejemplo A[Any] y A[None] y determina si los overloads ambiguos deben conservar una unión en lugar de convertirse en Any. Se considera terminado cuando la especificación de typing tiene una regla decidida y documentada para este caso y el ejemplo refleja esa regla.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- python
- Área
- documentation
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Estancado
- Claridad
- Bastante claro
- Aptitud para principiantes
- 30/100