| msg108822 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-06-28 11:43 |
| os.chdir(path) is often used with os.getcwd() call and doesn't return anything. It can return the name of the directory before the change. prev = os.chdir(path) ... os.chdir(prev) Maybe it will also be possible to implement 'with' construct: with os.chdir(path): ... |
|
|
| msg108829 - (view) |
Author: Brian Curtin (brian.curtin) *  |
Date: 2010-06-28 13:30 |
| -0 for having os.chdir be responsible for the previous directory. I'm not too much against this, but it's very easily done in it's current state. -1 for making os.chdir into a context manager which reverts itself upon exit. There are a number of race conditions this would have to handle and I think it's better for something like this to be implemented by the user. For example, if the original directory gets removed while you are within the block, what is the best fallback directory to change to upon exit? For the standard library, I don't think we can answer that. |
|
|
| msg108835 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2010-06-28 15:45 |
| -1 on chdir returning a the directory name. -1 on having it as context manager. Both are non-intuitive and may not serve any utility value. This can be verified by looking the code at the places where these functions are currently used. Brian also mentions about the dangers in that approach. . |
|
|
| msg108841 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-06-28 16:50 |
| Brian, in case you remove previous directory - you will get the same exception that in the following code. prev = os.chdir(somepath) os.rmdir(prev) os.chdir(prev) Senthil, your arguments are strange. Both use cases are at least useful for me (if not intuitive). I also can't see how can I verify you assumptions by looking at the code. If you want to say that not every piece of code need to return to parent directory after chdir - that's pretty obvious. If you had a list of use cases for os.chdir() - I could go through them to mark where this can be used (or not). label:api |
|
|
| msg108845 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2010-06-28 17:14 |
| On Mon, Jun 28, 2010 at 04:50:12PM +0000, anatoly techtonik wrote: >I also can't see how can I verify you assumptions by looking at the code. In the python source: find -name "*.py" | xargs grep 'os.chdir' gives 143 instances of its usage. I looked a couple of them (subprocess.py, forking.py) and found that returning a value as per your suggestion would add in an additional line of code instead of any obvious advantage. |
|
|
| msg108849 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-06-28 17:40 |
| In addition, os functions tend to be thin wrappers around system functions, and the system chdir does not return the cwd. Thus we'd be adding code to chdir that would be executed every time it was called even though it would only be used occasionally. Given that it only saves one line of python code in those same restricted cases, this does not seem like a sensible addition. You can, of course, write your own function that does this. The same is true of the idea of a chdir context manager: you can trivially write your own if you don't care about the issues Brian raised. If you do care then we'd have to figure out how to handle those issues. And how to handle them is different on different OSes (and I'm not just talking about windows vs posix, either; what happens when you delete the cwd differs on the different unix flavors). |
|
|
| msg108868 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2010-06-28 21:04 |
| -1 on this functionality being in os, for the same reasons David mentions. I find both of these behaviors useful and I have small utility functions of my own that do the same (and ignore any errors). I'm not so sure they need to be in stdlib, though. As mentioned, you need to either handle the errors, or do what I do and just fail if any of these conditions arise. |
|
|
| msg108966 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-06-30 04:00 |
| Even though I think that crossplatform language should normalize underlying platform behaviour, you've convinced me. Unneeded extra code execution decides. I also found that in another scenario it is better to return wrapper for target directory to implement chained API similar to string handling. |
|
|
| msg191688 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2013-06-23 09:50 |
| ..and still I miss: with os.chdir(path): do_something() |
|
|
| msg191690 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2013-06-23 11:36 |
| The idea was discussed many times, and there are existing implementations: http://mail.python.org/pipermail/python-ideas/2013-January/018756.html http://www.astropython.org/snippet/2009/10/chdir-context-manager http://stackoverflow.com/questions/169070/python-how-do-i-write-a-decorator-that-restores-the-cwd ... The idea was rejected because it is "an anti-pattern" "encouraging a bad habit". The current working directory is something global, as locales on UNIX: in a multithreaded application, all threads would be affected by such change. It's better to work only with absolute paths and never call os.chdir(). |
|
|
| msg191695 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2013-06-23 13:21 |
| "an anti-pattern" and "encouraging a bad habit" are subjective non-arguments as long as they fail to answer why. With or without the helper you still write this code: prev = os.getcwd() os.chdir(SDKPATH) ... os.chdir(prev) And because os.chdir() doesn't do anything high-level, there is no place for the multithreading warning. |
|
|
| msg191697 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2013-06-23 13:32 |
| > "an anti-pattern" and "encouraging a bad habit" are subjective non-arguments as long as they fail to answer why. The reasons are explained in the python-idea thread. Please read it. > With or without the helper you still write this code: Adding more functions using os.chdir() would "encoure a bad habit". |
|
|
| msg191707 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2013-06-23 16:13 |
| On Sun, Jun 23, 2013 at 4:32 PM, STINNER Victor <report@bugs.python.org>wrote: > > STINNER Victor added the comment: > > > "an anti-pattern" and "encouraging a bad habit" are subjective > non-arguments as long as they fail to answer why. > > The reasons are explained in the python-idea thread. Please read it. > This operation is time consuming. I counted +5 votes for the idea and then it turned into some complicated reading. If you know the reasons, why can't you do good for other people and summarize them here? |
|
|
| msg191708 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2013-06-23 16:32 |
| I would prefer that Haypo spend his time contributing code to Python. If someone else wants to summarize the arguments in the thread for this issue, that would be great. Absent that, the link to the discussion is sufficient for the curious. In any case, the arguments already in this issue are sufficient. |
|
|
| msg191728 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2013-06-23 20:34 |
| > anatoly techtonik added the comment: >> The reasons are explained in the python-idea thread. Please read it. > > This operation is time consuming. I counted +5 votes for the idea and then > it turned into some complicated reading. > If you know the reasons, why can't you do good for other people and > summarize them here? I'm sure that other core developers already explained you how Python is developed. It's not because someone proposed an idea and he/she has 5 supporters that the idea will be implemented. If you want to change Python, you have to explain your usecase, others will ask you questions, you will have to answer to answer to questions and propose technical solutions. For this issue, many questions have no answer. (Just one example, the fact that os.chdir() is process-wide.) I don't know why I'm repeating myself, I already told you something like that at least once on another topic. It's just a lack of respect of answering "This operation is time consuming." If you don't respect the rules (understand how Python is developed), we cannot work together. |
|
|