IDLE shouldn't pollute user's home directory on Windows, standard location for config files is %APPDATA%\<App>, which resolves to C:\Users\<user>\AppData\Roaming\<App> in Vista upwards and somewhere in Documents and Settings under XP.

On Windows, using the shell's [Known Folders API][1] is preferred. For Python 3.6+, an extension module could wrap SHGetKnownFolderPath and provide a dict of KNOWNFOLDERID values such as FOLDERID_RoamingAppData.

On Linux, there's the [XDG Base Directory Specification][2]. The application directory is created in one or more of the following directories {default in brackets}: $XDG_CONFIG_HOME {~/.config}, $XDG_DATA_HOME {~/.local/share}, and $XDG_CACHE_HOME {~/.cache}. 

What about Mac OS X?

[1]: https://msdn.microsoft.com/en-us/library/bb776911
[2]: http://standards.freedesktop.org/basedir-spec/latest

Mac Developer Library mentions Library/Application Support/<App> as a preferred directory to store configuration files for an application, gotten via a call to NSSearchPathForDirectoriesInDomains or NSFileManager with NSApplicationSupportDirectory path key and either NSLocalDomainMask domain (for all users) or NSUserDomainMask domain (for current user).

https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html

See also Issue 7175, although I think that is more about low-level Python configuration, rather than application-level configuration like Idle.

Two negative factors.

1. Users may edit the user config files 'by hand'. They occasionally must edit them to fix problems. Burying them in a *hidden* directory (invisible in Explorer) will make editing much harder, *especially for beginners*.  Even as a long-time Windows user, I only recently learned how to access %APPDATA% in Win 7, by fiddling with the entry bar the right way and adding exactly 'AppDate\' to the existing path, displayed as a path.  I am pretty sure this is different than with XP.  I imagine this has changed again in Win 8 and Win 10.  I really do not want to have to explain the Win version specific details when someone asks how to fix a problem here, python-list, or stackoverflow.  I doubt either of you want to either.

2. The one .idlerc directory is used for all currently installed python versions.  When one installs a new version, such as the upcoming 3.5.0, the custom font and size, custom keybindings, and anything else, are just there.  We cannot magically go back and change all existing installations.

> fiddling with the entry bar the right way and adding exactly 'AppDate\' to the existing path

You can type in '%APPDATA%' in the path bar, run dialog, or even start menu, and it will take you to the current user's Application Data folder. It works from XP upwards.

> The one .idlerc directory is used for all currently installed python versions

Yes, I imagine that's a bigger issue. The installer could, however, check whether there is currently an .idle directory in user folder and copy the settings over.

And if the older version is still present, as 2.7 will be for years, copy back to .idlerc.  To me, having two copies of the directory, one in the 'wrong' place, is worse than one copy in the wrong place.

Further to Terry's backwards compatibility issues (also discussed in #8231).

Storing things in the "correct" location (%APPDATA% on Windows, and Application Support on OS X) would presumably be the "right" thing to do if backwards compatibility weren't an issue.  

If "APPDATA" is the "correct" place, and "HOME" is what we've been using now, consider a solution like this:

- check if prefs exist in APPDATA; if so, use that
- check if prefs exist in HOME; if so, use that
- if neither, create prefs in APPDATA

This handles the common cases of existing user upgrading to new scheme (things stay stored in old location), new user upgrading to newer versions in future (things go in new place), but fails on the case of user starts with new version and then later uses an older version (results in two separate preferences, one used by newer versions, one used by older).

I think it's a legitimate question as to whether that latter case is common enough or problematic enough to worry about it (given "fails" doesn't break anything).

I do not consider the presence of .idlec in $HOME on Windows to be a problem in itself.  There are numerous applications, unix-derived and otherwise, that do the same with config files.  Very few, if any, have the issue of sharing between multiple simultaneous versions. Installing a new versions deletes the old.  Many do not have the issue of users needing to edit the files.  These would be better candidates for making the switch.

Under current circumstances, I reject the proposal.  However, since I hope circumstances change, I am closing this as 'postponed' rather than 'rejected'.  What I hope we can do, to make me *want* to re-open this.

* Switch from almost-dependable sockets to always-dependable pipes and delete the backup single-process (-n) mode (see IDLE Help).

* Switch from one user-code execution process to one for each editor window (including the shell).

* Let any recent (and installed) python version be chosen for each execution process.

* Improve configuration handling to where the need for user editing is mostly gone.  Example: ability to add a custom theme from a file without the user copy and pasting.

Each of these has benefits in itself, and the net effect would be that most everyone would only need to run the latest IDLE they have and not need to touch the .cfg files.  At this point, we would want to change the format and put them in a different (and less accessible) place anyway.

On Windows, how about creating a junction (_winapi.CreateJunction in 3.5, or the shell's mklink /j) from ~\.idlerc to %APPDATA%\idle? If ~\.idlerc already exists, it could be moved to %APPDATA%\idle before creating the junction. New code would directly use %APPDATA%\idle, but old code would continue to use ~\.idlerc.

Creating junctions requires no special privilege, but IDLE would need write access to the user's home directory. If write access is denied, at least newer IDLE versions that use %APPDATA% would work.

On Linux, a symbolic link could be created from ~/.idlerc to [$XDG_CONFIG_HOME|~/.config]/idle.