> A further version of the pickle protocol could 
> > have a dedicated opcode for sets instead...
> 
> -1 We don't have to introduce a new (and backwards incompatible)
> opcode for every possible container type.

What I was implying is that someone interested in more efficient pickles could start the work of a new protocol version which would *include* such an improvement.

> All that is saved is the enclosing list or tuple setup (five bytes
> in the case of sets).

No, you would save the (string) reference to "builtins.set" and the whole constructor invocation boilerplate.

>>> len(pickle.dumps([1,2,3]))
14
>>> len(pickle.dumps({1,2,3}))
36

See? The difference is much more than 5 bytes.

What's more, you would avoid building a temporary list only to convert it to a set at the end.

> 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, though, while the above suggestion would improve performance in addition to reducing pickle sizes.