Python 2.4 的未来发展
我正在工作中启动一个新的 python 项目,该项目主要针对 RHEL5 计算机,这些计算机可能会在几年内升级到 RHEL6。鉴于 python 2.4 是 RHEL5 上的标准,并且系统管理员不会支持超过他们必须的支持,因此在我们的本地存储库中获取 python 2.6 需要一些说服力。虽然看起来我可以很好地使用 python 2.4,但我对从头开始创建一个旨在与这样的旧版本 100% 兼容的项目持怀疑态度。
我应该争取在 2.6 中完成这个项目还是以最顺利地遵守 RHEL5 为目标?如果我坚持使用 2.4,我应该注意哪些陷阱?
仅供参考:我肯定会使用 sqlite 和 pygtk。
I'm starting a new python project at work that is targeted primarily at RHEL5 machines that may be upgraded to RHEL6 in couple years. Given that python 2.4 is standard on RHEL5 and the system admins won't support more than they have to, getting python 2.6 in our local repo will take some convincing. While it seems I could get by just fine with python 2.4, I feel leery about creating a project from the ground up aimed at being 100% compatible with such an old version.
Should I fight for having this project done in 2.6 or aim for the smoothest compliance with RHEL5? What are the pitfalls I should be aware of if I stick with 2.4?
FYI: I'll definitely be using sqlite, and pygtk.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
你最好的选择可能是坚持使用 2.4,并拥有一个 time_machine 模块,其中包含后来的 python 拥有的所有你想要的好东西。例如,当属性第一次出现时,您必须执行类似以下操作:
但在 2.6 中,它们将属性增强为装饰器本身,因此您可以编写:
这意味着类名称空间中的冗余函数更少。
我碰巧非常喜欢这个功能,所以我的 time_machine.py 的代码类似于
: 。
Your best bet is probably to stick with 2.4, and have a time_machine module with all the goodies that later pythons have that you want. For example, when properties first came out you had to do something like:
but in 2.6 they enhanced properties to also be decorators themselves, so then you could write:
which means less redundant functions hanging around in your class' namespace.
I happen to like that feature a lot, so my time_machine.py has code similar to:
The really nice part about this is that python equivalents are often used to demonstrate the new functionality, so you don't even have to write the code yourself.
2.5 中的新增功能,2.6, 2.7 >。此外,标准库还记录了添加某些功能的情况。例如,2.6 中添加了字符串格式。不过,第三方库的支持可能不太可靠。
What's new in 2.5, 2.6, 2.7. Also, the standard library documents when certain features were added. For example, string formatting was added in 2.6. Third party library support could dodgy though.
我主要担心的是第三方库 - 大多数库作者将运行 2.7 并考虑 3.X,因此任何仅在旧版本中出现的错误可能会获得较低的优先级(或完全忽略 - 如果该错误是对于 python 本身,作者可以很容易地说这不是他们的库的错)
My main worry would be third party libraries -- most library authors will be running 2.7 and thinking about 3.X, so any bugs that only show up with older versions are likely to get a lower priority (or ignored completely - if the bug is to do with python itself, the author could easily say it's not their library's fault)
算你自己幸运吧——上次我做真正的 Python 工作时,我必须以 Python 1.5.2 为目标,因为这是我们目标 RHEL 系统上可用的最大共同点。希望所有这些系统现在都已迁移到更新的工具。
它可能感觉很过时,但这就是当前的生态系统:要么让您的软件易于在目标客户中部署,要么让自己被忽视。业余爱好者的部署要容易得多,他们将在各处运行更新的系统,但他们通常不会支付账单。
Count yourself lucky -- last time I did real Python work, I had to aim for Python 1.5.2, because that was the greatest common denominator available on the RHEL systems we were targeting. Hopefully all those systems have migrated to newer tools by now.
It might feel archaic, but that's the current ecosystem: either make your software easy to deploy among your target customers or get yourself ignored. Hobbyist deployments are so much easier, they'll be running newer systems all around, but they don't often pay the bills.