This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author markroseman
Recipients eryksun, jan parowka, markroseman, martin.panter, terry.reedy
Date 2015-10-28.22:56:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1446072967.05.0.779304105904.issue24765@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2015-10-28 22:56:07markrosemansetrecipients: + markroseman, terry.reedy, martin.panter, eryksun, jan parowka
2015-10-28 22:56:07markrosemansetmessageid: <1446072967.05.0.779304105904.issue24765@psf.upfronthosting.co.za>
2015-10-28 22:56:07markrosemanlinkissue24765 messages
2015-10-28 22:56:06markrosemancreate