Comparisons and sorting of a numeric class....
rustompmody at gmail.com
Fri Jan 23 18:45:31 CET 2015
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
> 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.
No disagreement with the 'hack'
As for "no use case for equal but distinct tokens" - thats a strange
view given this thread
More information about the Python-list