> I don't see what this would bring over explicit compression:
> - depending on the use case, you may want to use different compression algorithms, e.g. for disk you may want higher compression ratio like bzip2/lzma, but for wire you'd prefer something fast like snappy
> - supporting multiple compression algorithms and levels would complicate the API
> - this would probably complicate the code, since you'd have to support optional compression, and have a way to indicate which format is used
> - that's really mixing two entirely different concepts (serialization vs compression)

I agree with Charles-François.
A feature that may be actually nice to have in the pickle protocol would
be some framing, to help with streaming unpickling (right now unpickling
a stream can read almost one byte at a time, IIRC).
However, that would also make the protocol and the pickler significantly
more complex.