>> People concerned about pickle size would be much better off investing >> time into a more generic solution (such as adding a code to
>> automatically run zip/gzip/bzip/xz etc).

> That's at the expense of (un)pickling speed, ...

Wanted to reply here so that the suggestion doesn't get lost.

When talking about pickle speed performance, we need to take into account that most use cases for pickle are i/o bound.  IOW, the time to pickle and unpickle is dominated by the time needed to read/write the pickle to/from disk or to send it across the wire.  In those common use cases, any time spent compressing/decompressing is more than made for by savings in transport/storage time.   This is a fairly common speed optimization and it would be nice if pickles supported it directly (i.e. the sender specifies a compression option and the receiver automatically detects the option from an opcode in the pickle.