homepage

> 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.