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

On 25 Aug, 01:25, 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

You are looking at this the other way round from me and I'll explain
why I think this is important. I'm not talking about the *programmer*
prescribing how the user should enter the data but the *user* being
able to choose to prepare the data in a certain format - the format
which makes sense for the data being entered. Your way only works if
those fields in every row have the same format. That may be the case
sometimes but is not general.


unary (1=one, 11=two, 111=three, 1111=four...) you can. 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.

Be careful! When designing a language feature don't be too ready to
*tell* the users of that language what restrictions they want. Just
because the designer wants features with a certain frequency does not
mean that all users will have the same priorities. (If it is
impossible or unreasonable to support a feature then by all means
don't support it. But don't decide up-front before examining the
options that something in not personally appealing.)

James
.

Relevant Pages

  • Re: Variable length/precision formats?
    ... Well, then you implemented it wrongly, because the format ... The usual definition of the feature *requires* that the user ... *implementation* no longer even needs to support the capability. ...
    (comp.lang.fortran)
  • Re: programming PIC16f877 using all-11
    ... > and used waccess software with all 11 programmer to burn the hex file ... format, in the tick boxes at the top right. ... Are you sure your crystal is suitable for the chip?. ...
    (sci.electronics.design)
  • Re: Vb 2003 Framework 1.1
    ... >> Ok taking this code below when i look at my LoByte and HiByte ... > If 3595 was a hex number, then the high byte would be hex 35 which ... so i would need to convert the 3595 into this type of format: ... Do you want to convert to a string? ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Question about blitting from RGB surface to YUV surface
    ... so if a spec doesnt ask for a feature, the hw guy wont think to add it, ... That and YUV is typically seen as a video format and not a 3D format. ... conversion needed, I should do the work programmly. ... PC with ATI graphic card, I notice that a RGB-format overlay surface was ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: Decimal-Hex-Binary coverter
    ... >> looks decimal numbers does not conform the hex and binary format. ... > It is the card which is confusing you. ... I have no task to get report in my custom format, ...
    (microsoft.public.windowsxp.general)