Btw, when you say translation table, do you mean just a string? Because a translation table would need to be continuous from 0 to the base so a real dicitionary-esque table may be overkill. The only advantage of a table might be to convert certain digits into multiple bytes (some sort of ad-hoc unicode use case?).


On Sun, Sep 13, 2009 at 9:06 PM, Mark Dickinson <> wrote:
On Fri, Sep 11, 2009 at 4:16 PM, Yuvgoog Greenle <> wrote:
> Does anybody have any more use cases, ideas or suggestions? I'm getting the
> feeling this suggestion is +0 to most people and +1 for the rest. I'm pretty
> new to these mailing lists so does that mean a yes or a no?

Just out of curiosity, I did a Google code search[*] for uses of the
inverse operation: int(<some_string> ,n).  I found a good handful of
uses of int(s, 36), almost all apparently to do with turning integers
into suitable id strings;  there was also evidence that people have
implemented the reverse 'integer -> base 36 string' conversion at
least twice.  I found no meaningful uses of any bases other than
2, 8, 10, 16, and 36.  So the main use case seems to be
serialization and deserialization of integers into some 'suitably nice'
alphabet, and that alphabet is likely to be application-dependent.

-0 for int.to_base(n) (2 <= n <= 36) or equivalent functionality in the core.

+0 for a pair of library functions converting to and from base n, with
explicitly given translation table.  I agree with MRAB that an implicit
digit set should only be allowed for 2 <= base <= 36, if at all.

By the way, _PyLong_Format in Objects/longobject.c *does* contain
code for general integer -> base b conversions, 2 <= b <= 36,
but that code is currently unused (as far as I can tell).