Brauche include statt import

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Apothecarius
User
Beiträge: 9
Registriert: Sonntag 8. März 2009, 21:19

Hi
Ich hab letztens (was heißt letztens, an dem Script schreib ich schon mindestens ein Jahr) ein Mensch ärger dich nicht Spiel geschrieben. Mit GTK Oberfläche, Bots, etc.
Das Problem ist das Script ist so nur schwer verbesserbar, weil der gesamte Code (ca 1500 Zeilen) in einer Datei steht (jaja ist schlechter Stil, das weiß ich jetzt auch)

Ich würde das Ganze gern in separate Module aufteilen (nach Klassen, Themen etc) allerdings gibt das seltsame Bugs.
Wenn ich eine Klasse, die auf eine andere zugreift (Klasse Spieler enthält je 4 Instanzen von Klasse Einheit) in ein Modul auslagere, dann beschwert sich Python, dass es diese andere Klasse(egal ob noch im Hauptscript oder ebenfalls ausgelagert) nicht sehen kann.

Die Lösung wäre wohl ein include statt import, das ein Script nur stupide in den Hauptcode einfügt, aber gibt es sowas in integriert in python?
Oder müsste ich das mit exec und open selber basteln?
Oder muss ich das ganze Programm neu schreiben?
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

1500 LoC sind doch nicht so viel.

Teile den Code sinnvoll auf. Außerdem müssen sich die einzelnen module sich gegenseitig kennen, wenn sie voneinander abhängen.

Includes gibt es aus guten Gründen nicht.
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
.robert
User
Beiträge: 274
Registriert: Mittwoch 25. April 2007, 17:59

Also prinzipiell solltest du mit import glücklich werden. Und weiter wäre es im Prinzip günstig, hier vllt. Fehlermeldungen zu posten, und einen reduzierten Code, der dein Problem reproduziert.

Ich vermute ja du hast bei dem Import einfach falsche Angaben gemacht oder so. Schon in der Python-Doku nach imports gesucht uns gelesen?
Benutzeravatar
/me
User
Beiträge: 3554
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

jbs hat geschrieben:1500 LoC sind doch nicht so viel.
In einem Skript halte ich das im Regelfall für zu viel.
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

Die Frage ist was man bezweckt. Wenn man es erweiterbar oder wiederverwendbar machen will, dann sollte man es sinnvoll aufteilen. Als Übung ist es sicherlich auch gut es zu trennen.

Was ich sagen will, es gibt sinnvollere Argumente für die Aufteilung als die LoCs.


Aber du sagtest ja auch Regelfall ;)
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Vielleicht solltest Du Dir mal den Abschnitt über Module im Tutorial angucken:
http://docs.python.org/tutorial/modules.html

Ansonsten hilft es sicherlich mal eine Fehlermeldung inkl. des zugehörigen Codes zu posten. Dieses nicht "sehen" können ist ein ImportError, oder AttributeError, oder..?

Wieso eigentlich hältst Du in einem Modul konkrete Klassenobjekte? Ich würde doch annehmen, dass diese dynamisch zur Laufzeit erzeugt werden.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Apothecarius
User
Beiträge: 9
Registriert: Sonntag 8. März 2009, 21:19

Ok, sachlich ausgedrückt:

Code: Alles auswählen

#(a.py)
class a:
	def __init__(self):
		pass
from b import *
asd = b()


#(b.py)
class b:
	def __init__(self):
		self.asd = a()
NameError: global name 'a' is not defined

Sowas hab ich alle Nase lang in meinem Programm
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

`b.py` muss eben `a` kennen, d.h. du musst dort eben auch importieren. Was aber auch nicht klappen wird, da das ein zirkulaerer Import waere.

Sehe ich das richtig und du erstellst fuer jede Klasse eine Datei? This way lies madness. Man sollte gruppieren was zusammengehoert und wenn du zirkulaere Importe hast ist das ein starkes Anzeichen dafuer, dass a) das Design ueberarbeitet werden muss oder b) die Aufteilung nicht stimmt.

P.S. Importe sollte man in den Anfang des Moduls schreiben und Sternchen-Importe vermeiden.
frabron
User
Beiträge: 306
Registriert: Dienstag 31. März 2009, 14:36

Ich bin mir nicht sicher, ob ich dein Beispiel richtig verstehe, aber du musst in b.py auch a.py importieren. Und bitte nicht mittels *-Import.

Code: Alles auswählen

#b.py
import a

foobar = a.a()
Edit
Knapp zu spät ...
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

Gegenseitige Abhängigkeiten zeugen häufig von krudem Design.
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
Apothecarius
User
Beiträge: 9
Registriert: Sonntag 8. März 2009, 21:19

Der ganze Code ist in einer Datei, NATÜRLICH ist es krudes Design.

Der ganze Code hat ständige Querverweise. Wenn ich zirkuläre Imports nicht verhindern kann, müsste ich alles neu schreiben.
Oder eben den Code includen statt zu importieren, aber das wird den Code womöglich nicht einfacher machen.
.robert
User
Beiträge: 274
Registriert: Mittwoch 25. April 2007, 17:59

Ich verstehe gerade nicht, wo du einen Unterschied von 'include' und 'import' siehst...

(... falls es ein include geben würde)
Apothecarius
User
Beiträge: 9
Registriert: Sonntag 8. März 2009, 21:19

In php macht include, dass der gesamte Inhalt einer anderen Datei an dieser Stelle eingefügt wird, ohne Überprüfungen oder irgendwas. Das würde meine Probleme lösen, da ich den Code für den Interpreter nicht wirklich ändere. Realisieren würde ich das ganze einfach indem ich die andere Datei mit open auslesen und mit exec ausführe.
rads
User
Beiträge: 153
Registriert: Freitag 26. März 2010, 15:51

Dann hast du aber eigentlich immer noch eine logische datei mit 1500 Zeilen ud trotzdem nicht die Funktionen (im Gedanken der Objektorientierung) in Teilmodulle ausgegliedert, was ja eigentlich Sinn der Auslagerungsaktion sein sollte?

Grüße

Stefan

[Edit]
natürlich ist die restrukturierung des codes aufwändig, aber durchaus sinnvoll Außerdem macht man dann den fehler 1500 zeilen in einer Klasse zu schreiben, nur einmal.
Mit Refactoring-mechanismen sollte das an sich noch einigermassen angenehm gehen?
Zuletzt geändert von rads am Montag 23. August 2010, 13:37, insgesamt 1-mal geändert.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Apothecarius hat geschrieben:In php macht include, dass der gesamte Inhalt einer anderen Datei an dieser Stelle eingefügt wird, ohne Überprüfungen oder irgendwas. Das würde meine Probleme lösen, da ich den Code für den Interpreter nicht wirklich ändere.
Und Du bist sicher, dass das die Übersicht erhöht?
Realisieren würde ich das ganze einfach indem ich die andere Datei mit open auslesen und mit exec ausführe.
Oh graus! :shock: Nee, nee, das lass mal lieber und refactore eben Dein Programm! Das mag ein wenig Mühe bedeuten, man lernt dadurch aber sicherlich mehr, als durch irgend eine Frickel-work-around Lösung.

Zumal Du daran ja weiterarbeiten willst!
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
.robert
User
Beiträge: 274
Registriert: Mittwoch 25. April 2007, 17:59

Apothecarius hat geschrieben:In php macht include, dass der gesamte Inhalt einer anderen Datei an dieser Stelle eingefügt wird, ohne Überprüfungen oder irgendwas. Das würde meine Probleme lösen, da ich den Code für den Interpreter nicht wirklich ändere. Realisieren würde ich das ganze einfach indem ich die andere Datei mit open auslesen und mit exec ausführe.
Brrrr, da bekomm ich ja ne Gänsehaut... :shock:

Deinem ersten Posting entnehme ich, dass du dein Script übersichtlicher machen und es in Module aufteilen willst, da wirst du also ein klein wenig Gehirnschmalz investieren müssen, um eine geeignete Modulstruktur daraus zu erzeugen. Deine Idee mit dem (brrr) include (/brrr) wird sich eher gegenteilig auswirken.
Apothecarius
User
Beiträge: 9
Registriert: Sonntag 8. März 2009, 21:19

Mit übersichtlichkeit mein ich mehr, dass man nicht ewig suchen muss wo die und die Funktion ist und dass man mehrere Teile gleichzeitig nebeneinander offen haben kann, um die Querverweise im Script besser zu erkennen/verstehen.
Aber okay, work work

Sobald ich damit fertig bin, post ich das Ergebnis mal. Wird aber womöglich dauern, hatte noch zigfach anderes vor.
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

Genau deshalb sind imports so toll. Man weiß immer wo etwas her kommt. Außer man benutzt * importe, was einem include schon sehr ähnlich ist.
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

jbs hat geschrieben:Außer man benutzt * importe, was einem include schon sehr ähnlich ist.
Bis auf die Tatsache, dass es eben immernoch in einem eigenen Namensraum ausgewertet wird und erst dann die Namen neu lokal gebunden werden und keine reine textuelle Ersetzung ist.

Man koennte natuerlich einen Praeprozessor vor den Python-Interpreter schnallen und den dann die Ersetzungen uebernehmen lassen, das war ja schon seit jeher eine Tolle Idee™
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

Dann kann man Module als Mixins benutzen :)
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
Antworten