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