[Python-Dev] PEP 351

[Raymond Hettinger]

[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