[Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

[Michael Hudson]

Keith Dart <kdart at kdart.com> writes:

> I am very concernced about something. The following code breaks with 2.4.1:
>
> fcntl.ioctl(self.rtc_fd, RTC_RD_TIME, ...)
>
> Where RTC_RD_TIME = 2149871625L
>
> In Python 2.3 it is -2145095671.

Well, you could always use "-2145095671"...

> Actually, this is supposed to be an unsigned int, and it was construced
> with hex values and shifts.

But well, quite.

> Now, with the integer unification, how is ioctl() supposed to work? I
> cannot figure out how to make it work in this case.

The shortest way I know of going from 2149871625L to -2145095671 is
the still-fairly-gross:

>>> v = 2149871625L
>>> ~int(~v&0xFFFFFFFF)
-2145095671

> I suppose the best thing is to introduce an "unsignedint" type for this
> purpose. 

Or some kind of bitfield type, maybe.

C uses integers both as bitfields and to count things, and at least in
my opinion the default assumption in Python should be that this is
what an integer is being used for, but when you need a bitfield it can
all get a bit horrible.

That said, I think in this case we can just make fcntl_ioctl use the
(new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just
be able to use 2149871625L and be happy (I think, haven't tried this).

> As it is right now, I cannot use 2.4 at all.

/Slightly/ odd place to mae this report!  Hope this mail helped.

Cheers,
mwh

-- 
  I'm okay with intellegent buildings, I'm okay with non-sentient
  buildings. I have serious reservations about stupid buildings.
     -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)