homepage

Creating this as a separate issue so as not to delay incorporation of the accepted PEP.
One legitimate criticism of the accepted PEP 435 is that the combination of requiring explicit assignment of values *and* allowing aliasing by default is that aliases may be created inadvertently. I believe we can actually do better than the initial implementation by making the following work:
>>> class Shape(Enum):
... square = 2
... diamond = 1
... circle = 3
... alias_for_square = square
...
>>> Shape.square
<Shape.square: 2>
>>> Shape.alias_for_square
<Shape.square: 2>
>>> Shape(2)
<Shape.square: 2>
While *disallowing* the following: 
>>> class Shape(Enum):
... square = 2
... diamond = 1
... circle = 3
... alias_for_square = 2
...
How, do you ask? By wrapping non-descriptors on assignment in a placeholder type, and keeping track of which values we have already seen. If a new attribute is mapped to a placeholder, then that's fine, we accept it as an explicit declaration of an alias. However, if it's mapped directly to a repeat value, then that would be disallowed (as it was in earlier versions of the PEP).

This would preclude code like:
class Shape(Enum):
 rectangle = shape = 2
which seems (to me) to be the most reasonable way to express aliasing.

That's a terrible way to express aliasing, because it's really unclear that "rectangle" is the canonical name.
By contrast:
 class Shape(Enum):
 rectangle = 2
 oblong = rectangle
leaves no doubt as to which is canonical and which is the alias. You never need to go beyond two assignments, as you can still use multiple target assignment for the aliases.

Another approach to handling this, and other, issues is to allow options to EnumMeta. My original aenum code had the default Enum class as unordered, no duplicates allowed, non-indexable, etc., but then allowed options to be passed in such as DUPLICATES to allow duplicates, ORDERED to add the ge-gt-le-lt methods, INDEXED to add __index__, etc.
For the aliasing issue this method is more robust as placeholders are not required, and code like this will work:
class Physics(Enum):
 e = 2.81847
 pi = 3.141596
 tau = 2 * pi
To make that code work with placeholders is possible (I have it in aenum) but a major pain (I was about to remove it before my offer to help with ref435 was accepted).

Hmm, that's an interesting point about allowing operations on the already defined values.
You could get around that by requiring that the wrapper be explicit when definined the alias:
>>> class Shape(enum.Enum):
... rectangle = 1
... oblong = enum.alias(rectangle)
Or, equivalently:
>>> class Shape(enum.Enum):
... rectangle = 1
... oblong = enum.alias(1)
So simple typos would trigger an error by default, and the enum.alias wrapper would tell the namespace (or the metaclass) "hey, this should be an alias for another value already defined here".
I definitely don't want us to turn the metaclass into a swiss army knife of behavioural options - I'm happy with customisation hooks in the metaclass on that front, as I believe it is an effective way to discourage excessive use of metaclass magic without preventing it when it is necessary.

That's way too much magic for my taste.

Also, since we currently don't forbid the following:
>>> {'a': 1, 'a': 2}
{'a': 2}
I don't see why enums should be any different. Recommend closing.

The difference is the use case: dicts are a general purpose data store,
enums are typically for defining mutually exclusive named values, with
aliasing as a concession to practical reality.

I'm with Antoine. Trying to prevent accidental redefinition behavior like
Nick proposes feels like un-Pythonic coddling to me, and I expect we'd be
closing off some occasionally useful patterns. Please leave well enough
alone.

OK, I mainly wanted to make sure this alternative was at least considered, as I didn't see it come up during the PEP discussions.

On May 12, 2013, at 06:51 AM, Nick Coghlan wrote:
>>>> class Shape(Enum):
>... square = 2
>... diamond = 1
>... circle = 3
>... alias_for_square = square
I see Guido pronounced against it, but I'm just registering that I kind of
like this. You could probably have guess that since flufl.enum doesn't allow
aliases at all mostly because of the potential for accidental duplicate
values, which this would avoid.
Hmm. LP: #1179529

I just wanted to note that there's a trivial way to prevent accidental aliases inline or in your test suite if you don't intend them:
 class MyEnum(Enum):
 ....
 assert len(MyEnum) == len(MyEnum.__members__)