2010-07-22 4 views

Répondre

4

Ne pas. Juste ne pas. Ai-je besoin d'expliquer à quel point c'est horrible? L'importation dynamique (quoique parfois inévitable) et l'importation dans un espace de noms global (toujours évitable, mais parfois la solution la plus facile et la fin des modules avec confiance) sont déjà assez mauvaises. L'importation dynamique dans l'espace de noms global est ... un cauchemar (et évitable). Il suffit de faire _temp = __import__(name, globals(), locals(), [name_of_class]); your_class = _temp.name_of_class. Selon le docs, il s'agit de ce que ferait le nom import name_of_class.

+0

Je l'ai eu aussi après avoir regardé les docs. Cela n'a pas fonctionné au début, la raison en est que j'ai oublié de déclarer la your_class globale. Merci quand même – Pwnna

+1

Donc en bref, vous dites d'utiliser 'my_class = __import __ (nom, globals(), locals(), [nom_de_classe]). Name_of_class' –

+0

Cela ne répond pas réellement à la question. La réponse ci-dessous est beaucoup mieux. – monokrome

2

Si quelqu'un lisant ceci veut une réponse réelle à la question dans le titre, vous pouvez le faire en manipulant le dictionnaire vars(). Oui, c'est idiot de le faire dans la plupart des scénarios, mais je peux penser à des cas d'utilisation où cela serait vraiment utile/cool (par exemple, vous voulez un nom de module statique, mais voulez que le contenu du module vienne d'ailleurs qui est défini lors de l'exécution. semblable et, OMI, mieux que le comportement de django.conf.settings si vous êtes familier avec elle)

module_name = "foo" 
for key, val in vars(__import__(module_name)).iteritems(): 
    if key.startswith('__') and key.endswith('__'): 
     continue 
    vars()[key] = val 

Ceci importe toutes les variables non-système dans le module foo.py dans l'espace de noms en cours.

Utilisez avec parcimonie :)