Class variable / instance variable

[ifigazsi]

class Something:

    saved_data = [2, 3, 4, 5]

    def __init__(self):
        self.data = Something.saved_data
        self.data2 = [x for x in Something.saved_data]

x = Something()

print(x.data is Something.saved_data)
print(x.data2 is Something.saved_data)

Very basic question:
I have a class variable, but I want to change this at instance level, without changing the original class variable, how can i make it?

self.data2 is a solution, but is there a better/faster/pythonic way?

Thank you,
ifigazsi

[buran]

I have a class variable, but I want to change this at instance level, without changing the original class variable, how can i make it

This looks like wrong design - if you want and are going to change it at instance level why it should be class attributee - it should be instance attribute.

[ifigazsi]

I have a class variable, but I want to change this at instance level, without changing the original class variable, how can i make it

This looks like wrong design - if you want and are going to change it at instance level why it should be class attributee - it should be instance attribute.

Ok, so it seems like wrong design. (first attempt in OOP ) (i tried to update it)

I want to create a initial_data which is accessible by all instances, to start to work with.
Then after a lot of iterations resume to the original (initial) data.

class Something:

    def __init__(self):
        self.saved_data = [2,3,4,5]
        self.data_to_work_with = self.saved_data
        self.data_to_work_with2 = [x for x in self.saved_data]

x = Something()

print(x.data_to_work_with is x.saved_data)
print(x.data_to_work_with2 is x.saved_data)

[Yoriz]

Something like this ?

class Something:
 
    data = [2, 3, 4, 5]
 
    def __init__(self):
        self.reset_data()

    def reset_data(self):
        self.data = Something.data[:]
 
something = Something()
 
something.data.append(6)
print(Something.data, something.data)
something.reset_data()
print(Something.data, something.data)

Output:
[2, 3, 4, 5] [2, 3, 4, 5, 6]
[2, 3, 4, 5] [2, 3, 4, 5]

[ifigazsi]

Something like this ?

class Something:
 
    data = [2, 3, 4, 5]
 
    def __init__(self):
        self.reset_data()

    def reset_data(self):
        self.data = Something.data[:]
 
something = Something()
 
something.data.append(6)
print(Something.data, something.data)
something.reset_data()
print(Something.data, something.data)

Output:
[2, 3, 4, 5] [2, 3, 4, 5, 6]
[2, 3, 4, 5] [2, 3, 4, 5]

Yes, thank you! :)
But is this a bad design or not necessarily?

[deanhystad]

Good or bad design depends on the problem you are trying to solve. Global variables are usually bad, but sometimes they can lead to an elegant solution for the right kind of problems. Using a class with no instances is usually bad, but it can be an elegant way to implement a singleton.

With no information about your problem it is impossible to say if any design is good or bad.

[ifigazsi]

Good or bad design depends on the problem you are trying to solve. Global variables are usually bad, but sometimes they can lead to an elegant solution for the right kind of problems. Using a class with no instances is usually bad, but it can be an elegant way to implement a singleton.

With no information about your problem it is impossible to say if any design is good or bad.

Ok, let's assume you have a few workshops, you want to track the component list and sometimes they got a refill. (i know it's simplistic, but for now that's all i need)
Is it a good/bad design? How you would improve this?

class Workshop:

    def __init__(self, name):
        self.name = name
        self.components_data = ['d2', 'f3', 'g4', 'h5']
        self.refill_all_components()

    def refill_all_components(self):
        self.components_available = self.components_data[:]
        self.components_used = []

    def use_a_component(self):
        from random import shuffle
        shuffle(self.components_available)
        self.components_used.append(self.components_available.pop())

    def __repr__(self):
        return (f'{self.name} components left: {self.components_available} components used: {self.components_used}')

workshop1 = Workshop('Unit1')
workshop2 = Workshop('Unit2')
workshop3 = Workshop('Unit3')

for i in range(2):
    workshop1.use_a_component()
print(workshop1)
workshop1.refill_all_components()
print(workshop1)

[deanhystad]

It is not a common practice to hid import statements inside a function. They should all appear at the top of the file unless you are trying to get around a circular reference problem.

As I said before, you cannot judge design in a vacuum. If this design works well for solving your problem, it is a good design. I can say that is is not a generic solution. This would never be a module that others can use to solve their problem. Components should be generic. An inventory control system would never have a "refill_all_components" method. It might have method(s) to check inventory numbers and aid in ordering, but "get everything right now" is unrealistic. In an inventory system the components would be more than just a string, they would be objects. The inventory system would know how to communicate with objects to let you know if a component was available or when a component was available.

Is this a good design? Maybe yes. Maybe no.

[ifigazsi]

It is not a common practice to hid import statements inside a function. They should all appear at the top of the file unless you are trying to get around a circular reference problem.

As I said before, you cannot judge design in a vacuum. If this design works well for solving your problem, it is a good design. I can say that is is not a generic solution. This would never be a module that others can use to solve their problem. Components should be generic. An inventory control system would never have a "refill_all_components" method. It might have method(s) to check inventory numbers and aid in ordering, but "get everything right now" is unrealistic. In an inventory system the components would be more than just a string, they would be objects. The inventory system would know how to communicate with objects to let you know if a component was available or when a component was available.

Is this a good design? Maybe yes. Maybe no.

Thanks that make sense. Anyway next time, I try to design something more generic and reusable. (On the other hand I guess that means more codeing)

[buran]

It's worth to mention that probably in real life one would like to have a count of the different components on their inventory