Kawałek znalezionego gdzieś w sieci kodu, rzucającego przyjemny pomost między najstarszym z autentycznie lubianych przeze mnie języków programowania a tym, po który najchętniej sięgam dzisiaj.

Dla osób przesiadających się z C++ czy Javy to jedna z bardziej szokujących właściwości Pythona (a także Perla i paru innych języków skryptowych): kod programu można zmienić w locie. Można - w szczególności - dopisać albo podmienić metody istniejącej klasy czy funkcje zadanego modułu.

Technika ryzykowna, łatwo prowadząca do powstawania niezrozumiałego kodu i trudnych do interpretacji błędów. Ale zarazem bardzo przydatna, zwłaszcza gdy trzeba zmodyfikować zachowanie jakiejś biblioteki w miejscu, którego jej autor nie przewidział (np. ostatnio przypomniałem ją sobie chcąc zmienić sposób w jaki Mercurial obsługuje hasła HTTP i SMTP). Monkey-patching bardzo często przydaje się też przy testach, pozwalając zamienić prawdziwy kod komunikacyjny czy bazodanowy zaślepkami.

W tym artykule o kilku możliwych sposobach zapisywania tej operacji.

Wirtualne środowiska Pythona bez problemu można wykorzystywać także przy pracy z Jythonem (a także do przełączania się między Pythonem a Jythonem). Nie wymaga to żadnych szczególnych działań, wszystko przebiega niemal identycznie jak pod Pythonem.

Ostatnia część relacji z polskiego Pycona (pierwsza jest tutaj, druga tutaj a trzecia tutaj). Słowo się rzekło, kobyłka u płotu, rozpoczęte dzieło trzeba zakończyć a Pycon z to-do, blogerowi lżej.

Do omówienia zostały wykłady niedzielne, opisuję też co uważam za najważniejsze własne wnioski z konferencji.

Kolejna część relacji z polskiego Pycona (jeśli ktoś nie czytał - pierwsza jest tutaj a druga tutaj). Sobotni wieczór.

Kontynuacja rozpoczętej wczorajszym wpisem relacji z polskiego Pycona. Tym razem o chyba najlepszym fragmencie konferencji czyli o sobotnim popołudniu.

Wybrałem się na tegoroczny polski Pycon do Ustronia. Oficjalną relację zamieszczą zapewne organizatorzy, poniżej trochę moich - bardzo subiektywnych - notatek.

Istotna uwaga: bardzo dawno nie byłem na żadnej branżowej konferencji, oceniam Pycona zestawiając go z własnymi oczekiwaniami.

Najpopularniejszym narzędziem do uruchamiania testów obciążeniowych jest JMeter. Nie potrafię się do niego przekonać - organicznie nie cierpię modelowania struktury kodu (tu - testów) w formie rozwijanego drzewa, gdzie zrozumienie co robią poszczególne elementy wymaga przeklikiwania się przez nie, a niekiedy nawet otwierania okienek właściwości. Prosty kod jest zdecydowanie czytelniejszy. Podobnie, wolę napisać wywołanie funkcji niż przeszukiwać wielopoziomowe prawoklikane menu.

Dlatego opisuję interesującą, lekką alternatywę, ciekawie łączącą testy wydajnościowe z jednostkowymi.

Jak właściwie poukładać kod źródłowy przy pisaniu bibliotek i skryptów w Pythonie? Problem wcale nie jest trywialny, stosowanych konwencji jest wiele, modułów utrzymywanych i dystrybuowanych jako chaotyczne paczki plików źródłowych - jeszcze więcej.

Opisuję niżej konwencję dobrze dopasowaną do pracy z użyciem wirtualnych środowisk pythona oraz SetupTools. Pasuje ona także do PyDev, czyli modułu pythonowego dla Eclipse. Zbieram tu techniki podejrzane w różnych cudzych bibliotekach, w sporej części opisane w książce Tereka Ziade.

Uzupełnienie do artykułu o wirtualnych środowiskach pythona. Skrypt virtualenvwrapper to miłe ułatwienie ich wykorzystywania - dla użytkowników Linuksa.

Poniżej omówienie funkcjonalności oraz krótka instrukcja.

Mamy pewną listę. Mamy jakąś funkcję testującą. Chcemy sprawdzić, czy dla jakiegokolwiek elementu listy funkcja testująca zwraca True.

To proste zadanko - bardzo częste w realnym kodzie - można wykonać na wiele sposobów.

Normalną metodą ładowania kodu pythonowego jest polecenie import i umieszczanie plików w standardowym drzewie modułów zarządzanym zmienną PYTHONPATH. To załatwia 99.9% przypadków.

W tym artykule o pozostałym 0.1% - kilka dziwnych ale czasem użytecznych technik ładowania kodu, od wczytywania pojedynczego pliku z nietypowego katalogu, po pisanie własnych ładowaczy modułów mogących generować kod, ściągać go ze zdalnej maszyny czy pobierać z bazy danych.

Próbuję się ostatnio wdrożyć w GTD (Getting Things Done), czyli modną od paru lat technikę zapisywania i porządkowania rzeczy do zrobienia. Sam pomysł by zapisywać sprawy i pomysły to nihil novi (czego ja już nie używałem - od issue trackera i różnych sieciowych kalendarzy po zbiory papierowych notatek) ale GTD przez swe rytuały i techniki daje pewną nadzieję na większą skuteczność (już mogę powiedzieć, że fajnie pozwala ograniczyć ilość naraz wiszących nad głową spraw).

Przesiadam się między kilkoma komputerami, więc narzuciło się użycie jakiejś aplikacji sieciowej. Pobawiłem się bodaj sześcioma i na razie wybrałem Nozbe - głównie dlatego, że zawiera to co trzeba a nie trzy razy za dużo (to w takiej aplikacji jest ważne), po części zaś w formie uznania dla rodaka (Michała Śliwińskiego), który ten serwis zrobił i promuje (bardzo ładnie i mądrze promuje, jego filmiki prezentujące GTD są zwarte i punktują kluczowe sprawy).

No ale w tym poście nie chcę pisać o GTD, Nozbe i jego konkurentach ani o alternatywnych metodach notowania zadań ale o narzędziu, które sobie przez dwa poprzednie wieczory napisałem.

Spodobała mi się kupiona niedawno książka o Pythonie. Spodobało mi się też miejsce, w którym ją kupiłem. Niżej o jednym i o drugim (przy czym księgarnia może być interesująca nie tylko dla miłośników Pythona).

Książka

Książka to Expert Python Programming autorstwa Tereka Ziadé.

Program musi obsłużyć kilka połączeń sieciowych naraz? Albo równocześnie wyświetlać interfejs i wykonywać jakieś przetwarzanie? Albo pośredniczyć w komunikacji między kilkoma klientami a kilkoma serwerami? Albo wysyłać maile. Albo ściągać dane z kilku źródeł. Albo... Oczywiste - trzeba użyć wątków!

To bywa dobre rozwiązanie, ale ma swój koszt. Nie będę się teraz szerzej rozwodził nad problemami synchronizacyjnymi, zakleszczeniami, kosztem przełączeń kontekstu, czy nadmiernym zużyciem pamięci (każdy wątek ma swój stos). Chcę pokazać, że jest inny sposób - nie tylko bardziej wydajny, ale często także łatwiejszy.