How about something like this:

_DTYPE_RANK = dict(zip(map(dtype, "fdFD"), range(4)))

max_rank = -1
for dtype in dtypes:
    if dtype.num < 11:  # <: integer | bool
        continue
    if (rank := _DTYPE_RANK.get(dtype)) is None:
        raise TypeError(...)
    if rank == 3:  # no need to go on
        return cdouble, cdouble
    if rank > max_rank:
        max_rank = rank

if max_rank > 1:
    return cdouble, (csingle, cdouble)[max_rank - 2]
else:
    return double, (single, double)[max_rank]

I didn't test it, but I expect this to be quite a bit faster (and it might even be correct, too). Anyway, even if not correct, I'm sure you get the idea.

Ideally, we don't rely on implementation details like type numbers... Also, no real reason to exclude user dtypes that know how to convert to double, etc. Using promote_types puts the burden where it belongs (and is in C, so pretty fast).

The promote_types approach is a bit faster than the PR here, so I will look into that option.

The main performance gain is from the if r.dtype != a.dtype: check. I want to see whether we can handle that inside the astype.

@mhvk To avoid the copy on the scalar we can also check in astype whether a copy is needed. A prototype for this is:

main...eendebakpt:numpy:astype

The advantage over the if r.dtype != a.dtype check is that it makes calls to scalar.astype faster (if no conversion is needed), also in other cases. The disadvantage is this adds some more complexity at the C side (and a very minor slowdown for the path where a conversion is needed).

At this moment I have no strong preference for either options, so any arguments in either direction are welcome.

@eendebakpt - I think your patch makes sense in principle, but is perhaps a bit orthogonal to the goals here? At least, I wrote the if statement mostly to avoid the second call to promote_types.

@mhvk Your patch looks good, I might end up refactoring this PR in that way.

It would be nice to also refactor the other methods calling _commonType in the same style. The np.promote_types does only handle 2 arguments (we need 3 some some methods). The np.result_type handles any number of arguments, but is quite a bit slower. I opened #28710 to improve performance, but it does not come close the promote_types performance (mainly due to dispatcher overhead).

p.s. For det at least, there is no need for _assert_stacked_square either - the gufunc will already check that there are at least 2 dimensions and that the last two are equal.

True, but _assert_stacked_square raises a LinAlgError and the gufunc a ValueError. So removing that check might lead to some backwards compatibility issues.