![](https://secure.gravatar.com/avatar/60cac87fb9e2b5689242622999656cb0.jpg?s=120&d=mm&r=g)
On Jul 24, 2011, at 6:19 PM, Jack Diederich wrote:
On Sun, Jul 24, 2011 at 8:33 PM, Guido van Rossum <guido@python.org> wrote:
For enums, I think we should just pick a solution. I'm in favor of Barry Warsaw's version, flufl.enum.
I don't care for enums but enough other people do that I wouldn't mind including a blessed implemenation.
I also don't care for enums and recommend against adding them to the language. IMO, it is something that makes good sense in statically compiled languages and is unnecessary for us. Not to mention, we already have several ways to do it (module and class namespaces for example). Also, when this idea came up in the past, it tended to get shot down because the various use cases suggested differing implementations with different features. I also urge caution because Python has already stopped being a small language. Enums are especially problematic because they will pop up everywhere. You won't have the option of ignoring them. Python has achieved an amazing adoption rate without enums. Most people just don't need them. Many, large and clean apps have been built without them. Those that have found did were typically able to implement them easily with the existing toolset. Raymond