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 gz
Recipients benjamin.peterson, gz, r.david.murray, vstinner
Date 2011-12-20.20:45:11
SpamBayes Score 1.3242641e-09
Marked as misclassified No
Message-id <1324413912.22.0.755313670707.issue13643@psf.upfronthosting.co.za>
In-reply-to
Content
> It was already discussed: using a different encoding for filenames and for
> other things is really not a good idea. The main problem is the interaction
> with other programs.

Yes, for many programs, a change like this will mean they create the file, but then throw a traceback anyway when trying to print its name to stdout or something.

> Read discussion of issues #8622, #8775 and #9992.

Thanks. I agree that spreading different values to things like subprocess arguments and the environment is asking for trouble. Just changing how unicode filename are encoded by default seems safer, though it certainly won't help all code.

> The right fix is to fix your locale, not Python.

I've found that hard to stick to in the face of bug reports where "your locale" turns out to be "the locale used by some cronjob". Fixing my library to work under LANG=C is easier than bugging every downstream project.
History
Date User Action Args
2011-12-20 20:45:12gzsetrecipients: + gz, vstinner, benjamin.peterson, r.david.murray
2011-12-20 20:45:12gzsetmessageid: <1324413912.22.0.755313670707.issue13643@psf.upfronthosting.co.za>
2011-12-20 20:45:11gzlinkissue13643 messages
2011-12-20 20:45:11gzcreate