[Python-3000] _heapq.c, etc. (was Re: Heaptypes) (original) (raw)

Josiah Carlson jcarlson at uci.edu
Fri Jul 20 10🔞01 CEST 2007

"Guido van Rossum" <guido at python.org> wrote:

On 7/19/07, Guido van Rossum <guido at python.org> wrote: > How about instead you help with fixing pickling of datetime objects? > This broke when I fixed testpickle. 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.

More information about the Python-3000 mailing list