On Aug 24, 7:25 pm, Steven D'Aprano <st...@remove-this-
cybersource.com.au> wrote:
> On Mon, 24 Aug 2009 16:23:06 -0700, James Harris wrote:
> > Sure but while I wouldn't normally want to type something as obscure as
> > 32"rst" into a file of data I might want to type 0xff00 or similar. That
> > is far clearer than 65280 in some cases.
>
> > My point was that int('ff00', 16) is OK for the programmer but cannot be
> > used generally as it includes a function call.
>
> No, it's the other way around. If you have *data*, whether entered at run
> time by the user or read from a file, you can easily pass it to a
> function to convert to an int. (In fact you have to do this anyway,
> because the data will be a string and you need an int.)
>
> If you want your data file to have values entered in hex, or oct, or even
> unary (1=one, 11=two, 111=three, 1111=four...) you can.
Unary? I think you'll find that Standard Positional Number
Systems are not defined for radix 1.
> There's no need
> to have the user enter int('ff00', 16) to get hex, just have them enter
> ff00.
>
> But when writing *code*, you want syntax which will accept integers in
> the most common bases (decimal, a distant second hex, an even more
> distant third octal, and way out on the horizon binary) without the
> runtime cost of a function call.
>
> --
> Steven
--
http://mail.python.org/mailman/listinfo/python-list
