[Python-Dev] Octal literals (original) (raw)

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 1014/1013 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