Should I use `import os.path` or `import os`?

Question

According to the official documentation, os.path is a module. Thus, what is the preferred way of importing it?

# Should I always import it explicitly?
import os.path

Or...

# Is importing os enough?
import os

Please DON'T answer "importing os works for me". I know, it works for me too right now (as of Python 2.6). What I want to know is any official recommendation about this issue. So, if you answer this question, please post your references.

Answer 1

os.path works in a funny way. It looks like os should be a package with a submodule path, but in reality os is a normal module that does magic with sys.modules to inject os.path. Here's what happens:

• When Python starts up, it loads a bunch of modules into sys.modules. They aren't bound to any names in your script, but you can access the already-created modules when you import them in some way.

  • sys.modules is a dict in which modules are cached. When you import a module, if it already has been imported somewhere, it gets the instance stored in sys.modules.

• os is among the modules that are loaded when Python starts up. It assigns its path attribute to an os-specific path module.

• It injects sys.modules['os.path'] = path so that you're able to do "import os.path" as though it was a submodule.

I tend to think of os.path as a module I want to use rather than a thing in the os module, so even though it's not really a submodule of a package called os, I import it sort of like it is one and I always do import os.path. This is consistent with how os.path is documented.

---

Incidentally, this sort of structure leads to a lot of Python programmers' early confusion about modules and packages and code organization, I think. This is really for two reasons

1. If you think of os as a package and know that you can do import os and have access to the submodule os.path, you may be surprised later when you can't do import twisted and automatically access twisted.spread without importing it.

2. It is confusing that os.name is a normal thing, a string, and os.path is a module. I always structure my packages with empty __init__.py files so that at the same level I always have one type of thing: a module/package or other stuff. Several big Python projects take this approach, which tends to make more structured code.

Answer 2

I agree with Mike

I think

import os is fine.

You just then have to mention details like this

os.path()

or if you are calling a module within a module

os.path.exists()

Answer 3

Couldn't find any definitive reference, but I see that the example code for os.walk uses os.path but only imports os

Answer 4

Common sense works here: os is a module, and os.path is a module, too. So just import the module you want to use:

• If you want to use functionalities in the os module, then import os.

• If you want to use functionalities in the os.path module, then import os.path.

• If you want to use functionalities in both modules, then import both modules:

  import os
  import os.path
  

For reference:

• Lib/idlelib/rpc.py uses os and imports os.

• Lib/idlelib/idle.py uses os.path and imports os.path.

• Lib/ensurepip/init.py uses both and imports both.

Answer 5

As per PEP-20 by Tim Peters, "Explicit is better than implicit" and "Readability counts". If all you need from the os module is under os.path, import os.path would be more explicit and let others know what you really care about.

Likewise, PEP-20 also says "Simple is better than complex", so if you also need stuff that resides under the more-general os umbrella, import os would be preferred.

Answer 6

Definitive answer: import os and use os.path. do not import os.path directly.

From the documentation of the module itself:

>>> import os
>>> help(os.path)
...
Instead of importing this module directly, import os and refer to
this module as os.path.  The "os.path" name is an alias for this
module on Posix systems; on other systems (e.g. Mac, Windows),
os.path provides the same operations in a manner specific to that
platform, and is an alias to another module (e.g. macpath, ntpath).
...