No właśnie, ja zazwyczaj piszę po prostu:
# -*- coding: utf-8 -*-
#!/usr/bin/env python
print('Hello world!')
# czyli wszystko od razu w skrypcie, jak leci
ale spotkałem się z takimi konstrukcjami dosyć często:
# -*- coding: utf-8 -*-
#!/usr/bin/env python
def main() :
print('Hello world!')
if __name__ == "__main__":
main()
Na logikę b.eleganckie jest to drugie ... Czy mam rację? Czy to pierwsze też jest akceptowalne?
nie widzę powodu, dla którego pierwsze miałoby być "nieakceptowalne".
co do drugiego: http://pl.wikibooks.org/wiki/Zanurkuj_w_Pythonie/Testowanie_modu%C5%82%C3%B3w
W skrócie: kiedy interpreter czyta źródło wykonuje cały kod jaki w nim znalazł. przed wykonaniem kodu definiowane są specjalne zmienne, np. jeśli python uruchamia ten moduł jako program główny, ustawia specjalną zmienną _name_ by miała wartość "main". jeśli plik jest importowany z innego modułu _name_ będzie miała inną wartość.
Może to moje zboczenie z Rubiego, ale osobiście preferuję podzielenie programu na osobne części z czego tylko 1 jest wykonywalna, a wszystkie biblioteki/klasy są wydzielone do osobnych plików.
Pierwsze i drugie rozwiązania są rożne.
Porównaj efekt poleceń (dla obu wersji):
python
import nazwa_skryptu
code>oraz
python nazwa_skryptu.py
Pierwsze rozwiązanie jest dobre do 5-linijkowców.
Drugie jest dobre, jeśli pracujesz z czymś dłuższym (w sensie linijek i czasu życia oprogramowania).
Why?
Drugie rozwiązanie skłania do dzielenia programu na kawałki, jest lepiej zarządzalne.
Wstawkę:
if __name__ == "__main__":
stosuje się żeby móc moduł wciągnąć jako część większego programu i móc korzystać z jego publicznych funkcji (a nie od razu uruchamiać).
Ja często stosuje fragment
if __name__=="__main__":
#kod testujący (ilustrujący wykorzystanie)
w plikach zawierających definicje funkcji (klas) uniwersalnych. Jeżeli zaimportuje moduł. to kod testujący się nie wykona, ale zdefiniowane w module funkcje(klasy) będą dostępne.