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

[Guido van Rossum]

> > That's why I'm adding the warnings to 2.3.  Note that the bit pattern
> > in the lower 32 bits will remain the same; it's just the
> > interpretation of the sign that will change.
> 
> That's exactly what I'd like too :-) With the only difference
> that you seem to see the sign bit as not included in the 32 bits.

I was using sloppy language by lumping "sign change" under "lost bits".
What I really meant was "returning a value that's different from what
the same operation on a long would return".  I've added something
about sign changes to the PEP.

> > Why do you want them to remain ints?  Does a long whose lower 32 bits
> > have the right bit pattern not work?
> 
> No, because you usually pass these objects directly to some
> Python C function (directly as parameter or indirectly as item
> in a list or tuple) which often enough insists on getting a true
> integer object.

There's no excuse for that any more.  The 'i' and 'l' format chars of
PyArg_Parse* and PyInt_AsLong() both work for longs as well as for
ints.

> No argument about this. It's just that I see a lot of programs
> breaking because of the 0x1 << 31 returning a long.

I think you're overly pessimistic.  But that's why I'm putting the
warning in for 2.3 -- the semantics are the same as for 2.2, they
won't change until 2.4 (or later if this turns out to be a bigger
issue).

> That needen't
> be the case. People using this will know what they are doing and
> use a long when possible anyway. However, tweaking C extensions to
> also accept longs instead of integers requires hacking those
> extensions which I'd like to avoid if possible. I already had
> one of these instances with file.tell() returning a long and
> that caused a lot of trouble then.

Sorry, no go.  There's no way I can defend returning a different value
for x<<y depending on the type of x.

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