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, [email protected] 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 >>>> <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 [email protected]. To post to this group, send email to [email protected]. 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.
