<div dir="ltr">I think a good solution would to use add a git_hooks directory with a pre-commit git hook along with an git hook installation script. And a note should be added to DEV_README.txt suggesting installing the git hooks for pep8 compatibility. I personally use this as a pre-commit <div>
<br></div><div><div><div><div>#!/bin/sh</div><div><br></div><div>FILES=$(git diff --cached --name-status | grep -v ^D | awk '$1 $2 { print $2}' | grep -e .py$)</div><div>if [ -n "$FILES" ]; then</div><div>
pep8 -r $FILES</div><div>fi</div></div></div></div><div><br></div><div>which is from here: <a href="https://gist.github.com/lentil/810399#comment-303703">https://gist.github.com/lentil/810399#comment-303703</a></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 10:54 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Sep 9, 2013 at 3:29 PM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Sep 9, 2013 at 8:12 AM, Richard Hattersley <<a href="mailto:rhattersley@gmail.com">rhattersley@gmail.com</a>><br>
> wrote:<br>
>><br>
>> > Something we have done in matplotlib is that we have made PEP8 a part of<br>
>> > the tests.<br>
>><br>
>> In Iris and Cartopy we've also done this and it works well. While we<br>
>> transition we have an exclusion list (which is gradually getting shorter).<br>
>> We've had mixed experiences with automatic reformatting, so prefer to keep<br>
>> the human in the loop.<br>
>><br>
><br>
> I agree with keeping a human in the loop, the script would be intended to<br>
> get things into the right neighborhood, the submitter would have to review<br>
> the changes after. If the script isn't too strict there will be than one way<br>
> to do some things and those bits would rely on the good taste of the coder.<br>
<br>
</div></div>So if I understand right, the goal is to have some script that<br>
developers can run before (or after) submitting a PR, like<br>
  tools/autopep8-my-changes numpy/<br>
that will fix up their changes, but leave the rest of numpy alone?<br>
<br>
And the proposed mechanism is to come up with a combination of changes<br>
to the numpy source and an autopep8 configuration such that<br>
  autopep8 --our-config numpy/<br>
becomes a no-op, and then we can use this as an implementation of<br>
tools/autopep8-my-changes?<br>
<br>
If that's right then my feeling is that the goal seems worthwhile but<br>
the approach seems difficult and unlikely to survive for long. As soon<br>
as someone overrides autopep8 once, we either have to disable the rule<br>
for the whole project or keep overriding it manually forever. You're<br>
already suggesting taking out the spaces-around-arithmetic rule, which<br>
strikes me as one of the most useful -- sure, it gets things wrongs<br>
sometimes, but I feel like we're constantly reviewing PRs where<br>
all*the*(arithmetic+is)-written**like*this.<br>
<br>
Maybe a better approach would be to spend that time hacking up some<br>
script that uses git and autopep8 together to run autopep8 over all<br>
and only those lines which the current branch has actually touched?<br>
It's pretty easy to parse 'git diff' output to get a list of all line<br>
numbers which have been modified, and then we could run autopep8 over<br>
the modified files and pull out only those changes which touch those<br>
lines.<br>
<br>
-n<br>
<br>
P.S.: definitely [:, :, 2]<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div><br></div>