> > But the real issue is what Moshe himself already brings up: contains > > should have a slot in the type struct, so extension types can also > > define this. > > > > Moshe, do you feel like doing this right? > > Yes, but not in the near future. Wouldn't adding a new slot break old > extension types? I'm a bit ignorant on the subject There are some spare slots in PyTypeObject: /* More spares */ long tp_xxx5; long tp_xxx6; long tp_xxx7; long tp_xxx8; These can be used for binary compatibility; old extensions will simply not have the new feature. There's also a more sophisticated feature, implemented through tp_flags, which can indicate that an extension is aware of a particular feature. These comments in object.h may explain this: /* Type flags (tp_flags) These flags are used to extend the type structure in a backwards-compatible fashion. Extensions can use the flags to indicate (and test) when a given type structure contains a new feature. The Python core will use these when introducing new functionality between major revisions (to avoid mid-version changes in the PYTHON_API_VERSION). Arbitration of the flag bit positions will need to be coordinated among all extension writers who publically release their extensions (this will be fewer than you might expect!).. Python 1.5.2 introduced the bf_getcharbuffer slot into PyBufferProcs. Type definitions should use Py_TPFLAGS_DEFAULT for their tp_flags value. Code can use PyType_HasFeature(type_ob, flag_value) to test whether the given type object has a specified feature. */ --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