style: clean up whitespace in python scripts

[rufuszero]

Remove all trailing whitespace, primarily between code sections.
Tidy up indentation of multi-line comments, unifying indentation style to tabs.

The trailing whitespace and final newlines change is done via native VSCode functionality when the following config file is used:
.vscode/config.json

{
    "files.trimFinalNewlines": true,
    "files.trimTrailingWhitespace": true
}

Multiline comments were brought to the common indentation style manually.

Code style suggestions

In case you are using VSCode and want to use it as a primary editor for the repo, I can commit the configuration above in a separate PR. This will automatically trim redundant whitespace on file save.

Alternatively, an .editorconfig file may be used to guide contributors towards common indentation style. I can prepare one if needed.
Editorconfig is supported natively or via extensions by many common developer-oriented editors, but is also just a good single source of truth for code style. It is then up to developer which tools he prefers to use to conform to the style.

Yet another alternative is to leave the indentation alone and just manually tweak it as needed.
Good option in case you don't want to pollute the repo with extra configuration/tools files that are not directly relevant to the oref itself. It's just two python files after all.

[F0lak]

Thanks for the PR!

So to make sure that I understand this correctly, this PR just removes the whitespace, and you're proposing standardizing the repo itself to use vscode as the standard editor and are willing to PR the necessary config files and submit a style guide for new contributors to follow?

[rufuszero]

@F0lak, almost correct.

This PR itself indeed only has whitespace changes, just tidying up the scripts.

As for the standardization, I'm proposing three options:

• Standardize the whole repo to VSCode, in which case I'm willing to PR the VSCode-specific config file.
• Standardize the codestyle for the repo with an .editorconfig file which I also can PR.
  • This leaves editor preference up to the contributor as their editor of choice will either pick up config from that file automatically (see https://editorconfig.org/#pre-installed for the list of editors that automatically recognize .editorconfig file out of the box) or contributor can look at the file and adjust their own environment to conform to the specified style.
• Don't standardize anything, just leave things simple.

The first two options would prevent the need for future PRs like this by ensuring automatic style conformity. The last option is simpler but might require periodic manual cleanups.