On Mar 17, 2015, at 11:31 AM, Nicholas Chammas <nicholas.chammas@gmail.com> wrote:

The Zen of Python says:

There should be one— and preferably only one —obvious way to do it.

As someone who uses autopep8 regularly but has at least once had resistance to getting into a team's workflow, +1 on the idea. The analogy with gofmt isn't perfect because gofmt only deals with some simple issues where there's an unambiguous 100%-clear standard, while PEP 8 includes a wide range of guidelines that are usually but not always consistent and appropriate, but that (obviously) doesn't mean autopep8 is an impossible or pointless non-starter.

So, is your proposal that autopep8 (and therefore pep8, on which it depends) be added to the stdlib with only minor changes? If so:

 * You'd probably want to ask whether Hideo Hattori and Johann C. Rocholl are willing to relicense and contribute their code, and maintain it for years to come, before asking whether Python will accept the result.
 * Will it be easy to transform a new version of the PyPI libraries into a new version of the stdlib module in some mostly-automated way for each new Python release?
 * Given that Python updates less often than pep8 and autopep8, will it generally be "good enough" to use the autopep8 1.1.3 that came with your Python 3.5 instead of installing the 1.1.7 that's on PyPI? What if you're still using Python 3.5 in another two years, and Python 3.6 came with 1.2.1, and 1.2.5 is on PyPI; is using 1.1.3 still a good idea? (Compare with pysqlite; I've used sqlite3 many times, and only wanted to get the newer version twice--and once just because it was the easiest way to build with a local variant of the C library on Windows.)
 * Are all of the current features and bugs (see issues on GitHub) acceptable as-is for the stdlib today?

If the answers to those questions is "yes", this seems like the way to go. Otherwise, you're probably suggesting someone either fork the existing projects or write a brand new one (and as the one with the itch and the ideas, who better than you?).

Python already has a style guide in PEP 8. More importantly, from a practical standpoint, Python has automated third-party tools for checking and enforcing PEP 8 guidelines:

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:

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, 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, 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 about gofmt interesting:

Gofmt also enables gofix, 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:

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, 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.

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/