strange interaction between open and cwd

[Baz Walter]

On 03/05/10 15:24, Grant Edwards wrote:
> On 2010-05-03, Baz Walter<bazwal at ftml.net>  wrote:
>> On 03/05/10 14:18, Chris Rebert wrote:
>>> Whether or not /home/baz/tmp/xxx/ exists, we know from the very
>>> structure and properties of directory paths that its parent directory
>>> is, *by definition*, /home/baz/tmp/ (just chop off everything after
>>> the second-to-last slash). I would assume this is what happens
>>> internally.
>>> How exactly this interacts with, say, moving the directory to a new
>>> location rather than deleting it, I don't know; again, it would quite
>>> likely be platform-specific.
>>
>> but how does '..' get resolved in the relative path '../abc.txt'?
>
> The current directory has an entry named '..' that points to the
> parent directory.
>
>> i'm assuming python must initially use getcwd() internally to do
>> this,
>
> Nope.  Python just passes the string '../abc.txt' to libc's open()
> function, and that in turn passes it on to the Unix/Linux open()
> syscall, when follows the link in the current working directory named
> '..'.
>
>> 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?
>
> None of this has anything at all to do with Python.

i think what i'm asking for is a python function that, given, say, a 
valid file descriptor, can return the file's full path. would such a 
thing even be possible?