Python not a Very High-Level Language?

[bjorn]

Tres Seaver wrote:

> In article <3870DB37.761034EA at roguewave.com>,
> bjorn  <bjorn at roguewave.com> wrote:
> >Aahz Maruch wrote:
> >
> >> In article <386E7BD4.514764EA at ndh.net>,
> >> Stefan Schwarzer  <s.schwarzer at ndh.net> wrote:
> >> >
> >> >The other topics which the author on the O'Reilly site, Greg Wilson,
> >> >mentions might also be worth considering. For example, I never needed
> >> >tuples (explicitly) yet, i. e. in a sense that lists would not work.
> >> >(If tuples would be taken out of the language or their use deprecated)
> >> >tuple un/packing would become list un/packing and so on.)
> >>
> >> Anyone who claims that tuples are unnecessary has never used a tuple as
> >> a dict key.  That requirement necessitates differentiating between a
> >> mutable and immutable list -- might as well stick with tuples.
> >> --
> >
> >So what you're saying is that dicts are broken since they can't take
> >lists as keys <wink>.
>
> What reasonable use can you propose for an associative container which allows
> mutable keys?  You might as well revert to a list of (key,value) pairs, since
> you're going to do a linear search on each lookup anyway if the keys are
> allowed to change.

If you look at any hashtable implementation for C, you'll see that the keys can
be char* (or any other mutable type for that matter).  There are really only two
requirements for the keys in an associative container (i) they must be hashable,
and (ii) they must remain unchanged for the duration of the container (or more
specifically, the hash value must remain unchanged).  It's might be nice (for a
suitable definition of nice) to have the language hold your hand through this,
but it is far from neccessary.  Sometimes it really does suffice to tell the
programmer that if he changes a key he'll get undefined behavior.

-- bjorn