[Python-Dev] Deprecation warning on integer shifts and such

[Guido van Rossum]

> > We are *already* offering developers a way to deal with unsigned data:
> > use longs.  Bit shifting works just fine on longs, and the results are
> > positive unless you "or" in a negative number.  Getting a 32-bit
> > result in Python is trivial (mask with 0xffffffffL).  The Python C API
> > already supports getting an unsigned C long out of a Python long
> > (PyLong_AsUnsignedLong()).
> 
> You are turning in circles here. Longs are not compatible
> to integers at C level. That's what I was trying to
> address.

In what sense are longs not compatible to C integers?  Because they
can hold larger values?  PyLong_AsUnsignedLong() does a range check;
Python code can force the value to be in range by using (e.g.)
x&0xffffffffL.

> Longs don't offer the performance you'd expect from bit operations,

Oh puleeeeeeze.  The overhead of the VM, object creation and
deallocation, overflow checks, etc., completely drown the time it
takes to do the meazly a<<b or a|b operation.  Doing the operation for
a Python long isn't significantly slower.

> so they are not a real-life alternative to native 32-bit or 64-bit
> integers or bit fields.

Of course they aren't, and that's not what we need.  We're talking
here about being able to pass various bits and masks to system and
library calls that.

> They are from a language designer's POV,
> but then I'd suggest to drop the difference between ints and longs
> completely in Py3k instead and make them a single hybrid type for
> multi-precision numbers which uses native C number types or arrays
> of bytes as necessary.

Yeah, in Py3k, there will be only one type.  Pep 237 tries to
approximate this without having to change *every* line of code dealing
with ints.  Unless you use isinstance() or type(), eventually you
won't be able to tell the difference (and we'll provide a way to
abstract away from those too, e.g. a baseint class).

> BTW, what do you mean by:
> 
> 	"hex()/oct() of negative int will return "
> 	"a signed string in Python 2.4 and up"
> 
> Are you suggesting that hex(0xff000000) returns
> "-0x1000000" ?

No, because 0xff000000 will be a positive number. :-)

However, hex(-1) will return '-0x1' rather than '0xffffffff'.

> That looks like another potentially harmful change.

That's why I'm adding warnings now.

I'm frustrated that you apparently didn't read PEP 237 when it was
discussed in the first place.

> Is it really worth breaking these things just for the sake
> of trying to avoid OverflowErrors where a simple explicit
> cast by the programmer is all that's needed to avoid them ?

Yes.

--Guido van Rossum (home page: http://www.python.org/~guido/)