[Python-ideas] RFC: PEP: Add dict.__version__

[Terry Reedy]

On 1/11/2016 1:48 AM, Andrew Barnert via Python-ideas wrote:
> On Jan 10, 2016, at 22:04, Terry Reedy
> <tjreedy at udel.edu> wrote:
>>
>> On 1/10/2016 12:23 AM, Chris Angelico wrote:
>>
>> (in reponse to Steven's response to my post)
>>
>>> There's more to it than that. Yes, a dict maps values to values;
>>> but the keys MUST be immutable
>>
>> Keys just have to be hashable; only hashes need to be immutable.
>
>> By default, hashes depends on ids, which are immutable for a
>> particular object within a run.
>>
>> (otherwise hashing has problems),

A '>' quote mark is missing here.  This line is from Chris.

>> only if the hash depends on values that mutate.  Some do.

In other words, hashes should not depend on values that mutate.  We all 
agree on that.

> But

We all three agree on the following.

> if equality depends on values, the hash has to depend on those
> same values. (Because two values that are equal have to hash equal.)
> Which means that if equality depends on any mutable values, the type
> can't be hashable. Which is why none of the built-in mutable types
> are hashable.

By default, object equality is based on ids.

> But it's not _that_ much of an oversimplification to say that keys
> have to be immutable.

By default, an instance of a subclass of object is mutable, hashable (by 
id, making the hash immutable), and usable as a dict key.  The majority 
of both builtin and user-defined classes follow this pattern and are 
quite usable as keys, contrary to the claim.

Classes with immutable instances (tuples, numbers, strings, frozen sets, 
some extension classes, and user classes that take special measures) are 
exceptions.  So are classes with mutable hashes (lists, sets, dicts, 
some extension classes, and user classes that override __eq__ and 
__hash__).

-- 
Terry Jan Reedy