Class Variable Access and Assignment

[Steven D'Aprano]

On Fri, 04 Nov 2005 12:10:11 +0000, Antoon Pardon wrote:

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

Is that a round-about way of saying that you really have no idea of
whether, how or when your proposed behaviour would be useful?

Personally, I think that when you are proposing a major change to a
language that would break the way inheritance works, there should be more
benefits to the new way than the old way. 


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

Antoon, I've been pedanted at by experts, and you ain't one. The behaviour
which you repeatedly described as not sane implements the model for
inheritance. The fact that you never explicitly said "the standard OO
model of inheritance" cuts no ice with me, not when you've written
multiple posts saying that the behaviour of that standard inheritance
model is not sane.


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

"Unsane" now?

Heaven forbid that I should criticise people for inventing new words, but
how precisely is unsane different from insane? In standard English,
something which is not sane is insane.


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

Well now is a good time for you to stop being so coy and tell us what you
want. You don't like the current behaviour. So what is your alternative?
I've given you some suggestions for alternative behaviour. You've refused
to say which one you prefer, or suggest your own.

If you're just trolling, you've done a great job of it because you fooled
me well and good. But if you are serious in your criticism about the
behaviour, then stop mucking about and tell us what the behaviour should
be. Otherwise your criticism isn't going to have any practical effect on
the language at all.



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

If you are serious about wanting the behaviour changed, and not just
whining, then somebody has to come up with an alternative behaviour that
is better. If not you, then who? Most of the folks who have commented on
this thread seem to like the existing behaviour.



-- 
Steven.