[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4