Switching from python-mode.el to python.el

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

From stackoverflow

• 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?

  fivebells : Thanks for your opinion, but it's rather authoritarian. I'm looking for a comparison of the packages' features, on a practical level. I don't care about the authors' perceived credentials.

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

  Carl Meyer : Using python.el from emacs-snapshot package in Ubuntu 8.04 (Emacs 23), I don't seem to have the python-complete-symbol function.

• 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

  paprika : I just tried this out with python-mode.el version 5.1.0 and couldn't reproduce it: docstrings work just fine with font locking. I don't think a bug like this would be present for a long time in *the* predominant python mode for Emacs, docstrings are everywhere, somebody would have catched the bad behavior pretty soon.

  paprika : Ah! *Now* I know what you mean... I just discovered this bug myself in a docstring: quoting *inside* a docstring does indeed break syntax highlighting.

• 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!