On Sun, Jul 24, 2011 at 9:22 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
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.
Don't worry about them being added to the language; it's just a stdlib module I'm proposing here. They do have their uses and fans, or there wouldn't be a PEP and several popular 3rd party libraries. My own reason for sometimes wanting them is that it gets old to use a lookup table from name -> string for printing, and using string values instead of integers isn't always an option. Google's protobuf also has them, as does protorpc, a Pythonic protobuf spinoff by my office mate Rafe Kaplan. -- --Guido van Rossum (python.org/~guido)