Re: Proposal to format Django using black

2019-04-25 Thread Herman S
On Fri, Apr 19, 2019 at 6:33 PM Mariusz Felisiak
 wrote:
> I don't think that our code style is any barrier for newcomers.

As a newcomer, I can tell you that it most definitely is a barrier, at
least it is for me – for the reasons laid out in my original email :)

*

>From what I can gather the following arguments have been raised against Black:

- I don't like the formatting style (double quotes, white-space, line
length, wrapping, ...)
- It produces one huge diff
- It, in some situations, produces weird formatting (lists with comments, ...)
- It doesn't solve an issue that we currently have

At the end of the day some of these arguments are just personal
opinions and comes down to preference. However a lot of
counter-arguments have been made and I'll just shortly summarize them
here:

* I don't like the formatting style
  We will never collectively agree on "the perfect" formatting and
many do not agree with the *current* formatting. The time spent having
these non value-adding discussions are not worth it, and Black would
eliminate them to
  to a large extent.

* It produces one huge diff
  There are tools to work around this (git-hyper-blame [0]), Github
has a great UI for browsing diffs and it looks like in the future it
will be possible to exclude certain commits from blame history [1].

* It, in some situations, produces weird formatting
  A lot of these can be remedied my using `--target-version=py37` as
the AST does not change in newer versions of Python. Other files (like
settings) can be either disabled from auto-formatting or we can
disable parts of the file with `# fmt: off`.

* It doesn't solve an issue that we currently have
  I, and a lot of people have expressed this too, feel like it
definitely solves a very real problem. Formatting of code delays PRs,
wastes time, makes it harder to contribute as a newcomer, is an extra
cognitive load for all of us, and produces
  loads of wasteful discussions.

I'm sure there are more arguments made too, I'm sorry if I missed
some, but these seem to be repeated most often.

*

I favor adopting the default configuration (88 width, double quotes)
in one go and just be done with it. It's not as scary as it seems and
it really just makes the day a tiny bit easier :-)

What has usually been the process of democratically deciding these
"controversial" topics in the past? From what I gather there is a
clear majority favoring Black, but I'm curious as to when and how we
decide to end the discussion either for or against.

Kind regards,

[0]: 
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
[1]: https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/

-- 
Herman Schistad

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN%3DnMTywHoSuccTi4krcXwfKDNu67mg1HKfmqk0LR94vBLFa%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Proposal to format Django using black

2019-04-13 Thread Herman S
Hi.

I propose that Django starts using 'black' [0] to auto-format all Python code.
For those unfamiliar with 'black' I recommend reading the the projects README.
The short version: it aims to reduce bike-shedding and non value-adding
discussions; saving time reviewing code; and making the barrier to entry lower
by taking some uncompromissing choices with regards to formatting.  This is
similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.

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
tweaking formatting. Before this, I had to research the style used by exploring
the docs at length and reading at least 10-20 different source – and even those
were not always consistent. At the end of the day I felt like almost 50% of the
time I used on the patch was not used on actually solving the issue at hand.
Thinking about code formatting in 2019 is a mental energy better used for other
things, and it feels unnecessary that core developers on Django spend their time
"nit-picking" on these things.

I recently led the efforts to make this change where I work. We have a 200K+
LOC Django code-base with more than 30K commits. Some key take-aways: it has
drastically changed the way we work with code across teams, new engineers are
easier on-boarded, PR are more focused on architectural choices and "naming
things", existing PRs before migration had surprisingly few conflicts and were
easy to fix, hot code paths are already "blameable" and it's easy to blame a
line of code and go past the "black-commit", and lastly the migration went
without any issues or down-time.

I had some really fruitful discussions at DjangoCon Europe this week on this
very topic, and it seems we are not alone in these experiences. I would love to
hear from all of you and hope that we can land on something that will enable
*more* people to easier contribute back to this project.

I've set up how this _could_ look depending on some configurables in Black:

* Default config: https://github.com/hermansc/django/pull/1
* Line length kept at 119: https://github.com/hermansc/django/pull/3
* Line length kept at 119, no string normalization:
https://github.com/hermansc/django/pull/2

Please have a look at the Black documentation. It explains the benefits better
than I possibly could do here.

With kind regards,
Herman Schistad

[0]: https://github.com/ambv/black

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.