Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #36790 > unrolled thread

Python modules

Back to article view | Back to comp.lang.python

Contents

  Python modules zoom <zoom@yahoo.com> - 2013-01-14 15:54 +0100
    Re: Python modules Dan Sommers <dan@tombstonezero.net> - 2013-01-14 15:01 +0000
      Re: Python modules zoom <zoom@yahoo.com> - 2013-01-14 16:03 +0100
    Re: Python modules Chris Angelico <rosuav@gmail.com> - 2013-01-15 02:04 +1100
      Re: Python modules Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-14 08:27 -0800
      Re: Python modules Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-14 08:27 -0800
        Re: Python modules Grant Edwards <invalid@invalid.invalid> - 2013-01-14 19:48 +0000

#36790 — Python modules

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?

[toc] | [next] | [standalone]

#36792

On Mon, 14 Jan 2013 15:54:27 +0100, zoom wrote:

> 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

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

[toc] | [prev] | [next] | [standalone]

#36793

On 01/14/2013 04:01 PM, Dan Sommers wrote:
> On Mon, 14 Jan 2013 15:54:27 +0100, zoom wrote:
>
>> 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...

[toc] | [prev] | [next] | [standalone]

#36794

On Tue, Jan 15, 2013 at 1:54 AM, zoom <zoom@yahoo.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#36797

On Monday, January 14, 2013 9:04:00 AM UTC-6, Chris Angelico wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#36798

On Monday, January 14, 2013 9:04:00 AM UTC-6, Chris Angelico wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#36815

On 2013-01-14, Rick Johnson <rantingrickjohnson@gmail.com> wrote:

> 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".

-- 
Grant Edwards               grant.b.edwards        Yow! Your CHEEKS sit like
                                  at               twin NECTARINES above
                              gmail.com            a MOUTH that knows no
                                                   BOUNDS --

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web