> > In other words, what does this new type_id thing > > actually *mean*? > > For the interpreter it means that it can assume the type > interface to be binary compatible to the "original" > type, e.g. by setting the flag to say PyDict_TypeID > the type assures that all PyDict_*() APIs will work > on the type -- basically the same thing as PyDict_Check() > does now except that the type object needn't be the same > anymore. I would be _very_ happy if this single type_id could somehow be replaced by an array, or a bitset. I have a lot of types in MacPython that are acceptable to the APIs of other types, a sort of poor-mans-inheritance scheme. For instance, all operating system calls that accept a MacOS WindowPtr will also happily accept a DialogPtr. Major magic is needed to get this to work reasonably in Python, and the Python user can still accidentally mess up the refcounting scheme and free things s/he isn't aware of. As the number of types in a given run of the interpreter appears to be limited (am I right here?) and type-identity-tests are valid within a single interpreter run only (am I right here?) an API like typeindex = Py_TypeToTypeIndex(typeobject); which would use a dictionary as storage for the mapping and generate the index numbers on the fly would do the trick. Call it once during module initalization and the Py_ISOBJECTCOMPATIBLEWITH(object, typeindex) macro would be a oneliner to test the bit in the set. A few hundred bits in the set would get us a long way, I guess. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
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