On 2018-07-31 09:36, INADA Naoki wrote:
I think PEP 580 is understandable only for people who tried to implement
method objects.
Is this really a problem? Do we expect that all Python developers can
understand all PEPs, especially on a technical subject like this?
To give a different example, I would say that PEP 567 is also quite
technical and not understandable by people who don't care about about
context variables.
If PEP 580 is accepted, we can make it very clear in the documentation
that this is only meant for implementing fast function/method classes
and that ordinary "extension writers" can safely skip that part. For
example, you write
They should learn PyCCallDef and CCALL_* flags in addition
to PyMethodDef and METH_*.
but that's not true: they can easily NOT learn those flags, just like
they do NOT need to learn about context variables if they don't need them.
I would like to stress that PEP 580 was designed for maximum
performance, both today and for future extensions (such as calling with
native C types).
I don't know what the word *stress* mean here. (Sorry, I'm not good at English
enough for such hard discussion).
But I want to see PoC of real benefit of PEP 580, as I said above.
"to stress" = to draw attention to, to make it clear that
So, PEP 580 is meant to keep all existing optimizations for
functions/methods. It can also be extended in the future (for example,
to support direct C calling) by just adding extra flags and structure
fields to PyCCallDef.
Hm, My point was providing easy and simple way to support FASTCALL
in callable object like functools.partial or functools.lru_cache.
That can be done easily with only PEP 580.
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/archive%40mail-archive.com
