[Python-Dev] Octal literals

[Bengt Richter]

On Sat, 04 Feb 2006 11:11:08 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote:

>Bengt Richter wrote:
>>>The typical way of processing incoming ints in C is through
>>>PyArg_ParseTuple, which already has the code to coerce long->int
>>>(which in turn may raise an exception for a range violation).
>>>
>>>So for typical C code, 0x80000004 is a perfect bit mask in Python 2.4.
>> 
>> Ok, I'll take your word that 'k' coercion takes no significant time for longs vs ints.
>
>I didn't say that 'k' takes no significant time for longs vs ints. In
>fact, I did not make any performance claims. I don't know what the
>relative performance is.
Sorry, I apologize for putting words in your mouth.
>
>> Well, I was visualizing having a homogeneous bunch of bit mask
>> definitions all as int type if they could fit. I can't express
>> them all in hex as literals without some processing. That got me started ;-)
>
>I still can't see *why* you want to do that. Just write them as
>hex literals the way you expect it to work, and it typically will
>work just fine. Some of these literals are longs, some are ints,
>but there is no need to worry about this. It will all work just
>fine.
Perhaps it's mostly aesthetics.
Imagine that I was a tile-setter and my supplier had an order form where I could
order square glazed tiles in various colors with dimensions in multiples of 4cm,
and I said that I was very happy with the product, except why does the supplier
have to send stretchable plastic tiles whenever I order the 32cm size, when I know
they can be made like the others? (Granted that the plastic works just fine for most uses ;-).

I have to admit the price for supplies is unbeatable, and that the necessary kit for
converting 32cm plastic to ceramic was also supplied, but still, if one can order ceramic
at all, why not the full range? Especially since if one orders the 32cm size in another dialect
one can get it without having to use the conversion kit, e.g.,
 >>> -2147483648
 -2147483648
but
 >>> -0x80000000
 -2147483648L
 >>> int(-0x80000000)
 -2147483648
;-)
That minus seems to bind differently in different literal dialects,
e.g. to make the point clearer, compare with above:
 >>> -2147483648
 -2147483648
 >>> -(2147483648)
 -2147483648L

>
>> BTW, is long mandatory for all implementations? Is there a doc that
>> defines minimum features for a conforming Python implementation?
>
>The Python language reference is typically considered as a specification
>of what Python is. There is no "minimal Python" specification: you have
>to do all of it.
Good to know, thanks. Sorry to go OT. If someone wants to add something about supersetting
and pypy's facilitation of same, I guess that belongs in another thread ;-)

Regards,
Bengt Richter