On 6/7/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 02:31 PM 6/6/2007 -0700, Guido van Rossum wrote: > >I wonder if this may meet the needs for your PEP 3124? In > >particularly, earlier on, you wrote: > > > >>Btw, PEP 3124 needs a way to receive the same class object at more or > >>less the same moment, although in the form of a callback rather than > >>a cell assignment. Guido suggested I co-ordinate with you to design > >>a mechanism for this. > > > >Is this relevant at all? > > Well, it tells us more or less where the callback would need to > be. :) Although I think that __class__ should really point to the > *decorated* class, rather than the undecorated one. I have used > decorators before that had to re-create the class object, but can't > think of any use cases where I'd have wanted to use super() to refer > to the *un*decorated class.
That's a problem, because I wouldn't know where to save a reference to the cell until after the decorations are done. If you want to suggest a solution, please study the patch first to see the difficulty. > Btw, my thought on the keyword and __class__ thing is simply that the > plus of having a keyword (or other compiler support) is that we don't > have to have the cell variable cluttering up the frames for every > single method, whether it uses super or not. Oh, but the patch *does* have compiler support, and only creates the cell when it is needed, and only passes it into those methods that need it. > Thus, my inclination is either to require explicit use of __class__ > (so the compiler would know whether to include the free variable), or > to make super a keyword, so that in either case, only the functions > that use it must pay for the overhead. My patch uses an intermediate solution: it assumes you need __class__ whenever you use a variable named 'super'. Thus, if you (globally) rename super to supper and use supper but not super, it won't work without arguments (but it will still work if you pass it either __class__ or the actual class object); if you have an unrelated variable named super, things will work but the method will use the slightly slower call path used for cell variables. I believe IronPython uses a similar strategy to support locals() -- AFAIK it generates slower code that provides an accessible stack frame when it thinks you may be using a global named 'locals'. So again, globally renaming locals to something else won't work, but having an unrelated variable named 'locals' will work at a slight performance penalty. > (Currently, functions that use any cell variables are invoked more > slowly than ones without them; in 2.x at least there's a fast calling > path for code objects with CO_NOFREE, and this change would make it > useless for everything but top-level functions.) Not true, explained above. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
