Comment organiser un projet Python?
Je suis nouveau à Python et je démarre un mini projet, mais j'ai des doutes sur la façon d'organiser les dossiers dans le "Python Way".
J'utilise PyDev dans mon environnement de développement, et lorsque je crée un nouveau projet, un dossier est créé appelé src
+ src
Maintenant, dans le PyDev, je peux créer Pydev Module et PyDev Package
J'ai besoin d'organiser mon projet de la manière suivante:
+ Indicators
- Moving_averages.py
- Stochastics.py
+ Strategies
- Moving_averages_cross.py
- example.py
Comment puis-je organiser cela en termes de modules et de packages? Quelle est la signification des modules et des packages?
Meilleures salutations,
Un package est essentiellement un dossier avec __init__.py fichier en dessous et généralement certains modules, où Module est un *.py fichier. Cela concerne principalement import. Si vous ajoutez __init__.py aux indicateurs que vous pouvez utiliser:
from Indicators.Stochastics import *
ou
from Indicators import Stochastics
Soit dit en passant, je recommanderais de garder les noms de module/package en minuscules. Cela n'affecte pas la fonctionnalité mais c'est plus "Pythonic".
Du point de vue du système de fichiers, un module est un fichier se terminant par .py et un package est un dossier contenant modules et (imbriqué) packages à nouveau. Python reconnaît un dossier comme package s'il contient un __init__.py fichier.
Une structure de fichiers comme ça
some/
__init__.py
foofoo.py
thing/
__init__.py
barbar.py
définit le packagesome, qui a un modulefoofoo et un paquet imbriqué thing, qui a encore un module barbar. Cependant, lorsque vous utilisez des packages et des modules, vous ne distinguez pas vraiment ces deux types:
import some
some.dothis() # dothis is defined in 'some/__init__.py'
import some.foofoo # <- module
import some.thing # <- package
Veuillez suivre PEP8 lors de la sélection du nom de vos packages/modules (c'est-à-dire utiliser des noms en minuscules).
Structure du répertoire
.
|-- bin
| `-- my_program
|-- docs
| `-- doc.txt
|-- my_program
| |-- data
| | `-- some_data.html
| |-- __init__.py
| |-- submodule
| | `-- __init__.py
| |-- helpers.py
|-- tests
| |-- __init__.py
| |-- test_helpers.py
|-- Makefile
|-- CHANGES.txt
|-- LICENSE.txt
|-- README.md
|-- requirements-dev.txt
|-- requirements.txt
`-- setup.py
chat Makefile
PYTHON=`which python`
NAME=`python setup.py --name`
all: check test source deb
init:
pip install -r requirements.txt --use-mirrors
dist: source deb
source:
$(PYTHON) setup.py sdist
deb:
$(PYTHON) setup.py --command-packages=stdeb.command bdist_deb
rpm:
$(PYTHON) setup.py bdist_rpm --post-install=rpm/postinstall --pre-uninstall=rpm/preuninstall
test:
unit2 discover -s tests -t .
python -mpytest weasyprint
check:
find . -name \*.py | grep -v "^test_" | xargs pylint --errors-only --reports=n
# pep8
# pyntch
# pyflakes
# pychecker
# pymetrics
clean:
$(PYTHON) setup.py clean
rm -rf build/ MANIFEST dist build my_program.Egg-info deb_dist
find . -name '*.pyc' -delete
Vous voudrez peut-être consulter la bibliothèque de modèles de packages modernes. Il fournit un moyen de configurer une mise en page de base vraiment agréable pour un projet qui vous guide à travers quelques questions et essaie de vous aider à obtenir quelque chose qui peut être distribué assez facilement.
Avant de décider d'une structure de projet, il est bon de vous demander quel sera le but du projet. Est-ce que ce sera une analyse ponctuelle? Un concept de jouet que vous souhaitez étudier? Un projet à part entière que vous comptez distribuer? La quantité d'efforts que vous souhaitez mettre dans la structuration de votre projet sera différente.
- Si c'est une analyse ponctuelle, j'aime utiliser cahiers ipython . Le bloc-notes capturera le flux de vos pensées et vous pourrez ajouter des notes de balisage à votre code pour référence ultérieure.
- Si c'est un concept de jouet que vous souhaitez étudier, je trouve une approche simple et rapide pour mieux fonctionner. Vous voulez être en mesure de mettre en œuvre rapidement votre concept pour découvrir s'il est même réalisable et qu'il vaut donc la peine d'y consacrer plus de temps. Une partie de la philosophie de Python est "N'essayez pas de perfection parce que" assez bon "est souvent juste cela. Vous pouvez toujours revenir plus tard et structurer votre projet d'une manière qui respecte les meilleures pratiques d'ingénierie logicielle.
Si vous souhaitez structurer votre projet afin de pouvoir le distribuer plus tard, et pour qu'il évolue vers de nombreux modules, je recommande la structure suivante:
projectname ├── MANIFEST.in ├── setup.py ├── README ├── .gitignore ├── .git ├── projectname_env └── projectname ├── __init__.py ├── subpackageone │ ├── __init__.py │ ├── second_module.py │ ├── tests │ │ └── test_second_module.py │ └── models │ └── model1 ├── first_module.py └── tests └── test_second_module.py
Les raisons détaillées pour lesquelles j'aime cette structure sont dans mon article de blog , mais l'essentiel est que le répertoire projectname de niveau hiérarchiquement inférieur contient votre projet réel. A côté, il y a tous les outils qui aident à le gérer (git) et à l'empaqueter (setup.py, MANIFEST.in).
Un package est un répertoire avec un __init__.py dedans. La différence avec un répertoire est que vous pouvez l'importer.
Il n'y a pas de "méthode Python" en soi, mais vous constaterez que c'est une bonne idée de mettre tous vos modules dans un seul paquet avec un nom lié au projet.
De plus, pour suivre le Python, PEP8, les noms de package et de module doivent être en minuscules. Donc, si nous supposons que le projet est appelé "Statistiques Botond", votre structure ressemblerait à ceci: :
botondstats/
indicators/
moving_averages.py
stochastics.py
strategies/
moving_averages_cross.py
example.py
Vous trouveriez alors la classe Stochastique en faisant
from botondstats.indicators.stochastics.Stochastics
(Il existe différentes façons de conserver la structure mais de raccourcir les importations, mais c'est une autre question).
Vous pouvez mettre cette structure sous src/ si vous voulez, mais ce n'est pas nécessaire. Je ne fais jamais. Au lieu de cela, j'ai un répertoire principal:
BotondStatistics/
docs/
botonstats/ # the above structure
setup.py # Distutils/distribute configuration for packaging.
Dans ce répertoire, j'ai généralement un virtualenv, donc j'ai également bin/lib/et al. Le développement se fait généralement en exécutant
./bin/python setup.py tests
Comme j'utilise le lanceur de test Distrubute pour exécuter les tests.
Voilà comment je le fais. :-)
Essayez python_boilerplate_template:
Le projet cookiecutter de audreyr comprend plusieurs modèles de projet Python:
Le package utilise un seul ~/.cookiecutterrc fichier pour créer des modèles de projet personnalisés en Python, Java, JS et d'autres langages.
Par exemple, un modèle Python compatible avec PyPI:
