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

[Nicholas Chammas]

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/9b2f759b/attachment.html>