Mailman 3 Re: [Python-Dev] PEP 575 (Unifying function/method classes) update - Python-Dev

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

older
Re: [Python-Dev] PEP 575 (Unifying...

Jeroen Demeyer

17 Jun 2018 17 Jun '18

2 a.m.

Hello, I have been working on a slightly different PEP to use a new type slot tp_ccalloffset instead the base_function base class. You can see the work in progress here: https://github.com/jdemeyer/PEP-ccall By creating a new protocol that each class can implement, there is a full decoupling between the features of a class and between the class hierarchy (such coupling was complained about during the PEP 575 discussion). So I got convinced that this is a better approach. It also has the advantage that changes can be made more gradually: this PEP changes nothing at all on the Python side, it only changes the CPython implementation. I still think that it would be a good idea to refactor the class hierarchy, but that's now an independent issue. Another advantage is that it's more general and easier for existing classes to use the protocol (PEP 575 on the other hand requires subclassing from base_function which may not be compatible with an existing class hierarchy). Jeroen.

Show replies by date

Nick Coghlan

17 Jun 17 Jun

4:55 a.m.

New subject: PEP 575 (Unifying function/method classes) update

On 17 June 2018 at 19:00, Jeroen Demeyer wrote:

...

Hello,

I have been working on a slightly different PEP to use a new type slot tp_ccalloffset instead the base_function base class. You can see the work in progress here:

https://github.com/jdemeyer/PEP-ccall

By creating a new protocol that each class can implement, there is a full decoupling between the features of a class and between the class hierarchy (such coupling was complained about during the PEP 575 discussion). So I got convinced that this is a better approach.

It also has the advantage that changes can be made more gradually: this PEP changes nothing at all on the Python side, it only changes the CPython implementation. I still think that it would be a good idea to refactor the class hierarchy, but that's now an independent issue.

Another advantage is that it's more general and easier for existing classes to use the protocol (PEP 575 on the other hand requires subclassing from base_function which may not be compatible with an existing class hierarchy).

Ah, this looks *very* nice :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Ronald Oussoren

5:50 a.m.

New subject: PEP 575 (Unifying function/method classes) update

...

On 17 Jun 2018, at 11:00, Jeroen Demeyer wrote:

Hello,

I have been working on a slightly different PEP to use a new type slot tp_ccalloffset instead the base_function base class. You can see the work in progress here:

https://github.com/jdemeyer/PEP-ccall

By creating a new protocol that each class can implement, there is a full decoupling between the features of a class and between the class hierarchy (such coupling was complained about during the PEP 575 discussion). So I got convinced that this is a better approach.

It also has the advantage that changes can be made more gradually: this PEP changes nothing at all on the Python side, it only changes the CPython implementation. I still think that it would be a good idea to refactor the class hierarchy, but that's now an independent issue.

Another advantage is that it's more general and easier for existing classes to use the protocol (PEP 575 on the other hand requires subclassing from base_function which may not be compatible with an existing class hierarchy).

This looks interesting. Why did you add a tp_ccalloffset slot to the type with the actual information in instances instead of storing the information in a slot? Ronald

Stefan Behnel

7:31 a.m.

New subject: PEP 575 (Unifying function/method classes) update

Ronald Oussoren schrieb am 17.06.2018 um 14:50:

...

Why did you add a tp_ccalloffset slot to the type with the actual information in instances instead of storing the information in a slot?

If the configuration of the callable was in the type, you would need a separate type for each kind of callable. That would quickly explode. Think of this as a generalised PyCFunction interface to arbitrary callables. There is a function pointer and some meta data, and both are specific to an instance. Also, there are usually only a limited number of callables around, so memory doesn't matter. (And memory usage would be a striking reason to have something in a type rather than an instance.) Stefan

Ronald Oussoren

10:52 a.m.

New subject: PEP 575 (Unifying function/method classes) update

...

On 17 Jun 2018, at 16:31, Stefan Behnel wrote:

Ronald Oussoren schrieb am 17.06.2018 um 14:50:

...
Why did you add a tp_ccalloffset slot to the type with the actual information in instances instead of storing the information in a slot?

If the configuration of the callable was in the type, you would need a separate type for each kind of callable. That would quickly explode. Think of this as a generalised PyCFunction interface to arbitrary callables. There is a function pointer and some meta data, and both are specific to an instance.

That’s true for PyCFunction, but not necessarily as a general replacement for the tp_call slot. I my code I’d basically use the same function pointer and metadata for all instances (that is, more like PyFunction than PyCFunction).

...

Also, there are usually only a limited number of callables around, so memory doesn't matter. (And memory usage would be a striking reason to have something in a type rather than an instance.)

I was mostly surprised that something that seems to be a replacement for tp_call stores the interesting information in instances instead of the type itself. Ronald

INADA Naoki

6:34 p.m.

New subject: PEP 575 (Unifying function/method classes) update

Hi Jeroen. It's interesting, but I think we need reference implementation to compare it's benefit with it's complexity. Victor had tried to add `tp_fastcall` slot, but he suspended his effort because it's benefit is not enough for it's complexity. https://bugs.python.org/issue29259 I think if your idea can reduce complexity of current special cases without any performance loss, it's nice. On the other hand, if your idea increase complexity, I doubt it's benefit. Increasing performance of all Python defined methods + most of builtin methods affects total application performance because it covers most calls. But calling callable object other than them are relatively rare. It may not affect real world performance of most applications. So, until I can compare it's complexity and benefits, I can say only "it's interesting." Regards, -- INADA Naoki

2136

Age (days ago)

2137

Last active (days ago)

List overview

Download

5 comments

5 participants

participants (5)

INADA Naoki
Jeroen Demeyer
Nick Coghlan
Ronald Oussoren
Stefan Behnel

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Jeroen Demeyer

Nick Coghlan

Ronald Oussoren

Stefan Behnel

Ronald Oussoren

INADA Naoki

tags

participants (5)