re module apis return longs now

[Robie Basak]

In raring, some library functions are returning longs instead of ints. This is different from behaviour in quantal. This is causing an FTBFS in genshi due to doctest failures.

Building from upstream source exhibits correct behaviour, including from upstream orig tarballs and upstream 2.7 hg tip. But if I build using the packaging, I get the problem (including sid and experimental). So I presume the problem is in Debian's packaging. But the problem does not occur in a sid chroot, so is this Ubuntu toolchain related?

Test case:

import re
re.compile('.').match('.', 0).end()

Expected result: an int
Actual result: a long

[Barry Warsaw (barry)]

This is an upstream change, as a byproduct of issue #10182

http://bugs.python.org/issue10182

In that bug, a complaint was made that match starts were being truncated on x64 Windows machines, so the types were changed to longs. I can reproduce this with hg tip of the 2.7 branch, and the world will see it whenever 2.7.4 is released. You see it in Ubuntu because we track hg tip, so you're getting this change before 2.7.4 is released.

It's arguably a backward incompatible change to Python 2.7 and perhaps it should be reverted (but it's a tough call). I'll update the Python issue, but I suggest you nosey yourself to it and engage on the change there.

I think your description on this bug is inaccurate since afaict it only affects the re module. I'll update that, but if you know of other apis that are affected, please let me know.

[Barry Warsaw (barry)]

Cool, so Benjamin reverted the API change in upstream hg by using PyInt* instead of PyLong* apis. You'll see this the next time Matthias syncs to upstream.

[Matthias Klose (doko)]

fixed in 2.7.3-15ubuntu1

[Robie Basak (racb)]

genshi successfully rebuilt in 0.6-3ubuntu1 using the fixed Python.