L'importation relative se produit chaque fois que vous importez un package par rapport au script / package actuel.
Prenons par exemple l'arbre suivant:
mypkg
├── base.py
└── derived.py
Maintenant, vous avez derived.pybesoin de quelque chose de base.py. Dans Python 2, vous pouvez le faire comme ceci (in derived.py):
from base import BaseThing
Python 3 ne prend plus en charge cela car il n'est pas explicite si vous voulez le "relatif" ou "absolu" base. En d'autres termes, s'il y avait un package Python nommé baseinstallé dans le système, vous vous tromperiez.
Au lieu de cela, il vous oblige à utiliser des importations explicites qui spécifient explicitement l'emplacement d'un module sur une base de chemin. Votre derived.pyressemblerait à:
from .base import BaseThing
Le premier .indique «importer basedepuis le répertoire du module»; en d'autres termes, .basecorrespond à ./base.py.
De même, il y a un ..préfixe qui monte dans la hiérarchie des répertoires comme ../(avec ..modmappage vers ../mod.py), puis ...qui monte de deux niveaux ( ../../mod.py) et ainsi de suite.
Veuillez cependant noter que les chemins relatifs listés ci-dessus étaient relatifs au répertoire dans lequel se trouve le module actuel ( derived.py), et non au répertoire de travail actuel.
@BrenBarn a déjà expliqué le cas de l'importation d'étoiles. Pour être complet, je vais devoir dire la même chose;).
Par exemple, vous devez utiliser quelques mathfonctions mais vous ne les utilisez que dans une seule fonction. Dans Python 2, vous étiez autorisé à être semi-paresseux:
def sin_degrees(x):
from math import *
return sin(degrees(x))
Notez qu'il déclenche déjà un avertissement dans Python 2:
a.py:1: SyntaxWarning: import * only allowed at module level
def sin_degrees(x):
Dans le code Python 2 moderne, vous devriez et dans Python 3, vous devez faire soit:
def sin_degrees(x):
from math import sin, degrees
return sin(degrees(x))
ou:
from math import *
def sin_degrees(x):
return sin(degrees(x))