On 25 April 2014 17:52, Carl Meyer <c...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
