34 votes

Meilleure pratique pour réutiliser du code python

Je dois écrire une bibliothèque python app(qui contient plusieurs *.py fichiers). Et plusieurs de mes python projets doivent réutiliser le code dans la bibliothèque de l'application. Quelle est la meilleure pratique recommandée pour la réutilisation de code python? Actuellement, j'ai pensé à trois options:

  1. Copier et coller. C'est loin d'être la meilleure pratique. Elle viole le Principe DRY.(Ne pas se répéter.)
  2. Ajouter le dossier de la bibliothèque de l'application de la variable d'environnement PYTHONPATH: export PYTHONPATH=/path/to/library/app. Ensuite, tous les projets sur le même ordinateur peut faire référence le code dans la bibliothèque de l'application.
  3. Et le dossier de la bibliothèque de l'application de sys.chemin d'accès dans le code python: sys.path.append('/path/to/library/app')

Parmi les trois options ci-dessus lequel préférez-vous? Quel avantage a-t-elle par rapport aux deux autres options? Avez-vous d'autres de meilleures options? Il est très apprécié que si quelqu'un avec des années de python expériences de développement qui pourrait répondre à cette question.

43voto

Nicola Musatti Points 10070

Permettez-moi de proposer une quatrième alternative: prenez le temps d'apprendre à empaqueter votre bibliothèque et à l'installer dans vos sites-packages; c'est plus facile qu'on ne le pense et je suis convaincu que le temps est bien dépensé. Ceci est un très bon point de départ: http://guide.python-distribute.org/

5voto

Ned Batchelder Points 128913

De vos trois options, PYTHONPATH est la voie à suivre. Le copier-coller est clairement sorti, et ajouter du code à vos autres projets pour modifier sys.path pollue simplement ces fichiers avec des connaissances sur leur environnement.

Une quatrième option consiste à créer un véritable package installable à partir de votre code commun et à l'installer dans votre installation Python. Ensuite, vous pouvez simplement importer ces modules comme tout autre code d'installation tiers.

3voto

Nix Points 22944

Si ses une bibliothèque partagée, vous devez emballer et ajoutez-le à site-packages et alors vous n'aurez pas à vous inquiéter de régler quoi que ce soit. C'est la meilleure option.


Si vous ne voulez pas l'utiliser site-packages, puis utilisez PYTHONPATH. Sa raison d'être, et c'est la façon de faire ce que vous voulez.


Vous voudrez peut-être regarder dans l'aide du site.addsitedir, chemin d'accès.append ne pas éviter les doublons. Il vous permettra également de l'effet de levier .la pth fichiers.

La définition dynamique/ajouter des choses à PYTHONPATH via sys.path permet d'obtenir le même résultat, mais cela peut compliquer les choses si vous choisissez de réutiliser votre nouvelle bibliothèque. Il provoque aussi des problèmes si vos chemins d'accès, vous devez changer le code par rapport à une variable d'environnement. À moins qu'il est tout à fait nécessaire, vous ne devriez pas dynamiquement la configuration de votre python path.


Le copier-Coller n'est pas une ré-utilisation du motif. Vous n'êtes pas réutiliser tout ce que vous sont duplication et l'augmentation de la maintenance.

2voto

delnan Points 52260

La première est, comme vous l'avez souligné vous-même, à peine acceptable, car elle a d'innombrables problèmes bien connus.

Les deux autres ont leurs propres problèmes. Pour commencer, ils nécessitent un travail manuel lorsque les fichiers à déplacer (notamment la mauvaise si vous le mélanger avec la logique d'application, c'est à dire mettre en *.py fichiers au lieu de les laisser dans l'ordinateur, il fonctionne sur) et nécessite soit fixe les emplacements d'installation (chemins absolus) ou au moins une certaine structure de répertoire (les chemins relatifs). À mon humble avis, ces moyens ne sont acceptables que si les applications ne sont pas toujours à se déplacer n'importe où d'autre. Dès que cela devient nécessaire, vous devez donner et l'utilisation de la solution existante comme une raison de ne pas l'utiliser, être exagéré pour les petites et les scripts locaux, ne s'applique pas ou plus du tout:

Faire des parties communes, qui apparemment vous avez déjà traiter comme un permanent de la bibliothèque (bon!), un véritable projet dans son propre droit, avec un setup.py qui permet de l'installer et de les ajouter à PYTHONPATH dans une croix-plate-forme avec une seule commande. Vous n'avez pas besoin de le publier sur PyPI, mais il fait faire tellement plus facile si vous devez changer votre esprit dans l'avenir. Devriez-vous le faire et aussi de publier certaines de vos projets sur PyPI, vous aussi faites de l'installation du projet en question et de ses dépendances plus facile pour chaque utilisateur potentiel.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X