2010-09-01 20 views
30

J'utilise PyQt et je suis confronté à ce problème. Si mes instructions d'importation sont:L'importation de caractères génériques doit-elle être évitée?

from PyQt4.QtCore import * 
from PyQt4.QtGui import * 

alors pylint donne des centaines d'avertissements "Importation inutilisée". J'hésite à les éteindre, car il pourrait y avoir d'autres importations inutilisées qui sont effectivement utiles à voir. Une autre option serait de faire ceci:

from PyQt4.QtCore import Qt, QPointF, QRectF 
from PyQt4.QtGui import QGraphicsItem, QGraphicsScene, ... 

et je finis par avoir 9 classes sur la ligne QtGui. Il y a une troisième option, qui est la suivante:

from PyQt4 import QtCore, QtGui 

puis préfixe toutes les classes avec QtCore ou QtGui chaque fois que je les utilise. À ce stade, je suis agnostique quant à laquelle je finis dans mon projet, bien que le dernier semble le plus douloureux de mon point de vue. Quelles sont les pratiques courantes ici? Y a-t-il une raison technique pour utiliser un style plutôt qu'un autre?

+0

Je cette question parce que tenu le premier rôle que je veux voir la réponse, mais je suis aussi curieux de savoir pourquoi on fais ceci. Habituellement, je ne fais qu'importer ce dont j'ai besoin, et je sais ce dont j'ai besoin, donc je ne fais qu'importer ces choses. Peut-être que je suis naïf, mais il me semble que la "douleur" de taper QtCore.something serait meilleure (autofill?) Que gaspiller le temps du processeur à importer des centaines d'éléments inutilisés. Je sais que cela me ferait exploser dans une revue de code. Ils me posent des questions sur chaque importation que j'utilise. – xnine

+0

Je serais d'accord avec vous pour le code professionnel, mais pour les scripts personnels ou les projets, ce n'est pas un gros problème. D'autant plus que l'importation va probablement se produire dès le lancement du programme, donc cela ne devrait pas affecter les performances, juste le temps de démarrage. – Colin

Répondre

31

La réponse au titre de votre question est « oui »: Je recommande ne jamais utiliser from ... import *, et moi avons discuté les raisons dans une autre réponse très récente. Brièvement, les noms qualifiés sont bon, les noms de barre sont très limités, donc la "troisième option" est optimale (car vous utiliserez des noms qualifiés, pas des noms de barre) parmi ceux que vous présentez. (Les avantages des noms qualifiés par rapport aux noms de barres incluent la facilité de truquage/simulation à des fins de test, réduit au risque annulé d'erreurs non détectées induites par une reconsolidation accidentelle, possibilité de "semi-faux" le nom supérieur dans une "classe de traçage" le but de noter exactement ce que vous utilisez et de faciliter des activités telles que le profilage, et ainsi de suite - inconvénients, à peu près aucun ... voir aussi le dernier-mais-non-moindre koan dans le zen de Python, import this à la invite d'interprète interactif).

Tout aussi bien, si vous Grudge les 7 caractères supplémentaires pour dire QtCore.whatever, est de abrégez - from PyQt4 import QtCore as Cr et from PyQt4 import QtGi as Gu (utilisez Cr.blah et Gu.zorp) ou similaire. Comme toutes les abréviations, c'est un compromis de style entre la concision et la clarté (préférez-vous nommer une variable count_of_all_widgets_in_the_inventory, num_widgets, ou ? Souvent le choix du milieu serait le meilleur, mais pas toujours ;-).

BTW, je ne voudrais pas utiliser plus d'une clause as en une seule déclaration from ou import (pourrait être source de confusion), je préfère avoir plusieurs instructions (également plus facile à déboguer si toute importation donne problème, modifier si vous changez vos importations dans le futur, ...).

+1

Merci, c'est beaucoup d'informations utiles – Colin

+0

Un autre avantage de qualifié - vous ne pouvez pas tout importer dans une lib énorme comme PyQt, et ensuite provoquer accidentellement une collision d'espace de noms avec quelque chose que vous ne saviez pas là. – user106514

+1

peut-être il ya une faute de frappe, "importer de ce" -> "importer ceci" – sunqiang

3

Python doc dit:

Although certain modules are designed to export only names that follow certain patterns when you use import *, it is still considered bad practise in production code.

Il peut avoir des effets secondaires et être très difficile à déboguer

Personellement, je me sers import plutôt que from import parce que je trouve de grandes déclarations terribles au début de le fichier et je pense qu'il maintient le code plus lisible

import PyQt4 

PyQt4.QtCore 

Si le nom du module est trop long et peut être renommé localement avec le mot-clé as. Par exemple:

import PyQt4.QtCore as Qc 

J'espère que cela aide

+0

Ainsi, si vous aviez un gestionnaire d'événement de souris, par exemple, vous pourriez avoir une ligne comme ceci: "if event.buttons() & PyQt4.QtCore.Qt.LeftButton:"? Cela ne semble pas aussi lisible que "if event.buttons() & Qt.LeftButton:" – Colin

+3

Si cela devient trop long, je fais: importer PyQt4.QtCore.Qt à Qc puis Qc.LeftButton – luc

+0

Je voulais dire: importer PyQt4. QtCore.Qt comme Qc – luc

6

Il existe également de bons cas pour import *. c'est à dire. il est courant pour les développeurs Django d'avoir de nombreux fichiers de configuration et les chaîne avec l'importation *:

settings.py: 
FOO = 1 
BAR = 2 
DEBUG = False 

test_settings.py: 
from settings import * 
DEBUG = True 

Dans ce cas, la plupart des inconvénients de import * deviennent des avantages.

+0

Ces fichiers sont des one-hit-wonders qui sont conçus pour être importés par star. PyQt4.QtGui n'est pas admissible! C-; – Phlip

+4

@Phlip D'accord, mais le titre de cet article est "Faut-il éviter l'importation de caractères génériques?" pas "Faut-il éviter l'importation de caractères génériques ** dans PyQt4 **?" –

+0

Je pense que cette réponse est nécessaire pour montrer de bons scénarios, pas seulement pour choisir le scénario principal et dire que c'est mauvais. C'est comme dire "Dois-je conduire ma voiture sur une route", et quelqu'un dit "oui" et quelqu'un d'autre dit "pas s'il n'y a pas de panneaux d'entrée". – James

0

L'importation pour PyQt4 est un cas particulier.
parfois je vais choisir la "première option" pour le codage rapide et sale, et le tourner à la "deuxième option" lorsque le code se développe de plus en plus longtemps.
collision d'espace de noms peut-être pas un gros problème ici, je n'ai pas vu d'autre nom de paquet commence avec un grand "Q". et chaque fois que je termine un script PyQt4. convertir "de PyQt4.QtGui import *" en sth. comme "

from PyQt4.QtGui import (QApplication, QDialog, QLineEdit, QTextBrowser, 
         QVBoxLayout) 

" juste FYI, parentheses for multi-line import est ici à portée de main.

1

J'utilise le "import *" pour les modules PyQt que j'utilise, mais je les mets dans leur propre module, donc il ne pollue pas l'espace de noms de l'utilisateur. par exemple.

En qt4.py:

 
from PyQt4.QtCore import * 
from PyQt4.QtGui import * 

ensuite l'utiliser comme ceci

 
import qt4 
app = qt4.QApplication(...) 
+1

N'est-ce pas équivalent à "importer PyQt4.QtCore comme qt4 "? Je suppose que vous auriez besoin d'espaces de noms séparés pour QtCore et QtGui si vous avez fait cela, mais cela ne semble pas être une si mauvaise chose – Colin

+0

C'est équivalent, s'il n'y a qu'une seule importation dans qt4.py. Nous n'avons pas trouvé la distinction entre QtCore, QtGui, etc ... très utile lors de la programmation – xioxox

+0

Ceci est une bonne solution qui contourne le croupet en haut des fichiers source. Les modules Qt ne sont pas en conflit les uns avec les autres. ne présente aucun problème pour autant que je sache. – mfitzp