Auto-formatting with yapf (was: Re: Auto-formatting code with black - object now if you have a strong opinion)
gregory.szorc at gmail.com
Mon Feb 11 13:21:16 EST 2019
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.
I'm not sure if it has been proposed yet, but have we considered vendoring
black and changing its behavior to satisfy our needs? 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>
> > >
> > >> 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
> > >> consistency level provided by e.g. astyle command. clang-format is
> > >> 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:
> Thanks for trying it. Maybe I have to agree that the black is less bad.
> Why does yapf split tuples unnecessarily?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel