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

Phillip J. Eby pje at telecommunity.com
Wed Jul 18 04:03:20 CEST 2007

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.

More information about the Python-3000 mailing list