On Fri, Sep 13, 2013 at 7:11 PM, Nick Coghlan <report@bugs.python.org>wrote:

>
> Nick Coghlan added the comment:
>
> +1 from me to just allow the names to be overwritten, even by another enum
> member.
>

Even though I was in favor of this in the initial discussions (obviously,
as I'm generally in favor of Enum being less magic and special) and had to
agree with the consensus, I think it's too late now - unless we want to
reopen the pandora box. Otherwise, it would not be fair, IMHO. In the
original discussions a lot of people gave their opinions and had the
context to chime in - now changing this "quietly" in the bug tracker with
only a handful of participants isn't appropriate.

The current behavior is fine, I think. The vast majority of enums will not
have methods, and some amount of safety against typos in member definitions
makes sense. Methods have other rules anyway (such as being definable in
subclasses), and since their uses are rarer and arguably more deliberate,
leaving them with more a Pythonic nature should be fine. This behavior is
documented in the PEP and documentation and is fairly well understood.
Also, we can always lift restrictions later without breaking existing code,
if it's deemed that some restrictions are too much.