IronPythonと元のPythonの比較。私は最初のものから何を期待できますか？

Question

私はPythonを学びたいと思っていますが、.NETでC＃開発者として一日中働いているので、IronPythonをダウンロードしてインストールし、IronPythonスタジオを統合することにしました。元のPythonとはどのように異なっているか類似していますか？ .Net開発者としては、.Net環境で従来のPythonスクリプトを問題なく実行することができますか？これはまったく同じ古い移行ユートピアですか？私は何を期待できますか？

ありがとうございます。

EDIT：Dic。 2009 - IronPythonは最近2.6にアップグレードされました。可能であれば、あなたの回答をアップグレードしてください。

Answer 1

あなたの状況では、IronPythonを勉強するのは完全に合理的です（特に、this bookがそれを手助けする素晴らしい仕事です）！基本的にすべてのPython 2.5の機能にアクセスできます（IronPythonがPythonの2.6バージョンにアップグレードされるときは確かではありませんが、2.5はすでに使用可能です）。とあなたが知っていると愛しているすべての.NetライブラリとアセンブリVisual Studioアドインなどのツール。

CPythonとIronPython（とJythonは、IronPythonと同じ概念をJVMに適用します） - Jim Huguninは、IronPythonを起点としたMicrosoftに移行するずっと前からJythonの創始者でしたIronPythonとJythonはその基盤となるプラットフォームに依存しているため、ガーベジコレクションとフリースレッドを使用しているため、CPythonは独自のロールを持ちます（したがって、参照カウントGC、参照ループを解決するためにしばらくの間、マークとスイープを使用し、グローバルインタプリタロックによって妨げられるスレッドを使用します）。

よくコーディングされたPythonスクリプトは、問題の実装の詳細に依存していません（GCはただちに発生するとは決して決して思っていません、Queue.Queueのメソッドのように、明示的に文書化されています）、もちろん、野生の中には、大雑把なスクリプトがたくさんあります。たとえば、

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

これは、ガベージコレクションされるまでファイルオブジェクトを開いたままにします。参照カウント環境では、コレクションは即座に行われます（そのため、ファイルはできるだけ早く閉じられます）。そのような構造を使用するプロセスは、誤っていくつかのファイル、多分多くのファイル、無駄に必要以上に長く開いて、システムリソースを無駄にする& c）。

ので、適切 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コードの再利用を妨げることもありません。特に、長時間実行しているサーバー、サービス、デーモンプロセス、& c）将来的にはそれを強化する必要があるかもしれません。だから、btwはUnladen Swallow & cのような、より新しいガーベジコレクションメカニズムを実装し、GILを取り除き、そしてその他の拡張を行うなど、より新しいCPythonバージョンを使いたい人たちです。うまくいけば、これは既にPythonコミュニティの "文化"をより正確でより控えめなコーディングに変えているのですが、もちろん古いコードがたくさん並んでいるので、いくつかの注意が必要です。

Answer 2

ほとんどのPythonスクリプトは、IronPythonでうまく機能します。

最新リリースのlist of packages and modules not included in IronPythonです。

スクリプトがこれらに依存しない限り、変更なしで動作する可能性が最も高いです。しかし、IronPythonの「力」の多くは、スクリプトをPython標準ライブラリの代わりに.NETフレームワーククラスを使用するように移行することで実際に機能します。