Interesting problem comparing strings with integer values...

Carl Banks imbosol at
Thu Jan 16 04:09:51 CET 2003

Chris Spencer wrote:

> As I mentioned in my most recent response, these strings are NOT
> being compared in the Python interpreter, but by the SQL engine on a
> database, so all the subclassing in the world won't help me here.
>  And though I sometimes don't agree with my boss on design issues, I
> have to say that this isn't one of those times.  We have very clear
> design constraints which REQUIRE us to store strings, integers,
> floats, dates/times, all in string format in TEXT blobs in the
> database.

I'd hate to see what kind of problem requires you to store numeric
data as strings, and yet still expects to be able to query those
strings as if the strings were numbers.

Anyways, one option is to pad the left with spaces instead of zeros.
Surprise!  The sorting still works (assuming you do it consistently).
All bets are off if you can't rely on ASCII characters.  There's still
that problem of how much to pad, though.

Maybe you will need to store very large numbers.  So how about reverse
lexically normalized scientific notaion?

    def RLNSNize_number(number):
        mantissa,exponent = ("%.18e" % number).split("e")
        return "%04dm%20s" % (int(exponent)+500, mantissa)

    def unRLNSNize_number(s):
        exponent = int(s[0:4])-500
	mantissa = s[5:25]
	return float("%se%d" % (mantissa,exponent))

(I assume, BTW, you won't be storing negative numbers.  If you are,
you're in bad shape, and might want to reconsider Option 1 from my
previous post.)


More information about the Python-list mailing list