Das deutsche Python-Forum

@hyperion: Das ist zu sehr vereinfacht
@sirius: geht klar
@BlackJack:
Nein, Du drehst mir die Worte im Mund um. Wenn ich vor einer Aufgabe stehe, werde ich sie lösen. Ob ich über den Sinn der Aufgabe zu befinden habe, hängt vom Aufgabensteller ab.
Wenn ich eine Frage nach dem WIE stelle und diese beantwortet bekomme mit einem WARUM, dann kann ich in der Regel nichts lernen bzw. die Anzahl meiner Möglichkeiten/Fertigkeiten wird nicht größer.

Es wäre schon leichter, wenn python nicht so religiös gesehen werden würde. "Fragen stellen" wird dann zu oft mit "In Frage stellen" verwechselt. Natürlich kommen manche Menschen zu python, die Erfahrungen mit anderen Programmiersprachen gemacht haben. Und auch ihr habt keine Zeit, komplette Konzepte zu liefern. Ich sitze beispielsweise seit 2 Wochenenden an einem python- Projekt, wo es mir mörderisch auf die Füße fällt, dass python ist wie es ist (speziell das mit der Typ- Bindung an den Inhalt und nicht an den Namen). Meine Familie hätte die Zeit gern mit mir verbracht.
Und es ist dann nicht wirklich zielführend, wenn dann jedes mühsam errungene Puzzleteil ob seiner Relevanz in Frage gestellt wird. Sicher, wenn ich Euer Wissen hätte, wäre das Problem wahrscheinlich schon lange gelöst, habe ich aber nicht. Ich muss mir also einen Weg suchen zwischen meinem vorhandenen und dem zu erlernenden neuen Wissen.

NoPy hat geschrieben:@hyperion: Das ist zu sehr vereinfacht

Inwiefern? Letztlich macht Sirius3 das doch ganz genauso, nämlich mit ``len`` auf einer Sammlung. Genauso würde ich das auch in C++, Java, C# oder Clojure lösen. Dass man irgend eine Art "Repository" als Zugriffsschicht auf seine Objekte hat, sollte wohl klar sein.

NoPy hat geschrieben: Nein, Du drehst mir die Worte im Mund um. Wenn ich vor einer Aufgabe stehe, werde ich sie lösen. Ob ich über den Sinn der Aufgabe zu befinden habe, hängt vom Aufgabensteller ab.

Manchmal ist die Lösung aber auch zu sagen: "Das ist nicht lösbar!". Und nicht wissende Entscheider bzw. Weisungsbefugte sind idR. dankbar dafür, wenn man Ihnen vermittelt, wieso das gewünschte unsinnig ist und man ggf. sogar einen Vorschlag machen kann, *was* diese eigentlich haben wollen.

@NoPy: Erster Schritt eine Aufgabe zu lösen, ist die Aufgabenstellung zu verstehen. Zu mir sind schon viele gekommen, mit ganz konkreten Problemen und sind mit viel mehr Fragen wieder gegangen. Aber eine einfache Lösung wäre eben nur eine Scheinlösung gewesen, mit der niemand glücklich geworden wäre. Deshalb ist es oft nötig, nach den Hintergründen zu fragen. Hat der Fragesteller alle Nebenbedingungen im Blick, die jemandem mit mehr Erfahrung sofort auffallen. Wie sieht es mit Fehlertoleranz, Erweiterbarkeit und Wiederverwendbarkeit aus?
Es ist wahr, dass viele im Forum nach Perfektion streben. Ich selbst wäre nicht so aktiv, wenn ich nicht auch versuchen würde, Python immer besser zu beherrschen. Das hat nichts mit Religion zu tun, sondern mit Best-Practice: wie gehe ich ein Problem generell an. Und dann ist es natürlich, dass Fragen nach anderen Blickwinkeln gestellt werden.

Ich verstehe meine Aufgabenstellung(en). Nur ist nicht immer in wenigen Worten das Gesamtsystem erklärt, so dass man für Details Lösungsansätze sucht, die u.U. unerwähnte Randbedingungen enthalten. Und dann nützen WARUM- Fragen eben nicht viel, sondern es kommt auf WIE- Antworten an.

Und in diesem Beispiel war die Frage, wie man Instanzen zählt.
Bisheriger Ansatz: Konstruktor- Destruktor
Aufgezählte Grenzen: Keine Kontrolle über Destruktor
passender Lösungsansatz: Alle Objekte, die solche Objekte enthalten, dazu bringen, diese Objekte herauszugeben und in einem Set zu speichern, anschließend alle Objekte im Set zählen.

Ist doch in Ordnung, wie bringt mich die Frage nach dem WARUM weiter?

Also keine Angst, ich bin mit dem Ergebnis zufrieden und über die Jahre werde ich wahrscheinlich auch python in angemessenem Umfang verstehen lernen. Aber das geht - zumindest bei mir - nicht ad hoc.
Und ganz ehrlich, alles, was ich an Tutorials gelesen habe, beschreibt zwar die Mittel, die man hat (und die style- Guides, auch wenn ich nicht alles als wirklich gut empfinde), aber kaum die Lösungsansätze für komplexere Szenarien - geht ja auch gar nicht. Also muss man Fragen nach Details stellen und diese nach und nach zusammensetzen und wenn man vom Großen und Ganzen mehr verstanden hat, findet man python- mäßigere Wege. Einen anderen Weg sehe ich für mich nicht.

@NoPy: Das Problem bei dem Instanzen zählen ist doch das *wir* die Aufgabenstellung nicht kennen. Das fällt doch nicht so einfach vom Himmel sondern muss doch irgend einen Sinn haben. Den man vielleicht anders viel einfacher erreichen kann ohne das konkrete Subproblem „Instanzen zählen” lösen zu müssen. Dazu müsste man aber das *eigentliche* Problem kennen was gelöst werden soll und nicht nur das was Du als Lösung ansiehst. An der Stelle vermuten dann viele ein XY-Problem und hätten die Problemstellung ganz gerne mal als Text ohne konkreten Lösungsansatz gehört, bevor man sich an etwas aufhält was letztendlich gar keine gute Lösung ist.

Bei Dir habe ich auch ein bisschen das Gefühl dass Du solche Probleme hast weil Du nicht mit der Sprache sondern gegen die Sprache programmierst, in dem Du Wissen und Lösungen aus anderen Sprachen versuchst in Python umzusetzen. An genau der Stelle macht es dann schon Sinn zu fragen *was* Du eigentlich machen willst statt Dir dabei zu ”helfen” wie man das möglicherweise „unpythonisch” umsetzt. Und natürlich werden dadurch dann auch Deine Möglichkeiten und Fertigkeiten grösser wenn Du dabei lernst wie man etwas in Python *idiomatisch* löst.

Du hast hier soweit ich das sehe noch nie nach einem konkreten Problem mit echtem Quelltext gefragt, sondern immer nur nach konstruierten Beispielen, die in der Regel irgendwie komisch und praxisfremd waren.

Noch mal kurz am Rande: Imho stellen solche "statischen" Zähler, wie Du sie offenbar gerne verwendest, eine Verletzung des SRP dar! Das Wissen um die Anzahl an Instanzen ist definitiv ein Cross Cutting Concern, der nichts im Objekt selber zu suchen hat.

Das Problem bei dem Instanzen zählen ist doch das *wir* die Aufgabenstellung nicht kennen.

eben

Das fällt doch nicht so einfach vom Himmel sondern muss doch irgend einen Sinn haben. Den man vielleicht anders viel einfacher erreichen kann ohne das konkrete Subproblem „Instanzen zählen” lösen zu müssen.

Vielleicht

Dazu müsste man aber das *eigentliche* Problem kennen was gelöst werden soll und nicht nur das was Du als Lösung ansiehst. An der Stelle vermuten dann viele ein XY-Problem und hätten die Problemstellung ganz gerne mal als Text ohne konkreten Lösungsansatz gehört, bevor man sich an etwas aufhält was letztendlich gar keine gute Lösung ist.

Nun ja´, ein wenig Arbeit kannst Du mir schon auch noch überlassen
Nein, im Ernst: Geh mal davon aus, dass man auch komplexere Probleme haben kann, für die so etwas nur ein Teilproblem sein könnte. Und mein aktuelles Problem wüsste ich gar nicht zu schildern in wenigen Worten, ich werde im Januar dazu einen Vortrag halten (vor Leuten, die sich mit der Materie schon auskennen) und das wird schon kompliziert.

Bei Dir habe ich auch ein bisschen das Gefühl dass Du solche Probleme hast weil Du nicht mit der Sprache sondern gegen die Sprache programmierst, in dem Du Wissen und Lösungen aus anderen Sprachen versuchst in Python umzusetzen.

Das ist schon möglich, aber nicht zu ändern. Du hast auch erst laufen gelernt, ehe Du Weitsprung gemacht hast.

An genau der Stelle macht es dann schon Sinn zu fragen *was* Du eigentlich machen willst statt Dir dabei zu ”helfen” wie man das möglicherweise „unpythonisch” umsetzt. Und natürlich werden dadurch dann auch Deine Möglichkeiten und Fertigkeiten grösser wenn Du dabei lernst wie man etwas in Python *idiomatisch* löst.

Immer noch vorausgesetzt, dass sich das Problem wirklich so leicht erklären lässt. Wir beide werden wohl damit leben müssen, dass ich - zumindest am Anfang, bis mir die Zusammenänge klarer sind - "unpythonische" Lösungen entwickeln werde, python quasi vergewaltige. Das Dilemma: Ich kann Dir nicht in einem Rutsch das Fachwissen übertragen und Du mir nicht in einem Rutsch Deine python- Kenntnisse. Daher sehen wir immer nur Ausschnitte und können auch nur mit diesen umgehen.

Du hast hier soweit ich das sehe noch nie nach einem konkreten Problem mit echtem Quelltext gefragt, sondern immer nur nach konstruierten Beispielen, die in der Regel irgendwie komisch und praxisfremd waren.

Ja, weil mich die "pythonmäßigste" Lösung interessiert hat. Für wie relevant Du das Problem hältst, ist damit zweitrangig. Und Du wirst Dich vielleicht wundern: Der Lösungsansatz hat mir durchaus "Inspiration" für andere Problemstellungen gegeben (wie auch die an sich triviale Sache mit der formatierten Textdarstellung von Sekunden).

@NoPy: Wenn Du das Problem nicht schildern kannst, dann kann man halt auch nicht bei einer Lösung helfen. Und wenn ich so etwas eigenartiges wie das Instanzen zählen als Lösung sehe bei der ich helfen soll sie umzusetzen, dann *muss* ich einfach nachfragen *wofür* das eine Lösung sein soll. Denn das kann in Python keine robuste Lösung für irgendwas sein¹. Falls doch, dann würde ich das gerne wissen, denn dann würde ich was dazulernen. Und auch in anderen Sprachen nicht, denn die Probleme die sich dabei ergeben, haben ja nicht nur mit der automatischen Speicherverwaltung zu tun. Man müsste sonst Annahmen treffen die sehr leicht mal verletzt werden können. Und das Entwurfsproblem so eines globalen Zählers ist auch unabhängig von der Sprache.

¹ Ein Einsatzzweck würde mir schon einfallen, aber der bezieht sich nicht auf normale Programme und insbesondere nicht auf Produktionscode.

BlackJack hat geschrieben:¹ Ein Einsatzzweck würde mir schon einfallen, aber der bezieht sich nicht auf normale Programme und insbesondere nicht auf Produktionscode.

Ich vermute, wir haben da Ähnliches im Sinn. Im Moment ist es so, dass ich stark fehlerbehafteten Code entwickle, einfach deshalb, weil ich mit python noch nicht so gut zurecht komme. Und in solchen Fällen hat es sich in meiner Vergangenheit als praktisch erwiesen, gewisse Statusinformationen mitzuführen, um leichter zu erkennen, wenn etwas aus dem Ruder läuft.
Beispielsweise habe ich in allen möglichen Funktionen Schleifenzähler drin, um zu sehen, ob eine Schleife tatsächlich nur wenige Male durchlaufen wird, wie ich es beabsichtige oder ob ich mir da was Fehlerhaftes eingebaut habe. Der Debugger hilft mir leider nicht so gut, wie ich es gebrauchen könnte, weil es für das System keine "simplen" Testszenarien gibt, sondern ich immer gleich mit Hunderten von Objekten kämpfen muss. Aber ich mach mal einen neuen Thread auf, vielleicht sorgt das für Inspiration.

Ich muss da nopy aber auch zustimmen: In vielen Fällen werden in solchen Tutorials halt auch Sachen vermittelt, dessen Sinn man zu dem Zeitpunkt noch gar nicht einordnen kann, die aber nichtsdestotrotz sinnvoll sind. Von einigen Sachen sollte man zumindest schon einmal grundlegend etwas gehört haben oder sie auch vielleicht schon einmal kurz eingesetzt haben.

Wenn dann nämlich mal der Zeitpunkt kommt, wo man es einsetzen muss, dann hat man es zumindest noch grob im Hinterkopf.

Dass manche Sachen dann im normalen Gebrauch eher nicht zu verwenden sind ist wieder eine andere Sache, aber da sollte man zumindest mal eine Warnung gehört haben. Ich habe zwar __del__ auch noch nie verwendet, aber ich finde es trotzdem sinnvoll, das mal gehört zu haben und auch zu wissen, was da überhaupt passiert. Auch um einfach die Hintergründe zu verstehen. Ob das direkt ganz am Anfang eingeführt werden soll ist wieder eine andere Frage, aber konzeptionell finde ich das schon nützlich.

@Hellstorm: Bei `__del__()` wird in den „schlechten” Tutorials ja aber gerade *nicht* erzählt was da passiert, sondern gefährlicher Unsinn und ohne irgendwelche Warnungen welche Garantien (nicht) gegeben werden und was das noch für Folgen haben kann (Speicherlecks). Bis Anfänger mal über ein Problem stolpern wo man tatsächlich `__del__()` sinnvoll verwenden kann, sind sie normalerweise keine Anfänger mehr, und viele werden sogar niemals über so ein Problem stolpern. Warum also Anfänger damit belasten. Das ist IMHO etwas ganz anderes als Anfänger mit einem „das wirst Du später verstehen” abzuspeisen bei Sachen die tatsächlich regelmässig in normalen Programmen zur Anwendung kommen.

Das was man statt `__del__()` häufig verwendet, nämlich Kontextmanager, kommt in Anfängertutorials dagegen sehr selten vor. Mir ist so aus dem Kopf gar keines bekannt. Und für den Zweck *wo* `__del__()` wohl am meisten sinnvoll angewendet wird, nämlich *soweit es halt geht* ”manuelle” Verwaltung von Ressourcen von denen die Python-Laufzeitumgebung nichts weiss, ist Speicherverwaltung bei der Anbindung von externen Bibliotheken mittels `ctypes`. Da muss man dann aber die Speicherverwaltung von Python *und* C ziemlich gut kennen. Trifft auf Anfänger nicht zu.

Moin Leute,

leicht verspätet, dafür aber ausführlicher, hier nun meine Antworten...

@ BlackJack
1): Ja, mit der eigentlichen Funktion(-sweise) der __init__ und der OOP im Allgemeinen habe ich mich wohl offensichtlich wirklich noch nicht so gut angefreundet...
Daher stelle ich das Thema OOP / Klassen auch erst einmal zurück, und beschäftige mich damit demnächst dann wieder irgendwann, dann allerdings auch von vorne mit kleinen Beispielen/Tuts, Fragen & co.
2): In dem Fall war die Klassenprogrammierung für mich ein Selbstzweck zum Einüben in die OOP, jedoch leicht unsinnig.
Für die OOP muss ich wahrscheinlich nochmal ganz von vorne anfangen und mir entsprechend diverse Tuts/Beiträge/Beispiele anschauen und selber umsetzen.
"for i in range(1)" - HUST! Kein Kommentar.
Ich denke, in dem try/except-Block sollte, wenn das der für das Laden der Sounddateien zuständige war, evtl. eine Runtime-Error-Ausnahme kommen. Weiß ich nicht. Muss ich mich nochmal mit beschäftigen, welche es alles gibt bzw. wie die kategorisiert sind.
Praktisch sollte ein evtl. nicht-laden der Dateien abgefangen werden, so dass das Programm notfalls auch ohne Sound fortfahren könnte. Ob mir dies logisch gelungen ist, weiß ich nicht. Laufen tut das Programm/Skript aber auch ohne die Dateien. Naja...wie gesagt, ist noch viel zu lernen!
Ist so abgespeichert - in Zukunft werden Ausnahmebehandlungen konkretisiert.
"sys.exit" werde ich versuchen zu meiden und mit einem break irgendwie, irgendwo die Hauptschleife in "if name == main" zu unterbrechen, müsste eigentlich machbar sein.


@ /me: Ja, das hatte mich auch gewundert, wieso das ganze nur so halb funktionierte. Ich stimme mit Dir voll und ganz überein (s.o.) und verschiebe den ganzen Komplex "OOP" erstmal etwas nach hinten.
Ich arbeite bzw. lerne mit dem Buch "Python für Einsteiger" von Thomas Theis (Galileo Comp.). Eigentlich ein, wie ich finde, sehr einfach erklärendes Buch. Leider ist - mMn - der Teil über die OOP zu kurz gekommen...aber gut, das Buch soll ja auch nur die Grundzüge der OOP / Python allg. darlegen. Für weitergehende Literatur gibts sicher noch weitere Bücher.
Wie gesagt, ist das Thema OOP bei mir nun erstmal nach hinten gerückt.
Als erstes möchte ich mein kleines Spielchen zu einem (vorläufigen...) Ende bringen, sprich: es soll (soweit...) sauber programmiert sein und funktionieren, dafür braucht es tatsächlich keine Klasse und ihre Instanzen, über einfache Funktionen lief es vorher auch wunderbar und ist unkomplizierter und für mich mit Sicherheit sauberer zu programmieren.
Darauf wird also erstmal mein Hauptaugenmerk liegen.


@ Sirius3: Danke für deine Hinweise! Ich habe mich gestern Abend schonmal drangesetzt und die reading()-Funktion umgearbeitet und deine Tipps umgesetzt.
Im letzten Teil entscheidet sich nun, ob die Ausgabe der nächsten Zeile 0.1 Sekunden oder 1.6 Sekunden lang auf sich warten lässt. Jede Code-Zeile kommt folglich nur noch einmal vor und die txt-Datei öffne ich gleich direkt mit "with open" und, soweit ich das nun mal zu behaupten wagen kann, "iteriere ich auch gleich über das Objekt"...*hust* (falls man das so sagt? Die Zeilen werden dennoch gesplittet, vielleicht habe ich da also auch was falsch verstanden...ich schicke dann alles nochmal gemeinsam hoch)
Das mit dem unleserlichen Code kann ich noch nachvollziehen, zu komplex finde ich den jedoch nicht. Liegt allerdings wahrscheinlich daran, dass ich ihn selber geschrieben habe und mir andere Codes viel komplexer vorkommen.
Dennoch nehme ich deinen Hinweis sehr gerne an und werde versuchen, den Code kürzer zu gestalten bzw. mit " ``` " statt mit " \ " zu arbeiten, sofern das nötig werden sollte.
Bei der Funktion "bisection()" habe ich gestern Abend schon die Variablen "obergrenze" / "untergrenze" in "right" / "left" umgeändert, da der Code so nun auch in eine Zeile passt.


@ HarteWare: Danke für den Link !! Sowas habe ich gesucht! Irgendwie habe ich bisher nur komisch abstrakte Abhandlungen & Meinungen oder - für mich - ziemlich komische Beispiele zur OOP und Klassen gefunden. Da wird das alles recht anschaulich erklärt - TOP !
Ich hab einfach ab Kapitel 3 oder 4 (?) kurz angefangen reinzulesen, und bis Kapitel 8 auch alles verstanden. Tolle Sache auch mit den DocStrings - die hab gestern Abend gleich in reading() und bisection() eingebaut - bisher fand ich alles Klasse erklärt!


Allgemein vielleicht noch kurz erwähnt: Ich hab mir die NINJA-IDE installiert.
Ich finde geany zwar übersichtlicher, und irgendwie wohl auch "leichter" / schneller, finde aber gut, dass der mir die ganzen Fehler gleich mit ausgibt, ebenso wie die PEP8-Hinweise. Über manches hab ich mich zwar auch gewundert, z.B. dass es meint, ich solle div. Formeln statt in "a = range(int(b, b-a))" folgendermaßen "a = list(range(int(a, b-a)))" schreiben, weil der Code vorher auch funktioniert hat, aber es scheint zu funktionieren.
Ich finde, dass ganze ist jedenfalls eine gute Unterstützung, um den Code gleich von Anfang an "etwas richtiger" zu gestalten.


So. Das wars dann auch erstmal von mir

Grüße
BSA

@BSA: Ich kenne Ninja-IDE nur vom Namen. Bei dem Hinweis mit dem zusätzlichen `list()` solltest Du eventuell mal nachforschen *warum* Dir der gegeben wird. Das klingt nach einem Hinweis um Python 2 Quelltext nach Python 3 zu portieren. Falls Du schon Python 3 verwendest macht das keinen Sinn, ansonsten könnte man an der Stelle `xrange()` statt `range()` verwenden wenn es auch ohne das `list()` funktioniert.

Und man muss immer im Hinterkopf behalten, dass manchmal auch falsche Hinweise kommen wenn die Prüfung entweder etwas nicht richtig interpretieren konnte, oder etwas falsch interpretiert. Wenn die Ninja-IDE zum Beispiel Pylinter integriert bekommt man bei so etwas hier Hinweise auf nicht konforme Namen bei `Point` und `get_first`, ganz einfach weil nicht erkannt wird dass es sich um einen Datentyp und eine Funktion handelt, wofür die Namen jeweils den Konventionen entsprechen: Man darf also nicht blind jedem Hinweis folgen. Sollte aber über alle nachdenken.

Kann gut sein! Ich bin zwar grad an einem andern Rechner, werd mir das aber zuhause noch mal genauer anschauen. Danke für den Hinweis!
Ich hatte auch irgendetwas von Py2to3 gelesen, wusste nur nicht, dass die Funktion (anscheinend...) "an" ist. Hatte sie in den Präferenzen eigentlich auch aus logischen Gründen nicht extra eingeschaltet...
Das mit Pylinter und den drei Funktionen aus den jeweils drei Modulen hab ich jetzt zwar ehrlich gesagt nicht verstanden, und auch sagen mir die Module alle nichts, aber auf GitHub hab ich kurz was mit Sublime2/3-Text bzgl. Pylinter gelesen. Die andern drei werd ich mir mal bei Zeiten auch noch anschauen, wozu die da sind.

Ich werd das list() also nachher wieder ausbauen. Und in Zukunft versuchen darauf zu achten, warum Ninja mir dies oder jenes eigentlich genau vorschlägt...

Grüße
BSA

@BSA: Pylinter ist ein Programm welches Python-Quelltext statisch analysiert und Warnungen generiert wenn gegen Konventionen verstossen wird, bei Fehlern die es erkennt und auch bei einiges Sachen die zumindest komisch sind. Zum Beispiel wenn man ein Funktionsargument innerhalb einer Funktion nicht verwendet, oder wenn man einem lokalen Namen etwas zuweist und den dann nicht verwendet. Das wird von den vielen IDEs für Python unterstützt, beziehungsweise verwendet um so etwas im Editor dann anzuzeigen. Kann man auch als alleinstehendes Programm benutzen. Für Sublime Text gibt es ein Plugin das jedes mal beim Speichern vom Quelltext eine Prüfung laufen lässt.

Der Punkt bei dem Beispielquelltext ist, dass `namedtuple()` eine Klasse als Ergebnis liefert und `partial()` eine Funktion. Das bekommt Pylinter aber nicht mit und meckert, dass die Namen `Point` und `get_first` nicht der Konvention für Konstanten entsprechen, weil die halt nicht mit ``class`` und ``def`` zustande gekommen sind.

Edit: Wobei mir gerade auffällt das `get_first` falsch definiert ist, das müsste nur ``get_first = itemgetter(0)`` heissen. Und für `itemgetter()` gilt aber was ich für `partial()` gesagt habe: das liefert als Ergebnis eine Funktion.

@NoPy:
Ich versuche mal, mit einem zugebenermaßen skurrilen Bsp. das WARUM zu beleuchten:

Ein Bauer kommt zu Dir und sagt: "Ich will meine Kühe zählen." Das WAS ist scheinbar schnell erfasst - Kühe zählen oder formaler, gesucht ist die Anzahl seiner Kühe. Daraus folgt die Frage nach dem WIE.

Du sagst: "Zähl doch einfach durch" - "nee, geht nicht sind zu viele" - "Dann mach doch ne Strichliste" - "Ja kann ich machen, aber die laufen immer kreuz und quer, da zähl ich einige mehrfach" - "Dann bind sie vorher an" - "Auf der Weide?"

Die Lösungswege oder Prozeduren (WIE) waren bisher wenig fruchtbar, da Information über das WAS vorenthalten wurde. "Ok verstehe, dann miete Dir einen Helikopter und fotografiere die Herde von oben, dann kannst Du sie auszählen" - "Ja und Nachbars Kühe?" - "Nachbars Kühe?" - "Na die sind doch in meine Weide eingebrochen" - "Ehm Kommando Pimperle, WARUM willst Du Deine Kühe zählen?"

Grundproblem ist die lückenhafte Problembeschreibung (WAS), welche nicht als Lösung taugt. Ein Problem, mit dem jeder Programmierer im Umgang mit Kundenwünschen ständig konfrontiert wird. Die Frage nach dem WARUM nötigt dem Problemsteller den Sinn oder zumindest die Hintergründe ab, mit deren Wissen die Übersetzung in eine andere Domäne einfacher gelingt, da man relativ schnell die Freiheitsgrade und etwaige Einschränkungen erkennt (semantische Erfassung). Nicht selten stellt sich dann auch das Problem anders dar.

Moin,

@ BlackJack: Stimmt, es wurde mir sogar mal hier im Forum zum Testen/Ausgeben phys. Zeilen empfohlen, ich war da nur nicht durchgestiegen und hatte es daher zurückgestellt

Ich habe jetzt gestern Abend noch den ganzen Code um- bzw. restrukturiert, suche allerdings noch einen Lösungsweg, lokale Variablen, welche in Bspw. Funktion1() erstellt werden, an Funktion2() zu übergeben, ohne dass Funktion1() dabei Funktion 2(Variable) aufrufen muss, um den Code so wenig rekursiv wie möglich zu gestalten...ist gar nicht so einfach.
Mit `return` klappt es anscheinend nicht, da die Variable nun zwar immerhin nicht mehr im globalen Namensraum gesucht wird, Funktion2() aber dennoch nicht weiß, dass sie die Variable aus Funktion1() übergeben bekommen soll / Funktion1() es nicht schafft, die Variable aus dem Mainloop heraus an Funktion2() zu übergeben.

In einer früheren Version (ohne Klassen, eben wie jetzt, mit weniger Funktionen jedoch) habe ich die Variablen fälschlicherweise durch rekursive Aufrufe aus den Funktionen heraus übergeben. Ich suche jetzt die Möglichkeit, diese über den Mainloop heraus jeweils von Funktion1 -> Mainloop -> Funktion2 -> Mainloop -> Funktion3 ... zu übergeben, ohne die Variablen im globalen Namensraum deklrarieren zu müssen...
Wahrscheinlich hab ich irgendwo einfach 'nen Denkfehler...
Ich probier mich da jetzt aber nochmal kurz dran. Und wenn mir die Lösung nicht wie Schuppen von den Augen fallen sollte, frag ich wohl heute Abend nochmal nach...

BSA hat geschrieben:Ich suche jetzt die Möglichkeit, diese über den Mainloop heraus jeweils von Funktion1 -> Mainloop -> Funktion2 -> Mainloop -> Funktion3 ... zu übergeben, ohne die Variablen im globalen Namensraum deklrarieren zu müssen...
Wahrscheinlich hab ich irgendwo einfach 'nen Denkfehler...

:K

Na, da wär ich aber von alleine erstmal wohl kaum draufgekommen...
Ich weiß zwar noch nicht so ganz, wie ich das ganze in meinem 400+xx-Zeilen-Code umsetzen soll, werd mich aber nachher mal dran probieren!

Das Prinzip jedenfalls hab ich mal eben kurz ausprobiert und bei rausgekommen ist folgendes:
Das sieht auch so aus als wenn es funktionieren würde.
Ich hab versucht nach deiner zweiten Methode vorzugehen, und den Wert der benötigten Variable durch Ausführen der jeweiligen Funktion über eine return-Anweisung an eben diese zu binden.
Das ganze geschieht hier in der Funktion ergebnisse() - sollte aber im Grunde auch mit etlichen if/elif/else-Abfragen in einem (für mich...) "etwas komplexeren Skript" funktionieren... ich werds ausprobieren!

Ich hoffe nur, dass es auch genausogut in meinem kleinen Spielchen klappt.
Das Problem seh ich nämlich darin, dass ich nicht für jede benötigte Variable jedes mal erneut die jeweilige Funktion durchlaufen lassen kann, da der Spieler evtl. einfach nur nochmal wiederholen möchte...
Allerdings fällt mir da auch grad auf, dass die Werte der dann ja erneut, jedoch nur noch lesend benötigten Variablen in dem mainloop noch weiterhin gespeichert sein dürften, bis sie eben durch erneuten Aufruf der Funktion neu gebunden werden...hmm...es bleibt spannend!

Wenn der Wert aller nach erstmaligem Durchlauf erstellten Variablen bis zum erneuten Überschreiben der Variablen durch erneuten Funktionsaufruf durch Eingabe des Nutzers lokal in der letzten while-Schleife innerhalb der main()-Funktion gespeichert bleibt, und solange mit ihrem jeweiligen Wert weiterhin von jeder noch zu nutzenden Funktion gelesen werden kann, dann müsste es theoretisch funktionieren. Und rekursiv sollte es mMn dann eigentlich auch nicht mehr sein, da jede benötigte Funktion jeweils nur durch die Hauptfunktion, dem mainloop, aufgerufen würde und die ganzen andern Funktionen sich selber nicht mehr berühren/aufrufen würden.

Wenn das also klappt, bin ich ein ganzes gutes Stück weiter, als ich noch jetzt bin.

In der Theorie klingt das auch sehr einfach. Was für eine Tipperei das nachher aber noch wird, bleibt gespannt abzuwarten

Danke nochmal für den Hinweis!

Grüße
BSA


edit: unnötigen Code rausgeschmissen (a = int(input(...)) -> a = input(...)
Bei den for-Schleifen bekomme ich keinen einmaligen Durchlauf durch "for i in 1" hin, int sei nicht iterierbar...daher durch while-Schleifen ersetzt!

@BSA: Mit sinnfreien Schleifen hast Du's irgendwie. Die in `subtraktion()` und `division()` werden grundsätzlich genau *einmal* durchlaufen. Und wenn man nicht zumindest potentiell etwas wiederholen will, braucht man keine Schleife.

Das Ergebnis jeweils aus- *und* zurückzugeben ist irgendwie redundant.

Allen Rechenfunktionen ist gemeinsam, dass sie `a` und `b` vom Benutzer erfragen. Das könnte man also in eine Funktion heraus ziehen. So wirklich unterscheiden tun sie sich aber nur durch die Rechnung und den Ausgabetext. Also könnte man eine generische Funktion für eine binäre Rechenoperation schreiben und die eigentliche Rechenfunktion und den Text als Argumente herausziehen. Zumindest zwei der Rechenfunktionen kann man direkt aus dem `operator`-Modul nehmen. Eigentlich auch bei `subtraktion()` und `division()`, denn die Fallunterscheidung dort verstehe ich nicht so ganz. Warum?

Und warum berechnet Quadrat zwei Quadrate und nicht nur eines?

Statt der durchnummerierten `v`\s in `ergebnisse()` hätte man eine Liste verwenden können.

Der Funktionsname passt nicht zu einer Funktion eher zu Werten — eben Ergebnisse.

Und natürlich kann man nicht über eine 1 iterieren. Was sollte denn da das Ergebnis in jedem Schleifendurchlauf sein?