int vs long

[Gabriel Genellina]

En Mon, 17 Dec 2007 10:30:05 -0300, Nick Craig-Wood <nick at craig-wood.com>  
escribió:

> Gabriel Genellina <gagsl-py2 at yahoo.com.ar> wrote:
>>  En Sun, 16 Dec 2007 20:28:02 -0300, Troels Thomsen <"nej
>>  tak..."@bag.python.org> escribi?:
>>
>> >
>> > The readFile function from the win32 package aparently really expect  
>> an
>> > integer :
>> >
>> >     def inWaiting(self):
>> >         """Returns the number of bytes waiting to be read"""
>> >         flags, comstat = ClearCommError(self.__handle)
>> >         return comstat.cbInQue
>> >
>> > ReadFile(h, s.inWaiting())
>> >
>> > My code crashes because inWaiting returns a long, not an int
>>
>>  That's very strange. The cbInQue field is a DWORD in C, seen as an int  
>> in
>>  Python. How do you know it returns a long?
>>
>> > Why is that different on my machine and my collegues ? Have I or he
>> > installed a wrong version of a package?
>> > CPython 2.5.
>>
>>  And pywin32 build 210, I presume.
>>
>> > Was not expecting int<->long type problems in excactly python  
>> language.
>> > Is that because we are navigating so close to the win32 api that the
>> > types
>> > are more strictly enforced ?
>>
>>  Somewhat. At the API level, function arguments have to be converted to
>>  native C types, like ReadFile expecting a DWORD. Any number greater  
>> than
>>  2**32 won't fit, but I can't think how such thing could happen looking  
>> at
>>  those few posted code lines.
>
> Actually any number >= 2**31 won't fit in a python int.
>
>   >>> 2**31
>   2147483648L
>
> According to my headers DWORD is defined like this
>
>   typedef unsigned long DWORD;
>
> So you might see longs returned when you expected ints if the result
> was >= 0x8000000.

More than 2GB waiting to be read from a serial port? If that were the case  
the OP has a very big throughput problem rather than an API mismatch :)

-- 
Gabriel Genellina