python路线上需要拿掉的四块"绊脚石",你难道不了解一下吗？
无论您是从事机器学习、API构建、devops，还是容器和微服务，您都将从这些Python的进步中获益
前言
python从不静止不动。随着每次迭代的进行，Python语言及其最广泛使用的实现CPython都在向前迈进，使每个使用它们的人的生活都变得更轻松。
随着Python变得越来越流行，它的用例也在扩展，某些Python限制(从缓慢启动到缺乏并发)变得更加明显。最新的一组改进是由Python在自动化、机器学习和微服务等领域所面临的各种需求驱动的。
在这里，我们来看看Python的核心开发团队正在推动的四个关键领域的重大改进。
1.缩短Python的启动时间
为Python计划的许多改进都属于“使事情更快”的范畴。最重要的优化之一是减少CPython解释器启动所需的时间。这可能会为开发带来最大的短期效益。
毫无疑问，Python的启动时间是个问题。Core CPython开发人员Victor Stinner演示了Python 3.7(当前主干版本)的启动速度比Python 2.7慢2.3到2.8倍。Perl 5和PHP 7的启动速度比Python 3快5到10倍(例如AWS Lambda)。
2.加速Python的命名元组
CPython的核心开发人员希望加快运行时(包括启动时间)的最常见方法之一是更快地实现命名元组。
Python中的uples是不可变的对象列表，比如整数或字符串，这些对象由它们的索引位置(元素0、元素1等等)访问。Python标准库中提供的命名元组允许通过点属性访问这些元素，例如。、地址。zip_code而不是地址[3]。这可以使代码更容易阅读。
然而，当前命名元组的实现被认为是Python启动时间较慢的一个可能原因。因此，Python的创建者Guido van Rossum已经下令，应该在CPython中对命名元组进行积极的优化——这既是因为它将提供CPython的启动时间，也是因为它将给所有使用CPython的第三方应用程序带来的好处。
正如van Rossum所指出的，从这个讨论中出现的优化CPython的一个方面是，在野外最常用的语言元素应该作为CPython的一个本地部分来实现，即用C语言而不是用python来加速。
van Rossum写道:“生成源代码和exec()ing it的方法很好地展示了Python的表达能力，但我一直认为，每当我们遇到使用exec()和eval()的流行习语时，我们应该增强语言(或内置)来避免这些调用。”
学习从来不是一个人的事情，要有个相互监督的伙伴，工作需要学习python或者有兴趣学习python的伙伴可以私信回复小编“学习” 领取全套免费python学习资料、视频()装包
3.重构CPython的内部api
CPython当前的许多限制都有一个共同的原因:需要维护其C API的向后兼容性。理论上，可以重写CPython以全面提供巨大的性能改进，但代价是破坏与大量软件的兼容性。Python社区长期以来都以不进行这种破坏更改而自豪，除非跨越语言版本边界(Python 2 vs. Python 3)。
核心Python开发人员Victor Stinner提出的一个可能的步骤是重构CPython的C API以隐藏其实现细节。通过这种方式，开发人员可以更容易地尝试新的优化，这些优化可能会破坏某些东西，例如。，丢弃全局解释器锁，或GIL。这种重构的测试不仅可以使用CPython自己的测试套件进行，还可以针对插入API的最常见的第三方包进行测试，比如NumPy和SciPy。
重构CPython的api将在其他方面得到回报。首先，它将使CPython的代码更容易导航和理解，并降低潜在贡献者的门槛。这补充了CPython团队已经采取的保持开发人员和贡献者兴趣健康的现有步骤，比如将源存储库迁移到GitHub。
4.抛弃Python的GIL(也许)
如果Python有一个限制是最常见的需要解决的问题，那就是全局解释器锁。GIL确保对CPython使用的每个对象的内存访问都是“线程安全的”，这意味着一个Python对象一次只能由一个线程使用。这也意味着CPython实际上是单线程的。多线程、cpu绑定的操作需要通过C扩展或CPython的多个实例来处理。
在Python的大部分生命周期中，这些限制都被认为是使用Python的成本的一部分。但是，随着CPU时钟速度趋于平稳，内核数量激增，Python面临着输给本地处理多线程的语言的风险。
当然，Python的许多主流应用程序，如机器学习和统计，都是通过不受GIL约束的C代码来加速的。但这个问题正变得越来越难以忽视。解决这个问题的python原生解决方案将更易于跨平台移植、跨应用程序更灵活、更容易被开发人员利用。
最近一组移除GIL的实验——CPython开发人员Larry hastings称之为“Gilectomy”——表明仅仅移除GIL并不是完整的答案。可以删除GIL，但代价是破坏与现有Python包(主要是C扩展)的向后兼容性。
为此，任何删除GIL的尝试都需要向后兼容C API。到目前为止，这样做的尝试带来了巨大的性能成本，正如黑斯廷斯在2017年PyCon大会上的一次演讲中所展示的那样。
现在，任何删除GIL的计划都只是暂时的和实验性的，必须受到现实世界中使用Python的方式的限制。但是，一旦CPython api的重新工作完成，GIL可能会变得更容易抛弃。
