Python modules

[zoom]

Is there any "rules" regarding importing python modules within your own
module? I mean, how does this affects the performance of the program?

For example, I have my own module named "sound".
At the top of the file sound.py I have:
import scipy

In the code I have:
import scipy, sound, etc

Now I have two instances of every function within scipy, e.g.
scipy.r_[a] = sound.scipy.r_[a]

Module importing is quite fast, but not instant. It takes some time, but
it happens only once. My concern is whether I hold all these multiple
instances of same function in the memory, and does this reduce the
performance of my program.

In short, when creating a module, is it worthwhile to be careful and
import only necessary functions, nothing more?

 

[zoom]

Is there any "rules" regarding importing python modules within your own
module? I mean, how does this affects the performance of the program?

"Even the initializers are optimized!" -- Mel, the real programmer
Great!

Unless you've profiled it, and the extra memory taken up by unused
functions or modules is measurable and near the top of the list of
performance issues, I wouldn't worry about it.

Now I have two instances of every function within scipy, e.g.
scipy.r_[a] = sound.scipy.r_[a]

No: now you have two names for every function within scipy. The
functions themselves are not duplicated.

Dan

Now I love Python even more...

 

[Chris Angelico]

Is there any "rules" regarding importing python modules within your own
module? I mean, how does this affects the performance of the program?

In short, when creating a module, is it worthwhile to be careful and import
only necessary functions, nothing more?

Nope. When you import a module, a record of it is kept in sys.modules,
so the next time you import it, it's just picking up the same module
object.

scipy.r_[a] = sound.scipy.r_[a]

They'll actually be the same thing, which you can test with the 'is'
operator. The performance cost of reimporting a module is very low; in
fact, trying to avoid it by adorning all your usage with an extra
dot-level will probably cost you a lot more, since there'll be an
extra lookup every time.

Have at it!

ChrisA

 

[Rick Johnson]

The performance cost of reimporting a module is very low;
in fact, trying to avoid it by adorning all your usage
with an extra dot-level will probably cost you a lot more,
since there'll be an extra lookup every time.

Most people "adorn" a module with an extra dot to:

1. create a shorter name (f.e.[1] tk instead of Tkinter)

2. keep their namespace clean.

Only a fool would do "from Tkinter import *"[2]. A wise programmer, who needed to access many members of Tkinter, would do instead "import Tkinter as tk", and then prepend all members with "tk.".

[1] Abbr: (F)or (E)xample. (I feel an EnglishWart brewing on this subject!)
[2] With the exception of command line testing, learning, or playing.

 

[Rick Johnson]

The performance cost of reimporting a module is very low;
in fact, trying to avoid it by adorning all your usage
with an extra dot-level will probably cost you a lot more,
since there'll be an extra lookup every time.

Most people "adorn" a module with an extra dot to:

1. create a shorter name (f.e.[1] tk instead of Tkinter)

2. keep their namespace clean.

Only a fool would do "from Tkinter import *"[2]. A wise programmer, who needed to access many members of Tkinter, would do instead "import Tkinter as tk", and then prepend all members with "tk.".

[1] Abbr: (F)or (E)xample. (I feel an EnglishWart brewing on this subject!)
[2] With the exception of command line testing, learning, or playing.

 

[Grant Edwards]

Only a fool would do "from Tkinter import *"[2].

[2] With the exception of command line testing, learning, or playing.

I don't think those should be excepted. Habits acquired during
learning/playing will be continue when doing real work, and "Example"
code provided as part of lessons/tutorials _will_ get copied into real
programs.

IMO, tutorials that take shortcuts like "from Tkinter import *" are A
Bad Thing(tm).

When teaching somebody how to do something, don't show them the wrong
way do to something and then after they've learned that add "by the
way, don't actually do it that way".