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