but that easily runs afoul of PEP8’s character limit on a line. Is there a recommended solution? The workarounds that I have come up with all have undesirables effect
Solution 2: instead of creating the temporary tuple and using = inside {}, repeat them manually
(
“(self.method1(), self.variable2, self.some_dict[‘some key’], …) = " # this ordinary string can be split further if needed
f”{self.method1()}, "
f"{self.variable2}, "
…
“)”
)
which becomes a maintenance nightmare as the string will gradually deviate from the rest of f-strings.
Solution 3: Don’t bother with the tuple
f"{self.method1() = }", …
which makes the log a bit more difficult to parse.
Solution 4: leave the line ultra long and silence any warnings from linters/checkers/…
The best course is your solution4, just ignore PEP-8 and write whatever looks best to you. Since this code isn’t going into the standard library, nobody should care.
I think this is easier, not harder to understand visually - the purpose of this kind of debugging f-string output is to understand what each output value is about, and this is easier when the values are separately labelled. This also allows for splitting up f-strings, which can even be implicitly concatenated:
If you’re using the logging module infrastructure, you should avoid building the string yourself, but passing the template and arguments, and the logging infrastructure will build the string. This has two benefits:
actually not building the string if the log would not be output (e.g. because of level rules)
protect the rest of the code of template/formatting errors
This loses the benefit of the {...=} notation though. Unless the formatting is particularly costly, I would go with the f-string, as it’s a much lower maintenance burden.