From 5483903c9f240130f660301322a9b70eb9f1c420 Mon Sep 17 00:00:00 2001
From: Guido van Rossum <guido@google.com>
Date: Wed, 21 Mar 2012 16:47:27 -0700
Subject: [PATCH] Reject PEP 416 (frozendict) with reasons why.

---
 pep-0416.txt | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/pep-0416.txt b/pep-0416.txt
index 7e236bf76..9d5892dc5 100644
--- a/pep-0416.txt
+++ b/pep-0416.txt
@@ -3,13 +3,40 @@ Title: Add a frozendict builtin type
 Version: $Revision$
 Last-Modified: $Date$
 Author: Victor Stinner <victor.stinner@gmail.com>
-Status: Draft
+Status: Rejected
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 29-February-2012
 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
 ========
 
@@ -26,7 +53,8 @@ hashable. A frozendict is hashable if and only if all values are hashable.
 Use cases:
 
  * 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.
    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