30

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

4

6 回答 6

4

对于它的价值，我没有看到您在问题 #1 中看到的行为，“每个访问 python 文件的缓冲区都有自己的劣质交互式 python shell。”

这就是我使用 Emacs 22.2 中的 python.el 所做的。

Cx Cf foo.py [插入：打印“foo”]

Cx Cf bar.py [插入：打印“bar”]

Cc Cz [*Python* 缓冲区出现]

Cxo

Cc Cl RET ["bar" 在 *Python* 中打印]

Cx b foo.py RET

Cc Cl RET ["foo" 打印在同一个 *Python* 缓冲区中]

因此，这两个文件共享相同的劣质 python shell。也许在您对 python-mode 的个人定制和 python.el 的默认行为之间存在一些无法预料的交互。您是否尝试过在没有 .emacs 自定义的情况下使用 python.el 并检查其行为是否相同？

python.el 在 python-mode 上的主要特性是符号补全函数 python-complete-symbol。你可以添加这样的东西

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

然后输入

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

你会得到一个 *Completions* 缓冲区，其中包含

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

它也可以在 .py 文件缓冲区中工作。

于 2008-12-15T15:34:00.567 回答
3

  1. 我无法在 Emacs v23.1 上重现这种行为，从那以后肯定已经改变了。

  2. 忘掉任何模式的骨架支持，改用超高级和可扩展的yasnippet，真的值得一试！

于 2010-03-31T15:24:02.107 回答
2

请注意，随着事情的变化，这里所说的几乎所有内容都已过时。

python-mode.el 命令基本上都以“py-”为前缀，您应该能够同时使用这两个命令，而不管先加载哪个命令。

python-mode.el 不卸载 python.el；在重新定义的 python-mode-map 旁边。

差异在显示的菜单和按键设置中，但是，最后加载的将决定。

于 2012-11-07T10:21:47.263 回答
1

python-mode.el 不支持三引号字符串，因此如果您的程序包含长文档字符串，所有语法着色（和相关的语法特征）往往会崩溃。

我的 .02

于 2009-06-17T07:08:48.227 回答
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?

于 2008-12-12T12:20:43.240 回答
0

Debian 已经删除了 python-mode 包，唉，所以我不得不尝试 python.el。我加载它并运行“describe-bindings”。它似乎是为那些认为c-X ;是注释一行 Python 代码的直观绑定的 elisp 编码人员而设计的。（哇。）此外，我根本没有办法评论代码区域，或者更确切地说，没有与其中的字符串“region”和“comment”绑定。

好的旧 python 模式仍然可以通过git clone https://gitlab.com/python-mode-devs/python-mode.git. 它是在一周前在撰写本文时最后一次编辑的，因此可以肯定地假设它没有被放弃。

于 2022-03-03T20:53:26.747 回答