[Python-3000] pep 3124 plans

[Guido van Rossum]

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 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/)