We recently introduced flake8 to check for bogus semicolon at the end of
line in python code. It can check for sooo much more than this. In
general it is desirable to comply with as much as possible, since this
results in python code that is more consistent in style to that seen in
other projects. Thus the goal was to enable everything. At the end there
are only two flake8 warnings that are surpressed. The line length one
leads to horrible code which I felt cannot be justified. The knuth line
break / operators one which I felt was of dubious value and though I
wouldn't object if someone wanted todo the work to address it.

Daniel P. Berrangé (10):
  docs: remove some dead code in apibuild.py
  build: change flake8 to use blacklist instead of whitelist
  python: fix use of undeclared variables in python scripts
  python: mark regex strings with 'r' prefix
  python: avoid variable named 'l'
  python: avoid bare 'except:' clause
  python: sanitize blank line usage
  python: sanitize spaces either side of operators
  python: sanitize indentation after line continuations
  build: comment on why we're not adopting certain flake8 rules

 build-aux/syntax-check.mk          |  15 +-
 docs/apibuild.py                   | 446 ++++++++++++++---------------
 docs/reformat-news.py              |   1 +
 src/esx/esx_vi_generator.py        | 237 ++++++---------
 src/hyperv/hyperv_wmi_generator.py |  29 +-
 tests/cputestdata/cpu-cpuid.py     |   5 +-
 6 files changed, 326 insertions(+), 407 deletions(-)

-- 
2.21.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 10/9/19 7:58 AM, Daniel P. Berrangé wrote:
> We recently introduced flake8 to check for bogus semicolon at the end of
> line in python code. It can check for sooo much more than this. In
> general it is desirable to comply with as much as possible, since this
> results in python code that is more consistent in style to that seen in
> other projects. Thus the goal was to enable everything. At the end there
> are only two flake8 warnings that are surpressed. The line length one
> leads to horrible code which I felt cannot be justified. The knuth line
> break / operators one which I felt was of dubious value and though I
> wouldn't object if someone wanted todo the work to address it.
> 
> Daniel P. Berrangé (10):
>    docs: remove some dead code in apibuild.py
>    build: change flake8 to use blacklist instead of whitelist
>    python: fix use of undeclared variables in python scripts
>    python: mark regex strings with 'r' prefix
>    python: avoid variable named 'l'
>    python: avoid bare 'except:' clause
>    python: sanitize blank line usage
>    python: sanitize spaces either side of operators
>    python: sanitize indentation after line continuations
>    build: comment on why we're not adopting certain flake8 rules

ACK series

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list