#3777: long(4.2) returned an int, and broke backward compatibility.

the __long__ slot is allowed to return either int or long, but the behaviour of
float objects should not change between 2.5 and 2.6.

Reviewed by Benjamin Peterson

Lib/test/test_long.py

@@ -279,6 +279,10 @@ class LongTest(unittest.TestCase):
         self.assertEqual(long(314), 314L)
         self.assertEqual(long(3.14), 3L)
         self.assertEqual(long(314L), 314L)
+        # Check that long() of basic types actually returns a long
+        self.assertEqual(type(long(314)), long)
+        self.assertEqual(type(long(3.14)), long)
+        self.assertEqual(type(long(314L)), long)
         # Check that conversion from float truncates towards zero
         self.assertEqual(long(-3.14), -3L)
         self.assertEqual(long(3.9), 3L)

Misc/NEWS

@@ -12,6 +12,11 @@ What's New in Python 2.6 release candidate 1?
 Core and Builtins
 -----------------
 
+- Issue #3777: long() applied to a float object now always return a long
+  object; previously an int would be returned for small values. the __long__
+  method is allowed to return either an int or a long, but the behaviour of
+  float objects should not change to respect backward compatibility.
+
 - Issue #3751: str.rpartition would perform a left-partition when called with
   a unicode argument.
 

Objects/floatobject.c

@@ -1104,6 +1104,13 @@ float_trunc(PyObject *v)
 	return PyLong_FromDouble(wholepart);
 }
 
+static PyObject *
+float_long(PyObject *v)
+{
+	double x = PyFloat_AsDouble(v);
+	return PyLong_FromDouble(x);
+}
+
 static PyObject *
 float_float(PyObject *v)
 {
@@ -1897,7 +1904,7 @@ static PyNumberMethods float_as_number = {
 	0,		/*nb_or*/
 	float_coerce, 	/*nb_coerce*/
 	float_trunc, 	/*nb_int*/
-	float_trunc, 	/*nb_long*/
+	float_long, 	/*nb_long*/
 	float_float,	/*nb_float*/
 	0,		/* nb_oct */
 	0,		/* nb_hex */