Hallo zusammen,
ich bin ganz neu im Forum und hoffe hier auf guten Support . Ich habe vor kurzem (einige Stunden) erst mit Python angefangen. Meine Literatur beschränkt sich bisher auf "A Byte of Python".
Naja....wagemutig wie ich bin, will ich direkt ein kleines Verwaltungsprogramm für meine Arbeit schreiben. In diesem Programm soll es die Möglichkeit geben Etwas mit bestimmten Eigenschaften anzulegen, zu bearbeiten, zu löschen und halt...zu verwalten.
Nun zu meiner ersten Frage:
Wie sollte ich ein solches Programm aufbauen? Also gibt es bestimmte Regeln nach denen ich sowas Aufbauen sollte?
Ich gebe mal ein Beispiel:
Ich dachte mir eine Datei für diverse Funktionen anzulegen und für jeden Bereich wie "Anlegen" , "Löschen" usw. ebenfalls eine eigene Datei anzulegen. Ist sowas sinnvoll oder eher nicht ? Gibt es bessere....sinnsollere Methonden für sowas?
Ob es so nun sinnvoll ist oder nicht, trotz alle dem würde ich gerne wissen wie man Dateien laden kann.....ähnlich dem "include" Befehl bei PHP vielleicht. Damit ich z.B. eine Datei namens "funktionen.py" irgendwo "include" um auf dessen Inhalt (die Funktionen eben) zu greifen kann.
Na das wars erst mal. Ich hoffe mir kann da mal jemand ein paar Infos geben.
Danke
//Ich
Fragen eines anfängers (Programmaufbau/Datei laden
Ob es so nun sinnvoll ist oder nicht, trotz alle dem würde ich gerne wissen wie man Dateien laden kann.....ähnlich dem "include" Befehl bei PHP vielleicht. Damit ich z.B. eine Datei namens "funktionen.py" irgendwo "include" um auf dessen Inhalt (die Funktionen eben) zu greifen kann.
Code: Alles auswählen
import funktionen
funktionen.blah()
Code: Alles auswählen
from funktionen import blah
blah()
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Ordne deinen Code semantisch und nicht syntaktisch, d.h. packe zusammen was zusammen gehoert und nicht nach Art getrennt.
Im kontreten Fall: ``admin.py`` fuer deine administrativen Teile (was du hier ``funktionen.py`` nennst), ``backend.py`` fuer die Persistenz und ``frontend.py`` fuer die GUI/CLI.
Im Tutorial solltest du dir vielleicht auch den Abschnitt ueber Module durchlesen.
Im kontreten Fall: ``admin.py`` fuer deine administrativen Teile (was du hier ``funktionen.py`` nennst), ``backend.py`` fuer die Persistenz und ``frontend.py`` fuer die GUI/CLI.
Im Tutorial solltest du dir vielleicht auch den Abschnitt ueber Module durchlesen.
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
-
- User
- Beiträge: 42
- Registriert: Samstag 11. Juli 2009, 16:36
Ich habe eine ganz ähnliche Frage zum Design von Programmen.
Hier erstmal ein kleines Testbeispiel zur Veranschaulichung:
GUI: http://paste.pocoo.org/show/131392/
APP: http://paste.pocoo.org/show/131393/
das Tool ist zweigeteilt in gui und app und man kann damit in ein Entry-widget Text eingeben und speichern, bzw. abgespeicherte Texte in das Entry-widget laden. Dabei importieren sich beide Dateien gegenseitig (sozusagen kreuzweise), da sie ja voneinander "wissen" müssen.
Ist das guter Stil? Macht man das so? Wenn nicht, wie macht man das sonst?
Hier erstmal ein kleines Testbeispiel zur Veranschaulichung:
GUI: http://paste.pocoo.org/show/131392/
APP: http://paste.pocoo.org/show/131393/
das Tool ist zweigeteilt in gui und app und man kann damit in ein Entry-widget Text eingeben und speichern, bzw. abgespeicherte Texte in das Entry-widget laden. Dabei importieren sich beide Dateien gegenseitig (sozusagen kreuzweise), da sie ja voneinander "wissen" müssen.
Ist das guter Stil? Macht man das so? Wenn nicht, wie macht man das sonst?
@AntagonisT: Kreuzweise importieren ist kein guter Stil und führt früher oder später auch zu handfesten Problemen. Schreib es so, dass die beiden nicht voneinander wissen müssen. In der Anwendungslogik sollte keine GUI bekannt sein müssen. Damit wäre die bei dem Beispiel dann allerdings so minimal, dass eine Auslagerung in ein eigenes Modul übertrieben ist.
Insgesamt ist das alles zu "global" und fest verdrahtet. Code auf Modulebene sollte sich auf Definitionen von Konstanten, Funktionen und Klassen beschränken. Und nicht veränderbare Objekte mit so nichtssagenden Namen wie `x` dort ablegen.
Insgesamt ist das alles zu "global" und fest verdrahtet. Code auf Modulebene sollte sich auf Definitionen von Konstanten, Funktionen und Klassen beschränken. Und nicht veränderbare Objekte mit so nichtssagenden Namen wie `x` dort ablegen.
-
- User
- Beiträge: 42
- Registriert: Samstag 11. Juli 2009, 16:36
Es geht hier auch nur um das Prinzip. Wie kann ich denn Daten an die GUI übergeben, wenn mein APP die gar nicht kennt? :KBlackJack hat geschrieben:Schreib es so, dass die beiden nicht voneinander wissen müssen. In der Anwendungslogik sollte keine GUI bekannt sein müssen.
Ich könnte die als Parameter in die APP-Funktionen übergeben, aber wenn ich jetzt 40 entry-widgets habe, die alle gespeichert/eingelesen werden sollen... ist das nicht auch umständlich?
Da waren sie wieder, meine 3 Probleme: Klassen, Klassen und Klassen..BlackJack hat geschrieben:Insgesamt ist das alles zu "global" und fest verdrahtet. Code auf Modulebene sollte sich auf Definitionen von Konstanten, Funktionen und Klassen beschränken.
Ich versuche seit ein paar Tagen, durchzusteigen, wozu die gut sein sollen; hier im Forum, Tutorials, Bücher. Ich. check. es. einfach. nicht!
Ich packe mein gui also in eine Klasse und dann ist gut? Oder wie ist das zu verstehen?
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Du übergibst keine Daten an die GUI, die GUI holt sich die Daten. Dadurch weiß die GUI von dem Backend aber das Backend muss nichts von der GUI wissen.AntagonisT hat geschrieben:Wie kann ich denn Daten an die GUI übergeben, wenn mein APP die gar nicht kennt? :K
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Poste bitte demnächst lauffähigen Code. Nachdem ich alle Vorkommnisse von `tkinter` durch `Tkinter` und `filedialog` durch `FileDialog` ersetzt habe, erhalte ich trotzdem eine Fehlermeldung:
Ich kann sie mir nicht erklären. Vielleicht liegt es an den zirkulären Importen.
Code: Alles auswählen
~/bin/py/test$ python gui.py
Traceback (most recent call last):
File "gui.py", line 2, in <module>
import app
File "/home/sebastian/bin/py/test/app.py", line 2, in <module>
import gui
File "/home/sebastian/bin/py/test/gui.py", line 13, in <module>
b1 ["command"] = app.file_open
AttributeError: 'module' object has no attribute 'file_open'
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Im Uebrigen ist das alles GUI, sollte also in einem Modul sein. Besser noch in einer Klasse die das GUI modelliert.
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
-
- User
- Beiträge: 42
- Registriert: Samstag 11. Juli 2009, 16:36
danke an alle Antworter.
@snafu: Das ist mit Python 3.1 lauffähig! und ja, das Problem könnte an den zirkulären Importen liegen. Kommt drauf an, welches der beiden Scripte Du startest...
neuer Versuch, diesmal ohne kreuzweise Importe, dafür ein unschönes Definitions-Hilfskonstrukt in meiner GUI:
GUI: http://paste.pocoo.org/show/131410/
APP: http://paste.pocoo.org/show/131411/
das mit "lambda" habe ich in der Zwischenzeit auch herausgefunden.
@snafu: Das ist mit Python 3.1 lauffähig! und ja, das Problem könnte an den zirkulären Importen liegen. Kommt drauf an, welches der beiden Scripte Du startest...
neuer Versuch, diesmal ohne kreuzweise Importe, dafür ein unschönes Definitions-Hilfskonstrukt in meiner GUI:
GUI: http://paste.pocoo.org/show/131410/
APP: http://paste.pocoo.org/show/131411/
das mit "lambda" habe ich in der Zwischenzeit auch herausgefunden.
-
- User
- Beiträge: 42
- Registriert: Samstag 11. Juli 2009, 16:36
AAAHHH, wo hört denn die GUI dann auf? Für mich war das bisher die reine Darstellung der Fenster, widgets, etc... und die übergeben alle "commands", Eingabewerte, etc... an ein anderes Modul.cofi hat geschrieben:Im Uebrigen ist das alles GUI, sollte also in einem Modul sein. Besser noch in einer Klasse die das GUI modelliert.
Das sollte man im Moment noch dazu schreiben. IMHO ist Python 2.6 momentan die meistverwendetste Version (ich möchte mich jetzt mal nicht zu "Standard" hinreißen lassen).AntagonisT hat geschrieben:Das ist mit Python 3.1 lauffähig!
Ich habe `gui.py` gestartet, weil dort der Mainloop aufgerufen wird.AntagonisT hat geschrieben:und ja, das Problem könnte an den zirkulären Importen liegen. Kommt drauf an, welches der beiden Scripte Du startest...
EDIT: `app.py` läuft. Ich werde mir jetzt mal deinen neuen Code angucken...
Zuletzt geändert von snafu am Mittwoch 29. Juli 2009, 10:08, insgesamt 1-mal geändert.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Die GUI hört dort auf, wo die algorithmische Berechnung beginnt, die das Problem löst. Bei dir gibt es so einen Teil gar nicht, also ist alles GUI.AntagonisT hat geschrieben:AAAHHH, wo hört denn die GUI dann auf? Für mich war das bisher die reine Darstellung der Fenster, widgets, etc... und die übergeben alle "commands", Eingabewerte, etc... an ein anderes Modul.
Richtwert: es sollte möglich sein, eine andere Oberfläche, zum Beispiel Textoberfläche oder Weboberfläche mit deinen nicht-GUI-Code zu verknüpfen. Dann hast du ordentliche Separation. Wenn aber überall in deinem Code Fenster aufgemacht werden oder eingaben entgegengenommen werden, dann ist eben alles (G)UI.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Um mal ein Beispiel zu nennen: Mit viel Wohlwollen könnte man eine Funktion `save_as_textfile()` schreiben, die Dateinamen und Inhalt annimmt (ohne den `filedialog`). Diese wäre dann unabhängig von der GUI verwendbar. Bei der jetzigen Größe deines Programms würde ich aber - wie schon von mehreren Vorrednern gesagt - alles in ein einziges Modul packen.
EDIT:
EDIT:
Code: Alles auswählen
def save_as_textfile(filename, content):
if not filename.endswith('.txt'):
filename += '.txt'
with open(filename, 'w') as textfile:
textfile.write(str(content))
-
- User
- Beiträge: 42
- Registriert: Samstag 11. Juli 2009, 16:36
sorry, wird in Zukunft gemacht!snafu hat geschrieben:Das sollte man im Moment noch dazu schreiben. IMHO ist Python 2.6 momentan die meistverwendetste Version (ich möchte mich jetzt mal nicht zu "Standard" hinreißen lassen).AntagonisT hat geschrieben:Das ist mit Python 3.1 lauffähig!
-
- User
- Beiträge: 42
- Registriert: Samstag 11. Juli 2009, 16:36
Danke, das hört sich gut an!Leonidas hat geschrieben:Richtwert: es sollte möglich sein, eine andere Oberfläche, zum Beispiel Textoberfläche oder Weboberfläche mit deinen nicht-GUI-Code zu verknüpfen. Dann hast du ordentliche Separation. Wenn aber überall in deinem Code Fenster aufgemacht werden oder eingaben entgegengenommen werden, dann ist eben alles (G)UI.
stimmt, den filedialog müsste ich natürlich noch rüber tun. Man sieht so viele Offensichtlichkeiten noch nicht, wenn man sich mit den elementarsten Dingen rumschlagen muss...snafu hat geschrieben:Um mal ein Beispiel zu nennen: Mit viel Wohlwollen könnte man eine Funktion `save_as_textfile()` schreiben, die Dateinamen und Inhalt annimmt (ohne den `filedialog`). Diese wäre dann unabhängig von der GUI verwendbar.
wie gesagt, das sollte nur ein kleines Testbeispiel sein, um erstmal ein mögliches Prinzip auszuprobieren. Das eigentliche GUI wird in etwa so ausschauen:snafu hat geschrieben:Bei der jetzigen Größe deines Programms würde ich aber - wie schon von mehreren Vorrednern gesagt - alles in ein einziges Modul packen.
EDIT:
Code: Alles auswählen
def save_as_textfile(filename, content): if not filename.endswith('.txt'): filename += '.txt' with open(filename, 'w') as textfile: textfile.write(str(content))