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

[Tim Peters]

]/F]
> as a footnote, SRE uses the same source code to generate
> both 8-bit and 16-bit versions of the match engine.  I see no
> reason why we cannot do the same for the string operations
> (PyString, PyUnicode, and strop).
>
> if anyone wants me to look into this, just say "go ahead".

go ahead

Here's another idea:  whenever we fix or extend Python's "%" formats, it
requires changes in both stringobject.c and unicodeobject.c, but they've
diverged in irritating ways that make it a fresh adventure in each.

In the early days, Python handled % formats pretty much by just building a
format string and passing that on to C's sprintf.

But as the years have gone by, and the number of buggy platforms increased,
Python has taken over more & more of it itself.  For example, it doesn't
trust sprintf to deal with justification, 0-fill or blank-fill, and needed to
grow its own from-scratch code for integer conversion in order to handle
Python longs.  In addition, it also grew a PyErr_Format() routine as yet
another layer of simulating what a safe sprintf-alike should do.  Even with
all that, we've still got platform bugs due to, e.g., platform %#x and %#o
conversion adding base markers when "they shouldn't" (according to C), or not
adding them when "they should" (according to Python).

All in all, the code would be simpler and quicker now if we left the platform
sprintf out of sprintf operations entirely <wink>.  The only thing we're not
simulating ourselves is float->string conversion.  Unfortunately, we can't do
that without also doing string->float, because platforms vary in the float
strings they can read back (e.g., if Python does float->string and produces
"Inf" for positive infinity, but uses strtod or atof to read floats back in,
it's a x-platform crapshoot whether "Inf" can be read back in).

but-in-favor-of-merging-the-code-even-without-that-ly y'rs  - tim