inspect not capturing type annotations created by __class_getitem__ #89601
Comments
|
In the example below, __annotations__ is correct but not the corresponding Signature object. ----------------------------------------------------------------------- from typing import List
def f(s: List[float]) -> None: pass
def g(s: list[float]) -> None: pass>>> inspect.signature(f)
<Signature (s: List[float]) -> None>
>>> inspect.signature(g)
<Signature (s: list) -> None>g.__annotations__ |
|
Raymond, the bug must be in the Python code in inspect.py. Could you dig a little deeper there? I don't know much about it. Specifically I think the problem may just be in the repr() of class Parameter: >>> inspect.signature(g).parameters['s']
<Parameter "s: list">
>>> inspect.signature(g).parameters['s'].annotation
list[float]
>>> |
|
It looks like the error is in inspect.formatannotation(). For instances of type, that function incorrectly returns only annotation.__qualname__. Instead, it should return repr(annotation) which would include the args. ================================================================= def formatannotation(annotation, base_module=None):
if getattr(annotation, '__module__', None) == 'typing':
return repr(annotation).replace('typing.', '')
if isinstance(annotation, type): # <== Erroneous case
if annotation.__module__ in ('builtins', base_module):
return annotation.__qualname__
return annotation.__module__+'.'+annotation.__qualname__
return repr(annotation) |
|
Sure. Waiting for your PR. :-) |
|
The cause is that isinstance(list[int], type) returns True. It can cause bugs in other parts of the code which test for instance of type. For example: >>> types.resolve_bases((typing.List[int],))
(<class 'list'>, <class 'typing.Generic'>)
>>> types.resolve_bases((list[int],))
(list[int],)
>>> types.prepare_class('A', (int,), {'metaclass': typing.Type[int]})
(typing.Type[int], {}, {})
>>> types.prepare_class('A', (int,), {'metaclass': type[int]})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/serhiy/py/cpython/Lib/types.py", line 125, in prepare_class
meta = _calculate_meta(meta, bases)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/serhiy/py/cpython/Lib/types.py", line 139, in _calculate_meta
if issubclass(base_meta, winner):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: issubclass() argument 2 cannot be a parameterized generic
>>> @functools.singledispatch
... def g(a): pass
...
>>> @g.register
... def g2(a: typing.List[int]): pass
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "/home/serhiy/py/cpython/Lib/functools.py", line 863, in register
raise TypeError(
^^^^^^^^^^^^^^^^
TypeError: Invalid annotation for 'a'. typing.List[int] is not a class.
>>> @g.register(list[int])
... def g2(a): pass
...
>>> @g.register
... def g3(a: typing.List[int]): pass
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "/home/serhiy/py/cpython/Lib/functools.py", line 863, in register
raise TypeError(
^^^^^^^^^^^^^^^^
TypeError: Invalid annotation for 'a'. typing.List[int] is not a class.
>>> @g.register
... def g3(a: list[int]): pass
... And many other examples, too many to show here. Was it mistake to make isinstance(list[int], type) returning True? |
|
Can confirm for 3.9.7 as well. |
|
I just created a PR and signed the contributor agreement. Waiting for it to update :-) Comments welcome! |
|
There are two ways to fix the larger issue.
I tried to implement option 1, but it is just too much places, so it would take a large amount of time which I do not have right now. First than invest my time in this I want to make sure which option is desirable in long term. Guido, Ivan, Ken Jin, what would you say? |
What was the motivation for this? At first glance returning True looks wrong. |
|
I really don't recall if we even seriously considered what isinstance(list[int], type) should return. PEP-585 doesn't mention it. I presume it falls out of the way it's being tested and the way list[int] passes most attribute requests on to the origin (i.e., to list). Given that this has returned True for two releases now I'm very reluctant to changing this now. So our best option is pursuing Serhiy's option 1, at least partially. The fix for the OP should be simple enough, right? |
|
Two years is not so long for a bug. We fixed 8-year and 12-year bugs. The issue is that this feature is internally inconsistent (isinstance() is not consistent with issubclass()), the C implementation of list[int] is not consistent with the Python implementation of List[int], and a lot of code was not tested with this feature, so we perhaps have a lot of bugs in the stdlib and in the third-party libraries. Are we going to backport changes for making code working with GenericAlias as a type to 3.9 and 3.10? If not, we will actually add new features in 3.11 and keep 3.9 and 3.10 broken. If yes, these changes can have larger effect than just making isinstance(list[int], type) returning False, and they can break more code. Note also that isinstance(List[int], type) was True before 3.7, and we intentionally made it False in 3.7 (it was required significant rewriting of the typing module and introducing __mro_entries__). Do we want to revert this decision? |
issubclass(x, list[int]) rejects the second argument for reasons explained in the PEP. I don't think from that reasoning you can infer that list[int] is not a type. Rather the contrary -- if it's not a type the PEP could just have said "it's not a type" but it doesn't, it says "it's unacceptable as second arg to issubclass()". In fact, the PEP uses language ("instances of parameterized collections") that makes me think in the PEP author's mind list[int] *is* a type.
Consistency with typing was not a goal of the PEP.
What other places are there that are broken because of this?
Without more evidence this sounds like speculation. *With* evidence you might well convince me.
I'm fine with backporting the fix in the PR, #73398.
Are there other fixes you already know about besides #73398? That PR seems 100% beneficial.
I don't recall why we changed that, I thought it was a side effect of making the implementation faster, not because of a decision that we didn't want these to be treated as types. I looked at inspect.py in 3.6, and it seems its formatannotation() has a special case for annotations that come from the typing module (like List[int]). I guess nobody thought to have a test for that, so the bug in inspect.py slipped by when it was introduced in 3.9 -- we're relying on Raymond's keen eye here. But if we had had such a test, and it had alerted us to the problem in 3.9 when types.GenericAlias was introduced, I expect that we would have fixed it just like martinitus does in his PR. Anyway, I am willing to be swayed by evidence, but this bug in inspect.py isn't enough. |
|
Just my two cents as a new contributor but long time user:
|
|
Can we close this? |
In msg403826 I showed few examples from just two files, but there are |
|
See also bpo-40296. |
|
OK, OK, I see your point. I'm curious what Łukasz thinks. |
|
I have opened separate issues for different cases and a meta-issue45665 for general discussion. |
serhiy-storchaka
added
type-bug
|
is there a recommended workaround until this is fixed? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: