2011/7/25 Michael Foord <fuzzyman@gmail.com>
On 25 July 2011 19:47, Raymond Hettinger
<raymond.hettinger@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.*?
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.
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.
Regards,
--- Giampaolo