[Python-ideas] PEP for enum library type?

[Alex Stewart]

On Friday, February 22, 2013 9:07:32 AM UTC-8, Andrew Barnert wrote:
>
> On Feb 21, 2013, at 15:24, Greg Ewing <greg.... at canterbury.ac.nz<javascript:>> 
> wrote: 
>
> That sounds reasonable. However, I'm wondering if there isn't a 
> > third case: where you don't care about the values, but you do 
> > want them to have a defined ordering? 
>

This is a valid point.  I think there are a lot of cases where enums are 
useful without any ordering, but there are arguably some cases where order 
would be useful (the immediate example that comes to mind is "logging 
levels", where DEBUG, INFO, and ERROR don't necessarily need to have any 
numerical meaning, but it would be nice to be able to say that DEBUG < INFO 
< ERROR)..  I think it should be possible to build this into an existing 
enum implementation which doesn't inherently rely on underlying numbers, 
though..  I'll look into it..

And a fourth case: You don't care about the values, but you want to be able 
> to | them together into a set. 
>

Heh.. I was kinda hoping nobody was going to bring this up yet :)  Good 
point, though, and FWIW, I had considered this too but didn't bring it up 
initially because I was afraid it would muddy the discussion too much too 
early.   I do however agree that this is a use case that will ultimately be 
important to support, and it's been in the back of my mind.  This actually 
applies both to the "valueless" case and the "valued" case, but in somewhat 
different ways.

As you mentioned, in the "valueless" case, the most obvious way to deal 
with this is with sets.  I think we could probably ameliorate the 
single-value case a bit by just having enum objects also behave like 
single-item sets if used with set operations (which I don't think is too 
magic), and then we can define the '|' operator to just create (or add to) 
an enum-set..

The valued case is actually more complicated, because ideally if READ = 
enum(1) and SHARED = enum(4), then saying "READ | SHARED" should produce 
something that has an int() value of the or'd values (5), but it would also 
be nice if it still represented itself symbolically (as "READ | SHARED", 
for example, instead of "5"), and though not strictly required, it would 
probably also be nice if they could be inspected using the same set-type 
operations as valueless enums/sets ("if READ in openmode", for example). 
 This would probably require some sort of new "enum-set" class/type which 
supported amalgomated valued enums, but I think it would still be doable 
without too much magic (I hope).  Then of course there's extra issues like: 
if we also support string-enums, what does 'or' mean for string constants? 
(etc, etc..)

But in summary, I think the valueless case is actually pretty easy to 
implement, but doing it well with valued-enums is much more work, which 
once again reinforces my opinion that valueless enums are useful to have, 
and preferable to use when lowlevel-type-compatibility is not explicitly 
required by some API..

--Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130222/a1ea449b/attachment.html>