-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDLE: Cleanup config code #71639
Comments
The config module code can be improved even without changing behavior. While working on bpo-27380, I noticed these two: IdleUserConfParser.RemoveFile is a simple one-liner called once. Put it inline. IdleConf.CreateConfigHandlers: A) As near as I can tell, __file__ is now always the absolute path of the file regardless if executed directly or imported. B) Creating two dicts of file names that are immediately used and deleted is useless and to me makes the code less readable. I intend these changes only for 3.6 and will not apply until after the new unix keys patch. Serhiy, have you noticed any similar cleanups that would be appropriate to add? |
If config.py is just executed, __file__ can be a relative path. RemoveFile() looks as a part of public API. If you are sure that nobody needs to remove a config file, you can remove this method. |
How can you get a relative path in 3.6 (or other current Python)? To test, I wrote file.py containing "print(file)". Executing from IDLE, with "python path/to/file.py", "path/to/file.py", "file.py" in the path/to directory, and "python -m to.file" (where path is on sys.path) all resulted in the absolute path. After adding "input()" to suspend execution, double clicking in Explorer gives the same result. Have I forgotten something? Do any of these result is something different on Linux? (or Mac?, for that matter) The only reason to execute rather than import config.py is to run the test at the end of the file after editing the file. In the absence of a thorough automated test, I occasionally do so. The approximately 500 lines of output is too much to read in detail (although one might check one specific part), but that it runs and produces the same number of lines before and after a change is reassuring. I should add a line counter and checksum to the dump function. As for removing RemoveFile: idlelib in 3.6 is, with a few exceptions, a private API. |
$ ./python -m file
/home/serhiy/py/cpython/file.py
$ ./python file.py
file.py |
New changeset da83e115afea by Terry Jan Reedy in branch '2.7': New changeset 127569004538 by Terry Jan Reedy in branch '3.5': New changeset c2e21bc83066 by Terry Jan Reedy in branch 'default': |
New changeset adbeef96ae95 by Terry Jan Reedy in branch 'default': |
Ah, the invocation I did not test ;-). It does not matter in this case because "os.path.dirname('config.py')" is '' and the join leaves relative names for the config files that work fine for opening them. F:\Python\dev\36\Lib\idlelib>..\..\pcbuild\win32\python_d.exe config.py {'keys': <main.IdleConfParser object at 0x000002633B200080>, At one time, I thought, sys.path[0] was '', representing the current directory, and not the absolute path of the starting directory. I am not sure if there are any cross platform, cross implementation, guarantees. There are 12 other idlelib files using __file__. I ran each in either idlelib or idle_test as appropriate. 11 run. test_help.py fails at this line (which I wrote) The comment in config appears to refer to the exec command/function. I don't know what either does with __name__, __file__, or sys.path. --- |
In this case it works, because os.join('', filename) returns filename. |
As near as I can tell, 'python file.py' results in absolute __file__ in 3.9 versus still relative in 3.8. |
Thanks for preparing the PR. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: