Numeric literals in other than base 10 - was Annoying octal notation

[Erik Max Francis]

James Harris wrote:
> On 24 Aug, 02:19, Max Erickson <maxerick... at gmail.com> wrote:
>>> It can be assumed however that .9. isn't in binary?
>>> That's a neat idea. But an even simpler scheme might be:
>>> .octal.100
>>> .decimal.100
>>> .hex.100
>>> .binary.100
>>> .trinary.100
>>> until it gets to this anyway:
>>> .thiryseximal.100
>> At some point, abandoning direct support for literals and just
>> having a function that can handle different bases starts to make a
>> lot of sense to me:
>>
>>>>> int('100', 8)
>> 64
>>>>> int('100', 10)
>> 100
>>>>> int('100', 16)
>> 256
>>>>> int('100', 2)
>> 4
>>>>> int('100', 3)
>> 9
>>>>> int('100', 36)
>> 1296
> 
> This is fine typed into the language directly but couldn't be entered
> by the user or read-in from or written to a file.

Why would a programmer be expecting an arbitrary-radix numeric literal 
typed in by a user or read from a file?  If you're reading it from a 
file, you've already got it in some satisfactory form, binary or 
otherwise.  If you're taking it as input from a user, they're not going 
to know the Python syntax anyway, and would type in the radix and then 
the literal (in the unlikely case this would ever be required, which is 
still hard to imagine).

Either way, conversion is, as Max showed, one line of code.  It's hard 
to see the explicit need for truly arbitrary-radix literals in any 
language -- and I'm the guy who's put quaternary literals in syntaxes 
he's had to develop just for fun.  Binary, octal, decimal, hexadecimal, 
sure.  Beyond that it's a solution begging for problems.

-- 
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   Do not seek death. Death will find you.
    -- Dag Hammarskjold