4 ms·

I have issues with some of Black’s formatting decisions but I’ve also suffered from inconsistent formatting and there is no question in my mind that consistent

I have issues with some of Black’s formatting decisions but I’ve also suffered from inconsistent formatting and there is no question in my mind that consistent formatting that I find ugly sometimes is 1000% better than the alternative. And after so many years of dealing with it it’s so refreshing to just “give up” and let the formatter win.

kstrauser 2y ago
Same here. I appreciate that Black annoyed everyone on our team about the same amount but in different ways. From the instant we added it, stupid style arguments completely disappeared. Know what I care about more than Black making my own code look less pretty? It making my coworker’s code look less horrid. (And funnily, I’m certain everyone on the team thinks exactly that same thing.)
- JimDabell 2y ago
  > I appreciate that Black annoyed everyone on our team about the same amount but in different ways. If it did affect people equally, it would be great. Unfortunately, spaces for indentation is an accessibility issue and the Black maintainers are hostile to making this configurable. Normally I am in agreement about minimising configurability, but this isn’t a matter of taste, it is making the Python ecosystem more difficult for some disabled people to participate in. https://github.com/psf/black/issues/2798 https://github.com/psf/black/issues/2798 Fortunately, Ruff makes this configurable, so you don’t have to choose between autoformatting and accessibility any more.
  - sunshowers 2y ago
    Thank you. I've heard this argument before and it seems to be a very strong one. I do have a question, though -- can accessibility tools infer tabs based on visual layout or some other mechanism? It seems like one option is for accessibility tools to transform code into tabs internally, which would make them instantly compatible with the vast majority of existing code that uses spaces. What are the practical barriers to making that happen? And is there a good article that discusses all this in a clear, even-handed fashion?

kstrauser 2y ago

Same here. I appreciate that Black annoyed everyone on our team about the same amount but in different ways. From the instant we added it, stupid style arguments completely disappeared. Know what I care about more than Black making my own code look less pretty? It making my coworker’s code look less horrid. (And funnily, I’m certain everyone on the team thinks exactly that same thing.)

JimDabell 2y ago
> I appreciate that Black annoyed everyone on our team about the same amount but in different ways. If it did affect people equally, it would be great. Unfortunately, spaces for indentation is an accessibility issue and the Black maintainers are hostile to making this configurable. Normally I am in agreement about minimising configurability, but this isn’t a matter of taste, it is making the Python ecosystem more difficult for some disabled people to participate in. https://github.com/psf/black/issues/2798 https://github.com/psf/black/issues/2798 Fortunately, Ruff makes this configurable, so you don’t have to choose between autoformatting and accessibility any more.
- sunshowers 2y ago
  Thank you. I've heard this argument before and it seems to be a very strong one. I do have a question, though -- can accessibility tools infer tabs based on visual layout or some other mechanism? It seems like one option is for accessibility tools to transform code into tabs internally, which would make them instantly compatible with the vast majority of existing code that uses spaces. What are the practical barriers to making that happen? And is there a good article that discusses all this in a clear, even-handed fashion?