Numeric literals in other than base 10 - was Annoying octal notation
Erik Max Francis
max at alcyone.com
Mon Aug 24 04:35:47 EDT 2009
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
More information about the Python-list
mailing list