Style question - defining immutable class data members

[Gary Herron]

John Posner wrote:
> Matthew Woodcraft said:
>
>   
>> I doubt it's because anyone particularly wanted this
>> behaviour; it just
>> falls out of the way '+=' is defined.
>>
>> At the point where 'inst.x += 1' is compiled,
>> Python doesn't know
>> whether 'inst.x' is going to turn out to be a class
>> attribute or an
>> instance attribute or a property. So really the only thing
>> it can do is
>> generate code to read inst.x in the usual way and then
>> assign to inst.x
>> in the usual way (where 'the usual way' for CPython
>> is LOAD_ATTR and
>> STORE_ATTR).
>>     
>
> That sounds reasonable to me.
>
>
> Matthew Woodcraft also said:
>
>   
>>> Is there any actual advantage to self.attribute picking up
>>> Class.attribute instead of raising a NameError?
>>>       
>
>   
>> You use that any time you call an ordinary method using syntax like
>> 'self.foo()'.
>>     
>
> Yes, but that's performing a read (and call) operation on an attribute. My question concerned itself with potential confusion when you perform a write operation on an attribute.
>
>
> Bruno Desthuilliers said:
>
>   
>>> My question is ... WHY does the interpreter  silently create the
>>> instance attribute at this point,
>>>       
>
>   
>> Becaause that's how you create instance attributes in Python. Why do you
>> think 'self' - that is, a reference to some object - is mandatory in
>> "methods" (really, functions) arguments list ?
>>     
>
>   
>> Or do you mean that the existence of a synonym class attribute should be
>> checked on each instance variable assignement ? This would probably be a
>> big performance hit, ...
>>     
>
> Yes, Bruno, I'm persuaded by this argument. Ideally, I'd like the interpreter to prevent the programmer from shooting him/herself in the foot, but it's not worth the performance hit.
>
>   
>> and it would make per-instance method overloading
>> impossible (remember that OOP is about objects, not classes).
>>     
>
> Yes again. While I was writing the above comment ("write operation on an attribute"), it *did* cross my mind that you might want to write self.attribute, even if it names a method, not a data-item.
>
>
> Summary: I no longer suspect that "Python is broken". I *do* think that there's a situation that is potentially quite confusing:
>
>  * In the statement "self.x = self.x + 1", the two "self.x" names can sometimes refer to different objects.
>
>  * Even worse, in the equivalent statement "self.x += 1", the single name "self.x" can sometimes refer to two different objects!
>
> I think this situation should be handled in documentation. (I'm a tech writer in my day job ... oh wait, I forgot ... I got laid off from my day job in December.) I'll look into what the standard Python doc set says on this matter.
>   

What's broken here is trying to have a class variable and an instance 
variable of the same name and expecting Python to get it right. 

Both of these problems become non-issues if you follow the "best 
practice" for defining instance variables: 

That is, set instance variables to their initial value in the __init__ 
method.    And if you need a class default value, name it differently:

For example:

class C:
  default_x = 123

  def __init__(self):
    self.x = self.default_x
 
  def inc(self):
    self.x += 1 // behaves as expected

Then self.x or inst=C() and inst.x will always refer to a instance 
variable, the code is clear,  and no confusion ensues.



Gary Herron





> -John
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>