[Python-3000] pep 3124 plans (original) (raw)

Phillip J. Eby pje at telecommunity.com
Wed Jul 18 00:38:06 CEST 2007

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.

More information about the Python-3000 mailing list