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

Michael Foord fuzzyman at voidspace.org.uk
Tue Nov 23 16:15:29 CET 2010

On 23/11/2010 15:01, Antoine Pitrou wrote:

Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :

2010/11/23 Antoine Pitrou<solipsis at pitrou.net>:

On Tue, 23 Nov 2010 14:24:18 +0000 Michael Foord<fuzzyman at voidspace.org.uk> wrote:

Well, for backwards compatibility reasons the new constants would have to behave like the old ones (including having the same underlying value and comparing equal to it).

In many cases it is likely that subclassing int is a better way of achieving that. Actually looking through the standard library to evaluate it is the only way of confirming that. Another API, that reduces the duplication of creating the enum and setting the names, could be something like: makeenums("Names", "NAMEONE NAMETWO NAMETHREE", basetype=int, module=name) Using name we can set the module globals in the call to makeenums. I don't understand why people insist on calling that an "enum". enum is a C legacy and it doesn't bring anything useful as I can tell. Instead, just assign the values explicitly. The concept of a "enumeration" of values is still useful outside its stunted C incarnation. Well, it is easy to assign range(N) to a tuple of names when desired. I don't think an automatically-enumerating constant generator is needed. Right, and that is current practise. It has the disadvantage (that you seemed to acknowledge) that when debugging the integer values are seen instead of something with a useful repr.

Having a simple class (and API to create them) that produces named constants with a useful repr, is what we are discussing, and that seems awfully like an enum (in the general sense not in a C specific sense). For backwards compatibility these constants, where they replace integer constants, would need to be integer subclasses with the same behaviour. Like the Qt example you appreciated so much. ;-)

There are still two reasonable APIs (unless you have changed your mind and think that sticking with plain integers is best), of which I prefer the latter:

SOME_CONST = Constant('SOME_CONST', 1) OTHER_CONST = Constant('OTHER_CONST', 2)

or:

Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST', start=1) SOME_CONST = Constants.SOME_CONST OTHER_CONST = Constants.OTHER_CONST

(Well, there is a third option that takes name and sets the constants in the module automagically. I can understand why people would dislike that though.)

All the best,

Michael Foord

Michael

Regards

Antoine.

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

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

More information about the Python-Dev mailing list