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.


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.


closed as off-topic by Mauro Vanzetto, GoHokies, Tyler Olsen, Christian Clason, Kirill May 16 '18 at 21:07

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 '18 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 '18 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 '18 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 '18 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 '18 at 13:18

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.

  • 1
    $\begingroup$ The Mathworks apparently disagrees, ha ha. $\endgroup$ – Mark L. Stone May 16 '18 at 17:32
  • $\begingroup$ @MarkL.Stone, they sure can :) That principle is not a dogma and certainly can be argued. $\endgroup$ – Anton Menshov May 16 '18 at 17:34
  • $\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 '18 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 '18 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 '18 at 8:48

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