2

I'm working on something in python and I have several variables that are calculated by very long formulas. I've done some searching on this site, and I found that python allows for implicit line breaking, which would be a solution for me as I can stretch the formula over multiple lines: line-breaking

Now currently I have been working in a different way. Let me give you an example, if A would be given by the following formula:

A = b + c + d + e

I would be coding it as:

A = b + c
A += d + e

I was wondering what would be the preferred method. Is there a computational advantage to use implicit line-breaking over my current method?

John Kugelman
  • 349,597
  • 67
  • 533
  • 578
Frederico
  • 23
  • 5

1 Answers1

5

We'd need more context to be sure, but here are some example cases.

For strings, as an implementation detail of CPython, the explicit split would be better (sometimes much better), because there is an optimization for an add (a = a + b) or inplace add (a += b) where the add/iadd instruction itself is immediately followed by a store to the left-hand side of the add. That said, for strings, you'll get more reliable performance regardless of operand size or the specific Python interpreter by doing A = ''.join((b, c, d, e)) rather than repeated concatenation.

For ints, floats and complex types, the single line approach is going to be ever so slightly more performant, solely because it avoids an unnecessary store and load instruction, but the difference is trivial; they're all immutable, scalar values, so no in-place manipulation of values occurs regardless, you'll have the same number of temporaries created during processing, the only question is whether they get (briefly) bound to a local name or not.

Frankly, if it's not a matter of concatenating strings or sequences (the former should be done with ''.join, the latter with itertools.chain to get O(n) performance), the preferred approach is not line continuation characters (which can easily get messed up by invisible trailing white space) but simple parentheses for grouping. If the real names of A = b + c + d + e were too long to fit on a line, my preferred approach would be:

A = (b + c +
     d + e)

PEP8 prefers to break lines before the next operator, not after, so strictly PEP8 code would be:

A = (b + c
     + d + e)

This is the approach supported by PEP8 (the Python style guide), which says:

The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation.

The only real case for using backslashes instead is when parentheses aren't a legal part of the grammar (the link includes an example for with statements).

ShadowRanger
  • 143,180
  • 12
  • 188
  • 271
  • The actual formula consists of adding (and multiplying) complex numbers. A more realistic example of my formulas would be something like: A = b * (c+d+e) + f * (g*h+i) Where in some cases (c+d+e) would already be split over more than 1 line. – Frederico Jan 09 '18 at 14:50
  • @Frederico: Yeah, for built-in numeric types, separating the steps will technically make it slower, but only trivially. If you can make the code more readable by breaking it up more, do it; outside of the hottest of hot code paths (which are cases where maybe avoiding Python would be worth it), the reduced maintenance effort is more than worth the "cost" of a few nanoseconds incurred by the additional store/load instructions. – ShadowRanger Jan 09 '18 at 14:57
  • If the formula is really that long, already for the sake of readability I'd probably break up the calculation and name the partial terms in a meaningful way, like `bla = c + d + e`. Then just use `bla` in the next step, and so on. This also allows for better debugging of the partial results. – Jeronimo Jan 09 '18 at 15:10