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

[Jean-Michel Pichavant]

J. Cliff Dyer wrote:
> On Mon, 2009-06-22 at 14:57 +0200, Jean-Michel Pichavant wrote:
>   
>> J. Cliff Dyer wrote:
>>     
>>> On Wed, 2009-06-17 at 14:13 +0200, Jean-Michel Pichavant wrote:
>>>   
>>>       
>>>> On Wed, Jun 17, 2009 at 04:14, Steven D'Aprano wrote:
>>>>     
>>>>         
>>>>>> What's np.arange?
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> import numpy as np
>>>>>
>>>>> --
>>>>> Pierre "delroth" Bourdon <delroth at gmail.com>
>>>>> Étudiant à l'EPITA / Student at EPITA
>>>>>   
>>>>>       
>>>>>           
>>>> Perfect example of why renaming namespaces should be done only when 
>>>> absolutely required, that is, almost never.
>>>>
>>>> Jean-Michel
>>>>     
>>>>         
>>> I disagree.  Renaming namespaces should always be done if it will help
>>> stop people from doing a 'from package import *'.  However, example code
>>> should always include relevant imports.
>>>
>>> Cheers,
>>> Cliff
>>>
>>>
>>>   
>>>       
>> The import * should not used if possible, I totally agree on that point, 
>> but there's no need to rename namespaces for that.
>>
>> br
>>
>> Jean-Michel
>>
>>     
>
> Technically, no.  But we're dealing with people, who are notoriously
> *un*technical in their behavior.  A person is much more likely to
> develop bad habits if the alternative means more work for them.  The
> reason people do `from foo import *` is that they don't want to type
> more than they have to.  If they can write a one or two letter
> namespace, they're likely to be happy with that trade-off.  If the
> alternative is to write out long module names every time you use a
> variable, they'll tend to develop bad habits.  To paraphrase Peter
> Maurin, coding guidelines should have the aim of helping to "bring about
> a world in which it is easy to be good."
>
> I don't really see much problem with renaming namespaces: For people
> reading the code, everything is explicit, as you can just look at the
> top of the module to find out what module a namespace variable
> represent; the local namespace doesn't get polluted with God knows what
> from God knows where; and code remains succinct.
>
> I've found in my own code that using, for example, the name `sqlalchemy`
> in my code means that I have to go through painful contortions to get
> your code down to the PEP-8 recommended 80 characters per line.  The
> resulting mess of multi-line statements is significantly less readable
> than the same code using the abbreviation `sa`.
>
> Do you have an argument for avoiding renaming namespaces?  So far the
> only example you provided is a code fragment that doesn't run.  I don't
> disagree with you on that example; referring to numpy as np without
> telling anyone what np refers to is a bad idea, but no functioning piece
> of code could reasonably do that.
>
> Cheers,
> Cliff
>
>   
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.

br

Jean-Michel