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 glyph
Recipients arjennienhuis, barry, benjamin.peterson, christian.heimes, durin42, ecir.hana, eric.smith, exarkun, ezio.melotti, flox, glyph, gregory.p.smith, gvanrossum, loewis, martin.panter, nlevitt@gmail.com, pitrou, serhiy.storchaka, stendec, terry.reedy, uau, vstinner
Date 2013-10-08.22:45:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <F7DEF204-DF4F-45CF-B167-AABC55007066@twistedmatrix.com>
In-reply-to <F1FC5C81-CAE7-40A8-9F5D-ACC7EE4FACFF@durin42.com>
Content
On Oct 8, 2013, at 3:19 PM, Augie Fackler wrote:

> No, I'm not. In Mercurial, all end-user data is OPAQUE BYTES, and must remain that way.

The PEP 383 technique for handling file names is completely capable of round-tripping exact bytes, given one encoding for both input and output.  You can still handle file names this way internally in Mercurial and not risk disturbing any observable output.  You do not need to change that in order to do what Victor suggests.

We should get together in some other forum and discuss file-name handling though, since you can't actually round-trip "opaque bytes" through a *filesystem* and not disturb your output.

> Ouch. Is there any way to write things to stderr and stdout without decoding and hopelessly breaking user data?

You can use sys.stdout.buffer.write.
History
Date User Action Args
2013-10-08 22:45:39glyphsetrecipients: + glyph, gvanrossum, loewis, barry, terry.reedy, gregory.p.smith, exarkun, pitrou, vstinner, eric.smith, christian.heimes, benjamin.peterson, ezio.melotti, durin42, arjennienhuis, flox, ecir.hana, uau, martin.panter, serhiy.storchaka, nlevitt@gmail.com, stendec
2013-10-08 22:45:39glyphlinkissue3982 messages
2013-10-08 22:45:39glyphcreate