slice[] to get more complex slices
For basic slices, the normal "slice(start, stop, step)" syntax works well. But it becomes much more verbose to create more complicated slices that you want to re-use for multiple multidimensional data structures, like numpy, pandas, xarray, etc. One idea I had was to allow creating slices by using indexing on the slice class. So for example: x = slice[5:1:-1, 10:20:2, 5:end] Would be equivalent to: x = (slice(5, 1, -1), slice(10, 20, 2), slice(5, None)) Note that this wouldn't be done on a slice instance, it would be done on the slice class. The basic idea is that it would simply return whatever is given to __getitem__.
Todd schrieb am 22.07.2018 um 21:03:
Personally, I always likes that idea, but it would be worth looking up the previous discussions in the list archive to find out if they lead to any conclusion. AFAICT, "slice.literal" was the latest such proposal that was discussed. Stefan
+1 on this. Seems easy a limited in scope, and it reduce the need to remember the details of slice constructor, just reuse the same syntax for getitem slices. Seems that the initial proposal was skipped just for timing reasons, and have a large support among numpy users. More mixed outside numpy, but still I think it was put under the rug a little too quickly...
Hi Grégory You wrote:
Seems that the initial proposal was skipped just for timing reasons
The discussion is in https://bugs.python.org/issue24379. It was first skipped for that reason. Second time around our Then and now Former BDFL wrote === https://bugs.python.org/msg280721 Actually I'm with Raymond -- I'm also not sure or mildly against (-0). Given how easy it is to do without and how cumbersome using the operator module is I don't see a great benefit. (IMO the operator module should be the measure of *last* resort -- it is not to become part of anybody's toolkit for common operators. But I seem to be a minority opinion here.) === and also === https://bugs.python.org/msg319695 Let's close it. Just because someone spent a lot of effort on a patch we don't have to accept it. === That said, I see merits in providing standard tools for creating slices. These tools, as discussed, to take advantage of the power of the [...] syntax. I'd start here: https://bugs.python.org/msg244801 -- Jonathan
Oh yes , I see. Seems like almost everybody think using the [...] syntax to define reusable slices is a good idea, the discussion is where this could be implemented, knowing that numpy.s_ already exists. Discussion is not easy to follow, with the patch almost accepted then delayed then rejected, in a very short amount of time. In particular, it's not clear why direct indexing of slice type (not instance) was not chosen. It was the first proposal, and here again Todd's choice. it was silently skipped/changed to slice.literal then moved to operators, at least that's the impression I got reading https://bugs.python.org/issue24379 ... Not sure slice[1::3] can be done, but this has my preference too: it's the most direct exposure I can think of...
Hi Grégory You wrote:
Oh yes , I see. Seems like almost everybody think using the [...] syntax to define reusable slices is a good idea,
Not sure slice[1::3] can be done, but this has my preference too: it's the most direct exposure I can think of...
The slice class already has all the core functionality it needs. This thread is looking for something extra. My preference is to create a new module, slicetools, that contains the functionality the people on this thread want to have. What I like about this approach is that the code can be written and deployed without getting permission from anyone. And when it's done and has a body of practice, the PEP would simply be "Add slicetools to the standard library". Anyone here up for working on that sort of approach? -- Jonathan
On Mon, Jul 23, 2018 at 6:28 AM, Jonathan Fine <jfine2358@gmail.com> wrote:
I only proposed on very limited thing here. My thought was that if it wasn't accepted in the slice class the next best place would be a dedicated class in boltons or toolz or some package like that. Besides the __getitem__ --> slice classmethod, what other functionality do you think is needed in such a module?
Todd schrieb am 22.07.2018 um 21:03:
Personally, I always likes that idea, but it would be worth looking up the previous discussions in the list archive to find out if they lead to any conclusion. AFAICT, "slice.literal" was the latest such proposal that was discussed. Stefan
+1 on this. Seems easy a limited in scope, and it reduce the need to remember the details of slice constructor, just reuse the same syntax for getitem slices. Seems that the initial proposal was skipped just for timing reasons, and have a large support among numpy users. More mixed outside numpy, but still I think it was put under the rug a little too quickly...
Hi Grégory You wrote:
Seems that the initial proposal was skipped just for timing reasons
The discussion is in https://bugs.python.org/issue24379. It was first skipped for that reason. Second time around our Then and now Former BDFL wrote === https://bugs.python.org/msg280721 Actually I'm with Raymond -- I'm also not sure or mildly against (-0). Given how easy it is to do without and how cumbersome using the operator module is I don't see a great benefit. (IMO the operator module should be the measure of *last* resort -- it is not to become part of anybody's toolkit for common operators. But I seem to be a minority opinion here.) === and also === https://bugs.python.org/msg319695 Let's close it. Just because someone spent a lot of effort on a patch we don't have to accept it. === That said, I see merits in providing standard tools for creating slices. These tools, as discussed, to take advantage of the power of the [...] syntax. I'd start here: https://bugs.python.org/msg244801 -- Jonathan
Oh yes , I see. Seems like almost everybody think using the [...] syntax to define reusable slices is a good idea, the discussion is where this could be implemented, knowing that numpy.s_ already exists. Discussion is not easy to follow, with the patch almost accepted then delayed then rejected, in a very short amount of time. In particular, it's not clear why direct indexing of slice type (not instance) was not chosen. It was the first proposal, and here again Todd's choice. it was silently skipped/changed to slice.literal then moved to operators, at least that's the impression I got reading https://bugs.python.org/issue24379 ... Not sure slice[1::3] can be done, but this has my preference too: it's the most direct exposure I can think of...
Hi Grégory You wrote:
Oh yes , I see. Seems like almost everybody think using the [...] syntax to define reusable slices is a good idea,
Not sure slice[1::3] can be done, but this has my preference too: it's the most direct exposure I can think of...
The slice class already has all the core functionality it needs. This thread is looking for something extra. My preference is to create a new module, slicetools, that contains the functionality the people on this thread want to have. What I like about this approach is that the code can be written and deployed without getting permission from anyone. And when it's done and has a body of practice, the PEP would simply be "Add slicetools to the standard library". Anyone here up for working on that sort of approach? -- Jonathan
On Mon, Jul 23, 2018 at 6:28 AM, Jonathan Fine <jfine2358@gmail.com> wrote:
I only proposed on very limited thing here. My thought was that if it wasn't accepted in the slice class the next best place would be a dedicated class in boltons or toolz or some package like that. Besides the __getitem__ --> slice classmethod, what other functionality do you think is needed in such a module?
participants (5)
-
Grégory Lielens -
Jonathan Fine -
Serhiy Storchaka -
Stefan Behnel -
Todd