[Python-ideas] Enums

Michael Foord fuzzyman at gmail.com
Mon Jul 25 18:46:22 CEST 2011

On 25 July 2011 01:33, Guido van Rossum <guido at python.org> wrote:

> On Sun, Jul 24, 2011 at 3:47 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > We've actually been down the 'namespace object' road years ago (Steve
> > Bethard even wrote a proto-PEP IIRC) and it suffered the same fate as
> > most enum PEPs: everyone has slightly different ideas on what should
> > be supported, so you end up being faced with one of two options:
> > 1. Ignore some of the use cases (so some users still have to do their own
> thing)
> > 2. Support all of the use cases by increasing the API complexity (so
> > many users will still do their own thing instead of learning the new
> > API)
> For enums, I think we should just pick a solution. I'm in favor of
> Barry Warsaw's version, flufl.enum.

I generally like the flufl.enum API. There are two things it doesn't do.

For new apis it is *usually* possible to just use strings rather than
integers - and have your library do the mapping if an underlying api takes
integers. For existing ones, for example many parts of the python standard
library, we couldn't replace the integer values with enums without a lot of

If the flufl enums subclassed integer then replacing most of the existing
constants in the standard library would be trivially easy (so we'd have a
built-in use case).
The second use case, where you really do want to use integers rather than
strings, is where you have flag constants that you "or" together. For
example in the standard library we have these in r, gzip, msilib, some in
xml.dom.NodeFilter, plus a bunch of others.

It would be nice to add support for or'ing of enums whilst retaining a nice

I did collect a whole lot of emails from a thread last year and was hoping
to put a pep together. I'd support flufl.enum - but it would be better if it
was extended so we could use it in the standard library.

All the best,

Michael Foord

> --
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110725/15d118bc/attachment.html>

More information about the Python-ideas mailing list