The os. path module is a very extensively used module that is handy when processing files from different places in the system. It is used for different purposes such as for merging, normalizing and retrieving path names in python .
The os.path module is always the path module suitable for the operating system Python is running on, and therefore usable for local paths. However, you can also import and use the individual modules if you want to manipulate a path that is always in one of the different formats.
path module is sub module of OS module in python used for common path name manipulation. os. path. exists() method in Python is used to check whether the specified path exists or not. This method can be also used to check whether the given path refers to an open file descriptor or not.
path. getmtime() method in Python is used to get the time of last modification of the specified path. This method returns a floating point value which represents the number of seconds since the epoch. This method raise OSError if the file does not exist or is somehow inaccessible.
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
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.
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.
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.
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).
...
Interestingly enough, importing os.path will import all of os. try the following in the interactive prompt:
import os.path
dir(os)
The result will be the same as if you just imported os. This is because os.path will refer to a different module based on which operating system you have, so python will import os to determine which module to load for path.
reference
With some modules, saying import foo
will not expose foo.bar
, so I guess it really depends the design of the specific module.
In general, just importing the explicit modules you need should be marginally faster. On my machine:
import os.path
: 7.54285810068e-06
seconds
import os
: 9.21904878972e-06
seconds
These times are close enough to be fairly negligible. Your program may need to use other modules from os
either now or at a later time, so usually it makes sense just to sacrifice the two microseconds and use import os
to avoid this error at a later time. I usually side with just importing os as a whole, but can see why some would prefer import os.path
to technically be more efficient and convey to readers of the code that that is the only part of the os
module that will need to be used. It essentially boils down to a style question in my mind.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With