[SciPy-user] What can be improved ?

Anne Archibald peridot.faceted at gmail.com
Thu May 17 13:42:57 EDT 2007


On 17/05/07, Steve Schmerler <elcorto at gmx.net> wrote:

> In most cases, import * results in poorly readable code. import * inside functions
> and more general importing *anything* in functions isn't a good idea because: usually
> you write a function in order to execute a chunk of code more than once. So if you
> call the func N times, all the importing will also be done N times which is simply
> overhead (execution time + memory action). A simple-minded timing example is
> attached, which shows the effect clearly (although not utilizing some nifty tricks
> offerd by the timeit module). Running it (from Ipython or the cmd line), I see the
> warning David mentioned. Maybe this was intruduced with Python 2.4.x and you are on
> 2.3.x if you don't see it?

A technical point: python imports are implemented to do nothing on
re-import, so calling import many times is not actually a problem.
What *is* a problem is "from whatever import *" in any namespace but
the global one. This confuses python about namespaces (some technical
problem that appeared when they introduced lexical scoping) and so
python warns about it.

The real problem with "from numpy import *" is that it just takes
everything in numpy and plops it over top of what's already there.
Interactively this is great, it saves you typing, but in a program
you're going to keep around it can be a problem: suppose I write code
using a local variable arange2d, debug my program and it's working
fine. Now I install a new version of numpy which has a function
"arange2d"; suddenly all the references to arange2d in my code mean
something different!

There are various alternatives:
"include numpy" -> "numpy.sin"
"include numpy as N" -> "N.sin"
"from numpy import sin" -> "sin"

More generally, "from whatever import *" is a problem because the
python library was designed with the "import name" mechanism in mind.
So functions in different modules often have the same name (for
example md5.new and sha.new), and will crash if you do "from whatever
import *". Even if they don't crash, "csv.reader: is a lot more
intelligible than "reader".

As for why not just import everything on your PC, there are lots of
reasons. Python has a *lot* of standard libraries, and loading all the
code for that takes time and memory and just isn't needed. Python also
has a lot of third-party libraries, which are not always easy to
locate automatically. More to the point, by saying "import numpy" you
are telling the python interpreter and readers of your code "this
program needs numpy to run"; it may mean they have to go out and
install it, it may mean they'll need to adapt the code if a new
version of numpy is released. Being explicit about dependencies is a
very good idea.

Anne

Anne



More information about the SciPy-User mailing list