Class-level variables - a scoping issue

[Ethan Furman]

John Nagle wrote:
> On 10/10/2010 12:53 AM, Lawrence D'Oliveiro wrote:
> 
>> In message<4cb14f8c$0$1627$742ec2ed at news.sonic.net>, John Nagle wrote:
>>
>>> Within "fn1", the first reference to "self.classvar" references the 
>>> class-
>>> level version of "classvar".  The assignment overrides that and 
>>> creates an
>>> object-level instance of "self.classvar". Further references to
>>> self.classvar" in f1 then reference the object-level "classvar"

As has been noted, this is the documented behavior, and completely 
rational in my mind with the way instances should interact with their 
classes.

>> I’d say there is definitely an inconsistency with the absoutely anal
>> restrictions on global variables, i.e. the well-known sequence
>>
>>      ... reference to globalvar ...
>>      globalvar = newvalue
>>
>> which triggers the error “UnboundLocalError: local variable 'globalvar'
>> referenced before assignment”.
>>
>> It seems to me the same principle, that of disallowing implicit 
>> overriding
>> of a name from an outer scope with that from an inner one after the 
>> former
>> has already been referenced, should be applied here as well.

I completely disagree.  Inner and outer scopes are working in the 
procedural (/functional?) paradigm, whereas classes and instances are 
working in the OO paradigm.

You don't make every auto driver wear helmets because motorcycle drivers 
have to*.

>     (If you want default values for an instance, you define them
> in __init__, not as class-level attributes.)

If you want non-class mutable attributes, you assign them in __init__. 
There is nothing incorrect about assigning default immutable attributes 
at the class level.

~Ethan~

--
* Obviously, this statement only makes sense in those locales that 
require helmets on motorcycle riders, but not on everyday auto drivers. 
  (Yes, I'm thinking of race-car drivers (at least in my locale.))