[radiowave]

Where x is an identifier (presumably aka tag?) that refers to a variable, it is not beyond the bounds of possibility for "x = 1" to be interpreted as "store the value of 1 into the variable that is referred to by identifier x". Plenty of languages, including dynamically typed ones, manage to do this, as indeed Python does in many cases.

Not knowing the type of x is unrelated to question of where x's value is stored, or whether x's value will be stored somewhere else after we've assigned a new value to it.

[macbony]

I'm not really sure I understand your point. The value of x is still going to be in memory, but you may not have any references to it and it will be garbage collected. The disconnect is in thinking x is a variable and not an identifier. x points to the object in the parent until it is overridden. This allows me to dynamically alter the functionality of a class and all it's subclasses that don't override that functionality during runtime.

[radiowave]

I'm not disputing how or why it works, just saying that I think it is poor design, as it causes a statement that looks like variable assignment to actually produce overriding. I think this violates the principle of least astonishment, and I suspect there is no good reason (beyond implementation simplicity) why Python class variables do behave this way.

(edit: replaced "an expression" with "a statement")

[macbony]

No, the reason it exists is so you can override functionality of subclasses at run time, otherwise things like monkey patching would be impossible. I guess it COULD do a pass to see if the attr is an immutable or some form of primative type when __new__ is called and force those to be instantiated as instance attributes at the cost of internal consistency, but it seems pretty straight forward to me the way it works now. You don't need to be an expert, you just need a basic understand of how Python evaluates code and the difference between tags and variables.