How does this compare to yapf?
[deleted]
Black: An uncompromising Python code formatter
61–70 of 262 posts
Re: Black: An uncompromising Python code formatter
#62> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?
You are certainly not a minority in the discussion. Personally I hate repeating the same argument as it's a style question. I program in C# and dislike braces on new lines, I leave it in place because my company rolled out a standard and if I deviate from that I create more work for myself and others. Are you consistent with your formatting rules? I'd be interested to know how much time you spend formatting your code…
It takes me a lot longer to write the code than it does to format it for readability.
I'm inclined to think that the reason that auto-formatters are popular is not because manually formatting code is hard, but simply to head off nitpicking in code review.
I think there's a better solution to the "style nitpicking in code review" problem: Just don't do it.
If you're nitpicking style during a code review, chances are good that you are not looking for real problems.
Re: Black: An uncompromising Python code formatter
#63Earlier quoted context omitted.
I don't know :) I worked on prettier myself because I wanted to solve formatting for the language I was involved in. It turned out that the prettier infrastructure was actually really good for other languages so we used it for CSS, Markdown, GraphQL... and added support for a plugin system for other people to build printers for their own language. patrick91 (not working at Facebook) is working on a python formatter u…
> One interesting thing I realized is that communities are built around programming languages and it's really hard to influence another community from the outside. IMO, that point is worthy of a detailed blog post or conference talk, if you would be so inclined. Would love to hear more.
That's true, I'll consider it, in the meantime here are some thoughts.
When I started working on React Native, I thought that the most difficult thing would be to design a good set of APIs to make it easy to write mobile apps using React that felt good. This turned out to be the "easy part", we started the project wanting to solve this and having lots of good ideas on how to do it.
What turned out to be a lot harder was the fact that we were trying to use JavaScript from within iOS and Android ecosystems.
1) Those at the time were in different repos, how do you synchronize code between them?
2) The three ecosystems use a different set of tools for everything: IDE (xcode, intellij, sublime/atom/code/emacs), package manager (cocoapods, maven, npm), linters (eslint), build (how do you hook up with the play button in xcode?), profilers (can you display stack traces with the two languages calling each other?)...
3) Mixing and matching languages inside of a single project is hard because there are a lot of subtle different semantics (eg: javascript doesn't have int32 or int64). If you have type systems, they are incompatible (flow vs obj-c). So in practice you end up with a lot of boilerplate to talk between the two languages and it's a performance overhead.
There's also a social aspect where you invested so much learning an ecosystem that it becomes part of your identity. So you see someone wanting to bring another language as trying to attack you directly.
My mission since then has been trying to "break down the silos" and trying to build tools that can work with all those languages. It's not been easy :)
Re: Black: An uncompromising Python code formatter
#64Anyone know how I can get auto format on save to work in Vim with Black? I installed with Plug.
Figured it out:
`autocmd BufWritePre *.py Black`
Re: Black: An uncompromising Python code formatter
#65> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?
Why are you interested in minutiae? Esp that which has no functional impact and can be automated. People are into things like this pep8 etc because they don't want to waste another second of their lives thinking about formatting. Or, worse discussing, arguing, bikesheding, documenting, enforcing, teaching the new guy how we format "here". I'm sorry to sound snarky, but this is one of the things you slowly learn over…
The phrasing "minutiae" is unfortunate because it makes it sound like the exact formatting is a matter of taste or doesn't matter. In my experience, there are always corner cases where either tools like these produce bad results. "Bad" isn't just some aesthetic property, it can mean the difference between being able to absorb the meaning of a block of code in 10 seconds, versus having to spend a minute taking it all in. Across a large body of code, those paper cuts really add up.
Personally, the only code formatter I've ever been really comfortable using is clang-format. And the reason is that they really try hard to get the corner cases right. Black might be fine, but I've been burned many times with other tools and in general would be reluctant to trust a tool like this without seeing what it does in practice to a large code base.
Re: Black: An uncompromising Python code formatter
#66Earlier quoted context omitted.
Curious, why is this a bad thing? Also it seems like you can change it to a lower number if you want.
80 columns is very standard.
It was a standard from a time when we had green-screen terminals only capable of displaying an 80x24 grid of characters. (https://en.wikipedia.org/wiki/VT100)
It's worth asking - does the standard make sense still, given how we edit today?
Re: Black: An uncompromising Python code formatter
#67> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?
Why are you interested in minutiae? Esp that which has no functional impact and can be automated. People are into things like this pep8 etc because they don't want to waste another second of their lives thinking about formatting. Or, worse discussing, arguing, bikesheding, documenting, enforcing, teaching the new guy how we format "here". I'm sorry to sound snarky, but this is one of the things you slowly learn over…
around the same length of time developing. ... i still hand format; mostly because i think most auto-formatters have bad defaults. Which may no longer be true, since i turn off indent in vim immediately on any installation.
It isn't really interest in minutia -- My fingers just do the thing automatically at this point; which means if autoindent is on, I then have to go back and delete all the stuff my muscle memory has made me do.
I'm ok with it if i'm forced into some IDE with an editor that is not built for actually writing code (i.e. every IDE default editor); in those instances auto-formatting is very useful. I just avoid those environments, if at all possible.
Re: Black: An uncompromising Python code formatter
#68This is great except for the enforcement of double-quotes around all strings and spaces around slice operators. These two choices contradict the standard Python documentation, most of the standard library, and the behaviour of the interpreter itself.
When the language itself has an established convention, Black should follow that convention, not fight it. These two weird choices just generate needless churn, which is surprising as it seems Black has quite the opposite goal.
It's a shame, because all the other design choices in Black are pretty good!
Re: Black: An uncompromising Python code formatter
#69Earlier quoted context omitted.
Why are you interested in minutiae? Esp that which has no functional impact and can be automated. People are into things like this pep8 etc because they don't want to waste another second of their lives thinking about formatting. Or, worse discussing, arguing, bikesheding, documenting, enforcing, teaching the new guy how we format "here". I'm sorry to sound snarky, but this is one of the things you slowly learn over…
The phrasing "minutiae" is unfortunate because it makes it sound like the exact formatting is a matter of taste or doesn't matter. In my experience, there are always corner cases where either tools like these produce bad results. "Bad" isn't just some aesthetic property, it can mean the difference between being able to absorb the meaning of a block of code in 10 seconds, versus having to spend a minute taking it all…
For a large codebase that uses Black, you might want to look at PyPA/Warehouse or Fabric 2.
Re: Black: An uncompromising Python code formatter
#70Earlier quoted context omitted.
80 columns is very standard.
It was a standard from a time when we had green-screen terminals only capable of displaying an 80x24 grid of characters. ( https://en.wikipedia.org/wiki/VT100 ) It's worth asking - does the standard make sense still, given how we edit today?
Probably not, there is line wrap.