Intersection of circles – How can I reduce this golf code to 127 bytes?

Use Python 2's arg unpacking: 124 bytes

from math import*;circleIntersection=lambda(v,w),(x,y),r:r*r*(lambda h:h<1and acos(h)-h*(1-h*h)**.5)(hypot(v-x,w-y)/r/2)//.5

Try it online!

Python 2 has parameter unpacking, allowing the input point arguments to be taken directly as pairs (v,w) and (x,y), where the input lists like [0,0] and [0,10] will be unpacked into the respective variables. This feature was removed in Python 3 -- a pity, in my opinion, since the old syntax seems more readable. But, the site has a Python 2 option, and nothing in your solution relies on Python 3.

Use def: 125 bytes

You have a classic dilemma of wanting to assign to a variable without losing the brevity of a lambda function. Your method of using an inner lambda for assignment is one solution. The problem site not having Python 3.8 means the walrus operator is unfortunately off limits.

But, it's shorter here to just use def and suck up the bytes of writing out return. This is generically a 7-byte cost according to this reference. Within the def, we can just write the statement h= to do the assignment. We put everything on one line separated with ; to avoid needing to indent.

125 bytes

from math import*
def circleIntersection(a,b,r):h=hypot(b[0]-a[0],b[1]-a[1])/r/2;return(h<1and acos(h)-h*(1-h*h)**.5)*r*r//.5

Try it online! (vs original)

I've changed the multiplication order from return r*r*(...)//.5 to return(...)*r*r//.5 to cut the space after return.

There are likely other byte saves, including FryAmTheEggman's switch to numpy, but refactoring from lambda to def is already enough to get below 128 bytes.

Direct translation to NumPy: 127 bytes

from numpy import*
circleIntersection=lambda a,b,r:r*r*(lambda h:h<1and arccos(h)-h*(1-h*h)**.5)(hypot(*subtract(b,a))/r/2)//.5

Try it online!

Converting your code to numpy seems to save the required bytes. While using hypot is still ugly, being able to splat the result of subtract is still enough shorter that the loss of converting to arccos doesn't matter.

It is possible this can save more since it doesn't error on h<1 and will return nan in the case that the circles do not intersect. I don't know if that is permissible though since nan is not equal to zero.

I'm not convinced this is optimal, in particular I didn't look at improving the algorithm at all.