As per the DEP process, I have merged DEP 8, Formatting Code With Black, into the DEP repo as a draft. This doesn't mean it's decided yet - any DEP that meets quality requirements gets merged as a draft - but it means that we're one step closer to doing so.
What follows is further discussion until it is either revised, withdrawn, or the author thinks they have enough feedback to put it to the technical board.
I will draw attention to the following part of DEP 1:
"However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate mailing list for the topic, having the DEP author accept private comments in the early design phases, setting up a wiki page, etc. DEP authors should use their discretion here"
Given this thread is now over 100 replies long, we might want to consider a better avenue for constructive feedback.
On Tue, Apr 30, 2019 at 12:31 PM Christian González <[hidden email]> wrote:
Just a thought: If Django were to adopt black (and I'm not saying it should), shouldn't it wait until it is out of the beta classification?
From: [hidden email] [mailto:[hidden email]] On Behalf Of Markus Holtermann
Sent: Thursday, May 2, 2019 11:06 AM
To: Django developers
Subject: Re: Proposal to format Django using black
Personally I first got involved contributing to Django couple of weeks back,
and from anecdotal experience I can testify to how 'formatting of code' creates
a huge barrier for entry. My PR at the time went multiple times back and forth
Wouldn't it have worked if you had used `black` on your code?
I.e. it is not necessary to apply it to the whole codebase, but maybe only mention it in the codestyle guide then? - leading to an incremental adoption, rather than applying it altogether.
I like black, but one of its bigger issues is not keeping already formatted/split lists (https://github.com/python/black/issues/796).