Thanks, I will wait until there is a conclusion to the debate. On Fri, Jul 6, 2018 at 4:05 PM Jeroen Demeyer <j.deme...@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@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)
_______________________________________________ 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
