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! ;-) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com