On 28Apr2013 19:46, Ethan Furman <et...@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, thomp...@apple.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com