Exposing `from_dlpack` to the main namespace
Hi, just a brief note that: https://github.com/numpy/numpy/pull/21145 will add `np.from_dlpack` (to import objects implementing the `__dlpack__` dunder [1]. It was added with an underscore mainly due to unlucky timing, IIRC. There may also be some choices that could be different, but I believe they ended up on the restrictive side for now so that shouldn't need to worry us. So this is just a heads-up, since it is an API addition, and I am not sure it was brought up on the mailing list before. Cheers, Sebastian [1] https://dmlc.github.io/dlpack/latest/python_spec.html
Hi Sebastian, On Tue, Mar 8, 2022, at 07:41, Sebastian Berg wrote:
just a brief note that:
https://github.com/numpy/numpy/pull/21145
will add `np.from_dlpack` (to import objects implementing the `__dlpack__` dunder [1].
In other places in the ecosystem, like pandas and xarray, `from_x` and friends live as static methods on their respective classes. Any reason not to add this as `numpy.array.from_dlpack`? We may also want to consider adding all the other `from*`'s there and deprecating the original usage (without removing it). Stéfan
On Tue, Mar 8, 2022 at 8:27 AM Stefan van der Walt <stefanv@berkeley.edu> wrote:
In other places in the ecosystem, like pandas and xarray, `from_x` and friends live as static methods on their respective classes. Any reason not to add this as `numpy.array.from_dlpack`? We may also want to consider adding all the other `from*`'s there and deprecating the original usage (without removing it).
Pandas and Xarray make almost everything else a method, too, and encourage using "method chaining" for manipulating datasets. So I'm not sure they are great precedents here. I think static/class methods are a fine way to write constructors, but are not inherently superior. My vote would be to keep it as a function for consistency with existing numpy constructors like frombuffer. It might even make sense to call it np.fromdlpack, though the underscore really does increase readability.
On Tue, 2022-03-08 at 08:26 -0800, Stefan van der Walt wrote:
Hi Sebastian,
On Tue, Mar 8, 2022, at 07:41, Sebastian Berg wrote:
just a brief note that:
https://github.com/numpy/numpy/pull/21145
will add `np.from_dlpack` (to import objects implementing the `__dlpack__` dunder [1].
In other places in the ecosystem, like pandas and xarray, `from_x` and friends live as static methods on their respective classes. Any reason not to add this as `numpy.array.from_dlpack`? We may also want to consider adding all the other `from*`'s there and deprecating the original usage (without removing it).
One thing I did not mention, is that what the data-api folks included the symbol in their namespace [1]. So keeping it in the main namespace has the benefit of aligning with that. A class-/staticmethod would be an interesting API choice. But I suppose it would mainly be nice if we have a clear intention of moving the others, too? (Which unfortunately seems slow?) If we almost certainly only consider duplicating this as methods, I would tend to not worry about it for this PR – adding it doesn't stop us from doing that later. But of course it may still be a good time to discuss it! An annoyance with methods is that our class is `np.ndarray` with an awkward `__new__` [2]. So if it is `np.array.from_*` it would not be (only) a static- or classmethod, but also attached to that function. Cheers, Sebastian [1] https://data-apis.org/array-api/latest/API_specification/generated/signature... [2] I suppose there may be a point in moving `np.ndarray(...)` users to something more appropriate. And maybe even eventually making `np.array` the actual class. But, if possible, the last part would be a very long haul.
Stéfan
On Tue, Mar 8, 2022, at 09:01, Sebastian Berg wrote:
An annoyance with methods is that our class is `np.ndarray` with an awkward `__new__` [2]. So if it is `np.array.from_*` it would not be (only) a static- or classmethod, but also attached to that function.
It sounds like there are several good reasons not to go the static route; thanks for considering, though. Stéfan
On Tue, Mar 8, 2022 at 10:02 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Tue, 2022-03-08 at 08:26 -0800, Stefan van der Walt wrote:
Hi Sebastian,
On Tue, Mar 8, 2022, at 07:41, Sebastian Berg wrote:
just a brief note that:
https://github.com/numpy/numpy/pull/21145
will add `np.from_dlpack` (to import objects implementing the `__dlpack__` dunder [1].
In other places in the ecosystem, like pandas and xarray, `from_x` and friends live as static methods on their respective classes. Any reason not to add this as `numpy.array.from_dlpack`? We may also want to consider adding all the other `from*`'s there and deprecating the original usage (without removing it).
One thing I did not mention, is that what the data-api folks included the symbol in their namespace [1]. So keeping it in the main namespace has the benefit of aligning with that.
The array API specification doesn't even have an "array" object as part of the namespace. Only top-level creation functions are supported for creating arrays. But it's also true in general that the array API specification prefers a functional API to methods on the array object. Aaron Meurer
A class-/staticmethod would be an interesting API choice. But I suppose it would mainly be nice if we have a clear intention of moving the others, too? (Which unfortunately seems slow?)
If we almost certainly only consider duplicating this as methods, I would tend to not worry about it for this PR – adding it doesn't stop us from doing that later. But of course it may still be a good time to discuss it!
An annoyance with methods is that our class is `np.ndarray` with an awkward `__new__` [2]. So if it is `np.array.from_*` it would not be (only) a static- or classmethod, but also attached to that function.
Cheers,
Sebastian
[1] https://data-apis.org/array-api/latest/API_specification/generated/signature...
[2] I suppose there may be a point in moving `np.ndarray(...)` users to something more appropriate. And maybe even eventually making `np.array` the actual class. But, if possible, the last part would be a very long haul.
Stéfan
_______________________________________________ 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: asmeurer@gmail.com
participants (4)
-
Aaron Meurer -
Sebastian Berg -
Stefan van der Walt -
Stephan Hoyer