On 5 September 2013 19:06, Skip Montanaro <s...@pobox.com> wrote:
>>> You can! Any name will work, functions aren't special.
>>>
>>> from module1 import method1, A, B, C, D, E
>>
>> Better practice is to use:
>>
>> import module1
>> print module1.A
>> print module2.B
>>
>> and so forth since that makes it far more clear what you are doing and
>> where they come from. But it's not compulsory.
>
> Maybe I'm imagining things, but I think it's pretty common to see some
> big-ass modules imported using "from module import *". While people
> may think that's expedient, I think it can often be the source of
> subtle bugs.
It is common in scientific programming e.g. 'from numpy import *' and
so on. And actually I think that it is a reasonable thing to do in
cases where:
1) You're writing a single smallish module/script.
2) The imported module is well-known and anyone who doesn't know it
won't understand your code anyway.
3) You're only doing one star-import.
4) You're using a lot of symbols from that import in lots of places in
your code.
Consider for example, this script:
#!/usr/bin/env python
import numpy
import matplotlib.pyplot
k = 1
f = 10
x = numpy.arange(0, 3, 0.01)
y = numpy.exp(k * x) * numpy.sin(2 * numpy.pi * x)
matplotlib.pyplot.plot(x, y)
matplotlib.pyplot.show()
I write a lot of scripts that look roughly like that except they're
usually quite a bit bigger. Written as above, the word numpy would
appear dozens of times in a single script. Because of this it's
commonplace to abbreviate the module names on import e.g.:
#!/usr/bin/env python
import numpy as np
import matplotlib.pyplot as plt
k = 1
f = 10
x = np.arange(0, 3, 0.01)
y = np.exp(k * x) * np.sin(2 * np.pi * x)
plt.plot(x, y)
plt.show()
But still in situations where you have to write 'np.' 3 or more times
on a line, it just becomes a distraction in your code. Of course you
can just import the names you want e.g.:
#!/usr/bin/env python
from numpy import arange, exp, sin, pi
from matplotlib.pyplot import plot, show
k = 1
f = 10
x = arange(0, 3, 0.01)
y = exp(k * x) * sin(2 * pi * x)
plot(x, y)
show()
But this just gets annoying. In practice I'll probably end up
importing 20 or so names. When writing a script like this I probably
tweak and rerun it continuously and so when I decide that actually I
meant cos not sin then I run it and get:
$ ./tmp3.py
Traceback (most recent call last):
File "./tmp3.py", line 9, in <module>
y = exp(k * x) * cos(2 * pi * x)
NameError: name 'cos' is not defined
And then I have to go back and edit the import line. This kind of
thing just wastes a bit of time while I'm working. So the matplotlib
folks created a special module called "pylab" that brings together the
symbols from numpy and matplotlib and is specifically designed so that
you can star-import it when writing this kind of code interactively or
in a script:
#!/usr/bin/env python
from pylab import *
k = 1
f = 10
x = arange(0, 3, 0.01)
y = exp(k * x) * sin(2 * pi * x)
plot(x, y)
show()
The pylab star-import brings a *huge* number of symbols into the
current namespace:
$ python -c 'import pylab; print(len(pylab.__dict__))'
933
However, it's very common that this set of symbols comprises
everything that a script needs. Personally I don't think there's
anything wrong with using that in a script (with the caveats I
mentioned above). A similar case is in a script that uses sympy (I
wouldn't do it with pylab and sympy together though). In either case I
would tend to think that I'm essentially using an augmentation of
builtins. Just as you need to know roughly what's in builtins to
understand ordinary Python code, you need to know what's in pylab or
sympy to understand this script.
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
