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

Guido van Rossum guido at python.org
Wed Jul 18 00:53:24 CEST 2007

On 7/17/07, Phillip J. Eby <pje at telecommunity.com> 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 funccode 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/)

More information about the Python-3000 mailing list