Sets in Python

thebjorn BjornSteinarFjeldPettersen at gmail.com
Thu Sep 20 02:45:45 EDT 2007


On Sep 20, 4:17 am, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
[...]
> Data structures don't have problems. Programmers do.

That's QOTW material :-)

> ... And language
> designers with sense build languages that minimize the programmers
> problems, not maximize them.
>
...
>
> The choices for the language designer are:
>
> (1) Invent some sort of magical non-deterministic hash function which
> always does the Right Thing.
>
> (2) Allow the hash of mutable objects to change, which means you can use
> mutable objects as keys in dicts but if you change them, you can no
> longer find them in the dict. They'll still be there, using up memory,
> but you can't get to them.
>
> (3) Simply disallow mutable objects as keys.

(4) Allow mutable objects as keys, but have undefined (implementation
defined) behavior if keys are mutated.

This would seem a natural extension of the "we're all adults" paradigm
(if I name a variable _foo you should treat it as private).
Unfortunately there is no visual cue in this case, and tracking down
where you relied on undefined behavior is notoriously time-consuming
(just ask your nearest C++ multiplatform programmer).

> Alternative 3 is easy to deal with: simply don't use mutable objects as
> keys. That's what Python does. Sure, the programmer sometimes needs to
> work around the lack (convert the list into a tuple, or a string, or
> pickle it, whatever...) which on rare occasions is hard to do, but at
> least there are no mysterious, hard to track down bugs.

Amen.

-- bjorn




More information about the Python-list mailing list