Comment on PEP-0322: Reverse Iteration Methods
dave at boost-consulting.com
Sat Sep 27 18:14:29 CEST 2003
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()
(2003, 9, 27, 12, 10, 43, 5, 270, 1)
> 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.
More information about the Python-list