homepage

My suggestion is to add somewhere in the configuration dialog when users
can enter a block of Python code to be executed at startup and whenever
Restart Shell is executed.
Use case: for people who use IDLE for calculations/experiments they
might like to always have certain module imported. For me personally, it
would be:
 import os
 import re
 import sys
 from math import *
but of course the whole point is that people can write any code they
like. (Some people might want to do various from __future__ imports in
Python 2.6 to get various Python 3 features for example.)
I know that you can use the -c option, but that only works at startup,
not every time you Restart Shell.

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 #5233 patch.)

This issue should include any startup configuration, such as making '-s' automatic (see #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.
1. Make it possible to run Shell startup code when IDLE is not started from the command line, which it usually is not, and without adding a separate startup script and icon. The two subproposals are storing in IDLE's user config either a filename (which file could also be used without IDLE) or a code block. I am willing to do both. 
2. Make it possible to run the new Shell startup code each time Shell starts without running editor code. I don't want to do 1. without 2., and I don't want to make re-running possibly only for new sources. I propose that we first fix re-running for existing sources, as described above, so that when 1. is done after, 2. easily follows.
===
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.