[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
>I have one remaining question for Phillip: why is your design
>"absolutely dependent on being able to modify functions in-place"?
>That dependency would appear to make it harder to port the design to
>other Python implementations whose function objects don't behave the
>same way. I can see it as a philosophical desirable feature; but I
>don't understand the technical need for it.

It allows the framework to bootstrap via successive 
approximation.  Initially, the 'implies()' function is just a plain 
function, and then it later becomes a generic function.  (And of 
course it gets called in between those two points.)  The same happens 
for 'disjuncts()' and 'overrides()'.

Is it potentially possible that there's another way to do it, given 
enough restrictions on how other code uses the exported API and 
enough hackery during bootstrapping?  Perhaps, but I don't know of 
such a way.  The modification-in-place approach allows me to just 
write the functions and not care precisely when they become 
generic.  I still have to do a little extra special bootstrapping for 
implies(), because of its self-referential nature, but everything 
else I can pretty much blaze right on through with.

(By the way, AFAIK IronPython, Jython (2.2), and PyPy all support 
writable func_code attributes, so it's evidently practical to do so 
for reasonably dynamic Python implementations.)


>Regarding the fate of PEP 3124, perhaps the right thing is to reject
>the PEP, and be content with having GFs as a third party add-on?

I've also suggested simply deferring it.  I'd still like to see a 
"blessed" meta-API for generic functions at some point.

Also, as I've said, there's nothing stopping anybody from stepping up 
with a less-ambitious and less-controversial implementation based on 
your preferred API.  I just won't be able to get to it myself for a 
month or so.

(Also, nothing stops such a less-ambitious approach from being later 
folded into something more like my approach, with full extensibility 
and all the bells and whistles.  In the worst case, one could always 
make a backward compatibility layer that fakes the more limited API 
using the more general one, as long as the lesser API is a strict 
subset of the greater -- and I believe it is.)


>There seems to be nothing particular about Python 3.0 as the point of
>introduction of GFs anyway -- they can be introduced just as easily in
>3.1 or 4.0 or any time later (or earlier, as Phillip's existing
>implementation show).

Well, the one thing that might still be relevant is the "overloading 
inside classes" rule.  That's the only bit that has any effect on 
Python 3.0 semantics vis-a-vis metaclasses, class decorators, etc.

The way things currently stand for 3.0, I actually *won't* be able to 
make a GF implementation that handles the "first argument should be 
of the containing class" rule without users having an explicit 
metaclass or class decorator that supports it.

In 2.x, I take advantage of the ability of code run inside a class 
suite to change the enclosing class' __metaclass__; in 3.0, you can't 
do this anymore since the __metaclass__ doesn't come from the class 
suite, and there isn't a replacement hook.