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 >> <https://www.google.com/url?q=https%3A%2F%2Fpep8.org%2F%23a-foolish-consistency-is-the-hobgoblin-of-little-minds&sa=D&sntz=1&usg=AFQjCNEySGgwf2j6XxUTgSju2qDS3z4zWw> >> >> >> 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/444c7f75-ddfd-4a56-ab23-bb70dd9d877b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
