>>> os.path.basename('http://example.com/file.txt')
'file.txt'
.. and I thought os.path.*
work only on local paths and not URLs? Note that the above example was run on Windows too .. with similar result.
>>> os.path.basename('http://example.com/file.txt')
'file.txt'
.. and I thought os.path.*
work only on local paths and not URLs? Note that the above example was run on Windows too .. with similar result.
On windows, look at the source code: C:\Python25\Lib\ntpath.py
def basename(p):
"""Returns the final component of a pathname"""
return split(p)[1]
os.path.split (in the same file) just split "\" (and sth. else)
Use the source Luke:
def basename(p):
"""Returns the final component of a pathname"""
i = p.rfind('/') + 1
return p[i:]
Edit (response to clarification):
It works for URLs by accident, that's it. Because of that, exploiting its behaviour could be considered code smell by some.
Trying to "fix" it (check if passed path is not url) is also surprisingly difficult
www.google.com/test.php
[email protected]/12
./src/bin/doc/goto.c
are at the same time correct pathnames and URLs (relative), so is the http:/hello.txt
(one /, and only on linux, and it's kinda stupid :)). You could "fix" it for absolute urls but relative ones will still work. Handling one special case in differently is a big no no in the python world.
To sum it up: import this
Why? Because it's useful for parsing URLs as well as local file paths. Why not?
In practice many functions of os.path
are just string manipulation functions (which just happen to be especially handy for path manipulation) -- and since that's innocuous and occasionally handy, while formally speaking "incorrect", I doubt this will change anytime soon -- for more details, use the following simple one-liner at a shell/command prompt:
$ python -c"import sys; import StringIO; x=StringIO.StringIO(); sys.stdout=x; import this; sys.stdout = sys.__stdout__; print x.getvalue().splitlines()[10][9:]"