Większość wyników tego wyszukiwania to narzędzia, które produkują Pythona ze źródeł SAS, i kilka z nich robi to dobrze. Ta strona zaczyna o krok wcześniej: czy przenosiny w ogóle mają sens dla waszej bazy kodu, ile kosztuje sprawdzenie wyniku i co zrobić, gdy odpowiedź brzmi nie.
Z bazy kodu w SAS wychodzą cztery drogi, nie dwie: oddać ją automatycznemu narzędziu, przepisać ręcznie, uruchomić programy SAS bez zmian na czymś, co nie jest SAS, albo zostawić ją w spokoju. Która jest właściwa, zależy niemal wyłącznie od dwóch pytań: ile jest kodu i czy ktoś musi odtworzyć to, co programy dawały wcześniej. Wszystko poniżej to koszt każdej drogi.
Python bywa lepszym celem częściej, niż strona taka jak ta zwykle przyznaje. Cztery warunki czynią wybór oczywistym: baza kodu jest na tyle mała, że jedna osoba przeczyta ją w tydzień, zespół i tak pisze Pythona na co dzień, analiza i tak zostanie zbudowana od nowa, a nic dalej w łańcuchu nie wymaga, by nowe liczby zgadzały się ze starymi co do cyfry. Gdy zachodzą wszystkie cztery, napisanie od nowa wychodzi taniej niż jakakolwiek warstwa zgodności, a zostaje kod, który zespół utrzyma bez drugiego języka.
Każda opcja tutaj jest dla kogoś właściwą odpowiedzią. Żadna nie jest bez kosztu, a droga część to nigdy nie składnia.
Narzędzia webowe, usługi dostawców i duże modele językowe biorą źródło .sas i zwracają Pythona, zwykle odwzorowując kroki DATA na pandas, a popularne procedury na statsmodels lub scikit-learn. Przy kilkuset wierszach prostego przetwarzania danych to prawdziwy skrót, a czytelny punkt wyjścia macie w kilka minut. Rachunek przychodzi później: każdy wiersz wyniku musi przeczytać ktoś, kto zna oba języki.
Ktoś czyta program SAS, ustala, co miał robić, i pisze to w Pythonie. Rusza wolniej i jest jedyną drogą, która kończy się kodem o kształcie Pythona, a nie SAS w pythonowym płaszczu. Zespoły zadowolone z Pythona po dwóch latach prawie zawsze doszły tam w ten sposób, zwykle pozwalając staremu programowi działać obok, aż liczby się zgodziły.
Droga, którą strony porównawcze pomijają. Jenner to implementacja języka SAS 9.4 wykonana w czystym pokoju i napisana w Rust: czyta pliki SAS7BDAT bezpośrednio i wykonuje źródło .sas takie, jakie jest, więc nie ma wygenerowanego kodu do przejrzenia ani drugiego języka do dźwigania przez zespół. Czego nie robi, to pokrycie całego języka SAS, a zakres jest publikowany procedura po procedurze, żebyście sprawdzili swoją, zanim na niej polegniecie.
Nicnierobienie to prawdziwa decyzja i często słuszna. Jeśli kod jest stabilny, środowisko, w którym działa, nie znika w tym roku i nikt nie prosi o zmianę, migracja, której nie robicie, ma najlepszy zwrot z całej tej strony. Wróćcie do pytania, gdy wymusi je zmiana platformy, audyt albo problem z rekrutacją.
Automatyczna konwersja nie zawodzi na błędzie składni; ten wychodzi przy pierwszym uruchomieniu. Zawodzi cichą różnicą liczbową. SAS dopełnia wartości znakowe spacjami z prawej, a Python nie, SAS liczy daty od 1 stycznia 1960, podczas gdy pandas od 1 stycznia 1970, a MERGE w kroku DATA nie zachowuje się jak merge w pandas, gdy klucz powtarza się po obu stronach. Nic z tego niczego nie zgłasza. Wychodzi liczba prawie poprawna, a to najgorszy rodzaj błędu. Dlatego prawdziwą ceną jest czytanie wiersz po wierszu przez kogoś, kto włada oboma językami, plus okres, w którym stare i nowe działają obok siebie na tych samych danych, aż wyniki się zgodzą — a ta cena rośnie z ilością kodu, nie z jego pomysłowością.
Wasz kod, wasze dane i logi obok siebie. To jest porównanie, które rozstrzyga, i nikt nie uruchomi go za was.
Rozpocznij bezpłatny okres próbny