[Python-Dev] Code formatter bot

[Andrew Barnert]

On Jan 20, 2016, at 00:35, Ben Finney <ben+python at benfinney.id.au> wrote:
> 
> francismb <francismb at email.de> writes:
> 
>> what's your opinion about a code-formatter bot for cpython.
> 
> What is the proposal? The opinions will surely depend on:

... plus:

* How does the formatter bot deal with "legacy code"? Large parts of CPython predate PEPs 7 and 8, and the decision was made long ago not to reformat existing code unless that code is being substantially modified for some other reason. Similarly, when the PEPs are updated, the usual decision is to not reformat old code.

* When code _is_ auto-reformatted, what tools do you have to help git's merge logic, Reitveld, human readers looking at diffs or blame/annotate locally or on the web, etc. look past the hundreds of trivial changes to highlight the ones that matter?

* What's the argument for specifically automating code formatting instead of any of the other things a commit-triggered linter can catch just as easily?

But one comment on Ben's comment:

>  * If on the other hand you propose to enforce only those rules which
>    are strict enough to be applied automatically (e.g. “don't mix
>    spaces and TABs”, “encode source using UTF-8 only”) then that's best
>    done by editor plug-ins like EditorConfig[0].

In my experience (although mostly with projects with a lot fewer contributors than CPython...), it can be helpful to have both suggested editor plugins that do the auto formatting on the dev's computer, and VCS-triggered checkers that ensure the formatting was correct. That catches those occasional cases where you do a quick "trivial" edit in nano instead of your usual editor and then forget you did so and try to check in), without the nasty side-effects you mention later (like committing code you haven't seen).

(Of course writing plugins that understand "legacy code" in the exact same way as the commit filter can be tricky, but in that case, it's better to know that one or the other isn't working as intended--both so a human can decide, and so people can see the bug in the plugin or filter--than to automatically make changes that weren't wanted.)