[Python-3000] [Python-Dev] inst_persistent_id

[Alexandre Vassalotti]

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

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

> > 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#:

http://www.codeplex.com/IronPython/SourceControl/FileView.aspx?itemId=296271&changeSetId=29832

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

-- Alexandre