On Thursday, February 21, 2013 11:54:49 AM UTC-8, Joao S. O. Bueno wrote:

4. They should subclass INTs in way it is possible to interact with low level libraries already using C Enums (only aplicable to those that need an int value) - their use should be as transparent as True and False are today.

Ok, I can see that would be a desirable trait (and personally I'm with you on that one), though I'm not sure it really qualifies as "required" (there are potential uses for int-enums which would still be useful/valid even if it couldn't do that automatically), but I'll definitely add that to my "desirable" list..

...

1. Enums should represent themselves (str/repr) by symbolic names, not as ints, etc. I would say that, while not "required", as low level languages lack this, the whole idea is simply not worth implementing without this. This is the real motivation - and NB. also for "Constants", not only "Enums".

Frankly, I think this one is so easy it's really not worth fussing about that much. It's pretty much a given that any solution we come up with will have this functionality anyway..

2. Enums from different groups should preferably not compare equal to each

other (even if they have the same associated int value). I am not shure about this requirement. I agree about "valueless" Enums, but as far as they have values associated, they should behave just like their values. I did not hear of anyone injured by " True == 1" in Python.

Well, it's explicitly not a requirement (that's why it's under "desirable" instead of "required"). Here's the question, though: Do you believe if a solution was proposed which had this property it would be a bad thing? Note that this isn't really exactly the same as the "True == 1" case. In my opinion the argument in favor of this is along the lines of: class FooOptions (Enum): YES = 1 MAYBE = 2 NO = 3 class BarOptions (Enum): NO = 1 MAYBE = 2 YES = 3 def foofunc(choice): if choice == FooOptions.YES: do_something() Now what if somebody calls foofunc(BarOptions.NO)? Admittedly, this is a somewhat exaggerated case, but I still think it would be better if in these sorts of cases FooOptions.YES != BarOptions.NO (if one explicitly did want to test if the values were the same (regardless of enum type) they could do something like "if int(choice) == FooOptions.YES" instead) --Alex

On 2013-02-21 23:24, Greg Ewing wrote:

On 22/02/13 08:18, Alex Stewart wrote:

...

In non-Python code, typically enums have always been represented under the covers as ints, and therefore must be passed back and forth as numbers. The fact that they have an integer value, however, is purely an implementation artifact. It comes from the fact that C and some other languages don't have a rich enough type system to properly make enums their own distinct type

I don't think that's true for all languages. For example, enums in Pascal are definitely distinct types from integers, yet the language explicitly assigns them ordinal values and defines an ordering for them. Wirth must have thought there was a benefit in doing that.

[snip] It means that sets of enums can be implemented using bitsets.

On 21/02/2013 23:24, Greg Ewing wrote:

On 22/02/13 08:18, Alex Stewart wrote:

...

In non-Python code, typically enums have always been represented under the covers as ints, and therefore must be passed back and forth as numbers. The fact that they have an integer value, however, is purely an implementation artifact. It comes from the fact that C and some other languages don't have a rich enough type system to properly make enums their own distinct type

I don't think that's true for all languages. For example, enums in Pascal are definitely distinct types from integers, yet the language explicitly assigns them ordinal values and defines an ordering for them. Wirth must have thought there was a benefit in doing that.

Not necessarily. With respect to the great man, he may not have given the matter as much thought, or considered (or been interested in) as many use cases as the contributors to this thread have.

...

It doesn't seem unreasonable, therefore, to define two different categories of enums: one that has no concept of "value" (for pure-Python), and one which does have associated values but all values have to be specified explicitly

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? The same thought occurred to me, although I could not think of a use case on the spot. But I think that there surely are such.

...

1. Enum syntax should not be "too magic". (In particular, it's pretty clear at this point that creating new enums as a side-effect of name lookups (even as convenient as it does make the syntax) is ultimately not gonna fly)

...

4. It shouldn't be necessary to quote enum names when defining them (since they won't be quoted when they're used)

Satisfying both of these constraints without new syntax seems to be pretty much impossible. That seems to be the main sticking point in these discussions.

...

I want to check: Is this a valid summary of things?

It looks pretty comprehensive to me!

Apart from the point about maybe wanting to order enums, I agree. I think Alex is right when he says you want to create singleton enums that don't equate to anything else. We don't think of RED, GREEN, BLUE as being identical with the ints 1,2,3, and so don't want our implementation of them to compare equal to those ints. Rob Cliffe

On 21 February 2013 22:58, Rob Cliffe wrote:

Apart from the point about maybe wanting to order enums, I agree. I think Alex is right when he says you want to create singleton enums that don't equate to anything else. We don't think of RED, GREEN, BLUE as being identical with the ints 1,2,3, and so don't want our implementation of them to compare equal to those ints.

Again, I thinnkt hat my 2002 code that expected a (1) working when it got a (True) instead was a great, great thing. And I think that lots of places where magical strings today ("str.decode" errors argument, "compile" mode argument) should be lifted up to expect constants and still keep working if one pass them the strings "replace" or "eval". Requiring that things compare differently, IMHO, is too much statically-typed-minded - it is not the way of Python. As for Alex's surreal example of someone defining "NO" and "YES" with different values in different Enums and passing the wrong one to a given call - this person will have it comming. Think of this case instead:

...

...

disk_io.IDDLE == "iddle" True network.IDDLE == "iddle" True disk_io.IDDLE == network.IDDLE False

So, if the compared enums do have an explicit value assigned to them (and I agree there are some cases the value is not needed) , they should compare just as that value - anything else is more close to C++ than Python. And no one is preventing people from using decorators or use other mecanisms for certain function calls to accept only values of a given Enum, just as no one ever was prohibited from statically verifying any other values in a call.

On 22 February 2013 15:21, Alex Stewart wrote:

On Friday, February 22, 2013 4:53:27 AM UTC-8, Joao S. O. Bueno wrote:

...

Again, I thinnkt hat my 2002 code that expected a (1) working when it got a (True) instead was a great, great thing. And I think that lots of places where magical strings today ("str.decode" errors argument, "compile" mode argument) should be lifted up to expect constants and still keep working if one pass them the strings "replace" or "eval".

Ok, first of all, nobody's suggesting that wouldn't work. I'm not talking about comparing enums with base types (which I have no problem working like this), I'm talking specifically about comparing enums directly with other enums from a different category. (big snip)

Ok. I do agree with your argumentation. And in fact, my previous example of ----------

...

...

disk_io.IDDLE == "iddle" True network.IDDLE == "iddle" True disk_io.IDDLE == network.IDDLE False

If the final behavior in some cases is this, no one will get harmed. We alread hav e NaN == Nan -> False and the language does not explode. :-) So, indeed - values in distinct enums should compare differently, even if they compare equal to their underlying value. (sorry for making you write the extensive e-mail) js -><-

On 02/22/2013 10:21 AM, Alex Stewart wrote:

On Friday, February 22, 2013 4:53:27 AM UTC-8, Joao S. O. Bueno wrote: Requiring that things compare differently, IMHO, is too much statically-typed-minded - it is not the way of Python. As for Alex's surreal example of someone defining "NO" and "YES" with different values in different Enums and passing the wrong one to a given call - this person will have it comming.

I think this is unnecessarily dismissive. Obviously, my example was simplified, but what if these two enums were created by two completely different people in different modules that just happen to be used in the same program? Does the hapless programmer "have it coming" then?

+1

You say that my suggestion is more like C++ than Python, but I counter that your suggestion seems to me a lot more like Perl than Python. It smacks of one of the things I dislike most about Perl, which also happens to be, in my opinion, one of the language features most responsible for (often subtle) bugs in Perl code even by experienced programmers: The contents of variables can have very different semantic meanings depending solely on the context in which they're evaluated (scalar vs array, etc). In this case what you're saying is that just because entirely unrelated programmers happened to use the same int value underneath, that Align.TOP and Errno.EPERM and Choice.OK should all be considered to mean exactly the same thing everywhere (even if none of the programmers actually intended or foresaw that possibility), but what that meaning is actually depends entirely on what context they happen to be evaluated in.

+1

Another way of looking at this is that what you're proposing is effectively implicit type-casting between enums of different types. Python does support implicit casting in a very few well-defined cases, but not most of the time, and only when doing so does not discard important semantic information (i.e. "meaning"). For ints, floats, etc, they really only have one piece of semantic information ("a number value"). Enums, however, have more than that. They have (potentially) a number value, but they also have names, and they (preferably) have information about "what type of thing am I". Automatically throwing out that extra information on a comparison where both objects have the extra info and it's not the same on both objects is, in my opinion, just wrong. If there were no extra semantic meaning to enums, then this wouldn't be an issue, but the symbolic information they carry is clearly important, because it's the whole reason we're having this discussion in the first place instead of just using ints everywhere.

+1

In pretty much all the cases I can imagine (and that have been suggested thus far), it seems to me that passing a different class of enum than the other side is testing against is almost always going to be an accident, or at the very least sloppy code (if there are cases where it is intentional, it's unlikely to be common, and the programmer should be able to explicitly cast between them somehow). Given this, I think that the Principle of Least Surprise enters into things here as well. If somebody makes a coding mistake and uses the wrong type of enum somewhere, which is likely to be the least surprising outcome?:

1. If you use an enum of the wrong type, it won't be considered equivalent to any of the expected options. 2. If you use an enum of the wrong type, it might not be considered to be equivalent to any of the expected options, or it might match one of them and do something either the same or completely different than you expect, but you have no way to tell what will happen without looking at an underlying constant which you're not supposed to have to care about.

+1000 Just to be clear, option 1 is what should happen. -- ~Ethan~

On 02/22/2013 09:07 AM, Andrew Barnert wrote:

On Feb 21, 2013, at 15:24, Greg Ewing wrote:

...

On 22/02/13 08:18, Alex Stewart wrote:

...

It doesn't seem unreasonable, therefore, to define two different categories of enums: one that has no concept of "value" (for pure-Python), and one which does have associated values but all values have to be specified explicitly

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?

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

For example, consider file open flags, mmap access flags, chmod flags, etc. You need some way to pass READ | TEXT, WRITE | SHARED, etc. occasionally, but most of the time you just pass READ or WRITE. It wouldn't be too onerous to require an explicit {READ, SHARED} set for the uncommon case, but set(READ) for the common case would be horrible. And you don't want every function that takes enums to typeswitch so it can handle a single value as if it were a set. The obvious answer to this is the one every other language uses: take READ | SHARED.

This doesn't have to mean flag enums have integral values. However, the only alternative I can think of is that enums have set syntax, so READ | SHARED returns something like READ.__class__({READ, SHARED}), which of course also means that set has to automatically be a valid value for the type. Which is pretty magical and complex.

Of course the answer could be not to allow that. Call mmap(file, access=WRITE, contention=SHARED), not mmap(WRITE | SHARED). But if we're talking about changing the stdlib and hopefully most popular third party libs, that would be a pretty drastic change.

Finally, the answer could be: if you want that, you have to give them int values, and accept ints instead of enums in your APIs, at which point I think the benefit of valueless enums has gone way down, because many places you'd think you want them (including all over the stdlib), you don't.

We shouldn't get hung up on "don't care about the values" == "no value assigned". I personally don't see any value in a valueless enum; I do see value in three other types: sequence (based on int), bitmask (based on int), and unique (or string -- based on str). It seems to me that we're throwing around "valueless" because we don't want some enums to support math operations -- so use the string version for that type. As for your example above: Python 3.2.3 (default, Oct 19 2012, 19:53:16) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. -->from yaenum import BitMaskEnum, enum -->BitMaskEnum.create('MMap', 'READ WRITE TEXT SHARED', export=globals()) -->READ, WRITE, TEXT, SHARED (MMap('READ', value=1), MMap('WRITE', value=2), MMap('TEXT', value=4), MMap('SHARED', value=8)) -->READ | TEXT MMap('READ|TEXT', value=5) -->WRITE | SHARED MMap('WRITE|SHARED', value=10)