This is a very odd inconsistency in math.log behavior.  That said, it is probably only a single bit imprecision at the end of the float result.  Still, 10 == 10L so I'd expect math.log of both to give the same result.

oss/cpython/2.7:LOAS$ ./python
Python 2.7.5+ (2.7:395ac61ebe1a, Aug 14 2013, 07:11:35) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(10) - math.log(10L)
4.440892098500626e-16
>>> math.log(10)
2.302585092994046
>>> math.log(10L)
2.3025850929940455
>>> 

In Python 3.3 things seem fine and match the int behavior from 2.7 above despite the internal number implementation being a PyLong in 3.x:

>>> math.log(10)
2.302585092994046

Fascinating, how did you find the issue?

Yup - 2.7 evaluates this in a less precise way, as

log(10L) = log(10./16 * 2**4) = log(0.625) + log(2)*4

>>> log(10L) == log(0.625) + log(2)*4
True

This patterns works well even for longs that are far too large to represent as a double; e.g.,

>>> log(1L << 50000)
34657.35902799726

which is evaluated internally as log(0.5) + log(2) * 50001:

>>> log(1L << 50000) == log(0.5) + log(2) * 50001
True

Python 3 is more careful, falling back to this pattern _only_ if converting the long to a double overflows.  Of course 10L can be represented exactly as a double, so Python 3 evaluates it directly as log(float(10L)) = log(10.0).  It's minor difference overall, but definitely visible ;-)

We found this while refactoring an API to be more consistent about returning longs vs ints in specific cases.  This resulted in another unittest that was using math.log for a nicer display of the value by magnitude to fail as the result was slightly different for the two input types.

arguably that is a fragile test as it cares about the last couple bits of a float... but that such a test exists does suggest that making a future 2.7.6+ release more pedantic about the behavior on values that safely fit into a double might break an odd test or three out there.  OTOH, it makes things more consistent all around and match 3.x in both cases so I'm still be for doing it.

FYI, the improvement was made in these 2 changesets:

c8dc4b5e54fb
a9349fd3d0f7

If desired, those could presumably be grafted back into the 2.7 branch.

The commit messages refer to issue #9599, but that appears to be mistaken.

OK, the correct one is issue #9959.

Ah, Tim saw through my cunningly-laid false trail of incorrect issue numbers.  Step 1 of my world domination plan is foiled!

Yes, let's fix this.  In my mind, it's definitely a bug that ints and longs aren't interchangeable here, and it would be nice to have 2.7 and 3.x behaving the same way.  I do have some worries about the fix breaking / changing existing code, but given that it'll only affect log of a long, those worries barely register.

+1 on fixing it in 2.7, for the reasons Mark gave.

Way back when I introduced the original scheme, log(a_long) raised an exception, and the `int` and `long` types had a much higher wall between them.  The original scheme changed an annoying failure into a "pretty good" approximation, and because int operations never returned a long back then the relatively rare code using longs forced their use.

In the meantime, you can change failing cases of log(some_long) to log(int(some_long)).  int(some_long) will convert to int if possible (avoiding this path in the log code), but return some_long unchanged otherwise.  In the old days, int(some_long) would fail if some_long was too big to fit in an int - that's different now too - and for the better :-)

Here's a patch that simply backports the Python 3.x code to Python 2.7.

New changeset f543863f4e43 by Mark Dickinson in branch '2.7':
Issue #18739: Fix inconsistent results from math.log(n) and math.log(long(n))
http://hg.python.org/cpython/rev/f543863f4e43

Patch applied.