Author Sworddragon
Recipients Jan Niklas Hasse, Sworddragon, abarry, akira, barry, ezio.melotti, inada.naoki, lemburg, ncoghlan, r.david.murray, vstinner, yan12125
Date 2017-01-07.02:33:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483756394.75.0.895559599676.issue28180@psf.upfronthosting.co.za>
In-reply-to
Content
On looking into PEP 538 and PEP 540 I think PEP 540 is the way to go. It provides an option for a stronger encapsulation for the de-/encoding logic between the interpreter and the developer. Instead of caring about error handling the developer has now to care about mojibake handling (for me and maybe others that is explicitly preferred but maybe this depends on each individual). If I'm not wrong PEP 538 improves this for the output too but input handling will still suffer from the overall issue while PEP 540 does also solve this case. Also PEP 540 would not make the C locale and thus eventually some systems potentially unsupported (but it might be an acceptable trade-off if we should really go PEP 538).


Specific for PEP 540:

> The POSIX locale enables the UTF-8 mode

Non-strict I assume?


> UTF-8 /backslashreplace

Was/is the reason to use backslashreplace for sys.stderr to guarantee that the developer/user sees the error messages? Might it make sense to also use surrogateescape instead of backslashescape for sys.stderr in UTF-8 non-strict mode to be consistent here?
History
Date User Action Args
2017-01-07 02:33:14Sworddragonsetrecipients: + Sworddragon, lemburg, barry, ncoghlan, vstinner, ezio.melotti, r.david.murray, inada.naoki, akira, yan12125, abarry, Jan Niklas Hasse
2017-01-07 02:33:14Sworddragonsetmessageid: <1483756394.75.0.895559599676.issue28180@psf.upfronthosting.co.za>
2017-01-07 02:33:14Sworddragonlinkissue28180 messages
2017-01-07 02:33:14Sworddragoncreate