Maison >développement back-end >Tutoriel Python >Python 3.3 élimine-t-il le besoin de __init__.py dans les packages ?
Python 3.3 et les versions ultérieures introduisent le concept de packages d'espace de noms. Cette fonctionnalité vous permet de créer un package sans fichier __init__.py.
< h2>Quand utiliser les packages d'espace de noms
Le cas d'utilisation principal de l'espace de noms packages, c'est lorsque vous avez plusieurs bibliothèques résidant à différents emplacements et que vous souhaitez qu'elles contribuent à un sous-package au package parent.
Par exemple :
google_pubsub/ <- Package 1
google/ <- Namespace package (no __init__.py) cloud/ <- Namespace package (no __init__.py) pubsub/ <- Regular package (with __init__.py) __init__.py <- Required to make the package a regular package foo.py
google_storage/ <- Forfait 2
google/ <- Namespace package (no __init__.py) cloud/ <- Namespace package (no __init__.py) storage/ <- Regular package (with __init__.py) __init__.py <- Required to make the package a regular package bar.py
Dans cet exemple, google_pubsub et google_storage partagent le même espace de noms google/cloud. Cela vous permet d'importer des modules depuis l'une ou l'autre des bibliothèques sans fournir le chemin complet.
Pour la plupart des cas d'utilisation, création de packages standards avec des fichiers __init__.py est toujours l’approche recommandée. Cela assure l'auto-confinement et évite les conflits potentiels d'espace de noms.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!