ENH: Create obvious way of getting a single 1-D list with all array elements #24989
Comments
|
I browsed gh-16243 and I don't find the reasoning for not returning a list compelling:
It seems pretty obvious to me that a method named >>> np.array([42]).tolist()
[42]
>>> np.array(42).tolist()
42
>>> np.int64(42).tolist()
42There are also several TODO's in This wasn't really on my radar, but I think it'd be a reasonable change to make for 2.0 (always returning a list that is, not I wasn't involved in the previous decision though, and I may be missing something. So pinging @eric-wieser and @seberg for input here. Also, we are pretty short on time for all the plans/wishes for 2.0. If the outcome is that we want to do this, would you be willing to implement it @vadimkantorov? |
|
Yes, it is mild misnomer, but no, I am absolutely not in favor of changing this.
And what about N-D arrays? I suspect this request comes from users mixing 1-D or 0-D arrays for whatever reason, if they were having 2-D arrays in there we would have another round of discussion and frustration. I would say a You can use |
Why? That returns a list just fine, nothing changes: >>> x = np.ones((3, 2))
>>> l = x.tolist()
>>> type(l)
<class 'list'>
>>> l
[[1.0, 1.0], [1.0, 1.0], [1.0, 1.0]] |
|
The point is that we return a nested list of depth |
|
I'm not at python right now, but I think our |
|
Okay, I interpreted the request as |
|
The simple reason is, that returning a list breaks consistency quite badly, and that is bound to bite someone else. Most likely worse than then the mild convenience added for the original person here. There is a simple solution IMO, and I have already said that, add one or both of:
(It is the job of the user to know the want to ravel higher dimensional arrays then, but OK.) |
tolist() return type, potentially for NumPy 2.0 or Array API|
Also it seems like this was trigger of the current iteration: pytorch/pytorch#104908 (comment) where you are dealing with N dimensions anyway and already must flatten. All additionally added checks are unnecessary (unless torch gets |
Proposed new feature or change:
@rgommers This has been discussed several times:
I propose to review it once again to potentially introduce a breaking change or some solution for this in NumPy 2.0 or Array API. It's most of time inconvenient to have the return type change as a function of numel() - usually we do some array processing after and having conditions complicates the consuming code.
Maybe a new argument
force=Trueargument can be introduced with existing behaviorforce=Falseas default, andatleast1d().tolist()behavior ifforce=Trueis passed. OR maybe a new methodaslist()can be introduced andtolist()be deprecated/produce-warnings and removed in a few years.The text was updated successfully, but these errors were encountered: