Accessing parent objects

[Rick Johnson]

On Saturday, March 24, 2018 at 11:31:38 PM UTC-5, Steven D'Aprano wrote:
> On Sat, 24 Mar 2018 20:08:47 -0700, Rick Johnson wrote:
[...]
> >
> > 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."
> >
> > Thus, i chose to abandon super altogether.
> 
> Baby, bathwater.

I'm afraid quote-mining won't help your argument. There is
nothing wrong about choosing consistency over inconsistency.
But what i find more troubling, is that you seem to
misunderstand the significance of Emerson's famous "foolish
consistency" quip; which became the spearhead of a more
broad treatise warning us of the dangers inherent in
orthodoxy. And while Emerson's warning can be applied widely
to personal philosophy, the warning applies only very
narrowly to the realm of programming; which forces us to use
certain structures and forms that are beyond our control.
For example, a Python programmer can no more define a class
with the keyword "object" than he/she could define a
function with the keyword "function", or import a module
from a package using colons, exclamation-marks and
ampersands:

    >>> object Foo():
    	
    SyntaxError: invalid syntax

    >>> function bar():
    	
    SyntaxError: invalid syntax

    >>> from foolish:consistency! import &platitudes
    SyntaxError: invalid syntax
    
Python dictates that we follow certain well-defined rules.
But following these rules is no evidence of a foolish
consistency, much less an orthodoxy. For example, here is a
quote from PEP8, which underscores my position and explains
the significance of the "foolish consistency" quip:

    """
    A Foolish Consistency is the Hobgoblin of Little Minds
    ---------------------------------------------------------
    
    One of Guido's key insights is that code is read much more
    often than it is written. The guidelines provided here are
    intended to improve the readability of code and make it
    consistent across the wide spectrum of Python code. As PEP
    20 says, "Readability counts".
    
    A style guide is about consistency. Consistency with this
    style guide is important. Consistency within a project is
    more important. Consistency within one module or function is
    the most important.
    """
    
Okay. So if there is one lesson to take away from this
quote, the lesson is that readability is important, and
futhermore, that readability is highly dependant on
maintaining a consistent presentation/form of source code
(aka: consistency).

Thus, a sporadic implementation of super() in my source code
would violate the spirit of PEP8. And although i freely
admit that super() is technically the correct way to go,
it's not my fault that Python2's Tkinter is incompatible
with super, and so my decision to maintain consistency --
and thus readability -- perfectly aligns with the standards
of PEP8. Thus, it is Pythonic.

So yes, I chose the path of _consistency_, for which the
natural side effect is _readability_, and Steven, there is
absolutely nothing "foolish" about that!

> > 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?

Yes. But there's more "method to my madness" than meets your
eye. And although you don't know it yet, you're about to
provide the justification for my delay using your very own
words 

(so stay tuned, this is going to be fun!)

(well, perhaps not for you!)

> 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.
> 
> [snip: link]
> 
> Python 4 is not going to be a massively compatibility-
> breaking change like Python 3 was,

Exactly! Thus the reason i am avoiding Python3 like the
plague.

> and version 4 is likely about 5 or 6 years away. 

That's fine. I'm in no hurry.

> Some hypothetical "Python 4000", or more likely "5000", is
> at least a decade away, if it ever occurs again. (Which it
> probably won't.)

Which is it? "5 or 6 years" or "a decade"? Make up your
mind, would ya?

Even if an official version number "4" is not offered, and
Python3 is the last version of Python, at some point the
churn of Python3 will slow, and thus, in sprit it will
become the stable equivalent of Python4. So sorry to
disappoint you Steven, but either way, i win. O:-)

> In the meantime, Python 2.7 will fall out of extended
> support in less than two years.

What? Me worry? o_O

> For comparison, here's how Python's super works in 3.x:
>
> [...]
> 
> Ruby's super reduces typing, at the cost of needing more
> magic and less flexibility:
> 
> [snip: link]
> 
> 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,

Ruby is fundamentally _opposed_ to the idea of multiple
inheritance  -- as MI is rife with issues (technical,
practical, and intuitive in nature) and thus, not a wise
solution -- but you would have known that Steven, had you
actually read the official tutorial and had any _real_
experience with the language. Mores the pity!

> which is exactly when super() is most important.

Your assertion presupposes that MI is the only way to solve
the problem that MI proposes to solve. And it is not only
the Ruby folks who find MI to be woefully inadequate. The
impracticality of MI has been the subject of much debate.

> 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;

Which is merely a natural result of Ruby's function/method
call syntax. Not allowing a parenthesis-free super call
would not only be inconsistent, it would be foolishly
inconsistent.

> - with parentheses, you have to manually pass the arguments
>   you want to pass.

Well, duh! Welcome to Ruby land. And please, keep your arms
and legs in the vehicle at all times, and leave your
preconceived notions where they belong -- where the sun
don't shine.

> So there's weird magic going on where `super` and `super()`
> both call the method but with different arguments. Ewww.

It's only weird because you are judging through a Python
lens. Ruby is not Python. And Python is not Ruby.

> But yes, Ruby's super requires less typing for the common
> case of "call the parent's method and pass the exact same
> arguments".

Finally a concession! Gheez, and my only regret is that i
had to pull-on my hip waders to get here.