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

[Eli Bendersky]

On Wed, Mar 18, 2015 at 9:52 AM, Nicholas Chammas <
nicholas.chammas at gmail.com> wrote:

> 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`?
>

Yes, very familiar.


> What are the differences between the tool y'all are releasing and
> `autopep8`?
>
>
autopep8's scope is both smaller and larger. It only detects PEP8
violations and attempts to fix them, not restricting itself to whitespace.
Our tool works more like the gofmt tool mentioned in the beginning of the
thread - it pretty much only cares about formatting, and it auto-reformats
the code to its own liking, covering more whitespace-related stuff than
PEP8. Basically the idea is "forget about formatting your code, just run it
through the tool", which is a similar philosophy as gofmt (and
clang-format) and has been hugely successful for those tools/languages.

Eli



>
> 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
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150318/c1bfba78/attachment.html>