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

[Gregory Szorc]

On Wed, May 8, 2019 at 12:42 PM Augie Fackler <raf at durin42.com> 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've gotten frustrated with yapf and explored autopep8 - yapf is
> frustrating, and autopep8 isn't very good at wrapping lines. Fortunately,
> at PyCon I was able to convince ambv that trailing-comma-implies-multiline
> was a good feature, and the code for that is under review.
>
> https://phab.mercurial-scm.org/D6342 is an updated version of the
> blackening preview with my black patch applied. I'm very happy with the
> results (compare with the previous round - in particular imports are
> cleaner.) It's not 100% what we want, specifically:
>
>  * imports of a single name will still get forced down to a single line
>  * one-tuples will get forced down to a single line, even if they started
> on multiple lines
>
> Overall I'm much happier with the results now - I can make another change
> that blackens more files if people are curious and not opposed to moving
> forward with black. Once we can reach a consensus on a formatter, we can
> think about running byteify-strings on everything. Realistically byteifying
> strings will require us to be on an auto-formatter because of all the
> too-long lines it will otherwise create.
>

I'm pretty happy with the state of D6342.

Out of curiosity, is Black opinionated about single versus double quotes?
AFAICT it seems to preserve whatever is there? That somewhat surprises me.

Also, I've mentioned this in other threads but I think it needs to be
repeated here: I view making the source code Python 3 native (read: no
source transforming module importer) as a prerequisite to removing the
"beta" label from Python 3 support. This is because the source transforming
is making some packaging problems very difficult. Because we need to use
bytes literals, I think it is easier for us to adopt a source formatter and
reformat the repo than to do everything by hand. So, the sooner we can get
a style formatter in place, the sooner we can make meaningful progress
towards making the source code Python 3 native and making Mercurial stable
on Python 3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190508/12e7d06c/attachment.html>