[Python-ideas] Enums

[Guido van Rossum]

On Sun, Jul 24, 2011 at 9:22 PM, Raymond Hettinger
<raymond.hettinger at 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 at 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)