Accessing parent objects

[Rick Johnson]

On Sunday, March 25, 2018 at 9:52:30 AM UTC-5, Steven D'Aprano wrote:
> On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
[...]
> But refusing to use super in modern, new-style classes that
> don't have anything to do with tkinter is precisely the
> sort of *foolish* consistency that Emerson was warning
> about.

Oh, obviously! Because in the late 1800's, Python's new
style vs old style classes, and the blinkered state of
Tkinter, was the subject of intense debate in philosophical
circles. Yes-sir-eee!

> Your position is equivalent to noting that tuples don't
> have a sort method, and so "for the sake of consistency"
> refusing to use list.sort() even when you *know* you have a
> list.

That's a BS equivalence and you know it. Tkinter's lack of
new style classes was a design flaw, whereas, tuples are
immutable and a sort method would violate the concept of
immutability.

> Or, and perhaps even more relevant, because *some*
> functions don't support keyword arguments [...] for the
> sake of consistency you must never use keyword arguments
> even though your code would be improved by it

For some definition of "more relevant", i suppose.

> > Thus, a sporadic implementation of super() in my source
> > code would violate the spirit of PEP8.
>
> That's the sort of dubious reading of PEP 8 that Guido was
> warning against in his quote from Emerson.  Just because
> for technical reasons class Foo cannot use super, does not
> mean that you should never use super in any other class for
> the sake of "consistency". Consistency within a single
> class is more important than a foolish consistency across
> all classes.

You cannot even handle basic reading and comprehension, can
you? And i quote _again_ from PEP8:

    """
    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.
    """

Using that paragraph as a guide, we can form the following
hierarchal table:

    Consistency with every word of PEP8 (important)
    Consistency within a project (more important)
    Consistency within "scopes" (most important)

My choice to abandon Python's super() in favor of
consistency most directly aligns with the moderate #2
(Consistency within a project). You see Steven, not only is
a single script considered a project; and not *ONLY* is a
package considered a project; but yes, even the aggregate of
all scripts composing an entire library (aka: ricklib!) is a
project. Any questions?

> Especially since by your own admission, you are *giving up
> correctness* in order to buy "consistency":

"sacrificing correctness" only in a purely ideological
sense.

Explicit inheritance (aka: hard-coding the superclass
symbol) works just as well as implicit inheritance (aka:
relying on the "resolution magic" of super). Of course, in
the former case, a slight bit of onerous is placed on the
programmer because he/she must know the exact spelling of
the superclass symbol, whereas, OO's `super` is nothing but
a lazy shortcut which looks up and returns the symbol for
you.

Thus, using super is similar to using a remote control to
open your garage door as opposed to punching in a code.
Either method will open the door just fine. The remote
merely removes the need to remember a code.

It's really not that complicated Steven...