Accessing parent objects

[Steven D'Aprano]

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