On Jan 23, 8:22 pm, Bryan Olson <fakeaddr...@nowhere.org> wrote: > Paul Rubin wrote: > > Bryan Olson writes: > >>> BTW, class instances are usually immutable and thus don't require a > >>> mutex in the system I described. > >> Then you are describing a language radically different from Python. > > > That one threw me for a minute too, but I think the idea is that the > > class instance itself is immutable, while its slots (specifically the > > attribute dictionary) point to mutable objects. > > The meaning of 'immutable' is well-established in the Python literature. > Python's immutable types include tuple, frozenset, and various kinds of > numbers and strings. Class instances, not so much.
Of course class instances aren't immutable types: they're not even types. Let me suggest that there is a distinction between an immutable type and an immutable object. Immutable types are what you are talking about: it means that the type provides usable mutator methods. (Whether they mutate the object itself or some associated object doesn't matter.) Immutable objects are a different thing: it means the object cannot change in memory. Classes in Python are mutable types, usually. Class instances are (except for the refcount) immutable objects, usually. We usually talk about mutability of types, but mutability of objects is appropriate for discussion as well. So I can't really agree with your assessment that I wrong to call class instances immutable objects aside from refcounts. BTW, here's a minor brain bender: immutable types are mutable objects. > What's more, this matters when considering a GIL-less implementation. > Typical method calls can traverse lots of mutable stuff just to find the > function to invoke. Now that doesn't make sense at all. What is all this mutable stuff you have to go through, and what does it have to do with the GIL-less implementation? Can you explain further? Or are you just saying it'll be slow. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
