[Python-Dev] pep8 reasoning

[Carl Meyer]

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