python-docx缺点_Python的3大缺点-及其解决方案

最新推荐文章于 2024-08-08 18:52:51 发布

cxu0262

最新推荐文章于 2024-08-08 18:52:51 发布

阅读量1k

点赞数

文章标签： python java 编程语言人工智能大数据

原文链接：https://www.infoworld.com/article/3429565/3-major-python-shortcomings-and-their-solutions.html

版权

尽管Python在编程语言中非常受欢迎，但它面临性能、打包和项目管理等方面的挑战。Python的多线程性能受限，打包成独立可执行文件的过程复杂，而项目管理和包管理工具的多样性增加了复杂性。解决方案包括使用Cython、PyPy、Numba等工具提升性能，PyInstaller进行打包，以及PEP 518等规范改进项目管理。

摘要由CSDN通过智能技术生成

python-docx缺点

尽管Python已有30多年的历史，但仅在最近几年中，其流行度就超过了除Java和C之外的所有编程语言。总体而言，Python非常受欢迎：该语言已成为教学和学习编程的主要内容，是开始进行软件开发的好地方，并且是任何技术堆栈的重要组成部分。

不幸的是，受欢迎程度也往往会放大自己的缺点。就像Python的优点一样，Python的问题-最著名的是性能，打包和应用程序交付以及项目管理-现在众所周知。它们并不是致命的缺陷，但它们是采用Python的障碍，随着时间的推移，随着来自Julia ，Nim， Rust和Go等其他语言的竞争加剧，Python的采用只会变得更加明显。

[在InfoWorld上更深入地研究Python：解释了Python虚拟环境。 • Python virtualenv和venv做和不做。 • 什么是Cython？ Python以C的速度运行。 • 什么是PyPy？ 更快的Python而无痛苦。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

以下是Python程序员面临的三个主要挑战，以及Python和第三方Python工具和库背后的开发人员努力解决这些问题的方式。

Python多线程和速度

问题是： Python的整体性能低下，有限的线程和多处理功能仍然是其未来开发的主要障碍。

Python一直重视在运行时速度上简化编程的价值。当可以通过利用C或C ++编写的高速外部库（例如NumPy或Numba）在Python中完成许多性能密集型任务时，这种折衷并不是世界上最糟糕的事情。尽管如此，Python的开箱即用性能仍然比其他语言（如Nim或Julia）同样直接编译为机器代码的语法落后一个数量级。

Python寿命最长的缺点之一是对多个内核或处理器的不良使用。尽管Python确实具有线程工具，但实际上它们仅限于一个内核。尽管Python还通过启动其运行时的子实例来支持多处理，但是调度和同步这些子过程的结果并不总是有效的。

解决方案：目前，没有针对Python性能问题的自上而下的整体解决方案。而是有一些旨在加快Python速度的计划的拼凑而成，每个计划都在特定领域做出了贡献。一些例子：

改善CPython的内部行为。 CPython的改进提供了适度但普遍的加速。例如，Python 3.8的Vectorcall协议为Python对象提供了更快的调用约定。尽管这些改进并不引人注目，但它们是可测量的和可预测的，它们不会破坏向后兼容性，并且无需重写就可以使现有的Python应用程序受益。
改进CPython的子解释器功能。 Python解释器实例的新程序接口可以及时允许解释器之间更优雅地共享数据，以进行多核处理。现在，该提议已设置为在Python 3.9中采用，因此至少在另外一个Python版本中，相关的位甚至都不会出现。
改善多个流程之间的对象共享。 Python中的多处理为每个内核启动了一个新的解释器实例，以实现最佳性能，但是当解释器尝试对同一内存对象进行操作时，这些性能提升中有许多会丢失。诸如SharedMemory类和新的pickle协议之类的新功能可以减少在解释器之间传递数据所需的复制或序列化数量，这是性能问题的根源。

Python本身之外的项目也提供了提高性能的方法，但仅以特定的方式提供了这些方法：

PyPy。 另一个Python解释器PyPy即时将Python编译为本机代码。长期以来，它在纯Python项目中效果最好，但是现在可以与流行的依赖二进制的库（例如NumPy）一起很好地运行。但是，最适合长期运行的服务，而不是一次性应用程序。
Cython。 Cython允许您将Python代码逐步转换为C。该项目最初是为科学和数字计算而设计的，但是它可以在大多数情况下使用。最大的缺点是语法，这是Cython特有的，使转换成为单向过程。最适合于代码的“热点”部分，这些部分从优化而不是整个程序中受益最大。
Numba。 Numba及时将Python编译为所选功能的机器代码。像Cython一样，Numba主要用于科学计算。它最适合就地运行而不是重新分发的代码。
Mypyc。 Mypyc是一个进行中的工作，可以通过用mypy类型注释修饰的Python代码生成C。 Mypyc很有前途，因为它使用Python的本机类型，但与在生产环境中使用尚有一段距离。
优化的Python发行版。 Python的某些第三方版本（例如Intel的Python发行版）具有经过特殊编译的数学和统计信息库版本，这些版本可以利用Intel处理器扩展（例如AVX512）。请注意，尽管它们可以极大地加快特定数学功能的速度，但它们并不能提供全面的速度提升。

长期使用Python的程序员还谈论着摆脱全局解释器锁（GIL），该锁序列化对对象的访问并确保线程不会在彼此的工作负载上脚。从理论上讲，放弃GIL可以提高性能。但是，没有GIL的Python基本上是向后不兼容的Python（尤其是Python C扩展）。到目前为止，所有删除GIL的尝试要么陷入僵局，要么放慢了 Python的速度，而不是加快了速度。

重构Python内部C API的实现是一项正在进行的Python举措，应该可以实现许多速度上的改进。从长远来看，较少杂乱无章的API集旨在使添加许多性能改进变得更加容易：重新设计或消除的GIL，强大的即时编译挂钩，更好的在解释器实例之间联合数据的方法等等。上。

Python打包和独立可执行文件

问题：即使30年后，Python仍然没有采取程序或脚本，将其转换为独立的可执行文件并在多个平台上部署的好方法。有很多方法可以做到，但是它们主要是第三方工具，它们不是Python的本机部分，因此很难使用。

这些工具中最著名和最受支持的PyInstaller仍然非常有用。 PyInstaller可以打包使用许多最受欢迎的第三方扩展程序的应用程序，例如NumPy。但是PyInstaller必须与这些第三方扩展手动保持同步，这在像Python那样庞大的生态系统中是一项艰巨的工作。而且，PyInstaller会生成超大的应用程序包，因为它捆绑了程序的import语句中要求的所有内容，并且不确定运行时实际使用的组件。 PyInstaller软件包程序也不能跨平台。您必须在要部署的平台上创建软件包。

解决方案：与所有应有的尊重PyInstaller，我们需要的是一个解决方案，是原产于Python的无论是在标准库或作为一个内置的，这使我们打包和交付的Python高效Apps做为独立的二进制文件的最常见的平台。理想情况下，此内置打包程序将使用运行时代码覆盖信息仅捆绑所需的库（而不是要求的所有库），并自动与其他Python保持同步。

现在，没有这样的东西存在。但是有关如何构建这样的工具的提示不断出现。 PyOxidizer项目使用Rust语言来生成嵌入Python的二进制文件，这是创建独立Python应用程序的一种方法。成为一个完善的应用交付解决方案还有很长的路要走，但是它暗示了来自Python生态系统外部的影响如何可以导致一个解决方案。

Python安装，包管理和项目管理

问题：您知道有什么太复杂了吗？使用目录结构和脚手架为专业级别的Python项目设置工作区；和管理与该项目关联的环境，程序包和依赖项；以可复制的方式重新分配项目的来源；并且不会一遍又一遍地完成上述所有操作，最终不会吃掉键盘。

从一开始，Rust and Go语言就要做的一件事就是提供一种单一的规范方法来设置项目并在整个生命周期中对其进行管理。 Rust和Go开发人员失去了灵活性，但他们在一致性，可预测性和可管理性方面又赢了。

Python的工具和方法用于管理随时间推移而产生的安装，程序包和项目，这是其30年使用寿命的遗产。这是件疯狂的被子。有用于包管理的pip ，用于创建虚拟环境的venv / virtualenv用于Pipenv进行元管理的virtualenvwrapper和Pipenv ，用于生成项目依赖项的pip-tools ，用于创建Python代码发行版的distutils和setuptools等。然后是定义项目所需的其他部分： setup.py ， requirements.txt ， setup.cfg ， MANIFEST.in ， Pipfile ……列表继续。

解决方案：同样，需要的是一个工具和过程来代替这种杂烩，由核心Python开发团队提供为规范的解决方案，并且能够优雅地迁移使用任何现有方法的项目。当然，这是一项艰巨的任务，但是Python越流行，降低进入和维护的障碍以及提供一致且可访问的工具就越关键。

在这个方向上已经采取了一些步骤。根据PEP 518 ，Python的构建依赖项已合并为pyproject.toml文件格式。像诗歌这样的第三方工具，即使仅包装现有工具，也更接近于多合一管理产品。随着时间的流逝，这些解决方案之一可能会在整个社区流行起来，并成为事实上的标准，甚至成为实际接受的标准的候选者。