Re: for / while else doesn't make sense

[theherk]

This is exactly what I'm referencing. We can do mental gymnastics for it to 
make sense, but remove the `break` in your code and what happens? The logic 
goes away. The code ends up executing anyway, which is what makes it more like 
"finally" to me. Although, as Ian pointed out that would cause breakages for 
the "finally" meaning, because with the break you wouldn't expect it to 
execute, but we expect "finally" always to execute.

It is a great example for sure, but it only makes sense in specific constructs. 
I think this is a really interesting topic to which there may not be a better 
answer.

On Thursday, May 19, 2016 at 10:22:31 AM UTC-7, Ned Batchelder wrote:
> On Thursday, May 19, 2016 at 12:43:56 PM UTC-4, Herkermer Sherwood wrote:
> > Most keywords in Python make linguistic sense, but using "else" in for and
> > while structures is kludgy and misleading. I am under the assumption that
> > this was just utilizing an already existing keyword. Adding another like
> > "andthen" would not be good.
> > 
> > But there is already a reserved keyword that would work great here.
> > "finally". It is already a known keyword used in try blocks, but would work
> > perfectly here. Best of all, it would actually make sense.
> > 
> > Unfortunately, it wouldn't follow the semantics of try/except/else/finally.
> > 
> > Is it better to follow the semantics used elsewhere in the language, or
> > have the language itself make sense semantically?
> > 
> > I think perhaps "finally" should be added to for and while to do the same
> > thing as "else". What do you think?
> 
> For/else has always caused people consternation.
> 
> My best stab at explaining it is this: the else clause is executed if no
> break was encountered in the body of the for loop.  A simple structure
> would look like this:
> 
> for thing in container:
> if something_about(thing):
> # Found it!
> do_something(thing)
> break
> else:
> # Didn't find it..
> no_such_thing()
> 
> I think of the "else" as being paired with the "if" inside the loop.
> At run time, you execute a number of "if"s, one for each iteration
> around the loop.  The "else" is what gets executed if none of the
> "if"s was true.  In that sense, it's exactly the right keyword to
> use.
> 
> --Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[theherk]

You seem to have missed the point. Nobody is suggesting, I don't believe, that 
all of a language should be intuitive. Rather that if any part of it is 
unnecessarily counter-intuitive, it may be worth looking for a better solution. 
Python is a very well designed language when it comes to in linguistic 
presentation. In this case however, it is not only unintuitive but 
counter-intuitive.

The original question was simply, "Is it better to follow the semantics used 
elsewhere in the language, or have the language itself make sense 
semantically?" So, it is better to leave counter-intuitive constructs so they 
are consistent across the language or try to make each keyword make semantic 
sense where it is used?

On Friday, May 20, 2016 at 3:43:58 PM UTC-7, Steven D'Aprano wrote:
> On Sat, 21 May 2016 05:20 am, Christopher Reimer wrote:
> 
> > According to "Effective Python: 59 Specific Ways to Write Better Python"
> > by Brett Slatkin, Item 12 recommends against using the else block after
> > for and while loops (see page 25): "Avoid using else blocks after loops
> > because their behavior isn't intuitive and can be confusing."
> 
> By that logic, we ought to:
> 
> - avoid using floats because their behaviour isn't intuitive and
>   can be confusing;
> - avoid using lists because their behaviour isn't intuitive and
>   can be confusing;
> - avoid using classes because their behaviour isn't intuitive and
>   can be confusing;
> - avoid any form of asynchronous functions because their behaviour
>   isn't intuitive and can be confusing;
> 
> and so on. I can give examples of unintuitive and confusing behaviour for
> all of those things, and more, except the last. And the reason I can't give
> examples for async programming is because it confuses me and I don't
> understand it well enough to give even a minimal example.
> 
> Just about the only things in Python which are intuitive and not confusing
> to somebody are None and ints.
> 
> Or, we can *learn how to use the features* and stop thinking that
> programming is a matter of intuition. And most importantly, stop thinking
> that features need to be judged entirely by the least knowledgeable
> programmers.
> 
> 
> > Until I read the book, I wasn't aware of this feature (or bug). Doesn't
> > seem like a feature I would use since it's not commonly found in other
> > programming languages. As the author demonstrates in his book, I would
> > probably write a helper function instead.
> 
> Sorry, was that called "Ineffective Python"?
> 
> There is absolutely nothing effective about re-inventing the wheel badly or
> writing unnecessary code.
> 
> Are you programming in those other languages or in Python? If you're
> programming in, say, Javascript, I can completely understand you deciding
> to limit yourself to features available in Javascript. Indeed to try to use
> Python language features in Javascript would be an exercise in frustration.
> Likewise using Ruby language features in Python is nothing but SyntaxError
> after SyntaxError, it makes it hard to get work done.
> 
> But the idea that you should avoid a Python feature while programming in
> Python because Javascript doesn't have it, or Ruby, or C, is surely the
> height of muddleheaded thinking. You're not programming Javascript, Ruby or
> C, you're programming in Python. The whole point of picking one language
> over another is to get access to the tools and features that language
> offers. Otherwise you're just wasting your time.
> 
> 
> 
> -- 
> Steven
-- 
https://mail.python.org/mailman/listinfo/python-list