Why doesn't Python remember the initial directory?

Mark Lawrence breamoreboy at yahoo.co.uk
Mon Aug 20 03:10:14 EDT 2012


On 20/08/2012 02:57, kj wrote:
> In <roy-CA6D77.17031119082012 at news.panix.com> Roy Smith <roy at panix.com> writes:
>
>> In article <k0rj38$2gc$1 at reader1.panix.com>, kj <no.email at 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.




More information about the Python-list mailing list