IronPython to Original Python comparison. What can I expect from the first one?_问答_开发者

I wish to learn Python but I'm working all day in .Net as a C# developer, so I decided to download and install IronPython and integrated IronPython studio. How different or similar from the original Python it is? As a .Net developer can I expect to run conventional Python script in .Net environment with no problem or this is just t开发者_C百科he same old migration utopia? What can I expect about?

Thanks in advance.

EDIT: Dic. 2009 - IronPython has been upgraded to 2.6 recently. Please upgrade your answers if is possible.

In your situation it's perfectly reasonable to study IronPython (especially as this book does a great job helping you do that!). You'll have access to essentially all of Python 2.5 functionality (not sure when IronPython will upgrade to a 2.6 version of Python, but 2.5 is already quite usable), plus all the .Net libraries and assemblies you know and love, and tools such as Visual Studio add-ins.

The differences between CPython and IronPython (and Jython, for that matter, which applies the same concept as IronPython to the JVM -- Jim Hugunin was the originator of Jython long before he moved to Microsoft where he originated IronPython, both projects now thrive) are chiefly in garbage collection and threading: IronPython and Jython rely on their underlying platforms (so, you get mark-and-sweep garbage collection and free threading), CPython rolls its own (so, it's mostly reference-count GC, with mark-and-sweep once in a while to resolve reference loops, and threading hampered by a global interpreter lock).

A well-coded Python script does not rely on the implementation details in question (it never assumes that GC happens immediately, never assumes that an operation is atomic under threading except for the few, like Queue.Queue's methods, that are explicitly documented to be), but of course there's plenty of scripts out in the wild that are sloppy. For example:

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

this leaves the file object open until it's garbage collected; in a reference-count environment the collection happens immediately (so the file gets closed ASAP), in a mark-and-sweep environment that is not the case (so the process using such constructs often would erroneously keep some files, maybe many files, uselessly open for far longer than they need to be, wasting system resources &c).

So, proper Python coding is instead:

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

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

which does guarantee immediate closure of the file in every implementation (the with statement is very very handy that way;-).

This doesn't affect your learning of Python, nor does it impede reuse of properly-coded Python code, but if and when you want to reuse sloppily-coded Python code (especially in a long-running server, service, daemon process, &c) you may in the future need to do some tightening up thereof. So, btw, will people who want to use newer and better CPython versions, such as Unladen Swallow &c, once those versions implement better garbage collection mechanisms, get rid of the GIL, and other enhancements; hopefully this is already changing the "culture" of the Python community towards more correct, less sloppy coding, but of course there's bazillions of lines of old sloppy code around, so some care is needed;-).

Most python scripts work perfectly well in IronPython.

Here is a list of packages and modules not included in IronPython in the latest release.

As long as your script doesn't rely on these, it will most likely work without changes. However, much of the "power" of IronPython really comes into play by migrating your scripts to use .NET framework classes instead of the python standard library.