inconsistency with += between different types ?

[Donn Cave]

Quoth "Steve Holden" <sholden at holdenweb.com>:
| "Andreas Leitgeb" <Andreas.Leitgeb at siemens.at> wrote ...
...
|> Also, what characterizes an object to be mutable ?
|> Is it the existence or not-existence of mutating methods, or
|>  is the more behind the scenes of strings,ints and tuples ?
|
| Section 3.1 of the Reference Manual defines mutability (in so far as an
| adequate definition is given). Section 6.3 says """When a target is part of
| a mutable object (an attribute reference, subscription or slicing), the
| mutable object must ultimately perform the assignment and decide about its
| validity, and may raise an exception if the assignment is unacceptable."""

``...The value of some objects can change. Objects whose value 
  can change are said to be mutable; objects whose value is unchangeable
  once they are created are called immutable. (The value of an immutable
  container object that contains a reference to a mutable object can 
  change when the latter's value is changed; however the container is
  still considered immutable, because the collection of objects it
  contains cannot be changed. So, immutability is not strictly the
  same as having an unchangeable value, it is more subtle.) An object's
  mutability is determined by its type; for instance, numbers, strings
  and tuples are immutable, while dictionaries and lists are mutable.''

The sad thing is, all this hand-waving is really germane to only one
issue I can think of, an object's suitability for use as a hash key.

Beyond that, we have no practical interest in whether an object is
mutable, only whether it supports the particular functionality that's
called for by the problem at hand.  That particular functionality may
imply mutability, but who cares?

And what could make the point more clearly, than a class instance that
can choose to be immutable, for practical purposes relative to in-place
modification functionality.

	Donn Cave, donn at u.washington.edu