This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Michel Desmoulin, ammar2, gregory.p.smith, ncoghlan, r.david.murray, vstinner, xtreak, yselivanov
Date 2019-10-24.14:38:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> To help address the original report filing issue, we could add a notion of .co_cwd to code objects for use in resolving co_filename.  Allow it to be '' if getcwd failed at source load time.  Code could check if co_cwd exists and join it with the co_filename.  Also let co_cwd remain empty when there is no valid co_filename for the code.

Do you mean that co_filename attribute of code objects must remain relative?

> Preaching: Code that calls os.chdir() is always a potential problem as it alters process global state.  That call is best avoided as modifying globals is impolite.

I thought that calling os.chdir("/") is a good practice when launching a program as a daemon. And thne call os.fork() twice to detach the process from its parent and run it in background.

I commonly use os.chdir() in my programs for various reasons. A classical use case is to mimick a shell script doing something like (cd $DIRECTORY; command): temporary change the current directory.

cwd parameter of subprocess.Popen helps to avoid changing the currently directory, but sometimes subprocess is not used at all.

Maybe avoiding os.chdir() is a good practice, but it's hard to prevent users to call it. I don't see how os.chdir() is bad by design. I'm not sure that it's really useful to debate this neither :-)
Date User Action Args
2019-10-24 14:38:54vstinnersetrecipients: + vstinner, gregory.p.smith, ncoghlan, r.david.murray, yselivanov, Michel Desmoulin, ammar2, xtreak
2019-10-24 14:38:54vstinnersetmessageid: <>
2019-10-24 14:38:54vstinnerlinkissue20443 messages
2019-10-24 14:38:53vstinnercreate