new enum idiom

Alex Martelli aleaxit at yahoo.com
Tue Jan 9 08:27:44 EST 2001


"Carel Fellinger" <cfelling at iae.nl> wrote in message
news:93dde1$8d2$1 at animus.fel.iae.nl...
    [snip]
> > This assumes a non-string argument (typically an integer, but that's
> > not checked here) is meant to set the value to be named by the
> > string-argument immediately *following* it -- a substantial
> > simplification.  So substantial, that if one
> ...
> > Needing to explicitly set values in an enum is rare enough, that it
> > would seem fully acceptable to me to place the explicit values right
> > _before_ their names in those rare cases, using the much-simpler
> > code above.  Viva simplicity...!-)
>
> Simplicity of implementation, yes.  But is this what one would expect?

Personally, I would expect _nothing in particular_ when reading
something like

    xx = enum('foo', 'bar', 32, 'fee', 'fie', 45, 'flip', 'flop')

i.e., just a list of name-like strings occasionally mixed with
values that clearly aren't names.


> I think all the languages I know that provide an enumaration method
> that allows for changing the count midway spell it the other way
> around, first the name then the value.

With some extra syntax, such as equal-signs, or arrowlike squigglies
pointing in either explicit direction, expectations would surely firm
up.  E.g., if I read:

    xx = enum('foo', 'bar', 32, '<-fee', 'fie', 45, '<-flip', 'flop')

I would guess the arrows are suggesting 32 is the value of 'fee' and
45 the value of 'flip, while if I read:

    xx = enum('foo', 'bar->', 32, 'fee', 'fie->', 45, 'flip', 'flop')

then the different arrows would suggest 32 as the value of 'bar' and
45 as that of 'fie'.


Absent such extra syntax clues, though, I don't see expectations
being meaningful either way.  What language lets you define enums
with _some_ values out-of-order by just letting you list names
and non-name values with no further demarcation?


Python's mantra "when in doubt, avoid the temptation to guess" would
then *strongly* urge one to drop this complication altogether.


> of it, especially since its use is so rare.  Arguely an even better
> approach would be to have such new counting points be spelled as
> tuples; a little more eye-catching and simplifying the code even
> further:)

That's one possibility.  Syntax such as "bar=32" (for names in the
enumlist whose value is explicitly defined) being another alternative,
still better than 'just the list' (and a split on that form is
enough to make it into the name/value pair, so it would be easy
enough to accept either).


Alex






More information about the Python-list mailing list