Projektstruktur, Inkrementor und generelle Fragen

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.
Antworten
beerus
User
Beiträge: 6
Registriert: Mittwoch 21. Februar 2018, 14:27

Mittwoch 21. Februar 2018, 15:03

Hallo zusammen
Vorweg:
Ich entschuldige mich für diesen Betreff, mir ist kein anderer eingefallen.
Ich bin Python-Neuling, allerdings nicht komplett ein Programmierer-Neuling. Ich komme aus Java.
Mein Ziel war eigentlich, dass ich mir eine neue Sprache aneigne, in erster Linie- um meinen Horizont zu erweitern und wer weiss, vielleicht auch mal bei Opensurce Projekten mitzumachen.
Vielleicht ist noch hilfreich zu wissen, dass ich blind bin und auf einen Screenreader angewiesen bin.
Nun ja, bereits jetzt tun sich Fragen auf:
Zum Programmieren benutze ich die Eclipse IDE, die kenn ich gut aus Java und generell sind SWT-GUIs sehr barrierefrei. .
a) Wie sollte ich eurer Meinung nach die Projektstruktur handhaben. Wie in Java? Bei mir sieht das momentan so aus:
Projektname-->SRC(Package)-->test.py. Falls ich jetzt Unittests schreiben sollte, sollte ich danach im Projekt ein weiteres Package mit Tests erstellen?
b) Ich war schockiert, als bei mir der interpreter CodeError von sich gab, ich habe nämlich probiert eine Variable hochzuzählen mit x++.
Hat es einen expliziten Grund, wieso das Enkrementieren bei Python nicht geht?
c) An die Java-C++-Programmierer: Konntet ihr euch an die Syntax von Python gewöhnen? Sprich keine Geschweifte klammern. Das ist sehr gewöhnigsbedürftig :D
d) Meine letzte Frage: Es scheint ja kein Switch zu geben, kann ich davon ausgehen, dass Switch das gleiche ist wie elif?
Danke für eure Antworten^^
Benutzeravatar
noisefloor
User
Beiträge: 2387
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: Görgeshausen
Kontaktdaten:

Mittwoch 21. Februar 2018, 15:34

Hallo,

zu b: das musst du mal die Macher von Python Fragen ;-) Grundsätzlich braucht man sowas bei Python aber eher selten. In Python arbeitet man viel mit Iteratoren, wo man eher selten mitzählen muss. Und wenn, dann nimmt man dafür enumerate

zu c: Fehler Nr 1 wäre, wenn du versuchts, Python wie Java zu programmieren. Dann kommt ganz gruseliger Code raus. Python hat andere Idiome und ideomatisches Python sieht anders aus als Java. Z.B. brauchst du bei Python in der Regel keine Getter und Setter.

zu d: genau, switch kannst du durch elif ersetzen.

Gruß, noisefloor
beerus
User
Beiträge: 6
Registriert: Mittwoch 21. Februar 2018, 14:27

Mittwoch 21. Februar 2018, 15:40

Danke, noisefloor.
Wie hast du deineProjektstruktur aufgebaut?
Kann ich das so aufbauen, wie im 1. Beitrag (a).
Oder wird in der Pythonwelt so was nicht verwendet.
__deets__
User
Beiträge: 2841
Registriert: Mittwoch 14. Oktober 2015, 14:29

Mittwoch 21. Februar 2018, 15:43

Hallo,

ein paar antworten habe ich für dich:

Ich verzichte auch src. Da Python nicht kompiliert wird im gleichen Sinne wie Java, sondern direkt ausgeführt wird, spart man sich durch diese fehlende indirektion unnötigen Aufwand. Stattdessen habe ich üblicherweise eine Struktur mir einem Paketnamen für das Projekt, darin die Quellen, und daneben parallel eine Ordner tests. Also mal auf Zeilen gebracht:

meinprojekt/
tests/
setup.py

Die setup.py lege ich auch immer an, zusammen mit einem virtualenv kann ich dann mein Projekt mit “python setup.py develop” während der Entwicklung gut bearbeiten.

Inkrementieren geht so in Python nicht, weil zahlen immutable sind. Du kannst das x += 1 Idiom nutzen wenn du willst. Das erzeugt den neuen wert und bindet ihn an den gleichen Namen, vom Ergebnis also das gleiche, aber das alte zahl-Objekt ist unangetastet.

Ich habe auch vorher Java und C++ programmiert, letzteres ist auch wieder verstärkt angesagt. Ich halte Befürchtungen da für unbegründet.

Bezüglich des Switch hatten wir gerade eine Diskussion. Grundsätzlich hast du recht. Oft kann man aber auch mit einem dict von callables arbeiten, dann ist das kompakter und etwas mehr datengetrieben, was mir besser gefällt. Python Switch Idiom zu googeln sollte da ein paar Möglichkeiten liefern.
DasIch
User
Beiträge: 2447
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Mittwoch 21. Februar 2018, 16:07

src/ ist nicht vollkommen unnötig wie in diesem Artikel gut erklärt ist.
__deets__
User
Beiträge: 2841
Registriert: Mittwoch 14. Oktober 2015, 14:29

Mittwoch 21. Februar 2018, 16:27

Interessant. Ich hab das Problem noch nicht so ganz überrissen (krank im Bett kann man schlecht experimentieren), aber ich *glaube* mein virtualenv Ansatz bewahrt mich davor. Und tox verwende ich nicht. Aber wenn der TE eh gerne src verwendet & da auch gute Gründe bestehen - dann gerne src.
beerus
User
Beiträge: 6
Registriert: Mittwoch 21. Februar 2018, 14:27

Mittwoch 21. Februar 2018, 16:38

Danke für eure Inputs.
Ich widdme mich wieder dem Python.
Die letzte Frage:
Habt ihr eine Aufgabensamlung? Noch besser wäre ein Buch.
Ich habe da eine:
https://pythonbuch.com/aufgabensammlung.html
Aber noch mehr Aufgaben wären nicht schlecht...
narpfel
User
Beiträge: 202
Registriert: Freitag 20. Oktober 2017, 16:10

Mittwoch 21. Februar 2018, 17:00

Moin,

ich kann mich meinen Vorrednern nur anschließen.

Ad Projektstruktur: Verglichen mit Java ist es in Python nicht üblich, für jede Klasse eine neue Datei anzulegen. Und es ist unüblich, alles in eine Klasse zu stecken.

Zur Strukturierung kann es hilfreich sein, sich an einem der größeren und bekannteren Projekte auf GitHub zu orientieren. Flask zum Beispiel ist da gut geeignet. Oder für das Modell mit `src/`-Ordner das in dem Blogbeitrag angesprochene `cryptography`. Für kleine Projekte reicht oftmals auch eine einzige Datei aus.

Für Unittests empfehle ich pytest. Das `unittest`-Modul aus der Standardbibliothek ist zwar quasi ein Port von JUnit aus der Java-Welt, aber genau deswegen will man es in Python eigentlich nicht benutzen.

Ad Syntax: Ich gewöhne mich wesentlich schneller an eine neue Syntax als an den Rest einer neuen Sprache.

Als Sammlung an kleinen Aufgaben würde ich Advent of Code empfehlen. Ist ja auch schon fast wieder Weihnachten...
Antworten