for / while else doesn't make sense

[theherk at gmail.com]

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