Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.mixmin.net!hq-usenetpeers.eweka.nl!81.171.88.15.MISMATCH!eweka.nl!lightspeed.eweka.nl!194.109.133.85.MISMATCH!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Subject: Re: Why doesn't Python remember the initial directory?
Date: Mon, 20 Aug 2012 08:10:14 +0100
References: <k0rj38$2gc$1@reader1.panix.com> <roy-CA6D77.17031119082012@news.panix.com> <k0s5iq$seh$1@reader1.panix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0
In-Reply-To: <k0s5iq$seh$1@reader1.panix.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3540.1345446515.4697.python-list@python.org>
Lines: 84
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:27467

On 20/08/2012 02:57, kj wrote:
> In <roy-CA6D77.17031119082012@news.panix.com> Roy Smith <roy@panix.com> writes:
>
>> In article <k0rj38$2gc$1@reader1.panix.com>, kj <no.email@please.post>
>> wrote:
>
>>> As far as I've been able to determine, Python does not remember
>>> (immutably, that is) the working directory at the program's start-up,
>>> or, if it does, it does not officially expose this information.
>
>> Why would you expect that it would?  What would it (or you) do with this
>> information?
>
>> More to the point, doing a chdir() is not something any library code
>> would do (at least not that I'm aware of), so if the directory changed,
>> it's because some application code did it.  In which case, you could
>> have just stored the working directory yourself.
>
> This means that no library code can ever count on, for example,
> being able to reliably find the path to the file that contains the
> definition of __main__.  That's a weakness, IMO.  One manifestation
> of this weakness is that os.chdir breaks inspect.getmodule, at
> least on Unix.  If you have some Unix system handy, you can try
> the following.  First change the argument to os.chdir below to some
> valid directory other than your working directory.  Then, run the
> script, making sure that you refer to it using a relative path.
> When I do this on my system (OS X + Python 2.7.3), the script bombs
> at the last print statement, because the second call to inspect.getmodule
> (though not the first one) returns None.
>
> import inspect
> import os
>
> frame = inspect.currentframe()
>
> print inspect.getmodule(frame).__name__
>
> os.chdir('/some/other/directory') # where '/some/other/directory' is
>                                    # different from the initial directory
>
> print inspect.getmodule(frame).__name__
>
> ...............
>
> % python demo.py
> python demo.py
> __main__
> Traceback (most recent call last):
>    File "demo.py", line 11, in <module>
>      print inspect.getmodule(frame).__name__
> AttributeError: 'NoneType' object has no attribute '__name__'
>
>
>
> I don't know of any way to fix inspect.getmodule that does not
> involve, directly or indirectly, keeping a stable record of the
> starting directory.
>
> But, who am I kidding?  What needs fixing, right?  That's not a
> bug, that's a feature!  Etc.
>
> By now I have learned to expect that 99.99% of Python programmers
> will find that there's nothing wrong with behavior like the one
> described above, that it is in fact exactly As It Should Be, because,
> you see, since Python is the epitome of perfection, it follows
> inexorably that any flaw or shortcoming one may *perceive* in Python
> is only an *illusion*: the flaw or shortcoming is really in the
> benighted programmer, for having stupid ideas about programming
> (i.e. any idea that may entail that Python is not *gasp* perfect).
> Pardon my cynicism, but the general vibe from the replies I've
> gotten to my post (i.e. "if Python ain't got it, it means you don't
> need it") is entirely in line with these expectations.
>

I see, I see, I get the picture.  You're in the "The OS is flawed so I 
expect the Python core developers to do my work for me by producing code 
that gets around every known flaw in every supported OS" club.  Somehow 
I don't think that will happen.

-- 
Cheers.

Mark Lawrence.