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?). --yuv On Sun, Sep 13, 2009 at 9:06 PM, Mark Dickinson <dickinsm@gmail.com> wrote:
Does anybody have any more use cases, ideas or suggestions? I'm getting
feeling this suggestion is +0 to most people and +1 for the rest. I'm
On Fri, Sep 11, 2009 at 4:16 PM, Yuvgoog Greenle <ubershmekel@gmail.com> wrote: the 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).
Mark