Accessing parent objects

[Steven D'Aprano]

On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:

> On Saturday, March 24, 2018 at 11:31:38 PM UTC-5, Steven D'Aprano wrote:
[...]
>> "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.

Depends on whether it is a foolish consistency or a sensible consistency.

[...]
> Python dictates that we follow certain well-defined rules.

Indeed. And one of those "rules" is that super is the right way to handle 
inheritance in a class. Unfortunately, for historical reasons, old-style 
Python 1 classes don't support super. So I sympathise with your plight in 
regards to tkinter classes.

(However that sympathy is heavily dissipated by the knowledge that this 
is a self-inflicted wound, due to your stubborn refusal to use Python 3.)

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.

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.

Or, and perhaps even more relevant, because *some* functions don't 
support keyword arguments:

    len(obj=arg)  # TypeError

for the sake of consistency you must never use keyword arguments even 
though your code would be improved by it:

    function_with_many_optional_arguments(
                None, None, None, None, None, None, 
                None, None, None, None, arg
                )


[...]
> 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.

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

> And although i freely admit that super() is
> technically the correct way to go


[...]
>> 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
[...]

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

Er... you do realise that Python 4.x is going to keep compatibility with 
Python 3.x? Whatever reasons you think you have for avoiding Python 3, 
those exact same reasons will apply to Python 4.

In fact, as Python continues to add more features, the distance between 
2.7 and the latest version is just going to continue growing.

If you're holding out under some fantasy that Python 4 is going to undo 
all the new features and become a de facto version 2.8, you are going to 
be very disappointed.



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

The moniker "Python X-thousand" (Python 3000, 4000, 5000...) is usually 
understood to mean a backwards-compatibility breaking version. Since 
Python 4 will *not* be such a version, what you are calling 4000 is 
better called "5000". If it even exists at all, it will be in the distant 
future, long after 4.0 and 4.1 are memories: my estimate is that nobody 
in the Python community will even consider another such major 
compatibility break until 4.7 or 4.9.

And even that is a very slim chance.


> 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:-)

Do you know what they call programming languages that stop evolving?

"Dead."



-- 
Steve