5 ms·

It is weird to add a feature to the language that would be ~immediately banned by every style guide worth its salt. Python is already expressive enough that un

It is weird to add a feature to the language that would be ~immediately banned by every style guide worth its salt. Python is already expressive enough that unlabeled break and continue are usually the wrong choice.

rich_sasha 4y ago
> unlabeled break and continue are usually the wrong choice. Citation needed. You can of course write code so they are not needed, but it won't necessarily be clearer, more efficient or "better" in any way. That sometimes they facilitate spaghetti code is no reason no ban them.
- joshuamorton 4y ago
  > Citation needed. You can of course write code so they are not needed, but it won't necessarily be clearer, more efficient or "better" in any way. If efficiency truly matters, you should not be using break or continue, you should be using a vectorized processing library like numpy or pandas. The pattern I describe in https://news.ycombinator.com/item?id=32710822 https://news.ycombinator.com/item?id=32710822 works for continue, and the same general concept works for break (and note that I've made this as unappealing as possible for my refactor, and it's still not really worse, but could easily be made even better): for i in x: if cond(i): break return do_a_thing(x) can become def find(x): for i in x: if cond(i): return i do_a_thing(find(x)) and these two patterns generalize to most more complex examples, and are fundamentally easier to follow, as the code is doing fewer things at any given time! Like break and return from a loop are equivalent modulo implicit state, and the same is true for continue and a conditional generator.
  - rich_sasha 4y ago
    They are not necessarily easier to follow, since you chop your logic into different functions. This may be better, but isn't necessarily. Esp if the loop has some (gasp) state which you then need to pass around to the outsourced functions. Not all loops ate numeric, in fact most aren't (since vectorisable stuff already is vectorised).
    - joshuamorton 4y ago
      > Esp if the loop has some (gasp) state which you then need to pass around to the outsourced functions. Being explicit about which state needs to be passed is almost universally better than having implicit state in a large complex function. If you're dealing with a complicated function tracking a large amount of state, separating the state needed to iterate over the loop, and the state needed to validate whatever condition you're checking is less complex than keeping it all in one larger function. The number of potential interactions grow exponentially in the number of local variables. Less state (fewer locals) means exponentially less complexity. When dealing with very small numbers of locals, the additional confusion from a second function might win out, but any situation where you're forced to pass state between the loop and the conditional is going to be over the threshold where multiple functions are easier for most people to follow. And that's just stateful interactions, the functions I've written have precisely one entrance and exit point, and precisely one path through them, while break and continue create opportunities for more complicated control flow. You're arguing that a function with more local state and more complex control structures should be simpler in some cases, but I don't see that happening as the state and control structures get even more complex. This is of course made obvious by the fact that the first code example I posted contains a bug, while the second avoids it.
      - rich_sasha 4y ago
        You're arguing a very patronizing point of view: you know what is better for my code. I find these things are not universal. Passing state around can be very confusing. Not on trend with everything being "pure" and functional but true pragmatically speaking. Certainly compared to walrus operator or f strings, labelled break/continue operations are very valid tools, which has different tradeoffs to alternative ways of emulating it, so sometimes will be better.
        joshuamorton 4y ago
        I am arguing the very obviously true point that some ways of writing a piece of code are easier to understand for most people. I'm not arguing anything about your code, I've only provided my own code examples. There's no reason for that to be patronizing. My point was and is that labelled break and continue are almost always a code smell, and would be banned by any good style guide, much like c++ has many misfeatures that are banned by most style guides. You may not be most people, break and continue may be clearer to you, but that's not a good reason to add a feature to a language. Not every language needs to be perfectly catered to your needs. Certainly not every language should (or needs) to cater to all of my needs, and again there's nothing patronizing about expressing that. Adding a misfeature doesn't make much sense, and you've done nothing to demonstrate that labelled break and continue are useful or make code clearer. Nor even that unlabelled break and continue are particularly valuable. Instead you've claimed I'm insulting you.
- ledauphin 4y ago
  "Citation needed" is an unproductive demand when we're discussing our opinions about programming language style and design. Or do you think your own assertions about labeled break should be met with the same demand?
  - rich_sasha 4y ago
    "I would find this useful" is self-supporting. "Break and continue are almost always the wrong choice" is not, and indeed dissing one the oldest and most retained features in programming language history requires substantial justification.

rich_sasha 4y ago

> unlabeled break and continue are usually the wrong choice. Citation needed. You can of course write code so they are not needed, but it won't necessarily be clearer, more efficient or "better" in any way. That sometimes they facilitate spaghetti code is no reason no ban them.

joshuamorton 4y ago
> Citation needed. You can of course write code so they are not needed, but it won't necessarily be clearer, more efficient or "better" in any way. If efficiency truly matters, you should not be using break or continue, you should be using a vectorized processing library like numpy or pandas. The pattern I describe in https://news.ycombinator.com/item?id=32710822 https://news.ycombinator.com/item?id=32710822 works for continue, and the same general concept works for break (and note that I've made this as unappealing as possible for my refactor, and it's still not really worse, but could easily be made even better): for i in x: if cond(i): break return do_a_thing(x) can become def find(x): for i in x: if cond(i): return i do_a_thing(find(x)) and these two patterns generalize to most more complex examples, and are fundamentally easier to follow, as the code is doing fewer things at any given time! Like break and return from a loop are equivalent modulo implicit state, and the same is true for continue and a conditional generator.
- rich_sasha 4y ago
  They are not necessarily easier to follow, since you chop your logic into different functions. This may be better, but isn't necessarily. Esp if the loop has some (gasp) state which you then need to pass around to the outsourced functions. Not all loops ate numeric, in fact most aren't (since vectorisable stuff already is vectorised).
  - joshuamorton 4y ago
    > Esp if the loop has some (gasp) state which you then need to pass around to the outsourced functions. Being explicit about which state needs to be passed is almost universally better than having implicit state in a large complex function. If you're dealing with a complicated function tracking a large amount of state, separating the state needed to iterate over the loop, and the state needed to validate whatever condition you're checking is less complex than keeping it all in one larger function. The number of potential interactions grow exponentially in the number of local variables. Less state (fewer locals) means exponentially less complexity. When dealing with very small numbers of locals, the additional confusion from a second function might win out, but any situation where you're forced to pass state between the loop and the conditional is going to be over the threshold where multiple functions are easier for most people to follow. And that's just stateful interactions, the functions I've written have precisely one entrance and exit point, and precisely one path through them, while break and continue create opportunities for more complicated control flow. You're arguing that a function with more local state and more complex control structures should be simpler in some cases, but I don't see that happening as the state and control structures get even more complex. This is of course made obvious by the fact that the first code example I posted contains a bug, while the second avoids it.
    - rich_sasha 4y ago
      You're arguing a very patronizing point of view: you know what is better for my code. I find these things are not universal. Passing state around can be very confusing. Not on trend with everything being "pure" and functional but true pragmatically speaking. Certainly compared to walrus operator or f strings, labelled break/continue operations are very valid tools, which has different tradeoffs to alternative ways of emulating it, so sometimes will be better.
      - joshuamorton 4y ago
        I am arguing the very obviously true point that some ways of writing a piece of code are easier to understand for most people. I'm not arguing anything about your code, I've only provided my own code examples. There's no reason for that to be patronizing. My point was and is that labelled break and continue are almost always a code smell, and would be banned by any good style guide, much like c++ has many misfeatures that are banned by most style guides. You may not be most people, break and continue may be clearer to you, but that's not a good reason to add a feature to a language. Not every language needs to be perfectly catered to your needs. Certainly not every language should (or needs) to cater to all of my needs, and again there's nothing patronizing about expressing that. Adding a misfeature doesn't make much sense, and you've done nothing to demonstrate that labelled break and continue are useful or make code clearer. Nor even that unlabelled break and continue are particularly valuable. Instead you've claimed I'm insulting you.
ledauphin 4y ago
"Citation needed" is an unproductive demand when we're discussing our opinions about programming language style and design. Or do you think your own assertions about labeled break should be met with the same demand?
- rich_sasha 4y ago
  "I would find this useful" is self-supporting. "Break and continue are almost always the wrong choice" is not, and indeed dissing one the oldest and most retained features in programming language history requires substantial justification.