[Biopython-dev] Further PEP8 Cleanup

[Christian Brueffer]

On 12/5/12 22:16 , Peter Cock wrote:
> On Mon, Dec 3, 2012 at 5:02 PM, Christian Brueffer
> <christian at brueffer.de> wrote:
>>> As you point out, the "repo churn" from fixing minor things
>>> like spaces around operators does have a cost in making
>>> merges a little harder. Things like the exception style updates
>>> which you've already fixed (seems I missed some) are more
>>> urgent for Python 3 support, so worth doing anyway.
>>>
>>
>> On the other hand, it's basically a one-time cost.  However I
>> want to fix the lowest-hanging fruit (read: the ones with the
>> lowest counts ;-) first.
> 
> The shear number of files touched in these PEP8 fixes would
> probably deserve to be called "repository churn" now - wow!
> 

I wonder whether there's a file left I haven't touched yet (except
the data files in Tests)...

> Although we have good test coverage, it isn't complete (anyone
> fancy trying some test coverage measuring tools like figleaf?)
> so there is a small but real risk we've accidentally broken
> something. I'm wondering if therefore a 'beta' release would
> be prudent, of if I am just worrying about things too much?
> 

It certainly can't hurt to advise users to have an extra eye on
possible regressions and strange behaviours in existing code.
I think the only risky changes were the ones concerning indentation,
(f68d334b1edfd743fe8a7bb4654046295f0ff939), I was extra careful about
those.

So, I'm pretty confident I haven't screwed things up but it's good
to be careful.

FYI, here's the "pep8 --statistics -qq" output as of commit
df4f12965a2ad3b6ed31bbf9d201bd5c716bd4ee:

680     E121 continuation line indentation is not a multiple of four
691     E122 continuation line missing indentation or outdented
171     E123 closing bracket does not match indentation of opening
bracket's line
86      E124 closing bracket does not match visual indentation
197     E126 continuation line over-indented for hanging indent
601     E127 continuation line over-indented for visual indent
1072    E128 continuation line under-indented for visual indent
772     E201 whitespace after '('
536     E202 whitespace before ')'
23444   E203 whitespace before ':'
94      E221 multiple spaces before operator
11      E222 multiple spaces after operator
5763    E225 missing whitespace around operator
6519    E231 missing whitespace after ','
2542    E251 no spaces around keyword / parameter equals
622     E261 at least two spaces before inline comment
347     E262 inline comment should start with '# '
1044    E302 expected 2 blank lines, found 1
1       E303 too many blank lines (2)
15526   E501 line too long (82 > 79 characters)
3       E711 comparison to None should be 'if cond is None:'
75      W291 trailing whitespace
12      W293 blank line contains whitespace
5       W601 .has_key() is deprecated, use 'in'

E203 looks scary, but 9900 of those are in Bio/SubsMat/MatrixInfo.py
alone.

>>> You've got us a lot closer to PEP8 compliance - do you think
>>> subject to a short white list of known cases (like module
>>> names) where we don't follow PEP8 we could aim to run a
>>> a pep8 tool automatically (e.g. as a unit test, or even a commit
>>> hook)? That is quite appealing as a way to spot any new code
>>> which breaks the style guidelines...
>>
>> Having a commit hook would be ideal (maybe with a possibility to
>> override).  This would be especially useful against the introduction of
>> gratuitous whitespace.  With some editors/IDEs you don't even notice it.
> 
> Would you be interested in looking into how to set that up?
> Presumably a client-side git hook would be best, but we'd
> need to explore cross platform issues (e.g. developing and
> testing on Windows) and making sure it allowed an override
> on demand (where the developer wants/needs to ignore a
> style warning).
> 

Yes, It's fairly high on my TODO list.

Chris