Eric V. Smith <e...@trueblade.com> added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue46511>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
