Jak powinienem zorganizować kod źródłowy Pythona? [Zamknięte]

Rozpoczynam pracę z Pythonem (najwyższy czas, aby spróbować) i szukam dobrych praktyk.

Mój pierwszy projekt to kolejka, która uruchamia eksperymenty wiersza poleceń w wielu wątkach. Zaczynam otrzymywać bardzo długi main.pyplik i chciałbym go przerwać. Ogólnie szukam: Jak programiści Pythona organizują wiele plików źródłowych?Czy jest jakaś konkretna struktura, która Ci odpowiada?

Moje szczegółowe pytania obejmują:

Czy każda klasa powinna znajdować się w osobnym pliku?
Jak należy zorganizować testy jednostkowe względem kodu źródłowego?
Gdzie powinienem umieścić komentarze do dokumentów, szczególnie te dotyczące operacji z wiersza poleceń?
Jeśli używam wielu katalogów, jak zaimportować między nimi klasy?

Prawdopodobnie mogę tutaj wyciągnąć własne wnioski metodą prób i błędów, ale wolałbym zacząć od czegoś dobrego .

python unit-testing code-organization

— Andres Jaan Tack
źródło

To wyjaśni kilka rzeczy związanych z organizowaniem kodu docs.python.org/tutorial/modules.html

— Nikola Smiljanić

Oto kilka przydatnych informacji z dokumentacji Pythona. <br> docs.python.org/3/tutorial/modules.html#packages

— rda3mon

To pytanie jest poszukiwaniem ogólnie przyjętej konwencji, szczególnie w społeczności Pythona. Odpowiedź nie jest kwestią opinii, chociaż podobnie jak większość odpowiedzi może się zmieniać z czasem. Proponuję to ponownie otworzyć lub przynajmniej cofnąć usunięcie oryginalnej odpowiedzi.

— Andres Jaan Tack

Odpowiedzi:

Artykuł Eric wskazał na to niesamowite, ponieważ obejmuje dane organizowania dużych baz kodu Pythona.

Jeśli wylądowałeś tutaj z Google i próbujesz dowiedzieć się, jak podzielić jeden duży plik źródłowy na wiele plików, które są łatwiejsze w zarządzaniu, krótko podsumuję ten proces.

Załóżmy, że obecnie masz wszystko w pliku o nazwie main.py:

Utwórz inny plik źródłowy w tym samym folderze (nazwijmy nasz utils.pyw tym przykładzie)
Przenieś dowolne klasy, funkcje, instrukcje itp. Z main.pydoutils.py
W main.pydodać pojedynczą linię u góry:import utils

Koncepcyjnie to, co robi, to utworzenie nowego modułu o nazwie utilsw innym pliku źródłowym. Następnie możesz go zaimportować w dowolnym miejscu.

— Drew Noakes
źródło

Czy pamiętasz artykuł, na który wskazał Eric? Nie mogę znaleźć Erica na to pytanie / odpowiedź

— Daniel Rucci

@DanR, tak, to jest artykuł . Z jakiegoś powodu moderator usunął swoją odpowiedź, mimo że otrzymała 56 głosów za.

— Drew Noakes

@DrewNoakes: Myślę, że został usunięty, ponieważ jest odpowiedzią zawierającą tylko łącze; gdyby tylko podsumował główne punkty artykułu.

— smci

Niestety artykuł jest teraz martwym linkiem :-(. Najnowsza zarchiwizowana wersja jest tutaj: web.archive.org/web/20190714164001/http://…

— Igor Brejc

Sposób organizacji kodu i testów jest dokładnie taki sam, jak w przypadku dowolnego języka obiektowego.

Odpowiedzi ze sposobu, w jaki to robię. Może to nie jest w porządku, ale dla mnie działa

Zależy od tego, jak podzielona jest Twoja funkcjonalność. Dla mojej głównej aplikacji Pythona mam 1 plik z klasami dla punktów wejścia, a następnie pakiety różnych bitów funkcjonalności
Używam PyDev do zaćmienia i organizuję to tak, jak w Javie.

>  Workspace
>     |
>     |-Src
>     |   |-Package1
>     |   |-Package2
>     |   |-main.py
>     |-Test
>         |-TestPackage1
>         |-TestPackage2

Używaj DocString wszędzie, aby śledzić wszystko
Po upewnieniu się, że odpowiednie __init__.pypliki znajdują się w folderach. to tylko prosty przypadekfrom module import class

— AutomatedTester
źródło

Jedno zastrzeżenie: java przyjmuje rodzaj dyktatorskiej relacji z pakietami, plikami i klasami. Czasami mam o wiele więcej plików źródłowych, niż bym chciał. Konwencje niektórych organizacji - np. - unikanie (zagnieżdżonych) klas wewnętrznych lub klas „pomocniczych” niższych w pliku - pogarszają to, wykraczając poza wymagania kompilatora. Utrzymuj porządek, a hierarchia jest przydatna, ale staraj się unikać marnotrawstwa.

— Roboprog