Nathan Goldbaum
Nathan Goldbaum
Yup, right now the suggestion is: don't do that. NumPy isn't thread safe in Python programs and has never been thread safe. Free-threading makes this more acute but it's a...
Maybe you want to use a `UnitSystem`? ``` In [27]: us = unyt.unit_systems.UnitSystem(name="my_unit_system", mass_unit=73833316470723*unyt.Msun/5000, length_unit='m', time_unit='s') In [28]: m = (1e13*unyt.Msun).to(us['mass']) In [29]: (arr[arr > m].min()).to('Msun') Out[29]: unyt_quantity(1.3776737e+13, dtype=float32, units='Msun')...
The issue is that `unyt.Msun` is in kg, so unyt tries to convert `arr` to kg to match, and that causes an overflow. > Why do I get an array...
Maybe? There would likely be a performance cost to do that check. Currently no effort is made to avoid overflows when doing these sorts of conversions.
Maybe open a CPython bug? It seems reasonable to me for python to add locking for global state in the C standard library.
This is almost certainly some broken error checking in C code somewhere.
While there's certainly some screwed up error handling happening somewhere, I can't reproduce the `SystemError` on my development setup and https://github.com/numpy/numpy/pull/29230 seems to avoid the issue.
the fix isn't merged yet so reopening
I like where this is going, but I think care needs to go into edge cases so we don't unnecessarily add noise. If *all* the values are different in two...
The linter still needs to be fixed.