[Python-ideas] constant/enum type in stdlib

Giampaolo Rodolà g.rodola at gmail.com
Wed Jan 30 22:52:53 CET 2013


2013/1/30 Eli Bendersky <eliben at gmail.com>:
>> Reading this thread it seems that many core devs are interested in the
>>
>> > feature and the discussion is mainly deciding on the exact semantics and
>> > implementation. Even Guido didn't really speak against it (only somewhat
>> > against adding new syntax).
>> >
>> > Eli
>>
>>
>> Personally I'm -1 for a variety of reasons.
>>
>> 1) a const/enum type looks like something which is subject to personal
>> taste to me. I personally don't like, for example, how flufl requires
>> to define constants by using a class.
>> It's just a matter of taste but to me module.FOO looks more "right"
>> than module.Bar.FOO.
>> Also "Colors.red < Colors.blue" raising an exception is something
>> subject to personal taste.
>>
>> 2) introducing something like that (class-based) wouldn't help
>> migrating the existent module-level constants we have in the stdlib.
>> Only new projects or new stdlib modules would benefit from it.
>
>
> These are more in the domain of implementation details, though, not
> criticizing the concep?

Personally I'd be +0 for a constant type and -1 for an enum type,
which I consider just useless.
If a 'constant' type has to be added though, I'd prefer it to be as
simple as possible and close to what we've been used thus far, meaning
accessing it as "foo.BAR".
In everybody's mind it is clear that "foo.BAR" is a constant, and that
should be preserved.
Something along these lines:

>>> from collections import constant
>>> STATUS_IDLE = constant(0, 'idle', doc='refers to the idle state')
>>> STATUS_IDLE
0
>>> str(STATUS_IDLE)
'idle'


---- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
http://code.google.com/p/pysendfile/



More information about the Python-ideas mailing list