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, thinkwel...@gmail.com 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

Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

[Carlton Gibson]

On Wednesday, 24 April 2019 02:19:32 UTC+2, Hyogeun Kim wrote:
>
>
> PS: I tested on my Mac and I got this error message "UnicodeDecodeError: 
> 'ascii' codec can't decode byte 0xe2 in position 9735: illegal multibyte 
> sequence" and It works as well with version 1.11 and 2.1 on Mac
>

Yes. OK. It will depend on your system locale. There was an implicit 
assumption of something using UTF-8. Either way resolved in 2.2.1. 🙂

Please open a new ticket if something else comes up. 

Thanks! 
Carlton 

-- 
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/18392f8a-4a3a-4dd1-a24d-adece942ff22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Carlton Gibson]

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, thinkwel...@gmail.com 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 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/1d5de155-f957-4132-84f7-a19c69fb2cc0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A different approach for the auto-reloader

[Ramiro Morales]

Hi all,

I had a stab at a somewhat simpler development server automatic reloading
strategy
https://github.com/django/django/compare/master...ramiro:synch-reloader

Intention is to test how an implementation of a design by Gary Bernhardt
would look. The best written description I could find is this:

https://github.com/devlocker/tychus/issues/3

Gary also had posted some tweets (this is how I got interested in the
topic) which seems to have been deleted since then.

Main idea is: Actual checking of changes on the filesystem for modules
under monitoring isn't performed in a loop or by depending on a OS kernel
feature but per-HTTP request by a front-end proxy process which is in
charge of restarting the 'upstream' web server process (in our case a
dumbed-down runserver dev server) only when it detects there have been
changes.

Been meaning to try this for some time. It would have been much harder
before Tom Forbes' work on refactoring and cleaning up the reloading code
for Django 2.2. IMHO Tom's code is so very well thought that for example I
just had to lightly subclass StatReload to implement this totally different
strategy.

Current form of the code is a new experimental 'serverrun' (for lack of a
better name) added to the Django code base whose command line UI mimics
100% the runserver one.

It copies code from a few places of our code base: The runserver command,
the WSGI app hosting code, etc.

I decided to implement this as a new built-in command for now a) to ease
experimentation and b) because it needs some minor changes to the
'runserver' command to handle cosmetic details (logging). If the idea is
accepted (read further below for reasons in favor of this) then maybe we
can switch runserver to this code. Or if the idea isn't deemed appropate
for Django core them I might implement it as an standalone django
app/project.

If the idea of a smarter stat()-based FS status monitor like this gets
actually tested and validated in the field (i.e. by users with big source
code trees) it could allow us to possibly stop needing to depend on all of:

* watchman
* pyinotify
* watchdog
(and removing our support code for them from the Django code base).

Also, this would mean:

* Setup simplification for final users (no third party Python libraries or
system daemon to install)
* Better cross-platform portability for Django (we go back to piggy-backing
stat() from the stdlib as our only way yo trigger code reloading).

Additionally, as the reloading is performed fully (by restarting the whole
HTTP server) and is triggered from another process (the transparent http
proxy one) we can drop some contortions we currently need to make:

- Having to wait for the app registry stabilization
- Avoiding race conditions with the url resolver

I suspect there could be power efficiency advantages too as:

* The scanning for changes is triggered by HTTP requests which should be
less frequent than periodically every N seconds.
* If the developer modifies more than one file before switching to the
browser there is need of only one FS scan to cater for all these changes,
which is performed just in time for the first HTTP request so the code
executed to render/serve it is 100% accurate in regard to actually
reflecting the state of the code on disk.

Similar projects include:
- serveit: https://github.com/garybernhardt/serveit
- tychus: https://github.com/devlocker/tychus
- wsgiwatch: https://github.com/dpk/wsgiwatch

Feedback is welcome!

Regards,

-- 
Ramiro Morales
@ramiromorales

-- 
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/CAO7PdF99hUobeXs8JQyb%3DywDJ6bkkKWyhUYC%3DEa9JzwQM%2BH_5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

[Hyogeun Kim]

I think I have same problem like this 
https://code.djangoproject.com/ticket/30324, and I checked another Django 
version 1.11 and 2.1. and It works well.

thank you Carlton

PS: I tested on my Mac and I got this error message "UnicodeDecodeError: 
'ascii' codec can't decode byte 0xe2 in position 9735: illegal multibyte 
sequence" and It works as well with version 1.11 and 2.1 on Mac

2019년 4월 23일 화요일 오후 9시 57분 55초 UTC+9, Carlton Gibson 님의 말:
>
>
>
> On Tuesday, 23 April 2019 14:30:48 UTC+2, Carlton Gibson wrote:
>>
>>
>> What IS the right way of setting the locale on Windows...? 
>>
>
> Not sure if it's the only way but, on Windows 10 you can tick a "Use 
> Unicode UTF-8 for worldwide language support", box in "Region & Language" - 
> "Administrative" - "Change system locale" - "Region Settings".
>
> This has a "beta" label next to it... 
>
> After a reboot it adjusts `local.getpreferredencoding(False)` to 
> `cp65001`, which the internets tell me is UTF8, which is what you want I 
> think. 
>
> C.
>

-- 
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/07300625-f7af-49b6-99e9-8d930473507c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google "Season of Docs"

[Adam Johnson]

Sounds great, thanks for your work here Carlton.

On Mon, 22 Apr 2019 at 09:42, Carlton Gibson 
wrote:

> Quick update:
>
> I've applied Django for Season of Docs. Don't know if we're accepted yet
> but 🤞
>
> As per the timeline Technical Writer applications open May 29th.
>
> https://developers.google.com/season-of-docs/docs/timeline
>
> I put a wiki page here:
>
> https://code.djangoproject.com/wiki/2019SeasonOfDocs
>
> If you have specific project ideas please add them.
> (TBH: "Take on the tickets" is what I'd really like 🙂)
>
> If you'd like to mentor, assuming we get accepted etc, please let
> me/Mariusz know.
>
> Kind Regards,
>
> Carlton
>
> --
> 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/c4432dad-2054-45d9-94e3-d917b0801e32%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM1Z%3D-fTMxc7y%3Dt46%3DUMCDdsWon5%2BzFOnVGh1KEkn4Jf7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

[Carlton Gibson]

On Tuesday, 23 April 2019 14:30:48 UTC+2, Carlton Gibson wrote:
>
>
> What IS the right way of setting the locale on Windows...? 
>

Not sure if it's the only way but, on Windows 10 you can tick a "Use 
Unicode UTF-8 for worldwide language support", box in "Region & Language" - 
"Administrative" - "Change system locale" - "Region Settings".

This has a "beta" label next to it... 

After a reboot it adjusts `local.getpreferredencoding(False)` to `cp65001`, 
which the internets tell me is UTF8, which is what you want I think. 

C.

-- 
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/60421d6e-793a-49c1-b972-cb955382fd33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

[Carlton Gibson]

On Tuesday, 23 April 2019 14:27:24 UTC+2, Carlton Gibson wrote:
>
> If you set the `PYTHONIOENCODING` to utf8 before launching...
>

Not actually sure this is sufficient. What IS the right way of setting the 
locale on Windows...? 

-- 
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/634f2e7f-9e07-4630-89db-0c61cf82373a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

[Carlton Gibson]

This looks to be https://code.djangoproject.com/ticket/30324, which will be 
fixed by 2.2.1 next week. 
(Please open a new ticket with full details if it is distinct.) 

If you set the `PYTHONIOENCODING` to utf8 before launching Python you 
shouldn't this. (Or related unicode errors)

https://docs.python.org/3.7/using/cmdline.html#envvar-PYTHONIOENCODING

HTH
Carlton 

-- 
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/fb967656-c067-4c03-ac42-90e040507c15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: Allow ManyToMany using a intermediary table to be defined as symmetrical

[Nadège Michel]

Hello,
 
We use self.referencing ManyToMany relationships with intermediate tables 
in our work project 
and I was wondering why we had to create ourselves the reverse link when we 
need the relationship to be symmetrical.
I looked at the 'symmetrical' attribute documentation and though we should 
just set it to True instead of False, 
but you may know that it triggers the error "fields.E332 Many-to-many 
fields with intermediate tables must not be symmetrical.".

I searched for a corresponding existing ticket a found this one which is 
kind of related https://code.djangoproject.com/ticket/9475
And you can see in the PR some discussion about the check 
https://github.com/django/django/pull/8981#discussion_r247946460
Thanks to the work of Collin Anderson in the previous PR I think we can now 
remove that check.

Questions I had:

   - retro compatibility?

As the current behavior forces the user to set 'symmetrical=False', the 
change is retro-compatible.

   - use 'through_defaults' when creating both objects or define a new 
   'through_reverse_defaults' to give different values for each row? 

if you want symmetrical relationship, both objects should have the same 
values 
so I chose to use 'through_defaults' for both objects. Which was also what 
was done in the #8981 
 PR in 
the first place.

I have a patch 

 
with theses changes:

   - removed the check 
   - removed tests for that check
   - added tests (tests/m2m_through, tests/m2m_recursive)
   - updated documentation (may need a bit more work)
   - added back the use of 'through_defaults' of #8981 
    in 
   the:

if self.symmetrical:  
self  ._add_items(...) 

Tests suite runs fine.

Any thoughts on this design change / new feature?  
I'll be happy to create a ticket and submit my patch for reviews :) 

-- 
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/3e2f799d-3444-407b-bc81-523c3f55ec0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

UnicodeDecodeError: 'cp949' codec can't decode byte 0xe2 in position 9735: illegal multibyte sequence

[Hyogeun Kim]

Hi everyone

I got this error message "UnicodeDecodeError: 'cp949' codec can't decode 
byte 0xe2 in position 9735: illegal multibyte sequence" when I write some 
data on admin site with Django 2.2

This is simple database model like this

class Bookmark(models.Model):
url = models.URLField(max_length=500)
title = models.CharField(max_length=500)

-- 
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/ed4ecef3-b714-4be0-a000-c32a95aebe6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

[Mariusz Felisiak]

I'm fine with removing this check and merge PR11244 
 prepared by Matthias. Any 
concerns?

-- 
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/35482fdb-23c6-47d1-ae05-d74035c416f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Sam Cooke]

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,  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 a