44

So I have Emacs 24.3 and with it comes a quite recent python.el file providing a Python mode for editing.

But I keep reading that there is a python-mode.el on Launchpad, and comparing the two files it jumps out to me that the former is under 4000 lines, while the latter is almost 20000. This suggests that the latter is much more feature-rich.

And I can't find any online feature comparison about them, documentation, or at least a list about the features for each of them. Yep, there is syntax highlighting and embedded interpreter, but what about completion in shell buffer, completion in source file buffer, autoindent, reindent etc.

So what are the important features of these modes? (Or any other Python mode for Emacs which you recommend.) Please provide detailed answers.

Improve this question
3
  • 3
    LoC is not a good measure to compare the features of both modes. Being part of Emacs trunk for some time now, python.el likely makes more use of built-in Emacs APIs for completion, interpreter handling, etc., whereas python-mode.el probably re-invents some wheels. That said, I've been using python.el for a long time, even before it became part of Emacs, and haven't missed anything. Commented Mar 28, 2013 at 11:15
  • a major part of code in python-mode.el is taken by the menu, like ["Execute statement" py-execute-statement :help "py-execute-statement' Send statement at point to Python interpreter. "] ["Execute block" py-execute-block :help "py-execute-block' Send block at point to Python interpreter. "] Commented Apr 6, 2013 at 15:21
  • Please explain the downvote. Commented Nov 13, 2014 at 8:19

2 Answers 2

Reset to default
22

I was python-mode.el user once but quit using it a year ago because I felt the way it was developed was not well organized. Here is a list from the note I took at that time. But I need to warn you that almost a year is passed since then so the situation may be changed.

  1. Many copy & paste functions.
  2. Many accidentally working code. For example, not passing around variables but using implicit binding. This produces many compile errors (and will not work if you change it to lexical scope).
  3. Rough granularity of commit. I send a patch, and it was committed with unrelated changes.

One thing I like about python-mode.el is it comes with automated test set (although I've never run it). python.el does not have a test set yet. But I know the author of python.el is writing it now.

While python.el is compact, it does not mean you get poor functionality. It is more like keeping core small and let others to extend it by providing concise API. Same author of python.el wrote python-django.el to extend python.el for django projects. I wrote auto-completion plugin for Python called Jedi.el and advanced IPython plugin called EIN. Both of them have better support for python.el than python-mode.el (well, that's because I don't use python-mode.el, though).

I had a few thing I missed from python-mode.el first, but they are quickly fixed in python.el (Of course, this probably means that I was not using so much functionality in python-mode.el).

what about completion in shell buffer, completion in source file buffer, autoindent, reindent etc.

  • completion in shell buffer: It sort of works in both python.el and python-mode.el. But sometimes it does not work if you have bad combination of Emacs version and python(-mode).el version. So probably python.el is safer in this manner. But if you want better solution, use EIN :)

  • completion in source file buffer: Just use Jedi.el :)

  • autoindent/reindent: I don't know which one is better in performance-wise. However, keybind for return differs one to the other. In python-mode.el, if you type RET you get autoindent. In python.el, RET does not give you indentation and you should use C-j instead. Actually C-j for newline+indentation is universal behavior in Emacs. So python.el is better if you do programming in other languages.

Improve this answer
Sign up to request clarification or add additional context in comments.

11 Comments

I will not file bug reports bug reports because I am not using python-mode.el. The reasons to quit using python-mode.el, including "rough granularity of commit, are written in my answer. No, granularity of commit is not pointless for me. It's just how developers care about their code base, IMHO.
Claiming "accidentally working code" when pointing at dynamic binding is false likewise. Dynamic binding is closely linked to Emacs success story even if having not many defenders nowedays.
Well, if it is not "accidentally working code" then it is not well written code. python-mode.el was using dynamical binding with non-prefixed variables, at least when I was using python-mode.el. If you want dynamical binding, I think you should declare it with defvar and put proper prefix.
tkf: Dynamic binding has been the Emacs way for decades (and continues to provide enormous benefits, as it has always done). Lexical binding has been in a release version of Emacs for less than one year. Criticising a library which dates back to 1992 for not being designed with lexical binding in mind is silly (as is the idea that people might elect to enable lexical binding for some arbitrary library and assume everything will continue to work).
@phils All I am saying that Emacs lisp program that follows conventional rules can be run on lexical mode without pain. This is why a lot of builtin Emacs lisp program can be converted to lexical mode with not much effort. But I guess talking about lexical mode is not the best way to convince you and Andreas Röhler that python-mode.el does not follow the conventional rules.
|
6

Being heavily involved in developing python-mode.el last years, my comment probably is biased: Recommend to stay with python.el for Emacs beginners. Also its author deserves credit for some useful approaches.

python-mode.el is designed to boost edits productivity. It makes it easy to run or execute via python2 and python3 or IPython shells in parallel.

It reduces number of needed keystrokes providing tailored commands. It makes edits faster, assists programming by speech, macro-driven input etc.

Supports Python language features not known from python.el currently:

py-up, py-down - travelling nested blocks

Avoid typos fetching forms at point, a clause for example:

py-backward-clause py-copy-clause py-down-clause

...

No need to customize when testing different versions:

py-execute-clause-python2 py-execute-clause-python3 py-execute-clause-ipython

...

  • notion of finer grained parts - py-expression, py-minor-expression
  • commands running versioned and paralleled (I)Python-executables, no need to re-define the default Python
  • largely removing the need of an active region marked before, see py-execute-line and a whole bunch more

To get an overview, have a look at the menu. Directory "doc" lists commands.

As the quality of code is raised: a way to compare both modes probably is checking for the bugs listed in http://debbugs.gnu.org/. See for example bug #15510, #16875; or http://lists.gnu.org/archive/html/help-gnu-emacs/2014-04/msg00250.html

Commented at "rough granularity of commit" already: While tkf basically is right looking for smaller pieces, sometimes conditions make me leave the rule. Considerable parts are not written by hand, but by programs residing in directory "devel". They create files used in development branch frist - i.e. components-python-mode. When starting a new feature it's often not obvious if the path chosen is fruitful. After a hundred would-be-commits or so it still might turn out impossible or not so recommendable. Instead of posting all the meanders, used to keep that experimental branch for several days in these cases and check in when tests passed.

BTW assume tkf refers not to compile-errors --which would be looked for instantly-- but compiler warnings. Unfortunately Emacs mixes warning about backed style preferences with real errors.

Improve this answer

2 Comments

Andreas - When you said "Have a look at the menu", where exactly is that menu? Is there a document that shows explains these commands?
@user815423426 See gnu.org/software/emacs/manual/html_node/emacs/Menu-Bar.html. BTW assume from your question you are new to Emacs: don't start with advanced features as debugger-sessions. Start simply editing, lower the learning curve, it's steep enough with Emacs. Cheers.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.