
On Wednesday 29 February 2012 20:17:05 Raymond Hettinger wrote:
On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
A frozendict type is a common request from users and there are various implementations.
ISTM, this request is never from someone who has a use case. Instead, it almost always comes from "completers", people who see that we have a frozenset type and think the core devs missed the ObviousThingToDo(tm). Frozendicts are trivial to implement, so that is why there are various implementations (i.e. the implementations are more fun to write than they are to use).
The frozenset type covers a niche case that is nice-to-have but *rarely* used. Many experienced Python users simply forget that we have a frozenset type. We don't get bug reports or feature requests about the type. When I do Python consulting work, I never see it in a client's codebase. It does occasionally get discussed in questions on StackOverflow but rarely gets offered as an answer (typically on variants of the "how do you make a set-of-sets" question). If Google's codesearch were still alive, we could add another datapoint showing how infrequently this type is used.
Here are my real-world use cases. Not for security, but for safety and performance reasons (I've built by own RODict and ROList modeled after dictproxy): - Global, but immutable containers, e.g. as class members - Caching. My data container objects (say, resultsets from a db or something) usually inherit from list or dict (sometimes also set) and are cached heavily. In order to ensure that they are not modified (accidentially), I have to choices: deepcopy or immutability. deepcopy is so expensive, that it's often cheaper to just leave out the cache. So I use immutability. (oh well, the objects are further restricted with __slots__) I agree, these are not general purpose issues, but they are not *rare*, I'd think. nd