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 ncoghlan
Recipients a.badger, abadger1999, benjamin.peterson, ezio.melotti, lemburg, ncoghlan, pitrou, r.david.murray, vstinner
Date 2013-08-21.02:35:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7fKZm4c-jnkZymjfROH2OqvjRp=-x=aXNyHDt-ZmgkXdg@mail.gmail.com>
In-reply-to <CAMpsgwYPqmKZRZpVw8WH9ftv8uOXjxuv89mD6O5Rz5ye39ieKQ@mail.gmail.com>
Content
Think sysadmins running scripts on Linux, writing to the console or a pipe.
I agree the generalisation is a bad idea, so only consider the original
proposal that was specifically limited to the standard streams.

Specifically, if a system is properly configured to use UTF-8 for all
interfaces, I shouldn't have to live in fear of Python steps in a command
pipeline falling over because it happens to encounter a filename encoded
with latin-1 (etc).

If the bytes oriented os tools like ls don't fall over on it, then neither
should Python. This is about treating the standard streams as OS
interfaces, as long as they're using the filesystem encoding.
History
Date User Action Args
2013-08-21 02:35:37ncoghlansetrecipients: + ncoghlan, lemburg, pitrou, vstinner, abadger1999, benjamin.peterson, ezio.melotti, a.badger, r.david.murray
2013-08-21 02:35:37ncoghlanlinkissue18713 messages
2013-08-21 02:35:36ncoghlancreate