既然我不是严格意义上的python开发人员,请不要因为这个问题就解雇我。在
我想知道python3k,在我看来,这可能是某种误解。 或者更进一步(我考虑的是2.6和3k版本,它们几乎是一个接一个的)。 在火焰开始之前,我会解释一下我在这个话题上的立场,并且我会从我的工作环境中假设一些事实。在
我在一家领先的市场数据解决方案公司工作, 我们主要使用函数语言来进行高吞吐量的数据分析。 但我们也使用python作为第二种技术来处理较小的任务、脚本、流程管理和监视。在
我的一些同事基于python技术编写了更多的严肃的生产应用程序, 但是:
每一个小型工具的开发也是基于2.6平台的。在
我还观察到:
(我知道您可以将大部分内容移植到3.1.x上,但在这里开销太大了。)
我知道Py3K还在成长,但是, 已经有了python 3.1.1,但是没有人“关心”(在我的环境中)。 我强烈地感觉到python3k的开销正在阻止它将这项伟大的技术推向新的维度。在
Py3k是Python语言发展过程中一个很好且必要的步骤。我喜欢它比2.x好得多,而且它的代码几乎是独占的。幸运的是,我不依赖第三方库,其中很少有针对Py3k的库。但他们会的。在
使用2.6-2.7并没有什么错-2.7将成为3.x的桥梁,而且您可以开始生成类似Py3k的代码,一旦您最喜欢的第三方库在那里,移植到3.x将变得非常简单。我想我在什么地方读到过,Py2k还会存在好几年。在
这里的问题到底是什么?您发现您当前使用的平台有一个更新版本。你有充分的理由坚持你现有的版本。这种模式在很多开发组织中都很常见,你根本无法追逐你使用的每一个新版本的东西。你也不能永远呆在原地,最终你需要迁移。在
例如,有些因素可能会促使您迁移
同时,您可以尝试将来验证您的代码,以便迁移更容易。你是否熟悉晋升所需的变革水平?在
OP似乎很惊讶他们的组织一夜之间发生了一次小小的版本升级(增加了一些漂亮的特性,基本上打破了现有的零代码,并允许对所有现有的第三方库进行琐碎的重建),而一个主要的版本升级(特别是从第三方库作者的角度来看,需要更多的努力)没有也不会。我想我对他们的惊讶大多感到惊讶;-)。在
在大多数大型项目和组织中,即使是较小的版本升级也不会立即发生;例如,App Engine仍在使用python2.5(显然,升级其专用的“沙盒”Python运行时,它所依赖的并不是一个零努力的命题,因此,他们更愿意继续把精力放在添加引擎特性上——因此我认为Jython和PyPy等实现也是如此(我认为IronPython正在迁移到2.6,但目前的生产版本仍然是2.5)。在
今天开始的全新项目应该认真考虑从python3开始;例如,allisonrandal的pynie(Python for Parrot)项目就做出了这样的选择(而且,我认为,在他们的情况下,这是正确的选择)。迁移现有项目是一个比较困难的问题,主要取决于现有项目依赖的第三方组件(如果一个新项目本质上依赖于第三方库2.6版而不是3.1版的某些功能,当然,新项目可能暂时还得坚持2.6版本)。在
正在积极开发中的第三方库可能会逐渐推出python3版本(例如,gmpy最近就这样做了)。一旦有足够多的第三方库可用,那么使用python3迁移一个现有项目(甚至更多的是启动一个新项目)的缺失库的可能性就开始急剧下降。这使得python3端口可行。在某种程度上,一些有吸引力的功能将只在python3中提供(例如,如果pynie发布,那么Parrot实现可能就是这种情况,它提供了与Perl&c的平滑互操作性),这将为一些项目提供一个强大的动机,使其只进行3个项目(从实用角度来说,比单纯的语言质量问题更为强大)。在
即便如此,一些足够大的项目和组织仍将长期坚持使用Python2,而且您可以自信地预计到某个时候2.7将存在(可能还会有一到两个,但这更难预测)。嘿,我清楚地记得在整个90年代,在大多数大型项目和组织中,“Fortran”仍然意味着Fortran 77(事实上,在某些地方——比Fortran版本的第一个发布版本晚了30多年——这一点在今天仍然适用!)。。。尽管Fortran 90及更高版本的所有优点,移植成本(尤其是各种编译器、库、工具)被认为是一个太高的代价,无法与新语言版本的优势相比。当一种语言拥有大量的安装基础和丰富的第三方工具和库的生态系统时,这是不可避免的,就像python2现在所做的那样。没理由惊讶!-)在
相关问题 更多 >
编程相关推荐