On Apr 25, 2014, at 5:52 PM, 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: >>>> >>>> And if you're going to publish a tool to enforce your *personal* style >>>> guide and include your own custom rules that the "this is OK" examples >>>> in PEP 8 fail to satisfy, don't call it "pep8". >>> >>> Two cases where signaled in the issue #256 last month, where the tool >>> is arguably not compliant with some of the current conventions of the >>> PEP. >>> I've highlighted the reasons behind these checkers in the issue >>> tracker directly. >>> I disagree that they are in direct opposition with the PEP 8 coding >>> conventions, though. >> >> The problem is that you've named it pep8. To me, that means I can run >> it and get PEP 8 results. If I have to add a manual configuration to >> get actual PEP 8 semantics, it's a buggy tool. >> >> For a similar example, I am the author/maintainer of enum34, which >> purports to be the backport of Python's 3.4 enum class. While I could >> go and make changes to it to better match my style, or even the styles >> of other users, calling it enum34 after that would be misleading as some >> one couldn't then switch from using enum34 in Python 3.2 to using the >> default enum in Python 3.4. >> >> If you had extra switches to turn on extra behavior, that would be >> fine. Leaving it as it is, and calling it something else would be >> fine. But as it stands now, with the name of pep8 and the behavior of >> failing on the PEP 8 document... well, that's false advertising. > > 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") > > - the tool makes it very easy to turn off whichever errors you don't > prefer to enforce. > > - 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. > > 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. > > Carl
Carl’s post mirrors my own thoughts and it’s said much better than I could have. pep8.py doesn’t violate PEP8, it just takes a stricter view of it. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
