[Python-Dev] Add a frozendict builtin type (original) (raw)
Guido van Rossum guido at python.org
Thu Mar 1 19:07:20 CET 2012
- Previous message: [Python-Dev] Add a frozendict builtin type
- Next message: [Python-Dev] Add a frozendict builtin type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Mar 1, 2012 at 9:44 AM, Victor Stinner <victor.stinner at gmail.com> wrote:
frozendict would help pysandbox but also any security Python module, not security, but also (many) other use cases ;-)
Well, let's focus on the other use cases, because to me the sandbox use case is too controversial (never mind how confident you are :-).
I like thinking through the cache use case a bit more, since this is a common pattern. But I think it would be sufficient there to prevent accidental modification, so it should be sufficient to have a dict subclass that overrides the various mutating methods: setitem, delitem, pop(), popitem(), clear(), setdefault(), update(). Technically also init() -- although calling init() on an existing object can hardly be called an accident. As was pointed out this is easy to circumvent, but (together with a reminder in the documentation) should be sufficient to avoid mistakes. I imagine someone who actively wants to mess with the cache can probably also reach into the cache implementation directly.
Also don't underestimate the speed of a shallow dict copy.
What other use cases are there? (I have to agree with the folks pushing back hard. Even demonstrated repeated requests for a certain feature do not prove a need -- it's quite common for people who are trying to deal with some problem to go down the wrong rabbit hole in their quest for a solution, and ending up thinking they need a certain feature while completely overlooking a much simpler solution.)
-- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-Dev] Add a frozendict builtin type
- Next message: [Python-Dev] Add a frozendict builtin type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]