On Tue, Mar 17, 2015 at 11:29 PM, Eli Bendersky <eliben@gmail.com> wrote:
We (at Google) are just on the verge of releasing an open-source tool for auto-formatting of Python code.

Interesting. Are y'all familiar with `autopep8`? What are the differences between the tool y'all are releasing and `autopep8`?


On Tue, Mar 17, 2015 at 11:29 PM, Eli Bendersky <eliben@gmail.com> wrote:
P.S. I'm also against such a tool being a part of the Python distribution, at least in the near term. A tool/library has to first prove itself outside of core for a while, and only when/if it proves to be widely used and stable, an incorporation into core should be considered. The stdlib is big as it is, and any additional code is a burden on all core developers. Incorporation into the stdlib also imposes a very slow pace of development/release on said library/tool, and hence should only be considered when it's been extremely stable for a while.

This makes sense. In fact, I recently watched a keynote that Guido gave and he said something similar.


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.


On Tue, Mar 17, 2015 at 11:42 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
Good coding style really should not be something we ship in the library, it should be something we teach.

This point is orthogonal to the discussion of whether or not to package an auto-styler, but there are many style points that are so mechanical I see little benefit in expending energy on teaching them. Best would be to automate as much of it away so that people can focus on bigger problems like, what is the right abstraction, did I design this API well, etc.

Put differently, consider the following straw man: "Good memory management should not be something we ship in the language, it should be something we teach."

There is always something to teach. But when we can automate part of the problem away, I think we generally should.


On Wed, Mar 18, 2015 at 2:38 AM, Ian Lee <ianlee1521@gmail.com> wrote:
And perhaps more to the point, should PEP-8 (and if so how), evolve over time to incorporate newer ideas that the community has now moved towards accepting as the "more Pythonic way to do things" now with the benefit of additional hindsight.

I consider PEP 8 to be a living document. That is, it is already changing with time. For example, I see that though PEP 8 was created in 2001, it was updated in 2013. I assume it will continue to be updated as accepted standards change.


On Wed, Mar 18, 2015 at 4:52 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Not necessarily. This list frequently includes half-baked ideas, but the
"bigger" the proposal, the more baked it should be to be taken
seriously.

Duly noted!

Nick