Comparisons and sorting of a numeric class....

[Rustom Mody]

On Friday, January 23, 2015 at 11:07:48 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Jan 24, 2015 at 4:22 AM, Rustom Mody  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
> True
> 
> 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.
> 
> ChrisA

No disagreement with the 'hack'
As for "no use case for equal but distinct tokens" - thats a strange
view given this thread