Comment on PEP-0322: Reverse Iteration Methods

[David Abrahams]

Alex Martelli <aleax at aleax.it> writes:

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

No, that's an entirely different question.  I can build an iterator
which iterates over pair<T,T>.

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

No, nothing like that.

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

Ah, no.  A tuple in C++ is a different thing, and much more like a
Python tuple: http://www.boost.org/libs/tuple

> That's basically what the "heterogeneous tuple" is supposed to be
> equivalent to, in the "party line" I was relating

Well, that's just nutty.  We can make a much better analogy to a
struct in Python with the usual class hacks.  But even then, we can
arrange to iterate the attributes.

>  (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, 

Whaa??  Are they subclassing tuple?  Nope, time.struct_time is not
even a tuple.  It's just the struct hack with a tuple-like repr()

>>> time.localtime()
(2003, 9, 27, 12, 10, 43, 5, 270, 1)
>>> type(time.localtime())
<type 'time.struct_time'>
>>> time.struct_time.__bases__
(<type 'object'>,)

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

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

Immutability is extremely useful whenever you have inplace operations
like +=, because it guarantees value stability for other references
to the same object.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com