Accessing parent objects
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Sun Mar 25 00:29:08 EDT 2018
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
More information about the Python-list
mailing list