On 8/9/2021 11:25 PM, Inada Naoki wrote:
On Tue, Aug 10, 2021 at 12:30 AM Eric V. Smith <eric@trueblade.com> wrote:
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.
I don't think there is much difference.
PEP 563 is not default. But the intent is/was to make it the default. That was the case in 3.10, up until right before the release of beta 1. And PEP 563 is not the only source of stringified annotation. So Accepting PEP 649 doesn't mean "they'll all get their wish". We need to say "won't fix" anyway.
If 649 is accepted, there will be few places where stringified annotations will be needed. For example, forward references that are defined before __annotations__ is examined will not need to be specified as strings. From the PEP: "Actually, annotations would become much easier to use, as they would now also handle forward references.
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.
Currently, reference implementation of PEP 649 has been suspended. We need to revive it and measure performance/memory impact.
Agreed. -- Eric