On 8/9/21 8:25 PM, Inada Naoki wrote:
Currently, reference implementation of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.
Perhaps this sounds strange--but I don't actually agree.
PEP 563 was proposed to solve a forward-references problem for the
typing community. If you read the PEP, you'll note it contains no
discussion about its impact on CPU performance or memory consumption.
The performance of its prototype was fine, and in any case, the
important thing was to solve the problem in the language.
I think PEP 649 should be considered in the same way. In my opinion,
the important thing is to figure out what semantics we want for the
language. Once we figure out what semantics we want, we should
implement them, and only /then/ should we start worrying about
performance. Fretting about performance at this point is premature and
a distraction.
I assert PEP 649's performance and memory use is already acceptable,
particularly for a prototype. And I'm confident that if PEP 649 is
accepted, the core dev community will find endless ways to optimize the
implementation.
As far as I remember, the reference implementation created a function
object for each methods.
First, it's only for methods with annotations. Second, it only stores a
code object on the annotated function; the co_annotations function is
lazily created. The exception to this is when co_annotations needs a
closure; in that case, it currently creates and binds the co_annotation
function non-lazily. Obviously this could be done lazily too, I didn't
bother for the prototype.
//arry/
_______________________________________________
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/R6QP2SQCJ3KBKUFXXA5HZW7GY2XAJQRD/
Code of Conduct: http://python.org/psf/codeofconduct/
