[Python-Dev] SF patch 864863: Bisect C implementation (original) (raw)

Tim Peters tim.one at comcast.net
Tue Dec 30 22:23:34 EST 2003

[Raymond]

Dmitry Vasiliev has submitted a C implementation for the bisect module.

My thoughts are to accept it with the following changes: * leave the original code intact for teaching purposes

+1

* import the C version from bisect

+1

* make sure the C code is not list specific and will work with any container supporting len(), getitem(), and insert().

-0.6. "Gratuitous hyper-generality", IMO -- I'm willing to bet nobody has ever written a production class, with that collection of methods, that would also be suitable for using with bisect. "list subtype" is good enough, and will leave the code clearer, quicker, and more maintainable.

Do you guys have any objections?

Six tenths of one, as above .

[Guido]

Only that I wished you had done the same for heapq.py.

It's not too late. IIRC, neither you nor I could make time to review the heapq plans before the C code got checked in. I was able to make a little time after, and mourned the loss of the educational value of the Python version (to Raymond, in pvt).

That's a big enough point that it deserves public airing, though: everyone (except Guido, I guess) please remember what it was like when you first learned Python! Mounds and mounds of library code written in Python, doing interesting things with interesting techniques, and written at a high enough level that you weren't wholly buried under details. Python's C code is generally clean and educational too, but has a much smaller potential audience than our pure-Python modules. Nobody can sanely accuse me of not caring about speed (see a decade of speed-obsessed Python checkins for counterexamples ), but I cry a little each time a piece of the system gets recoded in C. Keeping the original Python code around is a nice compromise (pioneered, IIRC, by string.py, a loooong time ago).

More information about the Python-Dev mailing list