Ironpython与原始python的比较。从第一个开始我能期待什么?

在你的情况下,研究Ironpython是完全合理的(尤其是 this book 帮你做那件事真是太好了!)。您基本上可以访问所有的python 2.5功能(不确定Ironpython何时升级到2.6版本的python,但2.5已经非常可用)。 加 所有你知道和喜欢的.NET库和程序集,以及诸如Visual Studio加载项之类的工具。

cpython和ironpython(以及jython,就这点而言,它将与ironpython相同的概念应用于jvm——Jim Hugunin是jython的创始人,早在他移居到微软之前,他就在微软创立了ironpython,这两个项目现在都很繁荣),这两者之间的区别主要在于垃圾收集和线程:ironpython和jython依赖于t继承者的底层平台(因此,您可以获得标记和清理垃圾收集和自由线程),cpython自己滚动(因此,它主要是引用计数gc,偶尔使用标记和清理来解决引用循环,线程受到全局解释器锁的阻碍)。

一个代码良好的Python脚本并不依赖于所讨论的实现细节(它从不假设GC立即发生,也从不假设一个操作在线程中是原子的,除了少数几个,比如queue.queue的方法,这些方法被明确记录为原子的),但是当然,在野外有很多脚本是草率的。例如:

data = open('x.txt').read()

这会使文件对象保持打开状态,直到被垃圾收集为止;在引用计数环境中,收集会立即发生(因此文件会尽快关闭),而在标记和扫描环境中,情况并非如此(因此,使用此类构造的进程通常会错误地将某些文件(可能是许多文件)保持打开时间远长于嘿,需要,浪费系统资源。

所以, 适当的 相反,python编码是:

# needed in 2.5, unneeded but innocuous in 2.6
from __future__ import with_statement

with open('x.txt') as f: data = f.read()

哪一个 做 确保在每个实现中立即关闭文件 with 这样的说法非常方便;-)。

这不会影响您对python的学习,也不会妨碍正确编码的python代码的重用,但是如果您想要重用不规范编码的python代码(尤其是在长时间运行的服务器、服务、守护进程中),将来可能需要对其进行一些加强。因此,顺便说一句,那些希望使用更新和更好的c python版本的人,比如unladen swallow&c,一旦这些版本实现了更好的垃圾收集机制,摆脱了gil和其他增强功能;希望这已经改变了python社区的“文化”,朝着更正确、更少草率的编码迈进,当然还有e有无数行旧的松散代码,因此需要注意;-)。

大多数Python脚本在Ironpython中都能很好地工作。

这里是一个 list of packages and modules not included in IronPython 在最新版本中。

只要您的脚本不依赖于这些,它很可能在不进行更改的情况下工作。然而,通过将脚本迁移到使用.NET框架类而不是Python标准库,Ironpython的大部分“功能”都真正发挥了作用。