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

[Guido van Rossum]

> Jack Jansen <Jack.Jansen@oratrix.com> writes:
> 
> > Yes, but due to the way the parser works everything works fine for
> > me. In the constant definition file it says "foo = 0xff000000". The
> > parser turns this into a negative integer. Fine with me, the bits
> > are the same, and PyArg_Parse doesn't complain.

[Martin]
> Please notice that this will stop working some day: 0xff000000 will be
> a positive number, and the "i" parser will raise an OverflowError.
> 
> By that time, you might be using the "k" parser, which will accept
> 0xff000000 both as a negative and a positive number, and fill the int
> with 0xff000000.
> 
> Before that happens, you might want to anticipate that problem, and
> propose an implementation that means minimum changes for you - it then
> will likely mean minimum changes for everybody else, as well. Perhaps
> "k" isn't such a good solution, perhaps "I" is better, or perhaps "i"
> should weaken its range checking, and emit a deprecationwarning when
> an unsigned number is passed.

Why is it so hard to get people to think about what they need?  (I
mean beyond "I don't want anything to change" or vague things like
that.  I am looking for an API that will make developers like Jack as
well as other extension developers happy, but it feels like pulling
teeth.  Have I not explained the issues and boundary conditions
clearly enough?  (About the only non-negotiable thing is that at some
point there shall be no difference in how ints and longs with the same
mathematical value are treated; and the fact that 0xffffffff shall be
a positive number whose value is 4294967295.)

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