In <roy-ca6d77.17031119082...@news.panix.com> Roy Smith <r...@panix.com> writes:
>In article <k0rj38$2gc$1...@reader1.panix.com>, kj <no.em...@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. -- http://mail.python.org/mailman/listinfo/python-list