On 25 July 2011 18:34, Barry Warsaw
<barry@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@python.org
http://mail.python.org/mailman/listinfo/python-ideas