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.