On 02/12/2013 11:13 AM, Guido van Rossum wrote:
On Tue, Feb 12, 2013 at 10:31 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 02/12/2013 10:08 AM, Guido van Rossum wrote:
I'm torn. I like the clean look of Tim's:
class Flag(Enum):
RED, WHITE, BLUE
However, I don't like the magic needed for its implementation -- and
anybody who thinks they know Python pretty well and thinks about this
syntax for more than two seconds has to wonder how on earth it's done
(and the answer is pretty horrible). It is also pretty brittle to
depend on the lookup order -- and I suspect it will be prone to
masking other bugs (any typo in a name used in class-level code will
essentially generate a bogus new enum value).
It seems to me the point of an enum is to give names to an order, so why
would the lookup order be a problem?
Because the language requirement that the expressions in a tuple are
evaluated left-to-right is fairly weak. (There are other, similar
contexts where the order is not l2r.)
Personally, I'd be fine with:
class Color(Enum):
BLACK
RED
BLUE
PURPLE
which avoids the l2r issue, and the repetitive use of val() (or whatever it's called).
We could minimize that issue by requiring that enum names be ALLCAPS -- if something comes through that isn't, don't supply a value and let the AttributeError perculate up.As far as typos go, I don't think that's a new problem (it certainly isn't
for me, anyway ;) and my best defense is plenty of tests.
So with Tim's implementation, what happens here:
class Color(Enum):
RED, GREEN, BLUE
if sys.platform == 'win32':
MAGENTA
and you happen to have no "import sys" in your module? The sys lookup
will succeed, create a new enum, and then you will get an error
something like this:
AttributeError: 'Enum' object has no attribute 'platform'