[Python-Dev] constant/enum type in stdlib (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Tue Nov 23 14:50:53 CET 2010

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/

More information about the Python-Dev mailing list