Finding where to store application data portably

Tony Houghton at
Wed Sep 21 21:07:54 CEST 2005

Steven D'Aprano wrote:
 > On Tue, 20 Sep 2005 23:03:52 +0100, Tony Houghton wrote:
 >>I'm using pygame to write a game called Bombz which needs to save some
 >>data in a directory associated with it. In Unix/Linux I'd probably use
 >>"~/.bombz", in Windows something like
 >>"C:\Documents And Settings\<user>\Applicacation Data\Bombz".
 > In Windows, you shouldn't hard-code the drive letter. I don't know 
how you
 > find out what the correct value is, but hard-coding it is just Bad.

That's why I said "something like". It seems there is a definitive way
of finding the correct value, but it needs extra W32 extensions
installed. You could also start from os.path.expanduser('~') I suppose.

 > As a Linux user, I really am sick of every damn application, script and
 > program under the sun filling the top level of my home directory with
 > dot-files.
 > I wish the Linux Standard Base folks would specify that settings files
 > should all go into a subdirectory like ~/settings rather than filling up
 > the home directory with cruft. That was acceptable in the days when 
 > only looked at their files with ls, but in these days of GUI file
 > managers, it is ridiculous that there are more than 100 dot files and
 > directories in my home directory.

Don't all file managers have an option to hide files beginning with '.'?

 > <tilting at windmills>
 > Can I ask developers to break with the obsolete and annoying habit of
 > creating user-specific config files as ~/.app-name and use
 > ~/settings/app-name instead?
 > </tilting at windmills>

You'll probably like the XDG basedir spec then:

I suppose I should really use that, but the trouble is it can be very
difficult to decide whether some files are config or data, so it would
be nice to have a standard that doesn't segregate the two.

Thanks to everyone else who's replied. I've saved Trent Mick's script
for later reference.

The address in the Reply-To is genuine and should not be edited.
See <> for more reliable contact 

More information about the Python-list mailing list