On Sat, 24 Mar 2018 20:08:47 -0700, Rick Johnson wrote: > After sending my response to Steven, i began to ponder why i had > rejected Python's super (because, after all, it's been a few years now, > and frankly, i forgot), and i realized it was more a matter of > consistency. > > You see, Tkinter (the Py2 version) uses old style classes
That would be an inconvenience and annoyance. > (though i beleve that design flaw has been rectified in Py3), Indeed. Not so much a design flaw as such, just an annoyance due to historical reasons. What was a reasonable design back in 1994 didn't age well, but backwards-compatibility prevented fixing it until Python 3. [...] > the inconsistency of using super > _outside_ of Tkinter code whilst simultaneously using explicit > inheritance _inside_ Tkinter code was quite frankly, disturbing to me. “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.” https://en.wikiquote.org/wiki/Consistency > Thus, i chose to abandon super altogether. Baby, bathwater. > But when i make the switch to Python4000, i will probably adopt super at > that time, along with all the other fully matured goodies. So, having avoided the first unstable compatibility-breaking version, Python 3000, you're going to wait until the next hypothetical unstable, compatibility-breaking version before upgrading? Python 3 is now six point releases in (and very soon to have a seventh, 3.7 being in beta as we speak). It is stable, feature-rich, and a joy to work in. As well as a heap of great new features, there have been a metric tonne of performance improvements, making Python 3 faster than 2.7 for many tasks, e.g. https://mail.python.org/pipermail/python-dev/2017-July/148641.html Python 4 is not going to be a massively compatibility-breaking change like Python 3 was, and version 4 is likely about 5 or 6 years away. Some hypothetical "Python 4000", or more likely "5000", is at least a decade away, if it ever occurs again. (Which it probably won't.) In the meantime, Python 2.7 will fall out of extended support in less than two years. Time to get with the programme, Rick, and stop living in the past :-) > In light of this revelation, I still don't believe Python's super() > function is as intuitive, as say, Ruby's super statement is, but it is > the correct way to do things, nonetheless. For comparison, here's how Python's super works in 3.x: def method(self, spam, eggs, cheese): result = super().method(spam, eggs, cheese) In other words, you must explicitly state the method you are calling, and give the arguments you want to pass on. Of course you can manipulate or remove those arguments as needed, or add new ones: result = super().method(spam+1, eggs*2, keyword='aardvark') because it's just an ordinary method call. In fact, once you have got the super proxy, you can even call another method: result = super().something_different(arg) if you need to for some reason. Remember: super() in Python gives you a proxy to the parent classes themselves, not just the parent's method of the same name. Ruby's super reduces typing, at the cost of needing more magic and less flexibility: http://rubylearning.com/satishtalim/ruby_overriding_methods.html Ruby's super doesn't return a superclass proxy, it automagically calls the same method as the current method, so you can't delegate to a different method if required. In addition, Ruby doesn't support multiple inheritance, which is exactly when super() is most important. Ruby's super calls the method in two ways: - with no arguments, using the parenthesis-free syntax, Ruby automagically forwards the same arguments to the (single) parent; - with parentheses, you have to manually pass the arguments you want to pass. So there's weird magic going on where `super` and `super()` both call the method but with different arguments. Ewww. But yes, Ruby's super requires less typing for the common case of "call the parent's method and pass the exact same arguments". > So yeah, i'll have to cross that rickety old bridge I see what you did there. -- Steve -- https://mail.python.org/mailman/listinfo/python-list