replacing `else` with `then` in `for` and `try`

Jon Ribbens jon+usenet at unequivocal.eu
Sun Nov 5 09:39:15 EST 2017


On 2017-11-05, Steve D'Aprano <steve+python at pearwood.info> wrote:
> On Sat, 4 Nov 2017 04:44 am, Jon Ribbens wrote:
>> 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.

You're entitled to your opinion, of course. I've provided you with a
way of thinking about 'for...else' that makes its purpose and meaning
intuitively obvious. You'd apparently prefer to think about it a
different way that makes it counter-intuitive, and would like to
change the language to match your thinking instead. I'd regretfully
suggest that that is not going to happen.

> 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':

Of course, that's searching for the condition "flip_coin() == 'Heads'".

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

You're conflating two completely different points:

  * whether to allow 'for...else' with no 'break'
  * how to think about 'for...else' with a 'break'

My comment about syntax errors only has any relevance at all to the
former point.

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

Just press up arrow to go back and edit the first line of your
current input and insert an 'if 1:' as someone else suggested.

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

The question isn't whether it's useful, but whether it's *more* useful
than preventing bugs in peoples' code. You're entitled to your opinion
on that, and I'm entitled to mine, and neither opinion is 'arrogant'.

We're all just making guesses in the dark, unless anybody has any
statistics about how much time is wasted each year by bugs caused by
'for...else' with no 'break' and how much time would be wasted each
year by people being unable to use your REPL trick.



More information about the Python-list mailing list