[Python-Dev] constant/enum type in stdlib
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:
>>>>
>>>> make_enums("Names", "NAME_ONE NAME_TWO NAME_THREE", base_type=int,
>>>> module=__name__)
>>>>
>>>> Using __name__ we can set the module globals in the call to make_enums.
>>> 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