Frage an python, pygame, import – Kann jemand bitte diese seltsame Pygame-Importkonvention erklären?

6

Ich sehe, dass Leute Pygame normalerweise so importieren:

<code>import pygame
from pygame.locals import *
</code>

Ich verstehe nicht, wofür die zweite Zeile ist. Wenn wir Pygame bereits vollständig importiert haben, warum dann importieren?pygame.locals? Enthält Pygame es nicht bereits, nachdem es importiert wurde?

Deine Antwort

6   die antwort
5

Eigentlich aus dem Pygamedocs:

Dieses Modul enthält verschiedene von Pygame verwendete Konstanten. Der Inhalt wird automatisch in den Pygame-Modul-Namespace eingefügt. Eine Anwendung kann jedoch pygame.locals verwenden, um nur die Pygame-Konstanten mit einem 'from pygame.locals-Import *' einzuschließen.

Alle diese Konstanten sind also bereits vorhanden, wenn Sie sie verwendenimport pygame. Wir können das sehen, wenn wir das tun:

<code>>>> import pygame
>>> from pygame.locals import *
>>> set(dir(pygame.locals)).issubset(set(dir(pygame)))
True
</code>

So,pygame.locals ist eine Teilmenge vonimport pygame.. Also absolut sinnlos, wenn du Pygame schon importiert hast! Abgesehen davon können Sie sie ohne die zugreifenpygame Präfix.

pygame.locals wird Einheimische genannt, weil es mit Funktionen gefüllt ist, die Sie häufig aufrufen. Hinzufügenpygame.locals. Jedes Mal würde der Code weniger kompakt machen. David Robinson
Das scheint ein bisschen überflüssig. corazza
@Bane: Es ist nicht redundant. Sie machen sehr deutlich, was und wie in Ihren Namespace gelangt. Stefano Borini
0

Ich würde mir keine Sorgen machen. Ich weiß, dass Ihnen das gesagt wurde* Importe sind schlecht. Dies gilt bis zu einem gewissen Grad, es sei denn, die Pygame-Entwickler haben dies ausdrücklich definiert__all__ Attribut, in das sie alle diese handlichen Konstanten eingegeben haben, und sie haben. Auf diese Weise machten sie dies besonders* Import sicher.

Das* bezieht sich auf die__all__ Attribut, so suchen Sie diepygame.locals Quellcode für alle Konstanten in der__all__ Attribut.

1

Enthält Pygame es nicht bereits, nachdem es importiert wurde?

Nee. Nicht unbedingt.

<code>stefanos-imac:python borini$ touch a/__init__.py
stefanos-imac:python borini$ touch a/b.py
stefanos-imac:python borini$ echo "print 'hello' " >a/b.py 
stefanos-imac:python borini$ python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import a
>>> import a.b
hello
>>> 
</code>
1
<code>import pygame
from pygame.locals import *
</code>

http://www.pygame.org/docs/tut/ImportInit.html

Die erste Zeile hier ist die einzig notwendige. Es importiert alle verfügbaren Pygame-Module in das Pygame-Paket. Die zweite Zeile ist optional und fügt eine begrenzte Anzahl von Konstanten und Funktionen in den globalen Namespace Ihres Skripts ein.

6
<code>import pygame
</code>

Importiert das Pygame-Modul in den "Pygame" -Namensraum.

<code>from pygame.locals import *
</code>

kopiert alle Namen in pygame.locals in deinen aktuellen Namespace. Dies ist nicht erforderlich, erspart Ihnen jedoch die Eingabe.

2

Wenn Sie ausführen

<code>import pygame
</code>

Das Pygame ist vollständig importiert und betriebsbereit. Es sind keine weiteren Importe erforderlich.

Nun ist die Frage zu dieser Zeile:

<code>from pygame.locals import *
</code>

Es gibt mehrere Gründe, warum dies verwendet werden sollte, und einige Gründe, dies nicht zu tun.

Performance. Wenn Sie so etwas wie eingebenfoo.bar.baz.ClassName.classmethod()gibt es 4 Lookups im Namespace, die einige Zeit kosten. Je mehr solche Zeilen im Code enthalten sind, desto unnötiger ist die Zeitverschwendung.Einfachheit. Wenn Sie Tutorials schreiben, versuchen Sie, die Dinge so einfach wie möglich zu erklären. Je weniger Code, desto besser das Tutorial.Leichtigkeit. Wenn Sie Ihren Code eingeben, verteilen Sie ihn auf verschiedene Dateien. Weil es einfacher ist, mit kleineren Nebendateien zu arbeiten und diese dann alle in die Hauptdatei zu importieren. Aber Sie verstehen genau, was Sie importieren.Namespase-Verschmutzung. Wenn Sie alles aus dem Modul in globale Variablen importieren, ist die Auswahl globaler Variablen eingeschränkter. Zum Beispiel,from struct import * Sie können Ihre Funktion nicht als benennenpack. Bevor Sie solche Importe verwenden, sollten Sie das Modul untersuchen. Was enthält es? Was importiert es von selbst?Chaos. Wenn Sie solche Importe oft verwenden,from foo import * undfrom bar import * undfrom baz import *Einige Variablen oder Konstanten können schattiert oder überschrieben sein. In diesem Beispielfoo.version wird überschrieben mitbar.version, jetzt benannt alsversion. So,foo.checkversion() funktioniert nicht mehr richtig.

Der richtige Weg ist, die häufig verwendeten Funktionen in expliziter Form zu importieren oder als Kurzreferenz zu verwenden, insbesondere wenn Sie das Modul nicht genau kennen.

Zum Beispiel:

<code>from foo.bar.baz import a_very_useful_function
</code>

oder

<code>import foo.bar.baz
quick_referenced_fn = foo.bar.baz.a_very_useful_function
</code>

Hierquick_referenced_fn ist immer nochfoo.bar.baz.a_very_useful_function und arbeitet im Namespace vonfoo.bar.baz, aber der Dolmetscher kennt seine Adresse direkt und führt keine zusätzlichen Suchvorgänge durch.

Verwandte Fragen