이 검색의 결과 대부분은 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와 같게 동작하지 않습니다. 어느 것도 아무 경고를 내지 않습니다. 거의 맞는 숫자가 나올 뿐이고, 그것이 가장 나쁜 종류의 오답입니다. 그래서 진짜 값은 두 언어에 능숙한 사람의 한 줄씩 읽기, 그리고 출력이 일치할 때까지 같은 입력으로 옛것과 새것을 나란히 돌리는 기간입니다. 그 값은 코드의 양에 따라 커지지, 코드의 영리함에 따라 커지지 않습니다.