On 10/08/2021 4:25 am, Inada Naoki wrote:
On Tue, Aug 10, 2021 at 12:30 AM Eric V. Smith <e...@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,
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/BIM5KHILDVFVTIL6SUIY6TGGV5SHG5MQ/
Code of Conduct: http://python.org/psf/codeofconduct/
