[Python-Dev] PEP 351

[Raymond Hettinger]

----- Original Message ----- 
From: "Alex Martelli" <aleaxit at gmail.com>
To: "Raymond Hettinger" <python at rcn.com>
Cc: <python-dev at python.org>
Sent: Saturday, February 11, 2006 3:55 PM
Subject: PEP 351


>
> On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
>
>> [Guido van Rossum]
>>> PEP 351 - freeze protocol. I'm personally -1; I don't like the  idea of
>>> freezing arbitrary mutable data structures. Are there champions who
>>> want to argue this?
>>
>> It has at least one anti-champion.  I think it is a horrible idea  and 
>> would
>> like to see it rejected in a way that brings finality.  If needed,  I can
>> elaborate in a separate thread.
>
> Could you please do that?  I'd like to understand all of your  objections. 
> Thanks!

Here was one email on the subject:
      http://mail.python.org/pipermail/python-dev/2005-October/057586.html

I have a number of comp.lang.python posts on the subject also.

The presence of frozenset() tempts this sort of hypergeneralization.  The 
first stumbling block comes with dictionaries.  Even if you skip past the 
question of why you would want to freeze a dictionary (do you really want to 
use it as a key?), one find that dicts are not naturally freezable -- dicts 
compare using both keys and values; hence, if you want to hash a dict, you 
need to hash both the keys and values, which means that the values have to 
be hashable, a new and suprising requirement -- also, the values cannot be 
mutated or else an equality comparison will fail when search for a frozen 
dict that has been used as a key.  One person who experimented with an 
implementation dealt with the problem by recursively freezing all the 
components (perhaps one of the dict's values is another dict which then 
needs to be frozen too).  Executive summary:  freezing dicts is a can of 
worms and not especially useful.

Another thought is that PEP 351 reflects a world view of wanting to treat 
all containers polymorphically.  I would suggest that they aren't designed 
that way (i.e. you use different methods to add elements to lists, dicts, 
and sets).  Also, it is not especially useful to shovel around mutable 
containers without respect to their type.  Further, even if they were 
polymorphic and freezable, treating them generically is likely to reflect 
bad design -- the soul of good programming is the correct choice of 
appropriate data structures.

Another PEP 351 world view is that tuples can serve as frozenlists; however, 
that view represents a Liskov violation (tuples don't support the same 
methods).  This idea resurfaces and has be shot down again every few months.

More important than all of the above is the thought that auto-freezing is 
like a bad C macro, it makes too much implicit and hides too much -- the 
supported methods change, there is a issue keeping in sync with the 
non-frozen original, etc.

In my experience with frozensets, I've learned that freezing is not an 
incidental downstream effect; instead, it is an intentional, essential part 
of the design and needs to be explicit.

If more is needed on the subject, I'll hunt down my old posts and organize 
them.  I hope we don't offer a freeze() builtin.  If it is there, it will be 
tempting to use it and I think it will steer people away from good design 
and have a net harmful effect.


Raymond

P.S.  The word "freezing" is itself misleading because it suggests an 
in-place change.  However, it really means that a new object is created 
(just like tuple(somelist)).