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 base64. -- https://mail.python.org/mailman/listinfo/python-list
