[Python-checkins] peps: Added use cases and some of the discussed variations.

eli.bendersky python-checkins at python.org
Sun Feb 24 15:33:00 CET 2013


http://hg.python.org/peps/rev/3754faa001f4
changeset:   4771:3754faa001f4
user:        Eli Bendersky <eliben at gmail.com>
date:        Sun Feb 24 06:32:40 2013 -0800
summary:
  Added use cases and some of the discussed variations.

files:
  pepdraft-0435.txt |  81 +++++++++++++++++++++++++++++++++++
  1 files changed, 81 insertions(+), 0 deletions(-)


diff --git a/pepdraft-0435.txt b/pepdraft-0435.txt
--- a/pepdraft-0435.txt
+++ b/pepdraft-0435.txt
@@ -381,6 +381,87 @@
     >>> 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
 ========================

-- 
Repository URL: http://hg.python.org/peps


More information about the Python-checkins mailing list