[Python-Dev] constant/enum type in stdlib

[Michael Foord]

On 23/11/2010 13:41, Nick Coghlan wrote:
> On Tue, Nov 23, 2010 at 2:46 AM,<exarkun at twistedmatrix.com>  wrote:
>> On 04:24 pm, solipsis at pitrou.net wrote:
>>> On Mon, 22 Nov 2010 17:08:36 +0100
>>> Hrvoje Niksic<hrvoje.niksic at avl.com>  wrote:
>>>> On 11/22/2010 04:37 PM, Antoine Pitrou wrote:
>>>>> +1.  The problem with int constants is that the int gets printed, not
>>>>> the name, when you dump them for debugging purposes :)
>>>> Well, it's trivial to subclass int to something with a nicer __repr__.
>>>> PyGTK uses that technique for wrapping C enums:
>>> Nice. It might be useful to add a private _Constant class somewhere for
>>> stdlib purposes.
>> http://www.python.org/dev/peps/pep-0354/
> Indeed, it is difficult to do enums is such a way that they feel
> sufficiently robust to be worth the effort of including them (although
> these days, I would be inclined to follow the namedtuple API style
> rather than that presented in PEP 354).
Right. As it happens I just submitted a patch to Barry Warsaw's enum 
package (nice), flufl.enum [1], to allow namedtuple style creation of 
named constants:

 >>> from flufl.enum import make_enum
 >>> Colors = make_enum('Colors', 'red green blue')
 >>> Colors
<Colors {red: 1, green: 2, blue: 3}>


PEP 354 was rejected for two primary reasons - lack of interest and 
nowhere obvious to put it. Would it be *so bad* if an enum type lived in 
its own module? There is certainly more interest now, and if we are to 
use something like this in the standard library it *has* to be in the 
standard library (unless every module implements their own private 
_Constant class).

Time to revisit the PEP?

All the best,

Michael

[1] https://launchpad.net/flufl.enum

> Cheers,
> Nick.
>


-- 
http://www.voidspace.org.uk/