Gui Designer auf GitHub

[Alfons Mittelmeyer]

@BlackJack Du hast natürlich recht damit, dass ich meine 'except: pass' Methoden überprüfen sollte und ob ich sie nur für Benutzereingaben benütze. In meinem Hauptmodul DynTkInter habe ich folgende 3 Methoden mit 'except: pass' :

Code: Alles auswählen

    # used by the GUI Creator: it tries to take the name of the widget as text. So Labels, Buttons and LabelFrames may be easily identified when doing the layout
    def text(self,mytext):
        try: self.config(text=mytext)
        except: pass

    # layout settings with the options as a string - is used by the GUI Creator
    def setlayout(self,name,value):
        dictionary = {}
        dictionary[name]=value
        try: self.layout(**dictionary)
        except: pass

    def setconfig(self,name,value):
        confdict={}
        confdict[name] = value
        try: self.config(**confdict)
        except: pass

Alle drei Methoden sind so richtig.

- text: Bei Widgets, welche die config Option 'text' haben, soll beim Anlegen der Widget Name als Text angezeigt werden - etwa bei Message, Label, Button, LabelFrame. Bei anderen Widgets soll das natürlich nicht abstürzen.

- setlayout: für Eingaben des Benutzers, nämlich für pack, grid oder place. Wenn er statt einer Spaltenangabe bei grid "wrdlbrmpfd" schreibt, soll das Programm nicht abstürzen. Kann sein, dass ich diese Funktion selber in meinem Programm benütze, statt pack, grid oder place. Ursprünglich hatte diese Methode kein try. Das hatte ich dann geändert für Benutzereingaben. Muss eben hier mal einen Fehler einbauen, um zu sehen, ob ich sie sonst noch benutze oder nicht.

- setconfig: für Eingaben des Benutzers bei Config Optionen. Dafür gilt dasselbe wie für setlayout. Muss auch hier mal schauen, ob ich das sonst noch benutze, etwa widget.setconfig('bg','yellow') anstatt widget['bg'] = 'yellow' oder auch widget.config(bg = 'yellow').

Jedenfalls haben diese Methoden sichtbare Effekte, bei denen man gleich sieht, geht es oder nicht. Und dass etwas nicht geht, hatte ich nicht gesehen.

[Hyperion]

Alle drei Methoden sind so richtig.

Ein nacktes ``try... except`` ist eigentlich nie sinnvoll

Deine Beispiele zeigen nichts, was das rechtfertigt!

[Alfons Mittelmeyer]

@Hyperion Ich habe genau beschrieben, wofür das da ist. Und gestern hatte ich geschrieben, dass der Benutzer bei Methode 2 und 3 eine Fehlermeldung durch Rücklesen des Wertes bekommt. Es findet also eine Fehlerbehandlung statt. Und bei Methode eins erübrigt sich jegliche Fehlerbehandlöung. Man sollte nicht nur Regeln im Kopf haben, sondern auch den Sinn von etwas verstehen können.

Und Hyperion, wenn Du Dir ein offenes Denken erwerben willst, dann vergiss absolute Begriffe. Statt 'nie' benütze 'nicht oft' statt 'nichts' benütze 'wenig' oder 'nicht viel'. Dann übersetzen wir mal Deinen Einwurf:

Ein blankes ``try... except`` ist eigentlich nicht oft sinnvoll

Deine Beispiele zeigen mir nicht viel, was das rechtfertigt!

[Hyperion]

@Hyperion Ich habe genau beschrieben, wofür das da ist.

Nö! Du hast nur beschrieben, *was* Du damit erreichen willst. Du hast aber offenbar immer noch nicht verstanden, *wie* man das tatsächlich erreicht, *ohne* sich Wege zu verbauen, *ungeplante* Ausnahmen zu erkennen...

Man sollte nicht nur Regeln im Kopf haben, sondern auch den Sinn von etwas verstehen können.

Richtig. Und letzteres hast Du offensichtlich im Bereich Exception-Handling (noch) nicht! Hättest Du das, würdest Du diese Regel nämlich selber verinnerlicht und damit richtig angewendet haben

Um es Dir aber noch mal explizit zu machen: Man sollte immer nur die Ausnahmen abfangen, mit denen man zur Design-Zeit rechnet und die man sinnvoller Weise behandeln kann. Behandeln kann durchaus auch "ignorieren" sein, keine Frage. Aber Exceptions, von denen man *niemals* denken würde, dass sie auftauchen, sollte man nicht "verschlucken", wie Du es tust. Tritt so etwas nämlich auf, so wird sich Dein Programm im schlimmsten Fall total sonderbar verhalten oder auch an Stellen abstürzen, bei denen Du keine Ahnung hast, was da schief gelaufen ist (eben weil das schon viel weiter vorher passiert ist, Du es aber nicht mitbekommst).

Aber was rede ich mir den Mund fusselig... Du wirst es ja eh nicht durchdenken, recherhciere oder gar ausprobieren

[Alfons Mittelmeyer]

Aber Exceptions, von denen man *niemals* denken würde, dass sie auftauchen, sollte man nicht "verschlucken", wie Du es tust.

Das siehst Du hier ganz falsch, denn es geht hier nicht um Exceptions, von denen ich *niemals* denke, dass sie auftauchen, sondern von denen ich denke, dass sie fortwährend auftauchen, und dass das das ganz normale Verhalten ist. Daher auch keine Fehlerbehandlng.

Und noch nichts gehört von EAFP Code? Also:

Code: Alles auswählen

# statt LYBL
if entry in myDictionary: del myDictionary[entry]

# EAFP
try: del myDictionary[entry]
except: pass

Quelle: https://www.jeffknupp.com/blog/2013/02/ ... xceptions/

Man sollte dabei natürlich noch abfangen, ob es myDictionary gibt.

Und ich könnte ja abfangen, ob es in tkinter 'config' gibt, das könnte ja auch umbenannt worden sein bei einer neueren tkinter Version. Aber dann würde sowieso nichts mehr gehen, und das merkt man dann schon

[cofi]

Natuerlich geht es um die Exceptions mit denen du *nicht* rechnest, schliesslich ignorierst du sie einfach.

Wuerde dein Code tatsaechlich das tun was du behauptest wuerde er so aussehen:

Code: Alles auswählen

try:
    del myDictionary[entry]
except (KeyError, ExpectedException):
    pass

Und wenn `myDictionary` nun ein Objekt ist dessen `__getitem__` unerwartete Exceptions wirft, wirst du es nun merken, ganz anders als bei deinem bisherigen Code.

Lustig ist natuerlich auch, dass du hier Quellen anfuehrst, die aber gar nicht deine blanken `except` rechtfertigen.

[Alfons Mittelmeyer]

@cofi Ja kann man so machen. Und welcher Error wäre dann das, wenn es in tkinter nicht 'config' geben würde und auch nicht die Parameter? Die Werte der Parameter sollen aber beliebig sein, auch wenn sie falsch sind in Fall 2 und 3. in Fall 1 dagegen braucht es auch den Key nicht zu geben. Also das mit dem dictionary habe ich nicht gemacht. Da habe ich LYBL verwendet.

Ach so, ich kann ja auch ausprobieren, welche Fehler ich bekomme, indem ich etwa comfig schreibe und danach einen falschen Key verwende und danach einen falschen Wert nehme.
Natürlich kann in Fall zwei und drei ein falscher Key nicht passieren, denn was man mit config bekommt, sollte auch wieder mit config gehen.

[Alfons Mittelmeyer]

@cofi Das mit dem except bringt nicht viel, denn es gibt da nur eine Art von Fehler: tkinter.TclError

Und wenn ich bei tkinter Operationen schreibe: except tkinter.TclError: pass
dann kann ich mir das mit except tkinter.TclError auch gleich sparen und gleich pass schreiben. Aber OK schreibe ich das eben rein, auch wenn es überhaupt nichts bringt.

[BlackJack]

@Alfons Mittelmeyer: Das stimmt doch gar nicht, es gibt noch viele andere Ausnahmen. Das Du die nicht erwartest, heisst ja nicht das sie nicht auftreten können, und genau das ist ja das Problem: Wenn dann mal eine andere Ausnahme kommt, bekommst Du das nicht mit und das Programm verhält sich nicht so wie Du erwartest, aber Du weisst nicht warum und es ist schwerer *das* dann heraus zu finden als wenn man die Ausnahme zusammen mit einem Traceback bekommt.

[Alfons Mittelmeyer]

@BlackJack Es geht um diese 3 Methoden, bei denen das 'except: pass' so bemängelt wurde. Weisst Du was sich da ändert, wenn ich except tkinter.TclError mache? Überhaupt nichts. Das würde genau dann einen NameError ausspucken, wenn eine dieser vier tkinter Methoden nicht mehr existiert:

- config
- grid
- pack
- place

Aber soweit kommt es gar nicht, denn config, grid und pack, benutzt der GUI Designer bereits beim Hochfahren ohne try,except. Und place würde wahrscheinlich bereits bei place_info aussteigen, oder wenn der Benutzer ein neues Place Layout macht oder die Koordinaten im Basis Layout verändert. Nur in dem unwahrscheinlichen Fall, dass er eine bereits bestehende GUI bearbeitet und dabei nur über die Layout Optionen geht, wäre der Fehler unterdrückt worden, wenn es place nicht mehr gibt. Aber gesehen hätte er bestimmt, dass sich dabei nichts ändert.

Aber ich denke, dass da ein ungeheurer Aufschrei bei allen tkinter Nutzern wäre, wenn es place nicht mehr gibt. Gemerkt hätte man das ganz bestimmt!

FALSCH: ein bereits exisierendes Placelayout wäre gar nicht erst hochgefahren, wenn es place nicht mehr gibt. Also der Fehler wäre ohne Exception sowieso bereits vorher aufgetreten.

Und es geht hier auch nicht um Fehler im Programm, sondern um Fehler bei tkinter. Wenn mir etwa grid_info einen Key liefert, den dann grid(..) nicht nehmen will, das wäre ein Fehler, den ich leider nicht abfangen kann. Das läßt sich nur durch Testen herausfinden. Oder ändert sich etwas, wenn ich sashrelief von 'flat' auf 'raised' umstelle? Und siehe da, es macht es. Und da habe ich nichts hartkodiert. Hartkodiert ist nur die Sortierreihenfolge. Und wenn ich mich da vertippt habe oder einen Key nicht berücksichtigt habe, dann wird ein Key - etwa aus grid_info() oder aus config() - nicht da einsortiert, wo ich ihn haben wollte, sondern kommt erst ziemlich weit hinten.

[BlackJack]

@Alfons Mittelmeyer: Natürlich ändert sich was wenn Du explizit nur `tkinter.TclError` behandelst. Du siehst dann alle anderen Ausnahmen mit denen Du nicht rechnest mit Traceback. Das Du damit nicht rechnest heisst ja nicht das es sie nicht gibt. Wenn man sich mal nur die Methoden ansieht kann da *jede* Ausnahme kommen die es unter der Sonne gibt, nicht nur der `AttributeError` (nicht `NameError`) falls jemand eine der Methoden entfernt hätte.

Alleine ein `MemoryError` ist eine Ausnahme die man in der Regel gar nicht sinnvoll behandeln kann, schon gar nicht durch ignorieren, weil das Problem ja nicht weggehen wird.

Jede beliebige Ausnahme kann deswegen auftreten weil dort Objekte an Tk übergeben werden und die für Tk in Zeichenketten umgewandelt werden (müssen). Und dabei kann je nach Objekt alles mögliche an Ausnahmen auftreten.

[Hyperion]

@BlackJack und andere: *seufz* Als wenn man gegen eine Wand redete...

@Alfons: IdR. vermeide ich auch "immer" und "nie", denn in der Tat geht es meist eher um Prinzipien und nicht um absolut gültige Reglen (<Sexismus Modus> Wer eine Freundin hat, weiß wovon ich rede, denn die Worte "immer" und "nie" sind bei Streitereien mit dem weibichen Geschlecht offenbar sehr beliebt und fallen "immer" </Sexismus Modus>)

Aber: Ich schrieb "eigentlich" - das ist imho Einschränkung genug an der Stelle. Wer in eine Situation kommt, in der man eine Ausnahme davon machen kann, der ist so gut, dass er weiß, was er tut. Das ist bei Dir übrigens noch nicht der Fall, denn bei Dir liegt eine andere Situation vor und Du zeigst fortwährend, dass Du den Sinn von Exceptions immer noch nicht verstanden hast!

Mich stört an Dir Thread übergreifend folgendes: Du "entdeckst" ein Dir total sinnvoll erscheinendes Muster und wendest es dann auf Teufel komm raus an. Wenn man Dir dann Schwächen oder Fehler daran nennt, stellst Du Dich zunächst überhaupt nicht in Frage und vertraust darauf, dass viele Regulars hier deutlich mehr Wissen und Erfahrung bezüglich Python haben als Du, und Dir folgerichtig *richtige und gute* Tipps geben, sondern Du verteidigst Deine Idee auf Teufel komm raus und suchst Quellen, die (vermeindlich) belegen, was Du behauptest. Denkst Du wirklich, dass Du Dich damit sinnvoll verbessern wirst?

Auch ein Albert Einstein hat die Grundlagen der Physik durch das Wissen von anderen gelernt, wie alle Schüler dieser Welt. Erst später hat er neue Ideen formuliert, die bis dato keiner hatte. Hingegen sind Leute, die das Rad komplett neu erfinden und sogar verbessern aufgrund von Isolation oder dem nicht vorhandenen Zugang zu Bildung, *extrem* selten. Zudem gehörst Du ja nicht zu letzteren, wie Deine aktive Teilnahme in diesem Forum beweist. Bleibt also nur der erste Fall...

Als intelligenter Mensch sollte man folgerichtig leicht zur Einsicht gelangen, dass man leichter und sicherer vorankommt, wenn man auf Ratschläge von anderen zurückgreift! Dabei muss man auch nicht alles als Gott gegeben hinstellen; kritisch hinterfragen sollte man Dinge durchaus. Aber dazu gehört es zunächst, diese Dinge genau zu durchleuchten und deren Intention zu verstehen. Mindestens diesen letzten Schritt machst Du sehr selten, wenn überhaupt einmal!

Und das nervt so gewaltig!

Natürlich könnte man das auch ignorieren, aber leider lesen hier ja auch nicht registrierte Menschen mit bzw. könnte falsche Aussagen finden und sich diesen Mist selber aneignen. Und das muss man eben verhindern, was leider nur durch eine aktive Teilnahme zu erreichen ist. Wäre das nicht der Fall, wären solche Threads von Dir wesentlich kürzer und eher Monologe - denn wer mag es schon wirklich, sture und beratungsresistente Menschen zu überzeugen? Ich glaube davon gibt es nicht allzu viele Regulars hier...

[Alfons Mittelmeyer]

Das ist bei Dir übrigens noch nicht der Fall, denn bei Dir liegt eine andere Situation vor und Du zeigst fortwährend, dass Du den Sinn von Exceptions immer noch nicht verstanden hast!

Natürlich hat alles seinen Sinn. Python Programmmierer sind gewohnt, dass Python ihnen Fehler anzeigt und die wollen dass die auch immer angezeigt werden. C Programmierer sind gewohnt, dass sie eine Exception nur bekommen, wenn sie durch 0 teilen oder in einen geschützten Speicherbereich schreiben oder den Speicher zum Überlauf gebracht haben. Assembler Programmierer sind gewohnt, dass sie leicht einen Systemabsturz bekommen, wenn sie etwa statt in den Kodebereich in Daten springen, die der Prozessor natürlich nicht richtig als Programm ausführen kann.

Und ich bin gewohnt, Programme fast immer fehlerfrei so zu schreiben, dass sie funktionieren. Allerdings hat mein GUI Designer, da ein paar Stellen noch nicht ganz fertig sind, noch Fehler. Habe etwa die Laderoutine geändert, die nun eine main-Funktion erwartet und die save-Routine noch nicht nachgezogen. Also ein paar Baustellen, sind da noch. Und Überarbeitung ist noch nötig.

Es gibt auch Programmierer die soweit gehen:

Code: Alles auswählen

a = 5
if a != 5:
    print("Error: a = ",a," instead of 5")

Es gibt also auch übertriebene Fehlerbehandlung. Wo ist da der Mittelweg? Ich sehe natürlich ein, dass solche Exceptions und die empfohlene Behandlung schon sinnvoll sind, und an den besagten Stellen könnten natürlich schon Fehler auftreten, wenn etwa statt einem Widget eine Referenz auf etwas anderes übergeben wird. Und viele programmieren sehr unsauber, dass so etwas des Öfteren passiert. Also mache ich es eben auch so, zufrieden?

[cofi]

Und ich bin gewohnt, Programme fast immer fehlerfrei so zu schreiben, dass sie funktionieren.

Das ist ja direkt Comedygold. Die Art und Weise wie du da Exceptions handhabst ist gerade ein Beispiel, dass du fehlerhafte Programme schreibst.

Wenn du nur eine bestimme Art von Exception erwartest und/oder behandeln kannst, dann behandelst du nur diese bestimmte Art. *Alles andere* ist fehlerhafter und unsauber programmierter Code.

[Alfons Mittelmeyer]

Und ich bin gewohnt, Programme fast immer fehlerfrei so zu schreiben, dass sie funktionieren.

Das ist ja direkt Comedygold. Die Art und Weise wie du da Exceptions handhabst ist gerade ein Beispiel, dass du fehlerhafte Programme schreibst.

Nein das ist kein Beispiel für fehlerhaft. Das ist ein Beispiel, dass ich ganz gut auf jede Art von Fehlermeldung verzichten kann. Oder meinst Du ich hätte irgendeine Fehlermeldung bekommen, als ich mal ein Arztpraxisverwaltungsprogramm in Assembler geschrieben hatte?

Das heißt auf alle Fehlermeldungen kann man natürlich nicht verzichten. Syntaxfehler muss ein Compiler oder Assembler melden. Und das erwarte ich auch von Python.

[BlackJack]

@Alfons Mittelmeyer: Du denkst Du kannst auf Fehlermeldungen verzichten weil Du hier unter grenzenloser Selbstüberschätzung leidest. *Kein* Programmierer kann auf die Meldung von Fehlern verzichten mit denen er nicht rechnet wenn er saubere Programme schreiben will.

Das bestimmte Sprachen keine besondere Unterstützung für Fehler- und Ausnahmesituationen bieten ist kein Argument, denn genau in diesen Sprachen ist es deswegen ja auch so schwer Fehler zu finden und oft überhaupt zeitnah zu bemerken.

[Alfons Mittelmeyer]

@BlackJack Ich leide nicht an grenzenloser Selbstüberschätzung, ich bin nur Spezialist im Fehlerfinden. Und ich weiss, dass sich da andere sehr schwer tun. Ich habe mal ein Projekt gemacht. Beim Nachfolgeprojekt waren es dann zehn Programmierer und die haben länger gebraucht, als ich vorher allein. Und ich war hauptsächlich damit beschäftigt, ihnen ihre Fehler mitzuteilen, die sie selber nicht gefunden haben. Statt die einfach kurzerhand rauszumachen, mußte ich Ihnen emails schreiben und ihnen klar machen, wo die Fehler sind, denn es war ja ihr Code.

Und statt über drei exceptions oder Sternchenimporte zu sprechen, sollte mann sich auf wirkliche Fehler konzentrieren.

Heute ging mein Programm nicht, Da hatte ich noch einen Murks reingemacht: if tkClass() == "PanedWindow" statt if tkClass == tk.PanedWindow
Und bekomme ich da eine Exception? Nein! Da wundert man sich nur, dass da ständig ein neues tkinter Fenster aufgeht.

Und was ist mit 'Problem: beim 2. Sash nimmt tkinter die Koordinaten nicht' anscheinend interessieren echte Fehler niemanden. Und wenn ein User ein fehlerhaftes Programm hat, was schreibt Ihr ihm dann?

Sternchenimporte soll man nicht machen, vier Leerzeichen einrücken statt Tab, Klassen nehmen, Exceptions richtig behandeln, gute Namenswahl. Also meist nichts von dem, was der Fehler ist, oder wie das Problem gelöst werden kann.

Mit vier Leerzeichenn statt Tab geht der Fehler sicher nicht weg, mit anderer Namenswahl auch nicht!

[BlackJack]

@Alfons Mittelmeyer: Auch wenn man Spezialist im Fehlerfinden ist, macht es keinen Sinn Fehlermeldungen mit denen man nicht rechnet, mutwillig zu unterdrücken. Das an sich ist ein Fehler, den Du offensichtlich nicht siehst obwohl Du doch Spezialist im Fehlerfinden bist. Insbesondere verstehe ich nicht warum man sich da so hartnäckig gegen sträuben muss es richtig zu machen, wenn das doch so verdammt *einfach* ist.

Sich an Konventionen zu halten hilft bei der Kommunikation. Leerzeichen statt Tabulatorzeichen verhindern schwer sichtbare Einrückfehler, und gute Namenswahl verhindert in sofern Fehler, als dass einem leichter auffällt wenn man etwas unsinniges macht, weil sich der Code dann in häufig einfach falsch ”anhört” wenn man ihn liest. Bei der Fehlersuche helfen gut gewählte Namen auch weil man von dem zusätzlichen Schritt kryptische Namen im Kopf erst auf die eigentliche Bedeutung abzubilden, befreit ist und man sich mehr auf das eigentliche Problem konzentrieren kann. Zudem ist es oft ein Zeichen das man etwas noch nicht richtig durchdacht hat wenn es schwer fällt einen passenden Namen für ein Objekt zu finden.

Klassen helfen Code sinnvoll zu strukturieren und Daten und Code zu kapseln, was Fehler vermeidet und bei der Fehlersuche hilfreich ist.

Ausnahmen sorgen dafür das man Fehler nicht übersehen kann weil sie in der Aufrufhierarchie nach oben weiter gereicht werden ohne das man etwas dafür tun muss, und gemeldet werden, wenn man sie nicht behandelt. Dadurch fallen eben jene Fehler auf mit denen man nicht gerechnet hat, wenn sie auftreten.

[Alfons Mittelmeyer]

Neue GUI Designer Version auf Github: https://github.com/AlfonsMittelmeyer/py ... -messaging

Jetzt auch mit Menu und Menubutton. Damit ist es die erste Vollversion.

Bitte noch nichts runterladen, denn Github fetcht immer noch.

[wuf]

Hi Alfons

Noch ein kleiner Tipp betreffs den Layout Options padx und pady. Dies betrifft also nur die padx und pady, welche als Layout Options verwendet werden! Nebst dem symetrischen padding kann auch ein asymetrisches definiert werden.

Für symetrisches padding z.B.:
padx=4
pady=6

Für asymetrisches padding z.B:
padx=(4, 10)
pady=(2, 10)

Gruss wuf