5 ms·

I thought the community standardized on black

• duckerude 7y ago
  black is opinionated. If you disagree with black's opinions then a negotiable formatter like YAPF might be better. I personally love black though.
  • bonzini 7y ago
    Black is opinionated enough that you will occasionally mumble about it, but good enough that you will keep using it anyway. That's a remarkable achievement for a formatter. For me it just took a little to get used to double-quoted strings. Rust's "cargo fmt" tool is similarly good.
    • gimboland 7y ago
      I hear you on the double-quoted strings; and that's why the only black configuration I allow myself, is "skip-string-normalization = true" in my pyproject.toml
    • strokirk 7y ago
      I'd say that black is way too opinionated, especially since it doesn't produce good output a lot of the time. At my company we consistently have to adjust the way we write code in order for black not to mangle it.
• aequitas 7y ago
  It doesn't really matter which standard you use imho, as long as you automate the tedious task of code formatting to arbitrary standards. If it's something the computer can do let it do it don't waste your time on it. This goes especially in pull requests where dedicated focus to trivial things like formatting often distracts from the real things that need review, like code architecture.
  • weberc2 7y ago
    It would be nice if things converted on a single standard, however.
    • aequitas 7y ago
      True, but the order of things will never allow this to happen, either the old standard lags behind, some people disagree on something (just look at the tabs vs spaces discussion) or some people just have inherently different personal preferences. Then there is always the eb and flow of of convergence and deviation. Thats why I've given up on pushing my preferred standard in a team and just enforce the rule that is must be automated so I don't have to spend time on it no matter which way the current standard wind blows.
• scrollaway 7y ago
  Black is just slightly too opinionated. It gives you configuration options for benign things such as numeric separators, but it flat out refuses to allow tab indent, which a fairly significant part of the python community uses. I tried to PR a --use-tabs flag but the PR was rejected without comments. Had to fork Black to be able to use it. Tan is a drop-in replacement that allows --use-tabs (and use-tabs = true in pyproject.toml). https://github.com/jleclanche/tan https://github.com/jleclanche/tan
  • jakear 7y ago
    Thats a shame, especially as I've heard tabs are more accessible: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/?utm_source=BD&utm_medium=Search&utm_name=Bing&utm_content=PSR1 https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
    • scrollaway 7y ago
      Precisely why I use them and why I'm uncomfortable with Black refusing to add the option (https://github.com/psf/black/pull/513 https://github.com/psf/black/pull/513).
      • patrec 7y ago
        This argument sounds quite bizarre to me. Why would a visually impaired programer not manage to set their editor up to show indenting spaces the way they want, or failing that, collaborate with others to do so? It's not like they can be effective at their job either without the ability to read 3rd party code, which overwhelmingly will be space indented.
        • j88439h84 7y ago
          How to set an editor to use big visual indents for spaces?
          • 7y ago
• mintplant 7y ago
  I disagree with a few of Black's decisions, so I forked it to Lavender [0], which I keep up to date with the latest stable Black release (and use actively in all my Python projects). > Differences from Black > - The default line length is 99 instead of 88 (configurable with --line-length). > - Single quoted strings are preferred (configurable with --string-normalization none/single/double). > - Empty lines between classes and defs are treated no differently from other code. The old behavior, which sometimes inserts double empty lines between them, remains available via --special-case-def-empty-lines. > - The Vim plugin configuration variable for line length is named g:lavender_line_length instead of g:lavender_linelength, for consistency with the other configuration variable names. [0] https://github.com/spinda/lavender https://github.com/spinda/lavender
  • akvadrako 7y ago
    Nice to hear. The single quote issue is the main thing that keeps me from using black. Double quotes are just too noisy.
    • jp_sc 7y ago
      Black can be configured to use single quotes. In fact, I think it's the only style configuration you can make.
      • akvadrako 7y ago
        Where do you see that? https://black.readthedocs.io/en/stable/the_black_code_style.html#strings https://black.readthedocs.io/en/stable/the_black_code_style....
        • 00ajcr 7y ago
          I think it's the `--skip-string-normalization` flag which means "Don't normalize string quotes or prefixes".
          • 7y ago