[Python-Dev] enum discussion: can someone please summarize open issues? (original) (raw)

Cameron Simpson cs at zip.com.au
Mon Apr 29 08:36:15 CEST 2013

On 28Apr2013 19:46, Ethan Furman <ethan at stoneleaf.us> wrote: | int, float, and bool all have object constructors that take the | given string and return a matching instance; int /may/ return a | pre-existing instance, bool /will/ return a pre-existing instance.

I think Guido's already pointed out this:

bool('False') True

| As I've stated before, 'bool's are the closest existing data type to | enums, in that bools use the object constructor to convert the | incoming parameter to an existing bool instance, of which there will | only ever be two. || bool(9) is bool('maybe') is bool(True) is True || and similarly, Enum behavior /should be/ (in my opinion ;) || Season.AUTUMN is Season('AUTUMN') is Season(3)

I think that would be efficient, but as an outside user I wouldn't necessarily expect it unless I'd ready the spec very closely and the spec was explicit about it.

Coming from (in the fairly distant past) a C background, I naively think of enums as nicely named ordinals of some kind and expect to compare them with ==, not "is".

If you want to guarantee "is", be my guest though. I don't know how that might make things go with some hypothetical subclass with many many and extensible enum values.

| Like it or not, when you write class Season(Enum) a new type is | created called Season, and Season(x) should either return a Season | instance that matches x or raise. Having a match and raising anyway | just doesn't seem to me to be the Python Way.

I'm +1 on all of this.

[...] | >I'm not sure whether flufl.enums support creating additional instances after the event, but if it did, I would expect | >that I could say Season('WET') to get a new instance. I am indifferent to whether or not Season('AUTUMN') should return | >the existing AUTUMN enum value. || Adding more enumerators after the fact should not be supported; | there is subclassing for that. Not worth actively preventing, but | not encouraged.

I'd go a bit further here: I'd take this final sentence as being -0 on preventing adding more enumerals(?), whereas I'm a solid -1 on preventing it. By all means not actively support it, but very against doing things that make it hard for a subclass to support it.

Just 2c,

Would you remember a one-line .sig? - Paul Thompson, thompson at apple.com

More information about the Python-Dev mailing list