"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > On 7/19/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > How about instead you help with fixing pickling of datetime objects? > > This broke when I fixed test_pickle. Rolling back your changes to > > datetime pickling didn't seem to help. > > Never mind; this was shallow -- cPickle doesn't pickle bytes > correctly. I've decided to get rid of cPickle -- someone is writing a > replacement for the summer of code anyway. The new approach will be > that you always write "import pickle" and this transparently attempts > to use the C accelerator if it can be imported, like heapq.py and > _heapq.c.
On a related note, since I had been supporting only Python 2.3 for quite a while, I didn't notice the fact that Python's _heapq.c (in 2.4 at least, I haven't tested on 2.5) only supported lists as containers, and not a list-like object with all methods that heapq calls (which was an issue for a pure-Python pair heap implementation I posted last December or so). What made it really annoying is that there was no way to tell the heapq module not to load the C version so that I could use a generic container. I ended up just commenting out the C module heapq import and moving on. I don't know if we want to make it possible to disable the loading of certain C modules that *don't* offer all of the same features, or if we want to limit the Python versions to what the C versions support, or even if we want to expand the C versions to handle all cases that the Python versions support. While the pickle/cPickle, StringIO/cStringIO, etc., naming can be a bit annoying, it does give me the choice whether I want it to be fast or flexible. - Josiah _______________________________________________ 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
