Message397017
I neglected to mention above what c is. I Irit guessed right as
>>> class C: pass
...
>>> c = C()
is what I (also) usually do for examples and testing.
Removing "new-style" elsewhere solved the issue with the error message for "ob.__class__ = non_class_object". The new error message for "ob.__class__ = someclass" replaces 'heap' with 'mutable'. But it can still be confusing as the qualification in
__class__ assignment only supported for mutable types or ModuleType subclasses
applies to both type(ob) and someclass and the same error is given if either does not qualify. The use of the plural 'types' allows but does not mandate this interpretation. Also, "mutable types" means that the types are mutable, not their instances. Although 'list' is sometimes referred to as a 'mutable type' because its instances are, 'list' itself is not mutable and does not qualify here.
I am closing this issue, which is about the error message, because the new message is accurate when understood. I cannot think of any better one-line message. Explaining the background needed to understand should be done elsewhere.
Andre, I nosied you in case the above would help you improve Friendly's explanation of this error. I was a bit confused myself until I did more experiments.
Note: Even when type(ob) and someclass both 'qualify', the assignment will fail if instances are 'incompatible'. Let M be a subclass of types.ModuleType.
c.__class__ = M # fails with
TypeError: __class__ assignment: 'M' object layout differs from 'C'
The difference is obvious by looking as dir(c) and dir(M('somename')). |
|
Date |
User |
Action |
Args |
2021-07-05 19:15:08 | terry.reedy | set | recipients:
+ terry.reedy, benjamin.peterson, aroberge, stutzbach, eric.araujo, Trundle, jonash, flox, iritkatriel |
2021-07-05 19:15:08 | terry.reedy | set | messageid: <1625512508.85.0.0407702827281.issue4600@roundup.psfhosted.org> |
2021-07-05 19:15:08 | terry.reedy | link | issue4600 messages |
2021-07-05 19:15:08 | terry.reedy | create | |
|