On 6/11/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > I'm very tempted to check in my patch even though the PEP isn't > > updated (it's been renamed from PEP 367 though). Any objections? > > Sorry - had to go visit family on the long weekend - only got back late last > night. > > My only objection is the special-casing of the 'super' name - specifically, > that it *won't* work if super is assigned to something else, and then called > with the no-arg version.
Well, what's the use case? I don't see that there would ever be a reason to alias super. So the use case seems to be only semantic purity. > But I'm happy to have the changes checked in, and > look at whether we can fix that without a performance penalty later. There's the rub -- it's easy to always add a reference to __class__ to every method, but that means that every method call slows down a tiny bit on account of passign the __class__ cell. Anyway, I'll check it in. > I'll update the PEP when I get the chance to reflect the new direction. > Ironically, it's now gone back more towards Calvin's original approach (and > my original self.super recipe). Working implementations talk. :-) > So - just clarifying the semantics for the PEP: > > 1. super() is a shortcut for super(__class__, first_arg). Yes. > Any reason we wouldn't just emit bytecode for the above if we detect a > no-arg call of super()? Ah - in case 'super' had been rebound. We could > continue to make 'super' a non-rebindable name. Believe me, modifying the byte code would be much harder. I don't like the idea of non-rebindable names that aren't keywords -- there are too many syntactic loopholes (e.g. someone found a way to bind __debug__ via an argument). > 2. __class__ can be called directly. But why should you? It's not there for calling, but for referencing (e.g. isinstance). Or maybe you meant "__class__ can be *used* directly." Yes, in that case. > __class__ will be available in any frame that uses either 'super' or > '__class__' (including inner functions of methods). Yeah, but that's only relevant to code digging around in the frame object. More usefully, the __class__ variable will be available in all function definitions that are lexically contained inside a class. > What if the function is *not* inside a class (lexically)? Will __class__ > exist, or will it be None? It will be undefined (i.e. give a NameError). super can still be used, but you must provide arguments as before. I should note that with the current class, while using __class__ in a nested function works, using super() in a nested function doesn't really work: while it gets the __class__ variable just fine, it gets the first argument of the nested function, which is most likely useless. Not that I can think of a use case for super() in a nested function anyway, but it should be noted. > > It is python.org/sf/1727209, use the latest (topmost) super2.diff > > patch. > > This would make the new and improved syntax super().foo(), which gets > > the class and object from the current frame, as the __class__ cell and > > the first argument, respectively. > > > > Neither __class__ nor super are keywords, but the compiler spots the > > use of 'super' as a free variable and makes sure the '__class__' is > > available in any frame where 'super' is used. > > > > Code is welcome to also use __class__ directly. It is set to the class > > before decoration (since this is the only way that I can figure out > > how to generate the code). > > > > The old syntax super(SomeClass, self) still works; also, > > super(__class__, self) is equivalent (assuming SomeClass is the > > nearest lexically containing class). > > Tim Delaney -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
