I'd like to revive the discussion of PEP 649
[https://www.python.org/dev/peps/pep-0649/] that started shortly before
development of 3.10 features was closed. This is Larry's PEP to defer
evaluation of __annotations__ until it's actually accessed. During the
discussion the decision was made to back out the change that made "from
__future__ import annotations" (PEP 563
[https://www.python.org/dev/peps/pep-0563/]) the default behavior for 3.10.
My understanding is that PEP 649 is currently in front of the SC.
Correct.
But do
we need to have any additional discussion here?
I think it's worth discussing whether PEP 649 is the solution we want to see as the solution to this problem or not?
My recollection is that
we backed out the PEP 563 change because we didn't feel we had enough
time to come to a good decision one way or the other before 3.10.
Correct.
Personally, I'd like to see PEP 649 accepted. There are a number of
issues on bpo where people expect dataclass's field.type to be an actual
Python object representing a type, and not a string. This field is
copied directly from __annotations__. If we stick with PEP 563's string
annotations, I'll probably just close these issues as "won't fix", and
tell the caller they need to convert the strings to Python objects
themselves. If 649 is accepted, then they'll all get their wish, and in
addition I can remove some ugly logic from dataclasses.
Do we need to do anything here to move forward on this issue? I've
chatted with Larry and Mark Shannon, who have some additional thoughts
and I'm sure will chime in.
I think the question is whether we have general consensus around PEP 649?
-Brett
--
Eric
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/2MEOWHCVDLPABOBLYUGRXVOOOBYOLLU6/
Code of Conduct: http://python.org/psf/codeofconduct/