Proposal: Add coerced type narrowing similar to 'cast'
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
My suggestion is to add a way to coerce type narrowing without any runtime change,
by adding new type_assert and/or ensure_type.
def function(arg: Any):
type_assert isinstance(arg, int)
reveal_type(arg) # Revealed type: "builtins.int"
def function(arg: Any):
ensure_type(arg, int)
reveal_type(arg) # Revealed type: "builtins.int"
These functions do nothing at runtime! they only help with the types.
Why not cast(int, arg)?
-
castcompletely replaces the type and we need to write a full new type.
With type narrowing it's only necessary to limit the options of the existing type.def function(arg: Union[int, str, list]): arg = cast(Union[str, list], arg) reveal_type(arg) # Revealed type: "str | list"def function(arg: Union[int, str, list]): type_assert not isinstance(arg, int) # only need to remove 'int' reveal_type(arg) # Revealed type: "str | list" -
castis more dangerous because we ignore the previous type. with narrowing we just limit the options of the previous type.def function(arg: Union[int, str, list]): arg1 = cast(dict, arg) reveal_type(arg1) # Revealed type: "dict"def function(arg: Union[int, str, list]): type_assert not isinstance(arg, dict) # Error: Subclass of "int" and "dict[Any, Any]" cannot existdef function(arg: Union[int, str, list]): type_assert not isinstance(arg, int) type_assert not isinstance(arg, str) type_assert not isinstance(arg, list) reveal_type(arg) # Error: Statement is unreachable -
castcan't doIntersection(yet). explained below.
Why type_assert and not a normal assert?
assertmakes it slower at runtime, and sometimes we careassertcan break things when improving types of an old code base
The downsides:
- Without
assertor if-else conditions at runtime, the coerced narrowing ignores the real type and is dangerous, almost likecast.
With Intersection type
Until we have Intersection type, this kind of things are problematic:
class Animal:
def say_my_name(self) -> None:
print("My name is Animal")
@runtime_checkable
class CanFlyProtocol(Protocol):
def fly(self) -> None: ...
class Bird(Animal, CanFlyProtocol):
def fly(self) -> None:
print("Fly")
def let_it_fly(animal: Animal): # we can't restrict the argument type to be Animal AND CanFlyProtocol
animal.say_my_name()
animal.fly() # Error: "Animal" has no attribute "fly"
Even cast can't help us, but we can narrow the type!
def let_it_fly(animal: Animal):
assert isinstance(animal, CanFlyProtocol)
animal.say_my_name()
animal.fly()
reveal_type(animal) # Revealed type: "<subclass of "Animal" and "CanFlyProtocol">"
Type checkers can understand Intersection when we narrow the type, great!
But what if we don't want to change runtime behavior? for this we can
replace assert with the suggested type_assert or ensure_type!
def let_it_fly(animal: Animal):
type_assert isinstance(animal, CanFlyProtocol)
animal.say_my_name()
animal.fly()
reveal_type(animal) # Revealed type: "<subclass of "Animal" and "CanFlyProtocol">"
A side note: with
type_assertwe probably can stop adding@runtime_checkableto Protocols, if we only added it for this kind of type-hint only issues thatassert isinstance(animal, CanFlyProtocol)solved.
Performingisinstancewith Protocol is very slow so this benefit is not small.
ensure_type with Not
See:
def function(arg: Union[int, str, list]):
type_assert not isinstance(arg, int)
reveal_type(arg) # Revealed type: "str | list"
How to do not isinstance with ensure_type? we have two options:
-
Add a similar
ensure_not_typedef function(arg: Union[int, str, list]): ensure_not_type(arg, int) reveal_type(arg) # Revealed type: "str | list" -
Wait for the
Not[]typedef function(arg: Union[int, str, list]): ensure_type(arg, Not[int]) reveal_type(arg) # Revealed type: "str | list"
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
El issue no menciona archivos, tests ni puntos de entrada de la implementación. Empieza revisando las formas propuestas type_assert y ensure_type y las discusiones vinculadas sobre Intersection y Not; define la semántica compatible, el comportamiento en tiempo de ejecución y las pruebas de aceptación antes de la implementación.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- python
- Área
- devtools
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Estancado
- Claridad
- Necesita aclaración
- Aptitud para principiantes
- 25/100