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