#翻译# Python 3 正在毁灭 Python

简介:

对于 Python 社区来说,Python 3 是最糟糕的的一个东西了。我依旧记得,当我第一次使用Python的时候,我已经在C++的领域摸爬滚打了很长时间,Python对我来说就像是一本圣经。我可以随便打开一个文本编辑器,几秒钟或几分钟之后,一个可以正常工作的程序就诞生了,而不用去花费几小时或几天的时间。我仍记得,Python 2.5问世的时候添加了许多好用的新特性。我爱Python,但同时我也承认她有缺点,但是还都说得过去,所有的语言都有缺点。她的优势在于她很有趣。尽管Python 3相比Python 2来说有了一些小的提升,但是她丢掉了很多Python 2的优势。

Python 2最重要的一个优势在于拥有众多的第三方库,可以用来做任何事情,但是Python 3没有这个优势。诚然,有很多的库已经移植到Python 3了,但是有更多的库没有移植,也不容易移植。例如,你需要解析 X,但是X不像YAML和JSON那样容易解析。很可能有一个第三方的解析器可供选择,但是只可以用Python 2,而没有针对Python 3的移植版本。此外,加之Python 2中的字节字符串(str)和Python 3 中的字节字符串(bytes)之间有着功能上的差异,使得这更难移植。而事实上,移植它非常困难,并且需要很多的小技巧(trick)来兼容Python 2和Python 3。所以,你有两种选择,要么使用Python 2 (已经不建议使用的语言)快速的开发你的程序,但这会花费你十倍以上的时间去移植相关的库(以及所有的依赖)。要么,使用另一门同样拥有很多库的编程语言,但是不用再困扰于Python 2 / 3之间的问题。第二种选择显然不受欢迎,因为如果我们这样做了,在我们的生产环境中已经有很多Python 3的程序了并且大部分Python 2的库需要被移植。不管这些情况是否存在,人们要么继续使用Python 2开发程序,要么选择另一门不会打自己脸的语言。

Python 2的另外一个优点是,用它写的程序几乎不用更改就可以运行在下一版本上。如果你的软件是基于Python 2的,那么就可能花费一大笔钱才能将其迁移至Python 3,因为你需要的工程可能相当地大,并且塞满了各种类库手册,而他们不能被迁移。这在商业策略上非常不明智,因为你不得不为此花费 大量的金钱和工程师的时间才能把工程迁移到Python 3。你不妨问问其他人将整个代码迁移到Ruby,或者,那还更划算。至此,要是你不得不重写你的软件,你还会选择Python 3吗?不。

大多数比较受欢迎并且支持兼容Python 2和Python3的库是通过运行在各自平台上的语言子集(subset)来写的。我最喜欢的Python库之一的SQLAlchemy做的很好,Django也是这样做的,但是稍有逊色。语言子集,我称之为Python X,并不那么好用,需要很怪异的hack,并且通常性能不如Python2 或 Python 3。将现有的Python 2的库移植到Python X有趣吗?没有什么趣味可言,反而很悲哀,因为正是由于有趣才造就了今天的Python。

不幸的是,Python 2 已经不推荐使用了,Python 3用的也不多。Python 3 的改变比较小,没有得到多少,反倒失去了不少。在过去的几个月里,我使用Python 3编写程序和服务。我个人感觉(没有吹嘘的意思),和用Python 2 写程序没有太多差别,除了第三方的库少一些。真没有其他的令人眼前一亮的了。Python的社区原本要在过去的几年中转移到Python 3,但是,他们逐渐发现,人们正在转向新的语言(或重新改进过的旧语言)。这些语言大都拥有非常棒的功能,像强大的类型系统,模式匹配,更好的性能,更好的支持线程和高并发,更简单的FFI,更好的lambda表达式等等。

一种解决方案是fork Python 2.7,并继续开发它,以向后兼容的方式添加新的功能,以便大多数不能移植的Python 2的应用程序可以继续演化和改善,并给人们和花费了大量时间来开发它的公司带来价值。这是正确的事(实际上,如果Guido和其他Python社区中的领导者以官方的名义这样做而不是强制fork就更好了)。Python 3中的功能需要向后移植到Python 2,并且需要发布Python 2.8。对于少数已经在使用纯Python 3开发程序的人来说,可以使用像3to2这样的工具来兼容Python 2.8。之后,Python 3就可以逐渐的退居幕后,这样以来,那些Python库的维护者就可以使用Python 2而不用使用Python X了。

虽然还有些别的方案,但复兴Python 2明显是现在应该做的,其他的都不值一提。因为官方的负责人对Python 2的使用者十分不屑,所以别指望他们会来复兴Python 2。如果社区不重振旗鼓并复兴Python 2,那Python 3在几年后就会变成Python的标准,同时很多相应的类库会被接入(尽管大多数肯定永远都不可能),很多的投资会失去。到那时,整个社区就会很明显地萎缩,失去她原有的光辉。看看Perl的下场吧,人们会离开去别的地方。

相关文章
|
26天前
|
数据安全/隐私保护 Python
1178: 密码翻译(python)
1178: 密码翻译(python)
|
27天前
|
存储 缓存 JavaScript
python实战篇:利用request库打造自己的翻译接口
python实战篇:利用request库打造自己的翻译接口
33 1
python实战篇:利用request库打造自己的翻译接口
|
3月前
|
Unix 程序员 Apache
从 Python 之父的对话聊起,关于知识产权、知识共享与文章翻译
从 Python 之父的对话聊起,关于知识产权、知识共享与文章翻译
31 0
|
3月前
|
Python
Python 3.10 版本采纳了首个 PEP,中文翻译即将推出
Python 3.10 版本采纳了首个 PEP,中文翻译即将推出
18 3
|
PyTorch API C#
【Python+C#】手把手搭建基于Hugging Face模型的离线翻译系统,并通过C#代码进行访问
目前翻译都是在线的,要在C#开发的程序上做一个可以实时翻译的功能,好像不是那么好做。而且大多数处于局域网内,所以访问在线的api也显得比较尴尬。于是,就有了以下这篇文章,自己搭建一套简单的离线翻译系统。以下内容采用python提供基础翻译服务+ C#访问服务的功能,欢迎围观。
906 0
【Python+C#】手把手搭建基于Hugging Face模型的离线翻译系统,并通过C#代码进行访问
|
5月前
|
前端开发 JavaScript 语音技术
|
5月前
|
运维 API 语音技术
Python智能语音识别语翻译平台|项目后端搭建
Python程序设计基础,第三方库Django、requests、hashlib、pyttsx3等的使用,百度API语音识别业务接口、文本朗读业务接口、翻译业务接口的传入。
119 0
Python智能语音识别语翻译平台|项目后端搭建
|
5月前
|
存储 文字识别 API
沃德天,Python竟然还能做实时翻译
沃德天,Python竟然还能做实时翻译
50 1
|
10月前
|
Python
|
10月前
|
数据采集 JSON 前端开发
用Python做一个简单的翻译工具
不过有时候,当我在命令行环境下写代码的时候,懒得再切换到浏览器里等待页面的加载。