Problèmes d'importation relatifs dans Python 3

Python importations drive me crazy (mon expérience avec python importations parfois ne correspond pas du tout à l'original 'Explicite est mieux qu'implicite 🙁 ):

[app]
    start.py
        from package1 import module1
    [package1]
        __init__.py
            print('Init package1')
        module1.py
            print('Init package1.module1')
            from . import module2
        module2.py
            print('Init package1.module2')
            import sys, pprint
            pprint.pprint(sys.modules)
            from . import module1

J'obtiens:

vic@ubuntu:~/Desktop/app2$ python3 start.py 
Init package1
Init package1.module1
Init package1.module2
{'__main__': <module '__main__' from 'start.py'>,
 ...
 'package1': <module 'package1' from '/home/vic/Desktop/app2/package1/__init__.py'>,
 'package1.module1': <module 'package1.module1' from '/home/vic/Desktop/app2/package1/module1.py'>,
 'package1.module2': <module 'package1.module2' from '/home/vic/Desktop/app2/package1/module2.py'>,
 ...
Traceback (most recent call last):
  File "start.py", line 3, in <module>
    from package1 import module1
  File "/home/vic/Desktop/app2/package1/module1.py", line 3, in <module>
    from . import module2
  File "/home/vic/Desktop/app2/package1/module2.py", line 5, in <module>
    from . import module1
ImportError: cannot import name module1
vic@ubuntu:~/Desktop/app2$

import package1.module1 fonctionne, mais je veux l'utiliser from . import module1 parce que je veux faire package1 portable pour mes autres applications, c'est pourquoi je veux utiliser des chemins relatifs.

Je suis à l'aide de python 3.

J'ai besoin circulaire importations. Une fonction dans module1 affirme que l'un de ses paramètre est instance d'une classe définie dans module2 et vice-versa.

En d'autres termes:

sys.modules contient 'package1.module1': <module 'package1.module1' from '/home/vic/Desktop/app2/package1/module1.py'>. Je veux obtenir une référence dans le formulaire de from . import module1mais il essaie d'obtenir un nom, pas un paquet comme dans le cas import package1.module1 (qui fonctionne correctement). J'ai essayé import .module1 as m1 - mais c'est une erreur de syntaxe.

Aussi, from . import module2 dans module1 fonctionne très bien, mais from . import module1 dans module2 ne fonctionne pas...

Mise à JOUR:

Ce hack fonctionne (mais je suis à la recherche de la "officielle"):

print('Init package1.module2')

import sys, pprint
pprint.pprint(sys.modules)

#from . import module1
parent_module_name = __name__.rpartition('.')[0]
module1 = sys.modules[parent_module_name + '.module1']

source d'informationauteur warvariuc

  1. 6

    Une meilleure solution pour votre problème est de mettre package1 dans son propre paquet. Bien sûr, alors il ne peut pas importer package2, mais encore une fois si elle est réutilisable, pourquoi le serait-il?

  2. 6

    Circulaire des importations doit généralement être évitée, voir aussi cette réponse à une question connexeou cet article sur effbot.org.

    Dans ce cas, le problème est que vous importez from . où . est le package courant. De sorte que tous vos from . import X importations de passer par le paquet __init__.py.

    Vous pouvez faire votre problème un peu plus visible, si vous avez explicitement importer vos modules dans le __init__.py et de leur donner un autre nom (et de régler les autres importations à utiliser ces noms de cours):

    print('Init package1')
from . import module1 as m1
from . import module2 as m2

    Maintenant, quand vous importez m1 dans start.pyle paquet initialise tout d'abord, m1 et en vient à la from . import m2 ligne. À ce stade, il n'y a pas de m2 connu dans __init__.py si vous obtenez un message d'erreur d'importation. Si vous passez les déclarations d'importation en __init__.py autour (si vous chargez m2 en premier), puis dans m2 il trouve le from . import m1 ligne, qui échoue pour la même raison que précédemment.

    Si vous ne spécifiez pas explicitement importer les modules dans __init__.py quelque chose de semblable se produit toujours en arrière-plan. La différence est que vous obtenez un moins à plat de la structure (que les importations ne sont plus a commencé à partir de l'ensemble seulement). De la sorte, module1 et module2 obtenir “commencé” et vous obtenez respectifs de l'initialisation de tirages.

    Pour le faire fonctionner, vous pourriez faire un absolu de l'importation dans module2. De cette façon, vous pouvez éviter que le paquet doit résoudre tout d'abord, et de rendre la réutilisation de l'importation à partir de start.py (comme il a le même chemin d'importation).

    Ou encore mieux, vous vous débarrassez de l'importation circulaire à tous. C'est généralement un signe que votre structure de la demande n'est pas très bon, si vous avez des références circulaires.

    (J'espère que mon explication n'a aucun sens, j'ai déjà eu des difficultés à écrire, mais l'idée générale doit être clair, je l'espère...)

    modifier

    En réponse à votre mise à jour; ce que vous faites, c'est que vous utilisez le nom complet du paquet pour obtenir la référence au module. C'est l'équivalent (mais beaucoup plus compliqué) pour la première option possible pour le faire fonctionner; vous utilisez un absolu de l'importation en utilisant le même chemin d'importation comme dans start.py.

  3. 2

    Votre mise à jour émule ce que l'absolu importer n': import package1.module1 si vous le faites alors que module1 importées. Si vous souhaitez utiliser une dynamique package parent nom avant de les importer module1 dans le module2.py:

    import importlib
module1 = importlib.import_module('.module1', __package__)

    J'ai besoin circulaire importations. Une fonction dans module1 affirme que l'un de ses
    paramètre est instance d'une classe définie dans module2 et vice-versa.

    Vous pouvez déplacer une les classes à un module séparé pour résoudre la dépendance circulaire ou de faire de l'importation à un niveau de fonction si vous ne voulez pas utiliser absolue des importations.

    .
├── start.py
#       from package1 import module1
└── package1
    ├── __init__.py
#           print("Init package1")
#           from . import module1, module2
    ├── c1.py
#           print("Init package1.c1")
#           class C1:
#               pass
    ├── module1.py
#           print("Init package1.module1")
#           from .c1 import C1
#           from .module2 import C2
    └── module2.py
#           print("Init package1.module2")
#           from .c1 import C1
#           class C2:
#               pass
#           def f():
#               from .module1 import C1

    De sortie

    Init package1
Init package1.module1
Init package1.c1
Init package1.module2

    Une autre option qui pourrait être plus simple que le refactoring hors c1.py est de fusionner module{1,2}.py en un seul common.py. module{1,2}.py rendre les importations en provenance de common dans ce cas.

  4. 1
    module2.py
          import module1

    Travaille trop.

  5. 0

    La accepté de répondre à Circulaire de la dépendance aux importations en Python fait un bon point:

    Si a dépend de c et de c dépend de l', ne sont-ils pas fait la même unité?

    Vous devriez vraiment examiner pourquoi vous avez split a et c en deux sous-ensembles, soit parce que vous avez un peu de code, vous devriez scission dans un autre package (afin de les rendre dépendent de ce nouveau package, mais pas les uns les autres), ou les fusionner en un seul paquet.

    — Lasse V. Karlsen♦

    Peut-être vous devriez envisager de les placer dans le même module. 🙂

  6. 0

    Je suis tombé sur cette même question aujourd'hui, et il semble que ce soit bien cassé en python3.4, mais travaille en python3.5.

    La changelog a une entrée:

    Circulaire impliquant des importations relative des importations sont désormais pris en charge. (Contribué par Brett Canon et Antoine Pitrou dans bpo-17636).

    En regardant à travers le rapport de bogue, il semble que ce n'est pas tellement un buf fixe, ainsi qu'une nouvelle fonctionnalité dans la façon dont les importations de travail. Se référant à poke la réponse ci-dessusil montre que from . import foo moyen de charger __init__.py et obtenir foo (éventuellement à partir de la chargée implicitement liste des submodules). Depuis python3.5, from . import foo fera de même, mais si foo n'est pas disponible comme un attribut, il reviendra à la recherche à travers les listes des modules chargés (sys.modules) pour voir si il est déjà présent, ce qui résout ce cas particulier. Je ne suis pas sûr à 100%, j'ai bien présenté la façon dont cela fonctionne, cependant.

  7. 0

    Assurez-vous que votre package1 est un dossier. Créer une classe dans __init__.py -- dire class1. Comprendre votre logique dans une méthode en vertu de class1 -- dire method1.

    Maintenant, écrivez le code suivant - 

    from .package1 import class1
class1.method1()

    C'était ma façon de le résoudre. Pour résumer, votre répertoire racine est . afin d'écrire votre import déclaration à l'aide de . notations, par exemple from .package ou from app.package.