Updated PEP 435 with some in-line motivations, and some general cleanup.

Marked PEP 354 as superseded by PEP 435.

pep-0354.txt

@@ -3,12 +3,13 @@ Title:          Enumerations in Python
 Version:        $Revision$
 Last-Modified:  $Date$
 Author:         Ben Finney <ben+python@benfinney.id.au>
-Status:         Rejected
+Status:         Superseded
 Type:           Standards Track
 Content-Type:   text/x-rst
 Created:        20-Dec-2005
 Python-Version: 2.6
 Post-History:   20-Dec-2005
+Superseded-By:  435
 
 
 Rejection Notice
@@ -21,6 +22,8 @@ modules.  Also, the PEP has generated no widespread interest.  For
 those who need enumerations, there are cookbook recipes and PyPI
 packages that meet these needs.
 
+*Note: this PEP was superseded by PEP 435, which has been accepted in
+May 2013.*
 
 Abstract
 ========

pep-0435.txt

@@ -54,6 +54,8 @@ Guido has pronounced a decision on this issue [5]_, as well as related issues
 of not allowing to subclass enums [6]_, unless they define no enumeration
 members [7]_.
 
+The PEP was accepted by Guido on May 10th, 2013 [1]_.
+
 
 Motivation
 ==========
@@ -216,7 +218,7 @@ aliases::
 
     >>> for name, member in Shape.__members__.items():
     ...   name, member
-    ... 
+    ...
     ('square', <Shape.square: 2>)
     ('diamond', <Shape.diamond: 1>)
     ('circle', <Shape.circle: 3>)
@@ -579,29 +581,34 @@ Ben Finney is the author of the earlier enumeration PEP 354.
 References
 ==========
 
-.. [1] Placeholder for pronouncement
+.. [1] http://mail.python.org/pipermail/python-dev/2013-May/126112.html
 .. [2] http://www.python.org/dev/peps/pep-0354/
 .. [3] http://mail.python.org/pipermail/python-ideas/2013-January/019003.html
 .. [4] http://mail.python.org/pipermail/python-ideas/2013-February/019373.html
-.. [5] http://mail.python.org/pipermail/python-dev/2013-April/125687.html
-.. [6] http://mail.python.org/pipermail/python-dev/2013-April/125716.html
-.. [7] http://mail.python.org/pipermail/python-dev/2013-May/125859.html
+.. [5] To make enums behave similarly to Python classes like bool, and
+       behave in a more intuitive way.  It would be surprising if the type of
+       ``Color.red`` would not be ``Color``. (Discussion in
+       http://mail.python.org/pipermail/python-dev/2013-April/125687.html)
+.. [6] Subclassing enums and adding new members creates an unresolvable
+       situation; on one hand ``MoreColor.red`` and ``Color.red`` should
+       not be the same object, and on the other ``isinstance`` checks become
+       confusing if they are not.  The discussion also links to Stack Overflow
+       discussions that make additional arguments.
+       (http://mail.python.org/pipermail/python-dev/2013-April/125716.html)
+.. [7] It may be useful to have a class defining some behavior (methods, with
+       no actual enumeration members) mixed into an enum, and this would not
+       create the problem discussed in [6]_.  (Discussion in
+       http://mail.python.org/pipermail/python-dev/2013-May/125859.html)
 .. [8] http://pythonhosted.org/flufl.enum/
 .. [9] http://docs.python.org/3/howto/descriptor.html
 
+
 Copyright
 =========
 
 This document has been placed in the public domain.
 
 
-Todo
-====
-
-* Mark PEP 354 "superseded by" this one, if accepted
-* In docs: describe the detailed extension API (i.e. __new__). Also describe
-  the problem with pickling of functional API in more detail.
-
 ..
    Local Variables:
    mode: indented-text