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
I have a module that needs to inspect type annotations on a few functions. One of the types I need to special case on is typing.Tuple, and I used code like this to detect it:
This was based on the comment from the typing module (Lib/typing.py:609) that specified this particular invariant on the __origin__ attribute:
__origin__ keeps a reference to a type that was subscripted,
e.g., Union[T, int].__origin__ == Union;
Everything worked just fine until I checked it on the alpha release of Python 3.7 in my CI. Turns out, that in that release we have
typing.Tuple[str, int].__origin__ == tuple
and not (which is the case in e.g. 3.6)
typing.Tuple[str, int].__origin__ == typing.Tuple
I know this is not a documented attribute, so it can change, but I wanted to highlight that it's either a regression, or the comment will need to be updated, so people won't try to depend on that.
Yes, the comment needs to be updated, but as you said, no guaranties about undocumented dunder attribute. We tried to preserve as much of the API as possible in 3.7 after PEP-560, but something needs to be sacrificed (especially in the purely internal API you used).
You may instead use typing_inspect library on PyPI, I am not 100% sure it will help in your case, but it has is_tuple_type function that should work across several versions of typing.
apaszke commented on May 3, 2018
apaszkemannequin
MannequinAuthor
More actions
Of course, I'm not expecting this to be 100% reliable, and so I'm ok with the answer that the comment is now outdated.
I'd like to avoid adding extra dependencies for so simple things, so I guess I'll just special case that in my code for now. It would be great if the typing module had some tools for introspection built in!
Activity
apaszke commentedon May 3, 2018
Hi everyone,
I have a module that needs to inspect type annotations on a few functions. One of the types I need to special case on is typing.Tuple, and I used code like this to detect it:
This was based on the comment from the typing module (Lib/typing.py:609) that specified this particular invariant on the __origin__ attribute:
Everything worked just fine until I checked it on the alpha release of Python 3.7 in my CI. Turns out, that in that release we have
typing.Tuple[str, int].__origin__ == tuple
and not (which is the case in e.g. 3.6)
typing.Tuple[str, int].__origin__ == typing.Tuple
I know this is not a documented attribute, so it can change, but I wanted to highlight that it's either a regression, or the comment will need to be updated, so people won't try to depend on that.
ilevkivskyi commentedon May 3, 2018
Yes, the comment needs to be updated, but as you said, no guaranties about undocumented dunder attribute. We tried to preserve as much of the API as possible in 3.7 after PEP-560, but something needs to be sacrificed (especially in the purely internal API you used).
You may instead use
typing_inspectlibrary on PyPI, I am not 100% sure it will help in your case, but it hasis_tuple_typefunction that should work across several versions oftyping.apaszke commentedon May 3, 2018
Of course, I'm not expecting this to be 100% reliable, and so I'm ok with the answer that the comment is now outdated.
I'd like to avoid adding extra dependencies for so simple things, so I guess I'll just special case that in my code for now. It would be great if the typing module had some tools for introspection built in!
[-]__origin__ invariant broken[/-][+][typing] __origin__ invariant broken[/+]ilevkivskyi commentedon May 9, 2018
This is now fixed on master by 43d12a6 (the comment is updated).