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. But I'm happy to have the changes checked in, and look at whether we can fix that without a performance penalty later. 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). So - just clarifying the semantics for the PEP: 1. super() is a shortcut for super(__class__, first_arg). 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. 2. __class__ can be called directly. __class__ will be available in any frame that uses either 'super' or '__class__' (including inner functions of methods). What if the function is *not* inside a class (lexically)? Will __class__ exist, or will it be None? > 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 _______________________________________________ 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
