另一方面，用C编写的Python实现是（...）
我很好奇为什么Python是用C而不是C ++编写的？
我想知道此决定的原因，答案应由历史参考（而非基于观点）支持。
#1 楼
从我所看到的一切来看，这是实践和历史原因的结合。 （大多数）历史原因是CPython 1.0于1989年发布。当时，C刚刚被标准化。 C ++几乎是未知的并且绝对不可移植，因为几乎没有人使用C ++编译器。与C ++兼容的C的子集。就其本身而言，这项工作几乎没有带来什么好处，甚至没有任何实际好处。我要指出微软从Windows 3.0内核到Windows NT内核的转换，以及苹果从MacOS 9到Mac OS / X的转换来反驳。谁都没有杀死公司-但它们绝对是大型，昂贵的长期项目。两者都指出了对成功至关重要的事情：将两个代码库维持足够长的时间，以便（大多数）用户（至少（基于）感知到的好处）可以在闲暇时切换到新的代码库。但是，对于Python大小的开发团队而言，这种改变要困难得多。甚至从Python 2到3的更改也花费了很多工作，并且需要类似的重叠。但是，至少在那种情况下，更改有直接的好处，而改写C ++本身（至少立即）不会（至少立即）提供。 ，所以我也会提到。我从Guido看到的任何信息都没有表明他对C ++有那种强烈的消极情绪。我见过他说的最糟糕的情况是，教C ++通常是一场灾难-但他立即继续说，这主要是因为老师不/不知道C ++。
我还认为，虽然可以相对轻松地将许多C代码转换为C ++，但要想从C ++中获得真正的优势，不仅需要进行大量重写，而且还需要对大多数相关开发人员进行大量培训。大多数写得很好的C ++与写得很好的C在做相同的事情上有本质的不同。不仅仅通过想象力将
malloc更改为new，将printf更改为cout即可。评论
+1您经常引用；他们很有趣。似乎可以添加链接会更好。
–n611x007
2012年11月25日在22:42
刚刚提交了带有Joel博客文章链接的编辑，该博客文章重写了joelonsoftware.com/articles/fog0000000069.html
– MarkJ
13年6月13日在8:33
这是一个很好的答案。我从中学到了很多。
–游戏Brainiac
13年6月22日在16:37
+1专门提到可以相对轻松地移植到c ++的c可能不值得。我已经知道了很长时间，但是答案确实加强了观点，并增加了一些方面。
–fkl
2013年12月5日下午6:44
“ Apple从MacOS 9到Mac OS / X的转换”指出OS / X并不是从头开始的改写：它是从MacOS9到NeXTStep的切换，经过改进并重新命名为Apple
–吉万
2014年12月29日下午5:43
#2 楼
我认为它最初是用ANSI C89编写的原因很简单，因为在那时，由于不同的编译器之间不兼容，所以C ++并不是可行的选择。我的意思是直到2005年才提出ABI规范，该规范允许使用一个编译器编译的代码可以调用使用其他编译器编译的代码？更有趣的问题是为什么它仍然是用C89编写的？
还有一个令人惊讶的答案：因为人们实际上在没有C ++和C99编译器的平台上使用Python！合并了受Forth启发的线程代码解释器优化时，对此进行了广泛的讨论，因为该代码（必需）使用了计算的
goto，而这不是C89的一部分。显然，人们确实担心该功能可能在当前使用Python的某些平台上不可用。Unladen Swallow也发生了同样的事情，其中使用了用C ++编写的LLVM。非常清楚地表明，将Unladen Swallow合并到CPython中的要求是您可以在没有JIT编译器的情况下进行编译，因为存在可以在其上运行Python的平台，而C ++编译器不存在。当然，如今，CPython不再是唯一的Python实现。有PyPy，它是用RPython（Python的静态类型子集），Java的Jython，C＃的IronPython，NQP和PIR的Pynie等编写的。
评论
我很想提出支持，但我不知道没有这样的平台，其中不存在C ++编译器（特别是考虑到Comeau C ++可以编译为C）
–比利·奥尼尔（Billy ONeal）
2011-2-14在23:58
+1提及ABI
– jk。
13年6月13日在11:12
@Abdul：不，Python根本不是软件。这是一个规范。该规范有多种实现，用多种语言编写。 IronPython是用C♯，Java的Jython，RPython的PyPy，NQP，PIR和Perl6的Pynie，C ++的Pyston以及C的CPython编写的。“ Python是用C编写的”语句是没有意义的。 Python不是软件。这是一个规范。它是用英语写的，而不是任何编程语言。 “ Java是C的派生”主要是错误的。 Java受到Objective-C的启发，但是它摆脱了大部分C部分，并且大部分采用了Smalltalk部分。
–Jörg W Mittag
16年7月9日在14:28
@MilesRout：在很多情况下，规范都偏离CPython。例如：Python规范不保证确定性的终结，但CPython至少对于非循环引用可以保证。但是，即使CPython保证了非循环引用的确定性终结，但是依赖于该事实的代码编写也被破坏了，因为它不是规范的一部分。 （我现在找不到引号，但是GvR明确表示确定性终结和引用计数是CPython的内部私有实现细节。）
–Jörg W Mittag
17-10-18在11:58
同样，CPython保证两个Python线程不能并行执行，但是这也是CPython的内部私有实现细节，并且不受语言规范的保证。如果您说的是正确的，那么就不可能有任何其他实现，因为任何其他实现都必须与CPython行为相同，因此也必须相同。 （模态重构不会改变可观察的行为。）
–Jörg W Mittag
17-10-18在12:02
#3 楼
更好的问题可能是：“为什么Python不是用Python编写的？”更重要的是，一旦用C编写了足够的Python类和对象原语，就可以使用这些原语来编写解释器的其余部分，因此使用C ++不会获得任何好处。
评论
如果您点击答案中的第一个链接，则会看到对Python中Python实现的引用。那还没有准备好生产。那是由欧盟资助的。如果很难从我的答案中找到答案，则指向codepeak.net/pypy/dist/pypy/doc。
–vpit3833
10 Nov 23 '22：02
这实际上是一个非常深刻的答案。并不是说Guido的Python实际上是用Python编写的，而是C语言中的低级结构用来编写高级结构。
–杰里米
10 Nov 24'1:43
我认为您错过了这一点，因为（对于从事解释器本身的人们而言）解释器使用的语言存在很大差异。语言会影响这些原语的外观以及它们之间的交互方式。例如，现在，在Python的C实现中，必须记住手动增加和减少引用计数，而为此可能可以在C ++中使用智能指针。
–彼得·多布罗格斯特（Piotr Dobrogost）
2014年7月28日14:06
现在PyPy可用了，有时有趣的是它的表现胜过CPython，我认为这真是个好主意。
– Sai Kumar Battinoju
18年7月20日在11:41
评论
我不知道为什么，但是我怀疑这很接近：thread.gmane.org/gmane.comp.version-control.git/57643/…:)@拉里·科尔曼：从来没有见过莱纳斯的咆哮？您必须避免使用“互联网” ...> _>
@Larry我确实看到了这种怒，并且在阅读它后几乎失去了对Linus的尊重。对他感到羞耻。
好吧，这是对Linus怒吼的回应，怎么回事：warp.povusers.org/OpenLetters/ResponseToTorvalds.html
我看不到问“为什么用（语言X）而不是（语言Y）编写（流行的程序）？”的意思。或更确切地说，可以反过来回答相同的问题：为什么选择Y，而不选择X？