>> Type objects are also singletons (e.g., type(True) returns the same >> object as type(False); ditto type("True") and type("False") and >> type("xyz"); etc). [Guido] > But types are not immutable, so their semantics are different anyway. > The point of the remark was to emphasize that immutable types have > some leniency in their semantics regarding object identity. For > mutable types the semantics regarding object identity are defined > explicitly by each type or operation (some operations always return a > new object, others always return the same one). The latter is forbidden by the language reference manual, though. Here's Joshua's original quote, but with more context: Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. I never thought of type objects as being mutable -- they're compared ("==") by identity, are usable as dict keys, act like immutable objects according to the text above, etc. Do you really think of them as being mutable? If so, why <wink>? E.g., after "a = 1; b = 1", a and b may or may not refer to the same object with the value one, depending on the implementation, but after "c = []; d = []", c and d are guaranteed to refer to two different, unique, newly created empty lists. (Note that "c = d = []" assigns the same object to both c and d.) If the text in the first quoted paragraph isn't correct, then this second paragraph doesn't explain anything about mutable objects in general by way of an example that happens to pick on empty-list literals, rather it's making a promise only about empty-list literals, but in a misleading way (reading for all the world as if it *were* trying to explain something about mutable objects in general by way of an example that happens to pick on empty-list literals). 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!
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