> That tool would also have to be integrated > into the pull request workflow somewhere; pushing for more PEP 8 > conformance requires identifying a suitable spot for that. >
What about documenting first this as a policy? E.g., here: https://github.com/sympy/sympy/wiki/Development-workflow#wiki-be-sure-that-all-tests-of-sympy-pass I think, for newcomers it's easier to run the style checker & fix mentioned errors, then to read the actual PEP 8. Another problem with PEP 8 conformance is that it raises the entry > barrier for new contributors, since they need to polish their code > before they can even test it. But after this, 1) we can avoid a dozens of comments about pep8 issues for almost every new PR (especially from newcomers). 2) we can cleanup the future git history a lot (by avoiding purely stylistic commits like 7d56e82). Again, almost in every new PR. I think, it will make happy git-blame users ;) > So the tool needs to be integrated in a > way that is as unobtrusive as possible (say, the failing test could tell > them the exact incantation for bin/pep8 to make the test pass; > There is an upstream documentation: http://pep8.readthedocs.org/en/latest/intro.html#error-codes If something is not clear enough here (what?), we can fix this. automatically running bin/pep8 in preparation to tests would be less > obtrusive but could damage code so bin/pep8 needs to be extra careful, > maybe by saving backups or something). > pep8 doesn't modify sources. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
