[Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.76,2.77 (original) (raw)
Guido van Rossum guido@digicool.com
Thu, 10 May 2001 08:43:07 -0500
- Previous message: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.76,2.77
- Next message: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.76,2.77
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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/)
- Previous message: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.76,2.77
- Next message: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.76,2.77
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]