既存のコードがどのように構築されているか、または新しいバージョンがどのように動作する予定であるかを知らなければ、具体的に答えるのは難しいですが、いくつかの一般論を述べることができます.
IronPython の制限事項/問題点 (重要度の高い順): * サードパーティの C 拡張モジュールはありません。依存している場合は、同等の .NET を見つけるか、同じものを自分で再実装する必要があります。そうでない場合は、問題ありません。* 3.x はありません。3.x を知っていれば、Unicode の方がはるかに簡単です。yield from
2.x は停滞しているのに対し、3.x は改善を続けています (さらには高速化さえしています)。しかし、これがどれくらいの価値があるかは個人の好みの問題であり、他の誰かが客観的に答えられるものではありません. * refcounting セマンティクスに (重要な方法で) 依存するサードパーティの純粋な Python モジュールはありません。これらはあまり多くありませんが、必要な場合は必要です。* IronPython と CPython の間にはいくつかの違いがあり、リリース ノートに記載されています。おそらくこれらのどれもあなたに影響を与えることはありませんが、確認する必要があります. * 負荷の高いアプリケーション ロジックがある場合 (すべての作業がネットワーク/ファイル/データベースであるのとは対照的に)、IronPython はいくつかの点で CPython よりもはるかに高速であり、他のいくつかの点ではるかに遅いため、おそらくプロファイリングとパフォーマンスが必要です。いずれかの道を行き過ぎる前にテストしてください。(そして、少なくとも PyPy を考慮してください。
次に、大容量システムに適した Windows プラットフォームはありますか? Windows は間違いなく、1 秒あたり数千の接続 (または要求、バイト、またはユース ケースに最も関連するもの) を処理できます。純粋な接続/秒/$ で Linux に勝ることはおそらくないでしょうが、運用コストと開発コストを現実的にトレードオフする必要があります。ただし、少し単純化しすぎると、Windows はリアクターを苦手とし、プロアクターを苦手としますが、Linux はリアクターを苦手とし、プロアクターを苦手とします (その他にも同様の問題があります。たとえば、上記の代わりにプロセス/スレッドを使用します)。したがって、Windowsは一般的に Linux とほぼ同じように機能しますが、同じコードではそれほどうまく機能しません。、または多くの場合、同じデザインでさえあります。Windows の機能を活用し、Windows の弱点を考慮してコードを設計する必要があります。また、フレームワークを使用して面倒な作業を行っている場合、選択肢が少なくなり、最良の選択肢が慣れ親しんだように機能しない可能性があります。これは通常、プラットフォームを変更するよりも開発コストがはるかに高くなります。 .
Linux で CPython を使用する場合、どの IDE を使用する必要がありますか? Visual Studio に固執します。すべてまたはほとんどのコードを、IronPython と Linux CPython の両方で実行されるクロスプラットフォームの方法で作成できます。また、おそらくそうするべきです。その後、Visual Studio で Iron Python を使用してコーディング、テスト、およびデバッグを行い、ネイティブの Windows CPython および/または Cygwin CPython を使用して時折の健全性チェックを行い、パフォーマンス テスト、リリース前の最終受け入れテスト、および問題のデバッグには Linux のみを使用します。 Windows での再現。Linux ではシンプルなテキスト エディタが必要になる場合もありますが、IDLE、vi-vs.-emacs のいずれか、または Linux ディストリビューションにデフォルトで付属している GUI テキスト エディタで十分です。
アプリケーション ロジックがリアクターの設計などと密接に結合している場合、これは困難な場合があります。実行できる場合は、おそらく実行する価値がありますが、そうでない場合は、実際のコードが Linux ボックスで実行されることを意図していても、Visual Studio をエディターおよびプロジェクト オーガナイザーとして使用できます。その方法では気の利いたデバッガー統合などは得られませんが、それでも多くのマイレージを得ることができます。