On Fri, May 15, 2009 at 6:52 AM, Arnaud Delobelle firstname.lastname@example.org wrote:
2009/5/15 Larry Hastings email@example.com:
On Thu, May 14, 2009 at 9:31 PM, Curt Hagenlocher firstname.lastname@example.org wrote:
I think this takes the discussion in a more practical direction. Imagine that there were a special method name __immutable__ to be implemented appropriately by all builtin types.
Python already has something *vaguely* like this; __hash__ is only supposed to be implemented on immutable objects. So if the object supports __hash__ one could declare that it is supposed to be immutable.
However, it's occasionally useful to define __hash__ on mutable objects, and indeed it's defined by default on user-defined classes. So __hash__ isn't a viable substitute for __immutable__ (&c).
However immutability is a shallow thing: tuple are immutable but () still can be changed!
More to the point, immutability is *not* the issue as Steven D'Aprano showed. There are perfectly legitimate reasons for using a default value that just happens to be mutable, without mutating it in the function body though. Dict is the most common example (especially since there is no frozendict type that could be used in its place).