Carl Banks wrote:
Bryan Olson 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.
Class instances my or may not be types, but that has nothing to do with
any point at issue here. I'm saying that class instances are usually,
mutable, contrary to your claim, "class instances are usually immutable".
Let me suggest that there is a distinction between an
immutable type and an immutable object.
Let me further suggest that Python's documentation is entirely clear:
instances of immutable types are immutable objects. Instances of mutable
types are generally mutable objects. For example, tuple is an immutable
type, and thus tuples are immutable; list is a mutable type, and thus
lists are mutable.
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.
There's where we disagree. I assert that class instances are usually
mutable objects.
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.
That confusion disappears once one grasps that instances of immutable
types are immutable objects.
BTW, here's a minor brain bender: immutable types are mutable objects.
Some brains are too easily bent. Python is one of the many
object-oriented languages that reifies types as run-time objects. I see
no point in going through Python's immutable types to examine if there
is any way to mutate the corresponding type 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.
I elaborated at some length in another strand of this thread.
--
--Bryan
--
http://mail.python.org/mailman/listinfo/python-list
