[Python-Dev] PEP 351
python at rcn.com
Sat Feb 11 23:04:43 CET 2006
----- 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
>> 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.
Here was one email on the subject:
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.
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)).
More information about the Python-Dev