2011-04-27 5 views
2

Mon module est dans un gros fichier qui devient difficile à maintenir. Quelle est la manière standard de casser les choses?Le module Python devient trop gros

J'ai un module dans un fichier my_module.py, que j'importer comme ceci:

import my_module 

« mon_module » sera bientôt mille lignes, ce qui repousse les limites de ma capacité à garder tout droit. Je pensais à l'ajout de fichiers my_module_base.py, my_module_blah.py, etc. Et puis, en remplacement my_module.py avec

from my_module_base import * 
from my_module_blah import * 
# etc. 

Ensuite, le code utilisateur n'a pas besoin de changer:

import my_module # still works... 

Est-ce le modèle standard?

Répondre

4

Cela dépend de ce que fait réellement votre module. Habituellement, c'est toujours une bonne idée de faire de votre module un répertoire contenant un fichier '__init__.py''. Donc, vous devez d'abord transformer votre your_module.py en quelque chose comme your_module/__init__.py.

Ensuite, vous continuez selon votre logique métier. Voici quelques exemples:

  • avez-vous des fonctions utilitaires qui ne sont pas directement utilisés par les modules API les mettre dans un fichier appelé utils.py

  • avez-vous des cours traitant de la base de données ou représentant votre base de données modèles les mettre en models.py

  • avez-vous une configuration interne, il peut être judicieux de le mettre dans un certain fichier supplémentaire appelé settings.py ou config.py

Ce ne sont que des exemples (un peu volé dans l'approche Django des applications réutilisables ^^). Comme dit, cela dépend beaucoup de ce que fait votre module. Si elle est encore trop grande après, il est également logique de créer des sous-modules (en tant que sous-répertoires avec leurs propres __init__.py).

+0

Quand quelqu'un importe mon module, que se passe-t-il en dehors du '__init __. Py'? Si rien, je mettrais des instructions comme 'from blah import *' dans mon '__init __. Py'? –

+0

Vous pouvez le faire, MAIS comme indiqué ici déjà ce n'est pas une bonne pratique. Voir la réponse de Senthil Kumaran ci-dessous sur ce qu'il vaudrait mieux faire. Importez juste ce que votre module devrait offrir à l'extérieur en faisant 'import my_module'. Tout le reste devrait être "caché" dans la logique des modules. –

2

Je suis sûr qu'il y a beaucoup d'opinions à ce sujet, mais je dirais que vous le divisez en unités fonctionnelles (modules) plus bien définies, contenues dans un paquet. Ensuite, vous utilisez:

from mypackage import modulex 

Ensuite, utilisez le nom du package pour faire référence à l'objet:

modulex.MyClass() 

etc.

Vous devriez (presque) jamais utiliser

from mypackage import * 

Depuis peut introduire des bogues (les noms en double provenant de différents modules finiront par en taper un).

+0

Merci pour votre réponse. Je n'étais pas sûr que ma question était bien formulée. S'il vous plaît voir mes modifications récentes. –

+0

Ok, bien sûr. Mais l'utilisateur a-t-il besoin de tout? Parfois, pour la transition, vous pouvez fournir un module supplémentaire de compatibilité ascendante qui récupère tout. C'est l'exception "presque". ;-) – Keith

+0

Bien que cela ne soit pas toujours approprié, vous pouvez également utiliser le formulaire 'depuis mypackage import modulex as mx' ou un autre nom plus court. – Wilduck

1

Non, ce n'est pas le modèle standard. from something import * n'est généralement pas une bonne pratique car elle importera beaucoup de choses que vous n'aviez pas l'intention de faire. Au lieu de suivre la même approche que vous avez fait, mais incluez les modules spécifiquement de l'un à l'autre, par exemple.

En base.py si vous avez def myfunc alors en main.py, utilisez 'from base import myfunc So that for your users, main.myfunc` fonctionnerait aussi. Bien sûr, vous devez veiller à ne pas effectuer d'importation circulaire.

De même, si vous voyez que from something import * est requis, contrôlez les valeurs d'importation à l'aide de la construction __all__.