> Fred was a proponent of small pickle sizes in the past,
> so I am adding him to the nosy list.

Thanks!

I am a proponent of small pickle sizes, in cases where it
matters.  I'm not convinced this is such a case.

The case for a small pickle size for datetime objects is
that they're very common in pickle-based persistent object
stores, such as ZODB.

Set objects are much less common in this environment; this
extends to most of Python's mutable data structures.  There
are three cases worth noting:

1. A separate persistent object is used to provide an API
   around the core Python data type, with an identical or
   similar API.  This is done to take care of noting
   changes, so the need to update the stored object is
   tracked.  In these cases, minor changes in the pickled
   size of the core object are swamped by the reference to
   the wrapper class.

2. An immutable object is used instead, and updates simply
   replace the value.  This allows the referring object to
   be responsible for change tracking, but means that types
   like the set, list, and dictionary aren't frequently
   used (though they may be used by other objects are part
   of their pickled representations).

3. Application objects may use mutable objects as part of
   their stored data value, but keep careful track of
   updates themselves.  This is most often the case when
   we want to avoid multiple round-trips to the storage
   server, and the size of the pickle isn't particularly
   interesting.

This isn't an argument that the change shouldn't be made,
but experiences with ZODB-like storages don't necessarily
suggest that all pickle sizes need be minimized.