Hi Paul,

On Sun, May 1, 2022 at 3:47 PM Paul Bryan <pbryan@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