Indeed, making a slice a view does pose painful challenges. For a slice 
iterator, I wonder if there is an bigger overhead in being an iterator or 
building an iterator. I wholeheartedly agree that 'adding add-hoc 
functionality' is slightly toy-ish, but I brought up the idea of 'start' and 
'stop' parameters because I believed that mentioning just these two things 
themselves are humbly adequately below that 'troublesome' or 'complex' line. 
Yes, Numpy's slice is a view and that is memory efficient. Memory_view, 
lazy_slice, View_object, and other terms, quite an expansive room of 
considerations.

For discussions-sake, I would like to comment about:     'Frankly, I didn't see 
a lot of use-cases at the time -- but now it seems that we have some more, and 
some more interest.'.      Indeed, if one puts on a perspective glasses of 
'use-cases', it's obvious that there is no urgency, no real-time necessity for 
that. We can see that there is growing interest, but just my opinion, the more 
deserving point is that it exhibits intelligence and power. Intelligence 
because a users gets to choose what to do with that sublist 'before' it takes 
memory - it's intelligent not to use resources unless explicitly told to, like 
a generator. Power because if I can 'specify' that section of a list without 
making a copy, I'm effectively achieving the same thing as many would using 
for-loop + range() + indices. It has that tiny little conceptual resemblance to 
how reversed() being much better than for-loop + range() + negative_indices, 
when iterating backwards.

I'm schooled by how there was a history archive on this. Thanks for the links.

Thanks for the input.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AJNG4C6QJ372HO3UKVT63HJXAPFKWX6P/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to