This is something discussed af length on the black issue tracker and not something the author wishes to change.
On Mon, 15 Apr 2019 at 4:47 pm, Dmitriy Sintsov <questpc...@gmail.com> wrote: > Why can't it use mixed quotes, single quotes for all strings except the > strings that contain single quote characters? I think mixed syntax of > strings is made in various programming languages so both single and double > quotes can be used inside strings not having to use ugly backslash > escaping. Maybe you or someone can create such feature request in black > repo? Why the people do not like mixed quotes strings and try to eliminate > such great feature? Aesthetical issues are very much biased and enforcing > these automatically is not always a good idea. Does the switching to double > quote string makes the code error prone and safer? Probably not. Just some > voluntary personal choice. > > > On Monday, April 15, 2019 at 2:02:49 AM UTC+3, charettes wrote: >> >> I was and and I'm still bugged by how black decided to go for double >> quotes instead of single ones. Even if it's backed some valid arguments it >> left all the projects following PEP 8's recommendations over the years with >> this git blaming loss trade off. From past experimentation with large'ish >> projects following PEP8's guideline string quotes changes represented well >> over 50% of the diff and there's no way to turn off only this form of >> string normalization, it's all or nothing. At $WORK we even went as far as >> forking the project to switch to use single quotes instead[0]. I understand >> requiring the use of a fork is not a feasible solution for Django but I >> just wished there was an option to stick to single quotes to reduce the >> cost of adoption for such projects without loosing all the other nifty >> string formatting goodies[1] /rant >> >> Even if I don't completely agree with black's formatting choices and the >> sometimes quite unnatural code it generates my past month's usage at work >> and the adoption of the project in the Python ecosystem that made it's way >> in most IDE makes me mostly share the same feeling as Aymeric; it's not >> always pretty but not having to think about it makes it worth it. I suggest >> we stick to disabling string normalization to reduce the noise generated by >> the migration though. >> >> Cheers, >> Simon >> >> [0] https://github.com/zapier/black/pull/1 >> [1] https://github.com/ambv/black#strings >> >> Le dimanche 14 avril 2019 09:40:10 UTC-4, Aymeric Augustin a écrit : >>> >>> Hello, >>> >>> I'm strongly in favor of adopting black with the default options. >>> >>> In my opinion, it's the first Python code formatter that passes the bar >>> of "on average, does better than any single programmer". Trying to enforce >>> something else manually is a waste of energy that produces worse results. >>> >>> I like nicely formatted code and I hate some of what black produces, >>> typically on Django model definitions. However, I've seen the benefits of >>> an automated code formatter, even on projects where I write almost all of >>> the code. >>> >>> I'm positive the benefits will be great on Django, where you can tell >>> when a module was (re)written just by looking at the style. Yes, there are >>> some downsides, but it's clearly a good tradeoff. >>> >>> Regarding the migration strategy, converting one package at a time >>> sounds good, because then we can proof-read the Big Diff and perhaps tweak >>> the code where the result really hurts the eyes. >>> >>> Most of Django's style guide will still applies, as it's mostly >>> conventions about naming things, ordering declarations, etc. >>> >>> Best regards, >>> >>> -- >>> Aymeric. >>> >>> >>> >>> On 13 Apr 2019, at 13:52, Herman S <herman....@gmail.com> 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 >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F1&sa=D&sntz=1&usg=AFQjCNHg_ctdhGBSbdZK3W4NXBAYv5TtMw> >>> * 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 >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fhermansc%2Fdjango%2Fpull%2F2&sa=D&sntz=1&usg=AFQjCNFQNq-hc9geZY_3egU-27BkSAvBhQ> >>> >>> Please have a look at the Black documentation. It explains the benefits >>> better >>> than I possibly could do here. >>> >>> With kind regards, >>> Herman Schistad >>> >>> [0]: https://github.com/ambv/black >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-d...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/21ef3344-673b-49af-9cbb-c17bb928ab0b%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/21ef3344-673b-49af-9cbb-c17bb928ab0b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-ykmWbnCdbnLcj%2B%2BEon5a9ny7W4-AyMAQMHOD%3DdFAMA%2BOoA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
