Re: [Python-Dev] [PEP 576/580] Comparing PEP 576 and 580
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.
On Tue, Jul 31, 2018 at 6:14 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
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.
Please don't "straw man" discussion! I said "So PEP 576/580 are needed only when implementing callable object". I showed example "functools.partial or functools.lru_cache". Using FASTCALL for callable object, instead of tp_call is one of important goal of PEP 576 and 580. So, cleary, ordinal extension author should be able to understand and implement PEP 576 and 580.
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.
Surely, they should understand they must use CCALL_* flags instead of METH_* flags when implementing fast-callable object.
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
OK, I'm very drawn attention to that already.
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.
After spent several days to read PEP 580 and your implementation, I think I can implement it. I think it's not easy, but it's not impossible too. But I think we should admit the fact it's complicated than PEP 576. Although I don't think it's important than some benefits of PEP 580. NOTE that I didn't say it's a big problem. I just explained because you said "Can you be more concrete what you find complicated?" -- INADA Naoki <songofacandy@gmail.com>
On Tue, 31 Jul 2018 19:10:48 +0900 INADA Naoki <songofacandy@gmail.com> wrote:
I said "So PEP 576/580 are needed only when implementing callable object". I showed example "functools.partial or functools.lru_cache".
Using FASTCALL for callable object, instead of tp_call is one of important goal of PEP 576 and 580.
So, cleary, ordinal extension author should be able to understand and implement PEP 576 and 580.
No, Jeroen is right here. Ordinary extension authors do not need to understand and implement PEP 576 and 580. First, it's rare for extension types to be callable. Second, even if an extension type is callable, implementing PEP 576 or 580 is only useful if tp_call overhead is really important. In any case, just using tp_call will be as good as it was before. There is no regression, hence it is incorrect to say that we place an additional burden on the shoulders of extension authors. Yes, they can learn an additional PEP to increase tp_call performance; but they don't have to. Regards Antoine.
On Tue, Jul 31, 2018 at 7:27 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 31 Jul 2018 19:10:48 +0900 INADA Naoki <songofacandy@gmail.com> wrote:
I said "So PEP 576/580 are needed only when implementing callable object". I showed example "functools.partial or functools.lru_cache".
Using FASTCALL for callable object, instead of tp_call is one of important goal of PEP 576 and 580.
So, cleary, ordinal extension author should be able to understand and implement PEP 576 and 580.
No, Jeroen is right here. Ordinary extension authors do not need to understand and implement PEP 576 and 580.
Ah, my wording "ordinary" was wrong. But Jeroen was wrong too. He said "PEP 567 is also quite technical and not understandable by people who don't care about context variables." People can skip PEP 567 easily when they don't care about contextvars. On the other hand, *if we accept PEP 576 over PEP 580", C extension author will use it easily. So when comparing PEP 576 and 580, understandability for C extension author is not out of the scope. Note that I didn't claim how important it is. I just compare design of PEP 576 and PEP 580.
First, it's rare for extension types to be callable. Second, even if an extension type is callable, implementing PEP 576 or 580 is only useful if tp_call overhead is really important.
In any case, just using tp_call will be as good as it was before. There is no regression, hence it is incorrect to say that we place an additional burden on the shoulders of extension authors. Yes, they can learn an additional PEP to increase tp_call performance; but they don't have to.
I agree here. I have grepped tp_call usage and about to send mail explaining "Why FASTCALL for tp_call is not so important".
Regards
Antoine.
-- INADA Naoki <songofacandy@gmail.com>
On 2018-07-31 10:07, Jeroen Demeyer wrote:
On 2018-07-31 09:36, INADA Naoki wrote: [snip]
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
In this context, I'd define it as: "to stress" = to emphasize
participants (4)
-
Antoine Pitrou -
INADA Naoki -
Jeroen Demeyer -
MRAB