4 ms·

> oesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we'r

> oesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code This is fine with me--I think it makes sense to optimize for readability, and I can read a long vertical list of arguments a lot more readily than a long comma-delineated list. > spurious changes in commits - if you happen to indent a block, Black will cause lines to break Is this a generic argument against wrapping lines, or am I misunderstanding something? > Black fails at its most basic premise - "avoiding manual code formatting" - because a trailing comma causes a list/function call to be split over lines regardless of width I'm not following this either. If black automatically reformats your code over multiple lines, that doesn't suggest manual formatting. Maybe you're arguing that all code which produces a given AST should be formatted in the same way--this would be cool and I would agree, but black gets us 95% of the way there so to argue that it "fails" is to imply that "0%" and "<100%" are equivalent.

otherme123 5y ago
I also noticed we are in 2022, and my screen is so big I can have three or four files of 80'ish chars wide side to side. Specially with Django, where you usually need models.py, views.py, forms.py and a template open at the same time. With 120'ish lines, I lose one vertical split.
yawaramin 5y ago
> the default width should be at least 120 characters, I mean we're in 2022 after all Even in 2022, some people don't have wide external monitors, sometimes like to view two files (or a diff) side-by-side, or need to use GitHub/BitBucket/etc. code viewer pages. Also, it's still difficult for humans to read long lines.
- throwaway894345 5y ago
  Agreed. It's really nice to be able to have two files side-by-side (or a file plus a shell) without having tiny font. I still do the overwhelming majority of my work on a laptop--maybe I'd feel differently with one or more 27" 4K monitors, but even then I don't think a code formatter should make these kinds of assumptions.
- neamar 5y ago
  True, but we also have word wrap to deal with this automatically!
zmmmmm 5y ago
> This is fine with me--I think it makes sense to optimize for readability You cannot read things you can't see. If half a function is scrolled off the bottom of the screen because every function arg is on its own line .... its pretty annoying.

otherme123 5y ago

I also noticed we are in 2022, and my screen is so big I can have three or four files of 80'ish chars wide side to side. Specially with Django, where you usually need models.py, views.py, forms.py and a template open at the same time. With 120'ish lines, I lose one vertical split.

yawaramin 5y ago

> the default width should be at least 120 characters, I mean we're in 2022 after all Even in 2022, some people don't have wide external monitors, sometimes like to view two files (or a diff) side-by-side, or need to use GitHub/BitBucket/etc. code viewer pages. Also, it's still difficult for humans to read long lines.

throwaway894345 5y ago
Agreed. It's really nice to be able to have two files side-by-side (or a file plus a shell) without having tiny font. I still do the overwhelming majority of my work on a laptop--maybe I'd feel differently with one or more 27" 4K monitors, but even then I don't think a code formatter should make these kinds of assumptions.
neamar 5y ago
True, but we also have word wrap to deal with this automatically!

zmmmmm 5y ago

> This is fine with me--I think it makes sense to optimize for readability You cannot read things you can't see. If half a function is scrolled off the bottom of the screen because every function arg is on its own line .... its pretty annoying.