Neat!

Just a head's up - longdouble is a bit of an unloved feature. That said, this seems reasonable to support.

Some suggestions:

• I doubt the test you added exercises all the code paths in the code you added. Can you try to make sure your tests cover all the new code you added? Error cases are often poorly tested, for example.
• While we're at it, we could fix the casts between the string DTypes and the longdouble dtype - IIRC the casts have the same problem.

I wonder if the linalg test that is failing is relying on the old broken conversion.

Ping @SwayamInSync - you might be interested in this. Swayam has been working on a quad precision DType we're hoping will ultimately allow us to deprecate longdouble support (or at least the float128 alias) in NumPy proper. The fact that longdouble has a subtly different meaning under different architectures is a constant source of bug reports and most users won't need it at all.

Not a full review, but here are a couple issues that should be easy to fix:

• This will not handle an input such as '0.5j' correctly; it returns 0.5+0j.
• It incorrectly accepts an input such as '0.5 plate of shrimp'. It prematurely returns successfully in that case.

Again not a full review (sorry), but it looks like the failures are because the new CLONGDOUBLE_setitem() is not correctly handling all its possible inputs. It might be given, for example, a Python float, a Python complex, a NumPy complex64, a NumPy complex128, a NumPy float64, a NumPy longdouble, etc. I don't know the NumPy C API well enough off the top of my head to quickly suggest the minimal set of type checks and conversion functions that would handle all the cases that will be handed to CLONGDOUBLE_setitem().

Currently, I'm relying on Python's complex type to deal with Python types as input to CLONGDOUBLE_setitem(PyObject *op). But this causes a loss in precision when converting from a Python int to np.clongdouble. I tried to use npy_longdouble_from_PyLong to handle the case of converting from a Python int to np.clongdouble, but that change causes test_nep50_weak_integers_with_inexact to fail.

That test specifically excludes longdouble (notice it tests "dDG", but not "g"), which has the same int->string issue, so it would probably fine to just change the test to exclude "G" as well. That's not an ideal solution, I think the test should be rewritten so that if npy_longdouble_from_PyLong is changed in the future to go directly from int->longdouble, the test should either test what it was supposed to test, or xpass or something, but doing the same thing for clongdouble as is done for longdouble seems fine to me.

^{It's kinda funny because IIRC running the numpy tests is what was used to determine how small of a limit they could get away with for integer string conversion, and yet the chosen limit is still is a problem even for the numpy tests...}