Python was always meant to look concise / beautiful... (MyPy has also made this trickier too)
An autoformatter removes 99% effort from formatting code, and that includes code actively being worked on. Autoformatters are incredibly useful.
A standardized format removes effort spent learning to read a new format. That's an hour per format at most.
I don't see any good reasons for an autoformatter to enforce a standard. A standard would work just as well if defined as a specific configuration.
I wish people just used more locals though. I don't see what the problem is and it makes Sentry errors easier to debug.
Blacks value isn't autoformatter, it's preemptive discussion ender.
Exactly. I have learned that having it formatted just like I want it is FAR FAR FAR less important than having the entire ecosystem share a single format.
One hour my ass.
Are the mentioned issues resolved by now? E.g. the quadratic algorithm?
assert outputs.get("foo.bar.baz", "default") == pytest.approx(
time_recorder.time_taken, abs=0.0001
)
In the last few years I find devs are happier to format and push to "sort that problem out", leaving the readability benefit of that thought process lost.
TL;DR writing readable code isn't just about getting the spaces and brackets right...
assert outputs.get("foo.bar.baz", "default") == pytest.approx(
time_recorder.time_taken, abs=0.0001)
And also it feels like the open and closing parens should be on lines that start at the same indentation level. Honestly this I think does aid in readability a bit.
> Part of the twisted beauty of PEP-008's narrow lines is that you're forced to extract (named) variables, or avoid overly indented code by extracting methods or applying higher level abstractions.
This feels orthogonal? The line is wrapping either way, which might sufficiently annoy someone to extract things out a bit more. But IMO it feels like a bit of an anti-pattern to create abstractions on the basis of syntax as opposed to the structure of the program.
> writing readable code isn't just about getting the spaces and brackets right...
? I mean of course not, but that's what we're talking about in the context of formatters right? I think the real, major way auto-formatters help with readability is by getting people to stop wasting mental cycles on things like spaces and brackets so that they can focus on more important code organization concerns.
int foo() {
return 1; }
Maybe it could be broken up differently though to avoid the lone paren.
assert (outputs.get("foo.bar.baz", "default") ==
pytest.approx(time_recorder.time_taken, abs=0.0001))Using the same three lines, you could instead assign each result to a temporary var:
x = outputs.get("foo.bar.baz", "default")
y = pytest.approx(time_recorder.time_taken, abs=0.0001)
assert x == y
self.assertEqual(
outputs.get("foo.bar.baz", "default"),
pytest.approx(time_recorder.time_taken, abs=0.0001),
)
foo = (
spark
.read
.parquet(...)
.filter(...)
.withColumn(...)
and turns it into
foo = spark.read.parquet(
...
...
...
which feels harder to parse for me. I also never quite got on board with the trailing commas.
instead
of
being
split
up
into
too
many
lines.
foo = (
spark.read.parquet(...)
.filter(...)
.withColumn(...)
)