Re:Black, the uncompromising Python code formatter, is stable
by scrollaway on Saturday January 29, 2022 @07:55PM
(#30132440)
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.
Re:Black, the uncompromising Python code formatter, is stable
by js2 on Saturday January 29, 2022 @09:13PM
(#30133142)
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.
Re:Black, the uncompromising Python code formatter, is stable
by scrollaway on Saturday January 29, 2022 @09:23PM
(#30133212)
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 ;)
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-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. :-)