> (1) do you think that disallowing lists as keys is a big drawback?
>
>Its not a practical drawback, it is merely a drawback in "elegance".
>It seems cleaner to do this than to do the deep copy thing though.
That's what I though too.
> (2) would you accept the performance penalty of always deep copying
> lists used as keys? (2a) when using lists (2b) when not using lists!
>
>How deep? Does Python allow cycles in such structures?
Oops, you're right, it is possible to create lists containing circular
references. This would make deep-copying even less practical.
(Circular references cause other problems too, e.g. can't be printed
or dumped through "marshal", but they can be useful nevertheless, and
checking would be problematic.)
> (3) do you happen to have another implementation idea?
>
>Icon allows structure keys, and such keys can change -- lists have an
>associated serial number that is used for hashing since neither the
>contents nor the pointer to the list are safe to hash on. It is fast,
>cheap, and consistent with the mutable nature of (Icon) lists...but
>maybe Python lists are qualitatively different than Icon lists.
In Python using the pointer as a hash value would be safe (since it
can't change), but this would make lists almost as useless keys: after
d = {[1, 2]: 2; [1, 2, 3]: 3}
the test
d.has_key([1, 2])
would yield false, since the [1, 2] used here is a different instance
than the [1, 2] used as key.
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>