> > The other is the new style where the PyMethodDef > > array is in tp_methods, and is scanned once by PyType_Ready. > > Right, again. Now, under the hopeful assumption that every > sensible extension module that has some types to publish also > does this through its module dictionary, I would have the > opportunity to cause PyType_Ready being called early enough > to modify the method table, before any of its methods is used > at all. Dangerous assumption! It's not inconceivable that a class would instantiate some of its own classes as part of its module initialization. > > 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 :-). > > Hee hee, yeah. Of course, if there isn't a reliable way to > intercept method table access before the first Py_FindMethod > call, I could of course modify Py_FindMethod. For instance, > a modified, new-style method table might be required to always > start with a dummy entry, where the flags word is completely > -1, to signal having been converted to new-style. Why so drastic? You could just set a reserved bit.f > ... > > >>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. > > You think of the definition in methodobject.c, as it is > > """ > /* Find a method in a single method list */ > > PyObject * > Py_FindMethod(PyMethodDef *methods, PyObject *self, char *name) > """ > > , assuming that self always is not NULL, but representing a valid > object with a type, and this type is already referring to the > methods table? Right. There is already code that uses self->ob_type in Py_FindMethodInChain(), which is called by Py_FindMethod(). > Except for module objects, this seems to be right. I've run > Python against a lot of Python modules, but none seems > to call Py_FindMethod with a self parameter of NULL. I don't think it would be safe to do so. > If that is true, then I can patch a small couple of > C functions to check for the new bit, and if it's not > there, re-create the method table in place. > This is music to me ears. But... > > Well, there is a drawback: > I *do* need two bits, and I hope you will allow me to add this > second bit, as well. > > The one, first bit, tells me if the source has been compiled > with Stackless and its extension stuff. Nullo problemo. > I can then in-place modify the method table in a compatible > way, or leave it as it is, bny default. > But then, this isn't sufficient to set this bit then, like an > "everything is fine, now" relief. This is so, since this is *still* > an old module, and while its type's method tables have been > patched, the type is still not augmented by new slots, like > the new tp_call_nr slots (and maybe a bazillion to come, soon). > The drawback is, that I cannot simply replace the whole type > object, since type objects are not represented as object > pointers (like they are now, most of the time, in the dynamic > heaptype case), but they are constant struct addresses, where > the old C module might be referring to. > > So, what I think to need is no longer 9 bits, but two of them: > One that says "everything great from the beginning", and another > one that says "well, ok so far, but this is still an old object". > > I do think this is the complete story, now. > Instead of requiring nine bits, I'm asking for two. > But this is just *your options; I also can live with one bit, > but then I have to add a special, invalid method table entry > that just serves for this purpose. > In order to keep my souce code hack to the minimum, I'd really > like to ask for the two bits in the typeobject flags. OK, two bits you shall have. Don't spend them all at once! > Thanks so much for being so supportive -- chris Anything to keep ctual stackless support out of the core. :-) --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