Mark Hammond wrote: >> * Are the directories for Windows, Mac and Unix fine? > > Regarding Windows, I personally think its OK (but I also personally think > the status-quo is OK too). As has already been mentioned in this thread, > Windows actually provides an API you can call to determine various "well > known" folders. I assume the PEP literally means "the environment variable > APPDATA" instead of the result of SHGetSpecialFolderPath(CSIDL_APPDATA); it > might be worth mentioning that (and ideally *why* the env-var is preferred). > Similarly, a justification for why CSIDL_APPDATA/%APPDATA% is preferred over > CSIDL_LOCAL_APPDATA - ie, why we are suggesting Python is a "roaming" > application (eg, this implies that in certain Unix environments, it is > likely that ~/.local/ will follow users as they log into different machines > on the network - I've no idea how true that is)
Isn't SHGetSpecialFolderPath() XP and newer only? Python 2.6 is going to support 2000 and newer. I've written a patch for the ntpath module which adds a getshellfolders() function. The function uses SHGetFolderPathW to build a dict of id to path mappings. The patch is available at http://bugs.python.org/issue1763. Maybe you have some time to review it? As far as I understand and remember the Windows API SHGetFolderPath() and friends are retrieving the information from the registry. The shell folder keys are (IIRC) REG_EXPAND_SZ keys which are expanded with the function ExpandEnvironmentStrings(). So at the end CSIDL_APPDATA uses the %APPDATA% env var -- unless I'm totally mistaken. Or do you suggest that I'm using the win32 API calls instead of the env var? Point taken! I'll justify why I view Python as a roaming app. All company and university Linux boxes I've used in the past had exported $HOME via NFS. So ~/.local is roamed. > I'd recommend not; IIUC, Python's main binary directory isn't added to the > path, but even if it was, it will only be useful if .py is also on PATHEXT. > Either way though, I'd suggest that particular decision is outside the scope > of the PEP and a question for the windows installer assuming the PEP be > accepted. Maybe some general hand-waving along the lines of "env vars on > Windows are left to the installer, where such global issues are considered > in a wider context" would do :) *hehe* I love your idea. It should be trivial to write a view lines of Python code which modify PATH in HKCU. I'm going to write a simple example and drop it into Tools/scripts/. Christian PS: Have you tested the new PCbuild directory for VS 2008? Martin said that you know how to create a new set of base addresses for pre-linking. dllbase_nt.txt is probably outdated. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
