[Python-Dev] Deprecation warning on integer shifts and such
Guido van Rossum
Mon, 12 Aug 2002 09:23:58 -0400
> > 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
> 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
> 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/)