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

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


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

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.
>

So am I. I don't like the changes it makes to scmposix.py, 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
black?


> 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 mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190508/af914ff0/attachment.html>


More information about the Mercurial-devel mailing list