I just wanna know about os.path module..

[kimes]

I've just started digging into how python works..
I found that other mudules are clearly declared like one file per a
module..

But the only os.path doesn't have their own file..
ye I know is has actually depending on os like in my case posixpath..

What I'd love to know is..
when I call import os.path..
how happened under the hood?

I'm currently using python 2.4 in linux machine..
I'd appreciate it

 

[James]

I've just started digging into how python works..
I found that other mudules are clearly declared like one file per a
module..

But the only os.path doesn't have their own file..
ye I know is has actually depending on os like in my case posixpath..

What I'd love to know is..
when I call import os.path..
how happened under the hood?

I'm currently using python 2.4 in linux machine..
I'd appreciate it

See line 5 of os.py (comment)
- os.path is one of the modules posixpath, ntpath, or macpath
It says it sets os.path depending on the platform

and does so in line 132
sys.modules['os.path'] = path

In your case, os.path should be implemented in posixpath.py
See line 48 to see where it came from

In short, "use the source, Luke"
especially when Python is exceptionally readable.

 

[Peter Otten]

But the only os.path doesn't have their own file..
ye I know is has actually depending on os like in my case posixpath..

What I'd love to know is..
when I call import os.path..
how happened under the hood?

At first os - module, or package, it doesn't matter here - is imported.
In its code, it detects the proper path module and imports it. The module
cache is then manipulated and the name 'path' is bound to posixpath, too:

sys.modules["os.path"] = posixpath
path = posixpath

The second stage of the import then reduces to just a lookup in the cache
instead of a search for the inexistent .../os/path.py in the filesystem.

Both the module attribute and the cache update are necessary when you want
to pull off similar tricks. Here is an example of the odd behaviour that
results from them being out of sync:
set(['pardir', 'sameopenfile', 'exists', 'sep', 'splitext', 'basename',
'walk', 'expandvars', 'old_globals', 'expanduser', 'getmtime', 'defpath',
'dirname', 'isfile', 'supports_unicode_filenames', 'pathsep', 'getsize',
'samestat', 'split', 'devnull', 'islink', 'curdir', 'samefile', 'realpath',
'commonprefix', 'abspath', 'normcase', 'getatime', 'isdir', 'join',
'altsep', 'getctime', 'isabs', 'normpath', 'ismount', 'splitdrive',
'extsep'])

Peter

 

[gene tani]

look at 'path' module too

http://www.jorendorff.com/articles/python/path/

 

[kimes]

Thanks for all you guys help..

But Peter,
You said 'At first os - module, or package, it doesn't matter here - is
imported.'

I'm still confused about that..
When I just call import os.path without calling import os..
In that case, you mean 'import os' is called implicitly?
Why? and How?

how python knows it should call import when we call import os?
Please make me clear..
Thanks..

 

[Terry Hancock]

Thanks for all you guys help..
I'm still confused about that..
When I just call import os.path without calling import os..
In that case, you mean 'import os' is called implicitly?
Why? and How?

how python knows it should call import when we call import os?
Please make me clear..

All you have to do is

import os

Python "knows" to import "os.path" because "os" tells it to. That is
to say, somewhere in "os" is code (conceptually) like:

import path

The os.path module is a sub-module of os. What makes it
particularly interesting is only that it is not always the *same*
module -- the particular os.path module that is loaded is
determined by your architecture. On a POSIX system (including
Unix and Linux) it will actually be an alias for "posixpath", but
it will be something else on Windows and Macintosh systems.

OTOH, the same thing will happen if you say:

import os.path

since it must import "os" in order to get to "path". I don't
think that Python is guaranteed to load the entire contents
of such dotted imports, although it appears to do so for the
case of "os" (I believe it depends on the code in the module).

Occasionally you will find packages that require you to load
subpackages explicitly:

import mypackage
import mypackage.subpackage

but not with "os".

Oh, and what Peter Otten meant by
"module, or package, it doesn't matter here"
is that the two terms are roughly equivalent, although there
is an internal distinction -- a "module" is a single Python source
file, whereas a "package" is a directory of source files which are
set up to load like a single module. For the purposes of this
discussion, the two terms are basically interchangeable (we
really ought to have a single term that can mean either -- I usually
speak loosely of "modules" regardless of which way they are
actually defined).

 

[Peter Otten]

You said 'At first os - module, or package, it doesn't matter here - is
imported.'

With a file mop.py in your path

import mop

creates a module instance and executes mop.py to fill it with content --
classes, functions, whatever python objects you can think of -- and puts
that module instance into the sys.modules cache. With a file
mop/__init__.py, the process is the same except that the code to fill the
module is taken from the __init__.py file. Differences only appear when you
try to import submodules.

I'm still confused about that..
When I just call import os.path without calling import os..
In that case, you mean 'import os' is called implicitly?

Yes. Try it yourself with a package/submodule where __init__.py and
submodule.py just contain a print statement. I find such an experimental
approach often more convenient than haunting the docs.

Why? and How?

Because it's a sensible assumption that a submodule depends on its parent
package? Because it makes access of submodules as easy as attribute access
for any other object? Because it makes conditional imports easy (see
Terry's post)? Because it's the simplest approach that just works?

how python knows it should call import when we call import os?
Please make me clear..

Conceptually, when you have a module alpha.beta.gamma you need just a bit of
string processing. "alpha.beta.gamma".split() -- aah, I have to import
alpha, then alpha.beta, then alpha.beta.gamma... read the source for the
strategy that is actually taken if you really care.

Peter