1.4 Importing from Modules and Packages
17
chosen item names, makes it even more obvious that “name conflicts” is an issue
that should be understood.
Several other coding alternatives would have helped the situation here. For example, instead of from math import *, we could switch the star (*) with a list of
item names, i.e. as from math import cos for the present version. As long as we
stay away from (by a mistake) importing exp also from math, no name conflict will
occur and the program will run fine. Alternatively, we could simply have switched
the order of the import statements (can you explain 13 why?), or, we could have
moved the import statement from math import * down, so that it comes after
the statement x = exp([0, 1, 2]) and before the line y = cos(0). Note that, in
Python 3, import statements on the form from module import * are only allowed
at module level, i.e., when placed inside functions, they give an error message.
Next, we will address the safer “standard” way of importing.
1.4.2 Importing for Use with Prefix
A safer implementation of our program would use the “standard” method of
importing, which we saw a glimpse of in ball_angle_prefix.py above. With
this import technique, the code would read
import numpy
import math
x = numpy.exp([0, 1, 2])
# do all 3 calculations
print(x)
# print all 3 results
y = math.cos(0)
print(y)
We note that the import statements are on the form
import some_library
# i.e., items will be used with prefix
and that item names belonging to some_library are prefixed with some_library
and a “dot”. This means that, e.g., numpy.exp([0, 1, 2]) refers to the (unique)
exp function from the numpy library. When the import statements are on the
“standard” form, the prefix is required. Leaving it out gives an error message. This
version of the program runs fine, producing the expected output.
With the prefixing method, the order of imports does not matter, as there is no
doubt where the functions (or items) come from. At the same time, though, it is clear
that prefixing does not make it any easier for a human to read the “math meaning”
out of the code. In mathematical writing, there would be no prefix, so a prefix will
just complicate the job for a human interpreter, and more so the more comprehensive
the expressions are.
13 By switching the order, Python would first read from math import * and would import
everything, including exp, from math. Then, it would read from numpy import exp, which
would cause Python to import the numpy version of exp, which effectively means that the math
version of exp is “overwritten” by the one from numpy. At any later point in the code then, Python
will associate the word exp with the numpy function.
17
chosen item names, makes it even more obvious that “name conflicts” is an issue
that should be understood.
Several other coding alternatives would have helped the situation here. For example, instead of from math import *, we could switch the star (*) with a list of
item names, i.e. as from math import cos for the present version. As long as we
stay away from (by a mistake) importing exp also from math, no name conflict will
occur and the program will run fine. Alternatively, we could simply have switched
the order of the import statements (can you explain 13 why?), or, we could have
moved the import statement from math import * down, so that it comes after
the statement x = exp([0, 1, 2]) and before the line y = cos(0). Note that, in
Python 3, import statements on the form from module import * are only allowed
at module level, i.e., when placed inside functions, they give an error message.
Next, we will address the safer “standard” way of importing.
1.4.2 Importing for Use with Prefix
A safer implementation of our program would use the “standard” method of
importing, which we saw a glimpse of in ball_angle_prefix.py above. With
this import technique, the code would read
import numpy
import math
x = numpy.exp([0, 1, 2])
# do all 3 calculations
print(x)
# print all 3 results
y = math.cos(0)
print(y)
We note that the import statements are on the form
import some_library
# i.e., items will be used with prefix
and that item names belonging to some_library are prefixed with some_library
and a “dot”. This means that, e.g., numpy.exp([0, 1, 2]) refers to the (unique)
exp function from the numpy library. When the import statements are on the
“standard” form, the prefix is required. Leaving it out gives an error message. This
version of the program runs fine, producing the expected output.
With the prefixing method, the order of imports does not matter, as there is no
doubt where the functions (or items) come from. At the same time, though, it is clear
that prefixing does not make it any easier for a human to read the “math meaning”
out of the code. In mathematical writing, there would be no prefix, so a prefix will
just complicate the job for a human interpreter, and more so the more comprehensive
the expressions are.
13 By switching the order, Python would first read from math import * and would import
everything, including exp, from math. Then, it would read from numpy import exp, which
would cause Python to import the numpy version of exp, which effectively means that the math
version of exp is “overwritten” by the one from numpy. At any later point in the code then, Python
will associate the word exp with the numpy function.