Really stupid question regarding PEP 252 and type/class unification

[Donn Cave]

Quoth Paul Prescod <paulp at ActiveState.com>:
| Russell Turpin wrote:
|>...
|> Now .. what about mutability? An int is immutable. But
|> a type derived from int is mutable. At least in its
|> attributes. But its default (core? base? what is the
|> right term?) value is still immutable. So mutability
|> is really a quality of the core/base/whatever value,
|> rather than of the type itself.
|
| I would say that the instance of the integer subtype is mutable but its
| value as an integer is not changeable. I expect it would still be
| hashable unless you override its __hash__.

The way I see it, mutability in Python is supported by object accessors,
so "is mutable" means "provides some feature that changes internal state."
Like __setitem__() or __setattr__().  There is no ambiguity.  An assigment
like "x = y" can't exploit mutability, and an assignment like "x.v = y"
must modify x, so only a mutable object can appear in that context without
error.  Mutability is not a profound difference between types of objects,
only a feature that appears in some kinds of objects.  That seems pretty
darned obvious, but I think if you didn't know Python you wouldn't guess
this from reading c.l.p, hence my mission to occasionally restate the obvious.

I haven't been following the present thread, but interpreted in this light,
I would expect any mutability of a derived type would appear with some
explicit notation, like x.value = 5 or whatever, and x = 5 would continue
to have nothing to do with mutability.  After what was done with x += 5,
though, I can't be totally sure how clear that is, so let me say, messing
with assignment in this way would utterly suck.

	Donn Cave, donn at u.washington.edu