PythonTidy is a utility to reformat Python source code according to Python PEP-8 style guide. It cleans up your source code and makes it adhere the community recommended practices.
PythonTidy does not lint or validate Python source code – it rewrites it to follow PEP-8 (and other) configured rules.
PythonTidy is very useful if you need to
- clean up old codebases and make them to embrace PEP-8
- work with people who do not yet follow strict programming disciplines (it helps to convert them if you can make them use a text editor which highlights the errors on background)
Adhering PEP-8 is also must when you are using a text editor which highlights linting errors in your source code while typing. If your source code is full of unneeded style errors you’ll miss the actual linting errors among them.
PythonTidy was created by Chuck Rhode.
1. PythonTidy plug-in for Sublime Text 2
The basic PythonTidy works from the command line. However, in this blog I show how to use PythonTidy plugin, by Andreas Zeidler, in Sublime Text 2 code editor with one key press integration. Sublime Text 2 has very powerful Python linting support through SublimeLinterl package, highlighting style and linting errors when you type.
First install PythonTidy using git (note: Sublime Text 2 own package control installer does not work due to usage of Git submodules, you need to do this from command line).
Below is a screenshot with two style errors (no space after comma, bad number of newlines between module main level code blocks).
Now you simply press CONTRL+CMD+ALT+T: your source is fixed:
2. Configuring PythonTidy for Sublime Text 2
PythonTidy uses ~/.pythontidy.xml configuration file. A default setting value which most people probably want to change is the line length – PythonTidy shortens your line to 76 characters by default as recommended by PEP-8, and this is really quite short for the modern widescreens, wasting a lot of space. (I know there are some crazy people using tmux + vim + some other terminal stuff from golden early 80s and splitting their screen to 12 mini squares, but most of us don’t do that…)
Configuration options are explained in PythonTidyWrapper.py. More example settings are available in this Gist. Here is what I threw in the config:
<config> <parm name="COL_LIMIT" value="int(1000)" /> <parm name="SHEBANG" value="" /> <parm name="PARENTHESIZE_TUPLE_DISPLAY" value="bool(False)" /> <parm name="ADD_BLANK_LINES_AROUND_COMMENTS" value="bool(False)" /> <parm name="ADD_BLANK_LINE_AFTER_DOC_STRING" value="bool(False)" /> <parm name="MAX_SEPS_FUNC_DEF" value="int(99)" /> <parm name="MAX_SEPS_FUNC_REF" value="int(99)" /> <parm name="WRAP_DOC_STRINGS" value="bool(False)" /> <parm name="NORMALIZE_DOC_STRINGS" value="bool(False)" /> </config>
Note: Looks like you cannot add XML comments in config for now.
3. Other text editors
Please post as a comment if you know any other text editors with PythonTidy or background PEP-8’ing support. I am especially interest how one could intergrate this with Eclipse + PyDev.
Also more Sublime Text 2 tips for Python developers.
Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+
you can use SublimeAutoPEP8 (https://github.com/wistful/SublimeAutoPEP8) plugin which uses autopep8 (https://github.com/hhatto/autopep8) module.
Isn’t SublimeLinter that lint your code ?
Don’t think SublimeCodeIntel do that, but maybe I’m wrong.
Sorry for the mixup- fixed that!
Pingback: In the News: 2012-11-29 | Klaus' Korner
How does the pythontidy compare to autopep8 ?
Today was the first time I heard about autopep8, but I have nothing to complain about PythonTidy and I am a happy user with it. If someone has experience on both of them, please tell us 🙂
For using PythonTidy in PyDev look at here: https://bear330.wordpress.com/2007/10/30/using-pythontidy-in-pydev-as-code-formatter/
“A Foolish Consistency is the Hobgoblin of Little Minds”
Taken from PEP8. http://www.peps.io/8/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
Remember its important to know when to use and not to use something like this.
I use that plugin myself.
I adhere to the 80 chars limit, not because of tmux and vim, but because I like be able to have as many files of source code open in parallel as possible. Also, I still own a laptop with 1366px width, its really hard to get 2 files open in parallel even with 80 chars limit.
I am against the advice to use this plugin to clean up old code. Strongly actually. Well written code often is already very pep8 compliant. If some code is really ugly and sublime shows lots of warning, the code might need to be restructured instead of reindented. I only use the plugin to write my well written code (lol) lazily and then press the reformat button to unify my usage of ‘ and “, spacing and all this stuff.
Patrick: Different people face different problems, so giving out general advice “don’t do it” against old codebase is overbroad. It might help many people and save a lot of time even if it’s not the solution itself.
Couldn’t get this to work for me for whatever reason… AutoPep8 works great and installs from package manager.
I did not want to suggest not to use the plugin to clean up old code, I just meant to be careful to suggest it so directly.
Thats not what I wrote, unfortunately 😉
I looked up some bad examples:
https://github.com/plone/Products.CMFPlone/pull/14/files#L10L173
https://github.com/plone/Products.CMFPlone/pull/14/files#L12L252 (slightly)
https://github.com/plone/Products.CMFPlone/pull/14/files#L12R490 (slightly)
https://github.com/plone/Products.CMFPlone/pull/14/files#L12R804 (slightly)
https://github.com/plone/Products.CMFPlone/pull/14/files#L47L20
This last example is the best one. If one really wants to adhere to the line limit (I usually want to) one would have created aliases for the long methods, maybe like this:
changeSiteProperties = portal_properties.site_properties.manage_changeProperties
changeNavtreeProperties = portal_properties.navtree_properties.manage_changeProperties
Ironically, all I complain about are bad style line breaks, which you do suggest to switch of anyways.
So let me rephrase a suggestion I’d agree with:
clean up old codebases and make them to embrace PEP-8, if you keep the line breaking settings, be careful not to look stupid because of semantically ugly line breaks