> The current `super` implementation was always (as I understood it) meant > to be an interim solution until a better syntax could be determined. Fair enough, although I doubt that I said it that way -- I believe I simply said something like "and here's how you can do 'super' using descriptors." > I've submitted a recipe to the Cookbook for an improved super/autosuper > which allows using syntax like: > > class A (autosuper): > > def __init__ (self, a, b): > print 'A.__init__' > print a, b > self.super(a, b) > > def test (self, a, b): > print 'A.test' > print a, b > self.super(a, b) > > class B (A): > > def __init__ (self): > print 'B.__init__' > self.super(1, 2) > self.super.test(3, 4) > > B() > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286195 I haven't downloaded that to test it thoroughly, and the code is way too hairy to understand easily, so I'm just asking here: how sure are you that it always does the right thing? There are some seriously nasty edge cases for super, including making sure you always follow the MRO correctly. > It's currently got some fairly serious inefficiencies in it, but it > shows that it is viable to produce a simpler `super` that doesn't > require hardcoding the class. Just as important is not having to hardcode the method (and you support that as well). But that requires using sys._getframe() or other nastiness to find the method name. > It's also backwards-compatible. Sure, although I'm not sure I understand in what sense. I guess you mean it doesn't define new keywords? > Would there be any interest in doing further work on this with the > aim of getting it into the core? Hmm... I'd rather work on a syntactic approach so the compiler can generate the appropriate call to the current super built-in. > BTW, I've made a couple of design choices which I'm not sure about. > Specifically, I've made `self.super` *not* throw an AttributeError when > no base class has the attribute - this simplifies dealing with mixin > classes (since you can just blindly put the self.super call in). This is clearly wrong. If your code doesn't even know whether there's a base class method or not, I doubt that you understand your base class well enough to be able to extend it. Introducing a new method should be clearly different from overriding an existing one (conceptually)! > I've included a second property `super_raise` for when you want the > exception. Most of my usage works better without the exception > (since everything resolves back to object, and it doesn't have many > methods ...). But I'd like other people's opinion on which is > preferable. You've got mine. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4