Op 2005-01-20, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> I missed that you would use it with the idiom: dct[x.frozen()]
>
> The list itself isn't hashable with this approach, so you don't have much 
> choice. I wasn't particularly clear about that point, though.
>
>> I have two problems with this approach.
>> 
>> 1) It doesn't work when you get your keys via the keys/items
>>    methods.
>
> True - the frozen object has no link back to the original object. That could 
> be 
> added though (by returning a tuple subtype with the extra attribute)
>
>> 2) This is rather minor, but a user could still unfreeze
>>    untimely 
>
> True - doing that is less likely than mutating a hashable list though :)
>
> I'm just noting this as a way to avoid copying data more than once when 
> storing 
> immutable copies of mutable data in a dictionary. You're quite right that 
> there 
> isn't a really clean idiom for doing that in Python (aside from moving to a 
> different data structure that works natively as a dict key, naturally).

The problem here is IMO is the, we are all consenting adults (which we
are not but I wont start on this now), approach.

I have been thinking a bit in your freeze direction, but more thorough.
The idea i had was that freeze would replace all mutating methods
with methods that would throw an exception. a thaw method would inverse
the proces. It would then be the responsibilty of the dictionary to
freeze an object on entry and thaw it when removed. However this
wouldn't work with ordinary python objects, since there is no easy way
to have readonly or private variables.

-- 
Antoon Pardon
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to