Supposons que vous avez 3 modules, a.py, b.py et c.py:Importations en Python: Est-ce que changer une variable dans "enfant" changera la variable "parent"/autres enfants?
a.py:
v1 = 1
v2 = 2
etc.
b.py:
from a import *
c.py :
from a import *
v1 = 0
Est-ce que c.py va changer v1 dans a.py et b.py? Si non, y a-t-il un moyen de le faire?
Tout ce qu'une déclaration comme:
v1 = 0
peut faire est de lier le nom v1 à l'objet 0. Cela ne peut pas affecter un module différent.
Si j'utilise des termes inconnus ici, et je suppose que je le suis probablement, je vous recommande fortement de lire l'excellent article de Fredrik Lundh, Python Objects: Reset your brain.
Oui, il vous suffit d'accéder correctement (et ne pas utiliser l'importation *, il est mal)
c.py:
import a
print a.v1 # prints 1
a.v1 = 0
print a.v1 # prints 0
La forme from ... import * est essentiellement destiné à une utilisation interactive à portée de main à l'invite de l'interprète: il est conseillé de ne jamais l'utiliser dans d'autres situations, car cela ne vous donnera que des problèmes.
En fait, le guide de style interne chez mon employeur va plus loin, recommandant de toujours importer un module, jamais contenu depuis un module (un module d'un package est OK et en fait recommandé). Par conséquent, dans notre base de code, les références aux objets importés sont toujours des noms qualifiés (themod.thething) et jamais des noms de barre (qui font toujours référence à des variables internes, des globales de ce même module ou des locales); cela rend le code beaucoup plus clair et plus lisible et évite toutes sortes d'anomalies subtiles.
Bien sûr, si le nom d'un module est trop long, une clause as dans l'importation, pour lui donner un alias plus court et plus pratique pour les besoins du module d'importation, est correcte. Mais, avec vos noms de modules à une lettre, cela ne sera pas nécessaire ;-).
Donc, si vous suivez la ligne directrice et toujours importer le module (et non les choses de l'intérieur), c.v1 sera toujours se référer à la même chose que a.v1 et b.v1, à la fois pour obtenir et définir: voici une anomalie subtile potentiel éviter dès le départ -)
Rappelez-vous la dernière bits du Zen de Python (faire import this à l'invite d'interprète pour tout voir):
Namespaces are one honking great idea -- let's do more of those!
Importation du module entier (pas de bits et pièces de l'intérieur) conserve son intégrité en tant que amespace, comme toujours se référant à des choses à l'intérieur du module importé par des noms qualifiés (pointillés). C'est une excellente idée klaxons: faire plus de cela -)
Donc, vous jamais "à partir de datetime import datetime"; vous importez toujours datetime, et tapez "datetime.datetime" à chaque fois?C'est un guide de style terrible. –
@Glenn, à votre question, "oui"; à votre avis, je ne connais aucun guide de style Python activement accepté (et imposé, via des "avis de lisibilité") par d'autres committers Python (y compris Guido ;-), ET notre Python SW semble avoir un succès raisonnable (y compris le temps de marché, maintenabilité, performance [cfr YouTube, basé sur Python ET rapide], etc), donc je me demande sur quelles données empiriques vous basez cette opinion. Oui, PEP 8 accepte "l'importation d'une classe", mais Guido a écrit que avant de rejoindre Google et rencontré (et accepté, et appliqué) notre guide de style génial! -) –
Écrire "datetime.datetime" est terriblement moche; "datetime.datetime.now" est encore plus laid; les styles de codage qui encouragent le code laid sont mauvais. Plus généralement, avoir le module comme espace de noms est simplement inutile lorsque la classe elle-même est un espace de noms. Importez le niveau qui est prévu comme espace de nom - pour de nombreux modules, c'est le module lui-même, mais pour des classes comme datetime, c'est la classe. –