17 ms·
Format Python Code Using YAPF
- zelly 7y agoI thought the community standardized on black
- duckerude 7y agoblack is opinionated. If you disagree with black's opinions then a negotiable formatter like YAPF might be better. I personally love black though.
- bonzini 7y agoBlack is opinionated enough that you will occasionally mumble about it, but good enough that you will keep using it anyway. That's a remarkable achievement for a formatter. For me it just took a little to get used to double-quoted strings. Rust's "cargo fmt" tool is similarly good.
- gimboland 7y agoI hear you on the double-quoted strings; and that's why the only black configuration I allow myself, is "skip-string-normalization = true" in my pyproject.toml
- strokirk 7y agoI'd say that black is way too opinionated, especially since it doesn't produce good output a lot of the time. At my company we consistently have to adjust the way we write code in order for black not to mangle it.
- aequitas 7y agoIt doesn't really matter which standard you use imho, as long as you automate the tedious task of code formatting to arbitrary standards. If it's something the computer can do let it do it don't waste your time on it. This goes especially in pull requests where dedicated focus to trivial things like formatting often distracts from the real things that need review, like code architecture.
- weberc2 7y agoIt would be nice if things converted on a single standard, however.
- aequitas 7y agoTrue, but the order of things will never allow this to happen, either the old standard lags behind, some people disagree on something (just look at the tabs vs spaces discussion) or some people just have inherently different personal preferences. Then there is always the eb and flow of of convergence and deviation. Thats why I've given up on pushing my preferred standard in a team and just enforce the rule that is must be automated so I don't have to spend time on it no matter which way the current standard wind blows.
- scrollaway 7y agoBlack is just slightly too opinionated. It gives you configuration options for benign things such as numeric separators, but it flat out refuses to allow tab indent, which a fairly significant part of the python community uses. I tried to PR a --use-tabs flag but the PR was rejected without comments. Had to fork Black to be able to use it. Tan is a drop-in replacement that allows --use-tabs (and use-tabs = true in pyproject.toml). https://github.com/jleclanche/tan https://github.com/jleclanche/tan
- jakear 7y agoThats a shame, especially as I've heard tabs are more accessible: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/?utm_source=BD&utm_medium=Search&utm_name=Bing&utm_content=PSR1 https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
- scrollaway 7y agoPrecisely why I use them and why I'm uncomfortable with Black refusing to add the option (https://github.com/psf/black/pull/513 https://github.com/psf/black/pull/513).
- patrec 7y agoThis argument sounds quite bizarre to me. Why would a visually impaired programer not manage to set their editor up to show indenting spaces the way they want, or failing that, collaborate with others to do so? It's not like they can be effective at their job either without the ability to read 3rd party code, which overwhelmingly will be space indented.
- j88439h84 7y agoHow to set an editor to use big visual indents for spaces?
- 7y ago
- mintplant 7y agoI disagree with a few of Black's decisions, so I forked it to Lavender [0], which I keep up to date with the latest stable Black release (and use actively in all my Python projects). > Differences from Black > - The default line length is 99 instead of 88 (configurable with --line-length). > - Single quoted strings are preferred (configurable with --string-normalization none/single/double). > - Empty lines between classes and defs are treated no differently from other code. The old behavior, which sometimes inserts double empty lines between them, remains available via --special-case-def-empty-lines. > - The Vim plugin configuration variable for line length is named g:lavender_line_length instead of g:lavender_linelength, for consistency with the other configuration variable names. [0] https://github.com/spinda/lavender https://github.com/spinda/lavender
- akvadrako 7y agoNice to hear. The single quote issue is the main thing that keeps me from using black. Double quotes are just too noisy.
- jp_sc 7y agoBlack can be configured to use single quotes. In fact, I think it's the only style configuration you can make.
- akvadrako 7y agoWhere do you see that? https://black.readthedocs.io/en/stable/the_black_code_style.html#strings https://black.readthedocs.io/en/stable/the_black_code_style....
- 00ajcr 7y agoI think it's the `--skip-string-normalization` flag which means "Don't normalize string quotes or prefixes".
- 7y ago
- fermigier 7y agoI've used Yapf for a year, then switched to Black when it appeared. Seriously, use Black. I my experience, and to my taste, it works perfectly all the time, and the result is beautiful. It's also pep8 compliant, for the parts of pep8 that are concerned by a reformatter.
- petters 7y agoFrom the experience in our code base, yapf produces higher-quality results, but is much slower. Black removes any additional parentheses added to enable a line split at a reasonable position (such as "and"). With those removed, black has to split at weird locations like at a function call. But switching to black just for the speed increase is reasonable.
- smitty1e 7y agoMy perfect formatter would be ridiculous to implement and maintain. Thus I "like" black's opinionated take. "I see some rude code and I want to paint it black, " -- Sir Mick Jagger, probably.
- lapink 7y agoBlack produces code with more lines than yapf. Sure sometimes yapf makes very weird decision (especially when using a dictionary litteral as an argument to a function) but at least it does not use 4 lines for a list with 2 items that could have fitted on one line.
- scrollaway 7y agoA somewhat-undocumented feature of black is that in recent versions, by giving the list a trailing comma, you're telling the indenter to always put it on multiple lines (eg `[1,2,]` will always wrap on 4 lines). If you remove the trailing comma to a multi-item list/dict/whatever, black will try to compact the literal to a single line (and if it fails because the line is too long, it will add the trailing comma back)
- weberc2 7y ago
- miguendes 7y agoI use black and couldn't be happier. Very fast and produces very readable code.
- hashhar 7y agoThe only successful formatter are ones who don't have any knobs to tune. The reason a formatter exists is to make all codebases look consistent, not to cater to your personal style. This is one area Golang got it right with gofmt.
- Lutzb 7y agoThis is the reason we switched to black for Python about a year ago. There are no options to tweak. At first I had to deal with a lot of complaining developers, but now everyone got accustomed to blacks formatting style and we moved on.
- londt8 7y agoIt has questionable default of 88 characters per line, which is configurable. I wish they chose 79 characters as PEP8 suggests.
- zzzeek 7y agoThat is one of the few things you can set, put it in your pyproject.toml, done. Oh you don't have a pyproject.toml? Well then we have a different problem :)
- kstrauser 7y agoSame. It looked weird at first, and everyone had specific complaints with it, but they were all different complaints. Now we all accept that it’s just what Python code looks like, and can stop thinking about it all.
- closed 7y ago> The reason a formatter exists is to make all codebases look consistent I'm not how this is related to not having any knobs to tune. Aren't there many ways for code to be consistent with pep8? Isn't advocating for only one version of pep8-consistent code in essence an attempt to supercede pep8?
- 7y ago
- danpalmer 7y agoA bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure. Black however could fall into this category of worse than no formatter. On my team we have a strong style guide with a lot of well-reasoned, detailed, and consistent rules. One of the main differences to other style guides is that we design our style to make review easier. One of the primary ways of doing this is minimising diff noise. While Black's vision is to reduce diff noise and design for easier review through a consistent style, it creates more diff noise and has a less consistent style than our style guide, and so we've had many discussions internally about whether it's right for us. I have no doubt that Black is better than weak/no style guide, and for open source projects the automation it brings would absolutely be the right choice. I just wish it was better at what it sets out to do. Edit: to address some of the questions raised: - Yes Black does save time over code review picking on style details, but we already have automated linters for most things we'd raise about style anyway, which negates some of the time saving. - The easiest example of where Black differs from our style guide and falls down on its promises is formatting lists/function calls/definitions. For example: foo = [bar, bar] When reaching the line length limit, we will turn this into: foo = [ bar, baz, quux, ] However Black will format this first as: foo = [ bar, baz, quux ] Only when it goes on a few more characters does it then format into the way we'd go straight to. This means that there's more diff noise more of the time, and when reading code there are 3 forms of this construction that one must be aware of, rather than the 2 forms that we have, meaning the code is less consistently formatted. This is picky, yes, but the point of Black is to be picky, and in a team where we can have a very good shared understanding of a style, and where we do already have that style, Black is much less convincing.
- jsmeaton 7y agoHave you got any specific examples of different rules/styles? Have you brought any of them up on the issue tracker? I’m a very big fan of black, and had disliked a few choices. But it’s saved our team literally dozens of hours of nit picking and style fixes. It’s so good to never have to critique style and just focus on function.
- 7y ago
- BiteCode_dev 7y agoI dislike a lot of black decisions and still use it for everything. My aesthetic taste is less important than getting things done. If you are not using it, stop arguing and nit picking about your preferences, we, as a community, have more important things to do. It will hurt only a little, I promise.
- ScoutOrgo 7y agoMy team has a handful of junior data scientists that really don't have a lot of experience of coding "well". Black was super helpful in 1, getting people used to decent coding format and 2, removing any effort or discussion around formatting in PRs. I added the formatting to pre-commit and the rest is effortless.
- tzs 7y agoSome editors or IDEs have pretty good automatic "formatting as you type" systems that can largely remove the need for stand-alone formatters for new code. Sometimes you can convince them to processes an existing file as if it is being typed in and so apply the "as you type" formatter, effectively giving you a stand-alone formatter. I used to do this with Emacs for C formatting. I don't remember how since I'm a vim user who only figured out enough Emacs for this one thing, and it was a long time ago, but I remember it worked very well. The Emacs C "as you type" formatter was very configurable and I was able to make it almost perfectly match my employer's style. How's Emacs "as you type" Python formatting?
- no_wizard 7y agoWe used YAPF[0] before we used Black[1] I really liked it, a lot. What set Black above is it is most of the decisions (if not all, really) makes is how we setup YAPF anyway. I do think it does some small things better, like reformatting function arguments in certain cases (as is highlighted elsewhere in this thread) If you need configurability, YAPF is the best choice, in my opinion. We still use isort though, because it sorts imports in a much more readable way. I just wish I could find a suitable replacement for C# development. StyleCop is okay, but I find we have to use `<NoWarn></NoWarn>` .csproj settings on so many little rules and it doesn't auto format (in as so far as I can tell). If your editor supports it, it will use it as a formatting source of truth, though. I just want something that also has a runnable console binary we can use in CI. Maybe I haven't looked at it closely enough. [0]https://github.com/google/yapf https://github.com/google/yapf [1]https://black.readthedocs.io/en/stable/ https://black.readthedocs.io/en/stable/