[IshKebab]

> What do you think is a convincing real-world example that should motivate its inclusion in Python?

That Rust example is a decent one. Also the various "find something in a nested structure" examples people have posted.

(And the fact that you can achieve the same result in a more awkward way by putting it in a function and using `return` is irrelevant because there are many many language features that are just convenient sugar: +=, lambdas, even while loops!)

[eesmith]

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]

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]

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]

Nah that's not a good enough example to motivate adding += to Python. You can just do `a.extend(b)`!

[eesmith]

It wasn't meant to be a convincing argument.

It was meant to show your comment at 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.