First of all I'd suggest to move our codebase to strict PEP8 (or
as-strict-as-possible), so we can have see how our code looks like, when
For starters, we could just plain use autopep8 -
How about that?
For the record, Josef put up the diff here:
As the most vocal naysayer during the IRC meeting, I have went through all of those
changes (and I have read PEP8 again), and I have to say the changes are not that bad. I
have feared that the code would look similarly to what Josef quoted in the email, but PEP8
is actually saner than I expected and allows much better stylistic formatting.
Which in fact touches one of the concerns I have, that it's hard to realize how to
write the code pretty and still comply to PEP8, but it's easy to realize how to write
the code ugly and comply. At least that's my experience.
I still have a few pet peeves about PEP8, for example check.py:189-192 or
config_defaults.py:63. I think human being can use whitespace to make code much more
readable (the code is in a monospace font for a reason), and PEP8's "I know
better" approach of enforced conformity quite bothers me. But I understand that can
be highly subjective, and for some people consistency is above readability, for me it is
the other way around.
That said, if everyone else happily supports this idea, I don't object against a trial
run in which we drop all custom configuration from .arclint and enable pep8 checking. We
will see how it works out. I don't think it will boost our productivity, I think it
will just move the "wasted" time from reviews (let's admit it, almost none
in the past months) to the patch preparation process and multiply it, but maybe I'm
PS: Speaking of line length, PEP8 actually allows going up to 100 chars , and most of
our existing codebase meets that, so I don't see that as much of a problem. The
comments and docstrings still need to be wrapped at 72 chars, though, so I'm curious
to see if we start to enforce that.