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. -- http://mail.python.org/mailman/listinfo/python-list