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

[M.-A. Lemburg]

Tim Peters wrote:
> [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.

Which make me think: wouldn't a complete redesign from scratch under
a new name provide more room for optimizations ?

(after all, you are doing this for Zope's ZODB, right ?)

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

I'm not using that. What I am using are the .save_*()
and .load_*() method signatures and the .file attribute;
plus the .disptach table, of course, which I have to update
after overriding the methods.

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

Cool :-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/