PEP8 improvements

[MarkusHackspacher]

#111
Have some suggestions todo pep8

[espg]

Thank you @MarkusHackspacher for the pull request, we appreciate it =) I added a few more changes to this as a PR on your fork and branch.

There are a few additions I left as comments in the review instead of as commits, so that we'd don't have any merge conflicts when this gets approved and merged.

[espg]

how about:

print(' %s.%s %-5s %-5s %2i' % (station['NetworkCode'],
                                station['StationCode'],
                                p['soln'], p['object'],
                                p['terms']))

so we stay under the 79 character length?

[MarkusHackspacher]

Is 80 length today useful? Modern editor could more.
In PR #109 in .github/workflows/python-package-conda.yml line 29+30 is set to --max-line-length=127

 # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics

[espg]

Yes, most projects still use a 79 character limit-- the character length convention is partly so that multiple editor windows can be opened side by side for comparing files.

Right now, #109 is just running flake8 as warnings, but there will be another github runner automation run for new Pull Requests that won't pass with pep8 errors, and will likely use the 79 character limit.

[MarkusHackspacher]

Thank you, have a question about the Output Formatting, what code style you preferred?

• Old-style String Formatting (% operator): This method is less preferred in newer Python code but still works.
• String Formatting (.format() method)
• Formatted String Literals (f-strings) (Python 3.6+)

[espg]

My strong preference and vote is for us to use Formatted String Literals (f-strings) moving forward.

We are currently pinned to using sklearn 1.1 or newer (which requires Python 3.8+)... and even if we were to remove that dependency, we are still required to use numpy version 1.19.5 or newer (which requires Python 3.6+). So we should always be on Python 3.6+ and have f-strings available as part of the standard library.

[MarkusHackspacher]

That sounds this line would change in the future.
If it possible say ok to this review and accept the PR? The other lines you requested, I make no change in that line, only a line upper.

[espg]

break this line into two? Python let's you do in parenthesis implicitly like this:

 print(' >> Found a set of matching parameters for station '
       + station_soln)

[espg]

Break this line into 2? Python let's you do implicit line continuation over brackets like this:

            tpar.frequencies = [float(1/float(p)) for p in
                                args.function_type[1:]]

[espg]

@demiangomez do we need these imports on lines 14-17?

AlterETM.py:14:1: F401 'pgamit.pyETM.DEFAULT_FREQUENCIES' imported but unused
AlterETM.py:14:1: F401 'pgamit.pyETM.DEFAULT_POL_TERMS' imported but unused
AlterETM.py:14:1: F401 'pgamit.pyETM.DEFAULT_RELAXATION' imported but unused

[espg]

@MarkusHackspacher sure, this looks good to merge. We'll revisit the string parsing and formatting in different PRs