[Python-3000] [Python-Dev] inst_persistent_id
alexandre at peadrop.com
Fri Jan 25 03:25:08 CET 2008
On Jan 24, 2008 9:47 AM, Jim Fulton <jim at zope.com> wrote:
> On Jan 23, 2008, at 4:30 PM, Alexandre Vassalotti wrote:
> > I am not sure what you mean by "cPickle.Pickler and cPickle.Unpickler
> > subclassible in the same way as the pickle classes." It is possible to
> > subclass the C implementation. However, the C implementation does not
> > expose pickle "private" methods, such as Pickler.save_int and
> > Unpickler.load_tuple. This is fine because these were never documented
> > as part of the interface of pickle.
> That doesn't mean that they aren't overridden. I've overridden them
> in specialized applications. I suspect that others have as well.
Well even in pickle.py, you can't override the save_* and load_*
methods (at least, directly), since they are called via a dispatch
> > Only Pickler.dump,
> > Pickler.clear_memo and Unpickler.load are supported by the Python
> > implementation. All these are supported by the C implementation as
> > well.
> How about find_class? I actually prefer cPickle's way of handling this.
I haven't thought much about these -- i.e., methods overrided via
__setattr__ -- yet. But, you are right -- they should be supported
> > So, what kind of "extensibility" are you looking for the C
> > implementation of pickle?
> I'm not really looking for anything that isn't there already. The
> python pickle version is more extensible that cPickle and I find that
> valuable. I don't want to make cPickle more flexible. I'd willing to
> trade off speed and flexibility depending on the application. I don't
> want to lose either in the interest of unification.
How much of cPickle is really speed critical? Personally, I think
built-in types pickling should be optimized as much as possible and
other things, such as user-defined classes and extension types
pickling, could be done in Python.
> > Quick note, one of the original motives for making the C
> > implementation of pickle transparent was to make it more "friendly"
> > for alternate implementations of Python (e.g., Jython, IronPython,
> > etc).
> I don't know what that means. I don't know that Jython or IronPython
> need to support cPickle.
Maybe, but it make it slightly harder for people to write code accross
these implementations. Interestingly, IronPython's team actually
reimplemented cPickle in C#:
> Having said that, I would agree that there are certain aspects of
> their external APIs that ought to be unified. A good example is
> handling of globals.
Could you elaborate about this, please; how the handling of globals by
cPickle is different from pickle?
More information about the Python-3000