[HN Gopher] Black, the uncompromising Python code formatter, is ...
___________________________________________________________________
Black, the uncompromising Python code formatter, is stable
Author : crlees
Score : 211 points
Date : 2022-01-29 20:53 UTC (2 hours ago)
(HTM) web link (pypi.org)
(TXT) w3m dump (pypi.org)
| robertlagrant wrote:
| Here's the best thing about Black:
|
| Python has significant whitespace, so you can't just click
| "ignore whitespace changes" in Github diffs and it doesn't
| matter. You have to put up with every silly whitespace change.
|
| Until Black.
| robertlagrant wrote:
| 5 upvotes generate a pro tip: have your CI run black --check
| against the code you want formatted. That way different devs
| can run the formatting how they like (in tox; in a pre-commit
| hook; in IDE; on the command line) and CI just enforces that it
| _happened_.
| topper-123 wrote:
| > Black is opinionated so you don't have to be.
|
| This is a very nice quote and sums up my own view on black (and
| code formatters in general) nicely. Thera are things you don't
| really want to have an opinion about.
| vogre wrote:
| I think every language should have such tool by default, like Go
| does.
| _tom_ wrote:
| Long ago, I worked at a company that decided it needed coding
| standards. We spend two weeks arguing about coding standards.
| Nothing else got done.
|
| Ever since then, I am not opinionated about coding standards. The
| benefits do not match the costs.
|
| Although I do like the approach of "use something like black on
| precommit", and if you don't like it, you can reformat to your
| standards on check out, and be happy. It will get fixed on check
| in.
| voidfunc wrote:
| Sort of why I think Go got it right with gofmt. Its not as
| strict as it could be but all Go looks more or less the same
| and it's because it was built into the language
| colechristensen wrote:
| Too many people have too strong opinions on the subject. Some
| things are reasonably good ideas, many more are just arbitrary,
| strict rules prevent doing reasonable exceptions, and an
| enormous amount of time is wasted discussing the matter.
| _3u10 wrote:
| its the penultimate bike shedding issue.
|
| If you're coders can code it doesn't matter, and if they
| can't formatting their poor code isn't going to fix it.
| colechristensen wrote:
| Just an off topic note on language: penultimate means
| second to (last, final, biggest, etc), i.e. the one before
| the ultimate. Perhaps an odd choice of word in context that
| is often misunderstood.
|
| It leads to the question "then what is the ultimate bike
| shedding issue?"
| keithasaurus wrote:
| To me, the point of using code formatters is that you don't
| have to think/talk about code formatting much at all. As in,
| there are never annoying comments about formatting in PRs.
|
| A nice bonus is that you end up having uniformly readable code.
| dgellow wrote:
| Yep, just agree on something, whatever it is, enforce it
| everywhere and move on. It's not worth the time arguing. I love
| gofmt for this.
| surfmike wrote:
| Arguing over coding standards is harmful, but consistency is a
| good thing. Best to adopt a standard style guide and limit any
| debate to deviations and even better to have a tool like Black
| make it automatic.
| danielvaughn wrote:
| Yep. Even if I personally hate a coding style, I'll stick to
| it religiously if it's what my team uses. A good coding style
| is one that everyone adheres to.
| ForHackernews wrote:
| Still ugly. I hate looking at code mangled by this thing. Single
| quotes? Fluent interfaces? Go write Go if you want ugly code you
| don't have to think about.
|
| Don't @ me.
| throwaway894345 wrote:
| Pretty sure Black prefers double quotes in the main case, but
| what are "fluent interfaces"? Go is pretty great though, I
| completely understand the envy! :)
| JacobHenner wrote:
| https://en.wikipedia.org/wiki/Fluent_interface
| throwaway894345 wrote:
| Does Black inhibit method chaining? In any case, I don't
| see the value in fluent interfaces--if I had to choose
| between an opinionated code formatter and something people
| do because Martin Fowler told them to do it, I would take
| the former every time.
| cdcarter wrote:
| Sure, but why would black make those hard? (It doesn't, in
| my experience).
| captainmuon wrote:
| Personally, I don't understand the appeal of opinionated code
| formatters. If you don't want to discuss "taste" questions, then
| just don't, it doesn't matter what option you pick. If it is an
| important question, then you _should_ debate it.
|
| I think you can convey meaning with subtle code style
| differences. Empty lines to delineate blocks. Single quotes if
| the string is a keyword, double quotes if it is for the user.
| Spaces around operators to make an expression clearer. I spend a
| minute or two before I commit to make the code tidy (linter and
| then manual tweaking) and would expect that from everybody on my
| team - it takes often less time than rebasing and picking good
| commit names, for example.
|
| But even though it annoys me slightly when I encounter Black (or
| god forbid, Go) used in a project, I know a lot of people like it
| a lot, and it is good to have the choice. So congrats to the
| release! :-)
| onphonenow wrote:
| The reason I like black is the most opinonated folks have WEIRD
| opinions.
|
| You see that here.
|
| Things like a = [ 1, 2, 3 ] when 90% of the world is a = [1, 2,
| 3]
|
| These folks will spend hours / days try to force weird
| approaches.
|
| Sometimes they are obviously wrong. But it's annoying to have
| to fight over it. Something like black saves you the hassle and
| the WEIRD local coding rules someone comes up with if you are
| on a project with them.
| throwaway894345 wrote:
| I can stop discussing taste issues, but it doesn't prevent
| others from debating what the proper style for my PR ought to
| be, meanwhile I can't merge my PR.
| Shacklz wrote:
| > I think you can convey meaning with subtle code style
| differences.
|
| Yes that's very true, but, and now comes the big but - if
| you're working in a project with dozens and dozens of other
| devs, you will necessarily see all kinds of weird formatting.
| And this is where an opinionated formatter shines. It doesn't
| matter how many people work on your project, what the churn-
| rate is or if the guy that just started yesterday already read
| the code-formatting guidelines or not - the formatter will just
| take care of it and remove all hassles surrounding that topic.
| And this only at the price of opinionated formatting which I
| may or may not like - a price that I likely have to pay either
| way, because there's no way that everybody shares the same
| opinion about formatting in the first place.
|
| I recommend to give opinionated formatters a try, if you
| haven't already. I know plenty of folks who were initially
| against it but eventually came around it because it made life a
| lot easier: No more discussions about formatting on PRs, no
| more tabs vs space wars, everything's already settled and
| automatically taken care of.
| ferdowsi wrote:
| > If you don't want to discuss "taste" questions, then just
| don't, it doesn't matter what option you pick. If it is an
| important question, then you should debate it.
|
| I'm personally glad to see Python development come to the same
| conclusion enforced by Go's opinionated tooling.
|
| That is: style questions are almost always unimportant to
| producing value, but teams still waste excessive time on them
| because of the engineering tendency to bikeshed triviata.
| mumblemumble wrote:
| I think the general consensus of many people, myself included,
| is that it doesn't matter what the specifics are, as long as
| they're being applied consistently. Beyond that, it's a
| question of optimizing the cost/benefit ratio.
|
| The problem with most things that have to be applied manually
| is that they're also applied inconsistently. It's like
| Hungarian notation. Over time, it becomes pure noise: you can't
| rely on it, especially when reading someone else's code, so
| it's safer to just ignore it. At which point, the convention's
| cost/benefit is approaching infinity, because its denominator
| nearly zero. So I'm not sure I care if the absolute cost is
| small. It's still an almost complete waste of effort.
|
| The only place I've ever seen manual conventions applied
| consistently enough to be useful in a sustainable way is when
| someone's carved out their own private silo of code that is
| mostly only touched by them.
| monsieurbanana wrote:
| > If you don't want to discuss "taste" questions, then just
| don't, it doesn't matter what option you pick.
|
| Exactly, it doesn't matter what option you pick, _as long as
| everybody picks the same option_. Enter opinionated code
| formatters, because otherwise how do you do it?
| colechristensen wrote:
| > otherwise how do you do it?
|
| Only reject obviously quite messy code, and only rarely allow
| formatting rewrites. Learn that anybody's strong preferences
| for a specific style or discussion of such aren't
| demonstrably beneficial for the bottom line of the business
| or customers.
| dragonwriter wrote:
| > Personally, I don't understand the appeal of opinionated code
| formatters.
|
| Opinionated code formatters mean that opinionated coders with
| different preferences on a team don't produce (or at least
| produce less) noise in diffs.
| erik_seaberg wrote:
| I only reformat code I am rewriting, for that reason. I've
| never seen a tool that was very good at bending its own rules
| to minimize these accidental changes.
| Closi wrote:
| > Personally, I don't understand the appeal of opinionated code
| formatters. If you don't want to discuss "taste" questions,
| then just don't, it doesn't matter what option you pick.
|
| I think the appeal is that it _avoids the discussions entirely_
| (i.e. if it doesn 't matter what option you pick, why even have
| the option? Particularly if these options will mean you divert
| away from the standard python style guide, which has been
| trying to standardize these choices for years so that codebases
| have similar rules.)
|
| i.e. if your org has inconsistent python formatting between
| different independently-operating teams, it's easier to enforce
| PEP 8 than start a load of pointless arguments about what good
| looks like.
| MrPowers wrote:
| I like Black for normal Python code, but it seems to mangle
| Pandas / Dask code at times. I still use it extensively cause it
| doesn't seem like there are other good alternatives.
|
| I wrote a blog post on how to use Black in Jupyter Lab notebooks
| if anyone is interested: https://coiled.io/blog/code-formatting-
| jupyter-notebooks-wit...
|
| It's really nice to format a notebook with the click of a button.
| iddan wrote:
| This is exciting! Can it now be a plug-in for Prettier?
| sergiotapia wrote:
| Huge milestone for the Python community! Very happy for you guys.
| In Elixir, `mix format` has saved so much time across multiple
| projects and teams. I can't remember the last time I talked about
| line breaks and how to divvy up a long multiple line function
| header.
| formerly_proven wrote:
| > Black prefers [i.e. converts] double quotes (" and """) over
| single quotes (' and ''').
|
| Can someone explain this to me? Why would you ever prefer " over
| ' in a language where both can be used equally?
| HALtheWise wrote:
| Additionally, standardizing all quotes makes searching for a
| specific string literal across a codebase easier, since you
| don't need regex to match against both quote types. Once you've
| decided to standardize strings, it doesn't matter much which
| one you pick.
|
| Personally, I still type single quotes in almost all cases, and
| just let Black reformat to double quotes to save shift key
| presses.
| mixmastamyk wrote:
| Try nero from PyPI instead, I'll upgrade to stable shortly.
| rirze wrote:
| Last commit was from 2019? It sounds like you're not
| automating the patch for every black release...
| floober wrote:
| Uniformity, presumably
| odiroot wrote:
| I prefer them too. Makes it easy to notice than single ones.
| It's just a personal preference, there's no big logic behind
| it.
| Teongot wrote:
| Because "don't" is easier to read than 'don\'t'
| shpx wrote:
| Black will use single quotes if your string contains double
| quotes and no single quotes. It'll reformat
| print("\"Hello\" he said")
|
| to print('"Hello" he said')
|
| I think pretty much all formatters for languages that let you
| use either quote do this. It makes sense.
| JackFr wrote:
| When you're embedding SQL in a string, a you use ' a lot more
| than ". Not the only use case, but one to give some
| consideration.
| throwaway894345 wrote:
| I think that's only MySQL. Postgres uses double quotes for
| identifiers and single quotes for literals.
|
| EDIT: I misinterpreted that single quote as a backtick. In
| any case, both single and double quotes are common in SQL,
| but single quotes are a bit more common.
| iqanq wrote:
| And 'do not' is easier to read than both :)
| breput wrote:
| A couple of possible reasons:
|
| * Double quotes are more visible, especially for triple quotes.
|
| * It makes it easier to have text without having to manually
| escape apostrophes.
| teddyh wrote:
| Because _most_ commonly used languages use double quotes, not
| single quotes, for string literals. Some languages can use
| both, either interchangeably or with slightly different
| semantics, but others either uses single quotes for other
| purposes, or do not use them for anything at all. Therefore,
| double quotes for strings look more normal, so to speak, in
| source code.
| tsimionescu wrote:
| Except that in the language you're most likely to mix with
| Python, SQL, strings are in single quotes (double quotes are
| for identifiers like column names, especially if they're case
| sensitive). So it's probably a bad choice on Black's part.
| drekipus wrote:
| It's a tic for me too, as I always prefer '.
|
| But to be fair I think it's because 1. Double quotes are
| ""universally"" strings in other languages 2. Having
| apostrophes gets annoying.
|
| The great benefit really is that I _can_ write single word
| strings just fine, and black will adjust it for me. I get my
| cake, and so do the others.
| ambivalence wrote:
| This was decided very early in the project, the discussion can
| be read here: https://github.com/psf/black/issues/51
| formerly_proven wrote:
| Did you lock that issue before posting it here? Is this some
| kind of sore/forbidden topic for the project?
|
| Edit: I suppose the question is superfluous seeing how many
| replies there are just here.
| ambivalence wrote:
| Yes, and yes. Edit: and yes.
| wging wrote:
| Also documented more permanently here: https://black.readthed
| ocs.io/en/latest/the_black_code_style/...
| nopenopenopeno wrote:
| It's easier and faster to differentiate between " and ` than
| between ' and `.
| indymike wrote:
| This is simple: the default is picked, so now no one has to
| argue about it.
| TameAntelope wrote:
| Arguing over Black formatting choices is a little ironic, isn't
| it?
|
| The whole point is that they're all arbitrary so just let the
| defaults win, and adjust yourself instead.
| kstrauser wrote:
| That was the thing that bugged me at first, but other people on
| my team loved it. Some things bugged other people on my team,
| even though I love them. If a tool can manage to annoy everyone
| about the same amount, but in different areas, it's doing
| something right.
|
| And while it's still kind of strange that `a = "foo"` looks
| different than `repr(a)`, after a while of using Black I don't
| notice it anymore.
| faangiq wrote:
| In some languages single vs double has different functionality.
| nu11ptr wrote:
| I don't always like Black's results, but I do like the
| opinionated nature in general and that I don't have to sit and
| think about how I want it configured. Wouldn't mind a few knobs
| though.
| throwawayt215 wrote:
| Hooray!
|
| Loosely related - This is Python pip. Trail of Bits has a tool
| pip-audit that audits Python environments and dependency trees
| for known vulnerabilities.
|
| https://github.com/trailofbits/pip-audit
| woodruffw wrote:
| Not that I don't appreciate the shoutout (I'm one of the
| developers of pip-audit), but what's the connection? Is it
| because black is installed via pip?
| throwawayt215 wrote:
| Yeah. Thanks for pip-audit
| hivacruz wrote:
| This is a great tool. I wish there was some settings to use
| single quotes instead of double quotes.
| nopenopenopeno wrote:
| There probably is, if you use another formatter that isn't
| Black.
| xapata wrote:
| I like yapf.
| crlees wrote:
| There is: -S, --skip-string-normalization Don't normalize
| string quotes or prefixes.
| hivacruz wrote:
| IIRC, the -S only avoid single quotes to get switched to
| double quotes. What I meant was allowing Black to switch
| double-quotes to single quotes automatically.
| mixmastamyk wrote:
| Try nero from PyPI instead, I'll update it to this stable
| release shortly.
| j1elo wrote:
| Funny that this is a common reaction against opinionated tools:
| " _I wish there was a configurable option to apply my opinions_
| "
|
| But the whole idea is that you should learn to suppress your
| ego and let the tool be the one dictating stylistic choices...
|
| Like the sibling comment mentions:
|
| _Dusty Phillips, writer:_
|
| " _Black is opinionated so you don't have to be._ "
| ForHackernews wrote:
| "My opinion is the correct one"
|
| - Author of some tool
| throwaway894345 wrote:
| "No opinion is correct, so we should stop wasting time
| debating it."
|
| - advocates of code formatters
| hivacruz wrote:
| I understand that. And this is what I like in Black. But the
| single quotes thing is really up to debate. When you use it
| with other tools such as flake8 or pylint, you have to
| disable a bunch of things to make them work together because
| no one agrees on this point.
| historyforsale wrote:
| > When you use it with other tools such as flake8 or
| pylint, you have to disable a bunch of things to make them
| work together
|
| Using Flake8 with Black requires only two configuration
| options [1], while Pylint requires three [2]. If you prefer
| to use Black with --line-length 79, then it's down to a
| single configuration option for Flake8 or two for Pylint.
|
| [1]: https://black.readthedocs.io/en/latest/guides/using_bl
| ack_wi...
|
| [2]: https://black.readthedocs.io/en/latest/guides/using_bl
| ack_wi...
| j1elo wrote:
| I'm not a full time Python dev so I won't (can't) get into
| what choice has more merits. But there is this:
|
| https://black.readthedocs.io/en/latest/the_black_code_style
| /...
|
| Seen from outside, I think the double quotes are just the
| natural form of strings in lots of other places, at least
| in those that come from the same family than C (C++, Java,
| C#, Rust, just to name a few)
|
| Also Prettier.js (which I'd call the "Black of JavaScript")
| also settled on double quotes. So we're left with a _de
| facto_ consensus across programming languages as a whole,
| which kind of feels nice.
| _tom_ wrote:
| That made me wonder, so I went and tested edge cases, like
| "abc\"d\"ef", which black quite properly converts to
| 'abc"d"ef'. So it does use single quotes where appropriate.
| EddieLomax wrote:
| It's now enabled by default in IPython, for better or worse:
| https://github.com/ipython/ipython/pull/13397
| ccordoba12 wrote:
| That will be reverted in the next version, i.e. it'll be
| optional.
| teddyh wrote:
| "the next release will likely revert it"
|
| -- Matthias Bussonnier,
| https://github.com/ipython/ipython/issues/13463#issuecomment...
| kzrdude wrote:
| Great, I'm sure it will end up with a good solution
| eventually. Unfortunate that it had to be this heated about
| this change.
|
| R. Hettinger needed to learn to always be graceful when
| commenting or criticizing the work of others, especially
| volunteers.
|
| And we all saw how wild the difference is in engagement for a
| project like ipython between the "normal" level and the
| "viral" level. Users are just using it and depending on it,
| never interacting with the project, but if something attracts
| attention it can be like a thousand flies flocking to it.
| Often when something gets negative attention..
| crlees wrote:
| I'm pleased to announce that Black is finally non-beta software!
| :party:!
|
| Change log:
| https://black.readthedocs.io/en/latest/change_log.html
|
| Going forward we'll follow our stability policy (https://black.re
| adthedocs.io/en/latest/the_black_code_style/...).
|
| Work continues as usual with bugfixes and enhancements, but style
| changes are now introduced under our new `--preview` CLI switch.
| This allows us to evolve Black's style without too much
| disruption to users that want consistency. The default style is
| updated yearly.
|
| Thanks to our maintainers for orchestrating the efforts,
| especially to our most recent reinforcement Batuhan
| (@isidentical) who was responsible for our match statement
| support! A hearty thank you to all of our contributors for
| pushing Black forward, and to our users for being the reason we
| do it!
| scrollaway wrote:
| Congratulations. I'm a Python developer of 17+ years and Black
| is truly a huge blessing in the Python ecosystem.
|
| That said, I'm a little sad to see it's gone stable without
| adding support for tabs, which would be extremely simple to add
| at this point (cf. https://github.com/jleclanche/tan/commit/e23
| c038167528bdacdd...). I have a lot of people using this tab-
| capable fork, that I did not advertise anywhere.
|
| Lukasz seems to have a personal grudge against tabs which may
| be why the issue for tab support was closed early on, but
| there's a plethora of good reasons to support it behind a flag.
| I don't want to rehash those arguments here on HN but you think
| you could re-think the approach a bit?
|
| I'd be happy to do a PR if it's not getting rejected right away
| with "no discussion allowed" like the last one was (before
| Black was moved to PSF maintainership).
| [deleted]
| gbarboza wrote:
| is it just me, or does the logo look _really_ similar to the ford
| logo?
| scrollaway wrote:
| It's meant to, as it references Henry Ford's "any color so long
| as it is black" quip.
| jreese wrote:
| Shameless self-promotion, as a former coworker of Lukasz, Black's
| creator:
|
| Another coworker and I have created an import sorter that fits
| well alongside Black, called usort. It is designed from the
| ground up to be a safe, stable import sorter that won't move
| imports in ways that potentially change behavior of the codebase,
| and without needing developers to litter their code with "skip"
| directives. We use it in our daily formatting codemods on tens of
| thousands of source files every day, and just finished our 1.0
| release in December.
|
| https://usort.readthedocs.io
|
| Going further, if you like enforcing both formatting and import
| order in your CI pipeline, I also created the project ufmt, which
| combines both Black and usort into a single, atomic formatting
| step. This ensures there's never any conflict of opinion between
| the two tools, and any formatting changes are presented as a
| single diff result.
|
| https://ufmt.readthedocs.io
| chrisseaton wrote:
| > that won't move imports in ways that potentially change
| behavior of the codebase
|
| How can that be the case? Can't Python imports have behaviour
| that varies on the time of the day if they want?
|
| An import could monkey patch a basic operation one day but not
| the next.
| stefan_ wrote:
| Even better, you can overwrite the default importer to
| substitute your own with any behavior you want. Used in EVE
| Online to do their "hide the python code somewhere" scheme.
| jreese wrote:
| Absolutely! We're hoping that the vast majority of modules
| are good citizens, but we also know that the reality not
| perfect. That's why usort allows you to configure a list of
| modules with known import-time side effects, and usort will
| then treat those are barriers everywhere.
|
| https://usort.readthedocs.io/en/stable/guide.html#side-
| effec...
| [deleted]
| wcdolphin wrote:
| Interesting. Now that isort has support for black-
| compatibility, what's the main difference with usort?
| jreese wrote:
| We've written a number of words on "Why usort", including a
| comparison to isort:
| https://usort.readthedocs.io/en/stable/why.html
|
| The biggest reason is usort's detection of sortable "blocks"
| of imports, and only sorting within those blocks to limit
| breaking changes, combined with use of proper parsing and CST
| manipulation to guarantee valid syntax after sorting.
| stdbrouw wrote:
| FWIW, there's one particular use case where the isort
| behavior is incredibly useful: in eval-as-you-type data
| science e.g. when using Hydrogen in Atom you type an import
| whenever you need it but that leads to a lot of duplication
| and imports scattered across the file, and it's nice that
| isort just moves that up top on every save.
| jreese wrote:
| That's something we're aware of, and something we've
| considered, but also potentially dangerous from a safety
| standpoint, due to Python's dynamic nature, and how much
| moving imports can affect runtime semantics. Any
| implementation of this would need to be aware of those
| dangers, and also be able to provide stable and
| predictable behavior. At the moment, it's not a huge
| priority given the availability of tooling to
| automatically add missing imports, or the limited impact
| of under-sorting in the context of notebooks.
| wcdolphin wrote:
| Very cool. I love the idea of one tool rather than two,
| I'll check it out!
| nopenopenopeno wrote:
| Thought I'd never see the day lol
| Mockapapella wrote:
| Fuck I love Black -- makes working with other developers amazing
| once you stick it in a precommit. The quote from Dusty Phillips
| on the homepage is perfect and has stuck with me for years. I
| don't have to debate with developers about their individual
| preferences over what's best because we can just use Black and be
| done with it.
| Alex3917 wrote:
| The problem I have with it is that, to me, these are super
| readable: x = [ 1, 2, 3 ] y = { 'a':
| 1, 'b': 2 }
|
| Whereas these are not: x = [1, 2, 3]
| y = {'a': 1, 'b': 2}
|
| To me, declaring inline lists and dicts without the leading and
| trailing space makes it more difficult to see what the data
| structure is, and what it contains. This is especially true
| when you have lists or dicts declared inline as arguments to
| functions, e.g.: my_function_call([ 1, 2, 3
| ])
|
| versus: my_function_call([1, 2, 3])
|
| While it's generally not good style to declare data structures
| inside function calls, at least with the space it's still
| somewhat apparent what's happening, whereas without the space
| it just looks like three positional arguments. I love the idea
| of black, but in practice I'm not going to use something that
| changes my own code into something that's more difficult for me
| to read.
| spiderice wrote:
| My only response to this would be "get used to it".
|
| I used to think 2 space tabs made code harder to read than 4.
| Now I used 2 spaces and I've gotten used to it and can read
| it fine. And I have no doubt you could learn to read the
| black formatted code just as easily. I can, since that is how
| I format my code anyway.
| NavinF wrote:
| That's gotta be a really unpopular opinion since I've never
| seen anyone write "[ 1, 2, 3 ]" instead of "[1, 2, 3]" in the
| last 10 years or so.
|
| If anything I'm seeing the opposite trend with a few devs
| writing "[1,2,3]" so that large constant literals don't
| overflow the line.
| LegionMammal978 wrote:
| I've recently been working with an old C++ codebase that
| formats every function call like this:
| Foo<Bar,Baz> value = some.method (1, 2, 3 + 4) ; //
| or with no parameters: value = some.method() ;
|
| I've never seen it anywhere else, and it took me a good
| week to get used to it.
| throwaway894345 wrote:
| Agreed. My only grievance with Black was that it was really
| slow compared to gofmt or rustfmt, but that's a perennial
| problem with Python tooling.
| ambivalence wrote:
| This is now improved. Black is compiled with mypyc, should be
| roughly 2X faster than before.
| throwaway894345 wrote:
| Oh, good to know!
| mumblemumble wrote:
| I love it even though I dislike quite a few of its formatting
| rules.
|
| Because the only thing worse than a slightly wonk formatting
| convention is spending any time at all implementing, arguing
| about, or otherwise worrying about formatting conventions.
| unfunco wrote:
| Rob Pike's proverbs about Go fmt springs to mind: "Go fmt's
| style is nobody's favourite, but go fmt is everybody's
| favourite."
| javajosh wrote:
| Word. I got major pushback trying to fix this problem at my
| last company, which is (in part) why I'm not there.
| crlees wrote:
| Here here! Same.
| teddyh wrote:
| NB: It's "Hear, hear", not "Here, here".
| crlees wrote:
| Thanks mate.
| oever wrote:
| We never agreed on the indents
|
| I typed a hundred tabs
|
| You go back to space and I go back to black
| CyberShadow wrote:
| One missed opportunity in Black's algorithm is that it currently
| treats the maximum line length as a literal hard limitation in
| number of characters. Here is a trivialized example:
| to_add = [item for item in data.new_items if item not in
| data.old_items] to_remove = [ item for item
| in data.old_items if item not in data.new_items ]
|
| Although the constructs are nearly structurally identical, they
| can be formatted very differently, which sometimes hinders
| understanding them.
|
| A different approach would be to instead normalize all words to a
| certain fixed width. So, "to_add" and "to_remove" would have the
| same virtual width.
|
| A related issue is that leading indentation counts towards the
| width limit. This causes refactorings which simply move code
| around (changing its indentation level) to change the code's
| shape, even when the code hasn't otherwise changed. This is
| exacerbated by that one often needs to mold code in such a way
| that Black formats it in an agreeable way, but this is generally
| not done during refactorings, so the readability of the code
| suffers.
|
| I had the opportunity to write a formatter (for SQL, also
| unconfigurable/opinionated); it seems to successfully avoid these
| problems: https://github.com/CyberShadow/squelch
| ed25519FUUU wrote:
| I use black and love it-- but only with 120 line lengths. The
| default of 80 is wayyy to low for the days of 4k monitors. The
| tricks it uses to split some things up onto new lines actually
| makes it less readable.
| megapolitics wrote:
| I agree. I've sometimes found Black's output to be on the
| borderline of unreadable with the default line length of 80. My
| team settled on a length of 120 (the only Black config item we
| changed) and it has largely, though not entirely, solved that
| problem.
| ambivalence wrote:
| As long as you can easily review code side-by-side with line
| numbers intact, you're good. The default was chosen for lower
| resolution 13" laptop monitors to be able to display the
| Phabricator diff page (think: Github PR review page) without
| having to wrap any lines.
| faut_reflechir wrote:
| I don't love how Black doesn't let you put some clarificatory
| parentheses -- for instance, they get wiped from `eq_balanced =
| (left_hand_side == right_hand_side)` But the benefits of never
| wasting time on discussing inanity outweigh any specific
| complaints.
| rsfern wrote:
| You can disable formatting for specific lines or blocks with `#
| fmt: off`
|
| https://black.readthedocs.io/en/stable/the_black_code_style/...
| rr808 wrote:
| Anyone have a foolproof way to reformatting all the code in a
| repo without screwing up history? I've seen some complicated
| commands which seem too sketchy to a git novice like myself.
| mumblemumble wrote:
| Do it all in one commit.
|
| Then put that commit's (full) sha in a file named something
| like .git-blame-ignore-revs
|
| Then `$ git config blame.ignoreRevsFile .git-blame-ignore-revs`
| rr808 wrote:
| Thanks, that is helpful, esp I can google that to get more
| docs. One issue is everyone in the team needs to do so, but
| its probably worth it.
| dang wrote:
| Past related threads:
|
| _Black - Uncompromising Python code formatter_ -
| https://news.ycombinator.com/item?id=19939806 - May 2019 (244
| comments)
|
| _Linting 400kLOC of Python Code with Black_ -
| https://news.ycombinator.com/item?id=18536731 - Nov 2018 (1
| comment)
|
| _Black: An uncompromising Python code formatter_ -
| https://news.ycombinator.com/item?id=17151813 - May 2018 (255
| comments)
| woodruffw wrote:
| Congratulations to the Black authors! It's a wonderful tool,
| probably the first one I install when creating a local Python
| development environment.
| faangiq wrote:
| Is there an equivalent for TS/JS? How about Java?
| iddan wrote:
| Check out Prettier
| _old_dude_ wrote:
| prettier [1] and google-java-format [2]
|
| [1] https://prettier.io/ [2] https://github.com/google/google-
| java-format
| lelandfe wrote:
| "Standard" was popular for a while but fell out of vogue.
| Prettier is the one to reach for these days. I'm a big fan
| simonw wrote:
| Prettier is the closest I've found for JavaScript.
| simonw wrote:
| Adopting Black made me realize quite how much of my coding
| thinking capacity had previously been spent thinking about code
| formatting - I used to really sweat the details about how to
| break up a long function call, where to put the line breaks, how
| to indent my dictionary literals...
|
| With Black, I don't spend a single moment thinking about that at
| all. I estimate I've got a 5-10% productivity boost in my time-
| spent-writing-code from this!
| eawoifjaiowepfj wrote:
| It's been at least a decade since I've not used an
| autoformatter on every piece of code ever. I didn't realize
| there were people who worked at places without autoformatters
| still.
| npage97 wrote:
| To add onto this, I also found that Black works as a nice
| heuristic indicating to split up code when the formatted output
| isn't "pretty" into separate lines.
| ublaze wrote:
| I remember we migrated 2+ million LoC to being formatted by Black
| at Dropbox.
|
| Our Livegrep instance with a custom Git blame implementation
| always crashed at the commit made to do the migration :-) We had
| to pause our merge queue because we didn't want to run into
| conflicts, and I remember the `git push` ended up taking a while.
|
| There was only one change that we had to make to Black to get it
| working on our codebase -
| https://github.com/psf/black/commit/024c9cab55da7bd3236fd887...
|
| Glad to see it's now stable.
| skrause wrote:
| When I switched the company to Black, I reformatted the whole
| repository history with it. Every developer had to clone the
| repository again and reapply their local changes to it, but in
| the end it was a good choice because "blame" still works
| perfectly since we don't have one big reformatting commit.
| glacials wrote:
| An alternative is to use Git's blame.ignoreRevsFile[1] option
| to ignore specific commits when calculating blames. The
| downside is that although you can save the list of commits in
| the repo, you cannot do the same for the config setting
| itself, so it calls for some light automation at scale.
|
| [1]: https://git-scm.com/docs/git-blame#Documentation/git-
| blame.t...
| Operyl wrote:
| `another_really_really_long_element_with_a_unnecessarily_long_n
| ame_to_describe_what_it_does_enterprise_style` hahahahaha, I
| love that test case.
| ublaze wrote:
| To clarify, the slow git push was likely custom pre-receive
| hooks being slow.
___________________________________________________________________
(page generated 2022-01-29 23:00 UTC)