Home Original page

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

Nicholas Chammas nicholas.chammas at gmail.com
Tue Mar 17 19:39:59 CET 2015 
I posted this via Google Groups and got a response back by email saying my 
post was rejected because I wasn't a list member. So I signed up via 
Mailman and resubmitted this post by mail. Not sure if I should expect a 
duplicate post to show up here on not... Apologies.

On Tuesday, March 17, 2015 at 2:13:31 PM UTC-4, Nicholas Chammas wrote:
>
> The Zen of Python <https://www.python.org/dev/peps/pep-0020/> says:
>
> There should be one— and preferably only one —obvious way to do it.
>
> Python already has a style guide in PEP 8 
> <https://www.python.org/dev/peps/pep-0008/>. More importantly, from a 
> practical standpoint, Python has automated third-party tools for checking 
> and enforcing PEP 8 guidelines:
>
>    - pep8 <https://pypi.python.org/pypi/pep8/>: Python style guide checker 
>    - autopep8 <https://pypi.python.org/pypi/autopep8/>: A tool that 
>    automatically formats Python code to conform to the PEP 8 style guide 
>
> I say “more importantly” because these tools are what make the style guide 
> alive. If a Python project of any non-trivial size is PEP 8-compliant, you 
> can bet it’s because the project contributors automated the process of 
> enforcing compliance using these or similar tools. (Certainly, some parts 
> of PEP 8 are hard to automate. But those parts that *can* be automated 
> have been, to the benefit of Python programmers everywhere.)
>
> Having a style guide provides benefits that I think are well-understood. 
> Additionally having a standardized style that can be *applied 
> automatically* makes whatever benefits of the style guide that much more 
> prevalent in the greater community and actually effective.
>
> As many of you may already know, the Go-lang folks have such a feature for 
> their language (though they call it formatting as opposed to styling). They 
> note:
>
> go fmt your code <http://blog.golang.org/go-fmt-your-code>:
>
> Gofmt <http://golang.org/cmd/gofmt/> is a tool that automatically formats 
> Go source code.
>
> Gofmt’d code is:
>
>    - easier to *write*: never worry about minor formatting concerns while 
>    hacking away, 
>    - easier to *read*: when all code looks the same you need not mentally 
>    convert others’ formatting style into something you can understand. 
>    - easier to *maintain*: mechanical changes to the source don’t cause 
>    unrelated changes to the file’s formatting; diffs show only the real 
>    changes. 
>    - *uncontroversial*: never have a debate about spacing or brace 
>    position ever again! 
>
>  Of course, we don’t worry about brace positions, but these benefits of a 
> standardized style carry over into any language. :)
>
> So, in the spirit of The Zen of Python, and taking a cue from Go-lang’s 
> gofmt <http://blog.golang.org/go-fmt-your-code>, I propose we promote 
> standardized auto-styling to a first-class language feature.
>
> UI-wise, I’m not sure how exactly we’d present this to the user. Perhaps 
> something like:
>
> python -m style script.py
>
> Don’t read too much into this UI suggestion, as I’m really not sure how it 
> would be implemented. The point is to expose some auto-styler as a standard 
> language tool—i.e. something like autopep8, but as a built-in utility.
>
> On running a command like that, script.py would automatically be updated 
> to conform to the standard style we want to promote. This is what gofmt 
> does for Go code.
>
> Promoting an auto-styler to be a first-class language feature builds on 
> the foundation laid in PEP 8 and in tools like pep8 and autopep8. It 
> helps reduce code style to more of a non-issue for Python projects than it 
> already is.
> ------------------------------
>
> *Side Note 1:* There was a previous python-ideas discussion about 
> introducing standardized formatting here 
> <https://groups.google.com/d/msg/python-ideas/ic-aPSvamS4/2lj53Em0VrsJ>, 
> but it was totally derailed by the OP’s suggestion that the formatter 
> introduce block delimiters. I am proposing no such thing here.
>
> *Side Note 2:* I found these additional comments 
> <http://blog.golang.org/go-fmt-your-code> about gofmt interesting:
>
> Gofmt also enables gofix <http://golang.org/cmd/fix/>, which can make 
> arbitrarily complex source transformations. Gofix was an invaluable tool 
> during the early days when we regularly made breaking changes to the 
> language and libraries.
>
> Introducing Gofix <http://blog.golang.org/introducing-gofix>:
>
> Gofix gives us the ability to fix mistakes or completely rethink package 
> APIs without worrying about the cost of converting existing code.
>
> Python has its own analog to gofix in 2to3 
> <https://docs.python.org/3/library/2to3.html>, though that was built for 
> a specific migration rather than as a regular language feature. I wonder if 
> having a gofmt analog in Python would similarly facilitate future 
> migrations, though I doubt we’ll ever have a big as migration as the 2-to-3 
> one.
> ​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150317/bf006c33/attachment-0001.html>
More information about the Python-ideas mailing list