Well, it does sound like we're not going to agree on how enums should behave. There are too many different use cases. So I am giving up. Sorry. (Also I'm going on vacation and will be mostly off-line for the next 2-3 weeks.) --Guido On Fri, Jul 29, 2011 at 10:07 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Guido van Rossum wrote:
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.
The situation with enums is different than for booleans: many data interchange formats out there support true/false directly, so there's little to change and little breakage involved. And it's easy to fix, since you only to deal with two such enums.
However, when you change existing code constants to enums, chances are high that your interchange libraries are going to fail because of this, or your application will start providing broken data to external resources, without you knowing.
Since it's easy to switch from %s to %r, if needed, I don't see much of a problem with having str(e) continue to return the integer string.
Regarding the repr(e): This should really be user-defined. There situations where you want to see both the integer code and description in the repr(e), e.g. when dealing with error codes where you quickly need to communicate the error, so a format like '[123] Error contacting server' would be better than just 'Error contacting server'.
In other cases, the subsystem is important, so getting '[Server][FTP] Permission error' is more useful than just 'Permission error'.
And in yet other circumstances, you want to see the defining module and class.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jul 29 2011)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
-- --Guido van Rossum (python.org/~guido)