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...
--
https://mail.python.org/mailman/listinfo/python-list
