1
$\begingroup$

Why do scientists bother with the np for numpy?

(Note this is more a "philosophical"/reasoning question - let us assume that you get your code to perform as intended regardless of choice of syntax)

When I write code for scientific applications, mathematical functions such as sqrt, as well as arrays and the many other features of Numpy are "bread and butter" - ubiquitous and taken for granted. For this reason, I always use 

from numpy import *

instead of 

import numpy as np

despite nearly every online example I see. Indeed, a colleague of mine who found my code useful said that they had to go through it and insert np everywhere. And yet, why bother? I can honestly say that in the thousands of lines of Python I've written, those three characters would have been redundant and a waste of my time. And that time is not trivial: as stated in many SE discussions, programmer time is more valuable than CPU time. If you want a super optimized program, use C or Fortran for HPC instead of python.

Using 

from numpy import sqrt

is also an option, but also has drawbacks for rapidly making a script where you might want to use a new function out of the blue (as you would in C, Fortran, Matlab, whatever).

Suppose that there is a library for accurately calculating the square root of a complex number - then it's still faster to import complxlib as cplx, use cplx.sqrt when necessary and sqrt the other 99% of the time. So is there a real example or argument as to why my approach is bad practice?

Please note that the question is specifically about numpy - a staple in scientific application of python, rather than e.g. super_esoteric_library8472.

Improve this question
$\endgroup$
8
  • 1
    $\begingroup$ In my opinion this is off topic here, anyway try to answer. Simply for clarity and avoid conflict. This is quite similar to c++ namespace where is better to use std::cout. If I see np.sqrt I know without error the exact function and there is not conflict also in future. $\endgroup$
    – Mauro Vanzetto
    May 16, 2018 at 17:10
  • 4
    $\begingroup$ from scipy import *; from numpy import *; log(1j) — 200 lines of code below you will wonder why it doesn't work. $\endgroup$
    – homocomputeris
    May 16, 2018 at 19:19
  • 1
    $\begingroup$ there are a lot of debates for having or not having using namespace std in C++ code by default - for a standard C++ library. Why should the same controversial exclusive approach apply to a non-standard (but of course very popular) package numpy? $\endgroup$
    – Anton Menshov ♦
    May 16, 2018 at 20:03
  • 4
    $\begingroup$ Debates about coding styles are at least as old as the Internet. It would make the question a lot more constructive if you were more precise about your criteria for evaluating a coding style, especially since they obviously don't match other people's criteria. Is saving characters really the ultimate goal? "Explicit is better than implicit" is at least as good a principle as saving characters (and I'd say better). Otherwise it is far too easy to end up talking past each other or accidentally start a flame war, which nobody would like. $\endgroup$
    – Kirill
    May 16, 2018 at 21:03
  • 1
    $\begingroup$ @ValentinAslanyan Why import all from NumPy if a project uses, say, SciPy, SymPy or FFTW more? If you want to save typing time, you can from numpy import sqrt as s. $\endgroup$
    – homocomputeris
    May 17, 2018 at 13:18

1 Answer 1

Reset to default
8
$\begingroup$

I would say, that it can be explained by the following famous programming principle:

Explicit is better than implicit

Usually, that is applied to types; however, it can be applied to namespaces (as mentioned by @Mauro Vanzetto) as well as particular libraries/packages.

I, personally, like having np.sqrt or std::cout (as opposed to just sqrt and cout) because typing that does not cost me a lot and I can feel sure that no tricky variable/function hiding can happen and explicitly see if I am using a function coming from a certain namespace/library/package.

In scientific computing, in particular, when even the order of summation can change the result significantly in some cases, I want to avoid a certain type of problems, to begin with – and simplify my life in debugging by explicitly pointing to where each function I am using is coming from.

Improve this answer
$\endgroup$
10
  • 2
    $\begingroup$ The Mathworks apparently disagrees, ha ha. $\endgroup$
    – Mark L. Stone
    May 16, 2018 at 17:32
  • 1
    $\begingroup$ Is it "better", though? I use a numpy math function maybe once a line on average. This means thousands of $\texttt{np.}$, much less clear code, e.g. $\texttt{np.cos(np.log(x))}$ for a simple compound math function - therefore less clarity for people reading it, debugging etc. $\endgroup$
    – Valentin Aslanyan
    May 16, 2018 at 17:34
  • 4
    $\begingroup$ @ValentinAslanyan you can use from numpy import log, cos if that is used that much. The point is that you are trying to keep the namespace clean that, say, matlab is an absolute disaster $\endgroup$
    – percusse
    May 17, 2018 at 13:05
  • 4
    $\begingroup$ @ValentinAslanyan Note that numpy does contain functions which shadow python builtins, which can affect performance (sum) or syntax (max) and I have seen the last one cause a serious, hard to debug issue. $\endgroup$
    – origimbo
    May 18, 2018 at 8:48
  • 1
    $\begingroup$ @origimbo Thank you, this is the first answer I've seen that I believe has a demonstrable point - I would love to know the details in a full answer, if the question hadn't been locked. After posting the OP, I was considering making a concrete comparison of numpy and builtin functions to see precisely how many overlap (results would not remain valid indefinitely, of course). $\endgroup$
    – Valentin Aslanyan
    May 18, 2018 at 13:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.