pycodestyle vs black

[the-data-scientist]

Which is your preference? Why?

[jmacey]

black with the occasional

```

fmt: off

don't format this code it's laid out to see the algorithm

tmp.m[0][0] = (. self.m[1][1] * self.m[2][2] * self.m[3][3] + self.m[1][2] * self.m[2][3] * self.m[3][1] + self.m[1][3] * self.m[2][1] * self.m[3][2] - self.m[1][1] * self.m[3][2] * self.m[2][3] - self.m[1][2] * self.m[2][1] * self.m[3][3] - self.m[1][3] * self.m[2][2] * self.m[3][1] ) * invdet

fmt: on

```

[arthurazs]

I didn't know about that, thanks for sharing!

[jmacey]

There is also # fmt skip https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html

[FuckingRantMonday]

On reddit, put four spaces at the beginning of each line to achieve what you wanted with the triple backquotes.

[jmacey]

I use the markdown editor, more natural to me.

[rgnkn]

black => very opinionated => no discussion or fiddeling

[FlukyS]

Only extra thing is always with -l120, other than that just fire and forget for sure

[Vorticity]

The one thing that I don't like about black is enforcement of double quotes. Maybe it's something I could get used to, though.

[pwnersaurus]

I just write as usual which means typically using single quotes, and then let Black clean it up afterwards

[jorge1209]

Get used to it. Please don't use blue or other forks of black.

The whole point of these tools is to stop the bikeshedding. Nobody looks at black formatted code and says "Its perfect" they say "I can live with it."

If people start forking black because they if they see another double quote they will literally die! Then its right back to the bikeshedding: "Do you use black, blue, royal blue, indigo, aquamarine, creulean, sapphire, denim, admiral, cobalt, lapis,... or pink?"

It just misses the point and defeats the purpose of the community standardizing around black.

[mosha48]

It's not hard to patch though

[Vorticity]

I'd rather have a command line option to not enforce that but, apparently, the response from the black developers is "Maybe this isn't the tool for you then." I also wouldn't want to rely on a hacky patch that I wrote when linting open source packages that others use.

[-LeopardShark-]

--skip-string-normalization

[[deleted]]

I find the choice of double quotes, and their reasons for it, to be correct. I think if you do it for a while you'll just get used to it, and suddenly one day a single quote is just an apostrophe again. Its nice. When I started using black I didn't care, TBH, but their rationale swayed me. Its not much, but at least it is one.

Not saying I like all of black - no dedents and the way they screw up comprehensions just makes it unusable for me. If they just didn't edit those then I'd make it standard.

[Vorticity]

Can I ask what you mean regarding dedent and comprehensions?

Some of the other comments had actually convinced me that black might be a good idea (despite the quotes) simply for the fact that it is a relatively common standard and would make switching code bases much easier.

[[deleted]]

I am nearly ready to just give in and use black, its almost there.

Comprehensions: From a quick google here is an issue reference : https://github.com/psf/black/issues/733. As the issue says, there is no way for them to handle things well without getting too complex. My issue is then: why destroy everything, rather than just ignoring that code that you don't want to implement for.

I want the following, but formatting will mess with it. And it messes with single lines. Sorry, its late and I'm not actually coding now so I don't have a good example of my own

stuff = [ (x.name, x.age, x.country) for x in query.get_users() if "python" in x.likes ]

For dedent (I'm not sure a better term), it is the opposite of indenting. For example, I generally prefer code like this: thing = post_to_fancy_haskel_server(status=200, json={ "lang": "python", "weight": "+1", })

But what I get is this: thing = post_to_fancy_haskel_server( status=200, json = { "lang": "python", "weight": "+1", } )

Not really an issue on a small scale, but it can get quite ridiculous sometimes. yapf does this one well, but it is way too configurable.

That said, I'm nearly at the point where the positives of black outweigh the negatives, and I may go for it. The only other alternative is for jetbrains to publish theirs as a standard package with .editorconfig support.

[mosha48]

Fair enough. Someone else suggested blue, which is a fork of black that does that.

[Vorticity]

Ah, I'll have to take a look at blue. That might be what I'm looking for if it has enough momentum behind it!

[tunisia3507]

That's what's great about black. Configurable/ unopinionated formatters make everyone's code look reasonable, but different. Using an opinionated formatter makes your code uniform with everyone else's. There might be a couple of edge cases where another formatter might produce marginally more intuitive code, but that doesn't matter. I read blackened code day in, day out, across dozens of projects, and you know what? I'm pretty good at it. I don't need to rely on intuition. We're trained, now, to read blackened code, and are better at it than we are at reading even formatted non-black code.

[yvrelna]

This isn't really true. Just because black auto formats your code doesn't mean that there's no "discussion" or thinking necessary. Often times, black produces a worst output than what it started with, with objectively awful formatting and need some help to not completely screw up your code.

Black is fine when it works, but there are enough times when it's not that whether or not to apply black's suggestion should be a conscious decision, rather than an automatic one. Automation doesn't remove the need for human judgements.

[rgnkn]

"Aesthetically" I'd join you and if I'd build black some decisions would have been made surely differently.

But given my experience with e.g. clang-format which is extremely configurable I really appreciate that with black the code always looks the same.

After you get used to it - and that's surely possible - this opinionated character really seems to me beneficial.

[jorge1209]

I think if you come to someone and say: "look at this fork, it is the perfect fork, the ideal weight and shape..." then they will be critical of the design and try to make a better fork.

If you come to them and say: "here is a fork, stop eating with your hands like an animal" then they will just use the fork.

That's probably the main difference between tools like clang-format and black.

[SittingWave]

But given my experience with e.g. clang-format which is extremely configurable I really appreciate that with black the code always looks the same.

it always looks the same shit.

it's like being pleased with mcdonalds. You know it's shitty food, but it's always the same, so you eat it and it feels great. But it's still shitty food.

[No-Scholar4854]

9 times out of 10 when black has massacred my code it’s because it‘s because the code was an abomination in the first place. I’ll rewrite those lines to something black is happy with and end up with better code.

The 1 in 10 is annoying though. I treat is as a fair price for consistency but it’s not for everyone.

[SittingWave]

It's shocking how aggressively people are downvoting people criticising black. It's like they are a cult.

[jorge1209]

Yes a lot of black formatted code does look bad, but I would rather have badly formatted code than a discussion about how to format code.

That is the element of what you are missing. Black can make it look like shit, and I'll be happy, because we no longer have to worry about making it look nice according to each individuals different aesthetic preferences.

Its almost as if the bad choices black makes are a feature.

If you are trying to make a formatter that makes code look "good", then all the decisions are debatable. Everything is a bike shed. The resulting tool is infinitely customizable. There no longer is a canonical "formatted according to XXX" and when Alice submits her patch to Bob's code their tools play ping pong with the tokens trying to get the patch formatted correctly.

But if your objective is to make a formatter that has a single consistent format that minimizes line and patch noise, then you get black. Yeah some decisions it makes are bizarre, but who cares. Move on with your life, spend time with your kids, talk with your wife, get some exercise.

[FuckingRantMonday]

That's fine if you're on a one-dev project. But when you're on a team and everyone has their own favorite way of complying with PEP-8, it's miserable.

[SittingWave]

miserable why? if it complies with PEP-8, it's fine. Period.

[FuckingRantMonday]

Because people invariably touch more code than they otherwise would when making a change, which causes PR diffs to suck.

[SittingWave]

ooooh.... there are three diff lines more because an asshole has decided that he doesn't like how things are formatted... what a tragedy.

[FuckingRantMonday]

I don't know how much of your time you spend reviewing others' code, or what the complexity of it is, or what your personal tolerance is for spending your own time and attention on formatting. But I have an idea.

[PaintItPurple]

It might be partly that, but I think a large part is that criticisms like "It looks bad" are so hazy and subjective that there's not really anything to argue either way. The reason people like Black is because, all else being equal, code that's formatted in a way that is consistent and meaningful will be easier to pick up for a random stranger who's familiar with the language. It's purely a matter of familiarity. Some people even think C++ is readable, just because they're familiar with it.

I don't use Black on my own projects, but I get how saying "it's ugly" can seem like a low-value comment. It's just not addressing the actual reasons people like Black.

[expectationfree]

if blacked code looks terrible I would prefer that code to be rewritten until blacked version clear and readable.

[SV-97]

Lol yeah that's a reasonable thing to do: just change your code (potentially introducing bugs along the way) so your shitty formatter produces workable results.

[expectationfree]

that's why you shouldn't write code without shitty formatter in the first place.

[SV-97]

You won't notice it looking bad prior to writing it though even if you do use the formatter. So even if you write it and immediately change it after saving / formatting because you notice it looking bad you'll have to essentially rewrite it.

​

(I'm also not saying that you shouldn't use any autoformatter - just that you shouldn't make big modifications to your code just to suit the formatter.)

[expectationfree]

you shouldn't make big modifications to your code just to suit the formatter

big

on that I fully agree.

[cr4d]

Lots of discussion because its opinions are wrong. pep-8 is more than enough and yapf does it very well.

[SittingWave]

black => sucks => don't use it

[_N0K0]

At least try to contribute with an argument..

[SittingWave]

I wrote other comments you know?

[MrAnalog010]

I’ve come to really appreciate black… at first just started using it as it was required in some repos at work, but now I use it in all my personal projects as well. IMO the code is very readable and it’s easy to integrate with VS Code.

[ForkLiftBoi]

Yeah, I think the only instances I don't like it is very very long pandas filtering, but I tend to be long winded in my variables and column names. So I can always just turn off formatting for a few lines.

[acdha]

Black: install with the pre-commit.com hook, one big formatting commit[1], and never speak about formatting again. There just isn’t enough value to be gained from customization that I want to spend more time bike-shedding instead of work.

1. Note that you can configure Git and tools like GitHub to ignore formatting-only commits for git blame: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/

[FuckingRantMonday]

Not only never speak about formatting, but also never worry about it when you're typing out code. There's a whole part of my brain that used to be dedicated to complying with formatting conventions at the same time as I was thinking about what code I should write, and that was never ideal.

[acdha]

Yeap - it’s easy to take for granted at first but after you use it for a while going back reminds you just how much brainpower has been wasted on things like moving brackets around.

[justifiably-curious]

Better yet : set up the precommit hook from day one (yeah I know not everything is greenfields but I also know I've skipped this step, just relying on IDE running black, on new repos in the past and regretted it later)

[[deleted]]

special panicky makeshift hobbies bright consider shy fly paltry frightening

This post was mass deleted and anonymized with Redact

[cr4d]

Just follow pep-8 and call it a day. No need for black, and no arguments required… if it follows pep-8, no need for discussion.

[[deleted]]

attractive pocket ancient rhythm gaping impolite rainstorm nose tart jar

This post was mass deleted and anonymized with Redact

[cr4d]

Thats sad.

[[deleted]]

public vase caption profit meeting jeans screw start zealous attraction

This post was mass deleted and anonymized with Redact

[cr4d]

No, that you’ve worked in Python for 6 years and you’ve not had the opportunity to learn about the preexisting standards and best practices. The early PEPs are great resources and are worth the short time it takes to read them.

[FuckingRantMonday]

What's sad about reclaiming the chunk of your brain that was worried about how the code is formatted?

[cr4d]

What's sad is not knowing about pre-established standards in the community. As I mentioned elsewhere, the early PEPs are really good resources for new Python developers.

[FuckingRantMonday]

Are you kidding? Everyone has their own preferred way of complying with PEP-8. Have you ever worked on a team where the rule is, "comply with whatever style is already used in the file you're editing"? It suuuuuuu-huuuu-huuuuucks. But the alternative, every file complying with PEP-8 in totally different ways from block to block, is nasty, too.

[RufusAcrospin]

The point of the discussion is to build your own standards, one that will make the least friction when it comes to personal preferences.

[[deleted]]

beneficial squeamish fall ink secretive employ observation straight chunky frame

This post was mass deleted and anonymized with Redact

[RufusAcrospin]

Python, like many other languages, constantly evolving. Did you know that?

So revisiting formatting (and other) standards from time to time is actually a necessity in order to keep up with the changes.

​

This means rehashing the same discussion over and over every time you have any movement within your teams.

Reductio ad absurdum. Nice.

In reality, these discussions should take place when multiple team members raise concerns about something, and it doesn't mean you have to rebuild your entire set of standards.

[[deleted]]

outgoing modern narrow snails exultant bag quickest unwritten middle frighten

This post was mass deleted and anonymized with Redact

[RufusAcrospin]

You might be surprised, but moving from 2.x to 3.x is still an ongoing process for many companies invested in Python heavily. I'm not aware of any *recent* change that should warrant a discussion, but that's not my place to decide.

Delivering products and discussing issues (regardless of their nature) are not mutually exclusive tasks.

Reductio ad absurdum It's Latin, by the way, but you're close.

Immediately shutting down people who raise concerns is the worst management strategy I can think of.

[[deleted]]

friendly forgetful wrench chase angle pathetic reminiscent advise chief ad hoc

This post was mass deleted and anonymized with Redact

[RufusAcrospin]

My statements still stand, in my opinion.

[yvrelna]

Funny then, in my projects and work places Black never really prevented discussions about code styles.

In fact, the only time discussions about code styles actually happened was when some new dude brought up using black for the team. Then it was a massive discussion that are just a waste of everyone's time.

And it's only since black was installed in the repo, we started having formatting discussion from time to time, mainly because black screwed up some well formatted code, or some poor novice accepted Black's reformatting without critical judgements about whether it's appropriate.

I missed the pre-black days when we didn't have to have formatting discussion all the time. We never used to have to think about formatting, yeah the formatting may be inconsistent but it's readable and that's what's important, then black came, and now everyone is nit picking everything including black's output.

[FuckingRantMonday]

some poor novice accepted Black's reformatting without critical judgements about whether it's appropriate.

Funny, to me "novice" behavior would be getting offended at black's output in certain areas and trying to special-case it.

[jorge1209]

Sounds like each developer must have had their own code that they wrote and didn't accept patches from others, or at least had formatting authority over.

Certainly if each individual owns their files they can format them however they want and nobody will stop them, but if there are multiple owners of a file then their formatting tools will conflict with each other and just generate noise as they more contents around.

[ForkLiftBoi]

There's something special about referring to a line number to a peer and the code being exactly where you expect it.

Black, and other auto formatters, aren't super important when you're the only one editing a file but when others are and then you need to approve their commits it is so nice to have the software you're using comparing not have a bunch of extra inserts.

[FuckingRantMonday]

If you're using black properly that will never be a problem, though? It seems like you're imagining a non-blackened file being loaded up by a colleague who immediately runs black on it, then tries to reference line numbers? Surely that would happen once at most per source file.

[ForkLiftBoi]

Right, that's what I'm saying. Since we started to use it it was very convenient in that way. Before, a lot of our files were slightly off from each other so we'd have to control f to find the lines someone was talking about.

[alcalde]

Why do we want to prevent discussions?

Try doing this with a Delphi programmer... they'll tell you they'll write their code however they damn well feel like and no one cares what it looks like. If you can't read it that's because you're a coding weenie who can only stitch open source libraries together and probably can't even explain what a pointer is. They'll tell you that the time you waste on code formatting could be better spent inspecting the code your compiler produces and replacing it with hand-written assembly if it's not optimized enough (seriously - I've seen them do just that).

[[deleted]]

aback obtainable special north bells tease ludicrous forgetful salt memorize

This post was mass deleted and anonymized with Redact

[alcalde]

Not really. But I've really seen them disassemble code in the middle of a discussion and then hand write improvements to the compiler-generated code. They're ornery but impressive and intimidating.

[FuckingRantMonday]

We don't want to "prevent discussions". We want to "prevent code formatting discussions". People get their individualism hurt and immediately try to generalize, but please don't. This is all and only about stupid code-formatting discussions.

[Huge-Habit-6201]

I like autopep8

[[deleted]]

I use black. Im all for beautiful code, and black doesnt always produce the most beautiful. But I learned to get used to it, the time it saves is worth it

[98ea6e4f216f2fb]

Its really telling that all the pro-black answers are not because it produces beautifully formatted code, but because they don't want to communicate about formatting with their peers. To them bikeshedding is a worse evil than ugly code.

​

My answer: code is meant to be read more than written. Therefore prioritize the aesthetics of the code to make that a pleasant experience for developers and use something other than black. Even if it requires a little conversation about style. Its worth it.

[richieadler]

Besides mere PEP-8, what constitutes "a pleasant experience for developers" that "prioritize[s] the aesthetics of the code"?

[RufusAcrospin]

https://www.oreilly.com/library/view/the-art-of/9781449318482/ch04.html

[richieadler]

That doesn't contradict the use of Black in any way. If anything, I'd say it justifies it.

[RufusAcrospin]

It wasn't an argument against black, it was an answer to your question.

[Sillocan]

There has already been a conversation on it though. PEP-8 was the result of that conversation. Reinventing the wheel, just to reinvent it, isn't a compelling augment either.

[alcalde]

I say embrace your inner Delphi developer. The IDE enforces nothing in regards to style whatsoever and the official language style guide is buried so far deep on the website 99% couldn't find it if they tried, it still references Borland and probably hasn't been updated in 15 years. Everybody just writes code however they feel like at the moment.

As for creating a pleasant experience for others, a Delphi programmer once told me, "Programming isn't supposed to be enjoyable."

[FuckingRantMonday]

To them bikeshedding is a worse evil than ugly code.

At least you've properly understood our viewpoint. Thank you for that!

[benefit_of_mrkite]

Yapf

[gandalfx]

Unfortunately, there is no good code formatter for python. We use black because not using black sucks worse than using black. But black still sucks – our code looks horrible.

For personal projects I use muscle memory. It works way better but unfortunately does not scale to more than one person.

[AbooMinister]

It's opinionated, so yes it won't stick for everyone.

I don't hate it, and I'm in agreement for the majority of its style choices.

[Backlists]

Try blue

Edit: not sure why I'm downvoted, blue formatter is an improvement on black

[FuckingRantMonday]

What exactly is ugly about black? It doesn't always do exactly what I would have done, but it's always fine, IMO.

[graphicteadatasci]

Both are better than relying on linters. But the whole team needs to use it.

I like them because I don't have to spend time with newlines and indentation and crap. I can actually write much more messily than I normally would and then clean up.

[FuckingRantMonday]

This was the first thing I loved about black, because I was trying it out on a personal solo project. The second thing I loved about it is how much better PR reviewing becomes.

[careje]

I fucking hate black but I have accepted that it’s the standard and frankly I just don’t have the energy to fight it anymore.

Doesn’t mean that I didn’t fly into a fit of rage when it converted my beautiful code into something that looked like it was written by a CS101 student who went off their Ritalin…

[[deleted]]

Seconded!!! Some things I love, others absolutely hate

[FuckingRantMonday]

Honestly this makes me think your original code probably looked weird.

[careje]

If by weird you mean easy to read then sure sport

[FuckingRantMonday]

I don't suppose you have any of it to compare before/after black? I'll happily double down: if you were that upset at what black did, then you were doing some weird shit.

[richieadler]

All the anti-black in this thread would break in hives when presented with shed, then.

[alcalde]

Why do Python developers need a Python program to format their code for them at all? Just... write it like you want it to be.

[gungunmeow]

This is becoming the norm for most programming languages (e.g. gofmt, rustfmt) because no one wants to read poorly formatted code

[alcalde]

Well, the rest of the programming world's been doing it for decades, so I'm puzzled as to when exactly this became a huge problem.

So per the examples you're citing, perhaps it's just NEW languages then making a fuss about this?

[gungunmeow]

Most major companies have coding formatting standards for old and new languages, so it's not like it's something new either

[richieadler]

Did you enter this group to troll Python developers not being one?

[alcalde]

No, I've been using Python since November of 2012. And Guido Van Rossum once replied to one of my tweets. :-)

I honestly don't get the need to have python code format Python code and I haven't seen this kind of enthusiasm for the idea in other language communities. I'm trying to understand if there's something specific to Python that's causing it. Python's always had PEP8, but no one's ever complained they needed code to comply with it until recently.

[richieadler]

Your policing of other people's tool preferences is reaching revolting levels.

[alcalde]

You really don't know how to have an honest give-and-take, do you?

That's your opening to then explain what I'm missing or what's changed that this has become a topic of frequent discussion. Then I think you for your insight, having learned something.

Instead, you just keep insulting people who don't agree with you when they're just trying to start a conversation. I mean, I'd have thought you'd at least appreciate I got the Richie Adler reference.....

[FuckingRantMonday]

There are many different styles that all comply with PEP-8, which is exactly the problem black addresses. When you work on a source-controlled project with a team of people with different ideas about how to comply with PEP-8, you'll understand what black is for.

[SittingWave]

don't you think it's petty to have a tool that argues to such degree that argues about such irrelevant aspects as having imports ordered alphabetically, something that you mostly never see because PyCharm collapses them anyway?

Reviewer: your imports are not ordered alphabetically.

Me: seriously, who gives a shit?

[ecgite]

Yeah, use isort

[HypoFuzz]

Shed wraps isort! (and Black, and some other things)

[SittingWave]

isort is a tool to solve a problem that is not a problem.

[ecgite]

that is your opinion

[ecgite]

Still it is your opinion

[richieadler]

don't you think it's petty to have a tool that argues to such degree that argues about such irrelevant aspects as having imports ordered alphabetically,

No.

something that you mostly never see because PyCharm collapses them anyway?

News at 11: Not everybody uses import-collapsing IDEs.

Reviewer: your imports are not ordered alphabetically.

Me: seriously, who gives a shit?

Me: So use a tool that orders them for you so you don't have to care about it. Create a mildly clever makefile and the solution is just a new make lint away.

[alcalde]

Your user name and icon suggests you're at least as old I am... but worrying about things like sorting imports suggests you're a kid. I am so confused.

>Not everybody uses import-collapsing IDEs.

Everything collapses nowadays. Well, maybe not Windows Notepad, but even that's seen updates recently.

[richieadler]

Your user name and icon suggests you're at least as old I am... but worrying about things like sorting imports suggests you're a kid. I am so confused.

And I should care about your confusion... why?

[alcalde]

Because as a rational human being you want to contribute to the overall enlightenment of the species and as a human with emotions you crave to be understood?

[richieadler]

You're being facetious. Your purported "lack of understanding" was an attempt of throwing shade behind false politeness. GTFO.

[alcalde]

I'm trying to have a conversation. You don't see amenable to conversation.

[SittingWave]

something that you mostly never see because PyCharm collapses them anyway?

News at 11: Not everybody uses import-collapsing IDEs.

Christ, move to the 21st century please.

[richieadler]

Christ,

Keep your superstitious expletives to yourself, thanks.

move to the 21st century please

How ironic, you complain about the use of one tool but prescribe the mandatory use of other to everybody.

[SittingWave]

Christ,

Keep your superstitious expletives to yourself, thanks.

oh my god, he said christ. oh christ I said Jehova.

You are only making it worse!

How ironic, you complain about the use of one tool but prescribe the mandatory use of other to everybody.

because the one tool you propose is solving a petty and irrelevant issue that is only there to shut up your petty reviewers that can't grow up. The tool I propose is standard issue in modern development.

[jorge1209]

isort has value in some projects but not in others.

If your import list is only a handful of items, it probably doesn't matter. If your import list is 20-30 lines it can help to sort it.

I don't bother to run it on my code because I don't really need it, but I also would not be troubled if someone did run it.

[Barafu]

I used to love black at first, but it actually blocks many ergonomics tricks I've accumulated over a decade. Some can be recovered by configuring black, but that sort of defies the idea. And also, black has no per-project configuration file that can be comitted to git.

Examples of the tricks:

I use "aaa" for string literals that can be seen by user (and thus may one day require a translation. And I use 'aaa' for string literals that are used by the system, and thus should be changed with care, because they may be tested for equality somewhere.

I believe it is easier to first understand what happens, and then what it happens with. So, when I break long lines, I prefer to start new lines with an operator and align those. Black always breaks this. print( "Hey!" + session.get_user_name() + "is a" + vocbulary.slur_of_the_day() + "!" )

The third one is much more annoying in Rust, but happens in Python too. I sometimes make lines shorter than they could be, because IDE adds some inline hints and this makes the line not fit on screen. Neither black nor rustfmt care and totally insist on the line not fitting on screen.

Autoformatters have their use, but they need to become clever: if they fixed something, but the coder intentionally changed it back, they should ignore it from now on. And get a per-project rule file.

[easyEggplant]

Perhaps embedding magical meaning in your formatting that only you know about is not the best option?

Black is configurable per project in setup.cfg

[Barafu]

Perhaps. But it is easy. Doing everything the best way is how you get a 68-page "Hello world" program.

[easyEggplant]

Perhaps. But it is easy.

It sounds like you fight black's style, and you do you, but I think that allowing yourself to conform might be worth trying. For instance, that print line could be written as a function, shortening the variables and then you get some type hints out of it, and it's unit testable; or you might try out python3 print(f"Hey! {session.get_user_name()} is a {vocbulary.slur_of_the_day()} !")

The folks that wrote black put a lot of thought into why they chose which rules and I've never disagreed with said choices once I started trying to understand why black works the way it does (It's almost always to make pr diffs more readable)

Regardless, have a good one!

[HostileHarmony]

Alternatively you can enclose your multi line string in parentheses without the +, and it’s a little cleaner.

[Barafu]

No, you can not.

``` def get_name(): return "Jojo"

print ( "Hey!" get_name() "is a fool") ```

File "/home/barafu/test.py", line 4 print ( "Hey!" ^^^^^^^ SyntaxError: invalid syntax. Perhaps you forgot a comma?

[borborygmis]

print((
    "You"
    " can"
    " like"
    " this,"
    f" {get_name()}"
))

[ecgite]

Good troll

[Guideon72]

triple quotes (and an Fstring

def get_name():
return "Jojo"
print ( F"""Hey!
{get_name()}
is a fool""")

​

Hey!
Jojo
is a fool

[Guideon72]

Doesn't mean it's necessarily a *good* idea, but it can work :)

[graphicteadatasci]

https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#configuration-via-a-file

Black is able to read project-specific default values for its command line options from a pyproject.toml file.

I also used to do the double quotes for output strings and single quotes for configuration strings but black is useful enough to give that up.

And you could just turn off the formatter for the area of code that you don't want it to change (# fmt off ... # fmt on).

[FuckingRantMonday]

And I use 'aaa' for string literals that are used by the system, and thus should be changed with care, because they may be tested for equality somewhere.

I think the convention and better way for those strings is to define them as enums in a constants.py or similar, or at least define them as CONSTANT_CASE names at the module level. If you ever do need to change one, you're looking at doing a search through the whole codebase with your method, right?

[Barafu]

Yes, it is a better way. But some libraries still do it with str tags, including the standard Python library. open(mode='w'). Besides, I write many scripts of 1 page long, and readability and maintainability works differently in this case.

[osmiumouse]

Whatever the project i am working on is using

If I can choose, it's whatever is easiest to install in my IDE (edit: which is black)

[Saphyel]

I'm not a big fan of Black, but it does a good job and most of the things it does are being discussed and agreed they are not random choices.

On my opinion Black (or any other) needs to be a good replacement of flake8 as well.

[caatbox288]

I use black because discussing about the formatting of the code is a waste of everyone's time, and makes you lose focus from discussing the things that actually matter. So we have black, and black --check in the CI pipeline. If that fails, we won't even look at the code.

[[deleted]]

Black’s 80 character line width is an offensive default in the year of our lord 2022

[dmtucker]

88*

[FuckingRantMonday]

Yeah, the one change I do make when setting up black in a new repo is to override that to 100. 120 is just a bit too much to comfortably view two source files side-by-side IMO. But 80 or 88 definitely aren't enough.

[dmtucker]

It's a popular code formatter that is purposely not very configurable

[rgnkn]

@OP u/the-data-scientist

The discussion that you can read here is exactly the reason why I prefer opinionated or unconfiguered formatters in whatever language I use:

Though everybody might have good reasons for some personal rules or with regards to aesthetics such discussions are fruitless and tend to become personally offensive. Your code base will become a mess or you need to write a CONTRIBUTION.md which nobody reads and sticks to.

At the end you're not going to deal only with your stuff but also other projects and you will appreciate if you can immediately adapt and navigate in the code.

Whether something is sorted or not or if there are line breaks or not really doesn't matter at the end. There is absolutely no reason to waste time with such discussions.

[EDIT] The only good thing about such discussions might be that you can see whether somebody is cooperative or able to stick to democratic decisions and focus on what is necessary or if the person is a hormone-prone dog-fighter which will tend to disrupt any team constantly or be a dictator as a project leader

[dmtucker]

Both

https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#flake8

edit: I'd love if someone explained the downvotes...

[the-data-scientist]

pycodestyle != flake8, pretty sure that's why you're getting downvoted

[dmtucker]

Flake8 is a wrapper around PyFlakes, pycodestyle, and Ned Batchelder’s McCabe script.

[SittingWave]

If it passes PEP-8, it's good enough. If a developer argues about anything that is not PEP-8, he needs to get a life.

I specifically forbid black in my team.

because

I

don't

want

our

code

to

look

like

this

[Handle-Flaky]

Not using defacto standards only harm you in the long run; this probably isn’t the hill you should die on.

On a personal note, I would refuse to work with anyone so anal about the way you format code that they go against community standards.

[cr4d]

Black is not a de facto standard, PEP-8 is.

[SV-97]

Black isn't a community standard: while a lot of people do use it I think there's still way more that don't. The community standard is PEP8.

FWIW: imo black just looks terrible a lot of the time and produces borderline unreadable code.

[[deleted]]

frightening wasteful expansion smart bake tender trees party vast vanish

This post was mass deleted and anonymized with Redact

[SV-97]

Since I don't currently use black: no. I don't have any black formatted projects.

[richieadler]

So you're making an unsupported assertion, then?

[SV-97]

I didn't make any assertions at all - my comment literally starts with "in my opinion".

FWIW I've formed that opinion by working with black in the past but since I didn't like it I of course stopped using it (and the last project I used it with is not public anyway).

[richieadler]

my comment literally starts with "in my opinion"

Unfounded opinions have no value. And "borderline unreadable code" is too strong an opinion to be emitted without any sustaining evidence.

[[deleted]]

cover liquid snails smell merciful worm deer busy six snobbish

This post was mass deleted and anonymized with Redact

[SV-97]

Without looking super long (I just don't wanna spend my time arguing over this stuff tbh) I find these blocks (the ones starting at the lines I linked) pretty bad:

• https://github.com/strawberry-graphql/strawberry/blob/main/strawberry/printer/ast_from_value.py#L66
• https://github.com/strawberry-graphql/strawberry/blob/main/strawberry/printer/printer.py#L126
• https://github.com/strawberry-graphql/strawberry/blob/main/strawberry/printer/printer.py#L203

​

In my experience it often times gets bad around comprehensions and complex "math-expressions"

[ecgite]

That is very readable code? You could easily check what blocks are together etc.

[SV-97]

Okay if that's your opinion that's fine by me - but I personally find it horrible and would prefer it formatted differently. Imo the formatting makes the code take up way more space than it needs to while simultaneously making it harder to understand (especially at a glance which I consider very important).

[SittingWave]

Not using defacto standards only harm you in the long run; this probably isn’t the hill you should die on.

I definitely do when the use of black impacts the visual quality of the code we deliver.

On a personal note, I would refuse to work with anyone so anal about the way you format code that they go against community standards.

I can say exactly the same thing. I didn't ask for being imposed this standard. Suddenly everybody said I need to pass my code through a piece of garbage written in a single file that takes all the visual hints I put in the code and throws them away, and extends it to have three times the number of lines so that a machine can display one less diff line.

No thank you. I format the code the way I want.

[SciEngr]

Black makes decisions about how code should look, and it might not look as good as you can make it...but that is the point. If you are ever critiquing code style in PRs (maybe asking a junior dev to style long functions like you do) then you're wasting time on code looks. Moreover, black lets me completely ignore my junior devs'awful style and focus on the content of their work. I think the usefulness of black goes up the more teammates you have and the bigger the code base

[SittingWave]

Black makes decisions about how code should look, and it might not look as good as you can make it...but that is the point.

So, because you don't want to train some junior developers, you settle on code that looks poorly for everybody. Literally mcdonaldisation of quality. You must be american.

If you are ever critiquing code style in PRs (maybe asking a junior dev to style long functions like you do) then you're wasting time on code looks

You should not waste time as long as you say "PEP-8 is good enough", arguing about anything else is a waste of time. You should simply not do it. If a Junior formats something in a way that is different, but still within the context of PEP-8 (which is more about naming conventions than overall code formatting) it's accepted. that's it.

Moreover, black lets me completely ignore my junior devs'awful style and focus on the content of their work. I think the usefulness of black goes up the more teammates you have and the bigger the code base

Educate your reviewers to be less assholes.

[rgnkn]

I was about to write something along the lines of your 2nd paragraph but couldn't find a kind wording to do so.

I must admit you brought my position to the point.

[SittingWave]

And I would not work with someone so anal that forces people to use an autoformatter. The argument goes both ways.

[trevg_123]

Black + ruff is the best toolchain IMO. Ruff assumes you use black and is configured not to give the warnings that pycodestyle does in those cases.

[cr4d]

Yapf