This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.smith
Recipients GBeauregard, JelleZijlstra, eric.smith
Date 2022-01-25.17:22:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1643131352.69.0.995116737868.issue46511@roundup.psfhosted.org>
In-reply-to
Content
My thoughts are that I'd like PEP 563 to go away, and PEP 649 to be accepted, and also never allow string literal annotations like the string "Annotated[ClassVar[int]]". But since we'll no doubt have to support string-ized annotations even if PEP 649 is accepted, that's a pipe dream.

I think your suggestion for #1 seems reasonable.

For #2, in the case where typing has been imported and the annotation isn't a string, I assume it's simple enough to look inside the Annotated object and extract the InitVar (or ClassVar) object. I haven't delved in to Annotated object yet.

For #2, with a string annotation, it does look like it will get ugly. I'll have to spend some time looking at _MODULE_IDENTIFIER_RE. I'm guessing we'll need another re that looks for the same basic thing with "Annotated[" or "module.Annotated[" prepended and then look inside that. Or maybe one re to do both. I don't think we should support cases like:

from __future__ import annotations
myAnnotated = typing.Annotated

@dataclass
class Foo:
    a: myAnnotated[ClassVar[int]]

(That is, we won't recognize the string "myAnnotated[ClassVar[int]]" as an Annotated ClassVar.

Maybe we should also restrict it to "Annotated" or "typing.Annotated", but that would prevent someone from using "import typing as _typing", for example. This is why the current code accepts any module name, not strictly "typing". At least that's my recollection, more study is needed.

Or maybe it's time to give up and use typing.get_type_hints() or inspect.get_annotations(), but I suspect there are enough corner cases that will fail that we'll never get that to work right. Nested classes, anyone?

The whole runtime inspection of string-ized annotations is a mess.

On the "performance is important" comment: I'm not sure this is really an issue any more. There was some PEP that was supposed to speed up importing typing, and I never looked at the performance once it was merged. But then again, I'm not sure we want to always have dataclasses import typing, either. If a program doesn't use dataclasses that using the typing module, there's no sense importing it and enlarging the working set of modules.

I welcome any insights on any of these issues. I'm not a typing expert.
History
Date User Action Args
2022-01-25 17:22:32eric.smithsetrecipients: + eric.smith, JelleZijlstra, GBeauregard
2022-01-25 17:22:32eric.smithsetmessageid: <1643131352.69.0.995116737868.issue46511@roundup.psfhosted.org>
2022-01-25 17:22:32eric.smithlinkissue46511 messages
2022-01-25 17:22:32eric.smithcreate