Comment on PEP-0322: Reverse Iteration Methods

[Andrew Dalke]

Raymond Hettinger:
> Beauty and clarity are a matter of taste and we differ here.
> To some (including me), s[::-1]  looks more like line noise
> than s.iter_backwards().

Understood.  In all this, let me make it clearthat I
have a preference for a function over a method, but won't
call it a wart of the BFDL thinks otherwise.  I point these
out because I'm rather detail oriented.

> > Also, a variant implementation may be even more concise,
>
> You must be pretty confident to take on the Timbot's code  ;-)

Well, I did say "may".  I wouldn't really want to use it since
inverting the score before the sort is a tricky thing to see and
somewhat unexpected.

(I'm half expecting some enlightening comment about how
negation has subtle interactions with IEEE 754 math -- though
I thought the point of 754 was to make naive approaches like
mine usually correct.  :)

> >       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."  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.

> > ] 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.

> 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.

> BTW, don't underestimate the intensity of resistance to adding
> new builtins.

For me it's two things: remembering what all these new things
do, and attempting to adhere to the 'don't use variables with
the same name as builtins' guiding philosophy.  I don't adhere
to the latter wrt the type named 'file'.

> 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?

It's slow, but if you want the performance, make an __riter__.

> I really don't understand the overpowering urge to make this a function
> and add a new magic method protocol.  Why isn't there a similar rage
> against dict.iteritems()?

Overpowering?

My preference is for a function because of:
  - similaraties to iter, which is also a function
  - there are many types of iteration orderings, and not all can be
      special cased methods.
  -  I don't see backwards iteration as all that important

As for iteritems, I was annoyed about it because it meant my
dictionary-like code would become more complicated to
implement, until I came across UserDict.DictMixin, which
lets user-defined code implement just a few methods then
builds the rest from there.

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

I also note that items is a method so by similarity it makes
sense that iteritems also be a method.  Additionally, many
things offer forward iteration, while only dicts offer items.

Should dicts support riteritems, ritervalues?

> Okay, we simply disagree here.  That's fine.

Yup.  I don't think I have anything useful or even interesting
to offer to this dicusssion.  I also think that with these changes,
the PEP is pretty complete and solid.

                    Andrew
                    dalke at dalkescientific.com