Pourquoi "import *" est-il mauvais?

Question

Il est recommandé de ne pas utiliser import * en Python. Quelqu'un peut-il s'il vous plaît partager la raison de cela, afin que je puisse éviter de le faire la prochaine fois?

Answer 1

• Parce qu'il met beaucoup de choses dans votre espace de noms (peut masquer un autre objet de l'importation précédente et vous ne le saurez pas).

• Parce que vous ne savez pas exactement ce qui est importé et que vous ne pouvez pas localiser quel module a été importé (lisibilité).

• Parce que vous ne pouvez pas utiliser d’outils géniaux comme pyflakes pour détecter des erreurs statiques dans votre code.

Answer 2

Selon le Python Zen :

Explicite est meilleur qu'implicite.

... ne peut pas discuter avec ça, sûrement?

Answer 3

Vous ne passez pas d' **locals() de fonctions, avez-vous?

Depuis le Python n'a pas de "comprendre" l'énoncé, et l' self paramètre est explicite, et la portée des règles sont assez simples, il est généralement très facile de pointer du doigt une variable et de dire d'où que l'objet vient de passer de la lecture à d'autres modules et sans aucune sorte d'IDE (qui sont limitées dans la voie de l'introspection, de toute façon, par le fait que la langue est très dynamique).

L' import * des sauts de tout cela.

Aussi, il a une possibilité concrète de se cacher de bugs.

import os, sys, foo, sqlalchemy, mystuff
from bar import *

Maintenant, si le module de barre a tout de la "os", "mystuff", etc... les attributs, ils remplacent de façon explicite pour ceux qui sont importés, et peut-être à des choses très différentes. La définition d' __all__ dans le bar est souvent sage -- les etats ce sera implicitement être importé, mais il est encore difficile de retrouver la trace où les objets viennent, sans la lecture et de l'analyse du module de barre et à la suite de ses importations. Un réseau d' import * est la première chose que j'ai corrigé quand je prends l'appropriation d'un projet.

Ne vous méprenez pas: si l' import * avaient disparus, j'ai envie de pleurer pour l'avoir. Mais il doit être utilisé avec précaution. Un bon cas d'utilisation est de fournir une façade interface sur un autre module. De même, l'utilisation de la réserve de déclarations d'importation, ou les importations à l'intérieur de la fonction/classe d'espaces de noms, demande un peu de discipline.

Je pense que dans un milieu à de grands projets, ou les petits, avec plusieurs contributeurs, un minimum d'hygiène est nécessaire en termes de statique -- analyse de la course au moins pyflakes ou encore mieux, un correctement configuré pylint -- à attraper plusieurs genre de bugs avant qu'ils ne surviennent.

Bien sûr, puisque c'est python-n'hésitez pas à briser les règles, et d'explorer -- mais méfiez-vous des projets qui pourraient être décuplées, si le code source est manquante de la discipline, il ne sera pas un problème.

Answer 4

C'est parce que vous polluez l'espace de noms. Vous allez importer toutes les fonctions et les classes dans votre propre espace de noms, ce qui peut entrer en conflit avec les fonctions que vous définissez vous-même.

De plus, je pense que l'utilisation d'un nom qualifié est plus claire pour la tâche de maintenance; vous voyez sur la ligne de code elle-même d'où provient une fonction, ce qui vous permet de consulter la documentation beaucoup plus facilement.

Dans le module foo:

 def myFunc():
    print 1
 

Dans votre code:

 from foo import *

def doThis():
    myFunc() # Which myFunc is called?

def myFunc():
    print 2
 

Answer 5

http://docs.python.org/tutorial/modules.html

Notez qu'en général, l'importation de * partir d'un module ou d'un package est désapprouvée, car cela provoque souvent un code peu lisible .