1) Possibility. Python can't build a string representation for a
structure with loops, so the `make_key_a_string` idiom didn't always
work. Along with the new id() function, dicts can now (with a little
care) be indexed by anything.
2) Efficiency. Computing a string representation can be arbitrarily
expensive. E.g., consider a class instance that carries a lot of
state. Or just long integers (`longint` takes time quadratic in the
length of the string).
3) Convenience. E.g., needing to backquote integer keys was an
irritation.
> The more general solution of building an inverse dictionary may have
> much wider uses.
A random one came up the other day, while prototyping a register
assigner:
1) Given such & such a register, which expression does it currently
contain?
2) Given a specific expression, in which register(s) can it currently be
found?
Of course there are _lots_ of mappings that are interesting in both
directions, and a pair of "mirror" dicts is a pleasant way to deal with
'em.
happily y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp