On 03/05/10 15:55, Grant Edwards wrote:
On 2010-05-03, Baz Walter<baz...@ftml.net> wrote:
On 03/05/10 14:56, Chris Rebert wrote:
but how does '..' get resolved in the relative path '../abc.txt'? i'm
assuming python must initially use getcwd() internally to do this, and then
if that fails it falls back on something else. but what is that something
else? is it something that is reproducible in pure python?
I would think that the OS system call, not Python itself, does the
relative->absolute conversion.
so there is a discrepancy between some of the std library path functions
(like realpath, getcwd, abspath) and the built-in open function.
Not really. There is a discrepancy between your perception and
expectations and the way the Unix filesystem works.
it's a fact that realpath/abspath/normpath etc can fail for paths that
don't when used with os.stat or the builtin open function. i think it's
reasonable to expect that a path that can be used to successfully open a
file wont then produce "No such file or directory" errors when used with
an os.path function like realpath. it shouldn't be necessary to have
detailed knowledge of the underlying filesytem to be able to use os.path
- it's supposed to be generic.
there are files which can be opened for which it is impossible to
resolve their full paths (on some platforms).
Sort of. The file in question _has_ a full path, you just can't tell
what it is based on the path you used to open it.
yes, that's exactly what i was trying to demonstrate in my OP. i can use
python to open a file; but under certain circumstances, there seems to
be no guarantee that i can then use python to locate that file in the
filesystem.
--
http://mail.python.org/mailman/listinfo/python-list
