Re: [PATCH 1/4] bitbake: main: fix bad-witespace pylint warnings

[Richard Purdie <richard.purdie@linuxfoundation.org>]

This patchset triggered a lively discussion between a few of us about
whether we should or shouldn't make whitespace changes to the codebase.

There is one viewpoint which is that we should state we're aiming for
PEP8 and modify the codebase to match.

Unfortunately there are pieces of API and conventions we have which do
make sense for us and don't match PEP8. For example the use of "d" as
our datastore variable (its a short variable name) or the camelcase in
the datastore methods (getVarFlag) which happens to have worked really
well for the variable dependency analysis.

Personally, I also really don't like unnecessary changes in the history
so that git blame and code annotation get distorted to the whitespace
change commits. I probably spend more time doing that than most.

My general thought is that we should aim for something PEP8 like,
particularly around argument and keyword spacing. I'd prefer to do this
as we add new code or modify existing code and I have been doing that
in my own changes for a while to try and improve consistency.

That said, I personally don't get worked up about line length limits
and even the short variable names aren't that bad, *if* they're limited
in scope to a handful of lines or follow a codebase wide convention (fn
is filename, lf is lockfile, e is exception are the main bitbake ones
that come to mind).

So my feeling is we continue to try and improve the style but not go as
far as large whitespace changes just for the sake of it.

There are some sections which might be worth considering such as Ed's
changes here to the continuation and line too long pieces of main.py
specifically as it is currently a mess. I think the short variable
change may actually confuse some conventions more than fixing them
though.

Certainly I don't want to see a ton of "PEP8" style cosmetic patches
hitting the list.

Cheers,

Richard