Switching from python-mode.el to python.el

Question

I recently tried switching from using python-mode.el to python.el for editing python files in emacs, found the experience a little alien and unproductive, and scurried back. I've been using python-mode.el for something like ten years, so perhaps I'm a little set in my ways. I'd be interested in hearing from anyone who's carefully evaluated the two modes, in particular of the pros and cons they perceive of each and how their work generally interacts with the features specific to python.el.

The two major issues for me with python.el were

1. Each buffer visiting a python file gets its own inferior interactive python shell. I am used to doing development in one interactive shell and sharing data between python files. (Might seem like bad practice from a software-engineering perspective, but I'm usually working with huge datasets which take a while to load into memory.)

2. The skeleton-mode support in python.el, which seemed absolutely gratuitous (python's syntax makes such automation unnecessary) and badly designed (for instance, it has no knowledge of "for" loop generator expressions or "<expr 1> if <cond> else <expr 2>" expressions, so you have to go back and remove the colons it helpfully inserts after insisting that you enter the expression clauses in the minibuffer.) I couldn't figure out how to turn it off. There was a python.el variable which claimed to control this, but it didn't seem to work. It could be that the version of python.el I was using was broken (it came from the debian emacs-snapshot package) so if anyone knows of an up-to-date version of it, I'd like to hear about it. (I had the same problem with the version in CVS emacs as of approximately two weeks ago.)

Answer 1

python-mode.el is written by the Python community. python.el is written by the emacs community. I've used python-mode.el for as long as I can remember and python.el doesn't even come close to the standards of python-mode.el. I trust the Python community better than the Emacs community to come up with a decent mode file. Just stick with python-mode.el, is there really a reason not to?

Answer 2

For what it's worth, I do not see the behavior you are seeing in issue #1, "Each buffer visiting a python file gets its own inferior interactive python shell."

This is what I did using python.el from Emacs 22.2.

C-x C-f foo.py [insert: print "foo"]

C-x C-f bar.py [insert: print "bar"]

C-c C-z [*Python* buffer appears]

C-x o

C-c C-l RET ["bar" is printed in *Python*]

C-x b foo.py RET

C-c C-l RET ["foo" is printed in the same *Python* buffer]

Therefore the two files are sharing the same inferior python shell. Perhaps there is some unforeseen interaction between your personal customizations of python-mode and the default behaviors of python.el. Have you tried using python.el without your .emacs customizations and checking if it behaves the same way?

The major feature addition of python.el over python-mode is the symbol completion function python-complete-symbol. You can add something like this

(define-key inferior-python-mode-map "\C-c\t" 'python-complete-symbol)

Then typing

>>> import os
>>> os.f[C-c TAB]

you'll get a *Completions* buffer containing

Click <mouse-2> on a completion to select it.
In this buffer, type RET to select the completion near point.

Possible completions are:
os.fchdir                          os.fdatasync
os.fdopen                          os.fork
os.forkpty                         os.fpathconf
os.fstat                           os.fstatvfs
os.fsync                           os.ftruncate

It'll work in .py file buffers too.

Answer 3

python-mode.el has no support triple-quoted strings, so if your program contains long docstrings, all the syntax coloring (and associated syntaxic features) tends to break down.

my .02

Answer 4

1. I can't reproduce this behavior on Emacs v23.1, this must have been changed since then.

2. Forget about any mode's skeleton support and use the hyper-advanced and extensible yasnippet instead, it's really worth a try!