6 ms·

I'm pleased to announce that Black is finally non-beta software! :party:! Change log: https://black.readthedocs.io/en/latest/change_log.html https://black.rea

• scrollaway 5y ago
  Congratulations. I'm a Python developer of 17+ years and Black is truly a huge blessing in the Python ecosystem. That said, I'm a little sad to see it's gone stable without adding support for tabs, which would be extremely simple to add at this point (cf. https://github.com/jleclanche/tan/commit/e23c038167528bdacddd6779c6b4234e2634cfa3 https://github.com/jleclanche/tan/commit/e23c038167528bdacdd...). I have a lot of people using this tab-capable fork, that I did not advertise anywhere. Łukasz seems to have a personal grudge against tabs which may be why the issue for tab support was closed early on, but there's a plethora of good reasons to support it behind a flag. I don't want to rehash those arguments here on HN but you think you could re-think the approach a bit? I'd be happy to do a PR if it's not getting rejected right away with "no discussion allowed" like the last one was (before Black was moved to PSF maintainership).
  • deleted 5y ago
    [deleted]
  • wenc 5y ago
    I think one of the great benefits of Black is that it is opinionated. Giving folks the option to select the type of indentation blunts the benefits. If you have a huge code base which mixes tabs and spaces it’s going to be hard to diff and merge code (or even reuse code snippets).
    • scrollaway 5y ago
      The point of black is that you run it on the same codebase with the same parameters. Prettier works the exact same way and does have --use-tabs as a parameter. Nobody died. No codebase ended up with mixed tabs and spaces from it. Codebases either do --use-tabs or don't. Like I said, there are a lot of reasons to allow for this. For one thing, tabs are an accessibility feature, but also it's impossible to use Black in an environment that prefers tabs. Whereas there's no such thing as "an environment that prefers exactly two spaces after every comma inside tuples", thus you don't need an option for this.
      • xigoi 5y ago
        https://prettier.io/docs/en/option-philosophy.html https://prettier.io/docs/en/option-philosophy.html >Yet the more options Prettier has, the further from the above goal it gets. The debates over styles just turn into debates over which Prettier options to use. Formatting wars break out with renewed vigour: “Which option values are better? Why? Did we make the right choices?” >And it’s not the only cost options have. To learn more about their downsides, see the issue about resisting adding configuration, which has more s than any option request issue. >So why are there any options at all? >A few were added during Prettier’s infancy to make it take off at all. >A couple were added after “great demand.” >Some were added for compatibility reasons.
        • wldcordeiro 5y ago
          Reading this doc it feels like the Prettier team is saying options like tabs/spaces were only added early on to get initial adoption, if it were up to them now there would be far less options to configure at all.
          • xigoi 5y ago
            Yes, that's right.
          • scrollaway 5y ago
            The options in question are some of the more.. fancy ones, and the "history" in question is things such as cross-compatibility with ESLint. Certainly not "tab support". (And I've contributed to Prettier a great deal, FWIW)
  • wolrah 5y ago
    Unfortunately Black goes with PEP8, and PEP8 recommends spaces. Guido made this call arbitrarily years ago for absolutely nonsensical reasoning (basically came down to that some people use shitty editors that don't handle tabs reasonably) and the entire Python community has had to suffer since.
  • btown 5y ago
    On the contrary, I think it's fundamentally useful to the ecosystem that there be a winner in the tabs-vs-spaces/how-many-spaces debate. Code snippets become portable, developers don't need to adapt when joining a new team, etc. Indeed, https://www.python.org/dev/peps/pep-0008/#indentation https://www.python.org/dev/peps/pep-0008/#indentation has enshrined 4 spaces as the official recommendation. And when the best-in-class formatter enforces this, that's a good thing. To be sure, I personally would have preferred that 2-spaces win out for compatibility with the Javascript ecosystem (so I am perhaps the furthest from the parent poster on the tabs-spaces spectrum!) but I abandoned my preference in favor of PEP-8 years ago, and doing so has opened far more doors for team productivity than it's closed.
    • scrollaway 5y ago
      Environments that prefer tabs just use Tan, or otherwise, those environments just didn't use Black at all. It's not useful to the ecosystem because those projects not actually using Black and unable to make the switch end up in a worse scenario (hence the fork which at least fixes this). Nobody wins, here; at best, you're unaffected. Again I invite you to look at Prettier which has had as much of an impact (if not more) on the JS ecosystem as Black did on Python, but does support tab indent (and is opinionated regardless).
      • wldcordeiro 5y ago
        The Prettier team has gone on to say they regret giving people several of the configuration options they did though and have a page dedicated to their option philosophy. https://prettier.io/docs/en/option-philosophy.html https://prettier.io/docs/en/option-philosophy.html
        • scrollaway 5y ago
          Yes, you'll find no mention of regretting adding tab support to prettier on that page. Key quote: --arrow-parens, --jsx-single-quote, --bracket-same-line and --no-bracket-spacing are not the type of options we’re happy to have. That's because these are entirely stylistic choices. Tab support is a mechanical one. Worth mentioning as well that Prettier supports multiple languages and tab/spaces is a global option, whereas all of these are very language-specific.
  • js2 5y ago
    On the contrary, I want to thank the authors of black for not adding tab support. I’ve been writing Python code for two decades. I know all the arguments for tabs vs spaces. Down the path of tabs lies madness. If you want them that badly, please see git’s smudge/clean filters. https://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs https://stackoverflow.com/questions/2316677/can-git-automati... There. Now the Python world has a single standard while you are free to use tabs in your checkout. See, you can make all the people happy all the time. :-)
    • scrollaway 5y ago
      At the risk of repeating myself, I forked Black into Tan and just added --use-tabs. The alternative was "don't use Black". Others are in my situation as well and use Tan, somehow finding it despite it not being advertised anywhere. Hell I had people bugging me to update it a few weeks back. There's extremely clear demand, I didn't just add a random flag to control how much space should be around parentheses. Switching an existing codebase using tabs to spaces is not always feasible. That said, TIL about a lot of what's in your link, but it looks like a completely inappropriate solution, I think you can agree.
      • js2 5y ago
        I shared that link in good faith, not aware of your specific use case. I still think it's for the better that black does not allow tabs, and that your fork is a good solution for shops that need tabs for an existing code base. Black encourages the Python ecosystem to settle on spaces. There should be some friction involved (more than a switch) to use tabs, otherwise we're likely to see new code using tabs too. $0.02 and all that.
        • scrollaway 5y ago
          Sorry, I re-read my comment and noticed it sounds way more aggressive than I intended it to be! I love the little hack actually, but it looks like it's really just a hack ;)
  • gopjop 5y ago
    PEP-8 is the de-facto standard for python. Why would a formatter for python support anything (such as tabs) that deviates from that? There might be code that does not adhere to PEP-8, but to me this is not a justification, just some people distancing themselves from the python core community.
    • scrollaway 5y ago
      Have you read PEP8? :) Tab codebases are PEP8 compliant. It merely says spaces are "preferred". What it disallows is mixing the two. What it also says is to use tabs if the codebase uses tabs, which I can't do with Black; how about that. Incidentally, PEP8 takes a much stronger stance on line length, says they should be no more than 79 characters, and Black has enough sense not to respect that by default (and... offer an option, because line length, much like tabs for indent, is an accessibility feature).
  • oefrha 5y ago
    And I’m a little sad to see it’s gone stable without adding support for single quotes... Wait I’m not. As much as I dislike double quotes, if they add an option every time someone is a little sad, we’re just going back to square one. I don’t want to debate styles anymore, ever, and I’m willing to give up my own aesthetics for that.
    • smazga 5y ago
      Just means I can't use it for work, since it turns a 1 line change into a several hundred line commit (all our code has single quotes). These 'opinionated' formatters are great as long as you agree with the opinions they have. But the inflexibility makes them useless, otherwise.
      • LittlePeter 5y ago
        And one commit converting all single quotes to double quotes is not an option?
  • pdonis 5y ago
    > support for tabs Tabs are not PEP 8 compliant except for consistency with existing code: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces But if you're going to use a tool like Black in the first place, you're already committed to not preserving different formatting styles in existing code. You want to enforce one consistent style everywhere in the code base. And PEP 8 says that means no tabs. > a personal grudge against tabs I don't see why there would have to be any personal grudge given the above.
    • scrollaway 5y ago
      88 character lines are always pep8 non-compliant :)
      • batisteo 5y ago
        Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters.
        • scrollaway 5y ago
          I know. That’s my point. Religiously following pep8 is absurd.
  • sciyoshi 5y ago
    Congrats to the black team on this release, and thank you scrollaway for your fork. We are in a similar position where we are (for various reasons) stuck on using tabs for an existing project. Luckily it seems like there might be some movement on this front where the maintainer team is at least more receptive to reopening this conversation: https://github.com/psf/black/issues/2798 https://github.com/psf/black/issues/2798
  • jeffrallen 5y ago
    Dude, what part of "you can have it any color as long as it's black" did you NOT understand?
• darkerside 5y ago
  > The default style is updated yearly. I'm hoping there will be minimal or even zero style based commits, excepting those related to new Python features. It wouldn't be very Black-like to force a commit of a potentially enormous size on users of the library every year. Probably something you're already thinking about. I was apprehensive about taking our legacy codebase Black, but zero regrets. Thanks for your work!