Perl's @foo[3,7,1,-1] ?

Lie Ryan lie.1296 at
Tue Jun 23 14:13:20 EDT 2009

Jean-Michel Pichavant wrote:
> Lie Ryan wrote:
>> Jean-Michel Pichavant wrote:
>> <snip>
>>> Maybe I've been a little bit too dictatorial when I was saying that
>>> renaming namespaces should be avoided.
>>> Sure your way of doing make sense. In fact they're 2 main purposes of
>>> having strong coding rules:
>>> 1/ ease the coder's life
>>> 2/ ease the reader's life
>>> The perfect rule satisfies both of them, but when I have to choose, I
>>> prefer number 2. Renaming packages, especially those who are world wide
>>> used, may confuse the reader and force him to browse into more code.
>>> From the OP example, I was just pointing the fact that **he alone**
>>> gains 3 characters when **all** the readers need to ask what means "np".
>>> Renaming namespaces with a well chosen name (meaningful) is harmless.
>> As long as you keep all import statements at the head of the file, there
>> is no readability problems with renaming namespace.
>> Glance at the header file, see:
>> import numpy as np
>> and it's not hard to mentally switch np as numpy...
>> well, as long as your header doesn't look like this:
>> import numpy as np
>> import itertools as it
>> import Tkinter as Tk
>> from time import time as t
> yep, your example is good, no namespace renaming ... :o)
> I would gladly accept the following renaming:
> import theMostEfficientPythonPackageInTheWorld as meppw
> Hopefully, package names are often usable as provided.
> Moreover, writing numpy instead of np is not harder for the coder than
> switching mentally from np to numpy for the reader. It's just about who
> you want to make the life easier, the coder or the reader ?

My point was, use namespace renaming whenever that improves readability;
however like all tools, don't overuse it

Another usecase might be when you have two similarly named package which
might bring confusion on which is which if left as is.

More information about the Python-list mailing list