[Python-ideas] Enums

[Guido van Rossum]

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 at egenix.com> wrote:
> Guido van Rossum wrote:
>> On Fri, Jul 29, 2011 at 7:55 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On Fri, Jul 29, 2011 at 7:37 PM, M.-A. Lemburg <mal at 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)