Fred L. Drake, Jr. <fdr...@acm.org> added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9120> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com