Trzy najlepsze Python IDE dla Data Scientistów

Jak powszechnie wiadomo, praca Data Scientista nie ogranicza się jedynie to wyprowadzania skomplikowanych równań na kartce papieru, ale jest to też praktyczna, programistyczna praca przy komputerze. Znajomość języków programowania, np. Pythona, a także bibliotek, takich jak Numpy, Pandas, Matplotlib, to jedno. Jednak wybór IDE, środowiska, w którym Data Scientist będzie pisał swój program lub przeprowadzał analizę eksploracyjną, jest także sprawą niesłychanie ważną.

Zanim przejdziemy do opisu najlepszych IDE dla Data Scientistów pracujących w Pythonie, zastanówmy się, czemu wybór środowiska jest taki ważny oraz czym dobre IDE powinno się charakteryzować. Przede wszystkim IDE powinno ułatwiać nam wykonywanie codziennych czynności, a przez to przyspieszać naszą pracę. Chodzi tu czasem o rzeczy naprawdę banalne, jak intuicyjna nawigacja po plikach w projekcie, możliwość posiadania paru plików otworzonych w kilku zakładkach czy wyświetlanie zawartości paru plików naraz, obok siebie. Możliwość dostosowania wyglądu IDE pod swoje potrzeby także jest bardzo ważne: chodzi tu o możliwość dowolnego przeciągania poszczególnych okien środowiska, aby były tam, gdzie wydaje nam się to najwygodniejsze, a także dowolność w ich otwieraniu i zamykaniu.

Analiza składni i co z tego wynika

Kolejną cechą, jaka zdecydowanie odróżnia środowisko z prawdziwego zdarzenia od zwykłego notatnika, jest kolorowanie składni. Osobne kolory otrzymują: słowa kluczowe danego języka, zmienne lokalne, pola klas, nazwy funkcji, metod, treść komentarzy czy stałych tekstowych. Dzięki temu jeden rzut oka w zupełności wystarczy, aby zorientować się, czy dany identyfikator jest argumentem metody czy polem klasy, poza tym pozwala to naszym umysłom łatwiej oddzielać od siebie poszczególne części kodu.

Rozumienie języka przez IDE sprawia, że może nam ono pomóc na o wiele więcej sposobów, niż tylko wspomniane wcześniej kolorowanie składni. Jest to chociażby podkreślanie błędów składniowych. Dzięki temu, jeśli zdarzy nam się literówka, widzimy ją od razu, bez konieczności napisania całego fragmentu kodu, a następnie jego uruchamiania, by przekonać się, że nasza funkcja nie działa z powodu braku wcięcia, dwukropka czy średnika.

Jeśli chodzi o wykrywanie błędów, to poza poprawianiem składni, dobre środowisko powinno także wspomagać proces tzw. debuggowania. Mamy tu na myśli uruchomienie kodu, a następnie możliwość prześledzenia, jak wygląda przepływ sterowania w programie, a także stan zmiennych w poszczególnych momentach działania aplikacji. Zazwyczaj taką analizę zaczynamy od postawienia tzw. breakpointa, czyli oznaczenia pewnego wiersza kodu, tak aby zatrzymać wykonywanie programu, gdy przepływ sterowania dotrze właśnie do niego. W tym momencie w nowym okienku powinniśmy być w stanie podejrzeć wartości zmiennych (powinno być to też możliwe po najechaniu na nią myszą), a także nakazać przejście do kolejnej instrukcji. W przypadku, gdy docieramy do wywołania funkcji, standardem jest to, że możemy wybrać, czy chcemy się w nią zagłębić, czy też potraktować ją jako pojedynczą instrukcję.

Oczywiście dobre środowisko programistyczne nie tylko pomaga nam w znajdowaniu błędów w istniejącym kodzie, ale też podpowiada, co napisać. Funkcję tę najczęściej nazywamy intellisense albo autouzupełnianiem. Oznacza to, że jeśli napiszemy nazwę obiektu, a następnie kropkę, wyświetli się nam okienko, w którym zobaczymy, co możemy po takiej kropce napisać. Najczęściej są to oczywiście pola i metody, które taki obiekt udostępnia. Co więcej, gdy już napiszemy wywołanie funkcji lub metody, dostaniemy informację, jakie argumenty ona przyjmuje. Taki sposób podpowiadania pozwala nam znacząco oszczędzić czas, który normalnie byśmy musieli spędzić czytając dokumentację.

Powiada się, że kod źródłowy znacznie częściej się czyta, niż pisze. Oznacza to m.in., że częstym scenariuszem jest czytanie własnego (albo cudzego) kodu sprzed paru tygodni lub miesięcy, by go zrozumieć i użyć w nowym projekcie lub po prostu zmodyfikować. W tym wypadku nieraz chcemy podejrzeć kod funkcji, która jest wywoływana w analizowanym przez nas fragmencie. Jednak ciało takiej funkcji może znajdować się w zupełnie innym pliku. Środowisko programistyczne powinno udostępniać nam możliwość automatycznego przejścia do definicji, niezależnie od tego, gdzie takowa się znajduje, poprzez ustawienie kursora na nazwie i naciśnięciu odpowiedniego skrótu klawiszowego. Co więcej, wcale nie takim rzadkim przypadkiem jest możliwość późniejszego cofnięcia się z powrotem.

Profesjonalne wytwarzanie oprogramowania: jakość kodu i jego wersjonowanie

Podczas profesjonalnego wytwarzania oprogramowania szczególną uwagę zwraca się na jakość kodu. Kod powinien nadawać się do wielokrotnego wykorzystania, a gdy ktoś będzie go czytał albo chciał zmodyfikować, nie powinien mieć z tym większych problemów. Oczywiście nie zawsze od razu wszystko udaje nam się napisać idealnie, a koncepcja potrafi zmienić się w trakcie. Dlatego bardzo przydatne są wszelkie funkcje, które pozwalają nam na tzw. refactoring, czyli takie operacje na kodzie źródłowym, które nie zmieniają jego działania, ale wpływają na jego jakość. Podstawową czynnością jest zmiana nazwy zmiennej lub funkcji czy metody. Funkcja wykonywała dwie czynności, ale po zmianach wykonuje jedną? Na pewno powinniśmy to odwzorować w jej nazwie. Po wybraniu nowego identyfikatora, inteligentne IDE wykryje i zamieni wszelkie wywołania takiej funkcji na nową nazwę w całym naszym projekcie. To samo tyczy się oczywiście zmiennych, tutaj także wszelkie jej wystąpienia zostaną zmienione.

Ostatnią cechą, jaką charakteryzować powinno się dobre IDE, jest integracja z systemem wersji, np. Gitem. W dzisiejszych czasach coraz rzadziej tworzy się oprogramowanie samemu, na swoim komputerze, bez współpracy z innymi ludźmi. Zazwyczaj kod źródłowy projektu jest trzymany na zewnętrznym serwerze, a wszyscy programiści pobierają jego kopię, dokonują zmian, a następnie przesyłają nową wersję z powrotem do publicznego repozytorium. IDE pomoże nam zobaczyć, jakie pliki zmodyfikowaliśmy, wybrać, które z nich chcemy wysłać na serwer, a także obejrzeć historię zmian danego pliku czy wycofać swoje zmiany i pobrać z powrotem kod z serwera.

Teraz, gdy wiemy, czym kierować się przy wyborze IDE, a także jakie są ich możliwości, pozostaje odpowiedzieć na pytanie, które z nich wybrać, będąc Data Scientistem programującym w Pythonie?

PyCharm

PyCharm jest na pewno środowiskiem programistycznym z prawdziwego zdarzenia, używanym przez różnych programistów Pythona, nie tylko tych z obszaru Data Science. Znajdziemy tu wszystkie opisywane wcześniej zalety. Możemy otwierać wiele plików w zakładkach, dowolnie dzielić okno, aby zobaczyć zawartość paru naraz, otwierać i zamykać inne okna. Tak samo bez zarzutu działa tu kolorowanie składni, debugowanie, autouzupełnianie kodu, przejście do definicji, zmiana nazwy funkcji czy integracja z systemem wersji.

PyCharm występuje zarówno w wersji darmowej (community), jak i płatnej, z dodatkowymi funkcjami. Na pewno warto najpierw zapoznać się z wersją bezpłatną, zanim zdecydujemy się wydać większą kwotę na płatną subskrybcję. Czy jednak oznacza to, że nie musimy już dalej szukać?

Jupyter/IPython

Wszystko, co do tej pory napisaliśmy, tyczy się następującego trybu pracy: najpierw piszemy w całości kod, a następnie go uruchamiamy. Dane są przetwarzane w całości, i tylko ostateczny wynik jest np. zapisywany do pliku lub bazy danych. O ile jest to typowy schemat postępowania dla programisty, o tyle nie jest on do końca wygodny dla analityka danych. Najczęściej zachodzi potrzeba działania małymi krokami: wczytania danych, podejrzenia ich, dokonania ich czyszczenia, pogrupowania, znów podejrzenia, co otrzymaliśmy, następnie policzenia prostych statystyk, by przejść do budowania różnych modeli. Tak więc jest to na zasadzie interaktywnej: na jeden nasz niewielki fragment kodu chcemy otrzymać jakiś wynik (może to też być tabela lub rysunek), i dopiero na jego podstawie zadecydować o dalszych krokach. Dopiero, gdy przejdziemy przez całą analizę, jesteśmy w stanie napisać pełen kod do naszego zagadnienia, np. w PyCharmie.

Dlatego taką popularnością wśród Data Scientistów cieszą się wszelkie edytory interaktywne. Jednym z najczęściej wymienianych jest Jupyter, który jest uogólnieniem i rozszerzeniem IPythona. Ma on spore ograniczenia w porównaniu do typowego IDE, takiego jak PyCharm, np. cały kod widzimy od góry do dołu, bez podziału na pliki (można oczywiście stworzyć parę notatników, ale to nie to samo, bo nie można np. zaimportować funkcji z jednego notatnika do drugiego). Tak samo nie pozwoli nam na zaawansowane debugowanie kodu, refactoring czy przejście do definicji. Jednak mamy tutaj dostęp do autouzupełniania kodu, podpowiedzi dotyczących argumentów funkcji czy szybkie zajrzenie do plików dokumentacji, co czasami w zupełności wystarczy. Co więcej, mamy tu cechy, których normalnie nie spotkamy: możemy przeplatać kod na przemian z markdownem, językiem pozwalającym na stworzenie schludnego tekstu, z pogrubieniem, kursywą czy wypunktowaniem. Tak więc Jupyter poza możliwością szybkiego tworzenia prototypów czy dokonania eksploracyjnej analizy danych, pozwala także w prosty sposób stworzyć raport, w którym mamy jednocześnie tekst, jak i wyniki naszych analiz, np. tabelę z średnimi czy histogram rozkładu wieku klientów.

Rodeo

Jeśli chcielibyśmy otrzymać kompromis pomiędzy pełnoprawnym IDE a pracą interaktywną, pewnym rozwiązaniem jest Rodeo. Jest ono wzorowane na RStudio, środowiskisku powszechnie używanym i uznawanym za standard dla języka R. Ekran Rodeo, podobnie jak RStudio, podzielony jest na 4 części: w jednej znajduje się nasz kod, w drugiej konsola Pythona, w której możemy zobaczyć wyniki poszczególnych wierszy naszego kodu, w trzeciej jest miejsce na rysunki, podczas gdy ostatnia zawiera nazwy zmiennych, które do tej pory stworzyliśmy wraz z wartościami.

Cała siła Rodeo polega na tym, że piszemy kod dokładnie w ten sam sposób, jak byśmy to robili w edytorze tekstowym, jednak gdy zaznaczymy pewien fragment kodu lub ustawimy kursor na danym wierszu, po wciśnięciu odpowiedniego skrótu klawiszowego otrzymujemy na konsoli wynik jedynie tego zaznaczonego fragmentu kodu. Tak samo po wykonaniu kodu tworzącego rysunek, możemy go od razu zobaczyć w odpowiedniej części IDE. O ile taki kompromis wydaje się idealny, niestety trzeba pamiętać, że w Rodeo debugowanie, zarządzanie plikami, przechodzenie do definicji czy refactoring nie jest tak wygodny, jak ma to miejsce w PyCharmie. Tak samo wynik naszej pracy nigdy nie będzie od razu gotowym raportem, gotowym do zaprezentowania szerszemu gronu odbiorców, jak w przypadku Jupytera. Jednak do codziennej pracy, która polega na interaktywnej analizie zbiorów danych i budowaniu prototypów modeli może okazać się nieco wygodniejszy od notatników Jupytera.

Jak widzimy, dobór odpowiedniego środowiska dla Data Scientista jest trudniejszy, niż dla zwykłego programisty. Poza standardowymi potrzebami, jak autouzupełnianie kodu czy wskazywanie błędów syntaktycznych, bardzo ważna jest możliwość pracy interaktywnej, której zazwyczaj nie udostępniają typowe IDE. Dlatego należy tak dobrać swój sposób pracy, aby być w stanie wykorzystać mocne strony każdego z dostępnych na rynku narzędzi.