Comment on PEP-0322: Reverse Iteration Methods

[Alex Martelli]

David Abrahams wrote:
   ...
> Well, (understanding that you don't nececessarily agree with the
> above) you can in fact iterate on std::pair<T,T> with the usual C++
> iterator protocol, 

You mean there's an std::pair::begin etc?!  OK, I guess I'm even
rustier on standard C++ than I thought I was -- I could have SWORN
there wasn't.  (Std chapter & verse pls?  I plan to win bets based
on this tidbit...!-).  So I guess the lack of those in gcc is a
breach of the Standard on gcc's part...?

> and with a new mixed compile-time/runtime tuple
> iterator protocol developed by Doug Gregor, iteration over
> heterogeneous tuples is possible too.  It certainly is desirable to be
> able to do that; it's a real need that has come up in practice.

So, given an arbitrary struct, with fields (generally) of different types,
you can iterate field by field?  That's basically what the "heterogeneous
tuple" is supposed to be equivalent to, in the "party line" I was relating
(although the names to go with the fields are only present in a FEW such
tuples, such as those returned by modules time and stat, as of now; more
general tuples still haven't grown the ability to access fields by name,
in Python).

My partial dissent comes from feeling the need for "frozen/immutable
lists" and the fact that tuples are often used as such (including goofy
immutable representations of dicts, e.g. via tuple(thedict.iteritems()),
and the like).  If tuples cannot be thought of as immutable lists, then
(I think) we need "immutable/hashable/frozen" lists by other means.
(I need to say "I think" because, as I quoted, Ruby experts claim that
the "anyobject.freeze" feature they do have isn't actually as useful
as it SEEMS it should be -- though I'm not sure I understand why, yet).


Alex