iterators (was: python-dev summary)

[Tim Peters]

[Donn Cave]
> The basic notions are simpler, but the notation that puts them
> together isn't obvious.  Until I have had a chance to look that
> up and use them for something enough to commit that syntax to
> memory, I won't understand the list comprehension code I see.

Here, guess what this does:

    print [x**2 for x in range(10)]

Bingo -- you're now educated <wink>.

> ...
> I have heard claims that they're faster, and that's a priority I
> can understand.

They *could* be quicker, but in the current implementation are usually
slower.  The primary intent is to be clearer than the alternatives.

> But every time some cool notion gets added to Python, it adds to
> the amount that we all eventually have to know.

As well as increase the set of available tools.  That was true in 0.9.6
too -- these are tradeoffs.

> I can't indefinitely postpone my education in list comprehensions
> without marginalizing myself, just as someone who comes along and
> learns them right away will still have to learn all the alternatives
> too.  Does that add to our ability to write software, or subtract
> from it?

I think it obvious that it does both.  Guido approves of ideas that, after
consideration, he believes will be a net win; he rejects ideas that he
believes will be a net loss (and no suggestion is without *some* value!).
You won't agree with him every time; and neither will I, although I pretend
that I do to keep universal harmony flowing on c.l.py <wink>.

that's-why-he-doesn't-want-anyone-reading-python-dev<wink>-ly y'rs  - tim