By lack of a better name, I'm using the name PEP 576bis to refer to
https://github.com/markshannon/peps/blob/new-calling-convention/pep-9999.rst
(This is why this should get a PEP number soon, even if the PEP is not
completely done yet).
On 2019-03-27 14:50, Petr Viktorin wrote:
The pre-PEP is simpler then PEP 580, because it solves simpler issues.
I'll need to confirm that it won't paint us into a corner -- that
there's a way to address all the issues in PEP 579 in the future.
One potential issue is calling bound methods (in the duck typing sense)
when the LOAD_METHOD optimization is *not* used. This would happen for
example when storing a bound method object somewhere and then calling it
(possibly repeatedly). Perhaps that's not a very common thing and we
should just live with that. However, since __self__ is part of the PEP
580 protocol, it allows calling a bound method object without any
performance penalty compared to calling the underlying function directly.
Similarly, a follow-up of PEP 580 could allow zero-overhead calling of
static/class methods (I didn't put this in PEP 580 because it's already
too long).
As far as I can see, PEP 580 claims not much improvement in CPython,
but rather large improvements for extensions (Mistune with Cython).
Cython is indeed the main reason for PEP 580.
The pre-PEP has a complication around offsetting arguments by 1 to
allow bound methods forward calls cheaply.
I honestly don't understand what this "offset by one" means or why it's
useful. It should be better explained in the PEP.
The pre-PEP's "any third-party class implementing the new call
interface will not be usable as a base class" looks quite limiting.
I agree, this is pretty bad. However, I don't think that there is a need
for this limitation. PEP 580 solves this by only inheriting the
Py_TPFLAGS_HAVE_CCALL flag in specific cases. PEP 576bis could do
something similar.
Finally, I don't agree with this sentence from PEP 576bis: PEP 580 is
specifically targetted at function-like objects, and doesn't support
other callables like classes, partial functions, or proxies.
It's true that classes are not supported (and I wonder how PEP 576bis
deals with that, it would be good to explain that more explicitly) but
other callables are not a problem.
Jeroen.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
