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

Luke Plant-2

Hi Tim,

I didn't mean to imply the original decisions were foolish, in their context. Reading it again, my language in the email was too strong - it was directed at myself as much as anyone else, because I'm also the kind of person who loves getting everything consistent, often too much, and that wasn't clear. What I meant to say was that if it turns out that our guidelines are becoming a problem, we should drop them, or change how we regard them (e.g. as guidelines for those who want to go the extra mile, not as rules that will frustrate contributors).

Your work on the Django code base has been tireless and fantastic, and along with the other fellows I don't know what we'd do without you, sorry for not making that clear with my comments.

Thanks,

Luke


On 19/04/2019 15:51, Tim Graham 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 <a href="https://docs.djangoproject.com/en/2.2/internals/contributing/writing-code/coding-style/" target="_blank" rel="nofollow" onmousedown="this.href='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';return true;" onclick="this.href='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';return true;" moz-do-not-send="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='javascript:';return true;" onclick="this.href='javascript:';return true;" moz-do-not-send="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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg_ctdhGBSbdZK3W4NXBAYv5TtMw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg_ctdhGBSbdZK3W4NXBAYv5TtMw';return true;" moz-do-not-send="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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGnhCGXsB5HJ8sSyIW9DS2rkVMraw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGnhCGXsB5HJ8sSyIW9DS2rkVMraw';return true;" moz-do-not-send="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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFQNq-hc9geZY_3egU-27BkSAvBhQ';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFQNq-hc9geZY_3egU-27BkSAvBhQ';return true;" moz-do-not-send="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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fambv%2Fblack\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrqVzKdISFdVR5lSsDnknmEceSew';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fambv%2Fblack\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrqVzKdISFdVR5lSsDnknmEceSew';return true;" moz-do-not-send="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='javascript:';return true;" onclick="this.href='javascript:';return true;" moz-do-not-send="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='javascript:';return true;" onclick="this.href='javascript:';return true;" moz-do-not-send="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='https://groups.google.com/group/django-developers';return true;" onclick="this.href='https://groups.google.com/group/django-developers';return true;" moz-do-not-send="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='https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com';return true;" onclick="this.href='https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com';return true;" moz-do-not-send="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='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;" moz-do-not-send="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='https://www.google.com/url?q\x3dhttps%3A%2F%2Fblog.jani.tiainen.cc%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHTEseRQOxS5qIoUn5nSrIsIG0Oeg';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fblog.jani.tiainen.cc%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHTEseRQOxS5qIoUn5nSrIsIG0Oeg';return true;" moz-do-not-send="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='javascript:';return true;" onclick="this.href='javascript:';return true;" moz-do-not-send="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='javascript:';return true;" onclick="this.href='javascript:';return true;" moz-do-not-send="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='https://groups.google.com/group/django-developers';return true;" onclick="this.href='https://groups.google.com/group/django-developers';return true;" moz-do-not-send="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='https://groups.google.com/d/msgid/django-developers/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick="this.href='https://groups.google.com/d/msgid/django-developers/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" moz-do-not-send="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='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;" moz-do-not-send="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.

--
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/5f47f119-c76c-ab90-78af-dc38a7df7700%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

Claude Paroz
I must admit I'm rather pleased by Luke's proposal. Let's keep our current isort/flake8 checks and relax other policies (considering the committer can always minor edit patches, as Tim did in the past).

I'm always a bit suspicious of tools that decide the formatting for me.

Claude

--
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/dae569ab-371d-40d5-bf2e-2cd4f4d38ed6%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
I'm against adopting black to Django. I don't like style proposed by black (some of rules make code less readable) and in the same time I really enjoy Django's style, but that's of course my subjective opinion.

I don't think that our code style is any barrier for newcomers. Just like Tim I make a minor stylistic edits before merging patches (if necessary) and it is not really a big issue for me. I double-check all lines of patches so minor edits don't increase the time that I spend on PR. I want to clarify that adopting black will not immediately solve any tickets because we've never blocked any patch due to stylistic nitpicks. I also don't believe that it will increase the number of contributors, if I would like to contribute to any package it wouldn't matter to me.

IMO we should stay with isort, flake8 and hanging indentation (we don't have many extra rules). Of course I'm open for discussion about relaxing our code policy.

Best,
Mariusz

--
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/1fe71fd2-5c3c-4ad6-8e3b-f172f07aacaa%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

Jacob Rief
I share the opinion of Mariusz Felisiak, Luke Plant and Claude Paroz, and believe that it is a bad idea to do this in an automatic way without the possibility to interfere manually.
- Jacob

--
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/3195031d-e5e7-4a60-aa79-249010577a80%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

Carlton Gibson-3
In reply to this post by Mariusz Felisiak


On Friday, 19 April 2019 20:33:13 UTC+2, Mariusz Felisiak wrote:

I don't think that our code style is any barrier for newcomers. ...we've never blocked any patch due to stylistic nitpicks. I also don't believe that it will increase the number of contributors, if I would like to contribute to any package it wouldn't matter to me.

So, I've been out banging the drum for new contributors for a year or so now. I've had a number of personal reports that this just isn't true. 

Members of our community who want to contribute to Django are finding the review process off-putting. (They've used stronger language than that.) We have a host of people that have made a single contribution and never come back. 

"Wrap to 79 chars", or whatever, would be better gone. I'm not sure I like Black per se, but using an auto-formatter would enable review comments to focus on substantive points. ("Can we rephrase this slightly to more like....")  (From experience in Go and Elm lands, the community using a single formatter has great benefits. After a couple of week your brain gets used to the different style.) 

It's not a panacea. But we have a massive barrier to entry. We need to address that. Using an auto-formatter would be one step. 

--
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/f198ce19-eb91-4bdc-a4bf-323daca60134%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

Claude Paroz


Le samedi 20 avril 2019 09:11:24 UTC+2, Carlton Gibson a écrit :


On Friday, 19 April 2019 20:33:13 UTC+2, Mariusz Felisiak wrote:

I don't think that our code style is any barrier for newcomers. ...we've never blocked any patch due to stylistic nitpicks. I also don't believe that it will increase the number of contributors, if I would like to contribute to any package it wouldn't matter to me.

So, I've been out banging the drum for new contributors for a year or so now. I've had a number of personal reports that this just isn't true. 

Members of our community who want to contribute to Django are finding the review process off-putting. (They've used stronger language than that.) We have a host of people that have made a single contribution and never come back. 

"Wrap to 79 chars", or whatever, would be better gone. I'm not sure I like Black per se, but using an auto-formatter would enable review comments to focus on substantive points. ("Can we rephrase this slightly to more like....")  (From experience in Go and Elm lands, the community using a single formatter has great benefits. After a couple of week your brain gets used to the different style.) 

It's not a panacea. But we have a massive barrier to entry. We need to address that. Using an auto-formatter would be one step.

Sorry, but I cannot believe that the coding style is a hurdle in our review process. Most Python devs should already write mostly PEP-8 compliant code. Let me repeat what I already said in other threads: contributing to Django today is hard because:
1. The low-hanging fruits are gone and most tickets are now non-trivial to solve.
2. Our quality expectations are high (tests, docs, backwards compatibility) and I don't think we should sacrifice any of those requirements just to get more contributors.

I think that we are at a point where asking a single person to handle a ticket from writing code down to the final commit is becoming a too heavy task (at least for newcomers). In my opinion, we should find a way to better split the various tasks involved in solving a ticket among several contributors.

This should be the subject of another thread probably. It is somewhat related to this thread in the sense that if the syntax polishing is simply ignored at first and deported to a pre-commit step (I'm sure we'll find people willing to do that part), then this issue is moot. We could imagine for example that isort/flake8 patch checks are only run at final stages of a patch process.

Claude

--
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/72e62389-eb9a-4c28-beb1-2cfdf488f4e9%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

J. Pic
Just note that the coala python package ( https://coala.io ) seems to be the alternative to black that will let you make some compromises, might be worth considering as well.

--
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/CAC6Op18_ZPJS5pm%3DZ%2B%2B3z3O4NZJydEvF75v-FNkmhQw0xjThYw%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

Nick Sarbicki
I'm still quite strongly in support of black. I find it's very nice to read a codebase that has strong consistency (which is historically usually the work of pedantic but very necessary reviews).

It's even nicer to go between multiple codebases which are all consistent with each other. PEP8 and linters like flake8 go quite a long way in achieving this but black goes even further.

There will always be arguments about what standards to use, it's an unsolvable problem. Some people may think the current Django standards are perfect, some will prefer blacks defaults, even more will have their own preferences. I feel that it is arbitrary to make this a major point, it will never be agreed upon.

Consistency in the end is the most important thing (even PEP8 agrees there). If we can contribute towards a global consistency in the python community that would be wonderful. If black is the way the community is going for this, then that is where my vote is. Even moreso if it lowers the barrier to entry (I don't think anyone is saying it raises it?).


On Mon, 22 Apr 2019, 07:44 Jamesie Pic, <[hidden email]> wrote:
Just note that the coala python package ( https://coala.io ) seems to be the alternative to black that will let you make some compromises, might be worth considering as well.

--
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/CAC6Op18_ZPJS5pm%3DZ%2B%2B3z3O4NZJydEvF75v-FNkmhQw0xjThYw%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/CAGuvt92iP_Z0niqWw%3D3T0j-BtTL-pyNmrcHPwcE0hHqhQWyMyw%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

J. Pic
Thanks for sharing some of your insight.

On Mon, Apr 22, 2019 at 10:57 AM Nick Sarbicki <[hidden email]> wrote:
 Even moreso if it lowers the barrier to entry (I don't think anyone is saying it raises it?).

I'm just saying that if "As contributor, I can haz automatic code formatter to lower the barrier" is precisely the story you want to solve, then black may not be the only solution you want to consider deeply ;)

Have a great day ;)
 
--

--
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/CAC6Op1-SfcGf9-Uv-ere92i9%3DGG24s0qkC%2BY7_%3Dc08Zvaw8v2g%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

Melvyn Sopacua
In reply to this post by Nick Sarbicki
On maandag 22 april 2019 10:57:19 CEST Nick Sarbicki wrote:

> Consistency in the end is the most important thing (even PEP8 agrees
> there).

Not sure where you got that impression:
https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Pep8 clearly states consistency is less important then readability (it's the
first thing mentioned and mentioned repeatedly that you can use as an argument
to break consistency). And this is the primary advantage of black, since
readability is hard to quantify (and therefore lint or format) and I think
this is where black has succeeded (by breaking consistency where it is
needed).
I mostly follow the discussion with interest from the sidelines, but just
wanted to correct this consistency argument: if you want consistent code, go
with autopep8, it'll keep your lines consistent below 79 characters and quite
an unreadable mess.
--
Melvyn Sopacua


--
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/2221950.OaZvUuSznM%40fritzbook.
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

Nick Sarbicki

I'm just saying that if "As contributor, I can haz automatic code formatter to lower the barrier" is precisely the story you want to solve, then black may not be the only solution you want to consider deeply ;)


Jamie, sure, I wasn't responding directly to you about this, more to the general people arguing against blacks style choices. I would happily consider alternatives to black - although (without any formal research to back this claim) it does feel like black has the most community support.

My point is mostly that if there is a growing community consistency through black then I'd be hesitant to choose another tool that goes against this.

 
> Consistency in the end is the most important thing (even PEP8 agrees
> there).

Not sure where you got that impression:
<a href="https://www.google.com/url?q=https%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;">https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Pep8 clearly states consistency is less important then readability (it's the
first thing mentioned and mentioned repeatedly that you can use as an argument
to break consistency). And this is the primary advantage of black, since
readability is hard to quantify (and therefore lint or format) and I think
this is where black has succeeded (by breaking consistency where it is
needed).
I mostly follow the discussion with interest from the sidelines, but just
wanted to correct this consistency argument: if you want consistent code, go
with autopep8, it'll keep your lines consistent below 79 characters and quite
an unreadable mess.
--

Thanks for the correction Melvyn, you're right - aside from readability and backwards compatibility consistency is important.

I'd also note the irony of using PEP8 to argue for consistency with a tool that is (at least on line length) inconsistent with PEP8. Although I really don't want to start a debate on line length.

--
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/3041089f-97dd-405e-98ff-e19d53575e1c%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

thinkwelldesigns
I wonder if there's a middle ground between minimizing code churn and having a standardized formatter. Our team recently switched to yapf after carefully configuring a .style.yapf file that's included in the root directory of every new repo. Once that config file is done, the workflow for yapf vs an unconfigurable formatter is identical.


I experimented a bit with the following .style.yapf settings on the django codebase and think the output is as good as black's without some of the arbitrariness of string quotes:

[style]
based_on_style
= pep8
column_limit
=100
i18n_function_call
=['_']
blank_line_before_nested_class_or_def
=True
join_multiple_lines
=False
indent_dictionary_value
=False

coalesce_brackets
=True
dedent_closing_brackets
=True
align_closing_bracket_with_visual_indent
=False
space_between_ending_comma_and_closing_bracket
=False

split_complex_comprehension
=True
split_before_first_argument
=True
split_before_logical_operator
=False
split_before_bitwise_operator
=False
split_arguments_when_comma_terminated
=True
split_before_expression_after_opening_paren
=True
split_before_named_assigns
=True


Yapf currently has more stars than black, but whether black has more momentum or not, who can say.


On Monday, April 22, 2019 at 10:14:44 AM UTC-4, Nick Sarbicki wrote:

I'm just saying that if "As contributor, I can haz automatic code formatter to lower the barrier" is precisely the story you want to solve, then black may not be the only solution you want to consider deeply ;)


Jamie, sure, I wasn't responding directly to you about this, more to the general people arguing against blacks style choices. I would happily consider alternatives to black - although (without any formal research to back this claim) it does feel like black has the most community support.

My point is mostly that if there is a growing community consistency through black then I'd be hesitant to choose another tool that goes against this.

 
> Consistency in the end is the most important thing (even PEP8 agrees
> there).

Not sure where you got that impression:
<a href="https://www.google.com/url?q=https%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;">https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Pep8 clearly states consistency is less important then readability (it's the
first thing mentioned and mentioned repeatedly that you can use as an argument
to break consistency). And this is the primary advantage of black, since
readability is hard to quantify (and therefore lint or format) and I think
this is where black has succeeded (by breaking consistency where it is
needed).
I mostly follow the discussion with interest from the sidelines, but just
wanted to correct this consistency argument: if you want consistent code, go
with autopep8, it'll keep your lines consistent below 79 characters and quite
an unreadable mess.
--

Thanks for the correction Melvyn, you're right - aside from readability and backwards compatibility consistency is important.

I'd also note the irony of using PEP8 to argue for consistency with a tool that is (at least on line length) inconsistent with PEP8. Although I really don't want to start a debate on line length.

--
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/444c7f75-ddfd-4a56-ab23-bb70dd9d877b%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

sdcooke
On projects I've been working on I started using "prettier" fro JavaScript and it made a huge difference to code consistency across the team, which was great, but my favourite benefit (that I'm not sure I've seen mentioned much here) is I can write code faster if I don't have to format it. Being able to just type without worrying about it, then hit save and it jumps into place, means if I'm working on files without automatic formatters I now feel like I'm doing a machine's job tidying things up.

Having said that - whilst I use black on all of my python projects, it's not had anywhere near as much of a positive impact as prettier has on JavaScript because:
 - python is generally more readable and consistent naturally than JavaScript
 - significant whitespace in python means you still spend time manually formatting code so you save less time than with JavaScript
 - I've found black to be unreliable - it silently fails on quite a few of my files
 - prettier is smarter about allowing you to add whitespace to make things like lists more readable, but black is 100% fixed in its ways

The best thing about automatic formatters, in my opinion, is even if you don't like the style at least you don't have to talk about it any more! And you tend to get used to it eventually.

On Mon, 22 Apr 2019 at 19:10, <[hidden email]> wrote:
I wonder if there's a middle ground between minimizing code churn and having a standardized formatter. Our team recently switched to yapf after carefully configuring a .style.yapf file that's included in the root directory of every new repo. Once that config file is done, the workflow for yapf vs an unconfigurable formatter is identical.


I experimented a bit with the following .style.yapf settings on the django codebase and think the output is as good as black's without some of the arbitrariness of string quotes:

[style]
based_on_style
= pep8
column_limit
=100
i18n_function_call
=['_']
blank_line_before_nested_class_or_def
=True
join_multiple_lines
=False
indent_dictionary_value
=False

coalesce_brackets
=True
dedent_closing_brackets
=True
align_closing_bracket_with_visual_indent
=False
space_between_ending_comma_and_closing_bracket
=False

split_complex_comprehension
=True
split_before_first_argument
=True
split_before_logical_operator
=False
split_before_bitwise_operator
=False
split_arguments_when_comma_terminated
=True
split_before_expression_after_opening_paren
=True
split_before_named_assigns
=True


Yapf currently has more stars than black, but whether black has more momentum or not, who can say.


On Monday, April 22, 2019 at 10:14:44 AM UTC-4, Nick Sarbicki wrote:

I'm just saying that if "As contributor, I can haz automatic code formatter to lower the barrier" is precisely the story you want to solve, then black may not be the only solution you want to consider deeply ;)


Jamie, sure, I wasn't responding directly to you about this, more to the general people arguing against blacks style choices. I would happily consider alternatives to black - although (without any formal research to back this claim) it does feel like black has the most community support.

My point is mostly that if there is a growing community consistency through black then I'd be hesitant to choose another tool that goes against this.

 
> Consistency in the end is the most important thing (even PEP8 agrees
> there).

Not sure where you got that impression:
https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Pep8 clearly states consistency is less important then readability (it's the
first thing mentioned and mentioned repeatedly that you can use as an argument
to break consistency). And this is the primary advantage of black, since
readability is hard to quantify (and therefore lint or format) and I think
this is where black has succeeded (by breaking consistency where it is
needed).
I mostly follow the discussion with interest from the sidelines, but just
wanted to correct this consistency argument: if you want consistent code, go
with autopep8, it'll keep your lines consistent below 79 characters and quite
an unreadable mess.
--

Thanks for the correction Melvyn, you're right - aside from readability and backwards compatibility consistency is important.

I'd also note the irony of using PEP8 to argue for consistency with a tool that is (at least on line length) inconsistent with PEP8. Although I really don't want to start a debate on line length.

--
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/444c7f75-ddfd-4a56-ab23-bb70dd9d877b%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/CAMyx3A3LoAtWAA503ooq779TABQPRre1nTwGhC6vX%3DF-3oXUwA%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

Carlton Gibson-3
In reply to this post by thinkwelldesigns
Thanks for the YAPF suggestion (and sample config!) I'll have a go with this this week. 
(If we can get auto-formatting, just on diffs(?), that matches the existing style...)

On Monday, 22 April 2019 20:10:41 UTC+2, [hidden email] wrote:
I wonder if there's a middle ground between minimizing code churn and having a standardized formatter. Our team recently switched to yapf after carefully configuring a .style.yapf file that's included in the root directory of every new repo. Once that config file is done, the workflow for yapf vs an unconfigurable formatter is identical.


I experimented a bit with the following .style.yapf settings on the django codebase and think the output is as good as black's without some of the arbitrariness of string quotes:

[style]
based_on_style
= pep8
column_limit
=100
i18n_function_call
=['_']
blank_line_before_nested_class_or_def
=True
join_multiple_lines
=False
indent_dictionary_value
=False

coalesce_brackets
=True
dedent_closing_brackets
=True
align_closing_bracket_with_visual_indent
=False
space_between_ending_comma_and_closing_bracket
=False

split_complex_comprehension
=True
split_before_first_argument
=True
split_before_logical_operator
=False
split_before_bitwise_operator
=False
split_arguments_when_comma_terminated
=True
split_before_expression_after_opening_paren
=True
split_before_named_assigns
=True


Yapf currently has more stars than black, but whether black has more momentum or not, who can say.


On Monday, April 22, 2019 at 10:14:44 AM UTC-4, Nick Sarbicki wrote:

I'm just saying that if "As contributor, I can haz automatic code formatter to lower the barrier" is precisely the story you want to solve, then black may not be the only solution you want to consider deeply ;)


Jamie, sure, I wasn't responding directly to you about this, more to the general people arguing against blacks style choices. I would happily consider alternatives to black - although (without any formal research to back this claim) it does feel like black has the most community support.

My point is mostly that if there is a growing community consistency through black then I'd be hesitant to choose another tool that goes against this.

 
> Consistency in the end is the most important thing (even PEP8 agrees
> there).

Not sure where you got that impression:
<a href="https://www.google.com/url?q=https%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;">https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Pep8 clearly states consistency is less important then readability (it's the
first thing mentioned and mentioned repeatedly that you can use as an argument
to break consistency). And this is the primary advantage of black, since
readability is hard to quantify (and therefore lint or format) and I think
this is where black has succeeded (by breaking consistency where it is
needed).
I mostly follow the discussion with interest from the sidelines, but just
wanted to correct this consistency argument: if you want consistent code, go
with autopep8, it'll keep your lines consistent below 79 characters and quite
an unreadable mess.
--

Thanks for the correction Melvyn, you're right - aside from readability and backwards compatibility consistency is important.

I'd also note the irony of using PEP8 to argue for consistency with a tool that is (at least on line length) inconsistent with PEP8. Although I really don't want to start a debate on line length.

--
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/1d5de155-f957-4132-84f7-a19c69fb2cc0%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

Josh Smeaton
FWIW, I'd be opposed to YAPF at all, but especially over Black. The community (that is, large projects that aren't Django) are standardising around Black - a single unambiguous format style. Having a slightly different format to everybody else I see as backwards. Contributors would also likely need to maintain two installations - one for Django, and one for (nearly) everything else. I'm probably being a little dramatic here with regards to the reach Black currently has, but there are many projects using it successfully.

There are also the problems with YAPF as described by Łukasz (black author) himself: https://news.ycombinator.com/item?id=17155205

Copied from link above:

- YAPF would at times not produce deterministic formatting (formatting the same file the second time with no changes in between would create a different formatting); Black treats this as a bug;

- YAPF would not format all files that use the latest Python 3.6 features (we have a lot of f-strings, there's cases of async generators, complex unpacking in collections and function calls, and so on); Black solves that;

- YAPF is based on a sophisticated algorithm that unwinds the line and applies "penalty points" for things that the user configured they don't like to see. With a bit of dynamic programming magic it arrives at a formatting with the minimal penalty value. This works fine most of the time. When it doesn't, and surprised people ask you to explain, you don't really know why. You might be able to suggest changing the penalty point value of a particular decision from, say, 47 to 48. It might help with this particular situation... but break five others in different places of the codebase.


I'm unsure how relevant all of these points still are. For me, I was never able to get YAPF to play nice, or get widespread agreement on a set of rules that all devs were OK with (lots of bikeshedding).

On Wednesday, 24 April 2019 16:35:57 UTC+10, Carlton Gibson wrote:
Thanks for the YAPF suggestion (and sample config!) I'll have a go with this this week. 
(If we can get auto-formatting, just on diffs(?), that matches the existing style...)

On Monday, 22 April 2019 20:10:41 UTC+2, [hidden email] wrote:
I wonder if there's a middle ground between minimizing code churn and having a standardized formatter. Our team recently switched to yapf after carefully configuring a .style.yapf file that's included in the root directory of every new repo. Once that config file is done, the workflow for yapf vs an unconfigurable formatter is identical.


I experimented a bit with the following .style.yapf settings on the django codebase and think the output is as good as black's without some of the arbitrariness of string quotes:

[style]
based_on_style
= pep8
column_limit
=100
i18n_function_call
=['_']
blank_line_before_nested_class_or_def
=True
join_multiple_lines
=False
indent_dictionary_value
=False

coalesce_brackets
=True
dedent_closing_brackets
=True
align_closing_bracket_with_visual_indent
=False
space_between_ending_comma_and_closing_bracket
=False

split_complex_comprehension
=True
split_before_first_argument
=True
split_before_logical_operator
=False
split_before_bitwise_operator
=False
split_arguments_when_comma_terminated
=True
split_before_expression_after_opening_paren
=True
split_before_named_assigns
=True


Yapf currently has more stars than black, but whether black has more momentum or not, who can say.


On Monday, April 22, 2019 at 10:14:44 AM UTC-4, Nick Sarbicki wrote:

I'm just saying that if "As contributor, I can haz automatic code formatter to lower the barrier" is precisely the story you want to solve, then black may not be the only solution you want to consider deeply ;)


Jamie, sure, I wasn't responding directly to you about this, more to the general people arguing against blacks style choices. I would happily consider alternatives to black - although (without any formal research to back this claim) it does feel like black has the most community support.

My point is mostly that if there is a growing community consistency through black then I'd be hesitant to choose another tool that goes against this.

 
> Consistency in the end is the most important thing (even PEP8 agrees
> there).

Not sure where you got that impression:
<a href="https://www.google.com/url?q=https%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw&#39;;return true;">https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Pep8 clearly states consistency is less important then readability (it's the
first thing mentioned and mentioned repeatedly that you can use as an argument
to break consistency). And this is the primary advantage of black, since
readability is hard to quantify (and therefore lint or format) and I think
this is where black has succeeded (by breaking consistency where it is
needed).
I mostly follow the discussion with interest from the sidelines, but just
wanted to correct this consistency argument: if you want consistent code, go
with autopep8, it'll keep your lines consistent below 79 characters and quite
an unreadable mess.
--

Thanks for the correction Melvyn, you're right - aside from readability and backwards compatibility consistency is important.

I'd also note the irony of using PEP8 to argue for consistency with a tool that is (at least on line length) inconsistent with PEP8. Although I really don't want to start a debate on line length.

--
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/a68c6e86-f99d-4518-a3c1-e5bb86409a06%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

Carlton Gibson-3
On Wednesday, 24 April 2019 08:58:57 UTC+2, Josh Smeaton wrote:
lots of bikeshedding

Yeah. 🙂 

But we've already got a style guide, so **IF** we can get a YAPF config to work to that then hopefully the arguments against using a formatter here would be moot. (Note that **IF** — I only said I'd have a play.) 

Equally, **IF** it's true that the Python community is standardising around black then, we should join in. But I get the impression that's not a done deal yet. 

I'm not fussed on the code style. The brain/eye adapts. As I said before, I would like us to have an auto formatter of some kind. 

--
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/1f79a79f-3aee-4bc2-90f8-55274e56c0d5%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

Matthias Kestenholz-7
On Wed, Apr 24, 2019 at 9:06 AM Carlton Gibson <[hidden email]> wrote:
On Wednesday, 24 April 2019 08:58:57 UTC+2, Josh Smeaton wrote:
lots of bikeshedding

Yeah. 🙂 

But we've already got a style guide, so **IF** we can get a YAPF config to work to that then hopefully the arguments against using a formatter here would be moot. (Note that **IF** — I only said I'd have a play.) 

Equally, **IF** it's true that the Python community is standardising around black then, we should join in. But I get the impression that's not a done deal yet. 

I'm not fussed on the code style. The brain/eye adapts. As I said before, I would like us to have an auto formatter of some kind. 

It's maybe not fair to count all channels-related repositories individually, but when I take a look at the code repositories in the Django organization on Github I see either repositories using only flake8/isort or repositories using black. One could say that the Django organization already is moving towards standardizing on black...

The arguments against a particular code style will never stop. In this case it's a big advantage to choose a tool developed by others which does not allow any bikeshedding.

I can see why one would want to wait on others to choose a standard tool for the Python community. On the other hand, Django could easily help establish the "obvious way to do it" given its visibility.

--
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/CANvPqgAzG3YUhOKD4003WF0PwXJ3xKUEAhJYfr-%2BoHuGE8C00w%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

René Fleschenberg
Hi

> The arguments against a particular code style will never stop. In this
> case it's a big advantage to choose a tool developed by others which
> does not allow any bikeshedding.
>
Will black really stop the arguments (which are not bikeshedding, IMO --
readability counts)? Or will they just be replaced by arguments over
when to use ``# fmt: off``?

--
Rene

--
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/954d583a-8dd4-bc83-dad0-a95b165d5546%40fleschenberg.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

Josh Smeaton
Black does not support disabling formatting by block with a comment. It removes all choice except for the upfront choices of length and string normalisation. 

On Wed, 24 Apr 2019 at 20:22, Rene Fleschenberg <[hidden email]> wrote:
Hi

> The arguments against a particular code style will never stop. In this
> case it's a big advantage to choose a tool developed by others which
> does not allow any bikeshedding.
>
Will black really stop the arguments (which are not bikeshedding, IMO --
readability counts)? Or will they just be replaced by arguments over
when to use ``# fmt: off``?

--
Rene

--
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/954d583a-8dd4-bc83-dad0-a95b165d5546%40fleschenberg.net.
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/CAPbDM0ehKKHiznK%2BsGzH%3DddrLDTcrHZUJChpYVHHE-K32RRgNA%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

Florian Apolloner

On Wednesday, April 24, 2019 at 1:25:55 PM UTC+2, Josh Smeaton wrote:
Black does not support disabling formatting by block with a comment. It removes all choice except for the upfront choices of length and string normalisation. 

It does, "# fmt: off" and "# fmt: on" can be used

--
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/237eb4ea-72b5-4ba0-a484-ad545d46479c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
123456