Added use cases and some of the discussed variations.

pepdraft-0435.txt

@@ -381,6 +381,87 @@ value.  If 2-tuples are used, all items must be 2-tuples::
     >>> enum.make('Flags', zip(list('abcdefg'), enumiter()))
     <Flags {a: 1, b: 2, c: 4, d: 8, e: 16, f: 32, g: 64}>
 
+Proposed variations
+===================
+
+Some variations were proposed during the discussions in the mailing list.
+Here's some of the more popular:
+
+Not having to specify values for enums
+--------------------------------------
+
+Michael Foord proposed (and Tim Delaney provided a proof-of-concept
+implementation) to use metaclass magic that makes this possible::
+
+    class Color(Enum):
+        red, green, blue
+
+The values get actually assigned only when first looked up.
+
+Pros: cleaner syntax that requires less typing for a very common task (just
+listing enumertion names without caring about the values).
+
+Cons: involves much magic in the implementation, which makes even the
+definition of such enums baffling when first seen.  Besides, explicit is better
+than implicit.
+
+Using special names or forms to auto-assign enum values
+-------------------------------------------------------
+
+A different approach to avoid specifying enum values is to use a special name
+or form to auto assign them.  For example::
+
+    class Color(Enum):
+        red = None          # auto-assigned to 0
+        green = None        # auto-assigned to 1
+        blue = None         # auto-assigned to 2
+
+More flexibly::
+
+    class Color(Enum):
+        red = 7
+        green = None        # auto-assigned to 8
+        blue = 19
+        purple = None       # auto-assigned to 20
+
+Some variations on this theme:
+
+#. A special name ``auto`` imported from the enum package.
+#. Georg Brandl proposed ellipsis (``...``) instead of ``None`` to achieve the
+   same effect.
+
+Pros: no need to manually enter values. Makes it easier to change the enum and
+extend it, especially for large enumerations.
+
+Cons: actually longer to type in many simple cases.  The argument of
+explicit vs. implicit applies here as well.
+
+Use-cases in the standard library
+=================================
+
+The Python standard library has many places where the usage of enums would be
+beneficial to replace other idioms currently used to represent them.  Such
+usages can be divided to two categories: user-code facing constants, and
+internal constants.
+
+User-code facing constants like ``os.SEEK_*``, ``socket`` module constants,
+decimal rounding modes, HTML error codes could benefit from being enums had
+they been implemented this way from the beginning.  At this point, however,
+at the risk of breaking user code (that relies on the constants' actual values
+rather than their meaning) such a change cannot be made.  This does not mean
+that future uses in the stdlib can't use an enum for defining new user-code
+facing constants.
+
+Internal constants are not seen by user code but are employed internally by
+stdlib modules.  It appears that nothing should stand in the way of
+implementing such constants with enums.  Some examples uncovered by a very
+partial skim through the stdlib: ``binhex``, ``imaplib``, ``http/client``,
+``urllib/robotparser``, ``idlelib``, ``concurrent.futures``, ``turledemo``.
+
+In addition, looking at the code of the Twisted library, there are many use
+cases for replacing internal state constants with enums.  The same can be
+said about a lot of networking code (especially implementation of protocols)
+and can be seen in test protocols written with the Tulip library as well.
 
 Differences from PEP 354
 ========================