[Python-Dev] pep8 reasoning

[Stephen J. Turnbull]

Chris Withers writes:
 > On 25/04/2014 04:03, Barry Warsaw wrote:

 > > I'd say it depends.  If the code is going to be shared with
 > > people outside of your organization (e.g. open source libraries),
 > > then there's a strong motivation to be consistent throughout the
 > > community, which means PEP 8.
 > 
 > Right, so for me this means even in a private code base, there are big 
 > benefits to using PEP 8; everything looks the same, whether it's a third 
 > party library, python core or your own code...

Indeed.  But channeling the FLUFL here, I would say that in your
situation where people have already developed a large code base that
apparently isn't shared much (if at all) outside the organization,
they've already paid the price of nonconformity for the existing code
base.  If there's a formal standard, and you don't expect the
"insiders only" policy to change soon (assuming it actually exists), I
don't see why you would push for a change to PEP 8 at all.

If you *don't* have a formal standard and existing code is a mixture
of styles, I'd be very tempted to say "PEP 8 for new modules" (even if
some of the mix is consistent -- for example all the ex-C++
programmers like CamelCase).  Ditto if you're going to be developing
modules to publish as OSS.

And from *outside* of your organization, it's a no-brainer.  PEP 8 is
what Python itself and most 3rd party OSS modules use.  Getting your
people to use PEP 8 will make it a lot easier for them to learn to
read Python core and stdlib code, and once they start reading --- why,
the obvious next step is *contributing*.  Yay! ;-)