Home Original page

Comment on PEP-0322: Reverse Iteration Methods

Sean Ross sross at connectmail.carleton.ca
Fri Sep 26 16:29:41 EDT 2003 
"Chad Netzer" <cnetzer at sonic.net> wrote in message
news:mailman.1064604518.1923.python-list at python.org...
> On Fri, 2003-09-26 at 11:42, Sean Ross wrote:
>
> > > I was questioning the feasibility of the implied semantics.
> >
> > Fine. Take it up with the person who proposed the idea.
>
> You proposed it (hear me out).  You are missing David's point.  In
> addition to whatever semantics a general reverse iterator might have, he
> is saying that the itertools iterators have an implied additional
> semantic of not (necessarily) needing to fully expand an iterable in
> memory to operate on it, as a general ireverse() would probably have to
> do.  So, having ireverse potentially use up VAST quantities of memory,
> in order to work, doesn't quite fit into the itertools philosophy.
>
> That is the point he is making, and it is a specific comment on your (I
> believe; others have probably proposed it as well) suggestion of an
> ireverse() in itertools.
>
> Now, my response to David's point is that currently, cycle() may also
> require enough extra storage to remember an entire iterated sequence, so
> the itertools philosophy is not a hard rule.  Still, ireverse() would
> imply some real devilry under the covers...
>
> -- 
> Chad Netzer
>
>

Hi.

Thanks for clearing that up.

Yes, "others have ... proposed it as well". I was merely interested in the
appearance of the code, not the underlying implementation. I was not aware
that the name would imply more than the other suggestions simply because it
was housed in itertools. But then that's not really the point, I suppose:
The main point is the "implied additional semantic", regardless of the
function's location. Yes? OK. Fine. I was not concerned with semantics when
I made the suggestion, only sugar, so I couldn't see where David was coming
from. Sorry for the confusion.

Sean
More information about the Python-list mailing list