Reputation: 475
Most of the tutorials and books about Django or Flask import specific classes from files instead of importing the whole file.
For example, importing DataRequiered
validator from wrtforms.validators
is done via from wtforms import validators
instead of importing it via import wtforms.validators as valids
and then accessing DataRequiered
with valids.DataRequiered
.
My question is: Is there an reason for this ?
I thought to something like avoiding the loading a whole module for computation/memory optimization (is it really relevant?) ? Or is it simply to make the code more readable ?
Upvotes: 1
Views: 528
Reputation: 77912
My question is: Is there an reason for this ?
from module_or_package import something
is the canonical pythonic idiom (when you only want to import something
in your current namespace of course).
Also, import module_or_package.something
only works if module_or_package
is a package and something
a submodule, it raises an ImportError(No module named something)
if something
is a function, class or whatever object defined in module_or_package
, as can be seen in the stdlib with os.path
(which is a submodule of the os.package
) vs datetime.date
(which is a class defined in the datetime
module):
>>> import os.path as p
>>> p
<module 'posixpath' from '/home/bruno/.virtualenvs/blook/lib/python2.7/posixpath.pyc'>
vs
>>>import datetime.date as d
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named date
thought to something like avoiding the loading a whole module for computation/memory optimization (is it really relevant?)
Totally irrelevant - importing a given name from a module requires importing the whole module. Actually, this:
from module_or_package import something
is only syntactic sugar for
import module_or_package
something = module_or_package.something
del module_or_package
EDIT: You mention in a comment that
Right, but importing the whole module means loading it to the memory, which can be a reason for importing only a submodule/class
so it seems I failed to make the point clear: in Python, you can not "import only a submodule/class", period.
In Python, import
, class
and def
are all executable statements (and actually just syntactic sugar for operation you can do 'manually' with functions and classes). Importing a module actually consists in executing all the code at the module's top-level (which will instanciate function
and class
objects) and create a module
object (instance of module
type) which attributes will be all names defined at the top-level via import
, def
and class
statements or via explicit assignment. It's only when all this has been done that you can access any name defined in the module, and this is why, as I stated above,
from module import obj
is only syntactic sugar for
import module
obj = module.obj
del module
But (unless you do something stupid like defining a terabyte-huge dict or list in your module) this doesn't actually take that much time nor eat much ram, and a module is only effectively executed once per process the first time it's imported - then it's cached in sys.modules
so subsequent imports only fetch it from cache.
Also, unless you actively prevents it, Python will cache the compiled version of the module (the .pyc files) and only recompile it if the .pyc is missing or older than the source .py file.
wrt/ packages and submodules, importing a submodule will also execute the package's __init__.py
and build a module
instance from it (IOW, at runtime, a package is also a module
). Package initializer are canonically rather short, and actually quite often empty FWIW...
Upvotes: 1
Reputation: 140
It depends, in the tutorial that was probably done for readability
Usually if you use most of the classes in a file, you import the file. If the files contains many classes but you only need a few, just import those. It's both a matter of readability and optimization.
Upvotes: 0