Add a mention of IntEnum, summarizing the language summit and later discussions

on the subject.

Note that this is still in draft stage and decisions can change (and have
changed more than once over the past few days).
This commit is contained in:
Eli Bendersky 2013-03-15 07:25:45 -07:00
parent 170a8f61e1
commit d99232e4df
1 changed files with 65 additions and 7 deletions

View File

@ -34,9 +34,25 @@ The idea of adding an enum type to Python is not new - PEP 354 [2]_ is a
previous attempt that was rejected in 2005. Recently a new set of discussions
was initiated [3]_ on the ``python-ideas`` mailing list. Many new ideas were
proposed in several threads; after a lengthy discussion Guido proposed adding
``flufl.enum`` to the standard library [4]_. This PEP is an attempt to
formalize this decision as well as discuss a number of variations that can be
considered for inclusion.
``flufl.enum`` to the standard library [4]_. During the PyCon 2013 language
summit the issue was discussed further. It became clear that many developers
want to see an enum that subclasses ``int``, which can allow us to replace
many integer constants in the standard library by enums with friendly string
representations, without ceding backwards compatibility. An additional
discussion among several interested core developers led to the proposal of
having ``IntEnum`` as a special case of ``Enum``.
The key dividing issue between ``Enum`` and ``IntEnum`` is whether comparing
to integers is semantically meaningful. For most uses of enumerations, it's
a **feature** to reject comparison to integers; enums that compare to integers
lead, through transitivity, to comparisons between enums of unrelated types,
which isn't desirable in most cases. For some uses, however, greater
interoperatiliby with integers is desired. For instance, this is the case for
replacing existing standard library constants (such as ``socket.AF_INET``)
with enumerations.
This PEP is an attempt to formalize this decision as well as discuss a number
of variations that were discussed and can be considered for inclusion.
Motivation
@ -153,9 +169,9 @@ same named values in the derived class::
>>> Colors.blue is MoreColors.blue
True
However, these are not doing comparisons against the integer equivalent
values, because if you define an enumeration with similar item names and
integer values, they will not be identical::
However, these are not doing comparisons against the integer equivalent values,
because if you define an enumeration with similar item names and integer values,
they will not be identical::
>>> class OtherColors(Enum):
... red = 1
@ -174,7 +190,7 @@ These enumeration values are not equal, nor do they hash equally::
2
Ordered comparisons between enumeration values are *not* supported. Enums are
not integers::
not integers (but see ``IntEnum`` below)::
>>> Colors.red < Colors.blue
Traceback (most recent call last):
@ -342,6 +358,48 @@ Enumeration values are hashable, so they can be used in dictionaries and sets::
green -> granny smith
IntEnum
-------
A variation of ``Enum`` is proposed that also subclasses ``int`` - ``IntEnum``.
Such enumerations behave much more similarly to integers. In particular, they
can be compared to integers; by extensions, enumerations of different types can
also be compared to each other::
>>> from enum import IntEnum
>>> class Shape(IntEnum):
... circle = 1
... square = 2
...
>>> class Request(IntEnum):
... post = 1
... get = 2
...
>>> Shape == 1
False
>>> Shape.circle == 1
True
>>> Shape.circle == Request.post
True
However they still can't be compared to ``Enum``::
>>> from enum import Enum, IntEnum
>>> class Shape(IntEnum):
... circle = 1
... square = 2
...
>>> class Colors(Enum):
... red = 1
... green = 2
...
>>> Shape.circle == Colors.red
False
For the vast majority of code, ``Enum`` is recommended. Only if a greater
degree of interoperatility with integers is required and ``Enum`` does not
fit the bill, ``IntEnum`` should be used.
Pickling
--------