Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import ldexp
>>> from sys import maxint

>>> ldexp(1.234, maxint//2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error

>>> ldexp(1.234, maxint)
0.0

>>> ldexp(1.234, -maxint)
0.0

>>> ldexp(1.234, -maxint-2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

The first and third cases seem right.

The second is clearly a bug.

In the fourth case, it would be more correct to return 0.0 than to raise
an exception IMHO.

ldexp(1.234, maxint) works as expected in our trunk-math branch.
ldexp(1.234, -maxint-2) fails with the same error message.

I agree that the second and fourth cases are bugs.

The second case looks like a Windows only problem:  I get the expected 
OverflowError on both OS X 10.5.2/Intel and SuSE Linux 10.2/i686.

The fourth case is cross-platform, and occurs also for large exponents:

>>> ldexp(1.234, maxint+1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

It's still present in Python 3.0.

I'll take a look.

There are similar problems with integer shifts.  In the trunk:

>>> 1>>(2**40)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

and in Python 3.0:

>>> 1>>(2**40)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

These should probably by fixed, too, though at least the error
message is clear.

What should 1<<(2**31) do?

Here's a patch that should fix ldexp(x, large_int), as follows:

ldexp(x, n) = x if x is a NaN, zero or infinity
ldexp(x, n) = copysign(0., x) for x finite and nonzero, n large and -ve
ldexp(x, n) -> OverflowError for x finite and nonzero, n large and +ve

It would be good if someone else could review this before I check it in;
Fredrik, would you have time for this?

I'm not qualified to comment on the implementation. The test cases all
look right.

I've committed a (slightly reworked) version of this patch in r62948.
Closing this issue; the problem with 1 >> 2**31 is a separate issue.  

Thanks for the report, Fredrik.