[ENH] Exponentiation should follow Python semantics (or the current semantic difference should be documented)

Is your feature request related to a problem? Please describe. Exponentiation is common in scientific code. Currently, the way that Cython processes exponentiation is to have the result type match the operand type. This issue has been brought up many times before (see #2133 for example). This can be surprise to those who choose to compile their code to gain a speed boost, even in Pure Python mode. For example:

def sqrt(x: double):
  return x ** 0.5
print(sqrt(-1)) # -> Prints (6.123233995736766e-17+1j) with Python (3.10.5), and nan with Cython (3.0.0a10 on Windows)

As previously mentioned, this issue have been closed before, but the recommended remedy (which is to add documentation to the Caveats page) has not been done

Describe the solution you’d like Personally, I would like Cython to compile Pure Python code to match Python semantics as much as reasonable, and I think, since Cython 3 is open to breaking changes, that following Python semantics for exponentiation should be the default action moving forward.

Describe alternatives you’ve considered An alternative that I am also happy is to keep the current semantics, but to provide a note in the “Caveats” section of the documentation, in addition to providing a clear compile-time warning whenever the Cython compiler can not guarantee adherence to Python exponentiation semantics.

Additional context I am willing to make a PR to the Caveats documentation if that is the route the core Cython devs want to go. But, as an aside, my current PR for documentation on __cinit__ has yet to be approved.

[da-woods]

I’m going to give this a go today though and see if I can get something working… I’m optimistic that it won’t be a huge change so can be dealt with fairly quickly

[0dminnimda]

It still will be prettier to have a cpow() function IMHO, but now it’s more about preferences and beauty of the code