Raymond Hettinger <rhettin...@users.sourceforge.net> added the comment:
> My understanding is that the desire to have pure > python versions of standard library modules is > to decouple the standard library from dependency > on CPython as far as practical. That is a bit of a broad brush. I do not know of an approved project to give all C modules a pure python equivalent (in fact modules like pickle presented a long-term maintenance problem in that the two versions differed and modules like sets.py were dropped entirelly). Looking at svn.python.org/view/python/trunk/Modules/ I see some which are good candidates and many which aren't. We need to show judgment on which one to do and recognize that maintaining dual code is a heavy maintenance burden and only do so where there is a clear value add. In my judgment, something like str.split() would benefit quite a bit from a pure python equivalent because its spec is somewhat opaque and hidden in C code and because both docs and the test coverage are incomplete. In contrast, I believe that dual code for datetime is a net loss. There is a reason that Uncle Timmy didn't put it in in the first place. Also, for those who haven't tried it before, it is not always easy to get good pure python equivalents (i.e. C iterators check their arguments when first called and Python versions do their argument checking when next() is first called; C functions sometimes do interesting keyword argument handling that cannot be done in pure python; and pure python versions differ in their tracebacks). Also, it's easy to make a mistake and misspecify the pure python version. You're relying on the test suite to catch all semantic differences. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7989> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
