[Python-Dev] Fixing #7175: a standard location for Python config files

Tim Golden mail at timgolden.me.uk
Thu Aug 12 11:50:41 CEST 2010


On 11/08/2010 16:22, Éric Araujo wrote:
> It would be nice to define one standard location for config files used
> by stdlib modules, and maybe also by third-party programs related
> closely to Python development (testing tools, static code checkers and
> the like), in a way that doesn’t clutter the user home directory with a
> dozen dotfiles while still being easily found.
>
> (The Unix notions of dotfiles and home directory have to be adapted to
> use non-dotfiles in some standard place on various Windows. The Mac
> experts disagree on the right directory to use.)

The canonical place on Windows (per Microsoft [1]) is:

for roaming data: the Application Data folder (exposed as the
APPDATA env var and as CSIDL_APPDATA pre-Vista and the
FOLDERID_RoamingAppData Known Folder on Vista+).

for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA
or FOLDERID_LocalAppData)

The obvious difference is whether a user expects the data to be
available for the same account on a different computer. At present,
the user site packages are held under %APPDATA%\Python\Pythonxx,
ie are considered roaming.

Unfortunately, the canonical place is not always the place most
used. Especially since the convention under *nix is to place dotfile
or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
various locations are considered $HOME, including (but not limited
to):

* the directory pointed to by %HOME%
* the directory pointed to by %USERPROFILE%
* the "My Documents" shell folder
   (often, but not always, %USERPROFILE%\My Documents)
* c:\ (no: really)
* the NT profile home directory (typically a mapped share)

Dotfiles are possible on Windows; the issue is that they can't
be created within the shell (ie within Windows Explorer). They
can be renamed, edited, etc without issue, so it's not much of
a problem. They can be created by any program which can call
CreateFile -- including Python, obviously.

TJG

[1] http://support.microsoft.com/kb/310294


More information about the Python-Dev mailing list