[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