You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
typing._eval_type is not preserving GenericAlias subclasses #130870
@Viicos How does this cause a problem in practice? Changing get_type_hints in this way will end up exposing implementation details, and I'm not sure it's worth the hassle if all we're after is getting a nicer repr().
collections.abc.Callable is such an example because the generic alias used is a GenericAlias subclass, but this can happen with any GenericAlias subclass (for instance with Pydantic, where we are trying to see how to use a GenericAlias subclass for parameterized generic Pydantic models). With this bug, it won't be possible to use generic Pydantic models in forward annotations.
Changing get_type_hints in this way will end up exposing implementation details
If you are referring to _should_unflatten_callable_args(), it is already there in the existing code. See my PR (the second one) for more details. I'll take a look at CI failures shortly.
If you are referring to _should_unflatten_callable_args(), it is already there in the existing code.
I'm referring to the _CallableGenericAlias instance, which isn't available or documented anywhere else. My concern is that we'll encouraging people to do introspection on the private API, which isn't fun for us when we want to change things. (But maybe this isn't a huge issue for typing?)
IMO, if you want this level of introspection, you should just use __annotations__ and parse things on your own. You're correctly opting in to extra maintenance by doing that.
I'm referring to the _CallableGenericAlias instance, which isn't available or documented anywhere else.
I just used this as an example to illustrate the bug. _CallableGenericAlias is a private type, but subclassing GenericAlias is publicly documented and currently such aliases are lost during type evaluation in typing._eval_type() (relied on by the public functions such as typing.get_type_hints()). See also the added test in my PR.
Activity
sharktide commentedon Mar 5, 2025
I'll make a pr on this branch
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
Add new test to test_typing.py to demonstrate fixed behaviour in pyth…
ZeroIntensity commentedon Jun 7, 2025
@Viicos How does this cause a problem in practice? Changing
get_type_hintsin this way will end up exposing implementation details, and I'm not sure it's worth the hassle if all we're after is getting a nicerrepr().Viicos commentedon Jun 8, 2025
collections.abc.Callableis such an example because the generic alias used is aGenericAliassubclass, but this can happen with anyGenericAliassubclass (for instance with Pydantic, where we are trying to see how to use aGenericAliassubclass for parameterized generic Pydantic models). With this bug, it won't be possible to use generic Pydantic models in forward annotations.If you are referring to
_should_unflatten_callable_args(), it is already there in the existing code. See my PR (the second one) for more details. I'll take a look at CI failures shortly.ZeroIntensity commentedon Jun 8, 2025
I'm referring to the
_CallableGenericAliasinstance, which isn't available or documented anywhere else. My concern is that we'll encouraging people to do introspection on the private API, which isn't fun for us when we want to change things. (But maybe this isn't a huge issue for typing?)IMO, if you want this level of introspection, you should just use
__annotations__and parse things on your own. You're correctly opting in to extra maintenance by doing that.Viicos commentedon Jun 9, 2025
I just used this as an example to illustrate the bug.
_CallableGenericAliasis a private type, but subclassingGenericAliasis publicly documented and currently such aliases are lost during type evaluation intyping._eval_type()(relied on by the public functions such astyping.get_type_hints()). See also the added test in my PR.ZeroIntensity commentedon Jun 9, 2025
Hm, ok, that makes more sense. For clarity: how is your PR (#131583) different from the first PR (#130897)?
sharktide commentedon Jun 9, 2025
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
gh-130870: Preserve `GenericAlias` subclasses in `typing.get_type_hin…
Viicos commentedon Jul 6, 2025
No backport required, so the issue along with the initial fix (#130897) can be closed.
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…
pythongh-130870: Preserve `GenericAlias` subclasses in `typing.get_ty…