> There is one second thought about this, but I'm not sure > whether it is allowed to do so: > > Assuming that I *would* simply do add a field to PyMethodDef, > and take care that all types coming from foreign binaries > don't have that special type bit set, could I not simply create > a new method table and replace it for that external type > by just changing its method table pointer? Probably. I just realize that there are two uses of PyMethodDef. One is the "classic", where the type's tp_getattr[o] implementation calls Py_FindMethod. The other is the new style where the PyMethodDef array is in tp_methods, and is scanned once by PyType_Ready. 3rd party modules that have been around for a while are likely to use Py_FindMethod. With Py_FindMethod you don't have a convenient way to store the pointer to the converted table, so it may be better to simply check your bit in the first array element and then cast to a PyMethodDef or a PyMethodDefEx array based on what the bit says (you can safely assume that all elements of an array are the same size :-). > I think traversing method tables is always an action that > the core dll does. Or do I have to fear that an extension > does special things to method tables at runtime? I wouldn't lose sleep over that. > If that approach is trustworthy, I also could drop > the request for these 8 bits. Sure. Ah, a bit in the type would work just as well, and Py_FindMethod *does* have access to the type. --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