On 2018-07-06 23:12, Guido van Rossum wrote:
It's your PEP. And you seem to be struggling with something. But I can't
tell quite what it is you're struggling with.
To be perfectly honest (no hard feelings though!): what I'm struggling
with is getting feedback (either positive or negative) from core devs
about the actual PEP 580.
At the same time I assume you want your PEP accepted.
As I also said during the PEP 575 discussion, my real goal is to solve a
concrete problem, not to push my personal PEP. I still think that PEP
580 is the best solution but I welcome other suggestions.
And how do they feel about PEP 576? I'd like to see some actual debate
of the pros and cons of the details of PEP 576 vs. PEP 580.
I started this thread to do precisely that.
My opinion: PEP 580 has zero performance cost, while PEP 576 does make
performance for bound methods worse (there is no reference
implementation of the new PEP 576 yet, so that's hard to quantify for
now). PEP 580 is also more future-proof: it defines a new protocol which
can easily be extended in the future. PEP 576 just builds on PyMethodDef
which cannot be extended because of ABI compatibility (putting
__text_signature__ and __doc__ in the same C string is a good symptom of
that). This extensibility is important because I want PEP 580 to be the
first in a series of PEPs working out this new protocol. See PEP 579 for
the bigger picture.
One thing that might count against PEP 580 is that it defines a whole
new protocol, which could be seen as too complicated. However, it must
be this complicated because it is meant to generalize the current
behavior and optimizations of built-in functions and methods. There are
lots of little tricks currently in CPython that must be "ported" to the
new protocol.
OK, so is it your claim that the NumPy developers don't care about which
one of these PEPs is accepted or even whether one is accepted at all?
I don't know, I haven't contacted any NumPy devs yet, so that was just
my personal feeling. These PEPs are about optimizing callables and NumPy
isn't really about callables. I think that the audience for PEP 580 is
mostly compilers (Cython for sure but possibly also Pythran, numba,
cppyy, ...). Also certain C classes like functools.lru_cache could
benefit from it.
Yet earlier in
*this* thread you seemed to claim that PEP 580 requires changes ro
FASTCALL.
I don't know what you mean with that. But maybe it's also confusing
because "FASTCALL" can mean different things: it can refer to a
PyMethodDef (used by builtin_function_or_method and method_descriptor)
with the METH_FASTCALL flag set. It can also refer to a more general API
like _PyCFunction_FastCallKeywords, which supports METH_FASTCALL but
also other calling conventions like METH_VARARGS.
I don't think that METH_FASTCALL should be changed (and PEP 580 isn't
really about that at all). For the latter, I'm suggesting some API
changes but nothing fundamental: mainly replacing the 5 existing private
functions _PyCFunction_FastCallKeywords, _PyCFunction_FastCallDict,
_PyMethodDescr_FastCallKeywords, _PyMethodDef_RawFastCallKeywords,
_PyMethodDef_RawFastCallDict by 1 public function PyCCall_FASTCALL.
Hopefully this clears some things up,
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
