[Python-Dev] C-level duck typing

[Dag Sverre Seljebotn]

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