
On 10/08/2021 4:25 am, 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. 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.
My only comment concerned performance. I won't claim that the cost of PEP 649 will be zero, but it won't be significantly more than PEP 563 if annotations are unused. The cost of unmarshalling a code object will be greater than a string, but it won't be significant. Not only that, but we are actively looking to reduce startup in 3.11 which will reduce the overhead further. If annotations *are* used, then PEP 649 should be cheaper as it relies on the interpreter to do the evaluation in an efficient fashion. For users of dataclasses and Pydantic, I expect PEP 649 to outperform PEP 563.
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.
No function object is created under normal circumstances. __annotations__ is a property that calls the underlying __co_annotations__ property, which lazily creates a callable. I'll leave it to Larry to explain why __co_annotations__ isn't just a code object.
It means doubles function objects. It has major impact to memory usage, startup time, and GC time.
Only if __annotations__ are widely used, in which case PEP 563 is probably worse. Cheers, Mark.
There was an idea to avoid creating function objects for most cases. But it was not implemented.
Regards,