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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4