[Python-Dev] How is the GitHub workflow working for people?

[Gregory P. Smith]

How often do we find ourselves grumbling over .py file style in PRs on
github?  If the answer to that isn't very often, the rest of my response
below seems moot. :)

On Wed, Feb 21, 2018 at 7:30 PM Guido van Rossum <guido at python.org> wrote:

> Where I work we have some teams using flake8 and some teams that use
> pylint, and while pylint is more thorough, it is also slower and pickier,
> and the general sense is to strongly prefer flake8.
>
> I honestly expect that running either with close-to-default flags on
> stdlib code would be a nightmare, and I wouldn't want *any* directives for
> either one to appear in stdlib code, ever.
>
> In some ideal future all code would just be reformatted before it's
> checked in -- we're very far from that, and I used to be horrified by the
> very idea, but in the Go world this is pretty much standard practice, and
> the people at work who are using it are loving it. So I'm trying to have an
> open mind about this. But there simply isn't a tool that does a good enough
> job of this.
>

I don't know the specifics of your idea of "a good enough job of this" for
an auto-formatter is (we'd need to settle on that definition in a PEP)..
but there is for my definition: yapf <https://pypi.python.org/pypi/yapf>.

Many teams require it pre-check-in for their code at Google these days. We
also use it for auto-reformatting of surrounding lines of code during all
sorts of mass-refactorings.  IIRC Lukas said Instagram/Facebook adopted it
as standard practice as well.

Some teams go all the way to enforce a "yapf must suggest no changes to the
edited areas of .py files" pre-submit error on their projects.

As Eric (and I believe Lukas in the past) has mentioned: auto formatters
don't have to produce mythical(*) "perfect" style the way individuals might
choose - they need to be good enough to keep people from arguing about
style with one another.  That's the productivity and consistency win.

What we need now is not more opinions on which formatter or linter is best.
> We need someone to actually do some work and estimate how much code would
> be changed if we ran e.g. tabnanny.py (or something more advanced!) over
> the entire stdlib, how much code would break (even the most conservative
> formatter sometimes breaks code that wasn't expecting to be reformatted --
> e.g. we used to have tests with significant trailing whitespace), and how
> often the result would be just too ugly to look at. If you're not willing
> to work on that, please don't respond to this thread.
>

Indeed.  There are at *least* four Python style and gotcha checkers in wide
use for Python code out there today.  Prematurely picking one up front
rather than coming up for criteria of which limited set of things we would
want and could practically use on the stdlib + testsuite seems wrong.

I've added "run yapf on all of CPython's .py files" to my list of things to
explore (or encourage someone else to) some day...

-gps

(*) caveat: Given that Guido has obtained History status
<https://twitter.com/gvanrossum/status/966346442477510657> and is BDFL he
can define mythical perfect style
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180223/b1a45a17/attachment-0001.html>