"Tim" == Tim Peters <tim.one@comcast.net> writes:
Tim> [Raymond] >> I would be happy to bring back the python version and make it coexist >> with the C version. Tim> Putting them under Demo doesn't do any good, because nobody Tim> maintains that directory; we don't even ship that directory in the Tim> Windows installer, so putting stuff there renders it invisible to Tim> most of Python's users. I still don't see why putting the original Python implementations under Demo somewhere is necessarily bad. They would still be available in source distributions and they could be tested from there without being installed - at least on Unix-like systems - by tweaking the "test" target in the Makefile. Something like: test: all platform # first two runs - test all modules which will be installed -find $(srcdir)/Lib -name '*.py[co]' -print | xargs rm -f -$(TESTPYTHON) $(TESTPROG) $(TESTOPTS) $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # second two runs - as above but force the Python versions of # certain modules to be used -find $(srcdir)/Lib -name '*.py[co]' -print | xargs rm -f PYTHONPATH=$(srcdir)/Demo/lib -$(TESTPYTHON) $(TESTPROG) $(TESTOPTS) PYTHONPATH=$(srcdir)/Demo/lib $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) might be sufficient. (You might have to rename some .so files in certain cases. Also, statically linked modules would pose problems.) >> In the itertools module, I documented pure python equivalents ... Tim> I love the Python-workalike docs for itertools! That's fine, but they can't easily be tested from there. Tim> I'd be perfectly happy if heapq.py were restored just as it was, Tim> and then a new section added at the bottom to replace it all with C Tim> functions. That's also tough to test. I believe there were situations over the years where the Python implementations of some functions in string.py and the corresponding C implementations in stropmodule.c got subtly out-of-sync. In part I think that's because the Python versions never got any exercise during the unit tests. The hack to suppress importing functions from strop would be ugly. I think you'd have to set an environment variable then test its presence in string.py before importing symbols from strop. If we are going to optimize standard library modules by implementing C counterparts but don't want the Python and C implementations to drift apart, we have to be able to test the Python versions somehow. Whatever that mechanism turns out to be has to be fairly convenient to use and shouldn't clutter up Python modules with checks solely used by the test framework. Skip