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: execute stored startup code on each Shell start. #49844
Comments
My suggestion is to add somewhere in the configuration dialog when users Use case: for people who use IDLE for calculations/experiments they import os
import re
import sys
from math import * but of course the whole point is that people can write any code they I know that you can use the -c option, but that only works at startup, |
Editing a block of code from inside the config dialog (and storing it in the config file?) seems a bad idea because you lose all the power of the normal IDLE editor. Instead, you should edit the startup code in the editor, save it to a file and point the IDLESTARTUP or PYTHONSTARTUP environment variable to it (http://docs.python.org/library/idle.html#startup). [Unfortunately, these envvars currently don't work after restart; http://bugs.python.org/issue5233 has patches to fix that.] What does make sense is having a way to set the startup file from the config dialog, instead of environment variables. I suspect nobody cares enough to implement this if you don't. |
(Another point I forgot to mention is that you must also run idle with the -s command-line option to look at these envvars. This was silly and is also fixed by the bpo-5233 patch.) |
This issue should include any startup configuration, such as making '-s' automatic (see bpo-5233). There is no way to pass that when clicking an icon or selecting 'Open with Idle' on a context menu. At present, the General tab has just 'Open edit window' *or* 'Open shell window'. There should should be a new Startup tab. There would then be room for a Text widget, which would be sufficient for simple scripts, such as Mark's example. This would be friendlier than a separate file for people who do not even know what a console is. Because user config files are (currently) used for all versions, we would have to make sure that default and user config files with the new sections still worked with older versions, and that older versions ignore and do not remove the new section. |
I created a pull request for this ticket. I did not include any of the other issues/tickets for using the command line information on restart or any of the issues with running certain code. I also added template code to be used in a new editor window. It made the Startup tab look nicer. :-) |
Currently, Shell start and restart act differently. Start can execute one of -s file, -c command, or neither (and there are other command line options). Restart prints a RESTART separator banner and optionally runs an edit buffer, but ignores all or most command-line options. I would like to try to solve this and related issues by simplifying pyshell so that there is a uniform user process startup, rather than initial start and later restart. Shell would always print a START header banner, adjusted according to which, if any, pre-defined code it was going to run, run the code, and then print a prompt for interactive input. My hesitation about making -s or -c repeat, expressed on another issue, is that someone might want stop repeating with exiting. I think an adequate solution would be a new section of the Shell menu with radio buttons such as () No startup, () Start file, and () Start command, with inapplicable choices grayed out. The above should be a separate new issue and a dependency of this one. This issue has 2 parts.
About the patch: You picked a non-trivial issue ;-), and review will not be quick. Could you list the 'other issues'? Even if they are handled later with separate PRs (if not rejected) I want to have them in mind before doing this. For instance, they may affect my idea of how we should split the General tab. I am not sure whether I have ever tested that -s, for instance, works correctly. Certainly not recently. User code must be exec'ed within the run process by run.py code and not run in main's global context by python. This is why I am unsure about using -c, as that should do the latter before run code takes over. Editor template code is different issue. I think it needs separate discussion, with consideration of how other editors work. AFAIK, there is no existing issue, so a new one is needed. My own use case, is for a separate project where most files, but not all, start with a template. Currently with IDLE, I open the template and immediately save with the new name. If I could instead start with a blank and insert the template, I could not accidentally overwrite. With multiple projects, I would probably want multiple templates. The File menu could have a entry such as 'New, with template'. I have expected to split the General tab. I was thinking there should be a new 'Editor' tab, which would seem to be the place for editor template information. I think both template file(s) and a config template block should be options. For code entry, whether startup code or template, the patch uses a Text widget with scrollbar added. I believe tkinter already has such. However, I agree with Cherniavsky that an IDLE editor would be even better. However, we really need a small editor frame, with no menu, rather than a separate window. The OK and Apply buttons would 'save' the contents. I have already intended to factor a subclassable editor frame out of EditorWindow. (I have also thought of using a subclass of such as the code entry area for Shell.) Startup and template code would be two other uses. |
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: