Repository navigation
Description
I'm seeing a spurious warning from a C extension in numpy, that only appears when running a pre-built interpreter from python-build-standalone (as far as I can tell).
# t.py
from astropy.coordinates import Angle
from astropy.units import degree
angle = Angle("1.0", unit=degree)
angle.to_string()run with uv run python -Werror t.py
Traceback (most recent call last):
File "/home/clm/dev/gh/astropy/astropy/t.py", line 5, in <module>
angle.to_string()
~~~~~~~~~~~~~~~^^
File "/home/clm/dev/gh/astropy/astropy/astropy/coordinates/angles/core.py", line 387, in to_string
result = format_ufunc(self.to_value(unit))
File "/home/clm/dev/gh/astropy/astropy/.venv/lib/python3.14/site-packages/numpy/lib/_function_base_impl.py", line 2518, in __call__
return self._call_as_normal(*args, **kwargs)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
File "/home/clm/dev/gh/astropy/astropy/.venv/lib/python3.14/site-packages/numpy/lib/_function_base_impl.py", line 2511, in _call_as_normal
return self._vectorize_call(func=func, args=vargs)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
File "/home/clm/dev/gh/astropy/astropy/.venv/lib/python3.14/site-packages/numpy/lib/_function_base_impl.py", line 2600, in _vectorize_call
outputs = ufunc(*args, out=...)
RuntimeWarning: invalid value encountered in do_format (vectorized)
It's a bit opaque since both numpy and astropy's internal logic is involved, and I'm 99% sure astropy isn't actually needed to reproduce (I'll be trying to eliminate this bit shortly), but here are a couple key details:
astropy.coordinates.Angle.to_stringruns an internal closure that's produced fromnp.vectorize- my understanding is that this warning normally corresponds to an invalid (nan) is received. Here the only value that is actually passed to the vectorized closure is
np.ndarray(np.float64(1.0), dtype=object)
I discovered this in CI, and I'm able to reproduce this locally under the following conditions:
- run on Linux: I can't reprod on macOS
- run with a release-build of numpy (either a wheel or a local build with default settings): the warning disappears when numpy is compiled in debug mode
- all versions of Python I tested are affected
- but only builds from python-build-standalone (that I use via uv): if I build my own interpreter locally, or if I switch to
actions/setup-pythonin CI, no warning is emitted.
Furthermore, my CI started failing with this warning on dec 20. My last successful job ran on dec 18. I'm surprised to see that uv didn't get a release since dec 9. Maybe my mental model for how python-build-standalone is used in uv is just wrong; I was working under the assumption no changes here would affect uv before it was mirrored (upgraded) there.
I'm very much out of my depth and currently out of ideas about where the problem might be coming from exactly, but I only see it with this project's relocatable builds of Python so this is where I'm starting my quest for help. I'll attempt to minimize my reproducer now.
Activity
jjhelmus commentedon Jan 6, 2026
I was able to reproduce this issue on Linux with Python 3.14.2. Have you been able to minimize this at all to something smaller? astropy/astropy#18989 mentions the same RuntimWarning.
neutrinoceros commentedon Jan 7, 2026
I was hoping it would take only a couple minutes but this didn't turn out the way I thought, so I haven't found the time to do it yet. Thanks for making the connection with this astropy issue ! clearly I was aware of it at some point but didn't connect the dots. I further note that astropy's CI is using
uvviatox-uvbut not uv-managed python interpreters. The plot thickensjjhelmus commentedon Jan 7, 2026
I was able to get this to a much smaller reproducer that only uses NumPy.
Produces a RuntimeWarning only on python-build-standalone on Linux.
neutrinoceros commentedon Jan 7, 2026
excellent, that's just what I was aiming for ! Can you clarify what interpreter you're using here ?
jjhelmus commentedon Jan 7, 2026
For the pbs interpreter I'm using the most recent build of 3.14.2 (Dec 17 2025). For comparison I'm using a conda environment with python 3.14.2 from conda-forge. The conda environment does not produce a runtime warning. Both are on a Ubunutu 24.04 system with an x86-64 CPU.
I was able to remove the use of
np.vectorizeand usefrompyfuncdirectly to produce the ufunc:numpy/numpy#27760 points out that error reporting in ufuncs created via vectorize (but also likely frompyfunc) is inconsistent.