[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Antoine Pitrou]

Le Mon, 25 Feb 2013 06:45:27 -0800,
Eli Bendersky <eliben at gmail.com> a écrit :

> For preparing the draft PEP I ran through some stdlib, Twisted and
> personal code and there are *tons* of places that just need a simple
> enum for some sort of "state", meaningful return value, or similar.

There are also *tons* of public APIs which are now ints and would
benefit from becoming named values, but only if doing so doesn't break
compatibility (i.e. if they are still usable everywhere an int can be
used).

> I prefer to have a good solution to one problem than a poorer
> solution that tries to cover two unrelated problems. For "names for
> ints", Nick's named value proposal seems more relevant, but why mix
> the two together?

Because the whole functionality is not important enough to have two
slightly different variations on it in the stdlib? And why is it a
poorer solution exactly?

Really, there can be two kinds of enum values (or named values):
- int-alike values (usable everywhere an int is)
- str-alike values (usable everywhere a str is)

A third kind of value, which is partly int-compatible but not entirely,
sounds like a byzantine subtlety to me.

Regards

Antoine.