Comparisons and sorting of a numeric class....

Chris Angelico rosuav at
Fri Jan 23 18:37:33 CET 2015

On Sat, Jan 24, 2015 at 4:22 AM, Rustom Mody <rustompmody at> wrote:
> Strikes me that making enumerations is-equal rather than just
> =-equal is a bit heavy-handed and unnecessary
> What do you think?

*Normal* use of an enumeration does make sense for them to be
identical. Classic use would be like this:

class AnsiColor(IntEnum):
    black = 0
    red = 1
    green = 2
    orange = 3
    # ... blue, magenta, cyan, white
    bold_black = 8
    bold_red = 9
    # etc etc etc
    bold_orange = 11
    yellow = 11 # On many screens, bold orange looks more yellow

There is absolutely no difference between the ANSI color "bold orange"
and the ANSI color "yellow". So you would expect them to be identical:

>>> AnsiColor.yellow
<AnsiColor.bold_orange: 11>
>>> AnsiColor.yellow is AnsiColor.bold_orange

And they are. There's simply no use-case for equal-but-distinct
tokens, when you're primarily using this to give names to numbers. For
another example, you could localize all the color names, or use
"bright" instead of "bold", or drop the underscores; but ultimately,
if you send "\e[11m" to the console, you're going to get the same
color, whether that 11 was called "bold_orange" or "jaune".

What you're trying to do here is a hack, so it's no surprise that the
system doesn't properly support it.


More information about the Python-list mailing list