PEP0 – kto, co, jak i gdzie?

---

Python Enhancement Proposal jest to rozwinięcie popularnego skrótu PEP, z którym każdy z testerów wykorzystujący w pracy Pythona, z pewnością się zetknął. Dokumenty te stanowią oficjalne zasady, reguły czy opisy nowych funkcji Pythona. Co ciekawe, PEP0 jest dokumentem zawierającym informacje dotyczące pozostałych PEP’ów.

Obecnie mamy dostępne niecałe 500 dokumentów, które są podzielone na kilka grup:

• Podstawowe – dotyczące procesu
• Inne Informacyjne
• Obowiązujące tymczasowo — mogą się zmienić
• Zaakceptowane, lecz mogą jeszcze nie obowiązywać
• W trakcie — rozważane
• Gotowe i stabilne
• Historyczne procesowe
• Odroczone
• Odrzucone i wycofane

Patrząc się na liczbę wszystkich dokumentów, łatwo się zniechęcić. Jednak jeżeli przyjrzeć się bliżej, można zauważyć, że każdy z dokumentów jest dodatkowo oznaczony kodem statusu oraz typu dokumentu. Dzięki temu możemy wyselekcjonować te, które aktualnie są zaakceptowane (A), odrzucone (R), wycofane (W) czy zastąpione (S). Pełny opis statusów oraz typów znajduje się również w dokumencie PEP0. Poniżej zamieszczam opis kilku dokumentów, które w mojej ocenie dobrze jest przeczytać.

PEP 8 – Style GUide for Python Code

Dokument zawiera wiele ciekawych rad, jak sprawić, aby nasz kod był czytelny i przejrzysty. Został on stworzony jeszcze w 2001 roku i z pewnymi zmianami jest obowiązujący do dziś. Co warto zauważyć, dokument został bardzo dobrze przyjęty przez środowisko ludzi pracujących z Pythonem, do tego stopnie, że wiele podstawowych zasad tego PEP’a jest z automatu zawartych w wielu IDE. Na przykład PyCharm, podkreśla nam wiele niezgodnych z dokumentem zapisów, między innymi:

• zbyt długie linie,
• niepoprawna liczba pustych linii pomiędzy funkcjami lub klasami,
• brak spacji wokół znaków przypisania,
• brak spacji po znaku komentarza.

Polecam zapoznanie się z dokumentem: PEP8

PEP 20 – The ZEN of Python

Ciekawy dokument, opublikowany w 2004 roku, który hasłowo opisuje najważniejsze zasady podczas przygotowywania, projektowania czy już samego kodowania. Pierwsza z zasad mogłoby się wydawać, że jest trywialna: Piękne jest lepsze niż brzydkie, jednak czytając czasem różny kod, myślę, że nie jest to takie oczywiste. Jak wiemy, są tego różne powody, jak na przykład napięty grafik, szybko wykonywane zmiany, czy inne zewnętrzne czynniki, jednak musimy mieć na uwadze, że takie podejście prędzej czy później się na nas zemści, a re-factoring takiego kodu stanie się konieczny, a będzie trudny… oj będzie ;). Dodatkowo dokument traktuje o przestrzeniach nazw, złożoności kodu, jego przejrzystości i wiele innych. Zawiera on raptem 19 sentencji. Polecam jako miłą lekturę do poduszki 🙂

PEP 257 – Docstring Conventions

W tym dokumencie są zawarte konwencja zapisu docstringów, a także definicja czym są docstringi. Warto przeczytać chociaż raz, a z pewnością się przyda w przyszłości. Dokument ten szczególnie polecałbym testerom piszącym test frameworki lub biblioteki, gdyż tam wykorzystanie docstringów jest niemalże niezbędne. Oczywiście zrezygnowanie z korzystania z docstringów nie spowoduje, że skrypty czy programy się nie uruchomią lub będą niepoprawnie działać, lecz z pewnością będą trudne w użyciu.

PEP 287 – reStructuredText Docstring Format

Jeśli dla kogoś konwencja docstringów z PEP257 to za mało, można zapoznać się z tym dokumentem. Proponuje on używanie znaczników reStructuredText, dzięki którym opis funkcji czy klas zdaje się dużo bardziej czytelny. Dzięki standaryzacji możliwe jest także automatyczne tworzenie dokumentacji oraz automatyczne odczytywanie konkretnych wartości z opisów. Część osób jednak nie jest przekonana do tej konwencji zapisu. Ciekawi mnie co Wy o tym sądzicie?

PEP 405 – Python Virtual Environments

Szczegółowy opis założeń oraz użytkowania wirtualnych środowisk wbudowanych w Pythona. Dokument pochodzi z 2011 roku z późniejszymi zmianami. Jest on niejako odpowiedzią na powstające zewnętrzne narzędzia do tworzenia wirtualnych środowisk. O tym, jak ważne i przydatne jest to narzędzie, możecie przeczytać w jednym z poprzednich artykułów:

PEP 435 – Adding an Enum type to the Python standard library

Jeśli przystępujemy do stworzenia testowego frameworku, prędzej czy później spotkamy się z tzw. enumami, czyli typami wyliczeniowymi. Obecnie są one częścią biblioteki standardowej Pythona, dlatego nie wymagają żadnej dodatkowej instalacji. Upraszczając, Enum jest klasą bazową, po której dziedziczy, uzyskując tym samym specjalny interfejs dla naszego typu.

W kolejnych artykułach postaram się przyblizyć wybrane dokumenty Python Enhancement Proposal.