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

[Brett]

Raymond Hettinger wrote:
> 
> [Barry]
> 
>> The problem is that relegating stuff to Demo would very likely lead
>> to bitrot, which is not a good thing.  Another advantage of having
> 
> current,
> 
>> working (and unit tested) pure-Python alternatives is that they are
>> 
> 
> much
> 
>> easier to modify if you're experimenting with new features, or bug 
>> fixes, etc.
>> 
>> OTOH, some of the really ancient Python modules will occasionally
>> need attention to bring them up to modern coding standards, idioms,
>> and practices.
> 
> 
> There a several ways to go:
> 
> * have two visible modules like StringIO and cStringIO -- personally,
> I see the approach as clutter but it makes it possible to unittest
> both.
> 

I agree with Raymond on this option; having two versions of the same 
thing when there is no difference sans performance just clutters up the 
stdlib.  Kind of goes against TIOOWTDI.

> * put the C module behind the scenes and import it into the python 
> module while leaving the old code conditionally excluded or just 
> commented out.
> 

But that has the same issue as moving it to Demo since it still won't be 
used and thus tested.

> * if the code is short, move it to the docs -- the itertools module
> has pure python equivalents in the docs -- that makes the code
> accessible and makes the docs more informative -- this might work for
> bisect and heapq where the amount of code is small.
> 

This is the best solution, but I am afraid that for the modules we are 
discussing this does not work because of the amount of code.


I am afraid there is no good solution to this.  Either we move the code 
to a place where it is not really used (such as Demo, but we can add a 
flag to regrtest.py to test modules in that directory so the bitrot is 
not horrendous) or not used at all which begins to wear away the 
usefulness of keeping the code around in the first place.

Perhaps we need to just consider the fact that some modules have such 
beautiful code in Python that we just leave them as such.  Not 
everything needs to be coded in C (and this is in no way meant to not 
show appreciation to Raymond and anyone else who has converted Python 
code to C!  Some modules do have a basic performance need like bisect 
that should be dealt with when possible).  The main reason I was able to 
get involved in python-dev was that I was able to jump in and help with 
the Python code without much of a learning curve since it did not 
require learning anything new beyond basic practices of the list. 
Maintainability is a really important thing and each C module makes that 
a little bit much harder.

I think now that this issue has come up it should be enough for people 
to be aware that some people care enough about the Python code that this 
probably won't be an issue in the future.  If someone has doubts as to 
whether someone will miss the Python code then they can just ask the 
list for a quick opinion.  But I trust everyone with checkin rights who 
feels up to replacing a module to not be rash about it so I don't see a 
need for a vote for every module.

As for dealing with the modules that have already been converted, I say 
put them in Demo.  There is no need to do the importing in a Python 
module wrapper if there was enough of a performance reason to write it 
in C.  And if the code is wanted as reference stick it in the C code's 
comments.

OK, back to the Summary.

-Brett