[Python-Dev] pep8 reasoning

[Donald Stufft]

On Apr 25, 2014, at 5:52 PM, 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:
>>>> 
>>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140425/9bcab52d/attachment-0001.sig>