[Python-Dev] For review: PEP 307 - Extensions to the pickle protocol

[Tim Peters]

[M.-A. Lemburg]
> That's nice to have :-) (previously I had to look those things
> up in the code itself... to the point where I simply didn't
> understand the various gimmicks)

Me neither -- I could never see the forest for the trees, although old-style
classes pickled and unpickled so easily by magic that I never really tried
before either.  It turns out there was a conceptually simple plan all along.
But by the time you write down all the details, you get Guido's 10-page PEP,
and in some sense there are even more trees now obscuring a clear view of
the tidy pickle hamlet.

> As long as pickle.py stays backwards compatible w/r to subclasses,
> I don't mind having a better alternative for the future at hand :-)
>
> If you do change the APIs, though, I'd consider adding new
> classes for Pickler and Unpickler (even if you have changed
> interna, because existing subclasses are likely to have been
> built on these as well simply because the code was never
> properly documented -- I know, because I did exactly this couple
> of time :-).

I'm not sure what you're saying.  If you have a subclass today, it should
continue to work.  Although pickle.py's Pickler internals were reworked to
key off a new "proto" attr in some places for protocol 2, the old "bin" attr
is still there, and set to self.proto > 1.  I suppose an existing subclass
with its own .proto attr could get screwed.

> Will cPickle also be updated according to the new features
> in pickle.py ?

Yup, and most (11 of 12) of the new opcodes are already implemented in
cPickle, and new tests for them in pickletester.py are run by both
test_pickle.py and test_cpickle.py.