Logged In: YES 
user_id=1330769

I agree that IDLE must have a no-subprocess mode, since it
has its uses. Still, I feel these uses are relatively
isoteric, so while the option should exist as a command line
option, it shouldn't usually be used by non-developers.

On systems without networking trying to use sockets will
fail, and IDLE should detect this and fall-back to
no-subprocess mode automatically. (Another item on the TODO
list...)


Well, we could "dodge" the Windows problem for now by having
IDLE try a random port every time (like in the IDLEfork
patch) - thus collisions will be kept to a minimum. If we
choose among over 10,000 ports, most users will never
encounter a port collision. And even when a collision does
happen, it will probably be detected and properly dealt with
- collision non-detection errors are, as you say, erratic.

Also, if a collision happens the listening socket won't
recieve a connection, and accept() will timeout. After this
we can continue trying other ports.

I submitted my implementation as a separate patch.