At 09:04 PM 7/17/2007 -0400, Jim Jewett wrote: >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"? > > > 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. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
