[Python-Dev] PEP 575 (Unifying function/method classes) update
Nick Coghlan
ncoghlan at gmail.com
Sun Jun 17 07:55:33 EDT 2018
More information about the Python-Dev mailing list
Sun Jun 17 07:55:33 EDT 2018
- Previous message (by thread): [Python-Dev] PEP 575 (Unifying function/method classes) update
- Next message (by thread): [Python-Dev] PEP 575 (Unifying function/method classes) update
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 17 June 2018 at 19:00, Jeroen Demeyer <J.Demeyer at ugent.be> 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 at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] PEP 575 (Unifying function/method classes) update
- Next message (by thread): [Python-Dev] PEP 575 (Unifying function/method classes) update
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list