[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 09:04 PM 7/17/2007 -0400, Jim Jewett wrote:
>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"?
>
> > It allows the framework to bootstrap via successive
> > approximation.  Initially, the 'implies()' function is just a plain
>
>Would it work to make the original 'implies()' something other than an
>ordinary function?  I realize that you prefer being able to overload
>anything, but it seems that you *could* mark the ones you'll need to
>overload as part of bootstrapping.

Fair enough.  The design is still dependent on modifying "functions" 
in place, for some value of "function".  It just never occurred to me 
to introduce a *third* type of "function", besides the two already 
being dealt with (i.e., standard functions and generic 
functions).  Even *thinking* about the idea right now is like 
fingernails on a chalkboard to me, so I can see why it didn't occur to me.  :)


> > 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,
>
>What was missing from the __class__ attribute that you get from the
>super PEP fail?  Was it that you wanted access to the class while
>defining the class, before the method is ever called?

Correct; you need access to it before the method is called, since 
it's to add an overload to a generic function.


>Why can't an ordinary class decorator work?

It can; it's just noise.


>   Is it because you want
>the funky stuff to be conditional?  If so, is that really required?

I don't understand what you mean by "funky stuff" or "conditional", here.


>Or are you just objecting to the fact that metaclasses like this won't
>be the default?

The idea is to make it so that using generic functions doesn't 
require a bunch of extra bookkeeping, like adding metaclasses or 
decorators.  Metaclasses are particularly problematic in that mixing 
multiple metaclasses is not an activity for novice wizards.

That's why I don't use that approach in today's Python: I can safely 
wizard around the problem using pseudo-metaclasses, such that the 
user's metaclasses aren't touched.

Post-PEP 3115, however, it won't be an option any more, and you'll at 
least need a boilerplate decorator for it to work, and it'll silently 
break without it, giving absolutely no clue as to the problem.