On Wed, 17 Jul 2002, Guido van Rossum wrote: [...]
OK, that's clear.
[...]
Yes.
[...]
Correct.
Neat! So much understanding.
Now, weren't you a co-author of the Iterator PEP? I wish you'd brought this up then. Or maybe you did, and I overruled you. Sorry then.
Indeed, i wrote the first draft of the PEP, though it was very different from what we have today; it's been largely rewritten. The big design changes happened at the iterator BOF, so unfortunately there's no e-mail record of the debate.
I recall that __iter__ made me uncomfortable, but i don't recall to what extent i expressed this. I don't remember whether there was any overruling. But it doesn't really matter; it's today now, and here we are. It is true that i failed to understand or express the issue well enough to have an effect on the design. I will cheerfully accept blame if it somehow means we'll end up with a nicer language. :)
But I don't think we can withdraw this so easily. It's not the end of the world.
I would be pleased to see a migration path (perhaps along the lines of Dave's suggestion, with warnings for a while), but i won't throw myself off a bridge if it doesn't happen.
I do think there is some potential for errors caused by misunderstandings about whether or not "for x in y" is destructive. That's the thing that worries me the most. I think this is the main reason why the old practice of abusing __getitem__ was bad, and thus helped to motivate iterators in the first place. It seems serious enough that migrating to something that distinguishes destructive-for from non-destructive-for could indeed be worth the cost.
The destructive-for issue may seem superficially unrelated to the __next__-naming issue. As i see it, the __next__-naming issue is related to the mandatory-__iter__ issue (because some people view __iter__ as a type flag), which is related to the destructive-for issue.
-- ?!ng