[Python-Dev] Octal literals

Bengt Richter bokr at oz.net
Fri Feb 3 09:05:25 CET 2006


On Thu, 2 Feb 2006 20:39:01 -0500, James Y Knight <foom at fuhm.net> wrote:

>On Feb 2, 2006, at 10:36 PM, Bengt Richter wrote:
>> So long as we have a distinction between int and long, IWT int will  
>> be fixed width
>> for any given implementation, and for interfacing with foreign  
>> functions it will
>> continue to be useful at times to limit the type of arguments being  
>> passed.
>
>We _don't_ have a distinction in any meaningful way, anymore. ints
Which will disappear, "int" or "long"? Or both in favor of "integer"?
What un-"meaningful" distinction(s) are you hedging your statement about? ;-)
  
>and longs are almost always treated exactly the same, other than the  
>"L" suffix. I expect that suffix will soon go away as well. If there  
>is code that _doesn't_ treat them the same, there is the bug. We  
If you are looking at them in C code receiving them as args in a call,
"treat them the same" would have to mean provide code to coerce long->int
or reject it with an exception, IWT. This could be a performance issue
that one might like to control by calling strictly with int args, or even
an implementation restriction due to lack of space on some microprocessor
for unnecessary general coercion code.

>don't need strange new syntax to work around buggy code.
It's not a matter of "buggy" if you are trying to optimize.
(I am aware of premature optimization issues, and IMO "strange"
is in the eye of the beholder. What syntax would you suggest?
I am not married to any particular syntax, just looking for
expressive control over what my programs will do ;-)

>
>Note that 10**14/10**13 is also a long, yet any interface that did  
>not accept that as an argument but did accept "10" is simply buggy.
def foo(i): assert isinstance(i, int); ... # when this becomes illegal, yes.

>Same goes for code that says it takes a 32-bit bitfield argument but  
>won't accept 0x80000000.
If the bitfield is signed, it can't, unless you are glossing over
an assumed coercion rule.

 >>> int(0x80000000)
 2147483648L
 >>> int(-0x80000000)
 -2147483648

BTW, I am usually on the pure-abstraction-view side of discussions ;-)
Noticing-kindling-is-wet-and-about-out-of-matches-ly,

Regards,
Bengt Richter



More information about the Python-Dev mailing list