Inverse of int(s, base)?

[Paul Rubin]

Oliver Fromme <olli at secnetix.de> writes:
> Is creating strings really that expensive in Python?  I'm
> surpised that you're saying that modifying a list and then
> calling reverse() and join() is more efficient.  I thought
> that the overhead of compound objects such as lists is
> more expensive than creating strings, which I thought where
> rather "cheap and simple".

Actually, for these int conversions (unless they're large long ints)
it's no big deal.  The concern is when you're building up a long
string (say, a 10 kilobyte html page) by concatenating a lot of short
strings.  When you say "a = a + b" the cost is proportional to
len(a+b), since that many chars must get copied around.  In the
extreme case, suppose you build up a 10k web page one character at a
time:

  for c in get_next_char():
      page = page + c

The first iteration copies 1 character, the next iteration copies 2
chars, the next one 3 chars, etc.  So the total amount of copying is
1+2+3+...+10000, which is around 50 million.  In general it's O(N**2)
where N is the number of concatenations.

By comparison, when you append something to a list, the cost is
usually constant.  There's extra space in the list for appending, so
nothing gets copied (if there's no extra space left, then stuff does
get copied and more space is allocated).  So
  for c in get_next_char():
    page.append(c)
is much more efficient than string concatenation.  At the end, you do
all the concatenation in one step with ''.join(page).

See also the StringIO and cStringIO library modules for possibly
preferable ways to do this.