[Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.76,2.77

[Guido van Rossum]

> [Guido]
> > Yes, but in the mean time the fact that it's buggy doesn't bother
> > me at all.  Let it be as buggy as it always was -- that's one more
> > reason to stop using it! :-)

[Tim]
> I think that's unsustainable in this specific case: stringobject and
> stropmodule contained several utility functions with the same names
> that clearly started life as identical code.  Over time they got out
> of synch, and when they punched me in the face today, I had no idea
> which was "right" and which "wrong".  Turned out they both had the
> same bug, and the clearest way to fix it in stringobject.c without
> leaving a more inconsistent x-module mess was to bring the
> once-common utility routines back into synch.

Of course, the real bug was copy-and-paste programming.  The common
code should have been factored out rather than copied.

> As /F said, though, the mymemreplace() approach is inefficient and
> "should be" replaced wholesale.  If that's done in stringobject.c
> alone, great, then I won't care about the legacy routines in
> stropmodule.c either.  What I can't abide is having one copy of a
> function in the codebase work and a clone of it not work -- unless
> you can keep the undocumented history of both in your mind at all
> times, you're just as likely to bump into the broken one first when
> searching the code base, and if you're unlucky never even realize it
> is "the broken one" (or, if you're lucky, bump into the good one
> too, and then pee away time trying to understand the differences).

Here's an idea.  We remove stropmodule.c, and replace it with a
strop.py that issues a warning and then imports selected things from
string.py.

The only complication is that there are a few constants and one
function in strop that are still imported into string.py; I propose to
move these to an "internal" extension module (e.g. "_string").

--Guido van Rossum (home page: http://www.python.org/~guido/)