Reject PEP 416 (frozendict) with reasons why.
This commit is contained in:
parent
7c225bd154
commit
5483903c9f
32
pep-0416.txt
32
pep-0416.txt
|
@ -3,13 +3,40 @@ Title: Add a frozendict builtin type
|
||||||
Version: $Revision$
|
Version: $Revision$
|
||||||
Last-Modified: $Date$
|
Last-Modified: $Date$
|
||||||
Author: Victor Stinner <victor.stinner@gmail.com>
|
Author: Victor Stinner <victor.stinner@gmail.com>
|
||||||
Status: Draft
|
Status: Rejected
|
||||||
Type: Standards Track
|
Type: Standards Track
|
||||||
Content-Type: text/x-rst
|
Content-Type: text/x-rst
|
||||||
Created: 29-February-2012
|
Created: 29-February-2012
|
||||||
Python-Version: 3.3
|
Python-Version: 3.3
|
||||||
|
|
||||||
|
|
||||||
|
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.)
|
||||||
|
|
||||||
|
|
||||||
Abstract
|
Abstract
|
||||||
========
|
========
|
||||||
|
|
||||||
|
@ -26,7 +53,8 @@ hashable. A frozendict is hashable if and only if all values are hashable.
|
||||||
Use cases:
|
Use cases:
|
||||||
|
|
||||||
* Immutable global variable like a default configuration.
|
* Immutable global variable like a default configuration.
|
||||||
* Default value of a function parameter. Avoid the issue of mutable default arguments.
|
* Default value of a function parameter. Avoid the issue of mutable default
|
||||||
|
arguments.
|
||||||
* Implement a cache: frozendict can be used to store function keywords.
|
* Implement a cache: frozendict can be used to store function keywords.
|
||||||
frozendict can be used as a key of a mapping or as a member of set.
|
frozendict can be used as a key of a mapping or as a member of set.
|
||||||
* frozendict avoids the need of a lock when the frozendict is shared
|
* frozendict avoids the need of a lock when the frozendict is shared
|
||||||
|
|
Loading…
Reference in New Issue