docs on for-loop with no __iter__?

[Alex Martelli]

Steven Bethard <steven.bethard at gmail.com> wrote:

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

Ah, sorry, you're right -- I'm not used to think of 2.2 applications as
"old code" yet, but of course there might theoretically be unmaintained
apps around written for 2.2.  Bug fixes can indeed "break old code"
which somehow managed to rely on the bug (the "is not monotonic" part in
your quote above being a bug with 2.2's MRO) -- Python is not quite as
fossilized yet as to guarantee bug-to-bug compatibility between
versions.

I just don't see fixing bugs as comparable in any way with other
maintenance activity, based on dropping or modifying existing features
that were never bugs, just because there are now better ways to perform
certain tasks that the existing features existed for.


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

You asked that question in the post I was answering, yes.  Then, when I
responded, you claimed that "Python always breaks old code", which
seemed and still seems like a weird claim to me.

> If no code would have been broken, I don't see why it would be unreasonable to
> use a more intuitive protocol.  

It may seem more intuitive to programmers trained in languages where
exceptions are to be used as little as feasible, but to a
dyed-in-the-wool Pythonista it doesn't.  Your proposed protocol would be
more complicated than the historical one, since it would have to cover
both classes that expose __len__ and ones that don't, in different ways,
while the historical one is simpler because it does not need to draw
that distinction, and "simpler is better than complicated" is a very
important design principle in Python.

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

My text you're quoting doesn't say you want to break old code: rather,
it's based on your saying that _Python_ (thus, presumably, the python
developers/committers, which is who I mean by "we" in my text you quote
above) "always breaks old code", and I believe THAT text of yours, at
least when read at face value, is the part which is "just being
inflammatory".  If you have used other programming platforms in the
past, I think it's reasonable to expect you to perceive that Python, far
from _always_ "breaking old code", goes to pretty great lengths to avoid
doing so, albeit only within the realm of the "reasonable" (an
application which relied on a bug happening to cause a certain specific
behavior was, in a sense, broken at birth...).

At this point, I suspect you didn't mean that "always" in the way I read
it, but I don't think my reading of it was unreasonable.  Starting from
the default assumption that miscommunications are most often due to both
speaker and listener, I'm quite willing to take my half share of
responsibility for this one if you're willing to take yours, and we can
call it quits.

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

No, I think this is the right forum, and I apologize if I seemed to
indicate otherwise.  History is of interest to few people, but, being
one of those few, I should be encouraging such interests, surely not
discouraging them.


Alex