J
J. Cliff Dyer
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
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
A
Alan G Isaac
Agreed. It was a cut and paste failure.
Apologies.
Alan Isaac
H
Hyuga
I was about to suggest that too, but it sounds like the OP has little
or no control, in this case, over the RE itself. Another thing I
would suggest is using the (?
syntax--it allows creating a syntacticgroup that isn't returned in the list of match groups.
J
Jean-Michel Pichavant
The import * should not used if possible, I totally agree on that point,J. Cliff Dyer said:
but there's no need to rename namespaces for that.
br
Jean-Michel
J
J. Cliff Dyer
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
J
Jean-Michel Pichavant
Maybe I've been a little bit too dictatorial when I was saying thatJ. Cliff Dyer said:
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
L
Lie Ryan
Jean-Michel Pichavant wrote:
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
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
J
Jean-Michel Pichavant
Lie said:
yep, your example is good, no namespace renaming ...
)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 ?
br
Jean-Michel
R
Robert Kern
<shrug> It depends on the audience. For those familiar with numpy and the np
convention, it's easier to read code that uses np because there are many lines
with several numpy functions called in each.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
L
Lie Ryan
Jean-Michel Pichavant said:yep, your example is good, no namespace renaming ...
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.