blocks|key|3100442|text|如果你想让你的代码主要基于.NET框架，我强烈推荐IronPython和Python.NET。IronPython几乎是原生的.NET+-所以它在与其他.NET语言集成时工作得很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3100443|如果您只想将.NET中的一两个组件集成到标准的python应用程序中，那么Python.NET是很好的选择。|3100444|在使用IronPython时有一些显著的区别--但大多数都是相当微妙的。Python.NET使用标准的CPython运行时，因此this+Wiki+page是两种实现之间差异的相关讨论。最大的差异出现在异常的成本上-因此，由于其实现的原因，一些标准的python库在IronPython中不能很好地执行。|offset|length|3100445|entityMap|0|LINK|mutability|MUTABLE|url|http://ironpython.codeplex.com/Wiki/View.aspx?title=IPy1.0.xCPyDifferences&referringTitle=Home^0|0|0|1S|E|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

If you want to mainly base your code on the .NET framework, I'd highly recommend IronPython vs Python.NET. IronPython is pretty much native .NET - so it just works great when integrating with other .NET langauges. 

Python.NET is good if you want to just integrate one or two components from .NET into a standard python application.

There are notable differences when using IronPython - but most of them are fairly subtle. Python.NET uses the standard CPython runtime, so <a href="http://ironpython.codeplex.com/Wiki/View.aspx?title=IPy1.0.xCPyDifferences&amp;referringTitle=Home" rel="noreferrer">this Wiki page</a> is a relevant discussion of the differences between the two implementations. The largest differences occur in the cost of exceptions - so some of the standard python libraries don't perform as well in IronPython due to their implementation.

blocks|key|3313316|text|IronPython是“.NET原生的”--因此，如果您希望将Python代码与.NET完全集成，它将是更好的选择；Python.NET与Classic+Python一起工作，因此它允许您将Python代码的“手臂长度”与.NET保持适当的距离。(请注意，使用this+code，您实际上可以在IronPython代码中使用为CPython编写的扩展，因此这不再是一个有区别的条件)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3313317|entityMap|0|LINK|mutability|MUTABLE|url|http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml^0|3M|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

IronPython is ".NET-native" -- so it will be preferable if you want to fully integrate your Python code with .NET all the way; Python.NET works with Classic Python, so it lets you keep your Python code's "arm's length" away from .NET proper. (Note that with <a href="http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml" rel="noreferrer">this code</a> you can actually use extensions written for CPython from your IronPython code, so that's not a discriminating condition any more).

blocks|key|333835|text|IronPython来自微软，所以我会凭直觉优先使用它，因为你必须假设它会与其他微软技术配合得更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|333836|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

IronPython comes from Microsoft, so I would go with my gut and use that one first since you have to assume it will play nicer with other MSFT technologies.

blocks|key|338764|text|在同意Reed+Copsey和Alex+Martelli给出的答案的同时，我想指出另一个不同之处--全局解释器锁(GIL)。虽然IronPython没有GIL的限制，但CPython有-所以对于那些GIL是瓶颈的应用程序来说，比如说在某些多核场景中，IronPython比Python.NET更有优势。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|338765|从Python.NET文档中：|338766|Python对嵌入者的重要说明:+Python不是自由线程的，它使用全局解释器锁来允许多线程应用程序与|338767|解释器安全地交互。有关这方面的更多信息，请参阅www.python.org网站上的Python+C+API文档。|blockquote|offset|length|style|CODE|338768|338769|在托管应用程序中嵌入Python时，您必须以与在C或C%2B%2B应用程序中嵌入Python时相同的方式来管理GIL。|338770|在与Python.Runtime名称空间提供的任何对象或API交互之前，调用代码必须已经通过调用PythonEngine.AcquireLock方法获得了Python全局解释器锁。此规则的唯一例外是PythonEngine.Initialize方法，该方法可以在启动时调用，而无需获取GIL。|338771|使用完Python后，托管代码必须调用相应的PythonEngine.ReleaseLock来释放GIL并允许其他线程使用Python。|338772|AcquireLock和ReleaseLock方法是Python+API中非托管PyGILState_Ensure和PyGILState_Release函数的薄包装器，这些API的文档适用于托管版本。|338773|338774|另一个问题是IDE支持。目前CPython可能比IronPython有更好的集成开发环境支持--所以这可能是选择其中一个的一个因素。|338775|entityMap^0|0|0|0|N|E|0|0|0|2|E|1C|O|2R|N|0|M|O|0|0|B|C|B|14|H|1M|I|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|13|8|@$I|14|J|15|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|18|8|@$I|19|J|1A|K|L]|$I|1B|J|1C|K|L]|$I|1D|J|1E|K|L]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1F|8|@$I|1G|J|1H|K|L]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1I|8|@$I|1J|J|1K|K|L]|$I|1L|J|1M|K|L]|$I|1N|J|1O|K|L]|$I|1P|J|1Q|K|L]]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|Z|$]]

While agreeing with the answers given by Reed Copsey and Alex Martelli, I'd like to point out one further difference - the Global Interpreter Lock (GIL). While IronPython doesn't have the limitations of the GIL, CPython does - so it would appear that for those applications where the GIL is a bottleneck, say in certain multicore scenarios, IronPython has an advantage over Python.NET.

From the Python.NET documentation:

<blockquote>
 Important Note for embedders: Python
 is not free-threaded and uses a global
 interpreter lock to allow
 multi-threaded applications to
 interact safely with the Python
 interpreter. Much more information
 about this is available in the Python
 C API documentation on the
 <code>www.python.org</code> Website.
 
 When embedding Python in a managed
 application, you have to manage the
 GIL in just the same way you would
 when embedding Python in a C or C++
 application.
 
 Before interacting with any of the
 objects or APIs provided by the
 <code>Python.Runtime</code> namespace, calling code
 must have acquired the Python global
 interpreter lock by calling the
 <code>PythonEngine.AcquireLock</code> method. The
 only exception to this rule is the
 <code>PythonEngine.Initialize</code> method, which
 may be called at startup without
 having acquired the GIL.
 
 When finished using Python APIs,
 managed code must call a corresponding
 <code>PythonEngine.ReleaseLock</code> to release
 the GIL and allow other threads to use
 Python.
 
 The <code>AcquireLock</code> and <code>ReleaseLock</code>
 methods are thin wrappers over the
 unmanaged <code>PyGILState_Ensure</code> and
 <code>PyGILState_Release</code> functions from the
 Python API, and the documentation for
 those APIs applies to the managed
 versions.
</blockquote>

Another issue is IDE support. CPython probably has better IDE support at present than IronPython - so this may be a factor in the choosing of one over the other.

blocks|key|338810|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|338811|Ironpython类似于C#，它依赖于静态预构建库，而C#不同于C%2B%2B是一种动态language.|ordered-list-item|338812|Cpython类似于Ironpython是一种动态语言，并且可以访问动态库，这反过来又意味着被迫编写everything.|338813|Ironpython在某些方面比C#快，但不比Cpython快，但是你可以将Ironpython链接到任何语言，从而克服即将出现的问题，但你也可以用cpython语言做同样的事情。|338814|338815|一种有趣、简单和强大的语言，无论你选择哪种语言！|338816|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|N|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|O|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|P|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|Q|7|@]|8|@]|9|$]]|$1|I|3|J|4|5|6|R|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|S|7|@]|8|@]|9|$]]]|L|$]]

<ol>
<li>Ironpython is like C# in turn it relies on static prebuilt libraries while unlike C# is a dynamic language.</li>
<li>Cpython is like C++ like Ironpython is a dynamic language and has access to dynamic libraries which in turn translates to being forced to write everything.</li>
<li>Ironpython is faster than C# in certain areas but not faster than Cpython, however you can link Ironpython to any language thus over coming problems but then again you can do the same with Cpython.</li>
</ol>

A funny, simple and powerful language regardless what you choose!

blocks|key|3313523|text|大多数科学和数值Python库依赖于CPython+C-API+(numpy、scipy、matplotlib、pandas、cython等)。主要在CPython下工作，所以在这种情况下，你最好的选择是pythonnet+(其他名称-+Python.NET和.NET的Python+)。WxWidgets、PyQt/PySide、GTK、Kivy等CPython图形用户界面绑定也是如此，尽管pythonnet和IronPython都可以使用WPF和WinForms。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3313524|最后，IronPython还不完全支持Python3。|3313525|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Most of scientific and numerical Python libraries that rely on CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) are working mostly under CPython, so in that case your best bet is pythonnet (other names - Python.NET and Python for .NET).
The same is true for CPython GUI bindings such as WxWidgets, PyQt/PySide, GTK, Kivy, etc., although both pythonnet and IronPython can use WPF and WinForms.

And finally IronPython does not fully support Python 3 yet.

blocks|key|3313562|text|至于2016年。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3313563|在我的公司，我们使用IronPython，但我们对性能不满意(主要是内存使用-垃圾收集器太慢了)，所以我们决定改用标准的Python，并使用Zeroce-s将其与.Net集成。|3313564|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

As for 2016. 

In my company we used IronPython, but we were not satisfied with performances (mostly memory use - garbage collector was too slow) so we decided to switch to standard Python and integrate it with .Net using Zeroce-s ICE.

blocks|key|336497|text|我主要喜欢Python+for+.NET，因为IronPython被编译成托管代码，可以很容易地反编译(这是我最讨厌的)，但是使用py2exe或pyinstaller，您可以将带有.NET模块的Python编译为非托管应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|336498|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I mainly prefer Python for .NET, because IronPython is compiled as managed code, which can be easily decompiled (what I most hate), but with py2exe or pyinstaller you can compile Python with NET module as an unmanaged application.

blocks|key|3100822|text|目前，IronPython不支持Python3.6(仅2.7)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3100823|来自IronPython+3的“尚未提供IronPython+3的内部版本”。|offset|length|3100824|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/IronLanguages/ironpython3#ironpython-3^0|0|2|C|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

IronPython, currently, doesn't support Python 3.6 (only 2.7)

from <a href="https://github.com/IronLanguages/ironpython3#ironpython-3" rel="nofollow noreferrer">IronPython 3</a> "Builds of IronPython 3 are not yet provided."

blocks|key|3313649|text|Iron+Python基本上是Python2.7，带有集成的.net支持，它可能永远不会支持Python3。它失去了C和Python库，但在扭曲方面可以访问.net，并可以用C#扩展。因此，如果你已经在使用C#，那么Iron+Python将是一个额外的奖励。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3313650|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Iron Python is basically Python 2.7 with integrated .net support it probably will never support Python 3. It loses out on C and Python libraries, however on the twist side has access to .net and can be extended with C#. So if you use C# already then Iron Python is a bonus.

I want to access some .NET assemblies written in C# from Python code. 

A little research showed I have two choices:

<ul>
<li><a href="http://www.codeplex.com/IronPython" rel="noreferrer">IronPython</a> with .NET interface capability/support built-in</li>
<li>Python with the <a href="https://github.com/pythonnet/pythonnet" rel="noreferrer">Python .NET</a> package</li>
</ul>

What are the trade-offs between both solutions?

IronPython vs. Python .NET

集成开发环境

解释器

Python

我想从Python代码访问一些用C#编写的.NET程序集。一项小小的研究表明我有两个选择：具有.NET接口功能的 /支持built-inPython以及 package两种解决方案之间的权衡是什么？

问IronPython与Python .NET
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问IronPython与Python .NETEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问IronPython与Python .NET
EN