docs on for-loop with no __iter__?

[Steven Bethard]

Alex Martelli <aleaxit <at> yahoo.com> writes:
> MRO didn't change for classic classes, thus unmaintaned apps can't be
> affected by that.

I may be mistaken, but I thought MRO did change for new classes...  I read in 
http://www.python.org/2.3/mro.html:

"In his post, Samuele showed that the Python 2.2 method resolution order is 
not monotonic and he proposed to replace it with the C3 method resolution 
order. Guido agreed with his arguments and therefore now Python 2.3 uses C3."

And the docs seemed to indicate that new-style classes were available in 
Python 2.2.  Did the new-style classes and the C3 MRO actually both come in 
2.2? 

Anyway, if you read the docs the way I did above, you could imagine that any 
new-style class that was written in Python 2.2 could potentially have been 
broken by the new MRO in Python 2.3.  So the change in MRO would have been a 
change that could break old code.

> > If you read my posts from the beginning, I was clearly never asking for the
> > workaround -- I was asking for why the protocol was the way it was and why 
> > it hadn't been updated after __iter__ was introduced.  Despite a few snide
> > remarks ;) you did answer my question though, thanks!
> 
> You're welcome, and I do think that the second part of the question was
> pretty weird -- with all the trouble we go to, to keep backwards
> compatibility with most old unmaintained apps, just imagining we'd go
> around breaking them to no good purpose seems weird to me.

Clearly we're talking past each other.  When I asked the question, I didn't 
know what code would be broken.  That's why I asked the question.  (Go back 
and read some of the thread where I ask questions like "Would it break old 
code if the __getitem__ iterator checked for a __len__ method...?" if you 
don't believe me.)

If no code would have been broken, I don't see why it would be unreasonable to 
use a more intuitive protocol.  I understand the history here is probably old 
hat to you, but it's not to me, and that's why I was asking.  Suggesting that 
I want to "go around breaking [apps] to no good purpose" is just being 
inflammatory.

> I can't really see why these historical quibbles would be of much interest, 
> anyway.

Well, it's an interesting design decision that resulted from an interesting 
set of facilities that were in the language at the time.  Of course, if you 
were already using Python at the time these decisions were made, you already 
knew all about it.  I'm a relative newcomer to Python though, and its history 
and evolution is still interesting to me.

If there's a better forum to ask questions about Python's history, I'd be glad 
if you'd redirect me to it.

Steve