On Wed, May 16, 2012 at 5:03 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > Dag wrote: > >> I'm not asking you to consider the details of all that. Just to allow some >> kind of high-performance extensibility of PyTypeObject, so that we can >> *stop* bothering python-dev with specific requirements from our parallel >> universe of nearly-all-Cython-and-Fortran-and-C++ codebases :-) > > > Maybe you should ask for a bit more than that. > > Tp_flags bits are a scarce resource, and they shouldn't > be handed out lightly to anyone who asks for one. Eventually > they're going to run out, and then something else will have to > be done to make further extensions of the type object possible. > > So maybe it's worth thinking about making a general mechanism > available for third parties to extend the type object without > them all needing to have their own tp_flags bits and without > needing to collude with each other to avoid conflicts. This is exactly what was proposed to start this thread (with minimal collusion to avoid conflicts, specifically partitioning up a global ID space). - Robert
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4