3

When using a class variable in Python, one can access and (if it's mutable) directly manipulate it via "self" (thanks to references) or "type(self)" (directly), while immutable variables (e.g., integers) apparently get shadowed by new instance objects when you just use "self".

So, when dealing with Python class variables, is it preferable/Pythonic to simply always use "type(self)" for working with class variables referred to from within class methods?

(I know class variables are sometimes frowned upon but when I work with them I want to access them in a consistent way (versus one way if they are immutable types and another way if they are mutable.)

Edit: Yes, if you modify the value an immutable you get a new object as a result. The side effect of modifying the value of a mutable object is what led to this question - "self" will give you a reference you can use to change the class variable without shadowing it, but if you assign a new object to it it will shadow it. Using classname.classvar or type(self).classvar or self.__class__ ensures you are always working with the class variable, not just shadowing it (though child classes complicate this as has been noted below).

MartyMacGyver
  • 9,483
  • 11
  • 47
  • 67
  • Can you show some example code? What do you mean by class methods? Do you mean methods that are decorated with @classmethod, or just methods of a class? – matt Jul 24 '14 at 01:41
  • I meant just regular methods of a class. There is some example code below - seems the question itself was understood despite the need for a few clarifications. – MartyMacGyver Jul 24 '14 at 02:38

4 Answers4

5

You'll probably want to access them with the actual type name, rather than either self or type(self).

The effect you're seeing has nothing to do with mutability. If you were to do

class Foo(object):
    x = []
    def __init__(self):
        self.x = [1]

the assignment in __init__ would create a new list and assign it to the instance attribute x, ignoring the class attribute, even though Foo.x is a mutable object. Whenever you want to assign to an attribute, you need to use the object it was actually defined on.

Note that modifying the attribute through type(self) fails in the case of inheritance:

class Foo(object):
    x = 1
    def modify_x(self, x):
        type(self).x = x

class Bar(Foo): pass

Foo().modify_x(2) # modifies Foo.x
Bar().modify_x(3) # modifies Bar.x, the wrong attribute
user2357112
  • 260,549
  • 28
  • 431
  • 505
  • Your point about explicitly using the class name is interesting... though I wonder if there is a cleaner way to do it than explicitly sprinkling the class name throughout. As for the example, yes, if you assign a new list "[1]" you'll shadow the class variable. But if you change the existing list (e.g., append) then you don't create a new object (while changing an immutable would always create a new object - shadowing being mediated only by the use of the class name or "self"). – MartyMacGyver Jul 24 '14 at 02:03
  • @MartyMacGyver: You *can't* change an immutable object. You can only reassign it, and *assignment* is the real source of your problem. – user2357112 Jul 24 '14 at 02:05
  • I could put "change" or "modify" in quotes, but yes, I got and get that fact. One could modify mutable class variables using self alone (because references), but I wanted to know if (for clarity) one should always use a type(self).classvar (or classname.classvar) construction when working with class variables, and avoid any side-effect of using "self" alone. – MartyMacGyver Jul 24 '14 at 02:12
  • @MartyMacGyver: There are cases where `self` would be preferable, for example if subclasses are expected to override the attribute. When you want to refer to a specific class's class attribute, though, I would recommend referring to the class explicitly. – user2357112 Jul 24 '14 at 02:21
  • Would "self" alone would work to override a *class* variable with a new *class* variable in a subclass? I can see it creating an instance variable... about all I can see working is an assignment to subclass.classvar. – MartyMacGyver Jul 24 '14 at 02:30
  • @MartyMacGyver: No, you couldn't create a class attribute through self. I mean that you'd access the proper override through self; for example, if you have a class `Base` with an `x` attribute and a bunch of subclasses that define their own values of `x`, you'd access the proper value through `self.x`. – user2357112 Jul 24 '14 at 02:33
  • How about ```self.__class__.attribute```? – wwii Jul 24 '14 at 04:10
1
python -c 'import this'
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I will suggest these for reference

Beautiful is better than ugly.
Simple is better than complex.
Readability counts.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
If the implementation is hard to explain, it's a bad idea.

and my suggestion is to use direct attribute reference because it is probably what the language designers intended.

Andrew Johnson
  • 3,078
  • 1
  • 18
  • 24
  • That was a long way around the block... So, direct as in classname.classvar or type(self).classvar or some other construction? – MartyMacGyver Jul 24 '14 at 02:07
  • Also `type(self).classvar` might have different effects on different versions of python. `type()` has gone through changes throughout python's history. – Andrew Johnson Jul 24 '14 at 02:11
  • Considering 2.6, 2.7 and 3.x, do you know of any such differing effects? And again, you recommend which construction - classname.classvar or type(self).classvar or something else? – MartyMacGyver Jul 24 '14 at 02:19
  • I recommend `classname.classvar`. Specifically the interaction between meta-classes and type have changed between 2.6, 2.7, and 3.x. Also meta-classes are common even if you don't intend to work with them yourself. http://python-3-patterns-idioms-test.readthedocs.org/en/latest/Metaprogramming.html#the-metaclass-hook – Andrew Johnson Jul 24 '14 at 02:28
  • @AndrewJohnson - Thanks for the detail and the advice! I'll give a closer look at meta-classes as well. – MartyMacGyver Jul 24 '14 at 02:34
1

After speaking with others offline (and per @wwii's comment on one of the answers here), it turns out the best way to do this without embedding the class name explicitly is to use self.__class__.attribute.

(While some people out there use type(self).attribute it causes other problems.)

MartyMacGyver
  • 9,483
  • 11
  • 47
  • 67
0

https://bitbucket.org/larry/cpython350/pull-requests/15/issue-24912-prevent-class-assignment/diff

In common cases they work the same (probably you should use YouClass.NameAttribute to avoid problems with later inheritance). In short the difference was till Python 3.5. The problem was issue #24912 (not allowing assingment in all cases). Example: an immutable type like int was alocated staticalli, and HEAPTYPE rules accidentally where stoping from alowing class assingment.

Bocian
  • 3
  • 3