On 14 June 2016 at 13:32, Toshio Kuratomi <a.bad...@gmail.com> wrote: > > On Jun 14, 2016 8:32 AM, "Joao S. O. Bueno" <jsbu...@python.org.br> wrote: >> >> On 14 June 2016 at 12:19, Steven D'Aprano <st...@pearwood.info> wrote: >> > Is there >> > a good reason for returning bytes? >> >> What about: it returns 0-255 numeric values for each position in a >> stream, with >> no clue whatsoever to how those values map to text characters beyond >> the 32-128 range? >> >> Maybe base64.decode could take a "encoding" optional parameter - or >> there could be >> a separate 'decote_to_text" method that would explicitly take a text codec >> name. >> Otherwise, no, you simply can't take a bunch of bytes and say they >> represent text. >> > Although it's not explicit, the question seems to be about the output of > encoding (and for symmetry, the input of decoding). In both of those cases, > valid output will consist only of ascii characters. > > The input to encoding would have to remain bytes (that's the main purpose of > base64... to turn bytes into an ascii string). >
Sorry, it is 2016, and I don't think at this point anyone can consider an ASCII string as a representative pattern of textual data in any field of application. Bytes are not text. Bytes with an associated, meaningful, encoding are text. I thought this had been through when Python 3 was out. Unless you are working with COBOL generated data (and intending to keep the file format) , it does not make sense in any real-world field. (supposing your Cobol data is ASCII and nort EBCDIC). > -Toshio _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com