Alexander Belopolsky wrote at Thu, 15 Oct 2015 17:56:42 +0000:

> I don't think your solution will work for date/time/datetime pickles.
> There are many values for which pickle payload consists of bytes
> within 0-127 range.

Hmmmm.

> IIUC, you propose to decode those to Python 3
> strings using ASCII encoding.

Yes. There are too many BINSTRING instances that need to be Python 3
strings.

> This will in turn require accepting str
> type in date/time/datetime constructors.

These datetime... constructors are strange beasts already.

The documentation says that three integer arguments are required for
datetime.datetime but it accepts a single bytes argument anyway. I
agree that it would be much nicer if there was a
datetime.datetime.load method instead. Unfortunately, that would
require Guido's time machine to go back all the way to 2003 (at least).

So yes, the only practical solution is to accept a single str typed
argument (as long as it is ASCII only). An alternative would be to add
a dispatch table for loading functions to Python 3's pickle that would
be used by load_global. That would add indirection for the datetime
constructors but would allow support for other types requiring
arguments of type bytes.

The change I proposed in http://bugs.python.org/issue22005#msg253042
to fix the handling of binary 8-bit strings is still necessary.

To summarize:

IMHO the solution needs to be implemented in Python 3 — otherwise
pickles with binary strings created by Python 2.x cannot be loaded in
Python 3. Changing the pickle implementation of Python 2 doesn't fix
existing pickles and couldn't fix the general problem of binary
strings, anyway.