[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Comparing PEP 576 and PEP 580

On 07/07/18 00:02, Jeroen Demeyer 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 
There is a minimal implementation and has been for a while.
There is a link at the bottom of the PEP.
Why do you claim it will make the performance of bound methods worse?
You provide no evidence of that claim.

> 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.
PEP 576 adds a new calling convention which can be used by *any* object.
Seems quite extensible to me.

> 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
> 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/mark%40hotpy.org