Random832 random832 at
Mon Jun 13 01:33:13 EDT 2016

On Mon, Jun 13, 2016, at 01:16, Steven D'Aprano wrote:
> Suppose instead it returned the Unicode string 'AUERFg=='. That's all
> well and good, but what are you going to do with it? You can't
> transmit it over a serial cable, because that almost surely is going
> to expect bytes, so you have to encode it. You can't embed it in an
> email, because that also expects bytes.

Unless you're using a library that expects to receive strings and encode
them itself. Such as, in the example you so helpfully provide, a file
opened in text mode.
> You could write it to a file. If the file is opened in binary mode,
> you have to encode the Unicode string to bytes before you can write
> it. If the file is opened in text mode, Python will accept your
> Unicode string and encode it for you, which could introduce non-
> base64 characters into the file. Consider if the file was opened
> using UTF-16:
> \x00A\x00U\x00E\x00R\x00F\x00g\x00=\x00=
> hardly counts as base64 in any meaningful sense.

Why do you say these things like you assume I will agree with them. It
doesn't, in fact, introduce non-base64 characters because base64
characters are *characters*, not *bytes* and UTF-16 (or EBCDIC or
whatever) is a perfectly valid encoding of those *characters*, and the
recipient will, naturally, open that file in text mode in the same
encoding, and receive the same string, which it can then decode as

More information about the Python-list mailing list