Repository: numpy/numpy
File: numpy/_core/src/umath/dispatching.cpp (C++)

Code before:
                        "Failed to create argsort method for %R",
                        dtype);
                return -1;
            }

            NPY_DT_SLOTS(dtype)->argsort_meth = argsort_meth->method;
            Py_INCREF(argsort_meth->method);
            Py_DECREF(argsort_meth);
        }
        else {
            PyObject *ufunc =
                PyObject_GetAttrString(PyImport_ImportModule("numpy"), slot->ufunc_name);
            if (ufunc == NULL) {
                return -1;
            }

            if (!PyObject_TypeCheck(ufunc, &PyUFunc_Type)) {
                PyErr_Format(PyExc_TypeError,
                        "numpy.%s was not a ufunc!", slot->ufunc_name);
                Py_DECREF(ufunc);
                return -1;
            }

            int ret = PyUFunc_AddLoopFromSpec_int(ufunc, slot->spec, 0);
            if (ret < 0) {
                Py_DECREF(ufunc);
                return -1;
            }

            Py_DECREF(ufunc);
        }
    }

    return 0;
}


/**
 * Resolves the implementation to use, this uses typical multiple dispatching
 * methods of finding the best matching implementation or resolver.
 * (Based on `isinstance()`, the knowledge that non-abstract DTypes cannot
 * be subclassed is used, however.)
 *
 * NOTE: This currently does not take into account output dtypes which do not
 *       have to match.  The possible extension here is that if an output
 *       is given (and thus an output dtype), but not part of the signature
 *       we could ignore it for matching, but *prefer* a loop that matches
 *       better.
 *       Why is this not done currently?  First, it seems a niche feature that
 *       loops can only be distinguished based on the output dtype.  Second,
 *       there are some nasty theoretical things because:

Review comment (refactor):
Move this before the `if` so that you can remove the one on l.256 as well. In fact, you could just fall through altogether, but perhaps that's too risky...

Code after:
                return -1;
            }

            NPY_DT_SLOTS(dtype)->sort_meth = sort_meth->method;
            Py_INCREF(sort_meth->method);
            Py_DECREF(sort_meth);
        }
        else if (ufunc == npy_runtime_imports.argsort) {
            Py_DECREF(ufunc);

            PyArray_DTypeMeta *dtype = slot->spec->dtypes[0];
            PyBoundArrayMethodObject *argsort_meth = PyArrayMethod_FromSpec_int(slot->spec, 0);
            if (argsort_meth == NULL) {
                return -1;
            }

            NPY_DT_SLOTS(dtype)->argsort_meth = argsort_meth->method;
            Py_INCREF(argsort_meth->method);
            Py_DECREF(argsort_meth);
        }
        else {
            if (!PyObject_TypeCheck(ufunc, &PyUFunc_Type)) {
                PyErr_Format(PyExc_TypeError, "%s was not a ufunc!", slot->name);
                Py_DECREF(ufunc);
                return -1;
            }

            int ret = PyUFunc_AddLoopFromSpec_int(ufunc, slot->spec, 0);
            Py_DECREF(ufunc);
            if (ret < 0) {
                return -1;
            }
        }
    }

    return 0;
}


/**
 * Resolves the implementation to use, this uses typical multiple dispatching
 * methods of finding the best matching implementation or resolver.
 * (Based on `isinstance()`, the knowledge that non-abstract DTypes cannot
 * be subclassed is used, however.)
 *
 * NOTE: This currently does not take into account output dtypes which do not
 *       have to match.  The possible extension here is that if an output
 *       is given (and thus an output dtype), but not part of the signature
 *       we could ignore it for matching, but *prefer* a loop that matches
 *       better.
 *       Why is this not done currently?  First, it seems a niche feature that