Peter Maydell <peter.mayd...@linaro.org> writes:
> On Fri, 26 Mar 2021 at 16:33, John Snow <js...@redhat.com> wrote:
>> Being less terse about it: Mostly, I don't like how it enforces this
>> column width even for indented structures. Generally, we claim that 72
>> columns is "comfortable to read" and I agree.
>>
>> However, when we start in a margin, I
>> am not convinced that this is
>> actually more readable than the
>> alternative. We aren't using our full
>> 72 characters here.
>
> I agree, and I don't see any strong reason to hold our Python
> code to a different standard to the rest of our codebase as
> regards line length and comment standards.
I can't see much of a conflict between canonical Python style and the
rest of our code. (If there was a conflict, then I'd doubt we should
hold our Python code to a different standard than pretty much all the
other Python code out there.)
PEP 8 is expressly a *guide*. It doesn't want to be treated as law. It
tells you when to ignore its guidance even before it gives any, right in
the second section. Applicable part:
Some other good reasons to ignore a particular guideline:
1. When applying the guideline would make the code less readable,
even for someone who is used to reading code that follows this PEP.
Going beyond 72 colums to make the comment more readable is exactly what
PEP 8 wants you to do.
This is no excuse for going beyond when you could just as well break the
line earlier.
There's a reason pycodestyle distinguishes between errors and warnings,
and "line too long" is a warning. We've been conditioned to conflate
warnings with errors by C's "the standard permits it, but you really
shouldn't" warnings. However, treating style warnings as errors is
exactly what PEP 8 calls a folly of little minds.
