[Python-Dev] C-level duck typing (original) (raw)

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Thu May 17 22:23:00 CEST 2012

On 05/17/2012 05:00 AM, Greg Ewing wrote:

On 17/05/12 12:17, Robert Bradshaw wrote:

This is exactly what was proposed to start this thread (with minimal collusion to avoid conflicts, specifically partitioning up a global ID space). Yes, but I think this part of the mechanism needs to be spelled out in more detail, perhaps in the form of a draft PEP. Then there will be something concrete to discuss in python-dev.

Well, we weren't 100% sure what is the best mechanism, so the point really was to solicit input, even if I got a bit argumentative along the way. Thanks to all of you!

If we in the end decide that we would like a propose the PEP, does anyone feel the odds are anything but very, very slim? I don't think I've heard a single positive word about the proposal so far except from Cython devs, so I'm reluctant to spend my own and your time on a fleshing out a full PEP for that reason.

In a PEP, the proposal would likely be an additional pointer to a table of "custom PyTypeObject extensions"; not a flag bit. The whole point would be to only do that once, and after that PyTypeObject would be infinitely extensible for custom purposes without collisions (even as a way of pre-testing PEPs about PyTypeObject in the wild before final approval!). Of course, a pointer more per type object is a bigger burden to push on others.

The thing is, you can just use a subtype of PyType_Type for this purpose (or any purpose), it's just my opinion that it's not be best solution here; it means many different libraries need a common dependency for this reason alone (or dynamically handshake on a base class at runtime). You could just stick that base class in CPython, which would be OK I guess but not great (using the type hierarchy is quite intrusive in general; you didn't subclass PyType_Type to stick in tp_as_buffer either).

Dag

More information about the Python-Dev mailing list