2014-04-25 18:10 GMT+02:00 Nick Coghlan <ncogh...@gmail.com>: > > 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". Especially don't do > that if you're then going to ignore a core developer that calls you on > misappropriating python-dev's authority :( > > Regards, > Nick. > > P.S. https://github.com/jcrocholl/pep8/issues/256 >
I am the current maintainer of this 'pep8' tool which was mentionned in a previous message. The tool was first published in 2006 by its original author. I take the feedbacks of the users in consideration, as much as I can. When something is unambiguously identified as a bug, I try to merge a patch in a timely manner. If it is an enhancement or a change of behavior, it is not in the priority list, of course. 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 first concern is about 4 spaces indentation for continuation lines. For this point, the text of the PEP says "Use 4 spaces per indentation level", which lets room for interpretation (like some other parts of the PEP). However I changed some stuff in v1.5 to better isolate this case, so the user can add E121 safely to the ignore list: https://github.com/jcrocholl/pep8/blob/master/CHANGES.txt#L96-L105 The second concern is about compound statements, which are "generally discouraged" in the words of the PEP. Technically, there's no obvious way to implement "generally discouraged" in code. The compromise is to disable the check E701 and "use your own judgment" instead, if you feel it does not match you project's style guide. By the way, the example reported in #256 was only added last year to the PEP: def f(x): return 2*x And if we look closer to the PEP 8 history for the last two years (since March 2012), there were lots of changes and I've already updated the tool to catch up with some of them. However the tool has a large base of users, and I try to preserve some stability instead of removing features every time someone has an objection. In such case, what I recommend to the users is to configure the tool to ignore the checks which conflict with their own habits or conventions. I wrote some words in the documentation, one year ago, to explain what is the purpose of the tool and its limitations. There's no claim of any endorsement implicit or explicit by the PSF, the PSU or any other python developer :-) http://pep8.readthedocs.org/en/latest/intro.html#disclaimer I'm sorry if you felt that my previous answer was an offense to some python-dev authority, this is not intentional. Kind regards, -- Florent _______________________________________________ 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
