[Python-ideas] Enums

[Michael Foord]

On 27 July 2011 13:36, Giampaolo Rodolà <g.rodola at gmail.com> wrote:

> 2011/7/25 Michael Foord <fuzzyman at gmail.com>
>
>>
>>
>> On 25 July 2011 19:47, Raymond Hettinger <raymond.hettinger at gmail.com>wrote:
>>
>>>
>>> On Jul 25, 2011, at 1:06 PM, Michael Foord wrote:
>>>
>>>
>>> Python standard library modules currently using integers for constants:
>>>
>>> * re - has flags (OR'able constants) defined in sre_constants, each flag
>>> has two names (e.g. re.IGNORECASE and re.I)
>>>
>>>
>>> What is being proposed here?  Will there be a new namespace so that we
>>> would start writing re.Flags.IGNORECASE instead of re.IGNORECASE?  Are
>>> module level constants now going to be considered bad-form?
>>>
>>> If constants switch from re.IGNORECASE to re.flags.IGNORECASE, are there
>>> any benefits to compensate for being both wordier and slower?
>>>
>>>
>> Nope. Just something like this at the module level.
>>
>> IGNORECASE = Flags.IGNORECASE
>>
>> What it gains you is a nicer representation when looking at the values
>> when debugging. On the other hand being able to have access to all the
>> constants namespaced on a single object (as well) doesn't seem like such a
>> bad thing.
>>
>
> Having aliases all around stdlib module namespaces doesn't sound like a
> good idea to me at all.
> "There should be one and preferably one obvious way to do it".
> That aside, it's not clear what name convention to use that extra "Flags"
> namespace which wasn't there before.
>
> Why re.Flags.* instead of re.Constants.*?
>

I used Flags as an arbitrary name for an example. It could be anything. It
could be _Constants if it was decided that the constant group itself wasn't
useful. I would expect it to be useful.


> If we decide to use re.Flags what should we expect to find into the socket
> module? socket.Constants?
> If so, why do we find AF_INET in socket.Constants.AF_INET rather
> than socket.Family.AF_INET?
>
>
...and so on.
>
>
We can give it whatever name is most useful.


> Also, while before it was clear that module.SOMETHING was referring to a
> constant, now I that I make a dir() of a module and see "Something"  instead
> of "SOMETHING", the first thing which comes to my mind is that "Something"
> is a class, not a container of some constants.
>

Something would be a class. SOMETHING would still exist and should behave as
expected. "Something" should in fact have a name that *does* tell you what
it does. "Constants" for example gives you a good clue.

Michael


>
> Regards,
>
> --- Giampaolo
> http://code.google.com/p/pyftpdlib/<http://code.google.com/p/psutil/downloads/list>
> http://code.google.com/p/psutil/<http://code.google.com/p/psutil/downloads/list>
>



-- 

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

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110727/00eec380/attachment.html>