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 -- https://mail.python.org/mailman/listinfo/python-list
