Merge from upstream.

pep-0373.txt

@@ -46,6 +46,13 @@ The current schedule is:
 - 2.7 rc2 2010-06-19
 - 2.7 final 2010-07-03
 
+Maintenance releases
+====================
+
+- 2.7.1 2010-11-27
+- 2.7.2 2011-07-21
+- 2.7.3rc1 2012-02-23
+
 
 Possible features for 2.7
 =========================

pep-0398.txt

@@ -79,7 +79,9 @@ Candidate PEPs:
 * PEP 382: Namespace Packages
 * PEP 395: Module Aliasing
 * PEP 397: Python launcher for Windows
+* PEP 412: Key-Sharing Dictionary
 * PEP 3143: Standard daemon process library
+* PEP 3144: IP Address manipulation library
 
 (Note that these are not accepted yet and even if they are, they might
 not be finished in time for Python 3.3.)

pep-0405.txt

@@ -8,7 +8,7 @@ Type: Standards Track
 Content-Type: text/x-rst
 Created: 13-Jun-2011
 Python-Version: 3.3
-Post-History: 24-Oct-2011, 28-Oct-2011
+Post-History: 24-Oct-2011, 28-Oct-2011, 06-Mar-2012
 
 
 Abstract

pep-0416.txt

@@ -20,9 +20,8 @@ Rationale
 =========
 
 A frozendict is a read-only mapping: a key cannot be added nor removed, and a
-key is always mapped to the same value. However, frozendict values can be
-mutable (not hashable). A frozendict is hashable and so immutable if and only
-if all values are hashable (immutable).
+key is always mapped to the same value. However, frozendict values can be not
+hashable. A frozendict is hashable if and only if all values are hashable.
 
 Use cases:
 

pep-0417.txt

@@ -0,0 +1,71 @@
+PEP: 417
+Title: Including mock in the Standard Library
+Version: $Revision$
+Last-Modified: $Date$
+Author: Michael Foord <michael@python.org>
+Status: Draft
+Type: Standards Track
+Content-Type: text/plain
+Created: 12-Mar-2012
+Python-Version: 3.3
+Post-History: 12-Mar-2012
+
+
+Abstract
+
+    This PEP proposes adding the mock [1]_  testing library
+    to the Python standard library as ``unittest.mock``.
+
+
+Rationale
+
+    Creating mock objects for testing is a common need in Python.
+    Many developers create ad-hoc mocks, as needed, in their test
+    suites. This is currently what we do in the Python test suite,
+    where a standardised mock object library would be helpful.
+    
+    There are many mock object libraries available for Python [2]_.
+    Of these, mock is overwhelmingly the most popular, with as many
+    downloads on PyPI as the other mocking libraries combined.
+    
+    An advantage of mock is that it is a mocking library and not a
+    framework. It provides a configurable and flexible mock object,
+    without being opinionated about how you write your tests. The
+    mock api is now well battle-tested and stable.
+    
+    mock also handles safely monkeypatching and unmonkeypatching
+    objects during the scope of a test. This is hard to do safely
+    and many developers / projects mimic this functionality
+    (often incorrectly). A standardised way to do this, handling
+    the complexity of patching in the presence of the descriptor
+    protocol (etc) is useful. People are asking for a "patch" [3]_
+    feature to unittest. Doing this via mock.patch is preferable
+    to re-implementing part of this functionality in unittest.
+
+
+Background
+    Addition of mock to the Python standard library was discussed
+    and agreed to at the Python Language Summit 2012.
+    
+
+References
+
+    [1] `mock library on PyPI<http://pypi.python.org/pypi/mock>`_
+    [2] http://pypi.python.org/pypi?%3Aaction=search&term=mock&submit=search
+    [3] http://bugs.python.org/issue11664
+
+
+
+Copyright
+
+    This document has been placed in the public domain.
+
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+sentence-end-double-space: t
+fill-column: 70
+coding: utf-8
+End: