[Fred]
Now that this idea has fermented for a few days, I'm inclined to not like it. It smells of making Unix-centric interface to something that isn't terribly portable as a concept.
Yes. After thinking more carefully and after a closer look to what Jack Jansen finally figured out for MacOS (see <http://www.python.org/pipermail/pythonmac-sig/2000-May/003667.html> ) I agree with Fred. My initial idea to put something into 'os.environ["HOME"]' on those platforms was too simple minded.
Perhaps there should be a function that does the "right thing", extracting os.environ["HOME"] if defined, and taking an alternate approach (os.getcwd() or whatever) otherwise. [...]
Every serious (non trivial) application usually contains something like "user preferences" or other state information, which should --if possible-- survive the following kind of events: 1. An upgrade of the application to a newer version. This is often accomplished by removing the directory tree, in which this application lives and replacing it by unpacking or installing in archive containing the new version of the application. 2. Another colleague uses the application on the same computer and modifies settings to fit his personal taste. On several versions of WinXX and on MacOS prior to release 9.X (and due to stability problems with the multiuser capabilities even in MacOS 9) the second kind of event seems to be rather unimportant to the users of these platforms, since the OSes are considered as "single user" systems anyway. Or in other words: the users are already used to this situation. Only the first kind of event should be solved for all platforms: <FANTASY> Imagine you are using grail version 4.61 on a daily basis for WWW browsing and one day you decide to install the nifty upgrade grail 4.73 on your computer running WinXX or MacOS X.Y and after doing so you just discover that all your carefully sorted bookmarks are gone! That wouldn't be nice? </FANTASY> I see some similarities here to the standard library module 'tempfile', which supplies (or at least it tries ;-) to) a cross-platform portable strategy for all applications which have to store temporary data. My intentation was to have simple a cross-platform portable API to store and retrieve such user specific state information (examples: the bookmarks of a Web browser, themes, color settings, fonts... other GUI settings, and so... you get the picture). On unices applications usually use the idiom os.path.join(os.environ.get("HOME", "."), ".dotfoobar") or something similar. Do people remember 'grail'? I've just stolen the following code snippets from 'grail0.6/grailbase/utils.py' just to demonstrate, that this is still a very common programming problem: ---------------- snip --------------------- # XXX Unix specific stuff # XXX (Actually it limps along just fine for Macintosh, too) def getgraildir(): return getenv("GRAILDIR") or os.path.join(gethome(), ".grail") ----- snip ------ def gethome(): try: home = getenv("HOME") if not home: import pwd user = getenv("USER") or getenv("LOGNAME") if not user: pwent = pwd.getpwuid(os.getuid()) else: pwent = pwd.getpwnam(user) home = pwent[6] return home except (KeyError, ImportError): return os.curdir ---------------- snap --------------------- [...] [Guido van Rossum]:
I could see defining a new API, e.g. os.gethomedir(), but that doesn't help all the programs that currently use $HOME... Perhaps we could do both? (I.e. add os.gethomedir() *and* set $HOME.)
I'm not sure whether this is really generic enough for the OS module. May be we should introduce a new small standard library module called 'userprefs' or some such? A programmer with a MacOS or WinXX background will probably not know what to do with 'os.gethomedir()'. However for the time being this module would only contain one simple function returning a directory pathname, which is guaranteed to exist and to survive a deinstallation of an application. May be introducing a new module is overkill? What do you think? Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)