Dear Core-Devs, what's your opinion about a code-formatter bot for cpython. Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ... - At least it should follow PEP 7 ;-) - ... Thanks in advance, francis
Not a core dev, but I would definitely recommend using them. Best, Sven On 19.01.2016 21:59, francismb wrote:
Dear Core-Devs, what's your opinion about a code-formatter bot for cpython. Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ...
- At least it should follow PEP 7 ;-) - ...
Thanks in advance, francis
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de
On Tue, Jan 19, 2016 at 12:59 PM, francismb <francismb@email.de> wrote:
Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ...
-1. formatting should be done by humans (with the help of tools) before committing. It should not be left to a robot to make automatic changes. We already some pre-commit hooks which do basic checks. If anything more automated is desirable then enhancement to the pre-commit hooks could be the place to look for. As far as I know, none of the core devs have expressed any complaints the pre-commit hooks. -- Senthil
Indeed, automated code formatting is a good thing. But a bot is the wrong approach. You want a code formatting checker as a potential pre-submit hook (like we have had for white space issues in the past), but until you have super high confidence in it you need to make sure it is not a blocker for a commit or push, just a default check that can be explicitly skipped for the infrequent cases where it is wrong. It's a workflow thing. Devs should have their editor setup to auto-run the correct formatter or easily run it if not automatic. -gps On Tue, Jan 19, 2016 at 4:29 PM Senthil Kumaran <senthil@uthcode.com> wrote:
On Tue, Jan 19, 2016 at 12:59 PM, francismb <francismb@email.de> wrote:
Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ...
-1. formatting should be done by humans (with the help of tools) before committing. It should not be left to a robot to make automatic changes.
We already some pre-commit hooks which do basic checks. If anything more automated is desirable then enhancement to the pre-commit hooks could be the place to look for. As far as I know, none of the core devs have expressed any complaints the pre-commit hooks.
-- Senthil
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
francismb <francismb@email.de> writes:
what's your opinion about a code-formatter bot for cpython.
What is the proposal? The opinions will surely depend on: * What formatting is to be applied automatically? * If you propose to enforce rigid interpretations of the style-guide PEPs as automatic rules, that will incur the wrath of those who have made clear those PEPs are not to be used that way. There is a clear opinion (from at least the BDFL) that the style guide PEPs are guidelines to be applied with human judgement. * 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]. * At which point in the workflow will the formatting be applied? * If you propose to change the code *after* the programmer sees it in their text editor, that is sure to be unpopular. The code committed to VCS should exactly match what the programmer sees when they choose to commit. * If you propose to reject the code at time of committing, there are VCS hooks that can do that; I don't know what different system you propose. * If you propose to present formatting violations as errors in the programmer's text editor so they can be corrected before using the VCS, then there are tools like EditorConfig[0] to do that. [0]: EditorConfig <URL:http://editorconfig.org/> -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but isn't a cucumber that small called a gherkin?” | _o__) —_Pinky and The Brain_ | Ben Finney
On Jan 20, 2016, at 00:35, Ben Finney <ben+python@benfinney.id.au> wrote:
francismb <francismb@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.)
Andrew Barnert via Python-Dev <python-dev@python.org> writes:
[…] 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.
Right, I was not intending the different stages to be exclusive. I was seeking clarification from the OP on the intended stages proposed to be automated. It's also worth noting that neither of the above approaches you mention would qualify IMO to be termed a “bot”, since they still leave it to the human operator to deal with formatting violations before the edits reach the VCS. But that's another clarification I'm seeking from the OP: what “bot” is being proposed? -- \ “Nothing is more sacred than the facts.” —Sam Harris, _The End | `\ of Faith_, 2004 | _o__) | Ben Finney
Thanks again to all persons that commented so far.
what's your opinion about a code-formatter bot for cpython. Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ...
- At least it should follow PEP 7 ;-) - ...
There seems to be too much implicit information on the lines above. Sorry for that. I'll try to clarify.
From my point of view (not a core-dev) the reviews seem to be one of the bottlenecks to the commit throughput, and I noticed on the other PEP 7 thread that time is taken to review such, IMHO, (and as Andrew also noted) trivialities. Thus the basic idea was to get that noise away from the reviews, somehow (better upfront, but why not after, accidental PEP 7 noise commits can happen). Well, people should first agree on that PEP and then some automatic could come.
Please notice that the interaction is not just: core-dev committing to a repo or a bot committing to a repo but external-contributor that tries to minimize review iterations. I have no problem with some process (call it now a bot or script) that just changes a patch/file to reduce that cycle (but it could, run on all the workflow points you mentioned, plus on the PR-site as a kind of an advisor/mentor). Regards, francis
Hi, from your valuable feedback, here is what I thing could be a previous requirements list (lets call it for e.g. autopep7 script by now): - It should follow PEP 7 :-) - It should check PEP 7 compliance on a per file basis (for simplicity) - It should be embeddable on the test suite, returning PASS or FAILURE - It should be usable as a pre-commit hook - It could return a patch to apply to the non compliant file making it compliant - It could return the lines (an the reason why) that aren't compliant Some other details on using some autopep7 on the infrastructure (as part of a workflow, by wrapping or enhancing it): - It could be used it on a regular basis against the cpython repo to be able to see how much files doesn't follow PEP 7. The first time shows the legacy ones (plus the current failures). - It should be used in pair with a "skip" list to avoid checking the legacy code mentioned (or a list of pairs file:reason to skip). - It could be used on the CI-side to flag PEP 7 compliance (core-devs doesn't have to need to point to that in reviews). Or could be used as a part of series of checks that generate a "ready-to-review" flag. - It could be used to continually check and proposes patches (on bug.python.org). - It could be used to continually check, log the issue on the tracker and commit the patch to the cpython repository. Regards, francis
On Jan 19, 2016, at 12:59 PM, francismb <francismb@email.de> wrote:
Dear Core-Devs, what's your opinion about a code-formatter bot for cpython. Pros, Cons, where could be applicable (new commits, new workflow, it doesn't make sense), ...
- At least it should follow PEP 7 ;-)
Please don't do this. It misses the spirit of how the style-guides are intended to be used. "I personally hate with a vengeance that there are tools named after style guide PEPs that claim to enforce the guidelines from those PEPs. The tools' rigidity and simplicity reflects badly on the PEPs, which try hard not to be rigid or simplistic." -- GvR https://mail.python.org/pipermail/python-dev/2016-January/142643.html "PEP 8 unto thyself, not onto others" -- Me https://www.youtube.com/watch?v=wf-BqAjZb8M (the most popular talk from last year's Pycon) Almost nothing that is wrong with CPython is stylistic, the real issues are more substantive. That is where you should devote your talents. Raymond Hettinger
Hi, On 01/25/2016 01:28 AM, Raymond Hettinger wrote:
- At least it should follow PEP 7 ;-)
Please don't do this. It misses the spirit of how the style-guides are intended to be used.
"I personally hate with a vengeance that there are tools named after style guide PEPs that claim to enforce the guidelines from those PEPs. The tools' rigidity and simplicity reflects badly on the PEPs, which try hard not to be rigid or simplistic." -- GvR https://mail.python.org/pipermail/python-dev/2016-January/142643.html
Good point, tools need to get better (more context sensitive), maybe should work only as advisors and have just funny names (and not claim the spirit).
"PEP 8 unto thyself, not onto others" -- Me https://www.youtube.com/watch?v=wf-BqAjZb8M (the most popular talk from last year's Pycon)
Almost nothing that is wrong with CPython is stylistic, the real issues are more substantive. That is where you should devote your talents.
Good advices and refactoring on your talk (and I love the gorilla part but I think that the "color_distraction" trick doesn't work for "non native" speakers as me ;-)) and indeed, that wanted to be my point: Let's review what the code does and not 007-Things. It's was really about the workflow not style, but I'll follow your advice. Regards, francis PS: Interesting is also how/why do people introduce bug's by reformatting or trying to beautify things (and how those can be avoided, by allowing change).
participants (7)
-
Andrew Barnert -
Ben Finney -
francismb -
Gregory P. Smith -
Raymond Hettinger -
Senthil Kumaran -
Sven R. Kunze