lambda

[Antoon Pardon]

Op 2005-01-17, Just schreef <just at xs4all.nl>:
> In article <slrncunk89.36o.apardon at rcpc42.vub.ac.be>,
>  Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>
>> >> I don't see a big difference between these principles
>> >> and the hash key principle,
>> >
>> > Than you haven't looked hard enough.
>> 
>> All of these can get unexpected behaviour because of the
>> assignment-doesn't-copy semantics. The same semantics
>> that can cause problems if you work with mutable dictionary
>> keys.
>
> Again, the difference is:
>
>   1. assigning mutable objects *can* cause unexpected behavior
>      (however, it's a useful feature, everyone using Python
>      for longer than a day or two knows this, and then it's
>      *expected* behavior.
>
>   2. mutating dict keys *does* *always* cause problems.
>      (unless you use an identity hash/cmp)

3 mutating an item in a sorted list *does* *always* cause problems

4 mutating an item in a heap queue *does* *always* cause problems

> It's nonsense to forbid 1) since it's a useful feature. It's useful to 
> forbid ("discourage") 2) since mutating dict keys is seldom useful (and 
> when it is, Python lets you support it in your own objects).

Yes mutating dict keys is seldom usefull. But again you are conflating
mutable dict keys with mutating dict keys. No mutables as dict keys
means you can't mutate the object even if it is not a key. But whether
assigning mutable objects is usefull or not doesn't depend on whether
the object will also be usefull as a key or not. You treat this as
if an obejct is always a key or never and then decide mutable objects
as dict keys is not usefull because mutating keys is not usefull.

More specific the Decimal class is mutable and usable as dict key.

-- 
Antoon Pardon