不是指重新实现一遍 Python。
回复内容：
Greenspun's tenth rule，与君共勉：Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. 谢谢邀请。
这个问题的目的有点可疑。读过这里的大部分回答之后，我的感觉是，也许我们都误解了提问者的意思。我猜提问者的意图跟 Python 没关系，真实的意思是：「我们能不能把尽可能多的 C/C++ 常用功能塞进标准库，让 C/C++ 程序员不再需要打理各种细节」。至于所谓「达到和 Python 的开发效率」，只是一个比方。
如果我的猜测没有错，那么我的回答是：可以，但只在具体的领域有效。
熟悉分布式程序设计的老程序员可能会记得 CORBA 和 ICE。CORBA 是老一辈的分布式架构，C/C++ 绑定时用的是 C 字符串类型；而 ICE 则直接用了 C++ 标准库的字符串。不仅如此，ICE 大量用了 STL 标准库。具体到开发效率时，ICE 的 C++ 绑定确实让我省去了大量时间折腾 CORBA 里的 C 字符串分配和释放问题，做个小应用确实轻松了很多。
但为什么我说只在具体领域内有效？因为 C/C++ 的定位决定它存在巨大的限制。仍然是字符串的例子：有谁知道有多少广为使用的 C++ 库没有实现自己的字符串类么？ICU、WxWidget、Qt、MFC，还有很多流行的库，都这样重新发明着轮子。我无意追问为什么我们会面对如今这种混乱的情况：这是个历史问题。无论如何，C++ 使用库碎片化已经是事实，无法如果。
既然不能如果，现在再谈重建标准功能库，就只能限定在某个具体的框架里，比如 MFC，比如 Qt。在这些具体的框架之内，确实可以有比纯利用 C++ 标准库高得多的开发效率。唯一的问题：请别超出框架的范围，不然就可能给自己惹麻烦。
那么，在理想情况下我们能不能达到 Python 的开发效率？也许可以吧，不过如果理想都达不到，我想我们还是别讨论了，立足现实更好些。 C/C++本质上是Raw Memory Processing语言
如果你不需要处理原始用户态内存，却选择了C/C++，说明你不理解C/C++
因为你放弃了这两个语言最有用的功能 你说的是用 C/C++ 写个 DSL？ 不能。
你会花和Python差不多的时间构思。
Python两倍的时间打字。
Python一百倍的时间编译。
比以上加起来还多十倍的时间debug内存越界和野指针。 c++的时候觉得最影响开发效率的我觉得是没法像python那样对什么东西都可以print出来。
和成熟的logging日志库来帮助调试。
所以在开发c++的时候自己写了一个头文件库。没有依赖，就没有伤害。
直接include进来就可以使用的。
https://github.com/yanyiwu/limonp
hope it will help 首先回答问题，不行！（仅回答c++语言）
从语言本身角度，c++不是为了这种生产环境设计，就算再多的类库，再多的补丁，实现再多的python功能，她还是c++，该有的c++功能还是有，而更多功能当然带来更复杂的逻辑，所以并不能像python一样快速开发。而且这个C++库恐怕会大到普通pc无法容忍的地步，编译时间和大小都不是普通用户能承受的。
但是！！如果拥有一个非常大的类库，确实大大增加c++的学习成本，同时增加c++的复杂性，同时，c++的源代码会变得比较简短也是事实，如果库写的不错，代码简化之后和python差距不大，或者更像一种神奇的c++类似的内存自动管理语言。
我现在刚接触了一个非常大的C++库，现在正在学习，个人感觉就像在用一门完全陌生的语言，各种调用都要查询很久文档才能写出几行代码，但是如果熟练的话，应该能够做到原来C++至少一半的代码量就解决相同问题。 为什么不理解成：有人为了用C/C艹语言实现高开发效率，最后发明了Python呢？
你觉得CPython里的C是啥意思… objectivec 嘛
开发速度快 但是执行速度慢 C++11 + STL + boost 的开发效率大可与 Python 一战，不过编译速度不能比
for (auto x : { 1,2,3,5,8,13,21,34 }) cout << x << '\n';
