From the reddit discussion and also the comments of my previous entry on import, 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, '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, 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'.)