Class Variable Access and Assignment

[Antoon Pardon]

Op 2005-11-04, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> On Fri, 04 Nov 2005 07:31:46 +0000, Antoon Pardon wrote:
>
>>> The model makes sense in my opinion. If you don't like it then there are
>>> plenty of other languages to choose from that have decided to implement
>>> things differently.
>> 
>> And again this argument. Like it or leave it, as if one can't in general
>> like the language, without being blind for a number of shortcomings.
>> 
>> It is this kind of recations that make me think a number of people is
>> blindly devoted to the language to the point that any criticism of
>> the language becomes intollerable.
>
> There are good usage cases for the current inheritance behaviour. I asked
> before what usage case or cases you have for your desired behaviour, and
> you haven't answered. Perhaps you missed the question? Perhaps you haven't
> had a chance to reply yet? Or perhaps you have no usage case for the
> behaviour you want.

There are good use cases for a lot of things python doesn't provide.
There are good use cases for writable closures, but python doesn't
provide it, shrug, I can live with that. Use cases is a red herring
here.

> Some things are a matter of taste: should CPython prefer <> or != for not
> equal? Some things are a matter of objective fact: should CPython use a
> byte-code compiler and virtual machine, or a 1970s style interpreter that
> interprets the source code directly?
>
> The behaviour you are calling "insane" is partly a matter of taste, but it
> is mostly a matter of objective fact. I believe that the standard
> model for inheritance that you call insane is rational because it is
> useful in far more potential and actual pieces of code than the behaviour
> you prefer -- and the designers of (almost?) all OO languages seem to
> agree with me.

I didn't call the model for inheritance insane.

> The standard behaviour makes it easy for code to do the right thing in
> more cases, without the developer taking any special steps, and in the
> few cases where it doesn't do the right thing (e.g. when the behaviour you
> want is for all instances to share state) it is easy to work around. By
> contrast, the behaviour you want seems to be of very limited usefulness,
> and it makes it difficult to do the expected thing in almost all cases,
> and work-arounds are complex and easy to get wrong.

Please don't make this about what I *want*. I don't want anything.
I just noted that one and the same reference can be processed
multiple times by the python machinery, resulting in that same
reference referencing differnt variables at the same time and
stated that that was unsane behaviour.

> The standard behaviour makes it easy for objects to inherit state, and
> easy for them to over-ride defaults. The behaviour(s) you and Graham want
> have awkward side-effects: your proposed behaviour would mean that class
> attributes would mask instance attributes, or vice versa, meaning that
> the programmer would have to jump through hoops to get common types of
> behaviour like inheriting state.

You don't know what I want. You only know that I have my criticism of
particular behaviour. You seem to have your idea about what the
alternative would be like, and project that to what I would want.

> The behaviour you want would make it too easy to inadvertently have
> instances share state. Normally we want instances to share behaviour but
> have unique states -- you would change that. Why? If it is just a matter
> of taste, you are welcome to your opinion. But you don't say that the
> standard behaviour is "ugly", you say it is "insane", that is, irrational,
> and that the behaviour you want is rational.

I called it unsane, not insane. I think I paid enough attention to never
use the word "insane", yes I once used "madness" but that was after you
were already all over me for this.

Even should I have used the word insane, I used it for a lot less than
you are implying.

> That's an objective claim: please explain what makes your behaviour more
> rational than the standard behaviour. Is your behaviour more useful? Does
> it make code easier to write? Does it result in more compact code? What
> usage cases?

What my behaviour? I don't need to specify alternative behaviour in
order to judge specific behaviour.

-- 
Antoon Pardon