# Why import numpy as np for scientific computing? [closed]

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 *


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.

• 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. – Mauro Vanzetto May 16 '18 at 17:10
• from scipy import *; from numpy import *; log(1j) — 200 lines of code below you will wonder why it doesn't work. – homocomputeris May 16 '18 at 19:19
• 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? – Anton Menshov May 16 '18 at 20:03
• 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. – Kirill May 16 '18 at 21:03
• @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. – 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.

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