> > I wish I had time to explain this, but I don't. For now, you'll have > > to read how types are initialized in typeobject.c -- maybe there's a > > way, maybe there isn't. > > > > > Any tips about the route to take? > > > > It can be done easily dynamically. > > I'm still struggling with this. How can it be done dynamically? > > My idea would be to realloc() the object after creation, adding > a few bytes at the end. The problem is that I don't know how to > find out about the object size without knowledge about the internals. > The formula given in PEP 253 > type->tp_basicsize + nitems * type->tp_itemsize > seems not to be valid any more (at least with CYCLE GC). I have thought about this a little more and come to the conclusion that you cannot define a metaclass that creates type objects that have more C slots than the standard type object lay-out. It would be the same as trying to add a C slot to the instances of a string subtype: there's variable-length data at the end, and you cannot place anything *before* that variable-length data because all the C code that works with the base type knows where the variable length data start; you cannot place anything *after* that variable-lenth data because there's no way to address it from C. The only way around this would be to duplicate *all* the code of type_new(), which I don't recommend because it will probably have to be changed for each Python version (even for bugfix releases). A better solution is to store additional information in the __dict__. --Guido van Rossum (home page: http://www.python.org/~guido/)
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