Class-level variables - a scoping issue
ethan at stoneleaf.us
Mon Oct 11 04:56:48 CEST 2010
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
>>> 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
>> 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
>> of a name from an outer scope with that from an inner one after the
>> 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
> (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.
* 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.))
More information about the Python-list