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?

On Mon, Aug 31, 2009 at 6:47 PM, MRAB wrote:
On 31 Aug 2009, at 15:00 , Nick Coghlan wrote:
Yuvgoog Greenle wrote:
I believe int(s, base) needs an inverse function to allow string
representation with different bases. An example use case is 'hashing' a
counter like video ID's on youtube, you could use a regular int
internally and publish a shorter base-62 id

This subject was discussed 2.5 years ago:
http://mail.python.org/pipermail/python-dev/2006-January/059789.html

I opened a feature request ticket:
http://bugs.python.org/issue6783

Some of the questions that remain:
1. Whether this should be a method for int or a regular function in a
standard library module like math.
2. What should the method/function be called? (base_convert, radix, etc)

What do you guys think?

This has been coming up for years and always gets bogged down in a
spelling argument (a method on int, a function in the math module and an
update to the str.format mini language would be the current contenders).

However, most of the actual real use cases for bases between 2 and 36
were dealt with by the addition of binary and octal output to string
formatting so the impetus to do anything about it is now a lot lower.

As far as bases between 37 and 62 go, that would involve first getting
agreement on extending int() to handle those bases by allowing case
sensitive digit parsing. Presumably that would use string lexical
ordering so that int('a', 37) > int('A', 37) and int('b', 37) would
raise an exception.

That would only be intuitive to someone that knows how ASCII based
alphanumeric ordering works though.

ASCII? Surely it should be Unicode! :-)

Or it could be handled via a translation table (needed both ways of course) mapping n indexes to n characters (with n the base you're working with), defaulting to something sane.

The default could cover only bases 2 to 36. Any base > 36 would require
a user-supplied translation table.

Though I'm not sure this is of much interest really: even Erlang (which provides pretty good base conversion tools: it supports literal integers of any base between 2 and 36) doesn't natively support bases beyond 36. A library would probably be better for those more conflictual (or less intuitive) ranges.

It could permit a dict as the translation table when 'decoding' so that
both 'A' and 'a' could be mapped to 10, if necessary.

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas