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
