2009-07-29 11 views
0

Ici, au bureau, nous avons une bibliothèque portant le nom de l'entreprise et des sous-bibliothèques, par projet plus ou moins, et dans chaque sous-bibliothèque il peut y avoir plus de modules ou de bibliothèques. nous utilisons Django, ce qui rend notre hiérarchie quelques étapes plus profondes ...Importer des modules avec des sous-modules depuis une bibliothèque

Je suis un peu perplexe sur les différences entre les instructions d'importation suivantes:

1:

 
import company.productline.specific.models, company.productline.base.models 
specific, base = company.productline.specific, company.productline.base 
2:

 
import company.productline.specific.models, company.productline.base.models 
from company.productline import specific, base 

3:

 
from company.productline import specific, base 
import company.productline.specific.models, company.productline.base.models 

les premières importations de style que le models? Quels sont alors les noms specific et base disponibles dans l'espace de noms actuel?

que se passe-t-il dans l'initialisation des modules si l'on importe les premiers sous-modules et seulement après les bibliothèques contenant?

peut-être le style le plus net est le dernier, où il est clair (au moins pour moi) que j'importer les deux modules et mettre leurs noms directement dans l'espace de noms actuel et que la seconde importation ajoute le sous-module model modules juste importés.

d'autre part, (1) me permet de seulement importer les modules internes et de se référer à eux dans un boîtier compact mais de façon claire (specific.models et base.models)

pas sûr que ce soit la question, mais je suis curieux de lire les commentaires.

Répondre

0

donc j'ai regardé dans un peu plus profond, en utilisant ce nouveau paquet inutile:

A:(__init__.py: print 'importing A', 
    B:(__init__.py: print 'importing B', 
     C1:(__init__.py: print 'importing C1', 
      D:(__init__.py: print 'importing D')) 
     C2:(__init__.py: print 'importing C2', 
      D:(__init__.py: print 'importing D')))) 

avis que C1 et C2 contiennent deux modules différents, tous deux nommés D dans leurs espaces de noms différents. J'aurai besoin d'eux tous les deux, je ne veux pas utiliser tout le chemin ABC1.D et ABC2.D parce que ça semble trop maladroit et je ne peux pas les mettre tous les deux dans l'espace de noms actuel parce que l'un écraserait l'autre et - Non, je n'aime pas l'idée de changer leurs noms. ce que je veux est d'avoir C1 et C2 dans l'espace de nom actuel et de charger les deux modules D inclus.

oh, oui: et je veux que le code soit lisible.

J'ai essayé les deux formes

from A.B import C1 

et le plus laid un bien

import A.B.C1 
C1 = A.B.C1 

et je conclus qu'ils sont équivalentes:


Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 
>>> from A.B import C1 
importing A 
importing B 
importing C1 
>>> C1 
<module 'A.B.C1' from 'A/B/C1/__init__.pyc'> 
>>> 

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 
>>> import A.B.C1 
importing A 
importing B 
importing C1 
>>> C1=A.B.C1 
>>> C1 
<module 'A.B.C1' from 'A/B/C1/__init__.pyc'> 
>>> 

L'importation de package C1 ou C2 n'importera pas les modules inclus simplement parce qu'ils sont présents. et tant pis que la forme from A.B import C1.D n'est pas syntaxiquement acceptée: ce serait une belle chose compacte à avoir. Par contre, on me donne la possibilité de le faire au A.B.C1.__init__.py si je le souhaite. donc si j'ajoutez la ligne import D au __init__.py dans A.B.C1, voici ce qui se passe:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 
>>> from A.B import C1 
importing A 
importing B 
importing C1 
importing D 
>>> 

importation de modules inclus est probablement mieux fait à la fin de l'initialisation du package.


compte tenu de tout cela et donné un comportement django spécifique (qui rend difficile/impossible de automatiquement import models lors de l'importation du paquet), je crois que je préfère le style 3.

0

Les trois exemples ci-dessus sont tous équivalents en pratique. Tous sont étranges, cependant. Il n'y a aucune raison de le faire

from company.productline import specific 

et

import company.productline.specific.models 

Vous pouvez (la plupart du temps) seulement les modèles d'accès par specific.models après la première importation.

Il semble raisonnable dans ce cas ne

from company.productline import base 
from company.productline import specific 

Et puis comme accéder à ces base.models, specific.whatever, etc. Si « spécifique » est un, vous devez également faire une import model en __init__.py pour être en mesure d'accéder specific.module.

+0

J'ai eu un coup d'œil à la norme paquet de courrier électronique, qui contient plusieurs modules plus profonds et ne définit pas de '__all__' (utile seulement pour' 'from import import ''), plutôt qu'il fait des choses fantaisie avec l'importation paresseuse ... assez intéressant. essayé un '__init __. py' contenant un' import models', mais ce que fait django dans les coulisses quand python importe des modèles le rend impossible (django scanne 'INSTALLED_APPS' et suppose qu'ils sont déjà là, alors que python l'importe toujours – mariotomo

+0

A, droit __all__ est seulement pour *, à droite. Pour corriger le "module vide", vous importez le sous-module dans __init__. Je m'en suis souvenu à l'envers. :) –

Questions connexes