Das deutsche Python-Forum

@Sirius3: Mit setup.py meinst du nicht etwa die Datei, die man erstellt, um mit p2exe oder cx_freeze eine *.exe-Datei zu erzeugen? Wenn ja, diese existiert bereits, nur habe ich sie auf meinen beiden Bildern ausgeblendet, einfach deshalb, weil ich mich zunächst auf das Wesentliche konzentrieren möchte. Warum es von xarphus einmal als *.pyw, *.py und *.bat-Datei gibt? Ganz einfach. Die *.py-Datei starte ich mit meinem IDLE, um zu sehen ob irgendwelche Fehler ausgegeben werden. Die *.pyw-Datei erstellte ich, weil ich mit meiner *.bat-Datei darauf zugreifen möchte. Manchmal bin ich einfach zu faul, und dann soll es bequem und mühelos von Statten gehen. Dazu eignet sich eine *.bat-Datei hervorragend Es steckt also keine weltbewegende Philosophie dahinter.

Da ich nun deine Fragen (zufriedenstellend?) beantwortet habe, möchte ich dich was fragen. Irgendwie verwirrst du mich, wenn du sagst, dass du in dem src-Ordner keine __init__.py-Datei platzieren würdest.

Hier meine vorläufige Ordnerstruktur. Tobt euch mit Kritik aus

(Ordnerstruktur in Kürze)


(Ordnerstruktur ausgeklappt)


Zurück zu deiner Anmerkung bezüglich des src-Ordners. Wie du im zweiten Bild siehst, hatte ich vor, in diesen Ordner gui-Klassen reinzupacken. Darunter verstehe ich jene Module, die die *.ui-Datei dynamisch laden, und in welcher dann auch sämtliche Aktionen, Klicks und sonstige Einstellungen festgelegt werden. Denn snaf hat mir darauf hingewiesen, dass eine Abhängigkeit hierarchisch nach unten durchaus in Ordnung sei, nur nicht aufwärts - also von unten nach oben. Um das zu vermeiden benutze ich den src-Ordner unter anderem dafür, dass ich mit den gui-Klassen abwärts auf den Unterordner gui zugreife, um mir dort die entsprechenden *.ui-Dateien zu holen und zu laden die ich brauche. Und da sowohl xarphus.py als auch xarphus.pyw außerhalb vom src-Ordner liegen, also eine Ebene höher, so brauche ich die __init_.py-Datei. Aber womöglich habe ich dich nur etwas falsch verstanden oder wir hatten beide andere Blickwinkel.

Allgemeine Anmerkung meinerseits. Mir wird schmerzlich bewusst, wie unsauber, schlampig und undiszipliniert ich in VB6 gearbeitet habe. Das fängt schon mit der (einfachsten und grundlegendsten) Ordnerstruktur eines Projektes an. Und dieses Verhalten möchte ich (dank euch) durch das Kennenlernen von Python loswerden.

@Sophus:Paketnamen sollten genauso aussagekräftig sein wie Variablennamen. "src" ist das unter Garantie nicht. Außerdem sollte der Name möglichst eindeutig sein, um Namenskonflikte zu vermeiden. Wenn Du in allen Deinen Projekten src benutzt ist das ja auch nicht mehr gegeben. Die ui-Pythondateien sind wahrscheinlich aus Versehen aus dem gui-Verzeichnis gerutscht? Dann ist auch das ui-Präfix unnötig. Was soll denn das pp-Präfix? Oder sind die ui-Dateien etwa die .ui-Dateien, die Du händisch in ,py-Dateien umgewandelt hast?
Das test-Verzeichnis fehlt noch.

@Sirius3: Du hast mir die Frage bezüglich der setup.py-Datei nicht beantwortet Du hast vermutlich Recht, src ist vielleicht kein sinnvoller Name. Ich betrachte den src-Ordner eher als "Sammelbecken". Das heißt, dort kommen nicht nur GUI-Klassen-Module rein, sondern auch andere Module wie config.py oder settings.py etc. Auch die LICENCE und README würde ich dann in src unterbringen. Was wäre eine sinnvolle Namensgebung anstelle von src? Vorschlag? Ich dachte, ich benenne eine GUI-Klasse zum Beispiel ui_pp.update.py, damit man rein optisch - ohne dabei den Quelltext des Modules zu kennen - sofort erkennt Aaaaah haaaa, es hat irgendwas mit ui zutun.. Denn, würde ich die Datei einfach update.py benennen, so könnte man denken, es handelt sich hier um ein Modul, in denen Funktionen für das Herunterladen von Dateien sind - also Programmlogik. Es ging mir eher um den Ersten Blick. Kann ja mal passieren, dass die Datei durch das ganze Kopieren auf einmal dort ist, wo sie nicht hingehört. Und dieses pp habe ich mir aus den Fingern gezogen

Und zum Test-Ordner. Innerhalb vom src-Ordner? Aber ich muss gestehen, dass ich mit dem unittest noch nicht gearbeitet habe. Aber das hast du sicherlich erahnt.

@Sophus: Für einen aufgeräumten Namensraum ist es gut, alle Python-Dateien in ein Paket zu stecken, das so heißt, wie das Projekt. Für Sprachen, die einen extra Build-Schritt haben, ist es vielleicht sinnvoll, ein src-Verzeichnis zu haben, um es von verschiedenen Build-Verzeichnissen zu trennen. In Python ist das aber unüblich. Schau Dir doch einfach mal andere Projekte an, wie die das gemacht haben. Z.B. Django. sqlalchemy hat für meinen Geschmack z.B. ein unnötiges lib-Verzeichnis, das ja nur das Paket-Verzeichnis sqlalchemy enthält, das hätte man gut eine Ebene höher ziehen können. BeautifulSoup hat auch das Paket-Verzeichnis bs4 auf oberster Ebene, dann aber die Tests als Unterpaket. requests wieder das Paket-Verzeichnis requests auf oberster Ebene, hier die Tests sogar nur in einer einzigen Datei, auch auf oberster Ebene. Man könnte noch etliche andere Beispiele finden, wahrscheinlich in allen möglichen Varianten, die große Mehrheit benutzt aber ein System, ähnlich wie ich es beschrieben habe, weil es sich als praktisch im Alltag herausgestellt hat.

@Sirius3: Ich merke schon, ab hier treffen Geschmäcker aufeinander. Das soll nicht bewertend gemeint sein. Aber alle Python-Dateien in ein Paket stecken? Das klingt - bildlich gesprochen - wie ein unaufgeräumtes, nein, nahe zu wie ein verwüstetes Zimmer. Wenn ich eine Fremde Wohnung betrete, und sehe, dass die Regale nicht aufgeräumt sind, dass alles auf einem Haufen ist etc., dann bekomme ich tierische Kopfschmerzen. Und diese kategorische und systematische Ordnung verlange ich von mir auch in de virtuellen Welt. Wäre das nicht ein Chaos, wenn logische Module, GUI-Module und sonstige Module alle durcheinander wie aufgescheuchte Hühner in einem Paket lungern? Bestes Beispiel: Du hast ja gesehen, dass ich sogar innerhalb des Bild-Verzeichnisses weitere Ordner für die jeweilige Größe des Bildes habe. Ich kann es sonst nicht ertragen, wenn 16x16-Größen mit anderen Größen in einem Bild-Paket rumliegen. Aber ich werde mal deinen Beispiel folgen, und mir einige Projekte ansehen. Aber trotzdem habt ihr mir wirklich sehr geholfen. Ich habe endlich Struktur in meinem Projekt, und das ist schon mal ein sehr guter Start.

@Sophus:
So ganz versteh ich Dein Anliegen mit solchen Themen nicht. Deine letzte Antwort ist recht kategorisch, da hättest Du Dir eigentlich das ganze Thema sparen können. Wie Du Dein Projekt auf Dateiebene strukturierst, ist am Ende Dir überlassen. Python gibt das nicht "hart" vor.

@jerch: Nein, ich konnte durch dieses Thema einiges abgewinnen, und habe durch eure Erfahrungen meine Projekt-Struktur auch tatsächlich umgewürfelt. (Siehe Abbildungen weiter oben). Jedoch hatte ich das Gefühl, dass wir an einem Punkt gelangten, in denen nun unterschiedliche Geschmäcker aufeinander treffen - was ja auch nicht schlecht ist.

@Sophus: es gibt verschiedene Geschmäcker, mit meinen Beispielen wollte ich zeigen, dass etliche große und beliebte Projekte alle ähnlich strukturiert sind. Eine __init__.py-Datei in einem Verzeichnis das src heißt, wirst Du aber nirgends finden. Das ist schlicht und einfach ein grober Designfehler.

@Sophus:
Warum liegen die Bildressourcen unter 'src'? Das ist kein Quelltext, was 'src' eigentlich meint. Wenn Du wirklich auf der Ebene trennen willst, gehören die Bilder eher unter einen Ordner 'assets' oä.

@jerch: Auch Sirius3 hat mich darauf hingewiesen, dass src kein hinreichender Name sei. Diesbezüglich überlege ich mir noch einen Namen. Ich dachte zuerst an den Namen scripts, jedoch müssten dann die Bilder auch aus diesem Verzeichnis. Man könnte src auch einfach den Namen meines Projektes geben, aber mein Top-Level-Ordner, also der aller erste Ordner trägt ja schon den Namen meines Projektes.

Sophus hat geschrieben:Man könnte src auch einfach den Namen meines Projektes geben, aber mein Top-Level-Ordner, also der aller erste Ordner trägt ja schon den Namen meines Projektes.

Na und? Einmal ist es der Projektname (bzw Name des Repos) und einmal ist es der Paketname.

@snafu: So nach dem Motto "Doppelt hält besser"? Verzeih für mein Anfängerverhalten. Denken wir kurz von GitHub und sonstige Plattformen weg (weil du Repo angesprochen hast). Wenn ich auf mein D:\ Laufwerk gehe, sehe ich einen Ordner xarphus, also weiß ich, es handelt sich um mein Projekt. Öffne ich den Ordner, dann sehe ich nochmal den Ordner xarphus neben anderen Dateien wie LICENCE, README, DISTRIBTION etc.? Kommt mir irgendwie seltsam vor. Liegt aber auch daran, dass ich dieses "Denken" noch nicht gewohnt bin?

@Sophus:
Beim Stichwort Repo gehts hier nicht um irgendeine Quelltextplattform im Internet, sondern um Dein Repo (Das Projekt ist hoffentlich mit einem VCS Deiner Wahl versehen.) Ansonsten wurden Dir doch schon genug Bsp. genannt, von denen Du Dir Deine Struktur ableiten kannst.

Üblich für Python ist z.B. alles Projektbezogene (Lizenz, LIESMICH, Doku, Pythonpaketordner etc.) auf oberster Repoebene zusammenzuführen (Projektordner - der Name ist hier Schall und Rauch und eigentlich nur für Dich wichtig zum Wiederfinden/Identifizieren des Projektes). Die Pythonpaketordner heissen dann so, wie sie im Pythonimport auftauchen sollen (bei Dir wahrscheinlich 'xarphus', 'xarphus.core' etc.). Im besten Falle deutet der Name der Pakete/Module die Funktionalität an. Auch sollte da alles rein, was fürs korrekte Ausführen des Pythoncodes von Belang ist. Alles andere fliegt da raus. Warum? Weil Du so Distributoren das Leben leichter machst und später z.B. im Pythonpfad nur laufzeitrelevante Dateien landen. So lagern Distributoren z.B. die Doku lieber unter /usr/share/doc aus.

@jerch: Was ist ein VCS?

Sophus hat geschrieben:@jerch: Was ist ein VCS?

http://lmgtfy.com/?q=VCS+programming

@snafu: Ich verstehe, also "VCS Verkehrs-Club der Schweiz"?

Nein, habs schon verstanden, dass es Version Control System bzw. Versionsverwaltung meint. Sowas wie Github oder Bitbucket.

EDIT:
Jetzt schummelst du, snafu Du hast den google-Link schön verändert, weil dir der Verkehrs-Club der Schweiz nicht gefällt

Sophus hat geschrieben:EDIT:
Jetzt schummelst du, snafu Du hast den google-Link schön verändert, weil dir der Verkehrs-Club der Schweiz nicht gefällt

Ja, da war ich etwas zu vorlaut.

Sophus hat geschrieben:Nein, habs schon verstanden, dass es Version Control System bzw. Versionsverwaltung meint. Sowas wie Github oder Bitbucket.

Naja nicht ganz. Diese Plattformen zeigen Dir nur einen Teil dessen, was heutige VCS leisten können und haben zusätzliche Funtionalität, welche nicht aus dem zugrundeliegenden VCS kommen. Daher VCS != Github bzw. Bitbucket. Bekannte VCS sind z.B. git, mercurial, Subversion und CVS.

@Sophus: Was jerch möglicherweise sagen will: Ein VCS muss nicht zwangsläufig ins Internet gestellt werden. Ein VCS dient einfach dazu, den Fortlauf eines Projekts in einer Art Historie darzustellen, sofern man es denn entsprechend verwendet. Es zeichnet sich dadurch aus, dass alte Stände angesehen und ggf auch zurückgeholt werden können. Du kannst mithilfe von Kommentaren in einer Übersicht immer schön sehen, wann was gemacht wurde.

Ein heutiges VCS unterstützt auch mehrere Zweige. Daher kann z.B. Python 2.7 neben dem aktuellen Python 3.x entwickelt werden. Manche Neuerungen werden in beide Zweige eingespielt, andere nur in den aktuellen Zweig. Auch kleine Hobby-Projekte können davon profitieren, wenn man z.B. Zweige für experimentelle Zwecke verwenden will. Wenn das Experiment gegen die Wand gefahren wurde, dann wirft man es weg und entwickelt am Hauptzweig weiter. Wenn es erfolgreich war, führt man es mittels eines bestimmten Kommandos mit dem Hauptzweig zusammen.

Möglicherweise ist das ja auch für dich mal einen Blick wert...

@snafu und jerch: Klingt alles sehr schön und interessant. Ich habe mir schon vor längerer Zeit, als ich mich zum ersten Mal für Python interessierte ein Konto bei GitHub und Bitbucket eingerichtet. Aber wie kann man außerhalb dieser Plattform und außerhalb des Internets eine VCS betreiben? Einfach per TXT-Datei jeden Tag so eine Art Entwicklertagebuch schreiben?

In Etwa so?
01.05.2015
- Funtion XY wurde verbesser
- Function XY wurde hinzugefügt

02.05.2015
- Funktion XY wurde aufgelöst und in Klasse umgewandelt
- ...