<p dir="ltr">Sure, a better last() should try to index into it[-1] first as an efficiency. And there are lots of iterators where the last element is predictable without looking through all the prior items. I know the last item of itertools.repeat(7, sys.maxsize) without having to loop for hours.</p>
<p dir="ltr">But the general case is that you need to get all the head elements to determine last().</p>
<p dir="ltr">If the main idea is "to access the previous iteration" then we already have it retools.accumulate() for exactly that purpose. If you want something that bandages a little different from accumulate, writing generator functions us really easy.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 23, 2016 8:59 AM, "Danilo J. S. Bellini" <<a href="mailto:danilo.bellini@gmail.com">danilo.bellini@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Of course. But if you want last(), why not just spell the utility function as I did? [...]<br></p></blockquote><div>I'm not against a general "last", I just said the main idea of this
thread is the access to the previous iteration output in a list/set/dict
comprehension or generator expression.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr"></p></blockquote><div>Actually, your code is similar
to the reference implementation I wrote for PyScanPrev, the main difference is
that my "last" raises a StopIteration on an empty input instead of an
UnboundLocalError:<br><a href="https://github.com/danilobellini/pyscanprev/blob/v0.1.0/pyscanprev.py#L148" target="_blank">https://github.com/danilobelli<wbr>ni/pyscanprev/blob/v0.1.0/pysc<wbr>anprev.py#L148</a><br>When the input is a sequence, it should be optimized to get the item at the index -1.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">That works fine for any iteratable (including a list, array, etc), whether or not it's a reduction/accumulation.</p></blockquote></div>Lists and arrays don't need to be traversed.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Consuming the iterator is *necessary* to get the last item. There's no way around that.</p></blockquote>Not if there's enough information to create the last value. Perhaps on the it = iter(range(9999999)) one can get 2 values (call next(it) twice) and use its __length_hint__ to create the last value. But I think only sequences should have such an optimization, not iterators.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="m_-7018459156242304117m_-3039325551743301001gmail-m_-1340667806962428581gmail-m_-1770368357973666107gmail_signature">Danilo J. S. Bellini<br>---------------<br>"<i>It is not our business to set up prohibitions, but to arrive at conventions.</i>" (R. Carnap)<br></div>
</div></div>
</blockquote></div></div>