"Martin v. Löwis" <martin at v.loewis.de> wrote in message news:402E2280.5070404 at v.loewis.de... > Tim Peters wrote: > > I expect the easiest way out is for you to decide that type objects are > > immutable after all -- even if there are obscure ways to mutate them! > > It's not at all obscure: > > >>> class A(object):pass > ... > >>> type(A).__name__ > 'type' > >>> A.foo = 1 > >>> A.foo > 1 > > Look, Ma, I'm mutating a type! > No, son, you are just modifying it. > > The properties you quote (comparison checks for identity, usable as a > dictionary key) don't imply at all that an object is immutable. Leaving aside mutability, there does seems to be something distinctively 'n-gleton'-like about types in that the identity of a type object is (a surrogate for) its value. For instance, after def f1(): pass def f2(): pass f1 and f2 will compare unequal, simply because '==' does not check functions for attribute equality, including code-object, identity. Nonetheless, f1 and f2 are interchangible in any calculation not dependent on identity. On the otherhand, after class c1(object): pass class c2(object): pass c1 and c2 *are* different and produce instances of different types when called. This sometimes surprises people, leading to misplaced clp bug posts, when the duplication is unintentional, as with slightly different imports resulting in two modules derived from the same disk file. Terry J. Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4