guido at python.org wrote: >> 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." Hmm - thought I'd seen it in various conversations online (as opposed to in the intro doc). Oh well ... > 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. Yeah - it's somewhat hairy at the moment. I'd like to simplify it further (it's better than it was ...). I came across a number of edge cases while implementing this that are dealt with. I definitely can't claim that I'm 100% sure that it does the right thing - haven't developed a full test suite for it yet (obviously) - this was something I've done in a couple of hours of "spare time" in the last couple of days. Mainly I wanted to get it out to the wider community to see if it was worthwhile pursuing further - and for other people to pick apart and criticise. > 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. Yeah - I meant to mention that (I did in the Cookbook). Yes, it uses sys.getframe() :( >> 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? No new keywords, doesn't impinge on the existing use of super. If it's implemented correctly (yet to be proven ;) existing uses of super and this can be used side-by-side, even in the same method. >> 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. That would be preferable. Although I do like having super be a property on the instance - it makes method calls on super consistent with everything else. I'd see this as a property on `object` in that case. Initially I wasn't passing self, but just finding it from the stack frame. I'd actually gone away from that approach though before I remembered that wouldn't work with psyco anyway :) >> 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)! The more I think about it, the more it should be that the default should be to throw exceptions. The rationale behind not throwing attribute exceptions is primarily mix-in classes - they can't know where in the MRO they're going to be - whether or not their attributes are going to interfere with other classes in the MRO. However, the more I think about it, the less examples I can think of where it would be a good thing to do. >> 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. :-) OK - super raises. super_raise goes away, and there is no equivalent for not raising. If people want that, they can subclass :) Thanks for the comments Guido. I think I'll let it soak for a while and see what other people think about it. Tim Delaney
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