Comment on PEP-0322: Reverse Iteration Methods

[David Abrahams]

I wasn't even going to post this to the list, because it's so full of
static and other unpythonic stuff.  But then, Stephen hides his email
address, and there is one real Python-related issue at the bottom,
so...

Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> writes:

> It was my intention to explain the origins of my misunderstanding,
> though certainly in a slightly less than serious way and with a big
> dollop of its-not-all-my-fault-you-know. 

I didn't need to have an assignment of blame in order to find closure
with this thread.  I was just trying to be helpful.

> I tend to screw this kind of thing up, and it seems I have done so
> again here.

Then I can't understand why you continue to charge about in the china
shop....

> I never said, anywhere, that you said that "std::pair supports..." if
> we are being that pedantic, but in the life of this thread neither of
> us really has been that pedantic. 

Seems like you've started.

> I quoted your exact words for the crucial point, which were...
>
> "you can in fact iterate on std::pair<T,T> with the usual C++ iterator
> protocol"
>
> Pedantically speaking, this is imprecise language. 

No, there is a common subset of all iterator requirements and that's
what I was referring to.

> Most significantly, there is no such thing as "the usual C++
> iterator protocol". An iterator may implement any one of five
> different iterator protocols, and these protocols have surprisingly
> little in common.  All require an operator++ and all require a
> dereference-style operator* and that is it.

And that is the usual iterator protocol.  I happen to know exactly
what those protocols have in common.

> Actually, even the operator* isn't as common as it seems - input
> iterators only support read access, output ones only write access

Actually it's subtler than that.  You can have input/output iterators
which support random access which aren't random access iterators
because they don't support lvalue access.  So what, though?

>  - so the practical commonality is limited to the operator++.

You need operator* regardless.

> But then you weren't writing a standards document, and I wasn't
> reading it as a standards document.

That's why I didn't understand why you were giving me such a hard
time.  Because it's informal speech I'm supposed to do quadruple duty
to make sure you haven't misinterpreted me?  I really was going out
of my way to explain this stuff to you politely.

> To most C++ programmers most of the time, the words "the usual C++
> iterator protocol" don't have the pedantic meaning set by the C++
> standard - they are not just about having an operator++

And operator*.

> They have a somewhat more pragmatic meaning, which includes the
> usual means of obtaining iterators from containers. std::pair *is* a
> container in the general sense of containing other objects, even
> though in the C++ standards document context it is not formally
> considered a container.

Then so is 

     struct { int x, y; };

Also, so is char[4], and unsigned long is a container of at least 32
bits.

This is getting ridiculous.  It seems like you want to have a pedantic
debate about terms whose meaning is going to be defined by your
completely informal and subjective interpretation.

> Of course there is room for misinterpretation in virtually any piece
> of writing - criticism of your choice of words was certainly
> intentional, but meant to be lighthearted.
>
> But if you really believe that I "read what [I] want to see into what
> [you] posted" then I'm afraid you're wrong. I saw an implication which
> you never intended, but that was right at the start when I had no
> reason to "want to see" anything in particular.
>
> I do have a certain history in this kind of
> minor-misunderstanding-gets-overblown storyline, as Alex Martelli I
> think can confirm if he's still following the thread. Actually,
> he'll probably say you should consider yourself lucky that it only
> got this bad ;-)
>
> Anyway, I'm in no doubt that I'm primarily (probably entirely)
> responsible for the 'overblown' part especially with my previous post.
> I appologise for that.

Thanks, I think.  This is somewhat of a backhanded apology, but I'll
take it.  [If you had just stopped with the last message, I wouldn't
even feel it mattered].

>>This whole discussion started out talking about what the Python
>>protocol for manipulating iterators should be.  The fact that
>>iterators must themselves have an __iter__ method in Python may just
>>be making this more confusing than it needs to be.
>
> We may think of '__iter__' as part of the iterator protocol but,
> pedantically speaking, it is no more part of the Python iterator
> protocol than 'begin' is part of the C++ iterator protocol.
>
> Iterators don't have to have an '__iter__' method in Python. Iterators
> only have to have a 'next' method. It is the iterable object that
> implements '__iter__'. And, as with getting C++ iterators from 'begin'
> etc, even that is a convention rather than a requirement.

Sorry,

http://www.python.org/doc/current/lib/typeiter.html#l2h-149

Read it twice, carefully.

> Sometimes iterators do have an '__iter__' method, but that normally
> just returns self

Always.

> - it's a quick-fix convenience for when iterators
> end up in a context where an iterable object is expected.
>
> I guess our mindsets aren't so different that we can't make similar
> mistakes ;-)

I'm afraid not.  I never, ever make mistakes in the first place ;->

infallib-ly y'rs
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com