Replies: 1 comment 1 reply
-
I think that depends on if you use the formatter or not. The way I would format it and I would like _COLUMN_DESCRIPTIONS = {
"MC_Time": "Index enumerating the Monte Carlo samples.",
"Time": "Physical euclidean time coordinate "
"along which correlation is measured.",
"Internal": "Any further internal structure, e.g.,"
"an index enumerating interpolating operators, "
"a blocking or smearing level, "
"or any combination thereof.",
"Correlation": "Measured values of the correlators.",
"Vac_exp": "Measured values of the vacuum expectation values (VEVs).",
} Possibly with some empty lines in between. An alternative that is also _COLUMN_DESCRIPTIONS = {
"MC_Time": "Index enumerating the Monte Carlo samples.",
"Time": (
"Physical euclidean time coordinate " "along which correlation is measured."
),
"Internal": (
"Any further internal structure, e.g.,"
"an index enumerating interpolating operators, "
"a blocking or smearing level, "
"or any combination thereof."
),
"Correlation": "Measured values of the correlators.",
"Vac_exp": "Measured values of the vacuum expectation values (VEVs).",
} |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
PLR2044 having been finalised has raised an issue in a project I work on.
I have some dicts of long strings, each of which is broken across multiple lines.
Empty comments are used to separate entries, as otherwise it's not obvious where strings end—the trailing
,
is not visually striking when every line ends with a"
and many have other punctuation before that. There isn't really a need for a non-empty comment; each dict entry is self-explanatory.Is there a recommended alternative for this? If not, then I can add PLR2044 to my exceptions list and/or
noqa
these data structures, but if there are better ways to format this then I'd be enthusiastic to adopt them.Beta Was this translation helpful? Give feedback.
All reactions