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 <gu...@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
_______________________________________________ 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/archive%40mail-archive.com
