There's an error in the way cmath computes the inverse sine, cosine and
tangent functions.

Example:
In 2.6: cmath.asin(2) returns 1.5707963267948966+1.3169578969248166j
However, the answer should be 1.5707963267948966-1.3169578969248166j
cmath.asin(2) returns the correct answer in 2.5.2.

Same problem exists in cmath.acos:
In 2.6: cmath.acos(2) = -1.3169578969248164j, but should be
1.3169578969248164j (once again, 2.5.2 returns the correct answer).

However, in 2.5.2 and 2.6, cmath.asin(1j) = 0.88137358701954283j, which
is correct.

I'm pretty sure that Python 2.6 is correct and Python 2.5 is wrong.

Python 2.6:
>>> cmath.asin(2.0)
(1.5707963267948966+1.3169578969248166j)
>>> cmath.asin(2.0+(+1E-300j))
(1.5707963267948966+1.3169578969248166j)
>>> cmath.asin(2.0+(-1E-300j))
(1.5707963267948966-1.3169578969248166j)

Python 2.5:
>>> cmath.asin(2.0)
(1.5707963267948966-1.3169578969248166j)
>>> cmath.asin(2.0+(+1E-300j))
(1.5707963267948966+1.3169578969248164j)
>>> cmath.asin(2.0+(-1E-300j))
(1.5707963267948966-1.3169578969248166j)

I used -1E-300j to get value that is almost a negative complex zero.

This is not a bug, at least in the sense that the behaviour of Python 
2.6 is intentional:  asin has branch cuts from 1 to infinity and -1 to -
infinity along the real axis.  As explained by the note at the top of 
the cmath documentation, on platforms with signed zeros (which is pretty 
much all platforms these days), the sign of the imaginary part of the 
argument is used to determine which side of the branch cut to use.  So:

>>> import cmath
>>> cmath.asin(complex(2.0, 0.0))
(1.5707963267948966+1.3169578969248166j)
>>> cmath.asin(complex(2.0, -0.0))
(1.5707963267948966-1.3169578969248166j)

This is fairly standard practice, and usually the right thing in 
applications;  see the Kahan paper referred to at the bottom of the 
cmath docs.  It also follows the suggestions outlined in Annex G of the 
C99 standard.