emacs as a Python IDE: a sorry tale

Anyone working extensively with computers should, once in a while, invest in perfecting their environment.  It’s rarely an appealing task but it truly is an investment, and is also usually well worth the effort despite the cost of a few hours, half a day or even a day.  Indeed, I still remember, eons ago, perfecting my X windows manager configuration, or my shell configuration, and I know without any doubt the benefits these painful moments have brought in the many years since then.

While most long time emacs users, have a boatload of lisp hacks and configuration tweaks they swear by, I do not.  I have, somehow, always managed to be content with relatively minor customizations.

Given how much Python I have been writing lately, I finally decided to look into what I might be missing out on, hoping to turn emacs into a much better IDE than the little bits that I have been living with (custom font-lock colors, dynamic abbreviations and TAGS).

Emacs Python modes

It was an incredibly frustrating exercise.  The internet is full of advice, often conflicting ones as there is not one Python mode, but 4.  And herein lies much of the pain.

1. python-mode.el – The first Python mode, distributed with Python itself and XEmacs
2. python.el – Distributed with GNU Emacs, starting with version 22.1 (June 2007)
3. python.el – A fork of the above, by Dave Love, the original(?) author
4. python.el – The newcomer (February 2011)

Confused yet?

There have been talks about merging #1 and #2, but they don’t seem all that serious (any more?), and there is a certain apparent bitterness around the whole issue.  (See this thread and this other thread if you are really curious.)

And yet, there may finally be light at the end of the tunnel with the arrival of Fabián Gallina and his new implementation which may be headed for adoption by GNU Emacs according to this last thread.

What is a Python developer to do?

As I mentioned above, there are many solutions on the internet, but there is no clear apparent winner.  Furthermore, most solutions include so many different pieces that it’s a convoluted puzzle, and it quickly becomes difficult to see what each piece adds.

Besides choosing one of the above modes, the most common suggestions are to use ropemacs and a syntax checker with flymake (avaliable in Emacs 23).

1. To get ropemacs to work, you will need to install rope, ropemode and finally ropemacs, all this without forgetting Pymacs
2. Running a syntax checker is a bit easier (except with Dave Love’s fork of python.el) and is mostly a matter of choosing which to use:
   • pylint which requires logilab-common and logilab-astng
   • pyflakes
   • pep8
   • pychecker

Taking the easy way out

Having played with most of the above, I settled on sticking with GNU Emacs’ python.el for the time being.  It is certainly disappointing, and this mode is undoubtedly imperfect but it seems to work well enough for me, and I am therefore content to wait for the dust to settle.  Hopefully, Fabián Gallina’s new implementation will conquer the world, and if he seems headed this way, I will probably try it in a little while once it has matured a bit.

I found the biggest improvements to my setup to come from the auto complete mode and setting up pyflakes.  ropemacs is interesting, but it can be quite slow on bigger projects, something I simply found intolerable.

auto complete mode is trivial to setup, and I used the following for pyflakes:

• Matthew Kennedy’s flymake minor mode
• Roger Hu’s pyflakes setup (to use /tmp for temporary files)

None of this gives me intelligent completion, but it is not clear to that one can really do a good job with a dynamic language like Python, and if intellisense is unreliable or worse unpredictable, then it will cause you plenty of pain (by misdirecting you).