Auto-formatting with yapf (was: Re: Auto-formatting code with black - object now if you have a strong opinion)

[Augie Fackler]

> On Feb 11, 2019, at 13:21, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> 
> I'm reviving this thread because I want us to commit to something.
> 
> I *really* want us to mass reformat the repo, mainly so we can make the source code Python 3 native (so we can do away with our custom source transforming module importer) ASAP.

Maybe take a look at the output yapf has with `split_all_comma_separated_values = true` removed from the config (see https://phab.mercurial-scm.org/D5539 for a starting point, alter the config and then run `hg status --rev .^ -m 'set:**/*.py' -n | xargs yapf -i` to see what changes) - that looks like it might be close enough we could live with it for at least until PyCon - I'd be happy to try and snag ambv at PyCon (I assume he'll be there) and see if I can convince him I'm right enough he should consider a patch.

> 
> I'm not sure if it has been proposed yet, but have we considered vendoring black and changing its behavior to satisfy our needs?

The only major problem with black is un-wrapping dict/set/tuple/list literals that we'd rather keep wrapped, right? I think if https://github.com/ambv/black/issues/601 was resolved in a manner similar to clang-format we'd be able to get everything we want.

> This will also make it easier for Mercurial developers to incorporate black into workflows: we'll be able to commit hooks/extensions for running/testing source formatting without having to worry about 3rd party dependencies being installed. I don't see a long-term maintainability issue with vendoring black because whatever version of black we vendor should continue to run for the foreseeable future: the only thing I can think of that would cause it to break would be the introduction of new symbols in Python's grammar, and that tends to be rare. And even when it does, Mercurial won't adopt them for years due to BC requirements.
> 
> On Fri, Jan 11, 2019 at 11:50 PM Yuya Nishihara <yuya at tcha.org> wrote:
> On Wed, 9 Jan 2019 15:30:19 -0500, Augie Fackler wrote:
> > 
> > 
> > > On Dec 6, 2018, at 23:21, Matt Harbison <mharbison72 at gmail.com> wrote:
> > > 
> > > On Wed, 05 Dec 2018 08:23:17 -0500, Yuya Nishihara <yuya at tcha.org> wrote:
> > > 
> > >> On Tue, 4 Dec 2018 10:06:24 -0500, Augie Fackler wrote:
> > >>> 
> > >>> So, options to move forward:
> > >>> 1) blacken everything (controversial for good reasons)
> > >>> 2) try black only on a subset
> > >>> 3) explore yapf
> > >>> 4) Give up and keep manually formatting files (I'd rather not do this, but I understand if it's where we end up)
> > >> 
> > >> My vote: 3 > 4 > 2 > 1
> > >> 
> > >> I'm not super enthusiastic about 100%-machine-forced formatting. I like
> > >> consistency level provided by e.g. astyle command. clang-format is pretty
> > >> good IMHO, but the black seems to sacrifice the code readability.
> > > 
> > > +1.
> > > 
> > > That said, I got used to longnamesthataresmooshedtogether, so I can probably adjust to anything after awhile.
> > 
> > I think I'd still prefer black overall (yapf is less opinionated and requires me to think more), but here's a yapf RFC: https://phab.mercurial-scm.org/D5539
> 
> Thanks for trying it. Maybe I have to agree that the black is less bad.
> 
> Why does yapf split tuples unnecessarily?
> https://phab.mercurial-scm.org/D5539#C29949NL27
> 
> Maybe yapf could be configured to get saner results, but I also heard yapf
> configuration is abstract, and it isn't easy to get expected result overall.