Increase the usage of augmented assignment statements

👀 Some source code analysis tools can help to find opportunities for improving software components. 💭 I propose to increase the usage of augmented assignment statements accordingly.

Would you like to integrate anything from a transformation result which can be generated by a command like the following? (👉 Please check also for questionable change suggestions because of an evolving search pattern.)

lokal$ perl -p -i.orig -0777 -e 's/^(?<indentation>\s+)(?<target>\S+)\s*=\s*\k<target>[ \t]*(?<operator>[+\-%&|^@]|\*\*?|\/\/?|<<|>>)/$+{indentation}$+{target} $+{operator}=/gm' $(find ~/Projekte/librosa/lokal -name '*.py')

[bmcfee]

Interested developers can try the shown search and replace approach out, can’t they?

Yes, but you could also have skipped this entire conversation by describing the proposed changes it would identify.

Asking devs to copypaste a baroque perl one-liner, clever as it might be, is pretty unreasonable. In general, I would never ask anyone to run code in a shell that isn’t 100% clear and obvious, if only for security reasons. Anyone asking strangers to paste commands into a shell should be greeted with healthy suspicion, as I’m doing here.

Would you find the following data format representation more appealing?

Yes! This way we can at least discuss the merits of individual changes. (Though, really, permalinking to the altered lines would be even better, but I’ll take it.)

Now, going point by point:

• beat.py:normalize: definitely not, it would alter the input onset strength signal.

• beat.py:dp

  • candidates: this one would be fine, since it’s a locally constructed variable
  • window: this would be okay as well

• audio.py:

  • n: sure, but it wouldn’t really make any difference (n is a scalar not an array)
  • n_samples: same
  • fwd_pred_error: nope, in this case we’d clobber the temporary storage and the result would be incorrect
  • bwd_pred_error: might be okay, but it’s not obvious to me
  • threshold: should be fine, scalar
  • mu-law quantize: nope, side effects

• constantq:

  • fmin: okay

• pitch.py:

  • period_candidates: maybe okay. there might be some subtleties to array broadcasting here

• spectrum.py:

  • dphase: probably okay, local variable

• display.py:

  • fmin: should be fine (scalar) but no obvious benefit

• filters.py:

  • constantq: probably okay, it’s a local variable being constructed here

• onset.py:

  • onset_envelope: nope, side effects

• utils.py:

  • detections: okay, local variable

• almost everything in tests: nope, modifying fixtures in-place would invalidate different runs of the tests

So of all that diff, there are maybe 6 lines that could be changed as you suggest. The rest would render the code incorrect (eg by modifying input arrays, or unsafely modifying other objects that are multiply referenced locally) or provide no clear benefit (ie relate to scalars instead of arrays).

[bmcfee]

I would expect that the logical semantics must be identical in the sense that something gets assigned to a selected variable.

Except that it isn’t the same. Consider the following two functions:

def f(x):
    # x is assumed to be a numpy.ndarray
    x = x + 1
    return x

def g(x):
    x += 1
    return x

And now call them as follows:

In [4]: x = np.arange(3)

In [5]: x
Out[5]: array([0, 1, 2])

In [6]: f(x)
Out[6]: array([1, 2, 3])

In [7]: x
Out[7]: array([0, 1, 2])

In [8]: g(x)
Out[8]: array([1, 2, 3])

In [9]: x
Out[9]: array([1, 2, 3])

The first function leaves the input unchanged, the second does not. (This is because ndarrays implement the += operator distinctly from the + operator.) In functional programming speak, we would say that the second has side-effects and the first is a pure function. We generally try to avoid side effects.

The software run time characteristics can be different.

Sure, but correctness is always more important than speed.

Do you find the explanation by the Python enhancement proposal 203 (from 2000-07-13) insufficient? thinking

Yes, actually. The question is not about the syntactic difference, but rather what is to be gained in our specific context.