この検索結果の多くは、SAS のソースから Python を生成するツールで、その仕事をうまくこなすものもいくつかあります。このページはその一歩手前から始めます。そもそもその移行が自分のコードベースにとって正しいのか、出力の検証に何がかかるのか、そして答えが「いいえ」だったときにどうするのか。
SAS のコードベースから出る道は二つではなく四つあります。自動ツールに渡す、手で書き直す、SAS 以外のもので SAS プログラムをそのまま実行する、そして何もしない。どれが正しいかは、ほぼ二つの問いだけで決まります。コードがどれだけあるか、そして以前の出力を誰かが再現しなければならないか。以下はそれぞれの道の費用です。
Python のほうが良い移行先である場面は、このようなページが普段認めるより多くあります。四つの条件がそろえば答えははっきりします。コードベースが一人で一週間に読み切れる程度であること、チームが日常的に Python を書いていること、分析をどのみち作り直すこと、そして新しい数値が以前の数値と厳密に一致することを下流の誰も求めていないこと。四つそろうなら、どんな互換レイヤーよりも書き直しのほうが安く、残るのは第二の言語を抱えずにチームが保守できるコードです。
ここにある選択肢はどれも、誰かにとっては正しい答えです。コストなしで済むものは一つもなく、高くつくのは決して構文ではありません。
ウェブツール、ベンダーのサービス、大規模言語モデルは .sas のソースを受け取って Python を返し、たいていは DATA ステップを pandas に、よく使う手続きを statsmodels や scikit-learn に対応づけます。単純なデータ加工が数百行なら本物の近道で、読める出発点が数分で手に入ります。請求書は後から届きます。出力の一行一行を、両方の言語を知る人が読む必要があるからです。
誰かが SAS プログラムを読み、何をするつもりだったのかを理解し、それを Python で書きます。立ち上がりは遅く、そして SAS の衣をまとった Python ではなく Python らしい形のコードで終わる唯一の道です。二年後に Python に満足しているチームは、たいていこの道を通っていて、数値が一致するまで古いプログラムを隣で動かし続けています。
比較ページが飛ばす道です。Jenner は SAS 9.4 言語のクリーンルーム実装で、Rust で書かれています。SAS7BDAT ファイルを直接読み、.sas のソースをそのまま実行するので、読み返すべき生成コードも、チームが抱える第二の言語もありません。できないのは SAS 言語のすべてを覆うことで、カバー範囲は手続き単位で公開されているため、頼る前に自分のものを確認できます。
何もしないことは本当の決断であり、しばしば正しい決断です。コードが安定していて、それを動かす環境が今年なくなるわけでもなく、誰も変更を求めていないなら、やらない移行がこのページで最も見返りの大きい選択です。プラットフォームの移動、監査、採用の問題がこの問いを迫ってきたら、また考えればよいのです。
自動変換の失敗の仕方は構文エラーではありません。構文エラーは最初の実行で表に出ます。問題は静かな数値の違いです。SAS は文字値の右側を空白で埋めますが Python は埋めません。SAS は日付を 1960 年 1 月 1 日から数え、pandas は 1970 年 1 月 1 日から数えます。そして DATA ステップの MERGE は、キーが両側で繰り返されるとき pandas の merge と同じようには動きません。どれも何も警告しません。ほとんど正しい数値が出るだけで、それが最も悪い種類の誤りです。だから本当の値段は、両方の言語に通じた人による一行ずつの読み合わせと、出力が一致するまで同じ入力で新旧を並べて動かす期間であり、その値段はコードの量に比例します。巧妙さではありません。