On 04/28/2013 06:52 PM, Steven D'Aprano wrote:
On 29/04/13 10:29, Ethan Furman wrote:
On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman <et...@stoneleaf.us> wrote:
- should an enum item be selectable via __call__ instead of __getitem__
(i.e. Season(3) is AUTUMN)
Does anyone know why this is even an issue? Is this pure bike-shedding over the
API, or are there
technical reasons for choosing one over the other?
This is an issue because currently every other type* in Python creates (or
selects ;) its instances via the call syntax:
- bool(1) # True
- int('11') # 11
- str(var) # whatever var had in it, now as a str
I think that's a red herring, because you're comparing the use of the object
constructor with look-up by name.
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.
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)
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.
But one of the latest changes to flufl.enum was to take out the call syntax,
and have only getitem syntax
- Season('AUTUMN') # raises an exception
- Season['AUTUMN'] # Season.AUTUMN
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.
--
~Ethan~
_______________________________________________
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
