Language Shootout

Bengt Richter bokr at accessone.com
Wed Jul 11 21:16:43 CEST 2001


On Wed, 11 Jul 2001 08:49:49 -0700, Jeff Shannon <jeff at ccvcorp.com> wrote:

>
>
>"David C. Ullrich" wrote:
>
>> On Wed, 11 Jul 2001 01:47:30 GMT, bokr at accessone.com (Bengt Richter)
>> wrote:
>>
>> >[18:47] C:\pywk\fib>strL.py str  10L**20899
>> >str took 13.601617 seconds
>> >
>> >[18:47] C:\pywk\fib>strL.py strL 10L**20899
>> >strL took  1.044989 seconds
>> >
>> >Recursion rides again ;-)
>>
>> Recursive or not, the idea that we can write
>> a replacement for str that's faster is very
>> curious.
>
>How much of this difference in speed, though, is because strL()
>is a special purpose integer->string conversion, where the
>standard str() is a general-purpose anything->string conversion?
>
I would guess the general purpose str already does something
internally specialized for longs. However, the % operator is even
more general purpose, and you may note that I used it
to trim my trees in strL (because it is faster than carrying
strLR's recursion all the way down to w=1 and chr(48+n) )

BDFL & Tim & co probably just had better things to do than cater
to the small percentage of strange people with programs
that need to convert longs to multi-kilo-digit integers ;-)

I'm sure they know how to do this kind of thing very well,
but if they think it's worth the seldom-used-bloat-increment,
they're certainly welcome to take strL and make it truly
Python-worthy and incorporate it. (Maybe I'd find out how to
keep everything but strL invisible from the user, and make
strLR nested without triggering a warning ;-)



More information about the Python-list mailing list