I think something like this would be better:

NPY_NO_EXPORT PyObject *
array_repr(PyArrayObject *self)
{
    if (PyArray_ReprFunction != NULL) {
        return PyObject_CallFunctionObjArgs(PyArray_ReprFunction, self, NULL);
    }

    /*
     * We need to do a delayed import here as initialization on module load
     * leads to circular import problems.
     */
    static PyObject *repr = NULL;
    npy_cache_import("numpy.core.arrayprint", "_default_array_repr", &repr);
    if (repr != NULL) {
        return PyObject_CallFunctionObjArgs(repr, self, NULL);
    }

    // Chain an explanation onto the `ImportError`, since something has gone very wrong,
    // likely due to something already being wrong for someone making changes to numpy.
    PyObject *exc, *val, *tb;
    PyErr_Fetch(&exc, &val, &tb);
    PyErr_Format(PyExc_RuntimeError, "Unable to configure ndarray.__repr__");
    npy_PyErr_ChainExceptionsCause(exc, val, tb);
    return NULL;
}

There's no need to do the import if we've configured a repr function by other means. This also results in a better traceback, without silencing the ImportError.

Note that using master and inserting

array([1,2,3]).__repr__()

in arrayprint before setting the repr function results in a segfault, the current default isn't working.

Thanks, that's good to know. I'm in favor of removing the broken fallback, but I think the above implementation is safer

I looked at PEP 0490 and implemented a helper function npy_PyExc_SetStringChained. It is local to the strfuncs file but we may want to move it after discussion to npy_3kcompat.

PEP 490 was rejected, PEP 3134 is the one that got accepted. I don't particularly like npy_PyExc_SetStringChained, because:

• It is named after a rejected PEP
• We only use it in two places
• It saves only three lines
• It doesn't generalize well, you end up with a Chained variant for every one of the PyExc_... functions

Umm, AFAICT, PEP 0490 was a followup to PEP 3134 (nee 344) extending it to C code. In any case, there are 30+ uses of npy_cache_import and the thought was that we might want to deal with some of those uses also. If not, we should just follow current practice and return NULL on failure.

Whoops, sorry for accusing you of having the wrong PEP.

In any case, there are 30+ uses of npy_cache_import and the thought was that we might want to deal with some of those uses also.

That's a fair argument. I'd maybe consider this failing import special, as someone who hits it is likely already trying to debug a bigger issue due to a change they made. Either is fine by me though - both are better than your original patch which discarded the ImportError.

_PyErr_FormatFromCause seems to be the name used internally by python, added in python/cpython@467ab19

I think that's a better name.

Since we use the limited API, I think we can just use _PyErr_FormatFromCause directly here and elsewhere.