[Raymond] > > Guido is basically okay with the idea but thought I should check here > > first to see if anyone has any profound thoughts about unexpected > > implications or perhaps a better way. > [Michael Hudson] > Not really, this sounds pretty reasonable. Two thoughts: > > 1) Man, I hate C. Not news :-) It certainly makes you appreciate coding in Python :-) > 2) /Might/ it be possible to do this automatically for a few slots? > (i.e. are there any slots that have parameter lists that let the > the tp_foo implementation function just be wrapped up in a METH_O > or METH_NOARGS PyCFunction?). Bit of a hack, mind. This idea may be doable but it certainly isn't minimally invasive ;-) One approach would entail: * expand the structure for PyCFunction to include the slot pointer * create an alternate constructor for PyCFunction that loads the slot pointer, flags, doc string, and a pointer to the wrapper function. * change all the wrapper functions match the signature of the function they are calling * have the wrapper functions become responsible for looking up the slot pointer from the expanded PyCFunction structure * eliminate the wrapper object type The bad news is that this would take a weekend of effort and I'm not 100% sure it would work. If it did, it would be slightly slower that what I've proposed. This would decrease the cohesion of PyCFunction and impose additional coupling to the wrapped functions (though the latter is minimized somewhat by the alternate constructor which hides the details of where wrapper information came from). The good news is that it eliminates an entire type. Also, it is much more general that what I proposed. And, any future enhancements to the calling mechanism would have once less case to worry about. Netting the good with the bad, it comes out close. Unfortunately, it could eat-up a whole weekend to find out whether simplification and generality of it outweigh the little hacks, the large number of lines that would change, and the relatively high risk of introducing some subtle bugs. [Phillip J. Eby] > What happens in subclasses? Nothing special. The behavior persists unless overridden by a subclass method. Raymond Hettinger
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