[Python-Dev] SF patch 864863: Bisect C implementation
bac at OCF.Berkeley.EDU
Thu Jan 1 17:26:26 EST 2004
Raymond Hettinger wrote:
>> The problem is that relegating stuff to Demo would very likely lead
>> to bitrot, which is not a good thing. Another advantage of having
>> working (and unit tested) pure-Python alternatives is that they are
>> 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
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
OK, back to the Summary.
More information about the Python-Dev