[Python-Dev] pep8 reasoning

[Stephen J. Turnbull]

Carl Meyer writes:

 > 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,

I would too.

N.B. Nick's complaints are a sort of left-handed compliment, too.

 > 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:

Of course.  But whether an example in the PEP passes or not is *not* a
judgment call at all, IMO.  Do you think that it is?

 > - 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")

That parenthetical remark was unnecessary, and at least in my case, I
understood very well that there is no "real" variance.  I disagree
with the implied requirements, however.  A program *intended to test
standard conformance* MUST (in the sense of RFC 2119) aspire to a
higher standard than "in the spirit", don't you think?  Anyway, that's
what I think.

 > - the tool makes it very easy to turn off whichever errors you
 > don't prefer to enforce.

This is precisely backward.  *I* have no errors I prefer to enforce or
not to enforce.  I want "PEP 8 conformance", I don't want to think
or make judgments about individual recommendations in PEP 8.  I want
to leave that up to the PEP 8 maintainers.

I suspect that is a common use case.

 > - 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.

Achieving "some" stability would not be difficult: version the error
sets of the tool, and provide a switch to invoke specific versions.
Each version could be dated, as well, to allow such stability without
knowing the precise content of the version of PEP 8 or pep8.py.

I personally would not use such a switch, however.  I would either
change my code to conform to current PEP 8, or not. ;-)

 > 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.

Again, for many users of the tool, that is precisely *not* why they
want to use the tool.  They want to delegate the decision of which
rules to enforce to the PEP 8 authors.

Since *you* have preferences, I repeat your words back to you: it's
not hard to turn on the ones you want.  (Or it needn't be.)

 > 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.

Note that what Nick is complaining about is not that pep8.py varies
from PEP 8 -- that's inevitable -- but rather that the variation is
not *acknowledged* as a bug.

So python-dev (but you really mean Nick) doesn't want to control the
precise behavior of pep8.py, as code.  What Nick wants is for code
*bearing the name* to conform to the PEP it was named for.  For users
who want PEP 8 conformance merely because it is the standard, that's
exactly right.  For those of you who want to pick and choose which
rules to follow and how strictly, the name doesn't much matter, does
it?  I think that in naming we should consider the use cases of those
who depend on the name to be meaningful as higher priority than those
who don't, but make their own judgments anyway.

Regards,