Plusy:
Po pierwsze: łagodne, możliwe do pokonania zaciemnienie.
Po drugie: jeśli kompilacja spowoduje znacznie mniejszy plik, otrzymasz krótszy czas ładowania. Ładne dla sieci.
Po trzecie: Python może pominąć krok kompilacji. Szybszy przy początkowym obciążeniu. Ładne dla procesora i sieci.
Po czwarte: im więcej komentujesz, tym mniejszy jest plik .pyc
lub .pyo
w porównaniu do źródła.py
pliku .
Po piąte: użytkownik końcowy posiadający tylko a .pyc
lub.pyo
plik w ręku, znacznie rzadziej przedstawia ci błąd, który spowodował przez nieodwróconą zmianę, o której zapomniał ci powiedzieć.
Po szóste: jeśli dążysz do systemu osadzonego, uzyskanie mniejszego rozmiaru pliku do osadzenia może stanowić znaczący plus, a architektura jest stabilna, więc wada, opisana poniżej, nie wchodzi w grę.
Kompilacja na najwyższym poziomie
Warto wiedzieć, że można skompilować plik źródłowy Pythona najwyższego poziomu do .pyc
pliku w ten sposób:
python -m py_compile myscript.py
To usuwa komentarze. Pozostawia docstrings
nietknięty. Jeśli chcesz się tego pozbyć docstrings
(możesz poważnie zastanowić się, dlaczego to robisz), a następnie skompiluj w ten sposób ...
python -OO -m py_compile myscript.py
... a otrzymasz .pyo
plik zamiast .pyc
pliku; równomiernie dystrybuowany pod względem podstawowej funkcjonalności kodu, ale mniejszy ze względu na rozmiar okrojony docstrings
(i mniej zrozumiały dla późniejszego zatrudnienia, gdyby był przyzwoitydocstrings
). Ale patrz wada trzecia poniżej.
Zauważ, że Python używa daty .py
pliku, jeśli jest obecny, aby zdecydować, czy powinien on wykonać .py
plik, a nie plik .pyc
lub .pyo
--- - więc edytuj plik .py, a .pyc
lub .pyo
jest przestarzały, a wszelkie korzyści, które uzyskałeś, zostaną utracone. Musisz go ponownie skompilować, aby ponownie odzyskać korzyści .pyc
lub .pyo
korzyści, takie jak mogą być.
Wady:
Po pierwsze: istnieje „magiczne ciasteczko” .pyc
i .pyo
pliki, które wskazują architekturę systemu, w której skompilowano plik python. Jeśli rozpowszechnisz jeden z tych plików w środowisku innego typu, ulegnie on awarii. Jeśli dystrybuujesz plik skojarzony .pyc
lub .pyo
bez niego w .py
celu ponownej kompilacji touch
, zastępuje on .pyc
lub .pyo
, użytkownik końcowy również nie może go naprawić.
Po drugie: jeśli docstrings
zostaną pominięte przy użyciu -OO
opcji wiersza polecenia, jak opisano powyżej, nikt nie będzie w stanie uzyskać tych informacji, co może utrudnić (lub uniemożliwić) użycie kodu.
Po trzecie: -OO
opcja Pythona implementuje również pewne optymalizacje zgodnie z -O
opcją wiersza poleceń; może to spowodować zmiany w działaniu. Znane optymalizacje to:
sys.flags.optimize
= 1
assert
instrukcje są pomijane
__debug__
= Fałsz
Po czwarte: jeśli celowo sprawiłeś, że twój skrypt Pythona jest wykonywalny z czymś w kolejności #!/usr/bin/python
w pierwszym wierszu, zostanie on rozebrany .pyc
i .pyo
pliki, a funkcjonalność zostanie utracona.
Po piąte: nieco oczywiste, ale jeśli skompilujesz swój kod, nie tylko wpłynie to na jego użycie, ale również zmniejszy, często poważnie, możliwość uczenia się z pracy przez innych.