编译器针对 .pyc 文件？
出于好奇，是否有许多编译器以 .pyc 文件为目标？
经过一番谷歌搜索后，我能找到的唯一两个是：
那么……还有更多吗？
（作为旁注，我开始考虑这个问题，因为我想编写一个Scheme-to-pyc编译器）
（作为第二个旁注，我并不幻想Scheme-to-pyc编译器会是有用，但它会给我一个令人难以置信的借口来学习Scheme和Python的一些内部原理）
Out of curiosity, are there many compilers out there which target .pyc files?
After a bit of Googling, the only two I can find are:
So… Are there any more?
(as a side note, I got thinking about this because I want to write a Scheme-to-pyc compiler)
(as a second side note, I'm not under any illusion that a Scheme-to-pyc compiler would be useful, but it would give me an incredible excuse to learn some internals of both Scheme and Python)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
“我想写一个Scheme-to-pyc编译器”。
我的脑子好痛！你为什么要这么做？ Python 字节码是一种中间语言，专门为满足 Python 语言的需求而设计，并设计为在 Python 虚拟机上运行，而 Python 虚拟机也是根据 Python 的需求量身定制的。如今，Python 开发的一些最重要领域正在将 Python 迁移到其他“虚拟机”，例如 Jython (JVM), IronPython (.NET), PyPy 和 Unladen Swallow 项目（将 CPython 迁移到基于 LLVM 的表示）。试图将另一种非常不同的语言（方案）的语法和语义压缩到另一种高级语言的中间表示中似乎是在错误的级别上解决问题（无论问题是什么）。因此，总的来说，似乎不会有很多 .pyc 编译器，这是有充分理由的。
"I want to write a Scheme-to-pyc compiler".
My brain hurts! Why would you want to do that? Python byte code is an intermediate language specifically designed to meet the needs of the Python language and designed to run on Python virtual machines that, again, have been tailored to the needs of Python. Some of the most important areas of Python development these days are moving Python to other "virtual machines", such as Jython (JVM), IronPython (.NET), PyPy and the Unladen Swallow project (moving CPython to an LLVM-based representation). Trying to squeeze the syntax and semantics of another, very different language (Scheme) into the intermediate representation of another high-level language seems to be attacking the problem (whatever the problem is) at the wrong level. So, in general, it doesn't seem like there would be many .pyc compilers out there and there's a good reason for that.
几年前我编写了一个编译器，它接受一种名为“Noodle”的类似 lisp 的语言并生成 Python 字节码。虽然它从未变得特别有用，但对于更好地理解 Common Lisp（我复制了它的几个功能）和更好地理解 Python 来说，这是一次非常好的学习经历。
我可以想到两种特殊情况，直接针对 Python 字节码可能有用，而不是生成 Python 并将其传递给 Python 编译器：
nonlocal关键字之前） ），如果不诉诸字节码黑客技术，就无法修改封闭变量的值。您可以改为改变值，因此通常的做法是让闭包引用列表，并从内部范围更改其中的第一个元素。这真的很烦人。不过，该限制是语法的一部分，而不是 Python VM。我的语言具有显式变量声明，因此它成功地提供了具有可修改封闭值的“正常”闭包。所以，是的，这可能比它的价值更多的工作，但我喜欢它，你可能也会。
I wrote a compiler several years ago which accepted a lisp-like language called "Noodle" and produced Python bytecode. While it never became particularly useful, it was a tremendously good learning experience both for understanding Common Lisp better (I copied several of its features) and for understanding Python better.
I can think of two particular cases when it might be useful to target Python bytecode directly, instead of producing Python and passing it on to a Python compiler:
nonlocalkeyword), you can't modify the value of a closed-over variable without resorting to bytecode hackery. You can mutate values instead, so it's common practice to have a closure referencing a list, for example, and changing the first element in it from the inner scope. That can get real annoying. The restriction is part of the syntax, though, not the Python VM. My language had explicit variable declaration, so it successfully provided "normal" closures with modifiable closed-over values.So yeah, it's probably way more work than it's worth, but I enjoyed it, and you might too.
我建议你专注于CPython。
http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html
而不是从Scheme到.pyc的转换器，我建议你编写一个Scheme到Python的转换器，然后让CPython处理到.pyc的转换。 （这样做是有先例的；第一个 C++ 编译器是 Cfront 它将 C++ 翻译成C，然后让系统C编译器完成剩下的工作。）
根据我对Scheme的了解，将Scheme翻译成Python并没有那么困难。
一个警告：Python 虚拟机对于Scheme 来说可能不如Scheme 本身那么快。例如，Python 不会自动将尾递归转变为迭代； Python 的堆栈相对较浅，因此您实际上需要将尾递归转换为翻译器的迭代。
作为奖励，一旦 Unladen Swallow 加速了 Python，您的Scheme-to-Python 翻译器就会受益，到那时甚至可能变得实用！
如果这对你来说是一个有趣的项目，我建议你去做吧。并非每个项目都必须立即实用。
PS 如果您想要一个更实用的项目，您可能需要编写一个 AWK 到 Python 的转换器。这样，使用旧版 AWK 脚本的人就可以轻松地跳转到 Python！
I suggest you focus on CPython.
http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html
Rather than a Scheme to .pyc translator, I suggest you write a Scheme to Python translator, and then let CPython handle the conversion to .pyc. (There is precedent for doing it this way; the first C++ compiler was Cfront which translated C++ into C, and then let the system C compiler do the rest.)
From what I know of Scheme, it wouldn't be that difficult to translate Scheme to Python.
One warning: the Python virtual machine is probably not as fast for Scheme as Scheme itself. For example, Python doesn't automatically turn tail recursion into iteration; and Python has a relatively shallow stack, so you would actually need to turn tail recursion to iteration for your translator.
As a bonus, once Unladen Swallow speeds up Python, your Scheme-to-Python translator would benefit, and at that point might even become practical!
If this seems like a fun project to you, I say go for it. Not every project has to be immediately practical.
P.S. If you want a project that is somewhat more practical, you might want to write an AWK to Python translator. That way, people with legacy AWK scripts could easily make the leap forward to Python!
出于您的兴趣，我编写了一个从简单的 LISP 到 Python 的玩具编译器。实际上，这是一个 LISP 到 pyc 编译器。
看一下： sinC - 最小的 LISP 编译器
Just for your interest, I have written a toy compiler from a simple LISP to Python. Practically, this is a LISP to pyc compiler.
Have a look: sinC - The tiniest LISP compiler
可能有点晚了，但如果你仍然感兴趣，clojure-py 项目（https://github.com/halgari/clojure-py）现在能够将 clojure 的一个重要子集编译为 python 字节码 - 但是总是欢迎一些帮助。
定位字节码本身并不难，除了一件事：它在跨平台上不稳定（例如，MAKE_FUNCTION 在 Python 3 中从堆栈中弹出 2 个元素，但在 Python 2 中只弹出 1 个元素），并且这些差异没有清楚地记录在单个文件中。点（afaict）——所以你可能需要一些抽象层。
Probably a bit late at the party but if you're still interested the clojure-py project (https://github.com/halgari/clojure-py) is now able to compile a significant subset of clojure to python bytecode -- but some help is always welcome.
Targeting bytecode is not that hard in itself, except for one thing: it is not stable across platforms (e.g. MAKE_FUNCTION pops 2 elements from the stack in Python 3 but only 1 in Python 2), and these differences are not clearly documented in a single spot (afaict) -- so you probably have some abstraction layer needed.