Fwd: Optional control over 0D array return behavior in PyArray_Return
Hello NumPy developers, I would like to propose an optional mechanism to control the behavior of 0-dimensional array return conversion in PyArray_Return. Currently, 0D NumPy arrays are automatically converted into Python scalars in many operations. In some workflows, it is desirable to preserve the ndarray object instead. Proposed idea: - Introduce an opt-in mechanism (initially implemented as a global flag) to control whether 0D arrays are converted to scalars or preserved as ndarray objects. - Default behavior remains unchanged for full backward compatibility. Motivation: In certain array-centric workflows, implicit scalar conversion of 0D arrays can lead to loss of consistency when uniform ndarray behavior is desired. I have implemented a prototype PR here: <https://github.com/numpy/numpy/pull/31221> However, I was informed that this kind of change requires prior discussion on the mailing list before proceeding further. I would appreciate feedback on: - whether this direction is acceptable - whether a global flag is appropriate - or if an alternative design (context-local, function-level, etc.) would be preferred Thank you for your time.
Hi Breno, Part of what you want is implemented by using `out=...`, though I can see the benefit of that happening by default. All the best, Marten Breno Augusto Favaretto via NumPy-Discussion <numpy-discussion@python.org> writes:
Hello NumPy developers,
I would like to propose an optional mechanism to control the behavior of 0-dimensional array return conversion in PyArray_Return.
Currently, 0D NumPy arrays are automatically converted into Python scalars in many operations. In some workflows, it is desirable to preserve the ndarray object instead.
Proposed idea: - Introduce an opt-in mechanism (initially implemented as a global flag) to control whether 0D arrays are converted to scalars or preserved as ndarray objects. - Default behavior remains unchanged for full backward compatibility.
Motivation: In certain array-centric workflows, implicit scalar conversion of 0D arrays can lead to loss of consistency when uniform ndarray behavior is desired.
I have implemented a prototype PR here: <https://github.com/numpy/numpy/pull/31221>
However, I was informed that this kind of change requires prior discussion on the mailing list before proceeding further.
I would appreciate feedback on: - whether this direction is acceptable - whether a global flag is appropriate - or if an alternative design (context-local, function-level, etc.) would be preferred
Thank you for your time.
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: mhvk@astro.utoronto.ca
Although I'm in favor of migrating away from scalars in favor of 0d arrays, I don't like the idea of using a global state (flags, contextmanagers, etc) for this. Mostly because that isn't possible to write static type annotations for, can be problematic when using multiple threads or processes, and because it's a global state it'd also affect downstream libraries and likely breaking them.
Thanks for the feedback. I agree that using global state (flags or a context manager) introduces issues, especially for static typing and in multi-threaded contexts. My main motivation is ensuring consistent return types. The implicit conversion from 0D arrays to scalars can be surprising and makes type reasoning less predictable. My initial idea was to introduce a flag for `np.clip` to control this behavior, but my implementation ended up being quite indirect. While `out=` provides a way to preserve 0D arrays, it feels somewhat indirect and not very ergonomic for this use case. An explicit API would likely be preferable over global state, but I also realize it may not be practical given how deeply this behavior is embedded across ufuncs and other functions. Curious to hear if something along those lines would be more acceptable.
participants (4)
-
Breno Augusto Favaretto -
brenoaugustofavaretto＠gmail.com
-
Joren Hammudoglu -
Marten van Kerkwijk