RetroSearch Browse

Tue Nov 23 16:15:29 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-November/105887.html

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/

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-November/105887.html below:

[Python-Dev] constant/enum type in stdlib