[Python-Dev] pep8 reasoning

[Florent]

2014-04-25 18:10 GMT+02:00 Nick Coghlan <ncoghlan at 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