This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eli.bendersky
Recipients alex, barry, benjamin.peterson, docs@python, dstufft, eli.bendersky, ethan.furman, ezio.melotti, gvanrossum, isoschiz, ncoghlan, pconnell, python-dev, zach.ware
Date 2013-05-27.02:32:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Guido, IMHO back-doors are fine in many cases, just not this one. The way I see it, our main goal here is to collect a bunch of custom implementations of enums under a single umbrella. This is not very different from what was done with OrderedDict and namedtuple at some point. There were probably a bunch of custom implementations, along with more and less commonly used recipes. At some point a single implementation was added to the stdlib, without (AFAICS) major back-doors.

Yes, the Enum case is vastly more complex than either OrderedDict or namedtuple, and there is a multitude of different behaviors that can be anticipated (as the lengthy discussions leading to the acceptance of PEP 435 demonstrated). And yet, I was also hoping to have a single canonical implementation, so that people eventually accept it as "the one". Stdlib modules tend to win over in the long run.

The other point is that I think the implementation could be much simpler without having these back doors. As it stands now, the code is complex and hence brittle. Any change will be difficult to do because we're locked down very strictly by a set of intrusive and deep, yet externally "promised" interfaces. The same can be said, again, about OrderedDict and namedtuple, the code of which is very straightforward.

Maybe I'm blowing this out of proportions, maybe not. I'm not sure. As I said, I don't want to strongly argue about this. If both you and Nick are OK with keeping the customization mechanisms in, I defer to your judgment.
Date User Action Args
2013-05-27 02:32:40eli.benderskysetrecipients: + eli.bendersky, gvanrossum, barry, ncoghlan, benjamin.peterson, ezio.melotti, alex, docs@python, ethan.furman, python-dev, zach.ware, pconnell, dstufft, isoschiz
2013-05-27 02:32:40eli.benderskysetmessageid: <>
2013-05-27 02:32:40eli.benderskylinkissue17947 messages
2013-05-27 02:32:39eli.benderskycreate