Say I have a class, which has a number of subclasses. I can instantiate the class. I can then set its <code>__class__</code> attribute to one of the subclasses. I have effectively changed the class type to the type of its subclass, on a live object. I can call methods on it which invoke the subclass's version of those methods. So, how dangerous is doing this? It seems weird, but is it wrong to do such a thing? Despite the ability to change type at run-time, is this a feature of the language that should completely be avoided? Why or why not? (Depending on responses, I'll post a more-specific question about what I would like to do, and if there are better alternatives).

Here's a list of things I can think of that make this dangerous, in rough order from worst to least bad: <ul> <li>It's likely to be confusing to someone reading or debugging your code.</li> <li>You won't have gotten the right <code>__init__</code> method, so you probably won't have all of the instance variables initialized properly (or even at all).</li> <li>The differences between 2.x and 3.x are significant enough that it may be painful to port.</li> <li>There are some edge cases with classmethods, hand-coded descriptors, hooks to the method resolution order, etc., and they're different between classic and new-style classes (and, again, between 2.x and 3.x).</li> <li>If you use <code>__slots__</code>, all of the classes must have identical slots. (And if you have the compatible but different slots, it may appear to work at first but do horrible things…) </li> <li>Special method definitions in new-style classes may not change. (In fact, this will work in practice with all current Python implementations, but it's not documented to work, so…)</li> <li>If you use <code>__new__</code>, things will not work the way you naively expected.</li> <li>If the classes have different metaclasses, things will get even more confusing.</li> </ul> Meanwhile, in many cases where you'd think this is necessary, there are better options: <ul> <li>Use a factory to create an instance of the appropriate class dynamically, instead of creating a base instance and then munging it into a derived one.</li> <li>Use <code>__new__</code> or other mechanisms to hook the construction.</li> <li>Redesign things so you have a single class with some data-driven behavior, instead of abusing inheritance.</li> </ul> As a very most common specific case of the last one, just put all of the "variable methods" into classes whose instances are kept as a data member of the "parent", rather than into subclasses. Instead of changing <code>self.__class__ = OtherSubclass</code>, just do <code>self.member = OtherSubclass(self)</code>. If you really need methods to magically change, automatic forwarding (e.g., via <code>__getattr__</code>) is a much more common and pythonic idiom than changing classes on the fly.

Assigning the <code>__class__</code> attribute is useful if you have a long time running application and you need to replace an old version of some object by a newer version of the same class without loss of data, e.g. after some <code>reload(mymodule)</code> and without reload of unchanged modules. Other example is if you implement persistency - something similar to <code>pickle.load</code>. All other usage is discouraged, especially if you can write the complete code before starting the application.

How dangerous is setting self.__class_

Say I have a class, which has a number of subclasses.

I can instantiate the class. I can then set its __class__ attribute to one of the subclasses. I have effectively changed the class type to the type of its subclass, on a live object. I can call methods on it which invoke the subclass's version of those methods.

So, how dangerous is doing this? It seems weird, but is it wrong to do such a thing? Despite the ability to change type at run-time, is this a feature of the language that should completely be avoided? Why or why not?

(Depending on responses, I'll post a more-specific question about what I would like to do, and if there are better alternatives).

What does self __ class __ do?

self. __class__ is a reference to the type of the current instance. Throwing an exception here is like using an assert statement elsewhere in your code, it protects you from making silly mistakes. type() should be preferred over self.

Why do class methods need self?

self represents the instance of the class. By using the “self” we can access the attributes and methods of the class in python. It binds the attributes with the given arguments. The reason you need to use self. is because Python does not use the @ syntax to refer to instance attributes.

Does every class method need self?

Class methods don't need a class instance. They can't access the instance ( self ) but they have access to the class itself via cls . Static methods don't have access to cls or self . They work like regular functions but belong to the class's namespace.

Why do we use self in Python class?

The self keyword is used to represent an instance (object) of the given class. In this case, the two Cat objects cat1 and cat2 have their own name and age attributes. If there was no self argument, the same class couldn't hold the information for both these objects.

Here's a list of things I can think of that make this dangerous, in rough order from worst to least bad:

It's likely to be confusing to someone reading or debugging your code.
You won't have gotten the right __init__ method, so you probably won't have all of the instance variables initialized properly (or even at all).
The differences between 2.x and 3.x are significant enough that it may be painful to port.
There are some edge cases with classmethods, hand-coded descriptors, hooks to the method resolution order, etc., and they're different between classic and new-style classes (and, again, between 2.x and 3.x).
If you use __slots__, all of the classes must have identical slots. (And if you have the compatible but different slots, it may appear to work at first but do horrible things…)
Special method definitions in new-style classes may not change. (In fact, this will work in practice with all current Python implementations, but it's not documented to work, so…)
If you use __new__, things will not work the way you naively expected.
If the classes have different metaclasses, things will get even more confusing.

Meanwhile, in many cases where you'd think this is necessary, there are better options:

Use a factory to create an instance of the appropriate class dynamically, instead of creating a base instance and then munging it into a derived one.
Use __new__ or other mechanisms to hook the construction.
Redesign things so you have a single class with some data-driven behavior, instead of abusing inheritance.

As a very most common specific case of the last one, just put all of the "variable methods" into classes whose instances are kept as a data member of the "parent", rather than into subclasses. Instead of changing self.__class__ = OtherSubclass, just do self.member = OtherSubclass(self). If you really need methods to magically change, automatic forwarding (e.g., via __getattr__) is a much more common and pythonic idiom than changing classes on the fly.

Assigning the __class__ attribute is useful if you have a long time running application and you need to replace an old version of some object by a newer version of the same class without loss of data, e.g. after some reload(mymodule) and without reload of unchanged modules. Other example is if you implement persistency - something similar to pickle.load.

All other usage is discouraged, especially if you can write the complete code before starting the application.

How dangerous is setting self.class to something else?

Tags:

python

python-3.x

python-2.x

imm

People also ask

2 Answers

abarnert

hynekcer

Recent Activity

Donate For Us

How dangerous is setting self.__class__ to something else?