Hallo!
Ich bin ganz neu in der Python-Materie. Eigelesen habe ich mich inzwischen mit "ByteOfPython" und Teilen des Galileo-Openbook, welches mir aber nicht wirklich gefällt.
Ich bastle schon an einem "größeren" Projekt und mache mir Gedanken um eine saubere Strukturierung. Vorallem das Aufteilen des Codes in verschiedene Module finde ich interessant. Da meine Kenntnisse ja nun wirklich noch nicht sehr gut sind und auch meine Stil alles andere als schön ist, dacht ich mir, einfach erstmal alle Module in einen Unterordner "dirty" zu packen, sodass ich das Projekt fertig stellen kann und später alles "clean" zu machen und in ordentliche Ordner zu verschieben. So müsste ich dann nur den Import-Pfad anpassen, oder?
Was haltet ihr generell von der Idee? Gibt es bessere Möglichkeiten?
Danke und gute Nacht!
Struktur- und Kodierungsfrage
@start_with_python: Die Frage ist IMHO nicht konkret genug. Von wievielen Modulen reden wir denn? Reicht da eventuell ein "Ordner" aus? Wenn es mehrere werden, sollte man auf jeden Fall Packages daraus machen. Den Import-Pfad sollte man IMHO gar nicht, oder wenn dann nur auf die Packagestruktur anpassen.
Wenn man ein GUI programmiert, sollte man bei größeren Projekten den GUI-Code von dem "Engine"-Code trennen. Das macht man üblicherweise mit drei Klassen "Model", "View" und "Controller".
Das sollte in den (Python-) Lehrbüchern stehen, tut's aber in der Regel leider nicht (weshalb ich schon allerhand umschreiben mußte ) ...
Gruß
Das sollte in den (Python-) Lehrbüchern stehen, tut's aber in der Regel leider nicht (weshalb ich schon allerhand umschreiben mußte ) ...
Gruß
-
- User
- Beiträge: 41
- Registriert: Samstag 20. Juni 2009, 18:12
Wie viele Module es werden weiß ich jetzt noch nicht. Ich plane aber mehere. Es wird wachsen, wachsen, wachsen, ...BlackJack hat geschrieben:Die Frage ist IMHO nicht konkret genug. Von wievielen Modulen reden wir denn? Reicht da eventuell ein "Ordner" aus? Wenn es mehrere werden, sollte man auf jeden Fall Packages daraus machen.
Du meinst mit Packeten sicher packages, oder? Ich meinte grob das gleiche, habs nur schlecht formuliert, sry. Ich will also Pakages nutzen, ja.
Das stellt mich vor ein Rätsel. Weinst du das?BlackJack hat geschrieben: Den Import-Pfad sollte man IMHO gar nicht, oder wenn dann nur auf die Packagestruktur anpassen.
Ich hätte es so gemacht
Code: Alles auswählen
import Megapacket.Dirty.Unterpacket.Modul as DasNutzeIch
import Megapacket.Dirty.Unterpacket.Modul2 as NochEinModul
import Megapacket.Unterpacket.Modul3 as SchonSauberProgrammiert
Das kommt auf meine "Bitte beachten"-Liste, sobald ich mit der Gui anfange. Aber bis dahin ist es noch ein weeeiter wegproblembär hat geschrieben:Wenn man ein GUI programmiert, sollte man bei größeren Projekten den GUI-Code von dem "Engine"-Code trennen. Das macht man üblicherweise mit drei Klassen "Model", "View" und "Controller".
Danke euch beiden schonmal!
Grüße[b]
start_with_python[/b]
Lust auf [url=https://www.dropbox.com/referrals/NTE5OTQ5Mjk5]DropBox[/url]? (RefLink)
start_with_python[/b]
Lust auf [url=https://www.dropbox.com/referrals/NTE5OTQ5Mjk5]DropBox[/url]? (RefLink)
@start_with_python: Ich meinte mit Packages in der Tat Packages. "Packete (sic!)" habe ich nicht geschrieben.
Mit Import-Pfad meinte ich den Pfad auf dem Dateisystem, in dem Python sucht. Nicht das was bei der ``import``-Anweisung angegeben wird.
Von einem "dirty"-Package halte ich nicht so viel. Das ist eine Information über den Zustand des Quelltextes und keine semantische Einteilung des Inhalts. So etwas gehört in die Dokumentation, aber IMHO nicht in die Paketstruktur. Es zerplittert die Aufteilung der Pakete und zieht Umbenennungs- bzw. Verschiebeaktionen nach sich, die nicht nötig wären.
Das war jetzt ja nur ein Beispiel von Dir, aber die Namensgebung entspricht nicht PEP8.
Mit Import-Pfad meinte ich den Pfad auf dem Dateisystem, in dem Python sucht. Nicht das was bei der ``import``-Anweisung angegeben wird.
Von einem "dirty"-Package halte ich nicht so viel. Das ist eine Information über den Zustand des Quelltextes und keine semantische Einteilung des Inhalts. So etwas gehört in die Dokumentation, aber IMHO nicht in die Paketstruktur. Es zerplittert die Aufteilung der Pakete und zieht Umbenennungs- bzw. Verschiebeaktionen nach sich, die nicht nötig wären.
Das war jetzt ja nur ein Beispiel von Dir, aber die Namensgebung entspricht nicht PEP8.
-
- User
- Beiträge: 41
- Registriert: Samstag 20. Juni 2009, 18:12
Hmm. Ok. An eine Doku habe ich nämlich bis dato auch nocht nicht gedacht. Aber das hört sich nach einer guten Idee an.BlackJack hat geschrieben: Von einem "dirty"-Package halte ich nicht so viel. Das ist eine Information über den Zustand des Quelltextes und keine semantische Einteilung des Inhalts. So etwas gehört in die Dokumentation, aber IMHO nicht in die Paketstruktur. Es zerplittert die Aufteilung der Pakete und zieht Umbenennungs- bzw. Verschiebeaktionen nach sich, die nicht nötig wären.
[wiki=PEP 8 (?ersetzung)]PEP8 [/wiki]- Warum wird man in Tutorials nicht auf soetwas hingewiesen? Finde ich klasse und werde versuchen mich daran zu halten!BlackJack hat geschrieben:PEP8.
Danke dir!
Grüße[b]
start_with_python[/b]
Lust auf [url=https://www.dropbox.com/referrals/NTE5OTQ5Mjk5]DropBox[/url]? (RefLink)
start_with_python[/b]
Lust auf [url=https://www.dropbox.com/referrals/NTE5OTQ5Mjk5]DropBox[/url]? (RefLink)
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Im offiziellen Tutorial wird man auf PEP8 hingewiesen.
Hier ist übrigens das Original
Hier ist übrigens das Original