And in Stack Exchange's "The Workplace", people are complaining that their employees strongly object to Black https://workplace.stackexchange.com/questions/136742/virulen...
Someone is always going to complain.
Black – Uncompromising Python code formatter
41–50 of 251 posts
Re: Black – Uncompromising Python code formatter
#42Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…
It's a very valid point. If there is a universal format, it should not do things so rare. The above example should be easy to address, check if the method argument is a single dictionary or multiple.
Re: Black – Uncompromising Python code formatter
#43Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…
I completely agree that black does not format all examples in a nice manner, and your example is something I see pretty often. Whenever black adds too many indentation levels and line breaks in what should be a simple-enough statement, I simply refactor into multiple statements, e.g.
stems = {
apple.stem for satchel in satchels for apple in satchel
}
basket.add(stems)
Re: Black – Uncompromising Python code formatter
#44I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.
> Having a standard is more important than the standard being excellent.
Neither is very important, though. It's just formatting and your code will run the same regardless.
Re: Black – Uncompromising Python code formatter
#45We use Black in a pre-commit hook for all our python code. It makes legibility and formatting a non-issue in the team. Yes it can look strange at first if you're not used to it, but after a while it makes formatting invisible (and it's odd reading non-black python). Would recommend.
how do you do this? do you have a jenkins server running that does the formatting? i would love to set this up because while i use black religiously i cannot for the life of me convince my boss get in the habit of using it (which is crazy because your commits are always fighting on whitespace).
Black's README explains how to do it: https://github.com/python/black#version-control-integration
Re: Black – Uncompromising Python code formatter
#46Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…
I use it with f-strings all day long...
Re: Black – Uncompromising Python code formatter
#47Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…
While I agree that the formatting choice looks a little weird. The primary benefit of a formatter is that the formatting is always the same not. It's less important that it matches everyone's preferences and more important that it always formats the code the same way.
If most people dislike it on my team, we simply won't use it :(
Re: Black – Uncompromising Python code formatter
#48I've been using it for a few months now, but I don't really like it. It does remove quabbles about formatting, but I've personally never felt that as a problem and it just replaces them with constant frustration. I think code formatting is very important for readability, and I think many (subtle) choices about how to make a piece of code more readable are very subjective. These types of tools are just incapable to ma…
You could configure your IDE to re-format files into your favorite format and just have a pre-commit hook that formats them back into the official format. That's how I work. No arguments about style and formatting, yet I get to make the code look how I personally prefer it.
There is no such thing as "my favorite format" in that sense. Also, I don't mind reading code in other people's "favorite format" nor do I have any problem in following another person's style if that's the style agreed upon by the team.
Re: Black – Uncompromising Python code formatter
#49Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…
if the progress of prettier (js) over the past few years is any indicator of what will happen with black, there will likely be incremental improvements in black that address the poor formatting cases you’re concerned about. i remember when prettier first came out, i was not convinced until my “standard” for formatting was met. but it was met eventually.
Re: Black – Uncompromising Python code formatter
#50I started using black with one of my personal projects. Now I find myself wishing if was set up in every other python project I work on!