Comment dois-je organiser le code source Python? [fermé]

99

Je commence avec Python (il est grand temps que je tente), et je recherche quelques bonnes pratiques.

Mon premier projet est une file d'attente qui exécute des expériences de ligne de commande dans plusieurs threads. Je commence à avoir un très long main.pydossier et j'aimerais le diviser. En général, je recherche: Comment les programmeurs python organisent-ils plusieurs fichiers source? Y a-t-il une structure particulière qui fonctionne pour vous?

Mes questions spécifiques incluent:

  1. Chaque classe devrait-elle être dans un fichier séparé?
  2. Comment organiser les tests unitaires par rapport au code source?
  3. Où dois-je mettre les commentaires doc, en particulier ceux pour le fonctionnement en ligne de commande?
  4. Si j'utilise plusieurs répertoires, comment importer des classes entre eux?

Je peux probablement tirer certaines de mes propres conclusions ici par essais et erreurs, mais je préfère partir de quelque chose de bien .

python unit-testing code-organization Andres Jaan Tack
la source
4
Cela vous expliquera quelques choses sur l'organisation de votre code docs.python.org/tutorial/modules.html
Nikola Smiljanić
2
Voici quelques informations plus utiles tirées de la documentation python. <br> docs.python.org/3/tutorial/modules.html#packages
rda3mon
11
Cette question est à la recherche d'une convention largement acceptée spécifiquement dans la communauté Python. La réponse n'est pas une question d'opinion, même si, comme la plupart des réponses, elle pourrait changer avec le temps. Je suggère que cela soit rouvert ou à tout le moins la réponse originale non supprimée.
Andres Jaan Tack

Réponses:

32

L' article auquel Eric a fait référence est génial car il couvre les détails de l'organisation de grandes bases de code Python.

Si vous avez atterri ici de Google et que vous essayez de savoir comment diviser un gros fichier source en plusieurs fichiers plus faciles à gérer, je résumerai brièvement le processus.

Supposons que vous avez actuellement tout dans un fichier appelé main.py:

  • Créez un autre fichier source dans le même dossier (appelons le nôtre utils.pypour cet exemple)
  • Déplacer les classes, quelle que soit les fonctions, déclarations, etc vous avez besoin de main.pyenutils.py
  • En main.pyrajoutez une seule ligne en haut:import utils

Conceptuellement, cela crée un nouveau module appelé utilsdans un autre fichier source. Vous pouvez ensuite l'importer partout où vous en avez besoin.

Drew Noakes
la source
Vous souvenez-vous de l'article auquel Eric a fait référence? Je n'arrive pas à trouver un Eric sur cette question / réponse
Daniel Rucci
7
@DanR, oui, c'est l'article . Pour une raison quelconque, un modérateur a supprimé sa réponse, malgré 56 votes positifs.
Drew Noakes
1
@DrewNoakes: Je pense qu'il a été supprimé pour être une réponse de lien seulement; si seulement il avait résumé les principaux points de l'article.
smci
1
Malheureusement, l'article est un lien mort maintenant :-(. La dernière version archivée est ici: web.archive.org/web/20190714164001/http
//...
7

La façon dont vous devez organiser votre code et vos tests est exactement la même que vous le feriez pour n'importe quel langage OO.

Réponses de la façon dont je le fais. Ce n'est peut-être pas juste mais ça marche pour moi

  1. Cela dépend de la répartition de vos fonctionnalités. Pour mon application python principale, j'ai 1 fichier avec des classes pour les points d'entrée, puis des packages de différents bits de fonctionnalités
  2. J'utilise PyDev pour eclipse et je l'organise comme je le ferais pour Java. 
>  Workspace
>     |
>     |-Src
>     |   |-Package1
>     |   |-Package2
>     |   |-main.py
>     |-Test
>         |-TestPackage1
>         |-TestPackage2
  1. Utilisez DocString partout pour garder une trace de tout
  2. Après vous être assuré que les __init__.pyfichiers concernés se trouvent dans les dossiers. c'est juste un simple cas defrom module import class
AutomatedTester
la source
5
Une mise en garde, cependant: java prend une sorte de relation dictatoriale avec les packages, les fichiers et les classes. Parfois, je me retrouve avec beaucoup plus de fichiers sources que je ne le souhaiterais vraiment. Les conventions de certaines organisations - par exemple - éviter les classes internes (imbriquées) ou les classes "auxiliaires" plus bas dans le fichier - aggravent la situation, au-delà des exigences du compilateur. Gardez-le en ordre, et une hiérarchie est utile, mais essayez d'éviter le make-work.
Roboprog