[Python-Dev] SF patch 864863: Bisect C implementation

[Tim Peters]

[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 <wink>.

[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 <wink>), 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).