i.atcorr: major refactoring of create_iwave.py #3886
Conversation
* speed up (e.g., do not run loops if one run is sufficient) * lower the amount of code duplicity * remove lines that actually do not do anything (e.g., lines containing declaration print without brackets) * general beauty salon treatment
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| bands[-1] = bands[-1].strip() | ||
| print(" > Number of bands found: %d" % len(bands)) | ||
| infile.close() | ||
| print(f" > Number of bands found: {len(bands)}") |
There was a problem hiding this comment.
A linter should complain that bands could be undefined here.
| for i in range(len(filter_f) + 1): | ||
| if i % 8 is 0: | ||
| if i is not 0: | ||
| if i % 8 == 0: |
There was a problem hiding this comment.
Just a infinitesimal implementation-dependent optimisation possible here: I stumbled upon something on stack overflow this weekend, not exactly related to this, but the example had this form.
This pattern uses at least 2 more opcodes than another possibility, as it has to protect himself from the variable not being an integer when comparing to 0. There's an alternative, but it was open three days ago on my computer, and I'm writing on my phone. It had something to do with either using "in" or nothing at all.
I'm just nerdsniping here, if you are curious to microoptimise here.
| pstring += value_wo_leading_zero | ||
| if i > 1 and i < len(filter_f): | ||
| pstring += ", " | ||
| if i is not 1: |
There was a problem hiding this comment.
The replacement of this doesn't seem exactly the equivalent. Is the new logic expected behavior? (Old one got triggered for -1, 0, 2, 3, 4..., new gets triggered for 2, 3, 4...)
printwithout brackets)