Class Variable Access and Assignment

[Antoon Pardon]

Op 2005-11-04, Magnus Lycka schreef <lycka at carmen.se>:
> Antoon Pardon wrote:
>>>Because b.a += 2 expands to b.a = b.a + 2. Why would you want b.a =
>>><something> to correspond to b.__class__.a = <something>?
>> 
>> 
>> That is an implemantation detail. The only answer that you are given
>> means nothing more than: because it is implemented that way.
>
> Something that is written in the language reference is not
> an implementation detail. Every implementation that aims to
> be Python must follow this. It's a design decision.

I have looked and didn't find it in the language reference.

This is what I have found:

An augmented assignment expression like x += 1 can be rewritten
as x = x + 1 to achieve a similar, but not exactly equal effect.

I think one could argue that in the case of b.a += 1 and a
being a class variable that incrementing the class variable
was a similar effect in this case.

But I can be and maybe a more strict definition is available
that I looked over. Do happen to know one?

> Whether you like it or not, you will find out that the behaviour
> of Python is largely based on an idea of an underlying structure.
> A lot of the syntax is basically just convenient ways to access
> this structure, and there is a strong tradition to avoid magic.

Fine. I already wrote that if people think that changing this
behaviour would cause more problems than it solved or that
solving it would cause more problems than it is worth, I would
have no problem with that.

That doesn't change the fact that the current behaviour is
on occasions awkward or whatever you want to call it.

> The explicit use of self might be the most obvious example of that,
> but you can find a lot of other things in Python that shows you
> this, __dict__ for instance.
>
> I agree that the behaviour you are questioning isn't completely
> unsurprising for someone who stumbles over it the first time, but
> considering how things work in Python classes, where the class
> scope is searched if a name isn't found in the instance scope
> (self.__dict__), any other solution would involve more magic, and
> be more surprising to someone who actually knows what is going on.

It would be more suprising to someone depending on what is now
going on. I also find that people underestimate the magic that
is going on in python. But just because you are familiar with
the magic, doesn't make it less magic. IMO python shows its
history a little. 

> It's possible that a oldie like me, who started coding Python in
> 1996 is just blind to the warts in Python by now, but no language
> is perfect, and whatever design decisions you make, they will have
> both positive and negative consequences.

I completely agree. Personnaly I find python has withstood
its changes remarkebly well and I find the design in general
still very consistent despite the changes it underwent.

> I frankly don't understand what you are after Antoon. Just to
> vent your frustrations? If you want to use Python in an effective
> way, try to learn how to use the language that actually exists.

I'm after nothing particular. The only thing I'm frustrated about
is the way in which some people seem willing to defend python
just because it is python. If the only reaction I would have
gotten would have been something like: Yeah that seems a bit
awkward but fixing this would break more than it would cure,
I would have left it as it is.

> Asking questions in this forum is clearly a part of that, but
> your confrontational style, and idea that everything that bothers
> you is a language bug that needs to be fixed is not the most
> constructive approach.

I have rarely indicated I wanted things to be fixed. Sure I would
like it if some things were different, but I recognize that there
are more important things that needs to be resolved.

Does that mean I shouldn't mention things that IMO could have been
better or that I should only mention them in the softest of
language that certainly can't be interpreted as emotional language.

-- 
Antoon pardon