[Tutor] Confused "from module import Name" better than "importmodule"?

Andreas Kostyrka andreas at kostyrka.org
Wed Jul 13 07:56:39 CEST 2005


Personally the type of import statement depends upon the module
imported, the use of the module and personal preferences.


from Module import *

produces certainly the danger of namespace pollution, and should be used
if at all only with pervasive modules that are designed to be used this
way. Typical examples where this is done this way include GUI modules
like Tkinter. The module imported this way should provide a __all__
declaration.

In many cases if the module imported is of huge importance to the
importing module, one might use renaming as the solution:
import module as m or import module ; m = module


from Module import Name, Name2, ...

Might be used if it's clear what Name, Name2 will do. 

import Module

Minimizes the namespace pollution.

Basically there are the following "objective" rules:

a) "from module import *" is bad because of the uncontrolled (from the
client side) name space pollution. Use only with caution with modules
designed to be used this way.

b) "from module import name" and "import module" are basically about as
acceptable, but the "from" form does have technical problems with
circular references, as it basically requires module to load completely.
"import" on the other hand can bind an incomplete module, and in this
way allows for circular references.

c) import "module" provides a much stronger decoupling. It's easier to
find all module objects in all modules and replace them than find all
names that got imported from a different module.

d) Python is basically a language that is dynamic and that provides
quite a deal of introspection and manipulation at runtime. For example
one can use imports in try/except blocks like this:
try:
    import cPickle as Pickle
except ImportError:
    import Pickle

or even more dynamic funnier:

dbmodule = __import__(db_name_to_use)

e) import statements can happen at any level -> if an import is used
only in rare cases it might make sense to include it inside a def.

f) If "absolute" performance is wanted, the usual way is to include
needed names into the local namespace of a function via default
arguments. This way you get the name "for free" into the local namespace
and local accesses are the fastest in Python:

def some_func(param1, param2,
some_really_important_external_func=module.func):

Andreas




Am Montag, den 11.07.2005, 21:06 +0100 schrieb Alan G:
> > I'm confused. I was just reading the URL below..
> >
> > http://jaynes.colorado.edu/PythonGuidelines.html
> 
> Me too. :-)
> 
> > and this statement confused me: "Always use from module import Name, 
> > Name2, Name3.. syntax instead of import module or from module import 
> > *. This is more efficient, reduces typing in the rest of the code, 
> > and it makes it much easier to see name collisions and to replace 
> > implementations."
> 
> The efficiency gain is negligible.
> The typing can be better reduced by using
> 
> import modulename as m
> 
> And it definitley doesn't make it easier to see name collisions, they 
> will
> just silently collide and one or the other name will be hidden with
> strange results!
> 
> > To me, import module is more explicit.
> 
> Undeniably so!
> 
> > It seems to easier to read CoolModule.niceFunction() than just 
> > niceFunction().
> 
> Easier to read but slightly harder to type. Personally I can live with 
> it!
> 
> Alan G. 
> 
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.python.org/pipermail/tutor/attachments/20050713/c8107235/attachment-0001.pgp


More information about the Tutor mailing list