|
145 | 145 | "Conventions:\n", |
146 | 146 | "\n", |
147 | 147 | " - **Strings MUST be 'single-quoted', but \"double quotes\" are allowed internally**\n", |
148 | | - " - This rule applies to triple quotes and doc strings also, contrary to PEP 257.\n", |
149 | | - " - Docstrings must begin and end on their own lines. No one-line doc-strings or text\n", |
| 148 | + " - This rule applies to triple quotes and docstrings also, contrary to PEP 257.\n", |
| 149 | + " - Docstrings must begin and end on their own lines. No one-line docstrings or text\n", |
150 | 150 | " immediately following the triple quotes.\n", |
151 | 151 | " - When there is a hyphen or single quote in the string, double quotes should be used,\n", |
152 | 152 | " not escaping/backslashing.\n", |
153 | 153 | " - For long streams of TinyNotation or Lilypond code, which both use single quotes to indicate octave,\n", |
154 | 154 | " triple single quotes around the string are better than double quotes. Internal whitespace\n", |
155 | 155 | " rarely matters in those formats.\n", |
| 156 | + " - Before v10 concatenating strings without a plus sign was discouraged. I've changed my mind,\n", |
| 157 | + " and am \"letting Python be Python\" now especially when three or more lines are involved.\n", |
| 158 | + " However, use a + sign if concatenation is mixed with different comma-separated arguments.\n", |
156 | 159 | " - Documentation should follow quoting in American English grammar when not\n", |
157 | 160 | " discussing code. So for instance, a quotation in documentation is in double quotes.\n", |
158 | 161 | " - Variable names:\n", |
|
163 | 166 | " - Line lengths are capped at 100, but if approaching this limit, look for ways to avoid one-lining.\n", |
164 | 167 | " - if it's easy to split your line into two which are both under 80 characters, do so.\n", |
165 | 168 | " - Line continuation characters (`\\`) are not allowed; use open parentheses.\n", |
166 | | - " - Prefer f-strings to `.format()`. The `%` interpolation is no longer allowed.\n", |
| 169 | + " - Greatly prefer f-strings to `.format()`. The `%` interpolation is no longer allowed.\n", |
| 170 | + " - `.format()` is only to be used when a repeated format string is involved.\n", |
167 | 171 | " - Annotating types is **required** in new code, and encouraged to be added to older code.\n", |
168 | 172 | " - e.g. `self.counter: int = 0` or `def makeNoises() -> list['noise.Noise']:`\n", |
169 | 173 | " - The typing library should always be imported as `t`.\n", |
|
193 | 197 | " manipulation of the original object. When `inPlace` is True, nothing should be returned\n", |
194 | 198 | " (not true for `music21j` since passing through objects is so expected in JavaScript thanks\n", |
195 | 199 | " to JQuery and other libraries). Use the `@overload` decorator to show how this parameter\n", |
196 | | - " affects the return value -- Python makes this a bit hard, but see for instance, :meth:`~music21.stream.base.Stream.getElementsByClass` for an example of how to use this.\n", |
| 200 | + " affects the return value -- Python makes this a bit hard, but see for\n", |
| 201 | + " instance, :meth:`~music21.stream.base.Stream.getElementsByClass` for an example of how to use this.\n", |
197 | 202 | " - Use descriptive pull request titles (rather than GitHub's default \"Update pitch.py\")\n", |
198 | 203 | " - Do not have a PR title so long that it cannot be seen in one line. Simplify and\n", |
199 | 204 | " rewrite and go into more detail in the description. I depend on skimming PR titles\n", |
|
0 commit comments