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

Skip Montanaro skip at pobox.com
Fri Jan 2 08:54:04 EST 2004

>>>>> "Tim" == Tim Peters <tim.one at 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
          # 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.


More information about the Python-Dev mailing list