After uninstalling Python 2.3.4 on my Windows 2000
workstation, I installed Python 2.4. Unfortunately,
IDLE refused to start up. I would just see some hard
drive activity, then nothing. 

Getting some help from the tutor list(Danny Yoo), I was
told to try...

import idlelib.PyShell
idlelib.PyShell.main()

from the Python command prompt.

IDLE fired up, but it complained about my color
theme(which I had created in Python 2.3.4).
Unfortunately, I do not have the errors/warnings. I
deleted the color theme from IDLE, and now IDLE fires
up without issue. The color theme must have been left
over from Python 2.3.4.

Logged In: YES 
user_id=149084

The (un)installer doesn't know about the user's .idlerc file.
There should not be any incompatiblility between 2.3.4 and
2.4 regarding the color themes.  It's too bad you didn't save
the error messages.  Could you describe exactly what you
mean by "I deleted the color theme?" .  What files or parts
of files were removed?

Logged In: YES 
user_id=1173237

From IDLE, I removed Deleted the Custom Theme. 
I will attempt to reproduce the issue and report on what
warnings and/or errors appear from the Python command line.

I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE.
Uninstall 2.3.4. Install 2.4 and see if I can capture the
warnings/errors.

Logged In: YES 
user_id=1173237

I was able to reproduce the problem. I'm attaching the
warning messages in a text file.

Logged In: YES 
user_id=149084

Thanks for the report.  I'll try to reproduce the problem myself.
What is supposed to happen is if IDLE has a problem 
retreiving the theme, it's supposed to load the default theme
from config-highlight.def and if that fails it's supposed to
use a fallback theme written into the code itself.  Clearly
all this complexity isn't working too well, and the error
messages aren't particularly helpful.

Logged In: YES 
user_id=149084

This bug was caused by adding the colorization of built-in
keywords.  The current design of the themes and keybindings
in the configuration system saves the entire modified config
file instead of just the changes.  When IDLE tried to load your
config-highlight.cfg it got out of sync and died miserably.

An initial fix would be to fix the config system to load the
default bindings (as intended) when there was a problem
with the user binding.

But to fully fix the problem and make the config system
robust, it appears to be necessary to redesign it to save
only the changes, as it does for config-main.cfg and 
config-extensions.cfg.  That way any new color items
would be loaded from the default config-highlight.def.
That's a bit of work.  Maybe someone will step up.

I've attached a patch to config-highlight.def which should take
care of the problem.  On Windows it's easiest, no doubt, to
just type in the four missing lines.  Or just delete
config-highlights.cfg and recreate it, whichever is less
work.

This bug describes a 2.3 -> 2.4 transition problem. The idea of making
the config system robust seems like a good RFE, if similar issues are
still possible.

This issue seems identical to issue2665: IDLE prints a lot of warnings,
and this can block the program after some amount of text, probably on
the first flush() because stderr is not connected to anything when
pythonw.exe is used.

issue2665 was fixed by not blocking the program, now IDLE can start.
The original problem remain, though.

I'm assuming that the attached patches are simply out of date.