== More on those Python import oddities

From the [[reddit discussion
http://www.reddit.com/r/Python/comments/e5vyp/how_ospath_exposes_some_python_import_weirdness/]]
and also the comments of my [[previous entry on _import_ ImportOddities]],
I learned that people both do '_import os.path_' and then use
os.whatever without explicitly importing _os_, and do '_import os_'
and then just use os.path.whatever without explicitly importing
_os.path_.

First off, I don't think that you should do either of these even if
(and when) they work, for _os_ or any other module. This is a stylistic
thing, but when doing imports I prefer to be explicit about what other
modules my code uses. Also, I don't like clever tricks like this because
they run a high risk of confusing people who read my code, and this
includes me in the future if I've forgotten this bit of arcane trivia by
then.

Both of these clearly work for _os_. But are they guaranteed to work in
general? The answer is half yes and half no.

As sort of discussed [[last time ImportOddities]], '_import x.y;
x.whatever_' is guaranteed to work because the semantics of useful
multi-level imports require it. '_import x.y_' is pointless if you cannot
resolve x.y.whatever afterwards, and in order to do that you must have
'_x_' in your namespace after the dust settles. So Python gives it
to you.

A more interesting question is whether '_import x; x.y.whatever_' is
guaranteed to work. The short answer is no, although I suspect that it
often will for relatively small modules. First off, modules that are
implemented as single Python files (as with _os_) have to make this
work; as discussed [[last time ImportOddities]], _x.y_ must be defined
after x.py has finished executing as part of the import process, because
there is no other way for the interpreter to find the x.y module.

For modules that are implemented as directories (with submodules as
either files or subdirectories) there is no requirement that the
module's ((__init__.py)) import the _y_ submodule for you. The tradeoff
is that importing submodules automatically makes '_from x import
*_' work as people expect, at the cost of loading potentially large
submodules that people are not going to use; the larger and less used
your set of submodules is, the more this matters. So you can sensibly
have a module that requires explicit imports of submodules, and indeed
there are modules in the Python standard library that work this way
(_xml_ is one example).

Now we come to a piece of _import_ trivia: ~~importing a submodule will
actually modify the parent module's namespace~~. If you do _import x.y_
(in any variant) and _y_ is not defined in _x_'s namespace, Python adds
it for you.  Once I thought about it, I realized that it had to work
this way if Python wanted to support submodules that had to be loaded by
hand, but I find it vaguely interesting that Python is willing to drop
things in another module's namespace for you as a result of stuff that
you do.

(This happens even if you do not get an explicit reference to _x_,
eg if you do '_import x.y as t_'.)