Proposal to format Django using black

classic Classic list List threaded Threaded
107 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Emil Madsen
Hello,

I'm not sure if it's relevant for the discussion, but black requires python 3.6.0+.
Several Linux distros does not ship 3.6.0+ yet, including, but not limited to:

* Debian Stretch (current LTS)
* FreeBSD 12 (current release)
* Ubuntu 16.04 Xenial (previous LTS)
* Linux Mint 18.1 (previous LTS)
* OpenSuse Leap 42 (previous LTS)
* Slackware 14.1 (previous LTS)
* Fedora 27 (two versions old)

While it is ofcourse possible to install python 3.6.0+ on these systems, it requires more effort than a simple package manager install.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/fd23a249-7808-4ab4-a994-1e64d1dfa66f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Florian Apolloner
Hi Emil,

this would only affect Django 3.0 which supports only python3.6 -- as such you couldn't even run Django on those systems anyways.

Cheers,
Florian

On Tuesday, April 16, 2019 at 10:12:20 AM UTC+2, Emil Madsen wrote:
Hello,

I'm not sure if it's relevant for the discussion, but black requires python 3.6.0+.
Several Linux distros does not ship 3.6.0+ yet, including, but not limited to:

* Debian Stretch (current LTS)
* FreeBSD 12 (current release)
* Ubuntu 16.04 Xenial (previous LTS)
* Linux Mint 18.1 (previous LTS)
* OpenSuse Leap 42 (previous LTS)
* Slackware 14.1 (previous LTS)
* Fedora 27 (two versions old)

While it is ofcourse possible to install python 3.6.0+ on these systems, it requires more effort than a simple package manager install.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/978cc4b6-ede8-4dde-8591-4e6ad3bfb51b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Christian González
In reply to this post by Florian Apolloner

Am 14.04.19 um 12:15 schrieb Florian Apolloner:

> Hi Christian,
>
> I think you are making a good argument here. On one hand short-comings
> in our tool chain should not block us from making changes. On the
> other hand, we do have to live with them -- so having at least some
> technical solution towards the "git blame" issue is needed. I guess
> the chromium team also realized this, which led to the development of
> tools like git-hyper-blame (see
> https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
> -- to be fair I haven't tried it yet).
I've filed a feature request for git itself
(https://public-inbox.org/git/5df051ce-007c-cc12-6f02-345b33480c0a@.../T/),
and it seems that there is a feature within git which is in development
and seems to deal with that blame-before-not-important-commits issues.
Like I said there, it's not perfect IMHO, and would be done easier by
using a config file and individual/project specific commit takeouts for
blaming. That's certainly seen for long-term, but When Django 3.0 will
arrive, hopefully with black 1.x, it's early enough for "git with blake
skip support" too. And, as it's only for development, It would be fully
backwards compatible for git users that don't have support for that
feature - they could always use black/git and skip blame the "old" way.

That said, I hope black will be used in Django.

Christian

--
Dr. Christian González
https://nerdocs.at

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/abf83a20-9485-c367-eed1-57e3ad88ef4f%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

pEpkey.asc (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Jacob Rief
In reply to this post by Curtis Maloney-2
To address some of Curtis Maloney's concerns:

1. automated code formatting will be a great boon - reduce work, lower
barrier for new committers, reduce work for the fellows, etc.

2. there are issues with git history in doing "the great commit".

3. there are issues with black's formatting choices.

 
How about, instead of reformatting all the code in one big go, discarding the "blame"-history,
instead we use a tool which only checks for formatting violations and prevents to commit such
code.

Such a tool, for instance is Coala https://coala.io/#/about?lang=Python
This could be added as a Pre-Commit Hook and prevents contributors to create non-conformant
branches on GitHub. This would address the problem of some pull requests not being merged
for a long period, because of minor formatting issues.

It also would enforce new coding styles over a longer period, keeping code annotations until
someone touches a file.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/11c2539c-27bb-4ec4-b361-8f5f9a155aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Mariusz Felisiak

This would address the problem of some pull requests not being merged
for a long period, because of minor formatting issues.

We don't have such PRs. If PRs have tests, docs (when required) and solutions are of good quality we would fix minor formatting issues before merge. It never stopped us from merging.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/b9fd3273-c062-42cc-aded-2c824ce19e21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Simon Charette
In reply to this post by Jacob Rief
I feel like it would be worse as it would break formatting changes across multiple commits,
creating an inconsistent formatting code base and generating large unrelated changes diff
when altering a still untouched file which would make the review harder.

Cheers,
Simon

Le mardi 16 avril 2019 10:37:13 UTC-4, Jacob Rief a écrit :
To address some of Curtis Maloney's concerns:

1. automated code formatting will be a great boon - reduce work, lower
barrier for new committers, reduce work for the fellows, etc.

2. there are issues with git history in doing "the great commit".

3. there are issues with black's formatting choices.

 
How about, instead of reformatting all the code in one big go, discarding the "blame"-history,
instead we use a tool which only checks for formatting violations and prevents to commit such
code.

Such a tool, for instance is Coala <a href="https://coala.io/#/about?lang=Python" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcoala.io%2F%23%2Fabout%3Flang%3DPython\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHQBrg2VsyQYw4sFhMGhmGH6GvKVw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcoala.io%2F%23%2Fabout%3Flang%3DPython\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHQBrg2VsyQYw4sFhMGhmGH6GvKVw&#39;;return true;">https://coala.io/#/about?lang=Python
This could be added as a Pre-Commit Hook and prevents contributors to create non-conformant
branches on GitHub. This would address the problem of some pull requests not being merged
for a long period, because of minor formatting issues.

It also would enforce new coding styles over a longer period, keeping code annotations until
someone touches a file.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/211f3e33-b81d-421f-8609-5fe4d697a52b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Ivan Anishchuk
In reply to this post by Herman Schistad
My two cents: black's mostly ok but I'm against any auto-formatting. Code style is much more than whitespace arrangement, it requires looking, creative thinking, judging, and sometimes actually compromising rules and looks for readability while the usual attitude with such tools is "I have this autoformatter tool so I don't have to think about style anymore, see, all my whitespace is nice and shining". Using some helpers in your favorite editor is great but relying on automatics without looking is almost completely counter-productive.

I find that PR autocommenter is a great way to keep issues detectable by flake8/pylint to a minimum.

Ivan.

On Sat, Apr 13, 2019 at 6:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Josh Smeaton
Ivan, what you’re talking about is subjective code formatting, and lends itself to extreme bikeshedding and little consensus. Django already has a formatting standard that mergers try to enforce at review and commit time. But it’s time consuming, prone to missing things, and requires lots of back and forth. 

Not having to think of formatting at all, either as a developer or reviewer, is a major productivity win. Even if some of the formatting choices are not agreeable. 

On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers (Contributions to Django itself) <[hidden email]> wrote:
My two cents: black's mostly ok but I'm against any auto-formatting. Code style is much more than whitespace arrangement, it requires looking, creative thinking, judging, and sometimes actually compromising rules and looks for readability while the usual attitude with such tools is "I have this autoformatter tool so I don't have to think about style anymore, see, all my whitespace is nice and shining". Using some helpers in your favorite editor is great but relying on automatics without looking is almost completely counter-productive.

I find that PR autocommenter is a great way to keep issues detectable by flake8/pylint to a minimum.

Ivan.

On Sat, Apr 13, 2019 at 6:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Ivan Anishchuk
Yeah, it's very common to confuse style with formatting. Not having to think is a productivity win when and only when you don't care about your product's quality (in which case I'd suggest using generators and stop thinking about code altogether). Language is a communication tool, a programming language is a tool programmers use to talk to each other, and code passed through autoformatters (especially if author _didn't think_ about style) is harder to understand then written by thinking humans. It's pretty much like trying to stop thinking about style in English -- by using some processor to put your commas and whitespace in place you can generate something that is usually possible to understand, at least for the most part, but that and _good style_ would still be worlds apart (yes, natural languages are different, it's much easier to make things worse there, but it's not any easier to make things better in programming languages).

There are situations where compromising style for formatting is acceptable and even a good idea, I don't think here is one of them. Removing a significant expressive tool from a language just to ensure your whitespace is arranged according to some arbitrary rules is about as counter-productive and pointless as it can get. Not because sometimes it produces some bad results but exactly because it prevents humans from thinking and expressing themselves properly. What would you think about some processor renaming all your variables so that you don't have to think about naming them? Must be even better for productivity.

Ivan.

On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton <[hidden email]> wrote:
Ivan, what you’re talking about is subjective code formatting, and lends itself to extreme bikeshedding and little consensus. Django already has a formatting standard that mergers try to enforce at review and commit time. But it’s time consuming, prone to missing things, and requires lots of back and forth. 

Not having to think of formatting at all, either as a developer or reviewer, is a major productivity win. Even if some of the formatting choices are not agreeable. 

On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers (Contributions to Django itself) <[hidden email]> wrote:
My two cents: black's mostly ok but I'm against any auto-formatting. Code style is much more than whitespace arrangement, it requires looking, creative thinking, judging, and sometimes actually compromising rules and looks for readability while the usual attitude with such tools is "I have this autoformatter tool so I don't have to think about style anymore, see, all my whitespace is nice and shining". Using some helpers in your favorite editor is great but relying on automatics without looking is almost completely counter-productive.

I find that PR autocommenter is a great way to keep issues detectable by flake8/pylint to a minimum.

Ivan.

On Sat, Apr 13, 2019 at 6:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CADPNjZ52oJ-vQL1L27VH2a4%2Bd82q4K0z7PGXv8xwokXtexy3%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Josh Smeaton
We aren't talking about code minifiers though, are we? We're talking about a very specific tool with very specific rules. No one will ever agree on one specific code style, which is why subjectivity is anti-productive. Black chooses a specific set of rules and removes ambiguity. Some choices will be agreeable, others will not be. And the ones that are agreeable aren't agreeable to every person.

> and code passed through autoformatters (especially if author _didn't think_ about style) is harder to understand then written by thinking humans

I find this statement to be mostly incorrect with regard to Black. There are edge cases, but they are few.

On Wednesday, 17 April 2019 09:45:11 UTC+10, Ivan Anishchuk wrote:
Yeah, it's very common to confuse style with formatting. Not having to think is a productivity win when and only when you don't care about your product's quality (in which case I'd suggest using generators and stop thinking about code altogether). Language is a communication tool, a programming language is a tool programmers use to talk to each other, and code passed through autoformatters (especially if author _didn't think_ about style) is harder to understand then written by thinking humans. It's pretty much like trying to stop thinking about style in English -- by using some processor to put your commas and whitespace in place you can generate something that is usually possible to understand, at least for the most part, but that and _good style_ would still be worlds apart (yes, natural languages are different, it's much easier to make things worse there, but it's not any easier to make things better in programming languages).

There are situations where compromising style for formatting is acceptable and even a good idea, I don't think here is one of them. Removing a significant expressive tool from a language just to ensure your whitespace is arranged according to some arbitrary rules is about as counter-productive and pointless as it can get. Not because sometimes it produces some bad results but exactly because it prevents humans from thinking and expressing themselves properly. What would you think about some processor renaming all your variables so that you don't have to think about naming them? Must be even better for productivity.

Ivan.

On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">josh....@...> wrote:
Ivan, what you’re talking about is subjective code formatting, and lends itself to extreme bikeshedding and little consensus. Django already has a formatting standard that mergers try to enforce at review and commit time. But it’s time consuming, prone to missing things, and requires lots of back and forth. 

Not having to think of formatting at all, either as a developer or reviewer, is a major productivity win. Even if some of the formatting choices are not agreeable. 

On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers (Contributions to Django itself) <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com> wrote:
My two cents: black's mostly ok but I'm against any auto-formatting. Code style is much more than whitespace arrangement, it requires looking, creative thinking, judging, and sometimes actually compromising rules and looks for readability while the usual attitude with such tools is "I have this autoformatter tool so I don't have to think about style anymore, see, all my whitespace is nice and shining". Using some helpers in your favorite editor is great but relying on automatics without looking is almost completely counter-productive.

I find that PR autocommenter is a great way to keep issues detectable by flake8/pylint to a minimum.

Ivan.

On Sat, Apr 13, 2019 at 6:35 PM Herman S <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">herman....@...> wrote:
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: <a href="https://github.com/hermansc/django/pull/1" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg_ctdhGBSbdZK3W4NXBAYv5TtMw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg_ctdhGBSbdZK3W4NXBAYv5TtMw&#39;;return true;">https://github.com/hermansc/django/pull/1
* Line length kept at 119: <a href="https://github.com/hermansc/django/pull/3" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGnhCGXsB5HJ8sSyIW9DS2rkVMraw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGnhCGXsB5HJ8sSyIW9DS2rkVMraw&#39;;return true;">https://github.com/hermansc/django/pull/3
* Line length kept at 119, no string normalization:
<a href="https://github.com/hermansc/django/pull/2" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFQNq-hc9geZY_3egU-27BkSAvBhQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFQNq-hc9geZY_3egU-27BkSAvBhQ&#39;;return true;">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]: <a href="https://github.com/ambv/black" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fambv%2Fblack\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrqVzKdISFdVR5lSsDnknmEceSew&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fambv%2Fblack\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrqVzKdISFdVR5lSsDnknmEceSew&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe&#39;;return true;">https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="zLwfH1CWAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/0fd5f210-1b79-4cce-947e-d8f4e132fd69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Dan Davis
+1 isort
-1 black

I think that codestyle checkers are better, because you teach yourself proper style for python.

On Tue, Apr 16, 2019 at 8:17 PM Josh Smeaton <[hidden email]> wrote:
We aren't talking about code minifiers though, are we? We're talking about a very specific tool with very specific rules. No one will ever agree on one specific code style, which is why subjectivity is anti-productive. Black chooses a specific set of rules and removes ambiguity. Some choices will be agreeable, others will not be. And the ones that are agreeable aren't agreeable to every person.

> and code passed through autoformatters (especially if author _didn't think_ about style) is harder to understand then written by thinking humans

I find this statement to be mostly incorrect with regard to Black. There are edge cases, but they are few.

On Wednesday, 17 April 2019 09:45:11 UTC+10, Ivan Anishchuk wrote:
Yeah, it's very common to confuse style with formatting. Not having to think is a productivity win when and only when you don't care about your product's quality (in which case I'd suggest using generators and stop thinking about code altogether). Language is a communication tool, a programming language is a tool programmers use to talk to each other, and code passed through autoformatters (especially if author _didn't think_ about style) is harder to understand then written by thinking humans. It's pretty much like trying to stop thinking about style in English -- by using some processor to put your commas and whitespace in place you can generate something that is usually possible to understand, at least for the most part, but that and _good style_ would still be worlds apart (yes, natural languages are different, it's much easier to make things worse there, but it's not any easier to make things better in programming languages).

There are situations where compromising style for formatting is acceptable and even a good idea, I don't think here is one of them. Removing a significant expressive tool from a language just to ensure your whitespace is arranged according to some arbitrary rules is about as counter-productive and pointless as it can get. Not because sometimes it produces some bad results but exactly because it prevents humans from thinking and expressing themselves properly. What would you think about some processor renaming all your variables so that you don't have to think about naming them? Must be even better for productivity.

Ivan.

On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton <[hidden email]> wrote:
Ivan, what you’re talking about is subjective code formatting, and lends itself to extreme bikeshedding and little consensus. Django already has a formatting standard that mergers try to enforce at review and commit time. But it’s time consuming, prone to missing things, and requires lots of back and forth. 

Not having to think of formatting at all, either as a developer or reviewer, is a major productivity win. Even if some of the formatting choices are not agreeable. 

On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers (Contributions to Django itself) <[hidden email]> wrote:
My two cents: black's mostly ok but I'm against any auto-formatting. Code style is much more than whitespace arrangement, it requires looking, creative thinking, judging, and sometimes actually compromising rules and looks for readability while the usual attitude with such tools is "I have this autoformatter tool so I don't have to think about style anymore, see, all my whitespace is nice and shining". Using some helpers in your favorite editor is great but relying on automatics without looking is almost completely counter-productive.

I find that PR autocommenter is a great way to keep issues detectable by flake8/pylint to a minimum.

Ivan.

On Sat, Apr 13, 2019 at 6:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/0fd5f210-1b79-4cce-947e-d8f4e132fd69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFzonYaRN65F%3DjULCNhs27gD%2BKsQLDbZsTHkb6PjDuvyudDRfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Matthias Kestenholz-7
In reply to this post by Herman Schistad
After dozens of mails it's clear that this is certainly a controversial topic -- especially, as always, string quoting.

I think there is an overwhelming benefit in adopting black and not deviating from the defaults even if the only benefit of this is just never having to discuss these choices again.

Adopting black has helped in all projects I (help) maintain. A few of them are well known, but the specific projects do not matter much.

And I'm one of those people who hesitated because I didn't like many of the choices black made but I adapted really quickly.

Thanks,
Matthias

On Sat, Apr 13, 2019 at 5:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.


--
www.feinheit.ch[hidden email] — +41 555 11 11 41

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CANvPqgBua2Jsga7f4jTaaW45%3DcROcxXt1zUbx2wH%2Bs4TJRp7Hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Tobias Kunze-2
In reply to this post by Dan Davis
Hi Dan,

On 19-04-16 20:33:29, Dan Davis wrote:
>+1 isort
>-1 black
>
>I think that codestyle checkers are better, because you teach yourself
>proper style for python.

I appreciate this argument, but: As Django community our primary concern
in this discussion has to be the impact black would have on the Django
code base and the Django development process – educating our
contributors cannot be a primary concern, compared to making
contributions as easy as possible.

Tobias

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/20190417082648.miicsigxjwoevmkl%40cordelia.localdomain.
For more options, visit https://groups.google.com/d/optout.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Brice PARENT-2
In reply to this post by Dan Davis
Le 17/4/19 à 2:33, Dan Davis a écrit :
> +1 isort
> -1 black
>
> I think that codestyle checkers are better, because you teach yourself
> proper style for python.

I'm in a team in which we've enforced Black a bit more than a year ago,
and I can tell you that now, everyone code in a blackish style from
start. Black is still always executed, but doesn't make any change most
of the time. It's just there to enforce the style, for newcomers and if
we sometimes make some style mistakes.

A big win here.

[snip]

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/23ba5efe-f290-c3d7-e24f-8e109d61efb9%40brice.xyz.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Tom Forbes
In reply to this post by Tobias Kunze-2
I would be +1 for Black. I think it makes a lot of sense for a project like Django, and it does seem that a non trivial amount of both contributor and reviewer time is spent on formatting fixes.

The choice of double quotes by default used to annoy me, but after using black for a while I think that the benefits outweigh the downsides.

One thing we have not considered here is that after running black on Django a huge portion of our outstanding merge requests will have conflicts, some of which might be tricky to rebase. I’m not sure there is much we can do about that though.

Tom

> On 17 Apr 2019, at 09:26, Tobias Kunze <[hidden email]> wrote:
>
> Hi Dan,
>
>> On 19-04-16 20:33:29, Dan Davis wrote:
>> +1 isort
>> -1 black
>>
>> I think that codestyle checkers are better, because you teach yourself
>> proper style for python.
>
> I appreciate this argument, but: As Django community our primary concern
> in this discussion has to be the impact black would have on the Django
> code base and the Django development process – educating our
> contributors cannot be a primary concern, compared to making
> contributions as easy as possible.
>
> Tobias
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> 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/20190417082648.miicsigxjwoevmkl%40cordelia.localdomain.
> For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/AFFEB466-A328-4DA6-8845-F2DFB55C1ED1%40tomforb.es.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Jon Dufresne
> One thing we have not considered here is that after running black on Django a huge portion of our outstanding merge requests will have conflicts, some of which might be tricky to rebase. I’m not sure there is much we can do about that though.

With a little bit of git-foo, this is actually not that bad. In past projects, this is the approach I took:

    $ git checkout my-branch
    # Rebase on the parent of the commit introducing Black.
    $ git rebase <black-commit>^
    # Fix normal merge conflicts.
    # ...
    # Rebase on the Black commit, instructing git to prefer the rebased changes
    # over the black changes. For rebase, the terminology is backwards, hence
    # "theirs".
    $ git rebase <black-commit> -X theirs
    # Reformat your changes with black.
    $ black .
    # Amend the commit with the Black formatting changes.
    $ git commit --ammend -a

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CADhq2b7JD6C-wqyKgPVDK0JOvX_W_vgzAe%2Be6TcSkC6ArPm5jA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Jani Tiainen
In reply to this post by Herman Schistad
Well let me add my two cents here since I was also in the group in DCEU that talked about the usage of black.

Personally I don't like to contribute to Django. And this is why:

Day one: I'll make the fix/patch and create PR
Day two (or four or five depending how busy reviewers are): I missed a comma or some minor indent is wrong
Day three: I fix styles
Day four: PR is accepted.

So whole round trip took about a five days (give a take few usually depending how busy reviewers are).

That gives me a feeling that I'm really wasting my time and since I can't get all the small bits and pieces exactly as Django wants in correct place.

And that's because we have slightly different rules at the work. And some other projects do have different rules.

So it would be great if some of this pain could be relieved with a tool. In my short experience with black (I've been using it for work projects) it does a pretty decent job.

Like others have said black does some decisions I don't agree with. But I don't have to. Black does it for a "greater good". And after a while black actually vanishes from the flow. 

On Sat, Apr 13, 2019 at 6:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.


--
Jani Tiainen
Software wizard


Always open for short term jobs or contracts to work with Django.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Luke Plant-2

Hi all,

An alternative solution to the problem of nit-picky, formatting related PR reviews is simple: let's not do that.

We already have an automated code formatting enforcer, flake8. Let's simply drop the requirement on fixing anything that flake8 doesn't pick up. A committer can fix up style issues if they want to, but shouldn't make anyone else do it. This would mean most of the stuff on our coding style page should just be delete, or at least not enforced - by which I mean almost anything that can't be enforced by a tool (such as isort, flake8, editors via .editorconfig etc.), and has no non-local effects. (So consistent naming of classes/functions *should* be enforced, because that affects other people's ability to use the code).  Large parts of that page are just duplicating of flake8/isort rules anyway. Honestly, does it kill us if someone writes "we" in a code comment? And black couldn't help with some of these things anyway. Let's just stop being code review jerks.

I'm kind of ambivalent on black itself. Certainly there are cases where it makes code less readable (a significant sin in my book) e.g. lists that are better displayed vertically, as mentioned already, and there are cases where it makes your diff larger than it needs to be (e.g. when it decides a list is now too long and needs to be re-formatted vertically). If we adopt black we'd have to live with those annoyances. Alternatively, we can live with the annoyance that code formatting is not perfectly consistent and we accept less than 'perfect' PR. But we should just live with those things:


    A foolish consistency is the hobgoblin of little minds


And if our consistency requirements are causing problems for people attempting to contribute, they are foolish and should be dropped.

My 2 ¢.

Luke


On 18/04/2019 16:03, Jani Tiainen wrote:
Well let me add my two cents here since I was also in the group in DCEU that talked about the usage of black.

Personally I don't like to contribute to Django. And this is why:

Day one: I'll make the fix/patch and create PR
Day two (or four or five depending how busy reviewers are): I missed a comma or some minor indent is wrong
Day three: I fix styles
Day four: PR is accepted.

So whole round trip took about a five days (give a take few usually depending how busy reviewers are).

That gives me a feeling that I'm really wasting my time and since I can't get all the small bits and pieces exactly as Django wants in correct place.

And that's because we have slightly different rules at the work. And some other projects do have different rules.

So it would be great if some of this pain could be relieved with a tool. In my short experience with black (I've been using it for work projects) it does a pretty decent job.

Like others have said black does some decisions I don't agree with. But I don't have to. Black does it for a "greater good". And after a while black actually vanishes from the flow. 

On Sat, Apr 13, 2019 at 6:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.


--
Jani Tiainen
Software wizard


Always open for short term jobs or contracts to work with Django.
--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/d0ea7514-247a-90fa-e4cb-1c238b07ffc3%40cantab.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Tim Graham-2
I'm sorry for establishing some (foolish?) guidelines that discouraged some people from contributing. I didn't establish those guidelines merely to be pedantic, but perhaps I'm too much of a perfectionist at times.

After GitHub allowed mergers to amend pull requests, I often made cosmetic adjustments myself to eliminate the trivial back and forth that some have lamented. I never blocked a merge merely for trivial cosmetic reasons.

On Friday, April 19, 2019 at 3:25:24 AM UTC-4, Luke Plant wrote:

Hi all,

An alternative solution to the problem of nit-picky, formatting related PR reviews is simple: let's not do that.

We already have an automated code formatting enforcer, flake8. Let's simply drop the requirement on fixing anything that flake8 doesn't pick up. A committer can fix up style issues if they want to, but shouldn't make anyone else do it. This would mean most of the stuff on our <a href="https://docs.djangoproject.com/en/2.2/internals/contributing/writing-code/coding-style/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.2%2Finternals%2Fcontributing%2Fwriting-code%2Fcoding-style%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEx92U2XpK0hC2DYm_xyMKnCZzlvQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.2%2Finternals%2Fcontributing%2Fwriting-code%2Fcoding-style%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEx92U2XpK0hC2DYm_xyMKnCZzlvQ&#39;;return true;">coding style page should just be delete, or at least not enforced - by which I mean almost anything that can't be enforced by a tool (such as isort, flake8, editors via .editorconfig etc.), and has no non-local effects. (So consistent naming of classes/functions *should* be enforced, because that affects other people's ability to use the code).  Large parts of that page are just duplicating of flake8/isort rules anyway. Honestly, does it kill us if someone writes "we" in a code comment? And black couldn't help with some of these things anyway. Let's just stop being code review jerks.

I'm kind of ambivalent on black itself. Certainly there are cases where it makes code less readable (a significant sin in my book) e.g. lists that are better displayed vertically, as mentioned already, and there are cases where it makes your diff larger than it needs to be (e.g. when it decides a list is now too long and needs to be re-formatted vertically). If we adopt black we'd have to live with those annoyances. Alternatively, we can live with the annoyance that code formatting is not perfectly consistent and we accept less than 'perfect' PR. But we should just live with those things:


    A foolish consistency is the hobgoblin of little minds


And if our consistency requirements are causing problems for people attempting to contribute, they are foolish and should be dropped.

My 2 ¢.

Luke


On 18/04/2019 16:03, Jani Tiainen wrote:
Well let me add my two cents here since I was also in the group in DCEU that talked about the usage of black.

Personally I don't like to contribute to Django. And this is why:

Day one: I'll make the fix/patch and create PR
Day two (or four or five depending how busy reviewers are): I missed a comma or some minor indent is wrong
Day three: I fix styles
Day four: PR is accepted.

So whole round trip took about a five days (give a take few usually depending how busy reviewers are).

That gives me a feeling that I'm really wasting my time and since I can't get all the small bits and pieces exactly as Django wants in correct place.

And that's because we have slightly different rules at the work. And some other projects do have different rules.

So it would be great if some of this pain could be relieved with a tool. In my short experience with black (I've been using it for work projects) it does a pretty decent job.

Like others have said black does some decisions I don't agree with. But I don't have to. Black does it for a "greater good". And after a while black actually vanishes from the flow. 

On Sat, Apr 13, 2019 at 6:35 PM Herman S <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="gn4UfpZMBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">herman....@...> wrote:
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: <a href="https://github.com/hermansc/django/pull/1" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg_ctdhGBSbdZK3W4NXBAYv5TtMw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg_ctdhGBSbdZK3W4NXBAYv5TtMw&#39;;return true;">https://github.com/hermansc/django/pull/1
* Line length kept at 119: <a href="https://github.com/hermansc/django/pull/3" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGnhCGXsB5HJ8sSyIW9DS2rkVMraw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGnhCGXsB5HJ8sSyIW9DS2rkVMraw&#39;;return true;">https://github.com/hermansc/django/pull/3
* Line length kept at 119, no string normalization:
<a href="https://github.com/hermansc/django/pull/2" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFQNq-hc9geZY_3egU-27BkSAvBhQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFQNq-hc9geZY_3egU-27BkSAvBhQ&#39;;return true;">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]: <a href="https://github.com/ambv/black" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fambv%2Fblack\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrqVzKdISFdVR5lSsDnknmEceSew&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fambv%2Fblack\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrqVzKdISFdVR5lSsDnknmEceSew&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="gn4UfpZMBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="gn4UfpZMBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
Jani Tiainen
Software wizard

<a href="https://blog.jani.tiainen.cc/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fblog.jani.tiainen.cc%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHTEseRQOxS5qIoUn5nSrIsIG0Oeg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fblog.jani.tiainen.cc%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHTEseRQOxS5qIoUn5nSrIsIG0Oeg&#39;;return true;">https://blog.jani.tiainen.cc/

Always open for short term jobs or contracts to work with Django.
--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="gn4UfpZMBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="gn4UfpZMBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/06cf99d0-0521-4441-9252-86ef7f779039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Tobias McNulty
FWIW, I like that we have high standards for concise and readable comments with proper grammar, especially because I myself often need a little extra push in that department. And I'm not easily convinced by the arguments that sound a whole lot like "I've written the code and don't have time to clean this up." In the thick of the moment it's easy to assume a solution will be obvious to others reading the code, when in reality taking a few extra minutes to clearly write down why something is the way it is (not to mention making the code itself readable in the first place) will save potentially hours of someone else's time later on. This is precisely what code reviews are for; to make sure we're handing down well-written, described, and documented code for those who come after us (including perhaps ourselves, a year or two down the road). The benefit to us as contributors is that it makes us stronger developers, and I think that might get forgotten sometimes.

I've continued to follow along in this thread and remain fairly ambivalent about Black. I see how it will simplify many things; on the other hand, I like my multi-line lists formatted my way. (Not poking fun, I really do.) That said, if Black will truly remove some significant hurdles, let's do it, but we should remain clear-headed about the fact that it's not going to remove from the equation what some may feel is nitpicking and others would argue is a necessary part of maintaining our high standards.

Herman, if you haven't been scared away from this just yet, I might suggest trying to summarize the discussion and your recommendation/proposal given the reactions so far (could be a DEP but doesn't have to be, IMO). I do feel there's a pragmatic solution in here somewhere.

Best to all,
Tobias


Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com


On Fri, Apr 19, 2019 at 8:52 AM Tim Graham <[hidden email]> wrote:
I'm sorry for establishing some (foolish?) guidelines that discouraged some people from contributing. I didn't establish those guidelines merely to be pedantic, but perhaps I'm too much of a perfectionist at times.

After GitHub allowed mergers to amend pull requests, I often made cosmetic adjustments myself to eliminate the trivial back and forth that some have lamented. I never blocked a merge merely for trivial cosmetic reasons.

On Friday, April 19, 2019 at 3:25:24 AM UTC-4, Luke Plant wrote:

Hi all,

An alternative solution to the problem of nit-picky, formatting related PR reviews is simple: let's not do that.

We already have an automated code formatting enforcer, flake8. Let's simply drop the requirement on fixing anything that flake8 doesn't pick up. A committer can fix up style issues if they want to, but shouldn't make anyone else do it. This would mean most of the stuff on our coding style page should just be delete, or at least not enforced - by which I mean almost anything that can't be enforced by a tool (such as isort, flake8, editors via .editorconfig etc.), and has no non-local effects. (So consistent naming of classes/functions *should* be enforced, because that affects other people's ability to use the code).  Large parts of that page are just duplicating of flake8/isort rules anyway. Honestly, does it kill us if someone writes "we" in a code comment? And black couldn't help with some of these things anyway. Let's just stop being code review jerks.

I'm kind of ambivalent on black itself. Certainly there are cases where it makes code less readable (a significant sin in my book) e.g. lists that are better displayed vertically, as mentioned already, and there are cases where it makes your diff larger than it needs to be (e.g. when it decides a list is now too long and needs to be re-formatted vertically). If we adopt black we'd have to live with those annoyances. Alternatively, we can live with the annoyance that code formatting is not perfectly consistent and we accept less than 'perfect' PR. But we should just live with those things:


    A foolish consistency is the hobgoblin of little minds


And if our consistency requirements are causing problems for people attempting to contribute, they are foolish and should be dropped.

My 2 ¢.

Luke


On 18/04/2019 16:03, Jani Tiainen wrote:
Well let me add my two cents here since I was also in the group in DCEU that talked about the usage of black.

Personally I don't like to contribute to Django. And this is why:

Day one: I'll make the fix/patch and create PR
Day two (or four or five depending how busy reviewers are): I missed a comma or some minor indent is wrong
Day three: I fix styles
Day four: PR is accepted.

So whole round trip took about a five days (give a take few usually depending how busy reviewers are).

That gives me a feeling that I'm really wasting my time and since I can't get all the small bits and pieces exactly as Django wants in correct place.

And that's because we have slightly different rules at the work. And some other projects do have different rules.

So it would be great if some of this pain could be relieved with a tool. In my short experience with black (I've been using it for work projects) it does a pretty decent job.

Like others have said black does some decisions I don't agree with. But I don't have to. Black does it for a "greater good". And after a while black actually vanishes from the flow. 

On Sat, Apr 13, 2019 at 6:35 PM Herman S <[hidden email]> wrote:
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 [hidden email].
To post to this group, send email to [hidden email].
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.


--
Jani Tiainen
Software wizard


Always open for short term jobs or contracts to work with Django.
--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/06cf99d0-0521-4441-9252-86ef7f779039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAMGFDKSg1yN8NQD831N9_NNmmXxBab1gG1z3aijmsBiApu6H1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
123456