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

Raymond Hettinger raymond.hettinger at verizon.net
Sun Feb 12 03:49:47 CET 2006

[Noam]

I just wanted to say this: you can reject PEP 351, please don't reject the idea of frozen objects completely. I'm working on an idea similar to that of the PEP, . . . I think these concerns can only be judged given a real suggestion, along with an implementation. I have already implemented most of my idea in CPython, and I think it's elegant and doesn't cause problems. Of course, I may not be objective about the subject, but I only ask to wait for the real suggestion before dropping it down

I was afraid of this -- the freezing concept is a poison that will cause some good minds to waste a good deal of their time. Once frozensets were introduced, it was like lighting a flame drawing moths to their doom. At first, it seems like such a natural, obvious extension to generically freeze anything that is mutable. People exploring it seem to lose sight of motivating use cases and get progressively turned around. It doesn't take long to suddenly start thinking it is a good idea to have mutable strings, to recursively freeze components of a dictionary, to introduce further list/tuple variants, etc. Perhaps a consistent solution can be found, but it no longer resembles Python; rather, it is a new language, one that is not grounded in real-world use cases. Worse, I think a frozen() built-in would be hazardous to users, drawing them away from better solutions to their problems.

Expect writing and defending a PEP to consume a month of your life. Before devoting more of your valuable time, here's a checklist of questions to ask yourself (sort of a mid-project self-assessment and reality check):

  1. It is already possible to turn many objects into key strings -- perhaps by marshaling, pickling, or making a custom repr such as repr(sorted(mydict.items())). Have you ever had occasion to use this? IOW, have you ever really needed to use a dictionary as a key to another dictionary? Has there been any clamor for a frozendict(), not as a toy recipe but as a real user need that cannot be met by other Python techniques? If the answer is no, it should be a hint that a generalized freezing protocol will rot in the basement.

  2. Before introducing a generalized freezing protocol, wouldn't it make sense to write a third-party extension for just frozendicts, just to see if anyone can possibly make productive use of it? One clue would be to search for code that exercises the existing code in dict.eq(). If you rarely have occasion to compare dicts, then it is certainly even more rare to want to be able to hash them. If not, then is this project being pursued because it is interesting or because there's a burning need that hasn't surfaced before?

  3. Does working out the idea entail recursive freezing of a dictionary? Does that impose limits on generality (you can freeze some dicts but not others)? Does working out the idea lead you to mutable strings? If so, don't count on Guido's support..

  4. Leaving reality behind (meaning actual problems that aren't readily solvable with the existing language), try to contrive some hypothetical use cases? Any there any that are not readily met by the simple recipe in the earlier email: http://mail.python.org/pipermail/python-dev/2005-October/057586.html ?

  5. How extensively does the rest of Python have to change to support the new built-in. If the patch ends-up touching many objects and introducing new rules, then the payoff needs to be pretty darned good. I presume that for frozen(x) to work a lot of types have to be modified. Python seems to fare quite well without frozendicts and frozenlists, so do we need to introduce them just to make the new frozen() built-in work with more than just sets?

Raymond

More information about the Python-Dev mailing list