Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Ethan Furman <ethan-gcWI5d7PMXnvaiG9KC9N7Q <at> public.gmane.org>
Subject: PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library
Newsgroups: gmane.comp.python.ideas
Date: Monday 11th March 2013 16:18:43 UTC (over 4 years ago)
First, I offer my apologies to all who are still battle-weary from the last
flurry of enum threads.

However, while flufl.enum (PEP 435) is a good package for the use-case it
handles, there are plenty of use-cases that it 
does not handle, or doesn't handle well, that it should not be the
implementation in the stdlib.  To quote one of my 
earlier emails:

> I'm beginning to see why enums as a class has not yet been added to
Python.
> We don't want to complicate the language with too many choices, yet there
is
> no One Obvious Enum to fit the wide variety of use-cases:
>
>   - named int enums  (http status codes)
>   - named str enums  (tkinter options)
>   - named bitmask enums  (file-type options)
>   - named valueless enums  (any random set of names)
>   - named valueless-yet-orderable enums  (any not-so-random set of names
;)

This new PEP proposes an enum module that handles all those use cases, and
makes it possible to handle others as well.

If you recognize your idea but don't see your name in acknowledgements,
please let me know.

Code is available at https://bitbucket.org/stoneleaf/aenum

--
~Ethan~

==============================================================================================
 
CD: 3ms