On Sat, 4 Nov 2017 04:44 am, Jon Ribbens wrote: > On 2017-11-03, Steve D'Aprano <steve+pyt...@pearwood.info> wrote: >> The for loop does not necessarily perform a search: >> >> count = 1 >> for obj in sequence: >> if count > MAX_OBJECTS: >> print("too many objects, halting") >> break >> process(obj) >> else: >> print("finished") >> >> According to your mental model, this code is... what? Illegal? Silly? >> Impossible? A syntax error? > > That conforms to my model. It's searching for the condition > 'count > MAX_OBJECTS'.
That's sounds to me that you are willing to call just about any test of a condition inside a loop a "search". I don't think that's helpful. I think it is mangling the word to the point it is meaningless. How about a loop that exits at some random time? Is that a search? for i in range(100, 0, -1): if flip_coin() == 'Heads': print("surprise!") break print("still running") else: print("countdown completed") [...] >> Your response to code that doesn't match your mental model is to say >> that it is obviously wrong and probably buggy and should be made >> into a syntax error if possible. > > No, it isn't. Try reading again what I actually wrote. What you actually wrote, in various posts: You have a 'for...else' with no 'break'. Like I said, that should probably be a syntax error. if what the 'for' clause is doing doesn't match the concept of 'searching for a match' then it's obvious that you shouldn't be using 'for...else' in the first place. the language doesn't currently strictly enforce the requirement for a 'break', but nevertheless if you don't have one you almost certainly have a bug. I stand by my comment as an accurate description of your response. >> Ah yes, because it is inconceivable that anyone might have thought of a use >> for for...else without a break. > > It's not inconceivable, but nobody has thought of a sensible use so far > (by which I mean one that shows it's a useful feature). I find the code useful. I shouldn't have to justify why it is useful to me, but for the record it especially comes in handy when I've already typed out a multi-line loop in the REPL, and only then realised that I'll need some way to add an extra line at the end. Since I spend a lot of time in the REPL doing exploratory coding, this happens more often than I'd like. Of course I could cancel the edit, then add in some sort of scaffolding code to allow me to print an extra line at the end, then hit the up arrow repeatedly to re-enter the lines I've already typed, editing them to fit the scaffolding, then add the final print. But that's tedious and painful and a waste of time and effort when it is trivially easy to just add "else: print()". That is *simple* and it *works* and it solves the problem. And yes, a better REPL would also solve that problem. But I have to use the REPL that exists, not the imaginary one that I'd like. If you want to call this a hackish work around for a limitation of the REPL, I'll say... okay. What's your point? It is still useful. Try thinking outside the box. There's nothing wrong with finding unusual and hackish uses for flow control statements. [...] >>> It's an incredibly obscure work-around for a different problem, >> >> You mean a different problem to "searching"? Yes indeed it is. > > No, I mean a problem that has nothing to do with 'for...else' clauses. I would say that it has nothing to do with the original motivation for introducing for...else clauses into the language. Since it uses for...else, it is pretty obtuse to deny that it has anything to do with for...else. The for...else control statement is a tool. We can use tools for any purpose we want, not just the ones that they were originally designed for. You are declaring that a perfectly useful, albeit hackish, trick for the REPL is illegitimate because it doesn't match your mental model. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list