On Tue, Mar 17, 2015 at 11:42 PM, Alexander Walters
<tritium-list@sdamon.com> wrote:
What coding style would be used for such a tool? PEP-8? What about a tool for those of us who believe that PEP-8 got a few things wrong?
What about for the tribal knowledge that pythonistas develop over time that are not part of the standard? Would such a tool include this?
I might be wrong, but I see PEP 8 as a living document. If the community believes parts of it are out of date, I would think it's better to update PEP 8 (or issue a replacement PEP) to reflect current thinking.
Any auto-styling tool included in the standard library would work best if it was based on a written "spec" like PEP 8 (granted, I don't think PEP 8 was meant to be a spec for programmatic implementation, but you get the idea).
If stuff is not part of PEP 8 that should be, or if parts of PEP 8 are agreed to be "wrong", then PEP 8 should be updated accordingly. Any auto-styling tool, I would hope, would just follow from PEP 8 (or a similar document). The tool should not be the specification.
On Tue, Mar 17, 2015 at 11:42 PM, Alexander Walters
<tritium-list@sdamon.com> wrote:
And what of third party tools that do the same thing? I have no evidence to support this, but I have the feeling that when the standard library includes something in a new space, third party work in that space slows (json and sqlite come to mind).
I see what you mean. Several people have made comments to this effect, and this is a good point.
I guess this is a separate discussion, but is there some way to offer users the advantages of having a library be included with Python without imposing the 2-year release cycle and additional burden on the library's developers?
This seems to be the root of the concern about including, for example, something like autopep8 with Python.
Good coding style really should not be something we ship in the library, it should be something we teach.