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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
