strange interaction between open and cwd

[Baz Walter]

On 03/05/10 15:55, Grant Edwards wrote:
> On 2010-05-03, Baz Walter<bazwal at 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.