Forum Archive

Sorry, to ask yet another Python question. But because of the nature of it, I wanted to ask here as I don't get it.

From what I have read, attrs defined above an init statement in a class, are shared variables for all instances of a class. i mind meaning there is only one copy of these vars for all instances of the object. Well that's how I think it works.

But I often want to say have a constant in my class, let's say for a menu_bar_height. I really don't like putting these constants up the top of the file. Especially when the file starts growing and you start having a lot of constants.
Also, makes it harder, to pick up one class and move it into another file or just copy and re-purpose the class.
But by being defined in the class a level of association is implied, helping with naming etc.
The other thing, I think seems that would be beneficial, is when you come back some weeks or months later, it's a lot easier to understand the class and it's constants dependencies.

So I put a sample below. I just wanted to ask is it valid and ok to do it. The reason I ask, I see no code like this. Maybe it's around, I just haven't seen it. If this is fine, I would prefer to start using this method keeping in mind I have to understand, if I do change one of these attrs, they change for instances of the object.

class CodeDisplay(ui.View):
    _label_name = 'style_label'
    _tool_button_height = 36
    _tool_bar_bg_color = 'lime'
    _tool_bar_tint_color = 'black'

    def __init__(self, style = 'colorful', use_linenos = True,
    *args, **kwargs):
        ui.View.__init__(self, *args, **kwargs)

        self.code = None
        self.web_view = None
        self.style = style
        self.use_linenos = use_linenos

That's valid. Be careful, though as it can be easy to get confused. If you ever set the attribute of the instance, it becomes an instance var rather than a class var. Then changes to the class var no longer update the instance.

>>> c=CodeDisplay()
>>> print c._tool_button_height 
36
>>> CodeDisplay._tool_button_height = 44
>>> print c._tool_button_height 
44
>>> c._tool_button_height = 36
>>> print c._tool_button_height 
36
>>> print CodeDisplay._tool_button_height 
44

@JonB , thanks. I didnt see that subtle difference. I am referring to the class attrs in the code using self._label_name for reading it. Does it make more sense to refer to the attr like CodeDisplay._label_name instead?

When using class attributes I write type(self).whatever. This means that if the class is subclassed, it will refer to the subclass's class attributes - I don't really know if that's a good or bad thing.

This sounds stupid I know, I could not help myself asking just incase 😱
But can you have a global as a class var? Well, a better name might be a persistent var.
In making a popup menu I would like it to have its own persistent state. But for the reasons above I would like to keep this in the class if possible rather than have a file/module global. In this instance, I would also prefer to to have to calling class track the value.

Again, it does not make sense to me I could do this. But Python is full of surprises.

Class attributes are very similar to module attributes/globals. After all, classes are (usually) just module attributes too, so the only difference is that the class attribute requires an extra step.

What exactly do you mean with "persistent"? If you want to keep the state across multiple runs then you need to save it in a file.

@dgelessus , thanks. Yeah, it is over multiple runs/calls. I have a view on screen, with a button on it that creates an instance of a pop menu class. I know the calling class could keep the object alive. But I don't want that. I want the popup menu/view to be as autonomous as possible.
It's ok, just thought I would ask in case I was missing something that was built in.
Easy enough to write a file. I don't why, I just feel so reluctant to do it.maybe I just need to get over it...

iirc, objects whose names start with double underscore do not get cleared -- though any custom modules they depend on might be., unless those custom modules are in site-packages.