6 ms·

The various examples are synthetic. The use of a helper-function is given in the lwn article as a reason for not supporting multi-level break: ] The solution

The various examples are synthetic. The use of a helper-function is given in the lwn article as a reason for not supporting multi-level break: ] The solution to "Python needs a way to jump out of a chunk of code" is usually to put the chunk of code into a function, then return out of it. More specifically: ] To make this proposal convincing, we need a realistic example of an algorithm that uses it, and that example needs to be significantly more readable and maintainable than the refactorings into functions, or the use of try…except (also a localised goto). ] If you intend to continue to push this idea, I strongly suggest you look at prior art: find languages which have added this capability, and see why they added it. The multi-level break in that Rust example may be "more readable and maintainable than the refactorings into functions", but it is not "significantly more readable."

IshKebab 4y ago
Frankly that's just broken logic. You could easily say: > The solution to "Python needs a way to increment variables" is usually to so `a = a + 1`. > To make this proposal convincing, we need a realistic example of an algorithm that uses it, and that example needs to be significantly more readable and maintainable than `a = a + 1`. Why does `+=` get into the language but labelled breaks (a reasonably standard feature) don't. This isn't hypothetical - not all languages have +=. Matlab for example requires you to do `a = a + 1`.
- eesmith 4y ago
  https://peps.python.org/pep-0203/ https://peps.python.org/pep-0203/ says: > The idea behind augmented assignment in Python is that it isn’t just an easier way to write the common practice of storing the result of a binary operation in its left-hand operand, but also a way for the left-hand operand in question to know that it should operate on itself, rather than creating a modified copy of itself. Here's an example of how "a += b" is not syntactic sugar for "a = a + b". First, "a = a + b", which rebinds 'a' to a new object while leaving 'b' bound to the original: >>> a = b = [9,8] >>> a + b [9, 8, 9, 8] >>> a = a + b >>> a [9, 8, 9, 8] >>> b [9, 8] Second, "a += b", which keeps both a and b bound to the same object: >>> a = b = [9,8] >>> a += b >>> a [9, 8, 9, 8] >>> b [9, 8, 9, 8]
  - IshKebab 4y ago
    Nah that's not a good enough example to motivate adding += to Python. You can just do `a.extend(b)`!
    - eesmith 4y ago
      It wasn't meant to be a convincing argument. It was meant to show your comment at https://news.ycombinator.com/item?id=32741165 https://news.ycombinator.com/item?id=32741165 wasn't a relevant parallel, because it ignored how "a+=1" and "a=a+1" are different. For a more convincing use, consider NumPy arrays, where a+=1 re-use the same (potentially very large) array, while a=a+1 creates a new array. import numpy a = b = numpy.array([[1,2], [3, 9]]) a += 1 # modify in-place a = a + 1 # create a new array >>> a array([[ 3, 4], [ 5, 11]]) >>> b array([[ 2, 3], [ 4, 10]]) In-place modification can improve performance over using intermediate/temporary arrays.

IshKebab 4y ago

Frankly that's just broken logic. You could easily say: > The solution to "Python needs a way to increment variables" is usually to so `a = a + 1`. > To make this proposal convincing, we need a realistic example of an algorithm that uses it, and that example needs to be significantly more readable and maintainable than `a = a + 1`. Why does `+=` get into the language but labelled breaks (a reasonably standard feature) don't. This isn't hypothetical - not all languages have +=. Matlab for example requires you to do `a = a + 1`.

eesmith 4y ago
https://peps.python.org/pep-0203/ https://peps.python.org/pep-0203/ says: > The idea behind augmented assignment in Python is that it isn’t just an easier way to write the common practice of storing the result of a binary operation in its left-hand operand, but also a way for the left-hand operand in question to know that it should operate on itself, rather than creating a modified copy of itself. Here's an example of how "a += b" is not syntactic sugar for "a = a + b". First, "a = a + b", which rebinds 'a' to a new object while leaving 'b' bound to the original: >>> a = b = [9,8] >>> a + b [9, 8, 9, 8] >>> a = a + b >>> a [9, 8, 9, 8] >>> b [9, 8] Second, "a += b", which keeps both a and b bound to the same object: >>> a = b = [9,8] >>> a += b >>> a [9, 8, 9, 8] >>> b [9, 8, 9, 8]
- IshKebab 4y ago
  Nah that's not a good enough example to motivate adding += to Python. You can just do `a.extend(b)`!
  - eesmith 4y ago
    It wasn't meant to be a convincing argument. It was meant to show your comment at https://news.ycombinator.com/item?id=32741165 https://news.ycombinator.com/item?id=32741165 wasn't a relevant parallel, because it ignored how "a+=1" and "a=a+1" are different. For a more convincing use, consider NumPy arrays, where a+=1 re-use the same (potentially very large) array, while a=a+1 creates a new array. import numpy a = b = numpy.array([[1,2], [3, 9]]) a += 1 # modify in-place a = a + 1 # create a new array >>> a array([[ 3, 4], [ 5, 11]]) >>> b array([[ 2, 3], [ 4, 10]]) In-place modification can improve performance over using intermediate/temporary arrays.