`black` + judicious (sparing!) use of "# fmt: off" == BLISS Thank you for this great tool, Lukas. I _do_ disagree with a few 'opinions' of Black, but then I took a step back, saw that those were basically bikeshedding, shrugs, and accept. How I wish the current FOSS project I'm now involved in adopted black...
Love using black, thank you so much for it, great job! The only thing that is weird to me is if one has a short line, and an inline comment on the same line, its like to add brackets around the statement and position the comment in a way that doesnt look related anymore. Maybe fixed by now.
So the only thing we miss in python is to agree all on black's default style. Except... that I'll never ever accept double apostrophes - so I patched my black . Ups... :-)
@@WebLego then what's the point of it. We want the same code style project wide and i'm not the only one working on the code base. We'll go with a patched version, there are some options meanwhile, oitnb or axblack. Their ignorance regarding single quotes but leaving line length configurable is a joke.
20:30 no. that's a pep8 violation and it looks awful. You can't visually distinguish the arguments from the body, and it's absolutely the wrong formatting to do. It becomes even worse when you have a return value type specification.
You can visually distinguish the arguments from the body by the dedented ):. The goal of the project is to minimize diffs so the ): has to be on its own line, the decision is just about indentation and their way is the clearest imo. Also it is pep8 compliant to do it this way. "The closing brace/bracket/parenthesis on multiline constructs... may be lined up under the first character of the line that starts the multiline construct" - www.python.org/dev/peps/pep-0008/?#indentation
@@Dave__AC It is literally defined as wrong in the second verbatim text in that section. Literally. What you are referring to has to do with variables, not function definitions.
I actually prefer double-quotes, because English sometimes uses single quotes. But I am always too lazy to use double-quotes, because of having to hold Shift in addition to pressing the quote button. Black fixes this!
Came across this video and tried out black. Awesome tool ! Readability of my scribbles improved a lot. Just enabled it in Pycharm.
Just now discovering black, can definitely say it changed the way i approach at code formatting
Great talk, I love using `black` - thanks!
you mean "black"? 😉
@@ewerybody Interpreter says: 'black' when I print it
`black` + judicious (sparing!) use of "# fmt: off" == BLISS
Thank you for this great tool, Lukas. I _do_ disagree with a few 'opinions' of Black, but then I took a step back, saw that those were basically bikeshedding, shrugs, and accept.
How I wish the current FOSS project I'm now involved in adopted black...
Love using black, thank you so much for it, great job! The only thing that is weird to me is if one has a short line, and an inline comment on the same line, its like to add brackets around the statement and position the comment in a way that doesnt look related anymore. Maybe fixed by now.
*isort -m 3* and *black -l 79 -t py38* must be the only way.
Using it from the terminal to format my files is great. Integration in visual studio code just does not work.
The github link is 404
github.com/psf/black
@@ElenaWilliams-elequ I mean the slides link
Yeah, you're right, looks like they had deleted this repository. There is also no slides of this talk at speakerdeck.com link.
So the only thing we miss in python is to agree all on black's default style. Except... that I'll never ever accept double apostrophes - so I patched my black . Ups... :-)
Just use -s
@@WebLego then what's the point of it. We want the same code style project wide and i'm not the only one working on the code base. We'll go with a patched version, there are some options meanwhile, oitnb or axblack. Their ignorance regarding single quotes but leaving line length configurable is a joke.
watching in 2024 of learnign python
I recently started working on a code base that used black. It is highly annoying. I don’t get why everyone is so head over heels on it.
20:30 no. that's a pep8 violation and it looks awful. You can't visually distinguish the arguments from the body, and it's absolutely the wrong formatting to do. It becomes even worse when you have a return value type specification.
You can visually distinguish the arguments from the body by the dedented ):. The goal of the project is to minimize diffs so the ): has to be on its own line, the decision is just about indentation and their way is the clearest imo. Also it is pep8 compliant to do it this way. "The closing brace/bracket/parenthesis on multiline constructs... may be lined up under the first character of the line that starts the multiline construct" - www.python.org/dev/peps/pep-0008/?#indentation
@@Dave__AC It is literally defined as wrong in the second verbatim text in that section. Literally. What you are referring to has to do with variables, not function definitions.
I checked the first two verbatims in pep8, and neither mentions the sad face on the next line.
@@StefanoBorini Its almost as if he told why we write function definitions exactly like we write lists or other data structures.
You lost me at double-quoted strings :)
I actually prefer double-quotes, because English sometimes uses single quotes. But I am always too lazy to use double-quotes, because of having to hold Shift in addition to pressing the quote button. Black fixes this!
You can use ‘-S’ to not change the quotes
@@BennyDaon Which is bull.
Just use `black -S|--skip-string-normalization` and keep the rest. :)
you lazy programmers! just spent a little more time and patience! or don't code at all.
Jesse what the fuck are you talking about.
sure thing grandpa, time for your meds now