今から何年も実行されるコードを書く
プログラミング言語が変わります。ライブラリが変更されます。5年、10年、または20年前のコードも実行され、期待どおりの結果が得られる場合がありますが、2年前のコードは構文エラーで失敗する場合があります。言語は進化しているため（少なくとも、ほとんどは進化しているため）、これは部分的に避けられません。開発者には、コードを維持する責任があります。しかし、生産コードでは安定性が重要な要件である場合があり、コードを毎年変更して言語の変更に適応させる必要なく、コードを10年間実行する必要があります。または、たとえば科学データ分析用の小さなスクリプトがあり、それらを何年も触れなかった後に再訪する必要があるかもしれません。たとえば、気象庁では、速度が重要ではない部分にも多くの操作可能なFortranコードがあり、コードの安定性が理由の1つです。私' 不安定性への恐怖は、Pythonへの移行に対する彼らのオブジェクトの1つです（もちろん、言語のinertia性は別として、古いコードに依存しない新しいコードに対してのみ可能です）。もちろん、安定したコードの1つの戦略は、オペレーティングシステム全体を凍結することです。しかし、それは常に実現可能ではありません。
例としてPythonを使用していますが、問題は特にPythonに限定されません。
Pythonの互換性の問題に関するドキュメント
Pythonの場合、後方互換性のない変更に関するポリシーの概要を示すドキュメントがいくつかあります。
PEP-5
PEP 5によると：
Pythonの移行バージョンのリリースと後方互換性のないバージョンのリリースとの間には、少なくとも1年間の移行期間が必要です。ユーザーは、少なくとも1年はプログラムをテストし、非推奨の構成の使用から別の構成に移行する必要があります。
個人的には、1年はかなり短いと思います。つまり、コードを書く可能性がありますが、1.5年後にはもう実行されなくなります。
PEP 291
PEP 291には、下位互換性を維持するために避けるべき事項のガイドラインの不完全なリストが含まれています。ただし、Python 2.xのみに関連します。Python 2.7は2.xシリーズの最終リリースであり、Python 2.7はバグ修正のみであるため、このPEPは歴史的な関心のみになりました。
PEP 387
下位互換性のない変更に関するPEP 387もあります。PEP 387はドラフトであり、公式のポリシーではありません。2009年6月、これはPython-ideasメーリングリストで議論されました。ディスカッションの一部では、開発者が言語の変更に対して堅牢なコードを作成する方法に焦点を当てました。ある投稿は、やってはいけないことに関するいくつかのアドバイスをリストしました：
これに加えて、おそらくほとんどの場合に当てはまるいくつかのルールがあります：で始まるものを呼び出したり
"_"、モンキーパッチを適用したり、自分以外のクラスのオブジェクトで動的クラス置換を使用したりしないでください、継承階層の深さに依存せず（たとえば、no".__bases__[0].__bases__[0]"）、DeprecationWarningsを生成せずにテストを実行し、他のライブラリから継承するクラスに属性を追加するときに潜在的な名前空間の競合に注意してください。しかし、これらすべてが1か所に書き留められているとは思いません。
さらに、「地雷原」（新機能が変更される可能性が高い）と「凍結領域」（ほとんど販売されていないAPIが変更されないことが実質的に保証されている）についていくつかの点がありました。アントワーヌ・ピトルーの引用：
「凍結領域」は、負の値（明示的な「地雷原」）ではなく、正の値（明示的なパブリックAPIと明示的に保証された動作）で定義する必要があると思います。そうしないと、いくつかの重要なものを地雷原に置くことを忘れ、後から互換性のない方法でそれらのものを変更する必要があるときに噛まれます。
このスレッドから結論は出ていないようですが、探しているものの中核にかなり近づいています。スレッドはほぼ4年前であるため、状況はおそらく変更または改善されています。どのような種類のコードが存続する可能性が高く、どのような種類のコードがより脆弱ですか？
移植のガイドライン
上記のドキュメントに加えて、各Pythonバージョンには移植ガイドラインが付属しています：Python 3.2への移植、Python 3.3への移植など。
便利な互換性
PEP 3151は、有用な互換性の概念を紹介してくれました。私自身の言葉で言えば、これは、コードが慎重に記述されている場合にのみ、言語開発者が互換性を維持するように注意する必要があるという考えに要約されます。それは実際に有用な互換性を定義するものではありませんが、上記のPEP 387の議論から引用したアイデアに似ていると思います。
プログラマーの観点から
プログラマーとして、私はPythonが将来変化し、人々、特に私自身が、おそらく数年後に、1、2、または3つのマイナーバージョンアップのPythonバージョンでコードを実行しようとすることを知っています。すべてが互換性があるわけではありません。実際、失敗するコードを思い付くのは簡単です（かつて私が言ったコードに遭遇しましたif sys.version[:3] != '2.3': print 'Wrong version, exiting'）。私が探しているのガイドラインのセットです何をすべきか、何 ではない 行うには、私のコードはまだ将来的に変更されていない実行される可能性を高めるため。
そのようなガイドラインはありますか？将来も実行されるPythonコードを作成するにはどうすればよいですか？
私の質問は、Pythonコアとその標準ライブラリだけでなく、一般的に使用されるアドオンライブラリ、特にnumpy、scipyにも関連していmatplotlibます。
編集：これまでのところ、答えの2つはpython2対python3に関連しています。これは私が言っていることではありません。Python2からPython3に移行するツールについて知っています。私の質問はまだ来ない言語変更に関連しています。より安定したコーディングガイドラインを見つけるには、クリスタルボールよりも優れています。例えば：
import moduleはfrom module import *、module1つ以上の新しい関数/クラスが大きくなるとコードが壊れる可能性があるため、より将来性があります。文書化されていないものは、まだ安定していないことの兆候である可能性があるため、文書化されていないメソッドを使用すると、文書化されたメソッドを使用する場合よりも将来性が低くなる場合があります。
私が求めているのは、この種の実用的なコーディングのアドバイスです。現在から未来についてですので、Python2はもう変更されないため、Python3に限定することができます。