Comment on PEP-0322: Reverse Iteration Methods

[Raymond Hettinger]

[Andrew Dalke]
> > >       verfiles = os.listdir('/usr/lib/setup')
> > >       verfiles = [name for name in verfiles
> > >                                if name.startswith("slack-version-")]
> >
> > I like your version better and recommend you submit it as a patch.
> > I'll take out the ifilter() comment.
>
> But that goes against the pretty good motto of "if it ain't broke,
> don't touch it."

Between major releases, refactoring is fair game.  Using newer
constructs like list comprehensions can make this code more
readable and maintainable.


> Granted, XP-style tests are supposed to
> help out with that, but I don't have a /usr/lib/setup where I
> can test this.

Submit a patch, assign to me, and I'll test it.


> > > > random.shuffle() uses for i in xrange(len(x)-1, 0, -1)
> > > This isn't a use case.  The xrange never returns a 0 while
> > > the iter_backwards one will.
> >
> > It is an important use case.  The replacement code is:
> >
> >   for i in xrange(1,len(x)). iter_backwards()
>
> Ahh, right.  Didn't think about that.  You should include that
> wording in the PEP.

Okay, done!


> > Whenever the indices have any complexity, the forwards version,
> > followed by .iter_backwards() is, IMHO, much easier to mentally verify.
>
> I agree.  When I do need to go backwards I often forgot to get
> both -1s in place.  Ie, I'll do (n, 0) instead of (n-1, -1).
> Well, don't forgot much and more, but there's some tension in
> my mind as I worry if I got it correct or not.

That is a key motivation for the pep!


> > Also, I have a preference for creating something that
> > is as robust as possible.  Making a builtin function that
> > doesn't apply to all objects; behaves badly with mappings;
> > and crashes with an infinite iterator is not my idea of robust.
>
> The backup which uses __getitem__ and negative offsets
> does work for all objects, behaves exactly as badly as the
> existing iter, and doesn't crash with an infinite iterator, no?

1.  Sure, all objects that define __getitem__ in a non-mapping
     sense or that don't ignore the index (that was at one time a
     common python practice).

2.  With infinite iterators, running them to completion causes
     the crash.  They can be used in other generators, iterators,
     or loops that have a break.  This is not true with reverse
     iterators where the very first call will cause the crash:

           itertools.count().next()   # this always works
           riter(itertools.count()).next() # this always fails


> That suggests a UserList.ListMixin might be useful, but it
> isn't obvious to me that it would be.

You're the fourth person to suggest it.
If you want to know the issues involved, see my post at:


http://groups.google.com/groups?selm=Bebab.9323%24hl4.4031@nwrdny01.gnilink.net


> Should dicts support riteritems, ritervalues?

Heck no!  I only want reverse iteration for lists, strings, and xrange
where forward and reverse orders make some sense.


>  I also think that with these changes,
> the PEP is pretty complete and solid.

Thanks for the detailed help getting it to that point.


Raymond