[Python-Dev] pep8 reasoning

[Steven D'Aprano]

On Fri, Apr 25, 2014 at 08:13:35PM -0400, Donald Stufft wrote:

> I agree that I’ve never taken the name to mean that you’re claiming any
> sort of endorsement. There are a *vast* number of projects that implement
> something that was defined somewhere else and I don’t think any reasonable
> person can assume that all of those tools are endorsed by the authors
> of what they are implementing.

I think that is wrong. "Endorsed" is the wrong word -- what's 
important is that if package PEP8 "checks for PEP 8 compliance", then if 
package PEP8 checks for foo, then people assume that foo-checking is 
specified by PEP 8 -- whether it does or not.

If something claims to be "JSON", say, then most 
people would expect that by default it would implement the JSON standard 
rather than some tweaked version of almost JSON. If their JSON library 
fails to match the standard, a significant number of people will assume 
that the library's non-standard version *is* the standard.

It may even become the de-facto standard, regardless of what the 
standard actually says, and so introduce ambiguity where there was none. 
E.g. consider browser's treatment of ISO-8859-1 as Windows-1252.

People and corporations often take this sort of stuff really seriously, 
and I'm not surprised that Nick feels as strongly as he does. I would 
too. Try releasing a package using the name "iPhone" without Apple's 
approval:

https://developer.apple.com/softwarelicensing/index.php

In this case, I too would have assumed that a package calling itself 
"PEP8" checks for compliance with PEP 8, and that any differences 
between PEP 8 and the package is a bug in the package. Providing the 
ability to turn on or off checks, or make them more or less strict, is 
okay, but I would expect that by default it should check for PEP 8 
compliance, exactly PEP 8 compliance, and nothing but PEP 8 compliance.



-- 
Steven