[Python-Dev] Comparing PEP 576 and PEP 580 (original) (raw)

Guido van Rossum guido at python.org
Fri Jul 6 19:10:36 EDT 2018

Thanks, I will wait until there is a conclusion to the debate.

On Fri, Jul 6, 2018 at 4:05 PM Jeroen Demeyer <J.Demeyer at ugent.be> wrote:

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 textsignature 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.lrucache 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 builtinfunctionormethod and methoddescriptor) with the METHFASTCALL flag set. It can also refer to a more general API like PyCFunctionFastCallKeywords, which supports METHFASTCALL but also other calling conventions like METHVARARGS. I don't think that METHFASTCALL 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 PyCFunctionFastCallKeywords, PyCFunctionFastCallDict, PyMethodDescrFastCallKeywords, PyMethodDefRawFastCallKeywords, PyMethodDefRawFastCallDict by 1 public function PyCCallFASTCALL.

Hopefully this clears some things up, Jeroen.

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180706/276f6bf4/attachment-0001.html>

More information about the Python-Dev mailing list