[Python-ideas] gofmt for Python: standardized styling as a language feature

[Nicholas Chammas]

On Tue, Mar 17, 2015 at 11:29 PM, Eli Bendersky <eliben at 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 at 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 <https://youtu.be/EBRMq2Ioxsc?t=49m23s>.


On Tue, Mar 17, 2015 at 11:42 PM, Alexander Walters <tritium-list at 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 at 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 at 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 at 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 <https://www.python.org/dev/peps/pep-0008/#id8>. 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150318/f3b25094/attachment.html>