Je ne connais pas le python, donc s'il y a un problème dans mes mots, dites-le moi. Si votre hiérarchie de fichiers est organisée comme ceci:
project\
module_1.py
module_2.py
module_1.py
définit une fonction appelée func_1()
, module_2.py :
from module_1 import func_1
def func_2():
func_1()
if __name__ == '__main__':
func_2()
et vous exécutez python module_2.py
en cmd, il exécutera ce qui func_1()
définit. C'est généralement ainsi que nous importons les mêmes fichiers de hiérarchie. Mais quand vous écrivez from .module_1 import func_1
dans module_2.py
, interpréteur Python dira No module named '__main__.module_1'; '__main__' is not a package
. Donc, pour résoudre ce problème, nous conservons simplement les modifications que nous venons d'apporter, et déplaçons les deux modules dans un package, et créons un troisième module en tant qu'appelant à exécuter module_2.py
.
project\
package_1\
module_1.py
module_2.py
main.py
main.py :
from package_1.module_2 import func_2
def func_3():
func_2()
if __name__ == '__main__':
func_3()
Mais la raison pour laquelle nous ajoutons un .
avant module_1
en module_2.py
est que si nous ne le faisons pas et exécuter main.py
, l' interpréteur python va dire No module named 'module_1'
, c'est un peu délicat, qui module_1.py
est juste à côté module_2.py
. Maintenant , je laisse func_1()
en module_1.py
do quelque chose:
def func_1():
print(__name__)
qui __name__
enregistre qui appelle func_1. Maintenant, nous gardons l' .
avant module_1
, exécutons main.py
, il imprimera package_1.module_1
, non module_1
. Cela indique que celui qui appelle func_1()
est dans la même hiérarchie que main.py
, .
cela implique qu'il module_1
est dans la même hiérarchie que module_2.py
lui. Donc, s'il n'y a pas de point, main.py
reconnaîtra module_1
la même hiérarchie que lui, il peut reconnaîtrepackage_1
, mais pas ce qui est "sous".
Maintenant, faisons un peu compliqué. Vous avez un config.ini
et un module définit une fonction pour le lire dans la même hiérarchie que 'main.py'.
project\
package_1\
module_1.py
module_2.py
config.py
config.ini
main.py
Et pour une raison inévitable, vous devez l'appeler avec module_2.py
, il doit donc importer de la hiérarchie supérieure. module_2.py :
import ..config
pass
Deux points signifie l'importation à partir de la hiérarchie supérieure (trois points d'accès supérieur à supérieur, etc.). Maintenant , nous courons main.py
, l'interprète dira: ValueError:attempted relative import beyond top-level package
. Le "package de niveau supérieur" ici est main.py
. Tout simplement parce qu'ils sont à config.py
côté main.py
, ils sont dans la même hiérarchie, config.py
ne sont pas "sous" main.py
, ou ils ne sont pas "dirigés" par main.py
, donc c'est au-delà main.py
. Pour résoudre ce problème, le moyen le plus simple est:
project\
package_1\
module_1.py
module_2.py
config.py
config.ini
main.py
Je pense que cela coïncide avec le principe de l'organisation de la hiérarchie des fichiers de projet, vous devez organiser les modules avec différentes fonctions dans différents dossiers, et laisser simplement un appelant supérieur à l'extérieur, et vous pouvez importer comme vous le souhaitez.