[Python-Dev] PEP 351 (original) (raw)

Raymond Hettinger 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 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)).

More information about the Python-Dev mailing list