Nicholas Neumann added the comment:
Apologies as I'm not super-familiar with Latin1 or how Python refers to Latin1,
but it seems a little odd to even call it Latin1. It can be decoded as Latin1,
but it can contain every possible byte, including 0x7f through 0x9f, which
aren't really Latin1.
Serhiy Storchaka added the comment:
Protocol 0 was initially ASCII, but it was changed since adding support for the
unicode type (and bytearray uses the unicode representation for compatibility
with Python 3). It is Latin1 now. And still mostly human-readable (except that
some control
Nicholas Neumann added the comment:
Wow, that's a great catch with bytearray on py2. Protocols 0-2 are all actually
supposed to work with python 2, and I was using 0 from Py3 as it's the default
for Py2, and what I want to use during a short transition where both Py3 and
Py2 are operating
Josh Rosenberg added the comment:
I'll note, the same bug appears in Python 2, but only when pickling bytearray;
since bytes in Python 2 is just a str alias, you don't see this misbehavior
with it, only with bytearray (which is consistently incorrect/non-ASCII on both
2 and 3).
--
Josh Rosenberg added the comment:
This seems like a bug in pickle; protocol 0 is *defined* to be ASCII
compatible. Nothing should encode to a byte above 0x7f. It's not actually
supposed to be "human-readable" (since many ASCII bytes aren't printable), so
the docs should be changed to
New submission from Nicholas Neumann :
The docs for pickle, in python 2, say that the default pickle protocol, 0,
produces ASCII. In the python 3 docs, this has changed to "human-readable".
While the pickle output with protocol 0 loads fine in python2, it is definitely
not human-readable, as
