[Python-ideas] Enums

[Michael Foord]

On 25 July 2011 18:34, Barry Warsaw <barry at python.org> wrote:

> On Jul 25, 2011, at 05:46 PM, Michael Foord wrote:
>
> >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
> >effort.
> >
> >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).
>
> I'm not sure it would be a good idea to do a mass mechanical substitution
> in
> the stdlib, so I'm not concerned that adopting enums would require a few
> int()
> calls to be added.
>
>
Well, if it isn't good enough for *us* then who is it good enough for? ;-)

Some apis (for example those exported directly from C) can't work with
something that isn't a real int.



> I've so far resisted the occasional suggestion to make enum values int
> subclasses, because I think enum values should not *be* ints, but should be
> compatible with ints (as they are now).  Ordered comparisons of enum values
> bothers me. ;)
>
> >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
> >repr.
>
> Hmm.  Of course ORing the enum values' int representation is trivial; you
> just
> have to pick the right values when you create the class.  I'd be interested
> to
> see some specific examples for something more direct you have in mind.
> (Perhaps as a merge proposal <wink>.)
>

Well:

>>> from flufl.enum import Enum
>>> class Thing(Enum):
...  a = 1
...  b = 2
...  c = 4
...
>>> Thing.a | Thing.b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'EnumValue' and 'EnumValue'



>
> >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.
>
> I think it would be usable in the stdlib today, but I'd like to see
> specific
> examples of how you think the API needs to be changed.  Making enum values
> ints and supporting ordered comparisons is a big difference IMO.
>
>
Sure, I have no use case for ordering enums... I'm not sure I have a
specific reason to *prevent* if that is extra work though.

Michael


> Cheers,
> -Barry
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>


-- 

http://www.voidspace.org.uk/

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/016bf645/attachment.html>