On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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()'.
Why isn't it possible to mark these functions as explicitly overloadable? I'm not sure I understand what you mean by "bootstrapping". > 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. I guess I'll have to reserve judgment until the implementation exists. > (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.) Fair enough, though I suspect that IronPython might use certain optimizations that depend on func_code not being written. However, I certainly don't know enough about it. Anyone familiar with IronPython on this list care to comment? > >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. I'll defer it. It seems you are the only one who can write such a blessed meta-API, and I'm guessing that's the part of PEP 3124 that was never completed. > 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. I'm not sure anybody else cares enough to pre-empt you. > (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. I don't understand enough of your implementation to understand this requirement. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
