[Python-Dev] int/long FutureWarning

[Jack Jansen]

Replying to various postings at once:

Mark Hammond wrote:
> Well, I am afraid it is slightly more than "no problem" for me if it=20=

> means I
> need to read the doc for and potentially touch *every single* function=20=

> in
> the Win32 extensions that accepts an integer as an input arg.

Exactly the same here. I have 2206 automatically generated Mac API=20
functions, and
each of these would have to be inspected.

Martin v. L=F6wis wrote:
> To silence the warning, you should really add "L" suffixes to all
> those literals - or we could provide a future statement, where you
> indicate that you want those literals to become positive longs *now*;
> you'ld need to add this statement once per module.

The future statement would solve most of the headaches (combined with
the 32 bit value parser that accepts both int and long).

Martin again:
> If we think that the case "large numbers are bitmaps" is more common
> than the case "large numbers are large numbers", we should drop the
> range check for the existing converters, and add new converters in
> case somebody wants large numbers instead of bitmaps, which then do
> the range checks.

This would be ideal, of course. But note that for me changing the=20
format char
is a minor issue, as long as the behavior of the new format char is as=20=

expected
(any 32 bit value is okay, and iff there is a way 32 bit constants can=20=

become longs
in the parser then those longs should be passed as 32 bit ints too).
Those 2206 routines mentioned above are automatically generated. There=20=

are a couple
of tens of manually generated wrappers, but as I've written those=20
myself, mainly,
there's a chance I will know what to do:-)

But of course I don't know how this would be for Mark...
--
- Jack Jansen        <Jack.Jansen@oratrix.com>       =20
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma=20
Goldman -