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

Reply via email to