Kategoria: Inne

Tak się składa, że ostatnio podstawowym językiem programowania, którego używam, jest Python. W związku z tym kilka przemyśleń na jego temat i na temat rozpoczynania zabawy z nim. Disclaimer: do Pythona podchodziłem już kiedyś, jeśli muszę coś napisać, to domyślnie korzystam z Perla. Niekoniecznie pięknego, często poganiającego polecenia systemowe, ale działającego. Historycznie bawiłem się Pascalem, C i oczywiście miałem kontakt z Bashem i PHP (do ostatniego oficjalnie się nie przyznaję).

Po pierwsze, istnieją czytelne reguły, np. PEP 8, którego wszyscy używają^[1] czy PEP 20. Są też narzędzia, które ułatwiają zachowanie zasad dotyczących formatowania kodu, aby był zgodny z wytycznymi. Nie sposób tu nie wspomnieć o edytorze Atom, którego kiedyś włączyłem i wydał mi się straszną kobyłą. Jednak w połączeniu z pluginami działa naprawdę dobrze. Na tyle na ile mogę stwierdzić przy tak małym doświadczeniu. W każdym razie ma wszystko, do czego używałem kate. I sporo więcej. Vim nigdy mi nie podszedł na tyle, bym go używał w bardziej zaawansowany sposób. Do szybkich poprawek zawsze było albo nano, albo właśnie vim. Ale tryb tekstowy to nie jest to, co preferuję przy pracy nad dłuższym kodem.

Po drugie, dostępnych jest dużo materiałów do nauki Pythona. Także bezpłatnych. Samych książek/kursów jest kilkanaście (choćby oficjalny The Hitchhiker’s Guide to Python). Istnieją też gry, które uczą programować w Pythonie. Choćby Codecombat, którym kiedyś się bawiłem, o którym miała być notka, ale które ostatecznie mnie nie wciągnęło, a pomysł na notkę jakoś się rozmył. Mi do gustu przypadł jednak interaktywny kurs Learn Python na Androida. Jednak jeśli coś piszę i są interaktywne testy, a nie tylko czytam, to zapamiętuję więcej. Oczywiście nawet jeśli zapamiętam to do poziomu „potrafię użyć w programie” jest jeszcze kawałek, ale przynajmniej rozumiem przykłady i gotowy kod.

Po trzecie, istnieje sporo gotowych modułów, które ułatwiają pisanie. Jednak nawet gdyby nie istniały, to kod można „pożyczać” z innych skryptów przy pomocy import. I można mieć różne wersje bibliotek za sprawą środowisk wirtualnych. Z jednej strony fajne, z drugiej tworzy bałagan. Do developerki przydatne i zgodne z modną ostatnio ideą konteneryzacji. Ogólnie nauczyłem się z tym żyć, ale odruchu, żeby wszystko robić w virutalenv jeszcze nie mam.

Skoro mowa o bałaganie, to pora na wady, a tych jest zaskakująco wiele. Po pierwsze, Python 2 nadal żyje, ma się dobrze i można go spotkać na wolności. Taka umowna wada i na razie nie bardzo przeszkadza. Niemniej, nie każdy kod napisany w Pythonie 3 daje się wykorzystać w wersji drugiej.

Inna trochę dziwna na początku rzecz, to struktury danych. Jest tablica (list, w Perlu array), jest tablica asocjacyjna (dict, w Perlu hash). Ale są też tuple (niemodyfikowalne listy) i sety (nieuporządkowane zbiory unikatowych wartości). Nie żebym nie widział zalet, ale żeby aż wydzielać to? Zwł. sety (normalnie to po prostu się hasha tworzy, klucze są nieuporządkowane i unikatowe)…

To co się najbardziej rzuca w oczy: wcięcia. Są wymagane i rzutują na kod. Najprostszy przykład to:

for i in range (3):
    print ("wartosc: ")
    print (i)

Usunięcie wcięcia w ostatnim wierszu totalnie zmieni sposób działania programu. Drażni szczególnie na początku, gdy chcemy coś na szybko przetestować i np. coś wklejamy. Trzeba poprawić i dokładnie sprawdzić wcięcia, inaczej mogą być kwiatki jak wyżej.

Kolejna rzecz, która irytuje, to wciskanie filozofii w stylu zen. Na siłę i niekoniecznie zgodnie z prawdą. Weźmy mój ulubiony przykład:

There should be one– and preferably only one –obvious way to do it.

No to teraz bierzemy na tapetę set. Można go utworzyć przez

mojset = set([1, 2, 3])

Ale od wersji 2.7 można użyć do tworzenia równoważnej formy

mojset = {1, 2, 3}

Nie ma problemu? No to jak utworzyć pustego seta? Gdyby ktoś wpadł na całkiem logiczny pomysł użycia

mojset = {}

to niech wie, że nie pustego seta stworzył, a pustego dicta i za chwilę dostanie błędem po oczach. BTDT, dobry kwadrans dumania, czemu to nie działa. Dopiero wezwana pomoc uratowała sytuację, bo nie wiem ile bym jeszcze nad tym dumał.

Także one way my ass, skoro Tim Toady wita nas już na samym wstępie, przy tworzeniu jednego z podstawowych typów danych.

Możliwe, że dla ludzi, którzy zaczynają programowanie od Pythona, wady nie są tak zauważalne czy irytujące.

Niemniej, oddaję sprawiedliwość – w Pythonie pisze się przyjemnie i w praktyce jest to łatwiejsze, niż wygląda na pierwszy rzut oka. Wystarczy przejrzeć jakiś tutorial. Zdarzało mi się pisać rozszerzenia do istniejących skryptów po kilku dniach styczności z językiem i nie było większych problemów. Więc faktycznie, może być czytelnie, prosto i wygodnie. Oczywiście mogło być tak, że na ładne skrypty trafiłem. 😉

Z Perlem oczywiście nie kończę, bo do pewnych rzeczy nadaje się IMHO lepiej. Trochę gratów mam w nim napisanych, ale wersji 6 raczej już nie zacznę.

[1] A przynajmniej prawie wszyscy. A przynajmniej starają się. Prawie wszyscy.

UPDATE: Wspomniany kurs Learn Python skończyłem i szczerze polecam. Świetna podstawka, traktująca szeroko o różnych zagadnieniach, przy czym, jednak, te praktyczne części są lepsze, a teoretyczne kuleją. Jest w sumie o wszystkim najważniejszym, z programowaniem obiektowym i regexpami włącznie. Zapomniałem też wspomnieć o ipython – bardzo fajny do szybkiego sprawdzenia jakichś drobiazgów.

Swoją drogą, dziwi mnie to wciskanie regexpów do nauki programowania. To jest IMHO osobna działka zupełnie i nijak się nie klei z resztą.

Przy okazji kolejny kamyczek do ogródka w Pythonie jest inaczej. Tym razem chodzi o re.match, które działa totalnie nieintuicyjnie, choć przyznaję, że w sposób zgodny z dokumentacją. Otóż ww. funkcja dopasowuje wyrażenie tylko na początku stringa. Czyli ma takie niejawne, hardcodowane ^ – i albo .* na początku, albo korzystamy z re.search, żeby było normalnie. One way my ass, ponownie. Szczęśliwie wyszło to na Learn Python, nie w praktyce. Nie wiem co za piękny umysł to wymyślił i w imię czego…