On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > I've been working on improved super syntax for quite a while now - my > original approach was 'self.super' which used _getframe() and mro crawling > too. I hit on using bytecode hacking to instantiate a super object at the > start of the method to gain performance, which required storing the class in > co_consts, etc. It turns out that using a metaclass then makes this a lot > cleaner. > > > However, I seem to think that if the __this_class__ PEP goes through, > > your version can be simplified as well. No tricky stuffy things in > > cells would be needed, but we can just expand the super 'keyword' to > > __super__(__this_class__, self), which has been suggested at least > > once. It seems this would be much simpler to implement, and it also > > brings up a second point. > > > > Also, I like that the super object is created at the beginning of the > > function, which my proposal couldn't even do. It is more efficient if > > you have multiple super calls, and gets around a problem I completely > > missed: what happens if the instance name were rebound before the > > implicit lookup of the instance object at the time of the super call? > > You could expand it inline, but I think your second point is a strong > argument against it. Also, sticking the super instance into a cell means > that inner classes get access to it for free. Otherwise each inner class > would *also* need to instantiate a super instance, and __this_class__ (or > whatever it's called) would need to be in a cell for them to get access to > it instead. > > BTW, one of my test cases involves multiple super calls in the same method - > there is a *very* large performance improvement by instantiating it once.
Note that I would now advocate the creation of the super object at the beginning of function, and when I talk about expanding super to super(__this_class__, self) I do mean doing it at the beginning of the function, just like you are saying, so we're in agreement here. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
