Repository navigation
Top / function argument level ClassVar should not be allowed during get_type_hints() #89446
Description
| BPO | 45283 |
|---|---|
| Nosy | @gvanrossum, @ambv, @sobolevn, @Fidget-Spinner |
| PRs |
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:
assignee = None
closed_at = None
created_at = <Date 2021-09-24.13:44:07.559>
labels = ['type-bug', 'library', '3.9', '3.10', '3.11']
title = 'Top / function argument level ClassVar should not be allowed during `get_type_hints()`'
updated_at = <Date 2021-09-26.17:09:09.780>
user = 'https://github.com/sobolevn'bugs.python.org fields:
activity = <Date 2021-09-26.17:09:09.780>
actor = 'lukasz.langa'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-09-24.13:44:07.559>
creator = 'sobolevn'
dependencies = []
files = []
hgrepos = []
issue_num = 45283
keywords = ['patch']
message_count = 7.0
messages = ['402563', '402628', '402631', '402636', '402640', '402641', '402671']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'lukasz.langa', 'sobolevn', 'kj']
pr_nums = ['28563']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue45283'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
Activity
sobolevn commented on Sep 24, 2021
This code currently does not raise any issues:
And then:
It should not be allowed. Currently, the same with from __future__ import annotations does correctly raise TypeError: typing.ClassVar[int] is not valid as type argument
Related: #28279
I will send a PR with the fix shortly.
gvanrossum commented on Sep 25, 2021
Hm. IMO it is up to static type checkers to reject bad use of types. The runtime should be relaxed so type checkers can develop new features assigning new semantics to such constructs.
Fidget-Spinner commented on Sep 25, 2021
This makes get_type_hints quite opinionated and backwards incompatible. The first line the docs says "This is often the same as obj.annotations".
I also agree with Guido. FYI, we've tried to reduce usage of _type_check in new features since version 3.10. We've found that they make typing_extensions operability with typing worse. For example, the whole of PEP-612 in typing_extensions required lots of hacks to work with typing's Callable.
If you're really vouching for this change. We probably need a 2 major version deprecation period (with warnings telling the user their current type hints are invalid) *plus* asking typing-sig/python-dev if the runtime type hints users will be affected. See PEP-387 for more info.
On the other hand, we now have a less-opinionated alternative to get_type_hints with inspect.get_annotations, but it can't do as much (like resolving ForwardRef).
sobolevn commented on Sep 25, 2021
Just to bring in some context for this discussion: #28279
We have dicussed in the PR above that current implementation depends on existing of __future__ import of annotations.
With from __future__ import annotations:
Without from __future import annotationsit accepts all the cases above.
I share two opposite views on this change:
My opinion is that consitency is more important here. Because I received quite a lot of bug reports from users involving different behavior with / without __future__ import of annotations.
But, I understand that it is not up to me to decide :)
Fidget-Spinner commented on Sep 25, 2021
That's definitely a plus. But please consider this hypothetical scenario:
If this sounds familiar, that's because something similar has already happened! Callable and Generic had too strict checking in typing (requiring Callable's args to be a tuple of types always) before 3.10. So typing_extensions doesn't support the full PEP-612 syntax :( https://github.com/python/typing/tree/master/typing_extensions#other-notes-and-limitations.
Stricter runtime type checking makes growing the typing syntax harder. For the newer types, we try to defer checking to 3rd-party libraries.
Your perspective as a runtime typing library dev is very valuable. Thank you for your feedback! IMO, from __future__ import annotations becoming the default in 3.11 is still undecided. It was yanked from 3.10 for breaking pydantic and FastAPI, and I doubt it will land in 3.11 for the same reasons. It seems the current consensus is to use that import for code with purely static typing, and not use it with runtime typing libraries.
sobolevn commented on Sep 25, 2021
Thank you, Ken Jin! Very clear explanation!
Is it an official position? Or just a common usage pattern?
What can we do to make this more widely known?
Maybe we can formulate something like "When to use: raw, string, future annotations" in the typing docs (https://docs.python.org/3/library/typing.html)?
ambv commented on Sep 26, 2021
No, we need to decide what will happen to PEP-563 and PEP-649 in Python 3.11.
AlexWaygood commented on Apr 14, 2022
The consensus on this issue is that stricter runtime type-checking in get_type_hints (at least for ClassVar, probably also in general) would be undesirable, and the linked PR has been closed. I am therefore closing this issue.