I'll have a couple hours to kill in the Montreal airport this afternoon and will test this and see if I can reproduce the issue.

I'll have a couple hours to kill in the Montreal airport this afternoon and will test this and see if I can reproduce the issue.

Thanks @ngoldbaum happy journey

I can reproduce the issue. I bet you can too if you set up a conda environment like this on your Mac:

micromamba create -n quad -c conda-forge python numpy
micromamba activate quad
pip install numpy_quaddtype
python -c "import numpy_quaddtype"

I'm also noticing that quaddtype now has a build dependency on an unreleased version of NumPy - which is a little annoying to work around...

I can also confirm that this PR allows me to successfully import numpy_quaddtype after installing a from-source build. Because I can't easily create an isolated build environment with an unreleased numpy version, I couldn't check if building and installing a wheel also works, but I suspect it does.

So, I think this is good. One question though: is the py_quadblas_set_num_threads function still safe to expose publicly in the Python API?

I'm also noticing that quaddtype now has a build dependency on an unreleased version of NumPy

Yes, we switched to the nightly releases to keep the work going in NumPy and stay here in sync

One question though: is the py_quadblas_set_num_threads function still safe to expose publicly in the Python API?

Right, I am happy to remove it as by default openmp uses all hardware threads on a system and instead of these APIs user can use threadpoolctl in case of oversubscription
Although changing them during runtime using current APIs never crashed for me

Nah, let's only remove it if it actually is a problem. In it goes!

Because of the new numpy version bound you should consider opening a 0.2.x maintenance branch based on 0.2.0, backport this fix, and then do a 0.2.1 release so users don't hit this issue.