[Python-Dev] PEP 416: Add a frozendict builtin type (original) (raw)
Guido van Rossum guido at python.org
Thu Mar 22 00:49:26 CET 2012
- Previous message: [Python-Dev] PEP 416: Add a frozendict builtin type
- Next message: [Python-Dev] PEP 416: Add a frozendict builtin type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To close the loop, I've rejected the PEP, adding the following rejection notice:
""" I'm rejecting this PEP. A number of reasons (not exhaustive):
- According to Raymond Hettinger, use of frozendict is low. Those that do use it tend to use it as a hint only, such as declaring global or class-level "constants": they aren't really immutable, since anyone can still assign to the name.
- There are existing idioms for avoiding mutable default values.
- The potential of optimizing code using frozendict in PyPy is unsure; a lot of other things would have to change first. The same holds for compile-time lookups in general.
- Multiple threads can agree by convention not to mutate a shared dict, there's no great need for enforcement. Multiple processes can't share dicts.
- Adding a security sandbox written in Python, even with a limited scope, is frowned upon by many, due to the inherent difficulty with ever proving that the sandbox is actually secure. Because of this we won't be adding one to the stdlib any time soon, so this use case falls outside the scope of a PEP.
On the other hand, exposing the existing read-only dict proxy as a built-in type sounds good to me. (It would need to be changed to allow calling the constructor.) """
-- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-Dev] PEP 416: Add a frozendict builtin type
- Next message: [Python-Dev] PEP 416: Add a frozendict builtin type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]