Comparisons and sorting of a numeric class....
rosuav at gmail.com
Fri Jan 23 18:37:33 CET 2015
On Sat, Jan 24, 2015 at 4:22 AM, Rustom Mody <rustompmody at gmail.com> 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:
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 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