[Python-Dev] PEP 575 (Unifying function/method classes) update (original) (raw)
Ronald Oussoren ronaldoussoren at mac.com
Sun Jun 17 08:50:04 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 Jun 2018, at 11: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 tpccalloffset instead the basefunction 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 basefunction 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
- 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 ]