Tim Peters wrote:
[Tim]
About combining strop and buffers and strings, don't forget unicodeobject.c: that's got oodles of basically duplicate code too. /F suggested dealing with the minor differences via maintaining one code file that gets compiled multiple times w/ appropriate #defines.
[MAL]
Hmm, that only saves us a few kB in source, but certainly not in the object files.
That's not the point. Manually duplicated code blocks always get out of synch, as people fix bugs in, or enhance, one of them but don't even know about the others. /F brought this up after I pissed away a few hours trying to repair one of these in all places, and he noted that strop.replace() and string.replace() are woefully inefficient anyway.
Ok, so what we'd need is a bunch of generic low-level string operations: one set for 8-bit and one for 16-bit code. Looking at unicodeobject.c it seems that the section "Helpers" would be a good start, plus perhaps a few bits from the method implementations refactored to form a low-level string template library. Perhaps we should move this code into a file stringhelpers.h which then gets included by stringobject.c and unicodeobject.c with appropriate #defines set up for 8-bit strings and for Unicode.
The better idea would be making the types subclass from a generic abstract string object -- I just don't know how this will be possible with Guido's type patches. We'll just have to wait, I guess.
Wait for what? If it were possible, is the chance that you'd take time to rework unicodeobject.c to "subclass from a generic abstract string object" greater than 0? The chance that I would is exactly 0.
Well, that's hard to say. It would certainly be low-priority; same for the above refactoring. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/