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 it is not valid ASCII and contains every possible byte.

To see a simple example, run this in both python 2 and 3

import pickle
a = bytearray(range(255)) #bytes containing 0..255
b = bytes(a)
c = pickle.dumps(b,protocol=0)
print(c)#human readable in 2, not in 3
c.decode('ascii')#throws in 3, not in 2

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 describe protocol 0 as ASCII consistently; if this isn't fixed to make it ASCII consistently, "human-readable" is still meaningless and shouldn't be used.

I'm kind of surprised the output from Py3 works on Py2 to be honest.

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).

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 on my pickled data. I was surprised when Py3's protocol 0 output was so different than Py2's protocol 0.

To be "human-readable", I think the protocol would have to be even stricter, omitting the non-printable ASCII characters.

I wonder if protocol 0 was initially ASCII (or even stricter), and then this went out the window or was unintentionally not adhered to when new things like bytearray (2.6) were introduced.

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 characters in Unicode strings can be invisible on your terminal).

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. It is human readable when pickling certain data types, but when others are involved, it sure seems like binary to me.

I think that is fine, and perhaps all that needs to be done is to update the documentation to say something like: "Protocol level 0 is the original pickling format. It is the default for Python 2 and is now a binary format; it originally was an ASCII format but this ceased to be true as support for new datatypes was added to Python."