Class Variable Access and Assignment

[Antoon Pardon]

Op 2005-11-05, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> 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?

I am not proposing specific behaviour. Because if I do, you will
just try to argue how much worst my proposed behaviour is.

Whether or not I can come up with a better proposal is irrelevant
to how sane the current behaviour is.

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

How many times do I have to repeat myself. I'm not proposing a change
to the language. 

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

I haven't written that once. You may think that you can imply it from
what I wrote, but then that is your inferance and not my words.

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

Well maybe English works differently from dutch, but I thought there
were a whole lot of gradation between sane and insane. And not being
sane IMO just means not being at one end of the extreme while being
insane meant to be at the other end of the extreme.

So when something doesn't make complete sense, instead of it making
no sense at all, I would think that wording it as unsane instead of
insane resembles best what I intended to mean.

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

I wasn't trolling. I just threw in an off hand remark. That you got so
heated up about that remark is not my responsibility. I'm not trolling
because I'm willing to defend my remark and I don't intend to get
people to get heated up about it. I just don't hold back because
people may get heated up about it.

> 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 I would be whining I would want the behaviour changed. I would just
keep complaining about it until someone else would have changed it.

Sure I would prefer it changed, but it is not that I *want* it to
change. I'll happily continue with python if it doesn't change.

Maybe when someone mentions something negative about python,
you shouldn't translate that into someone demanding a change
in python.

> If not you, then who? Most of the folks who have commented on
> this thread seem to like the existing behaviour.

Well fine, in that case it won't even change if I do come up with
an alternative proposal. So why should I bother?

-- 
Antoon Pardon