Why doesn't Python remember the initial directory?

R

Roy Smith

Walter Hurry said:
It is difficult to think of a sensible use for os.chdir, IMHO.

It is true that you can mostly avoid chdir() by building absolute
pathnames, but it's often more convenient to just cd somewhere and use
names relative to that. Fabric (a very cool tool for writing remote
sysadmin scripts), gives you a cd() command which is a context manager,
making it extra convenient.

Also, core files get created in the current directory. Sometimes
daemons will cd to some fixed location to make sure that if they dump
core, it goes in the right place.

On occasion, you run into (poorly designed, IMHO) utilities which insist
of reading or writing a file in the current directory. If you're
invoking one of those, you may have no choice but to chdir() to the
right place before running them.
 
A

andrea crotti

2012/8/20 Roy Smith said:
It is true that you can mostly avoid chdir() by building absolute
pathnames, but it's often more convenient to just cd somewhere and use
names relative to that. Fabric (a very cool tool for writing remote
sysadmin scripts), gives you a cd() command which is a context manager,
making it extra convenient.

Also, core files get created in the current directory. Sometimes
daemons will cd to some fixed location to make sure that if they dump
core, it goes in the right place.

On occasion, you run into (poorly designed, IMHO) utilities which insist
of reading or writing a file in the current directory. If you're
invoking one of those, you may have no choice but to chdir() to the
right place before running them.


I've done quite a lot of system programming as well, and changing
directory is only a source of possible troubles in general.

If I really have to for some reasons I do this


class TempCd:
"""Change temporarily the current directory
"""
def __init__(self, newcwd):
self.newcwd = newcwd
self.oldcwd = getcwd()

def __enter__(self):
chdir(self.newcwd)
return self

def __exit__(self, type, value, traceback):
chdir(self.oldcwd)


with TempCd('/tmp'):
# now working in /tmp

# now in the original

So it's not that hard to avoid problems..
 
J

Jean-Michel Pichavant

kj said:
99.99% of Python programmers
will find that there's nothing wrong with behavior [snip]
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")
[snip]

Don't you find there's something wrong in applying your observation from
2 or 3 replies to your post to 99% of python programmer ? Moreover,
flaming people on their own mailing list won't do you any good, ever, in
any list.

To get back to your original question,
inspect.getmodule?
Docstring:
Return the module an object was defined in, or None if not found.

As getmodule may return None if not found, you need too handle that
case. There's possibly a weakness in the inspect module when changing
the current directory however nothing wrong with Python having the
remember the intial directory. If you need to remember it, do it youself
(or file a bug to inspect module authors).

JM
 
G

Grant Edwards

In said:
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__.

What makes you think that the file that contains the definition of
__main__ is the working directory on program startup? That's almost
never the case in my experience.

2) Why should a library expect to be able to access the file
containing the definition of __main__.
That's a weakness, IMO.

You must be in possession of some rather odd use cases. I've been
writing Python programs for something like 13 years, and I've never
felt any need to have either an immutable record of the startup
directory or access to the file containing the definition of __main__.
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.

If what you really want is access to the definition of __main__, what
does that have to do with the startup directory?

If you want to know where __main__ is, you can probably figure it out
from /proc/self/<something-or-other>
 
P

Piet van Oostrum

kj said:
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.

On Unix based systems there is no reliable way to find out this
information. So how could Python reliably supply this?
 
J

John Roth

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__.

If you want to find that, look up __main__ in sys.modules and then look at the __file__ attribute. You need to be a bit careful with this; the import machinery was rewritten for the upcoming 3.3 release, and there were several changes to the module information.

John Roth
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top