This is maybe a minor nit, but math.log(0) raises an OverflowError (range error) while math.log(0L) raises a ValueError (domain error). Seems to me they ought to behave the same. I noticed this in 2.2.2 but it's present in CVS. In 2.1, both return -Inf.
Logged In: YES user_id=44345 Ack! I realized this is probably platform-dependent. The results I reported on were for Mac OS X. Here's a little table of everything I could quickly get my hands on. Platform Python Version math.log(0) math.log(0L) Mac OS X 2.1.3 -Inf -Inf Mac OS X 2.2.2 OverflowError ValueError Mac OS X CVS OverflowError ValueError Win2k/MSVC 2.2.2 OverflowError ValueError Win2k/MSVC 2.3a2 OverflowError ValueError Win2k/cygwin 2.2.2 ValueError ValueError Solaris/gcc 2.95.2 2.3a2+ OverflowError ValueError
Logged In: YES user_id=31435 I'm happy enough the way it is. 2.2 specifically added the ability to get a good result for log (long) even when the long is far too large to fit in a float. That's why log(long) takes a different path starting in 2.2, and why there's no inconsistency across platforms in log(0L) behavior since 2.2. If you want consistency for log(0.0), then Python cannot allow the platfrom log to see 0.0: "standard" libm error behavior is platform-dependent, and error cases for log aren't unique in this respect: Python would have to write its own error- checking code around all libm functions. That's a much larger project than it may sound, and short of doing that, there's really no point special-casing the snot out of one specific log case. It might be better if the math module docs explained that the specific exceptions raised in assorted error cases (and even whether some arguments are considered to be exceptional at all) are, in reality, not defined in any useful cross-platform or cross-release way.
Logged In: YES user_id=3066 Reopened and assigned to Skip for a documentation patch he has. It will be applied *after* the 2.3b1 release; we're too far along at this point.
Logged In: YES user_id=3066 I'll also note that the patch should be applied for 2.2.3; there's no need to delay committing it on that branch. Thanks, Skip!