Emacs 的 Python 模式比较答案

【问题标题】：Comparison of Python modes for EmacsEmacs 的 Python 模式比较
【发布时间】：2013-03-18 05:19:43
【问题描述】：

所以我有 Emacs 24.3，它附带了一个相当新的 python.el 文件，提供 Python 模式进行编辑。

但我一直读到Launchpad 上有一个python-mode.el，比较两个文件，我发现前者不到 4000 行，而后者几乎是 20000 行。这表明后者是功能更丰富。

而且我找不到任何关于它们的在线功能比较、文档，或者至少是关于它们每个功能的列表。是的，有语法高亮和嵌入式解释器，但是在 shell 缓冲区中完成、在源文件缓冲区中完成、自动缩进、重新缩进等呢？

那么这些模式的重要特点是什么？（或您推荐的 Emacs 的任何其他 Python 模式。）请提供详细答案。

【问题讨论】：

LoC 不是比较两种模式特性的好方法。一段时间以来，作为 Emacs 主干的一部分，python.el 可能更多地使用内置的 Emacs API 来完成、解释器处理等，而python-mode.el 可能重新发明了一些轮子。也就是说，我已经使用 python.el 很长时间了，甚至在它成为 Emacs 的一部分之前，并且没有错过任何东西。
python-mode.el 中的大部分代码都被菜单占用了，比如 ["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' 发送块指向 Python 解释器。"]
请解释否决票。

标签： python emacs

【解决方案1】：

我曾经是 python-mode.el 的用户，但一年前就停止使用它，因为我觉得它的开发方式组织得不好。这是我当时记下的一份清单。但是我需要提醒你，从那时起已经过去了将近一年，所以情况可能会改变。

许多复制和粘贴功能。
许多意外工作的代码。例如，不传递变量而是使用隐式绑定。这会产生许多编译错误（如果将其更改为词法范围，将无法正常工作）。
提交的粗略粒度。我发送了一个补丁，并提交了不相关的更改。

我喜欢 python-mode.el 的一点是它带有自动化测试集（尽管我从未运行过它）。 python.el 还没有测试集。但是我知道python.el的作者现在正在写。

虽然 python.el 很紧凑，但这并不意味着您的功能很差。它更像是保持核心小，并通过提供简洁的 API 让其他人扩展它。 python.el 的同一作者写了python-django.el 来为 django 项目扩展 python.el。我为 Python 编写了名为 Jedi.el 的自动完成插件和名为 EIN 的高级 IPython 插件。与 python-mode.el 相比，它们对 python.el 的支持都更好（嗯，那是因为我不使用 python-mode.el）。

我首先从 python-mode.el 中遗漏了一些东西，但它们很快在 python.el 中得到了修复（当然，这可能意味着我没有在 python-mode.el 中使用这么多的功能）。

shell 缓冲区中的完成、源文件缓冲区中的完成、自动缩进、重新缩进等呢？

在 shell 缓冲区中完成：它在 python.el 和 python-mode.el 中都有效。但有时如果 Emacs 版本和 python(-mode).el 版本的组合不好，它就不起作用。所以可能 python.el 以这种方式更安全。但如果您想要更好的解决方案，请使用EIN :)
源文件缓冲区完成：只需使用Jedi.el :)
自动缩进/重新缩进：我不知道哪一个在性能方面更好。但是，用于返回的键绑定彼此不同。在 python-mode.el 中，如果你输入 RET 你会得到自动缩进。在 python.el 中，RET 不给你缩进，你应该使用 C-j 代替。实际上，换行+缩进的 C-j 是 Emacs 中的通用行为。所以如果你用其他语言编程，python.el 会更好。

【讨论】：

我不会提交错误报告错误报告，因为我没有使用 python-mode.el。退出使用 python-mode.el 的原因，包括“粗略的提交粒度，写在我的回答中。不，提交的粒度对我来说并不是毫无意义的。这就是开发人员关心他们的代码库的方式，恕我直言。
在指向动态绑定时声称“意外工作代码”同样是错误的。动态绑定与 Emacs 的成功故事密切相关，即使现在支持者不多。
好吧，如果它不是“意外工作代码”，那么它就不是写得好的代码。 python-mode.el 使用与非前缀变量的动态绑定，至少在我使用 python-mode.el 时是这样。如果你想要动态绑定，我认为你应该用defvar 声明它并放置适当的前缀。
tkf：动态绑定几十年来一直是 Emacs 的方式（并且一如既往地提供巨大的好处）。词法绑定在 Emacs 的发布版本中出现还不到一年。批评一个可以追溯到 1992 年的库在设计时没有考虑到词法绑定是愚蠢的（人们可能会选择为某个任意库启用词法绑定并假设一切都会继续工作，这也是一种想法）。
@phils 我的意思是，遵循常规规则的 Emacs lisp 程序可以在词法模式下运行而没有痛苦。这就是为什么很多内置的 Emacs lisp 程序可以毫不费力地转换为词法模式的原因。但我想谈论词法模式并不是让你和 Andreas Röhler 相信 python-mode.el 不遵循常规规则的最佳方式。

【解决方案2】：

去年大量参与开发 python-mode.el，我的评论可能有偏见：建议 Emacs 初学者继续使用 python.el。它的作者也因为一些有用的方法而值得称赞。

python-mode.el 旨在提高编辑效率。它使通过 python2 和 python3 或 IPython shell 并行运行或执行变得容易。

它减少了提供定制命令所需的击键次数。它使编辑更快，通过语音、宏驱动输入等辅助编程。

目前支持 python.el 中未知的 Python 语言功能：

py-up, py-down - 移动嵌套块

避免拼写错误，例如一个子句：

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

...

测试不同版本时无需自定义：

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

...

细粒度部件的概念 - py-expression, py-minor-expression
运行版本控制和并行 (I)Python 可执行文件的命令，无需重新定义默认 Python
很大程度上消除了对之前标记的活动区域的需求，请参阅py-execute-line 和一大堆更多内容

要获得概览，请查看菜单。目录“doc”列出了命令。

随着代码质量的提高：比较两种模式的一种方法可能是检查http://debbugs.gnu.org/ 中列出的错误。参见例如错误 #15510、#16875；或http://lists.gnu.org/archive/html/help-gnu-emacs/2014-04/msg00250.html

已经评论了“粗略的提交粒度”：虽然 tkf 基本上是在寻找较小的部分，但有时条件让我离开了规则。相当多的部分不是手工编写的，而是由位于“devel”目录中的程序编写的。他们创建用于开发分支的文件 - 即 components-python-mode。当开始一个新功能时，如果选择的路径是富有成效的，通常并不明显。经过一百次左右的可能提交后，它仍然可能变得不可能或不那么值得推荐。不是发布所有的曲折，而是在这些情况下将那个实验分支保留几天，并在测试通过时签入。

顺便说一句，假设 tkf 不是指编译错误——它会立即被查找——而是编译器警告。不幸的是，Emacs 将有关支持样式偏好的警告与实际错误混合在一起。

【讨论】：

Andreas - 当你说“看看菜单”时，那个菜单到底在哪里？是否有说明这些命令的文档？
@user815423426 见gnu.org/software/emacs/manual/html_node/emacs/Menu-Bar.html。顺便说一句，从您的问题假设您是 Emacs 的新手：不要从调试器会话等高级功能开始。开始简单的编辑，降低学习曲线，使用 Emacs 已经足够陡峭了。干杯。