On Fri, Mar 29, 2024 at 8:07 AM Steven G. Johnson <stev...@mit.edu> wrote:
> Should a dtype=object array be treated more like Python lists for type > detection/coercion reasons? Currently, they are treated quite differently: > >>> np.isfinite([1,2,3]) > array([ True, True, True]) > In this case, the `[1, 2, 3]` is being converted into an array of integers before it is acted upon by `np.isfinite`. The function needs an array and the list-to-array coercion selects a reasonably narrow dtype based on the values in the list. In principle, the dtype of the list of Python `int` values could be `object`, `np.int64`, `np.int32`, or maybe even a floating point type (because integers are a subset of the reals), but `np.int64` is reasonable. (Although on Windows, the choice is `np.int32`!) When the `np.isfinite` function is given an array, which already has a specified dtype, it takes that dtype seriously and doesn't try to change it. So, given `np.array([1, 2, 3], dtype=object)`, no coercion is attempted, and `np.isfinite` can't operate on arrays with that dtype. The difference with respect to Julia is that types are more of a focal point of user attention than in Python. NumPy array types are a focal point of user attention, but Python types are less so. `Any[]` is a good analogue of NumPy arrays with `dtype=object` in the sense that functions don't try to downcast them to the narrowest type supported by their values, but there isn't a good Julia analogue of a Python list, which is fair game for such downcasting. A Python user, like me, *wants* NumPy to figure out that if I pass `[1, 2, 3]` to a function that needs an array, it should cast it as an array of integers—at least when I'm in the hacking stage of developing a project or interactively trying things out in a terminal or Jupyter. Later, to have more control over a project that's getting more mature, I'll be explicit about types and explicitly cast them as NumPy arrays with specified dtypes. (For example, to ensure that integer types have the same bit width on all platforms.) Since Julia uses types to determine which implementation of a function to run, Julia can't be this loose about types at any stage of development: invoking a different method-overload of a function is not a small, gradual change. For the interface between Python and Julia, then, there are going to be some hard decisions to make. Not every type on one side has a good equivalent on the other. Personally, I would consider it reasonable for all Julia AbstractArrays to transfer to Python as NumPy arrays—none of them as Python lists. The transformation can't be bijective because Python lists would transfer to Julia as `Any[]`. Users of both languages would have to be aware that the conversion doesn't round-trip. -- Jim
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
