...

...

...

...

"TP" == Tim Peters writes:

TP> I'd rather find a way to avoid __reduce__ entirely, though! Me, too! TP> The Python implementation of these things didn't need it, and in TP> the date and datetime cases it's creating bigger pickles than it TP> should -- __getstate__ and __setstate__ already did all that was TP> necessary, and no more than that. Supplying an argument tuple TP> for __reduce__'s benefit loses either way: I either put the real TP> date/datetime arguments there, but then the pickle is of a big TP> tuple rather than of a tiny string. Or I put a dummy argument TP> tuple there and also include the tiny string for __setstate__, TP> but these constructors require at least 3 arguments so that the TP> "dummy argument tuple" consumes substantial space of its own. TP> So, as it stands, ignoring the new-style-class administrative TP> pickle bloat in the Python implementation, the *guts* of the TP> pickles produced by the Python implementation are substantially TP> smaller than those produced by the C implementation. The __reduce__() approach seems to be (either or both) overly complex and underdocumented. It's a real shame that something simple like __getstate__() and __setstate__() can't be made to work for new-style classes. If I recall correctly, the problem is that there is no way to distinguish a user-defined new-style class from a builtin type from a user-defined subclass of a builtin type. As a result, there's no way for pickle to decide if it should be looking for __getstate__() or invoking the complicated machinery that allows subclasses of builtin types to be pickleable. Another victim of unification.

I figured timedelta *was* "a class", although now I guess that, in this context, it's not "a class" but "a type". That's what you get when you unify the concepts <wink>.

Jerem