Yaroslav Nikitenko <mets...@gmail.com> added the comment:

I hope it's fine to add to closed topics here.

I agree with the decision that islice should not handle a special case of sized 
containers vs iterables.

However, I think that the support of negative indices in islice would be nice. 
A simple use case would be to get the last element of an iterable.
I had to write my own code for that (you may read and/or use it if needed), 
because I needed this algorithm in my analysis. Here is the link to my function 
ISlice._run_negative_islice in my architectural framework for data analysis: 
https://github.com/ynikitenko/lena/blob/master/lena/flow/iterators.py#L150 or 
on https://lena.readthedocs.io/en/latest/flow.html#lena.flow.iterators.ISlice 
(I'm afraid the correct link might change later).

I also agree that to support negative indices would require more work. Indeed, 
it seems that for each combination of positive/negative start/stop it required 
a new algorithm! I didn't implement negative steps.

However, I think that because it's not easy to implement, it would be even 
better to include that in the standard library (because it would save other 
people from writing that).

If we care about code reuse: I think that negative indices make the algorithm 
more useful, while non-trivial steps are redundant, because they can be 
implemented by a composition of a slice with step=1 with a simple slice with 
start, stop=None, None with step!=1.

Negative slice fundamentally changes the algorithm: if one wants to have the 
flow inverted, fflow[0, None, -1], one would have to store it all in memory! 
Anyway it's easy to make this in a separate function. So I think it's more 
functional to implement negative indices and discard negative steps (or 
non-trivial steps at all).

About drop_first, drop_last suggested above: I also think that they are 
redundant and would be better incorporated into islice.

----------
nosy: +ynikitenko

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33040>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to