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. -- ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4