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. 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.
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. As far as I remember, the reference implementation created a function object for each methods. It means doubles function objects. It has major impact to memory usage, startup time, and GC time. There was an idea to avoid creating function objects for most cases. But it was not implemented. Regards, -- Inada Naoki <songofacandy@gmail.com>