[Python-Dev] PEP 351
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