
On Fri, Jul 29, 2011 at 7:55 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Fri, Jul 29, 2011 at 7:37 PM, M.-A. Lemburg <mal@egenix.com> wrote:
Paul Colomiets wrote:
The problem with named value is that:
namedvalue(1, "red")
Will give you are repr of "red". And you don't know whether it's TerminalColors.red or WebSafe.red or BuildbotState.red. And most of us will be too lazy to add group name or module name directly into the named value (partially because it's repeating yourself).
So the big feature of flufl.enum is classname (call it group name) in repr and isinstance check.
A meta class variant could easily add class and module names to the attrbute name, if needed/wanted.
Given that the status quo is for "TerminalColors.red" et al to just display as "1" (or whatever integers they're assigned), I'm finding it hard to consider this a particularly significant criticism. If we don't even know what *kind* of values are being passed to a debugging message, we have bigger problems than whether or not those values have been given names (and searching for all named values of 'red' with a value of '1' is going to create a much smaller resulting set than searching for all values of '1' ).
Just to make sure:
namedvalue() will just change the repr() of the value, not the str() of it, right ?
Yeah, I figured out the mechanics needed to make that work properly when writing up the recipe for the cookbook (http://code.activestate.com/recipes/577810-named-values/)
I think that's essential for making namedvalue()s useful in practice, since you mostly need this for debugging and error reporting and don't want the namevalue aspect of a constant to get in the way of its normal use in e.g. conversion to text formats such as JSON, XML, etc.
Yeah, the case I first thought of was writing numbers to CSV files, but it's really any data export operation.
That's assuming the data export format doesn't support enums. I would fine enums whose str() is just an int pretty annoying. Note that str(True) == repr(True) == 'True' and that's how I'd like it to be for enums in general. If you want the int value, use int(e). If you want the class name, use e.__class__.__name__ (maybe e.__class__ is what you're after anyway). My observation is that most enums have sufficiently unique names that during a debugging session the class is not a big mystery; it's the mapping from value to name that's hard to memorize. As a compromise, I could live with str(e) == 'red' and repr(e) == 'Color.red'. But I don't think I could stomach str(e) == 1. -- --Guido van Rossum (python.org/~guido)