Neuling in Python

[NoPy]

Imperative Sprachen entsprechen letztlich mehr dem gewöhnlichen Leben.
Ich sage zu meiner Frau: "Mach mir Kaffee!"

Anschließend wird dann vermutlich auch Deine Frau eine imperative Sprache bevorzugen ...

Ja, der Inhalt der Botschaft ist immer anders, aber der Typ ist bekannt

Code: Alles auswählen

function MachKaffe(const pcnTemperatur:float):TLieferung;
var 
    lvErgebnis : TAerger;
    lvnZufallszahl : integer;
begin
  lvAerger := TAerger.Create();
  lvnZufallsZahl := Random(10);
  case lvnZufallsZahl  of
    0: lvErgebnis.Set('Bitte schön', KaffeeTasse(38.2));
    1,2: lvErgebnis.Set('Bitte schön, Achtung, heiß', KaffeTasse(35+random(40));
    3,4: lvErgebnis.Set('Bitte schön!!!', KaffeTasse(20+random(10));
    5:lvErgebnis.Set('SachMa, gehts noch?', KaffeTasse(None));
    6:lvErgebnis.Set('Loof selber!', KaffeTasse(None));
    7:lvErgebnis.Set('Ich werf gleich damit!', KaffeTasse(None));
    8,9:lvErgebnis.Set('', KaffeTasse(None));
  end;
  Result := lvErgebnis;
end;

[BlackJack]

@NoPy: Was wäre denn „Glücklich wäre ich, wenn ich eine Tasse Kaffee bekommen könnte!“ für ein Programmierparadigma? Und wie entspräche eine Funktion die Kaffeepulver und Wasser übergeben bekommt und heissen Kaffee zurück gibt nicht dem ”gewöhnlichen Leben”? Zumal Programme auch dann nicht „dem gewöhnlichen“ Leben entsprechen wenn sie auch noch so sehr versuchen umgangssprachlich zu wirken, denn letztendlich stehen immer sehr formale und strikte Regeln dahinter. In die Falle tappen Anfänger ja oft wenn sie so etwas wie „if x = 'J' or 'Ja':“ schreiben.

Das bauen einer Oberfläche mit Python ist für *Dich* nicht intuitiv. In Delphi ist es das aber auch nicht. Auch da muss man es lernen. Es ist halt ein anderer Ansatz und nicht der mit dem Du angefangen hast. Zusätzlich gibt es in Python nicht ”den” Ansatz, denn eine Tk-GUI in Code zu entwerfen ist etwas anderes als eine im Qt-Designer zu entwerfen, ist etwas anderes als eine mit CSS, HTML, und JavaScript zu entwerfen. Wobei ich mich dann schon frage wo der grosse Unterschied rein bei der GUI ist wenn man Delphi und den Qt-Designer vergleicht. Man muss beim Qt-Designer später die GUI und den Code manuell verbinden, was man bei Delphi integrierter hat, aber vom Konzept ist dass doch das gleiche.

Mit ”dynamische” GUI meinte ich genau so etwas was Du beschrieben hast. Ich sehe da jetzt keine Polemik. Man braucht also Datenstrukturen die dann auf diese GUI-Elemente abgebildet werden, während der OP so wie's aussieht noch mit einem Variabennamen pro Manschafft rechnet. Wie da jetzt die Fenstergrösse ins Spiel kommt ist mir ein Rätsel.

Den Sinn der Trennung GUI/Geschäftslogik wird man hoffentlich einsehen ohne das man Komponenten austauscht, nämlich schon dann wenn man die Geschäftslogik automatisiert testet, oder auch wenn man das manuell machen möchte ohne sich dauernd durch eine GUI klicken zu müssen.

Ich habe die Erfahrung gemacht das unterschiedliche Leute sehr unterschiedlich schnell lernen, also ist so ein Wettbewerb nur aussagekräftig wenn man das mit vielen Leuten macht. Ausserdem ist die Frage was dabei am Ende heraus kommt. Jemandem Programmieren beizubringen oder wie man schnell und dreckig etwas zusammenstoppelt sind zwei unterschiedliche paar Schuhe.

Was das installieren angeht: Wenn man bei Tk für die GUI bleiben kann, dann reicht wahrscheinlich eine Python-Standardinstallation.

Das Programm ist ja nicht wirklich angegeben. Das ist nur eine sehr vage Beschreibung.

[NoPy]

@NoPy: Was wäre denn „Glücklich wäre ich, wenn ich eine Tasse Kaffee bekommen könnte!“ für ein Programmierparadigma? Und wie entspräche eine Funktion die Kaffeepulver und Wasser übergeben bekommt und heissen Kaffee zurück gibt nicht dem ”gewöhnlichen Leben”?

Du bist nicht gezwungen, jeden Witzversuch meinerseits auf die Goldwaage zu legen. Sollte hahnebüchen imperative und funktionale Programmierung gegenüberstellen, lohnt aber wirklich nicht der Diskussion.

Das bauen einer Oberfläche mit Python ist für *Dich* nicht intuitiv. In Delphi ist es das aber auch nicht. Auch da muss man es lernen. Es ist halt ein anderer Ansatz und nicht der mit dem Du angefangen hast. Zusätzlich gibt es in Python nicht ”den” Ansatz, denn eine Tk-GUI in Code zu entwerfen ist etwas anderes als eine im Qt-Designer zu entwerfen, ist etwas anderes als eine mit CSS, HTML, und JavaScript zu entwerfen. Wobei ich mich dann schon frage wo der grosse Unterschied rein bei der GUI ist wenn man Delphi und den Qt-Designer vergleicht. Man muss beim Qt-Designer später die GUI und den Code manuell verbinden, was man bei Delphi integrierter hat, aber vom Konzept ist dass doch das gleiche.

Natürlich ist es vom Konzept zumindest sehr ähnlich bis das Gleiche. Das hat auch kein Mensch bestritten. Intuitiv ist es für MICH daher, weil ich mit einem Knopfdruck die IDE starte und alles, was ich benötige, in einer Oberfläche behandeln kann. Und alles, was zu sehen ist, sehe ich (zumindest schematisch) und alle Eigenschaften, mit denen ich arbeiten kann, kann ich bearbeiten. Alle Ereignisse, die ich benutzen kann, sehe ich auch. Das ist in Delphi auch (noch) "besser" gelöst, als in Lazarus, weil ich dort einfach Fremd- oder eigene Komponenten importieren kann und diese sich in die IDE einschmiegen, ohne wie bei Lazarus alles noch einmal compilieren zu müssen.
Wenn ich es mit dem Qt- Designer machen muss, brauche ich einen Qt- Designer. Und ich muss mich um die Verknüpfung kümmern. Alles machbar, aber mit etwas größeren Einstiegshürden verbunden. Komme ich mit TK aus, sehe ich nicht, was ich tue, sondern muss alles coden. Auch nicht so intuitiv FÜR MICH.

Um das mal in einem Bild wiederzugeben: Mit Delphi/Lazarus/VC ... kaufe ich ein Auto. Das hat schon alle Schalter und Knöpfe, ich kann auf Straßen fahren, die ich sehe und in den Kofferraum packen, was ich möchte. Und wenn ich WILL, dann kann ich mich auch noch ein Autoradio einbauen.
Mit Python habe ich einen Bausatz. Da sind schon alle Schalter dabei und wenn ich das richtige Handbuch nehme, habe ich es in Windeseile zusammengesetzt und kann sogar selbst darüber bestimmen, in welcher Weise mein Katalysator funktioniert. Einzig der Blick auf die Straße ist mir erschwert, weil ich dazu noch "Frontscheibe" installieren muss, sonst sehe ich nichts. Oder ich puzzle die Frontscheibe zusammen aus den vielen kleinen durchsichtigen Chips, die auch mit im Koffer liegen. Dafür kann diese dann jede Form haben, die ich will.
Und um zu wissen ob ein Werkzeug passt, muss ich es immer erst auf die Schraube halten, denn es kann mit mehreren Schrauben funktionieren, deswegen steht es nicht dran. Wenn es nicht zur Schraube passt, bekomme ich das durch einen sanften Elektroschock mitgeteilt. Und der Werkzeugkasten ist immer TOP aufgeräumt, wäre es anders, würde nicht nur der Werkzeugkasten, sondern das ganze Auto nicht funktionieren.

Mit ”dynamische” GUI meinte ich genau so etwas was Du beschrieben hast. Ich sehe da jetzt keine Polemik. Man braucht also Datenstrukturen die dann auf diese GUI-Elemente abgebildet werden, während der OP so wie's aussieht noch mit einem Variabennamen pro Manschafft rechnet. Wie da jetzt die Fenstergrösse ins Spiel kommt ist mir ein Rätsel.

Es ist für mich nicht wirklich dynamisch, wenn Bestandteile eines Fensters bei Größenänderung des Fensters ihre eigenen Eigenschaften daran anpassen. Dynamisch ist für mich, wenn je nach internem Modell GUI- Komponenten erschaffen werden, die sich dann irgendwo einpassen. 5 Mannschaften - 5 Knöpfe, 6 Mannschaften - 6 Knöpfe. So etwas ist mit Lazarus/Delphi möglich, aber umständlich. Wenn Du Deine GUI sowieso codest, ist das egal, weil im Grunde nur das Ende der Schleife verändert wird. Auch dynamisch ist, wenn die Strukturen eines Fensters "gebrochen" werden müssen, um alles darzustellen. In meinem Beispiel müsste man evtl. die Elemte eines Tabs herauslösen und danebenstellen oder so, da die Verzerrung schon sehr groß wäre. Ginge auch, wäre auch wieder aufwändiger. Ist aber auch alles nicht der Rede wert.

Den Sinn der Trennung GUI/Geschäftslogik wird man hoffentlich einsehen ohne das man Komponenten austauscht, nämlich schon dann wenn man die Geschäftslogik automatisiert testet, oder auch wenn man das manuell machen möchte ohne sich dauernd durch eine GUI klicken zu müssen.

Ich weiß nicht, wie lange es her ist, dass Du Deine erste Programmiersprache gelernt oder gelehrt hast. Auf dem Level, wenn man lernt, was Schleifen sind, wozu man Variablen benötigt und was deren Typen bedeuten, spielen weder Testklassen noch Trennung in eine 3 oder 4- Schichten- Architektur eine Rolle. Das kommt später. Und es hat sich bei mir nie bewährt, jemandem erst alle Möglichkeiten zu zeigen und alle Paradigmen beizubringen, ehe er das erste wirklich anwenden kann. Menschen sind in der Regel visuell und wenn ich ein visuelles Problem habe, dann will ich das auch sehen und die Veränderungen daran wahrnehmen können. Und noch einmal: Mit Standard- Python sind diese Einstiegshürden höher.

Ich habe die Erfahrung gemacht das unterschiedliche Leute sehr unterschiedlich schnell lernen, also ist so ein Wettbewerb nur aussagekräftig wenn man das mit vielen Leuten macht. Ausserdem ist die Frage was dabei am Ende heraus kommt. Jemandem Programmieren beizubringen oder wie man schnell und dreckig etwas zusammenstoppelt sind zwei unterschiedliche paar Schuhe.

Natürlich. Während meines Studiums habe ich Heerscharen von Studenten anderer Fachrichtungen Programmieren beibringen müssen, weil deren Profs das nicht so vermittelt haben, dass sie es verstanden. Und ich behaupte weiterhin, dass ich einem 08/15- Studenten in 20 Stunden beibringen kann, wie er mit Lazarus eine Software schreibt, die oben genannte Funktionen erfüllt.

Was das installieren angeht: Wenn man bei Tk für die GUI bleiben kann, dann reicht wahrscheinlich eine Python-Standardinstallation.
Das Programm ist ja nicht wirklich angegeben. Das ist nur eine sehr vage Beschreibung.

Aber diese vage Beschreibung entspricht doch sehr einem Kundengespräch, oder? Der Kunde kommt, nennt sein Problem, nennt u.U. tausend Details, die zwar umgesetzt werden müssen, aber das Problem nicht verschärfen (Und der Rand soll rot sein, die Schriftart HupsBlaBla). Bei diesem Beispiel kann man doch ein "Lastenheft" für einen Prototypen mühelos erstellen. Außerdem sahen zu meiner Zeit auch Informatik- Aufgaben an Studenten so oder so ähnlich aus. Ich habe mal einen 5- Mann Beleg umgesetzt, in welchem im Grunde grob stand, dass unter Angabe des Quadratmeterpreises und der Beschreibung der Flächen die Gesamtkosten für den Fußbodenbelag auszurechnen war. Da ich diesen Text erst zum Schluss bekam und mir meine Pappenheimer nur gesagt haben, was sie wie umsetzen wollen, habe ich denen damals im Grunde eine Art CAD- System geschrieben. Als ich dann die Bewertung und damit die Aufgabenstellung sah, habe ich mir in den Hintern gebissen.

[BlackJack]

@NoPy: Ich hatte das nicht als reinen Witzversuch gesehen sondern als Argument das imperativ natürlicher ist. Mit einem nicht so trockenen Beispielsatz. Es stellt halt nicht wirklich beides gegenüber — zumindest sehe ich das funktionale im zweiten Satz nicht.

Auf dem absoluten Grundlagenlevel spielt die Trennung zwar keine Rolle, aber beim, beziehungsweise vor dem ersten Projekt in der grösse die dem OP vorschwebt, sollte es das schon. Programmlogik und Benutzerinteraktion zu trennen ist IMHO eine wichtige Grundlage die man möglichst früh lernen und umsetzen sollte. Und die auch einfach umzusetzen ist. Ist ja jetzt nicht wirklich „rocket science“.

Tests sollten da auch schon eine Rolle spielen. Mindestens mal manuelle Tests, nämlich interaktiv in einer Shell ausprobieren, was ich als eine der Stärken von Python ansehe, das man vieles einfach mal explorariv ausprobieren kann. Das ist sowohl beim Lernen als auch beim Entwickeln von Software sehr nützlich und sollte dem Lernenden geläufig sein, weil man sich so in der Regel auch durch Grundlagentutorials arbeitet. Und auch Unit-Tests sollte man früh anfangen. Das ist in Python auch nicht so umständlich wie in vielen anderen Sprachen. Doctests sind beispielsweise ein guter Einstieg, und Werkzeuge wie `nose` oder `py.test` vereinfachen auch vieles was die XUnit-API umständlich(er) macht. Gute Tests zu schreiben trainiert auch guten Produktivcode zu schreiben, weil man sich bei beidem über die Wertebereiche der Ein- und Ausgaben Gedanken machen muss, und über Randfälle nachdenkt und auch Fehlerbehandlung mal tatsächlich testet.

Mit meiner ersten Programmiersprache ist das alles nicht vergleichbar weil man sich damals um ganz andere Dinge Gedanken machen musste und es viele Werkzeuge noch gar nicht gab. Habe mit CBM-BASIC V2 und 6510-Assembler auf einem C64 angefangen.

Ich behaupte weiterhin das so eine Software die von einem 08/15-Studenten nach 20 Stunden Training zusammengeklickt wird, aus softwaretechnischer Sicht auch dementsprechend aussieht.

Die vage Beschreibung entspricht einem ersten Kundengespräch beziehungsweise der Anfrage des Kunden. Danach kann niemand ernsthaft sinnvoll mit dem Programmieren anfangen, sondern höchstens damit einen Fragenkatalog für das nächste Gespräch zu erstellen. Das könnte man schon in Form eines Gerüsts für ein Lastenheft machen, aber ich wäre mir da nicht sicher das jeder das gleiche Lastenheft erstellen würde und ob das damit am Ende auch tatsächlich das Problem des OP zufriedenstellend abdeckt. Dein Beispiel am Ende zeigt ja wie leicht man daneben liegen oder über's Ziel hinaus schiessen kann wenn die Infos nicht vollständig oder genau genug sind. Und gerade bei realen Projekten fange ich eigentlich nicht an bis ich genug gesicherte Informationen zusammen habe um einen umfangreiche unnötige Arbeit zu vermeiden.

Ich fange immer mit der Programmlogik an. GUI-Prototypen nur um die Bedienung und die Arbeitsschritte aus Kundensicht abklären zu können. Bei der Umsetzung kommt dann aber immer erst die Datenstruktur und die Programmlogik, im Idealfall auch immer schön getestet (manchmal sogar „test driven development“), bis die Operationen umgesetzt sind, und *dann* setze ich da eine GUI drauf. Und so würde ich das auch vermitteln wenn ich mich als Lehrer eignen würde. Bei umfangreichen Programmen kann man das auch in „Säulen“ machen statt komplett in „Schichten“, also Teilaspekte der Software erst als Programmlogik fertigstellen und dann die (Teil)GUI dafür drauf setzen bevor man den nächsten Aspekt umsetzt, aber grundsätzlich finde ich diese Reihenfolge sinnvoller und die führt aus meiner Sicht einfacher zu besserem test- und wartbarem Code als wenn man das anders herum angeht. Zumindest bräuchte man andersherum mehr Disziplin und Erfahrung, was Anfänger in der Regel nicht haben, eben weil sie Anfänger sind.

[NoPy]

Die vage Beschreibung entspricht einem ersten Kundengespräch beziehungsweise der Anfrage des Kunden. Danach kann niemand ernsthaft sinnvoll mit dem Programmieren anfangen, sondern höchstens damit einen Fragenkatalog für das nächste Gespräch zu erstellen. Das könnte man schon in Form eines Gerüsts für ein Lastenheft machen, aber ich wäre mir da nicht sicher das jeder das gleiche Lastenheft erstellen würde und ob das damit am Ende auch tatsächlich das Problem des OP zufriedenstellend abdeckt. Dein Beispiel am Ende zeigt ja wie leicht man daneben liegen oder über's Ziel hinaus schiessen kann wenn die Infos nicht vollständig oder genau genug sind. Und gerade bei realen Projekten fange ich eigentlich nicht an bis ich genug gesicherte Informationen zusammen habe um einen umfangreiche unnötige Arbeit zu vermeiden.

Meine Erfahrung ist, dass eben auch der Kunde visuell versteht. Daher bin ich - je nach Aufgabenstellung - schneller dabei, einen Prototypen oder einen Bericht zu bauen, als beim Lastenheft. Machen wir uns mal nichts vor, die eigentliche Geschäftslogik ist doch typischerweise trivial. Ein Benutzer X will irgend etwas eingeben. Das muss in einer Datenbasis auftauchen.
Benutzer Y will im weitesten Sinne wissen, was in seiner Datenbasis drinsteckt.
Benutzer Z will Operationen auf dieser Datenbasis laufen lassen, die irgendetwas berechnen, korrigieren oder läschen.
Der komplexere Teil sind eben gerade die Nutzerschnittstellen, also das, was er sieht. Wie sieht die Maske aus? Was kann ich von da aus alles erreichen? Wie komme ich von Feld zu Feld? Wie kann ich denn meine Katze damit abmalen? Ich will aber, dass der Name der Katze genau zwischen die Augen gemalt wird.
Ich hatte bislang eigentlich erst einmal den Fall, für einen Kunden etwas zu schreiben, bei dem der Hauptaufwand in der Logik steckte. Wir hatten sogar in Betracht gezogen, die Logik mit Prolog abzubilden, um nur das gewünschte Ergebnis beschreiben zu müssen und nicht den Weg dahin.
In allen anderen Fällen wollte er etwas triviales mit einem individuellen Benutzerzwischengesicht.

Ich fange immer mit der Programmlogik an. GUI-Prototypen nur um die Bedienung und die Arbeitsschritte aus Kundensicht abklären zu können. Bei der Umsetzung kommt dann aber immer erst die Datenstruktur und die Programmlogik, im Idealfall auch immer schön getestet (manchmal sogar „test driven development“), bis die Operationen umgesetzt sind, und *dann* setze ich da eine GUI drauf. Und so würde ich das auch vermitteln wenn ich mich als Lehrer eignen würde. Bei umfangreichen Programmen kann man das auch in „Säulen“ machen statt komplett in „Schichten“, also Teilaspekte der Software erst als Programmlogik fertigstellen und dann die (Teil)GUI dafür drauf setzen bevor man den nächsten Aspekt umsetzt, aber grundsätzlich finde ich diese Reihenfolge sinnvoller und die führt aus meiner Sicht einfacher zu besserem test- und wartbarem Code als wenn man das anders herum angeht. Zumindest bräuchte man andersherum mehr Disziplin und Erfahrung, was Anfänger in der Regel nicht haben, eben weil sie Anfänger sind.

Ich habe kein Problem damit, Schichten und Säulen als sinnvoll anzuerkennen. Aber wenn Du mit Basic und Assembler angefangen hast, hast zumindest Du keinesfalls von Anfang an in Schichten operiert, ich auch nicht. Ich will nicht sagen, dass Lernen nur über Schmerz geht, aber ehe Du nicht begriffen hast, was es Dir bringt, eine solche Unterteilung zu machen, wirst Du es auch nicht RICHTIG machen.
Und für die Aufgabe des OP ist es bei dieser Komplexität völlig Wurst, ob die reine Lehre an dieser Stelle eingehalten wird. In diesem Stadium ist es wesentlich wichtiger, dass er lernt, seine Aufgaben in Teilaufgaben zu strukturieren, Bezeichner zweckmäßig zu wählen, die Schnittstellen zwischen seinen Teilaufgaben zweckmäßig aufzubauen, mögliche Ausführungsfehler zu erkennen und gegebenenfalls abzufangen usw.
Erst, wenn er dafür ein Gefühl hat, wird er überhaupt damit umgehen können, welche Teilaufgaben in welcher Schicht und welcher Säule am besten aufgehoben ist. Man darf m.E. nicht zu viel wollen. Ich habe mit meinen Kindern angefangen, indem ich mit Lazarus ein Malprogramm gebaut habe. Zuerst kamen die Bilder und damit der Spaß und das Verständnis, danach schrittweise so etwas wie Variablen, Funktionen etc. Ich bin noch lange nicht fertig, aber der Anfang ist gemacht.
Natürlich nimmt man damit automatisch in Kauf, dass man entweder die Schichten wieder entzahnen muss, ehe man sie tauschen kann, oder noch einmal von vorn beginnt. Aber Hand aufs Herz: Dein allererstes Programm - wie oft hast Du das neu geschrieben? Zumindest wesentliche Teile davon?

[BlackJack]

@NoPy: In CBM BASIC und Assembler habe ich am Anfang nicht in Schichten und Säulen gedacht und implementiert, allerdings sind das halt auch keine Programmiersprachen in denen man heutzutage noch umfangreichere Programme schreiben möchte, eben weil man sich da noch über ganz andere Sachen Gedanken machen muss, statt sich dem Lösen des eigentlichen Problems zu widmen. Anfänger gehen heute nicht mehr bis auf diese Ebenen runter und fangen in aller Regel nicht dort an. Jedenfalls nicht wenn es um Anwendungsentwicklung geht.

Ich denke halt nicht das die Trennung in diesem Stadium für einen Anfänger Wurst ist, weil er handfeste und praktische Vorteile davon hat. Jedenfalls wenn man Software so entwickelt das man die Funktionen interaktiv ausprobiert ob sie das tun was sie sollen, oder halt auch wenn sie nicht das tun was sie sollen, zur Fehlersuche. Und es geht hier ja auch nicht um eine aufwändige oder schwierige Trennung, sondern nur darum in Funktionen/Methoden die etwas mit den Nutzerdaten anstellen keinen Code zu haben der Benutzerinteraktion erfordert. Also kein `print()` und kein `input()` beziehungsweise nicht auf GUI-Objekte zugreifen. Nichts worüber man lange nachdenken bräuchte. Das gehört zu dem von Dir erwähnten Punkt die Schnittstellen zwischen den Teilaufgaben zweckmässig aufzubauen, denn Benutzerinteraktion ist eine (eigene) Teilaufgabe.

Malprogramm ist ein schlechtes Beispiel/Gegenargument weil das sehr GUI-lastig ist und auch wesentlich stärker an das GUI-Toolkit gebunden ist als bei ”normalen” Anwendungen. Während man die Programmlogik für so eine Turnierverwaltung komplett ohne eine GUI implementieren kann, ist das bei einem Malprogramm eher nicht möglich.

Mein allererstes Programm habe ich auf Papier in BASIC geschrieben und einmal die Woche wenn ich in der Schule in den Computerraum konnte, dann auf dem Rechner abgetippt. Ich glaube komplett neu geschrieben habe ich es nie, aber in weiten Teilen umgeschrieben. War ein Textadventure in BASIC. Ist leider nicht mehr erhalten. Oder $GOTT sei Dank — wahrscheinlich kann man nicht alles was daran gruselig ist/war auf die verwendete Programmiersprache abwälzen.

[NoPy]

Ich denke halt nicht das die Trennung in diesem Stadium für einen Anfänger Wurst ist, weil er handfeste und praktische Vorteile davon hat. Jedenfalls wenn man Software so entwickelt das man die Funktionen interaktiv ausprobiert ob sie das tun was sie sollen, oder halt auch wenn sie nicht das tun was sie sollen, zur Fehlersuche. Und es geht hier ja auch nicht um eine aufwändige oder schwierige Trennung, sondern nur darum in Funktionen/Methoden die etwas mit den Nutzerdaten anstellen keinen Code zu haben der Benutzerinteraktion erfordert. Also kein `print()` und kein `input()` beziehungsweise nicht auf GUI-Objekte zugreifen. Nichts worüber man lange nachdenken bräuchte. Das gehört zu dem von Dir erwähnten Punkt die Schnittstellen zwischen den Teilaufgaben zweckmässig aufzubauen, denn Benutzerinteraktion ist eine (eigene) Teilaufgabe.

Austausch von Komponenten - nö, bleibt Wurst.
Testmöglichkeiten - vielleicht. Allerdings sind seine Komponenten doch eher schlicht, ich denke, es ginge in diesem Fall ohne, alles andere wäre mit Kanonen auf Spatzen schießen. Auch hier gilt für mich: Solange er noch lernen muss, ist das verzichtbar. Er muss erst lernen, was getestet werden muss/kann, wie Szenarien aussehen.

Malprogramm ist ein schlechtes Beispiel/Gegenargument weil das sehr GUI-lastig ist und auch wesentlich stärker an das GUI-Toolkit gebunden ist als bei ”normalen” Anwendungen. Während man die Programmlogik für so eine Turnierverwaltung komplett ohne eine GUI implementieren kann, ist das bei einem Malprogramm eher nicht möglich.

Wirklich? Das bisschen Berechnung? Im Wesentlichen muss er
1 (UI) seine Mannschaften eingeben können
2 (BL) daraus eine Spielmatrix bauen lassen
3 (BL) daraus eine Liste von Spieltagen ermitteln lassen
4 (UI) Eingabe der Ergebnisse in die Tabelle eintragen
5 (BL) Ermitteln der aktuellen Tabellenreihenfolge
6 (UI) Darstellung des Ganzen
Die Spielmatrix zu erstellen (2) ist ja nun hochgradig simpel, in python passt das wahrscheinlich in eine Zeile, konventionell sind das 2 Schleifen.
Die Liste von Spieltagen zu ermitteln (3) ist nur unwesentlich komplizierter.
Das Ermitteln der Tabellenreihenfolge (5) ist eine Fingerübung.
Da kann man mit der Oberfläche, selbst bei brauchbarem Designer schon wesentlich mehr Zeit lassen.

Mein allererstes Programm habe ich auf Papier in BASIC geschrieben und einmal die Woche wenn ich in der Schule in den Computerraum konnte, dann auf dem Rechner abgetippt. Ich glaube komplett neu geschrieben habe ich es nie, aber in weiten Teilen umgeschrieben. War ein Textadventure in BASIC. Ist leider nicht mehr erhalten. Oder $GOTT sei Dank — wahrscheinlich kann man nicht alles was daran gruselig ist/war auf die verwendete Programmiersprache abwälzen.

Von Fingerübungen abgesehen, bei denen ich mit dBase2 einen Kreis auf einen ASCII- Bildschirm gemalt habe oder einigen anderen kleineren Projekten, mit denen ich mir meine Hausaufgaben in Mathe und Physik erleichtert habe, musste ich mit sehr rudimentären Mitteln äußerst unterschiedliche Daten zu einem Bericht machen, lange, bevor es Reportgeneratoren gab. Was ich da geschrieben und verworfen habe, das war schon eine Menge.

[BlackJack]

@NoPy: Wo schrieb ich was vom Austausch von Komponenten?

Und bei Testmöglichkeiten hast Du glaube ich Schwierigkeiten Dir vorzustellen wie man in Python, und vor allem auch als Anfänger, Programme entwickeln kann, weil Du zu sehr in statischen Sprachen ohne interaktive Shell denkst. Es geht hier um das ”live” ausprobieren und herumspielen mit den eigenen Funktionen um die zu testen, kennen zu lernen, zu sehen wie sich was bei welchen Eingaben verhält. Das ist etwas wobei Anfänger viel lernen können. Und auch bei der Fehlersuche ist das nützlich. Und letztendlich auch beim schreiben von robustem Code und guten automatisierten Tests. Und Dokumentation, denn die typischen Anwendungsfälle die man in der Python-Shell für eine Funktion mal durchprobiert um sie sich selbst klarer zu machen, kann man ja auch hernehmen und in den Docstring kopieren, damit andere (oder man selbst nach ein paar Monaten) sehen können wie die Funktion verwendet wird. Und man hat dann auch schon ganz nebenbei einen automatisierbaren Test weil man den Code aus der Shell im Docstring ganz einfach testen kann ob der tatsächlich (noch) das tut was man da mal ausprobiert hat. Das sind alles wirklich keine Kanonen. Und auch eine Funktion zu schreiben die `test_irgendwas()` heisst und einen einfachen Test durchführt und mit dem ``assert``-Schlüssewort testet ist keine Kanone. Man muss in Python nicht irgendwelche komplizierten `TestCase`-Klassen ableiten und in `TestSuite`-Exemplaren zusammenfassen. *Das* wären Kanonen.

Mal die Funktion von weiter oben durch Dokumentation ergänzt:

Code: Alles auswählen

def update_points(club_a, club_b, goals_a, goals_b):
    """Update the points for the given clubs according to the goals.

    >>> club_a, club_b = Club('Parrots'), Club('Spam Fighters')
    >>> club_a.points, club_b.points
    (0, 0)

    When there is a tie, both clubs get one point.

    >>> update_points(club_a, club_b, 42, 42)
    >>> club_a.points, club_b.points
    (1, 1)

    Otherwise the winner gets three points.
    
    >>> update_points(club_a, club_b, 42, 23)
    >>> club_a.points, club_b.points
    (4, 1)
    >>> update_points(club_a, club_b, 23, 42)
    >>> club_a.points, club_b.points
    (4, 4)
    """
    if goals_a == goals_b:
        club_a.points += 1
        club_b.points += 1
    else:
        (club_a if goals_a > goals_b else club_b).points += 3

Da habe ich die Funktion einfach mal interaktiv ausprobiert und die Ein- und Ausgaben in den Docstring kopiert. Und das ist dann auch gleich ein automatisierbarer Test, denn ob zu den dort geschriebenen Eingaben auch die entsprechenden Ausgaben kommen, kann man mit dem `doctest`-Modul einfach überprüfen, beziehungsweise können Testrahmenwerke wie Nose das auch gleich als Unit-Test einbinden/auswerten. Ich sehe da keine Kanone. Test des Tests:

Code: Alles auswählen

$ nosetests --with-doctest forum4
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK

Und wenn man die Punkte für einen Sieg im Quelltext um eins verringert:

Code: Alles auswählen

$ nosetests --with-doctest forum4
F
======================================================================
FAIL: Doctest: forum4.update_points
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for forum4.update_points
  File "/home/bj/forum4.py", line 21, in update_points

----------------------------------------------------------------------
File "/home/bj/forum4.py", line 37, in forum4.update_points
Failed example:
    club_a.points, club_b.points
Expected:
    (4, 1)
Got:
    (3, 1)
----------------------------------------------------------------------
File "/home/bj/forum4.py", line 40, in forum4.update_points
Failed example:
    club_a.points, club_b.points
Expected:
    (4, 4)
Got:
    (3, 3)


----------------------------------------------------------------------
Ran 1 test in 0.024s

FAILED (failures=1)

[jerch]

@doclektor:
Mal zurück zu Deiner Frage und Bezug nehmend auf die Nebendiskussion - um die Sache "selbstprogrammiert mit eigenem GUI-Programm" zu lösen, brauchst Du einiges an Programmierkenntnissen. Und da Du die Frage in einem Pythonforum stellst, gehe ich davon aus, dass Du Python lernen möchtest und nicht etwa Pascal oder Cobol

GUIs:
Als GUI-Baukasten bringt Python Tk (Tkinter) mit. Für simple Oberflächen sind dessen Widgets idR ausreichend. Wenn es was Aufwändigeres werden soll, gibt es bindings für die GUI-Bibliotheken Qt, Gtk und WX, wobei ich Gtk unter Windows für unbrauchbar halte und persönlich eh zu Qt greifen würde. Für alle genannten haben wir auch Subsektionen im Forum, wo spezielle Fragen dazu gut aufgehoben sind.

Einstieg:
Wie sieht es denn mit Deinen Programmiererfahrungen aus? Kennst Du objektorientierte und ereignisgesteuerte Programmierung bereits? Falls nicht, ist es ein längerer Weg zum Ziel, da beides unabdingbar für die Arbeit mit GUIs ist (auch in Delphi). Dann solltest Du mit einem Einsteigertutorial beginnen, um erstmal mit der Python Syntax/Semantik warm zu werden, z.B. http://learnpythonthehardway.org/

[doclektor]

Hallo !
Ich bin dabei ein Tutorial einer Datenbank mit GUI abzuarbeiten.
Wie ich button, Eingabefelder Labels und Listenfelder mache ist mir schon einigermaßen klar.

Auch habe ich gelernt wie man Daten aus der Datenbank einließt und auch schreibt und anhängt.
Über GUI Daten Löschen, Daten Eingeben Daten Ändern alles dabei.

Ich weiß halt noch nicht wie man richtig anfängt.

Es wird mit einer Sql Datenbank gearbeitet, kann ich das auch für mein Projekt anwenden?.

Die Diskussion auf meine Frage macht mir Sorgen das hier einige Böse auf mich sind. :K

[BlackJack]

@doclektor: Keine Sorge, hier ist niemand böse auf Dich.

Klar kann man eine relationale Datenbank für die Datenhaltung für Dein Projekt verwenden. Das ist neben den Python-Grundlagen, Objektorientierung, und ereignisbasierter Programmierung für die GUI allerdings ein weiteres, relativ komplexes Feld mit einer eigenen Abfragesprache die man lernen muss. Wenn man die Daten im Programm als Objekte modelliert, bietet sich hier eine entsprechende Bibliothek an die das relationale Modell auf Objekte abbildet → „Object Relational Mapper“ (ORM). Recht weit verbreitet ist da bei Python die SQLAlchemy-Bibliothek, die ich persönlich fast immer als Abstraktionsschicht für den Datenbankzugriff verwende, auch wenn ich kein ORM brauche.

[NoPy]

@doclektor: Auf Dich ist hier niemand böse, höchstens auf mich. Und selbst da kommen weniger Steine, als erwartet
@BlackJack:
Sicher muss ich noch einiges lernen, beispielsweise ist mir der Zweck und die Anwendung von doc- Strings noch nicht klar.
Das man bei Tests etwas einfacher hantieren kann, als mit anderen Umgebungen, ist mir bewusst. Das wiegt für mich persönlich aber NOCH nicht die Vorteile auf, die ICH PERSÖNLICH bei einer echten IDE hatte (Syntax- Kontrolle, Typsicherheit), denn in python habe ich halt mehr Testszenarien. Wenn ich eine allgemeine Funktion

Code: Alles auswählen

def a(b):
    pass

schreibe, weiß ich in der Funktion erst einmal nicht, was als b alles ankommt. Ergo muss ich dazu auch noch Tests fahren.
Dazu kommt, dass triviale Tests (zählt er wirklich hoch, wenn ich das sage?) erst für automatisierte Tests eine Rolle spielen, denn was ich gerade gemacht habe, weiß ich in der Regel. Die eigentlichen Testszenarien sind nun mal komplexer: (Wenn nach dem Buchen des Sitzpplatzes und des Gepäckes und dem Zahlvorgang der Flieger storniert wurde, geht dann auch das Geld zurück? - Mag sein, dass sich das in python auch einfacher formulieren lässt, als in anderen Umgebungen, aber wie gesagt, ein Gefühl für das richtige Strukturieren von python- Code habe ich noch nicht entwickelt. Gemessen an den Projekten, die ich bislang außerhalb von python gefertigt habe, stümpere ich noch herum. Ich benötige für die Erstfertigung eines Moduls ca. 3 mal so lange, wie sonst. Und um dieses Modul ein halbes Jahr später um Kleinigkeiten zu erweitern und das fehlerfrei zu lauffähig zu bekommen, benötige ich gefühlt noch länger)

Aber ich bin ja hier, um zu lernen, nicht wahr?
Meine aktuellen Stichworte sind Docstrings, ORM, SQLAlchemie

[Hyperion]

@NoPy: Bei Unit Tests (und automatisierten Tests i.A.) ist es nicht wesentlich, ob Du "gerade noch weißt", was der Code macht und auch nicht, ob das etwas kompliziertes ist! Es geht insbesondere um die Absicherung, dass Dinge auch nach (späteren) Änderungen oder Erweiterungen des Programms noch funktionieren.

Auch vermeintlich kleine und einfache Dinge können das Ergebnis stark beeinflussen - das wissen wir alle spätestens seit Jurassic Park

[NoPy]

@NoPy: Bei Unit Tests (und automatisierten Tests i.A.) ist es nicht wesentlich, ob Du "gerade noch weißt", was der Code macht und auch nicht, ob das etwas kompliziertes ist! Es geht insbesondere um die Absicherung, dass Dinge auch nach (späteren) Änderungen oder Erweiterungen des Programms noch funktionieren.

Auch vermeintlich kleine und einfache Dinge können das Ergebnis stark beeinflussen - das wissen wir alle spätestens seit Jurassic Park

Genau das habe ich gemeint

[doclektor]

Hallo,

kann mir jemand sagen wo der fehler liegt

Code: Alles auswählen

if s > t:
    (x) =+3
elif t > s:
    (y) =+3
elif s == t:
    (x)+1,(y)+1
print (x)
print (y)

Die + 3 rechnet er jeweils richtig auf.
s == t gibt er mir jeweils nur 0 0 aus anstatt 1 1
Bin am üben habe schon mehrere Variationen probiert.

Läuft ohne Fehlermeldung durch, aber halt das Ergebnis o ist falsch.

Danke

[pillmuncher]

Setz bitte Code in Codetags. Sonst kann man es nicht lesen.

Code: Alles auswählen

if s > t:
    (x) =+3
elif t > s:
    (y) =+3
elif s == t:
    (x)+1,(y)+1
print (x)
print (y)

Die + 3 rechnet er jeweils richtig auf.

Nein, tut "er" nicht. Dazu unten mehr.

Warum schreibst du x und y in Klammern? Das meinst du, bewirkt das?

Außerdem ist += nicht dasselbe wie =+:

Code: Alles auswählen

In [1]: x = 5

In [2]: x + 3
Out[2]: 8

In [3]: x
Out[3]: 5

In [4]: x =+ 3

In [5]: x
Out[5]: 3

In [6]: x += 4

In [7]: x
Out[7]: 7

bla =+ blub ist dasselbe wie bla = (+blub). += ist ein Operator, = + sind zwei.

[BlackJack]

@doclektor: Wenn `t` und `s` gleich sind veränderst Du weder `x` noch `y`. Du erstellst ein Tupel mit den Werten von `x` und `y` jeweils plus 1 und das wars. Mit dem Tupel wird dann nichts gemacht, es wird also einfach wieder verworfen und keinen sichtbaren Effekt.

[NoPy]

Code: Alles auswählen

if s > t: #das macht das, was Du erwartest
    x += 3 #(x) =+3 ist gleichbedeutend mit x = 3
elif t > s: #das macht das, was Du erwartest
    y += 3 #siehe oben
elif s == t: #das macht das, was Du erwartest
   x += 1
   y += 1  #(x)+1,(y)+1 erzeugt ein Tupel aus 2 Werten, die um je 1 größer sind, als x und y
print (x) #macht in etwa, was Du erwartest. Mit den Klammern erreichst Du, dass nicht etwa eine Zahl zurückgegeben wird, sondern ein Tupel mit einer Zahl
print (y)

[/me]

print (x) #macht in etwa, was Du erwartest. Mit den Klammern erreichst Du, dass nicht etwa eine Zahl zurückgegeben wird, sondern ein Tupel mit einer Zahl

Das ist falsch. Ein Tupel wird nicht durch die Klammern, sondern durch ein Komma definiert.

Code: Alles auswählen

>>> x = (1)
>>> x
1
>>> type(x)
<class 'int'>
>>> y = 1,
>>> y
(1,)
>>> type(y)
<class 'tuple'>

[bwbg]

Ergänzend hierzu:

Code: Alles auswählen

>>> ()
()
>>> type(())
<class 'tuple'>

Hier bildet () ein leeres Tupel.