Any adv. in importing a module and some objects in the samemodule, into the same file?

[Visco Shaun]

http://docs.python.org/library/logging.html

While going thr' the above link i came across import statements
"import logging
import logging.handlers"

What is the use of second import as the first import will be
enough(AFAIK) to access anything intended by the second import?
Is there any kind of advantage?

 

[Piet van Oostrum]

VS> http://docs.python.org/library/logging.html
VS> While going thr' the above link i came across import statements
VS> "import logging
VS> import logging.handlers"

VS> What is the use of second import as the first import will be
VS> enough(AFAIK) to access anything intended by the second import?
VS> Is there any kind of advantage?

Have you tried?
Traceback (most recent call last):

'logging' is a package. The 'logging' module does not contain a
definition of 'handlers' but there is a module 'handlers' in the 'logging'
directory.

 

[alex23]

What is the use of second import as the first import will be
enough(AFAIK) to access anything intended by the second import?
Is there any kind of advantage?

While Piet's explanation is correct for the logging module, you'll
also see examples like:

import os
import os.path

Where os.path _is_ accessible via the original os import.

I believe that in this case, os.path is imported and stored against
'os.path', so any further references to it will be handled by the
standard module lookup, rather than having to look up the 'os' import
and then use getattr to reach path. I would expect that this is mostly
of interest if you were using os.path.methods in an inner loop, to
reduce the number of lookups.

 

[Gabriel Genellina]

While Piet's explanation is correct for the logging module, you'll
also see examples like:

import os
import os.path

Where os.path _is_ accessible via the original os import.

logging is a package, and os is just a module. Usually you *cannot* write
`import foo.bar` when foo is not a package, so `import os.path` would
normally be an error. But the os module explicitely adds "os.path" to
sys.modules so it becomes valid.
That really confused me a lot when I started using Python.

I believe that in this case, os.path is imported and stored against
'os.path', so any further references to it will be handled by the
standard module lookup, rather than having to look up the 'os' import
and then use getattr to reach path.

(os.path is *not* a typical example!)

If you write `print os.path.dirname(...)` then the name "path" is looked
into the os module as any other attribute. But if you use `import os.path
as path` or `from os import path` then the name "path" can be used
directly as in "print path.dirname(...)"

I would expect that this is mostly
of interest if you were using os.path.methods in an inner loop, to
reduce the number of lookups.

In that case I'd assign the desired function to a local name, to avoid any
name lookup inside the loop.