On Jan 24, 2008 9:47 AM, Jim Fulton <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
