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

Noam Raphael noamraph at gmail.com
Sun Feb 12 00:15:12 CET 2006


Hello,

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, and I think that it can be done elegantly, without the concrete problems that Raymond pointed. I didn't work on it in the last few weeks, because of my job, but I hope to come back to it soon and post a PEP and a reference implementation in CPython.

My quick responses, mostly to try to convince that I know a bit about what I'm talking about:

First about the last point: I suggest that the function will be named frozen(x), which suggests that nothing happens to x, you only get a "frozen x". I suggest that this operation won't be called "freezing x", but "making a frozen copy of x".

Now, along with the original order. Frozen dicts - if you want, you can decide that dicts aren't frozenable, and that's ok. But if you do want to make frozen copies of dicts, it isn't really such a problem - it's similar to hashing a tuple, which requires recursive hashing of all its elements; for making a frozen copy of a dict, you make a frozen copy of all its values.

Treating all containers polymorphically - I don't suggest that. In my suggestion, you may have frozen lists, frozen tuples (which are normal tuples with frozen elements), frozen sets and frozen dicts.

Treating tuples as frozen lists - I don't suggest to do that. But if my suggestion is accepted, there would be no need for tuples - frozen lists would be just as useful.

And about the other concerns:

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.

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.

To summarize, I see the faults in PEP 351. I think that another, fairly similar idea might be a good one.

Have a good week, Noam



More information about the Python-Dev mailing list