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

Martin von Zweigbergk martinvonz at
Wed May 8 23:08:16 EDT 2019

*From: *Gregory Szorc <gregory.szorc at>
*Date: *Wed, May 8, 2019, 19:32
*To: *Augie Fackler
*Cc: *mercurial-devel at, Matt Harbison

On Wed, May 8, 2019 at 12:42 PM Augie Fackler <raf at> wrote:
>> > On Dec 6, 2018, at 23:21, Matt Harbison <mharbison72 at> wrote:
>> >
>> > On Wed, 05 Dec 2018 08:23:17 -0500, Yuya Nishihara <yuya at>
>> 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.
>> 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.

So am I. I don't like the changes it makes to, but I assume
there is no way that black will change that (since it would change too many
existing users' code). I can easily live with it.

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

That surprises me too. I'm pretty sure an earlier version of that patch
changed them all to double quotes. Augie, is that something you changed in

> 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.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Mercurial-devel mailing list