It's a common issue that IDLE cannot start on Windows because
"IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection."
Everyone claim that the user should set the firewal so that IDLE can connect to subprocess via loopback. I found, instead, that this issue is often caused by an incorrect or missing setting of one the following variables: HOME, USERPROFILE or the combination of HOMEPATH and HOMEDRIVE; if these variables don't represent an existent and writable directory, the error occurs.
Try setting HOMEPATH to an unexistent or unwritable directory just before launching idle.bat script.
Check IdleConf.GetUserCfgDir() in module configHandler.py, where the function os.path.expanduser is called to get the user home directory. You might also temporarly patch GetUserCfgDir, setting the userDir variable to an unexistent path just after it has been initialized via os.path.expanduser (line 202).
Should be considered a check on expanduser behaviour?
OS: Windows XP
Python version: 3.2.2
title: IDLE cannot connect to subprocess - New solution
versions: Python 3.2
I can confirm that setting HOMEPATH to a non-existent directory will prevent IDLE from starting when using idle.bat. If you modify idle.bat such that python.exe is called instead of pythonw.exe, then IDLE starts normally, but with this console message:
Warning: os.path.expanduser("~") points to
but the path does not exist.
Normally, the message is written to sys.stderr, which is None when using pythonw. See issue13582 for more information.
Trying to understand how IDLE uses HOMEPATH and USERPROFILE Windows
variables, I have found the following information:
1) it seems that when executed via Windows command prompt (cmd.exe),
os.path.expanduser refers to USERPROFILE to determine the user's
2) analizing the stack traces of the first calls to
IdleConf.GetUserCfgDir, you can see that GetUserCfgDir (which
calls expanduser) is called three times during IDLE startup:
the first two times it refers to USERPROFILE, the third (called
via run.py, probably after starting a subprocess) it refers to
the combination of HOMEDRIVE and HOMEPATH. (???)
3) when you start IDLE using pythonw, sys.stderr.write(warn) seems
to raise an AttributeError exception, which is unhandled. This
causes IDLE to stop running when you either start IDLE that way
and the user's home directory is unreachable.
Due to the Python's tricky behaviour in determining the Windows
user's home directory, my opinion would be to consider if it is
worth to go further with this discussion or if it could produce
a benefit to IDLE. For sure, it gave me a little bit of headache.
It certainly is worthwhile pursing this in some fashion, since at the very least the existing error message needs to be improved. But perhaps there is something more that can be done to gracefully handle this case, instead. I think the next interesting question is to find out why an invalid home directory causes idle to not start up. There's no obvious reason why that should be the case in principle, so I suspect there's some error handling missing somewhere.
This probably also applies to 2.7; someone should test that.
I guess IdleConf should to have flag like 'writable'.
If user environment points to invalid location (or there are no write access) this flag should be set.
It flag can affect IDLE configuration dialog: user should be notified what him changes will not be permanently saved.
Subprocess can check that flag as well if need.
In combination with the "writable flag" solution, you might create a class
variable in IdleConf (e.g. "user_cfg") that contains the user's home directory;
such variable will be initialized to an empty string by IdleConf.__init__.
On each call, GetUserCfgDir tries to initialize "user_cfg" only if it is an
empty string, otherwise it returns it's content.
Anyway, keep in mind that in GetUserConfig there's an unhandled exception (AttributeError) that might be the cause of the "IDLE doesn't start..." issue reported by users.