Do more imported objects affect performance

  • Thread starter Filip GruszczyÅ„ski
  • Start date
F

Filip Gruszczyński

I have following question: if I use

from module import *

instead

from module import Class

am I affecting performance of my program? I believe, that all those
names must be stored somewhere, when they are imported and then
browsed when one of them is called. So am I putting a lot of "garbage"
to this storage and make those searches longer?
 
R

Rafe

I have following question: if I use

from module import *

instead

from module import Class

am I affecting performance of my program? I believe, that all those
names must be stored somewhere, when they are imported and then
browsed when one of them is called. So am I putting a lot of "garbage"
to this storage and make those searches longer?

Why use it if you don't need it? Your post implies a choice and the
'*' import can really make things muddy if it isn't actually necessary
(rare). Why not just import the module and use what you need? It is
way easier to read/debug and maintains the name-space.

- Rafe
 
N

Nick Craig-Wood

I always prefer to use import module and then use module.function. The
reason is simple. It makes the code more readable and maintainable.

I prefer the "from module import function". That means that if
"module" doesn't supply "function" it raises an exception at compile
time, not run time when you try to run "module.function". It then
becomes very easy to see which functions you use from any given module
too. It is also very slightly faster but that isn't a major
consideration.

PEP 8 endorses this style somewhat

http://www.python.org/dev/peps/pep-0008/ - see the Imports section.

[...]

it's okay to say this though:

from subprocess import Popen, PIPE

[...]

When importing a class from a class-containing module, it's usually
okay to spell this

from myclass import MyClass
from foo.bar.yourclass import YourClass

If this spelling causes local name clashes, then spell them

import myclass
import foo.bar.yourclass

and use "myclass.MyClass" and "foo.bar.yourclass.YourClass"

Ultimately it is a matter of taste I think!
 
B

Bruno Desthuilliers

Nick Craig-Wood a écrit :
I prefer the "from module import function". That means that if
"module" doesn't supply "function" it raises an exception at compile
time, not run time when you try to run "module.function".

Nope. import is an executable statement, and ImportError happens at
runtime too.
 
S

Steven D'Aprano

I prefer the "from module import function". That means that if "module"
doesn't supply "function" it raises an exception at compile time, not
run time when you try to run "module.function".

Wanna bet?

.... from math import harmonic_series
.... return harmonic_series()
.... 2 0 LOAD_CONST 1 (-1)
3 LOAD_CONST 2 (('harmonic_series',))
6 IMPORT_NAME 0 (math)
9 IMPORT_FROM 1 (harmonic_series)
12 STORE_FAST 0 (harmonic_series)
15 POP_TOP

3 16 LOAD_FAST 0 (harmonic_series)
19 CALL_FUNCTION 0
22 RETURN_VALUETraceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in spam
ImportError: cannot import name harmonic_series


The same thing happens if the from...import is at the top level of the
module, except that compilation is immediately followed by execution.

It then becomes very
easy to see which functions you use from any given module too.

If that's important to you. Personally, I find it more useful to know
where a function is defined.
 
S

Steve Holden

Filip Gruszczyński wrote:
[something I moved to after Nick's reply, where it belongs]
I see. Thanks for a really good explanation, I like to know, how to do
things in the proper way :)
Pardon me for intruding, but timings here are entirely the wrong focus
for a Python newcomer. Given that imports are super-optimized (i.e. the
code in the module is only performed once) such a small difference in
timing is inconsequential, I would suggest.

As long as "from module import *" is only ever used with modules
specifically designed to support it, the other forms can be used as
required. Sure, there is a timing difference between

import module
...
module.something()

and

from module import something
...
something()

but that's hardly the point. Learning to write sound Python is *much*
more important that learning to write fast Python, and often the two
coincide anyway.

It was true when Kernighan and Plauger wrote it forty years ago and it's
true now: "First, make it work. Then, *if it doesn't work fast enough*,
make it work faster".

regards
Steve
 
N

Nick Craig-Wood

Pardon me for intruding, but timings here are entirely the wrong focus
for a Python newcomer. Given that imports are super-optimized (i.e. the
code in the module is only performed once) such a small difference in
timing is inconsequential, I would suggest.

As long as "from module import *" is only ever used with modules
specifically designed to support it, the other forms can be used as
required. Sure, there is a timing difference between

import module
...
module.something()

and

from module import something
...
something()

but that's hardly the point. Learning to write sound Python is *much*
more important that learning to write fast Python, and often the two
coincide anyway.

It was true when Kernighan and Plauger wrote it forty years ago and it's
true now: "First, make it work. Then, *if it doesn't work fast enough*,
make it work faster".

You are 100% right of course Steve. I was just trying to answer the
specific question "which is faster" question which probably isn't
helpful for new Python programmers to focus on.

PS I enjoyed your book :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top