Thanks, Carl and Larry for the explanations. On Sun, 2022-05-01 at 16:13 -0600, Carl Meyer wrote: > Hi Paul, > > On Sun, May 1, 2022 at 3:47 PM Paul Bryan <pbr...@anode.ca> wrote: > > > > Can someone state what's currently unpalatable about 649? It seemed > > to address the forward-referencing issues, certainly all of the > > cases I was expecting to encounter. > > Broadly speaking I think there are 3-4 issues to resolve as part of > moving forward with PEP 649: > > 1) Class decorators (the most relevant being @dataclass) that need to > inspect something about annotations, and because they run right after > class definition, the laziness of PEP 649 is not sufficient to allow > forward references to work. Roughly in a similar boat are `if > TYPE_CHECKING` use cases where annotations reference names that > aren't > ever imported. > > 2) "Documentation" use cases (e.g. built-in "help()") that really > prefer access to the original text of the annotation, not the repr() > of the fully-evaluated object -- this is especially relevant if the > annotation text is a nice short meaningful type alias name, and the > actual value is some massive unreadable Union type. > > 3) Ensuring that we don't regress import performance too much. > > 4) A solid migration path from the status quo (where many people have > already started adopting PEP 563) to the best future end state. > Particularly for libraries that want to support the full range of > supported Python versions. > > Issues (1) and (2) can be resolved under PEP 649 by providing a way > to > run the __co_annotations__ function without erroring on > not-yet-defined names, I think we have agreement on a plan there. > Performance of the latest PEP 649 reference implementation does not > look too bad relative to PEP 563 in my experiments, so I think this > is > not an issue -- there are ideas for how we could reduce the overhead > even further. The migration path is maybe the most difficult issue -- > specifically how to weigh "medium-term migration pain" (which under > some proposals might last for years) vs "best long-term end state." > Still working on reaching consensus there, but we have options to > choose from. Expect a more thorough proposal (probably in the form of > an update to PEP 649?) sometime after PyCon. > > Carl
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M3ZPMSHFZBG4MQ4X55DPNAPA7J4T2ZXM/ Code of Conduct: http://python.org/psf/codeofconduct/
