[Python-Dev] Comparing PEP 576 and PEP 580

[Guido van Rossum]

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
> __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 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>