[Python-Dev] FW: METH_COEXIST

[Raymond Hettinger]

[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