Why doesn't Python remember the initial directory?
no.email at please.post
Mon Aug 20 03:57:46 CEST 2012
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>
>> 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
>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.
frame = inspect.currentframe()
os.chdir('/some/other/directory') # where '/some/other/directory' is
# different from the initial directory
% python demo.py
Traceback (most recent call last):
File "demo.py", line 11, in <module>
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
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.
More information about the Python-list