[Python-Dev] pep8 reasoning

[Nick Coghlan]

On 25 April 2014 17:52, Carl Meyer <carl at oddbird.net> wrote:
> On 04/25/2014 01:55 PM, Ethan Furman wrote:
>> On 04/25/2014 12:45 PM, Florent wrote:
>>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan:
> I think this fuss is unreasonable and unwarranted.
>
> I'd like to thank Florent for taking the time to maintain an
> extremely-useful tool that makes it feasible to keep to a consistent PEP
> 8 style throughout a large codebase with many contributors, and I think
> he should have the leeway as maintainer to make the necessary judgment
> calls about precisely which PEP 8 recommendations are reported precisely
> how by the tool, given that:
>
> - we aren't talking about real variance from the spirit or
> recommendations of PEP 8 (though you wouldn't know it from some of the
> rhetoric here about "personal preferences")

Yes we are. My name is on PEP 8 as one of the three co-authors, and my
request to downgrade anything in the "pep8" tools that is not
*explicitly* disallowed by the PEP to be a warning at most has been
ignored. If you read the GitHub issue, you can see I *want* to be able
to recommend this tool universally. But at the moment, I cannot, as
its name is a lie: it enforces rules I don't personally agree with,
yet claims to be based on a PEP I helped write.

There is a way to get changes made to the common guidelines in PEP 8:
you bring your case to python-dev and argue for the adoption of those
rules in the standard library.

If a tool doesn't claim to be speaking in my name, I don't care what
rules it enforces. If a tool adds extra warnings, I also don't care.
But "pep8" currently claims as errors code that is listed *in PEP 8
itself* as acceptable. I am *not* OK with that.

> - the tool makes it very easy to turn off whichever errors you don't
> prefer to enforce.

This is about the default behaviour, and claiming as errors things
that are explicitly listed in the PEP as OK.

> - PEP 8 changes regularly (as Florent noted, the offending code example
> was only added recently), and there is value in the automated tool
> maintaining some stability for its users.
>
> Personally, I would much rather see pep8.py err on the side of being too
> strict with PEP 8's recommendations than too loose. Again, it's not hard
> to turn off the ones you don't want.

No, this is exactly the *wrong* way to approach it. A tool laying
claim to PEP 8's authority should err on the side of *not* enforcing
rules that are not clearly rules - if more clarity is desired, then
ask for clarity from python-dev.

> If python-dev wants to control the precise behavior of pep8.py, bring it
> into the standard library and adopt maintenance of it. Otherwise, please
> give Florent some grace.

Note that I don't complain about the default behaviour of pylint,
pychecker, or any other linter tools. But by continuing to call the
tool "pep8", Florent is claiming the endorsement of the PEP 8 authors
and the consensus of python-dev for the tool's default behaviour (as
noted above, this makes it personal for me, as I am a co-author of PEP
8).

There is a very, very simple guideline that can be followed here:
anything which is not clearly and unambiguously disallowed in the PEP
itself should never be more than a warning in a tool that is called
"pep8".

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia