3 ms·

Walrus operator? In. F string interpolation? In. Pattern matching? Hacked in. Genuinely useful feature that is awkward to emulate? Nah. Let's face it, everyon

Walrus operator? In. F string interpolation? In. Pattern matching? Hacked in. Genuinely useful feature that is awkward to emulate? Nah. Let's face it, everyone writes a double or triple nested for loop every now and then.

BiteCode_dev 4y ago
Python has had itertools.product for ages for this use case.
- masklinn 4y ago
  product only covers independent nested iterations, some of them have dependencies. But for those you've got iterools.concat, or generator comprehensions.
joshuamorton 4y ago
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.
  - 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.
stinos 4y ago
every now and then Exactly; at least for me the other features you mention I use daily (or when considering coding hours only, multiple times per hour), whereas I cannot even exactly remember when the last time was I had to break out of a nested loop. I'm not saying it's not useful, just that I don't think that code frequency is a useful argument to make here, especially not in comparison with the features you mention.
- rich_sasha 4y ago
  See I'm the other way round. I don't use walrus op, I dislike f strings because the "operator" f is to the left, whereas I'm used to "filling" a strong from the right. Pattern matching scares me, since unless you're working with data classes, the contents of a class can be only loosely related to its constructor. Loops i write daily. This feels like a bunch of people projecting their subjective biases on what code should look like on everyone else. Python 2/3 all over again (in a small teacup).
deleted 4y ago
[deleted]

BiteCode_dev 4y ago

Python has had itertools.product for ages for this use case.

masklinn 4y ago
product only covers independent nested iterations, some of them have dependencies. But for those you've got iterools.concat, or generator comprehensions.

joshuamorton 4y ago

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

stinos 4y ago

every now and then Exactly; at least for me the other features you mention I use daily (or when considering coding hours only, multiple times per hour), whereas I cannot even exactly remember when the last time was I had to break out of a nested loop. I'm not saying it's not useful, just that I don't think that code frequency is a useful argument to make here, especially not in comparison with the features you mention.

rich_sasha 4y ago
See I'm the other way round. I don't use walrus op, I dislike f strings because the "operator" f is to the left, whereas I'm used to "filling" a strong from the right. Pattern matching scares me, since unless you're working with data classes, the contents of a class can be only loosely related to its constructor. Loops i write daily. This feels like a bunch of people projecting their subjective biases on what code should look like on everyone else. Python 2/3 all over again (in a small teacup).

deleted 4y ago

[deleted]