Klassen. Attribute, Methoden für eine tkinter GUI? Wozu?

Fragen zu Tkinter.
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

BlackJack hat geschrieben:Zudem haben diese lokalen Funktionen den Nachteil das man sie nicht isoliert testen kann, weder zur Fehlersuche,
noch in Unit-Tests.
Was denkst Du warum ich diesen Aufstand mit dem Zugriffsschutz mache?
Damit man keine kreuz und quer Zugriffe macht.
DAMIT MAN ISOLIERT ENTWICKELT UND ISOLIERT TESTEN KANN!
Zuletzt geändert von Alfons Mittelmeyer am Dienstag 22. August 2017, 20:32, insgesamt 1-mal geändert.
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

BlackJack hat geschrieben:@Alfons Mittelmeyer: :lol:
Lach Du nur, schreiben dass man das nicht testen kann, aber anderen empfehlen, dass sie partial benutzen sollen. Also genau das, was man Deiner Meinung nach nicht testen kann.

Ich benutze schon lange mein eigenes partial und brav, wie ich da bin, erzeuge ich ein Objekt und geb eine Methode zurück, Aber partial gibt anscheinend eine Closure Funktionsreferenz zurück. Und das empfiehlst Du?

Hier ein sicheres partial ohne diese angeblich nicht testbaren lokalen Referenzen, denn das ist wirklich ein Objekt:

Code: Alles auswählen

class Callback:

    def __init__(self,function,*args,**kwargs):
        self.function = function
        self.args = args
        self.kwargs = kwargs

    def execute(self,*args,**kwargs):
        dict_kwargs = dict(self.kwargs)
        dict_kwargs.update(kwargs)
        self.function(*list(self.args)+list(args),**dict_kwargs)

def partial(function,*args,**kwargs):
    return Callback(function,*args,**kwargs).execute
Auch hier haben wir wieder den Zugriffsschutz. Man bekommt keine Referenz auf das Objekt, kann aber dessen Methode mittels (*args,**kwargs) aufrufen.
Sirius3
User
Beiträge: 17703
Registriert: Sonntag 21. Oktober 2012, 17:20

@Alfons Mittelmeyer: man testet ja auch nicht die mit partial veränderte Funktion, denn partial ist schon getestet und es ist sinnvoller die ursprüngliche Funktion zu testen. Was ist der Sinn, partial nachzuprogrammieren? Zugriffsschutz hat nichts mit Kapselung zu tun. Und zum hunderttausendstenmal, das was Du hier veranstaltest ist einfach nur umständlich und da Du keine Ahnung hast, wie Python intern arbeitet, sind Deine Mutmaßungen, was wie funktioniert meist amüsant., haben aber in einem normalen Programm nichts verloren. Auc bei Künstlern gibt, bevor sie die anerkannte Malerei verlassen haben, konnte auch ein Picasso realistisch malen. Bevor Du also anfängst, Deine eigene Programmierphilosophie aufzuschreiben, muß Du erst richtig programmieren lernen.
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

Sirius3 hat geschrieben:@Alfons Mittelmeyer: man testet ja auch nicht die mit partial veränderte Funktion, denn partial ist schon getestet und es ist sinnvoller die ursprüngliche Funktion zu testen. Was ist der Sinn, partial nachzuprogrammieren?
Ich habe nicht partial nachprogrammiert, sondern ich benutze diese Callback Klasse auch in Verbindung mit anderen Funktionen und Klassen. Partial war da nur ein Beiprodukt. Läßt sich auch so schreiben:

Code: Alles auswählen

def partial(function,*args,**kwargs):
    def execute(*new_args,**new_kwargs):
        dict_kwargs = dict(kwargs)
        dict_kwargs.update(new_kwargs)
        function(*list(args)+list(new_args),**dict_kwargs)
    return execute
Außerdem hatte ich des öfteren Probleme mit partial. Funktionierte manchmal nicht. So gut konnte es da ja nicht getestet sein. Aber mein partial ging. Leider ist mir dieser Fehler bei partial in letzter Zeit nicht mehr aufgefallen, sodass ich ihn auch nicht zeigen kann. Evtl. wurde dieser ja bei einem update behoben.
Sirius3 hat geschrieben:Zugriffsschutz hat nichts mit Kapselung zu tun.
Wie kommst Du auf solchen Unsinn?

Laut Wikipedia und nicht nur laut Wikipedia geht es dabei um:
Als Datenkapselung (englisch encapsulation, nach David Parnas auch bekannt als information hiding) bezeichnet man in der Programmierung das Verbergen von Daten oder Informationen vor dem Zugriff von außen. Der direkte Zugriff auf die interne Datenstruktur wird unterbunden und erfolgt stattdessen über definierte Schnittstellen (Black-Box-Modell).
Quelle: https://de.wikipedia.org/wiki/Datenkaps ... mierung%29

Klaro?
Sirius3 hat geschrieben: Und zum hunderttausendstenmal, das was Du hier veranstaltest ist einfach nur umständlich und da Du keine Ahnung hast, wie Python intern arbeitet, sind Deine Mutmaßungen, was wie funktioniert meist amüsant., haben aber in einem normalen Programm nichts verloren. Auc bei Künstlern gibt, bevor sie die anerkannte Malerei verlassen haben, konnte auch ein Picasso realistisch malen. Bevor Du also anfängst, Deine eigene Programmierphilosophie aufzuschreiben, muß Du erst richtig programmieren lernen.
Ja toll, dass meine Programme, die angeblich auf Mutmaßungen aufgebaut sind, so gut funktionieren. Muß wohl an den sogenannten Mutmaßungen etwas dran sein. Naja, Bugs sind natürlich nicht ausgeschlossen haben aber mit der Philosophie des Programmaufbaus nichts zu tun.
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

Sirius3 hat geschrieben:Was ist der Sinn, partial nachzuprogrammieren?
Ich habe das bestimmt nicht nachprogrammiert:

Code: Alles auswählen

def partial(func, *args, **keywords):
    def newfunc(*fargs, **fkeywords):
        newkeywords = keywords.copy()
        newkeywords.update(fkeywords)
        return func(*(args + fargs), **newkeywords)
    newfunc.func = func
    newfunc.args = args
    newfunc.keywords = keywords
    return newfunc
Quelle: https://docs.python.org/2/library/functools.html

Zeilen 6 bis 8 sind Quatsch bei einer Closure, denn das wurde bereits als Parameter übergeben - außerdem verwirrend. Sieht man auch, wenn man Zeile 8 und 3 vergleicht, denn in Zeile 3 greift man wieder auf den übergebenen Parameter zurück statt newfunc.keywords und was soll überhaupt der Punkt da drin?
Anscheinend haben die bei python docs nicht viel Ahnung von Python.

In Zeile 3 habe ich statt copy dict benutzt. Vielleicht ist copy ja schneller.
In Zeile 5 habe ich noch list benutzt, vielleicht braucht man das nicht.

Aber dass man auch noch den Funktionswert zurückgeben kann (Zeile 5), habe ich vergessen.
Bei Callbacks etwa für commands und events war das ja auch nicht nötig. Und dass man einen Returnwert vom Eventbroker bekommen könnte, sollte man sich nicht angewöhnen, denn manche arbeiten auch mit einer Queue, wo das dann sowieso nicht geht.
Zuletzt geändert von Alfons Mittelmeyer am Dienstag 22. August 2017, 22:07, insgesamt 1-mal geändert.
BlackJack

@Alfons Mittelmeyer: Ja nee, schon klar, `partial()` funktioniert nicht, aber was genau kannst Du nicht sagen. ;-) Ich würde ja eher sagen Du hast oder hattest es nicht verstanden, wie so vieles nicht. Schau einfach mal in den Quellen nach wann `partial()` das letzte mal verändert wurde.

Und wo steht da jetzt in dem wikipedia-Zitat das man Zugriffsschutz braucht? Braucht man nämlich nicht. „Unterbunden“ heisst nicht das man es absolut gar nicht mehr machen kann, sondern das der direkte Zugriff einfach nicht mehr zur offiziellen API gehört. Kapselung funktioniert auch in dem man sich einfach an entsprechende Konventionen hält und dokumentiert was nicht öffentlich oder nur lesbar sein soll.

Deine Programme funktionieren nicht gut, sondern eher erstaunlicherweise und nur soweit Du damit kommst, was eher selten ein tatsächlich sinnvolles Stück Software ist, sondern meistens reine Selbstbefriedigung Deines Spieltriebs, ohne Sinn und Verstand, um zu schauen wie abwegig und umständlich man eigentlich bereits gelöste Probleme anders lösen kann als alle anderen und wie weit man sich dabei von Python und allgemeinen „best practices“ entfernen kann.

Die Zeilen 6-8 sind kein Quatsch, weil man auf diese Weise eben einfach an die Bestandteile heran kommt aus denen das neue Funktionsobjekt besteht.

Und selbst nicht wissen was der Punktoperator macht, aber im nächsten Satz den Python-Entwicklern unterstellen das sie nicht viel Ahnung von Python haben ist wieder so ein Klassiker der es echt schwer macht irgendwas von Deinen Aussagen tatsächlich ernst zu nehmen. Das ist schon fast surreal.

Also letztendlich hast Du `partial()` natürlich nicht nachprogrammiert, denn *das* ist wenigstens sinnvoll implementiert. :-)
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

BlackJack hat geschrieben:@Alfons Mittelmeyer: Ja nee, schon klar, `partial()` funktioniert nicht, aber was genau kannst Du nicht sagen. ;-) Ich würde ja eher sagen Du hast oder hattest es nicht verstanden, wie so vieles nicht. Schau einfach mal in den Quellen nach wann `partial()` das letzte mal verändert wurde.
Wäre natürlich auch möglich, dass das nichts mit partial zu tun hatte, sondern mit direktem Binding einer Funktion an einen command. Normalerweise sollen solche bindings im GuiDesigner nicht über direkten Aufruf laufen sondern über die Queue des dort verwendeten Eventbrokers, weil sich ansonsten eine veränderte Aufrufreihenfolge ergibt, Denn da ich in tkinter die Queue nicht polle, gilt da, dass den ersten die Hunde beißen. Wenn der etwas sendet, muß er erst warten, bis alle anderen, die aufgerufen werden und die auch senden, dieses auch getan haben und dann kann er erst weitermachen. Wenn allerdings der command auf der Queue liegt, dann muß dieser warten, was er ja sowieso muß. Und die anderen können dann senden, indem sie die Messages einfach auf die Queue legen, ohne dann warten zu müssen.
BlackJack hat geschrieben:Und wo steht da jetzt in dem wikipedia-Zitat das man Zugriffsschutz braucht? Braucht man nämlich nicht. „Unterbunden“ heisst nicht das man es absolut gar nicht mehr machen kann, sondern das der direkte Zugriff einfach nicht mehr zur offiziellen API gehört. Kapselung funktioniert auch in dem man sich einfach an entsprechende Konventionen hält und dokumentiert was nicht öffentlich oder nur lesbar sein soll.
Sicher braucht man den, denn wieso bemühen sich dann andere Programmiersprachen um Attribute und Methoden als private zu erklären? Kapselung funktioniert dann gut, wenn jemand, der eine Ahnung hat, etwas so schreibt, dass es den Konventionen von Kapselung entspricht und denjenigen etwas auf den Deckel gibt, die sich nicht daran halten, Wenn aber jemand, der nicht viel Ahnung hat, die Attribute und Methoden schreibt, denkt er dabei kaum an Kapselung.
BlackJack hat geschrieben:Deine Programme funktionieren nicht gut, sondern eher erstaunlicherweise und nur soweit Du damit kommst, was eher selten ein tatsächlich sinnvolles Stück Software ist, sondern meistens reine Selbstbefriedigung Deines Spieltriebs, ohne Sinn und Verstand, um zu schauen wie abwegig und umständlich man eigentlich bereits gelöste Probleme anders lösen kann als alle anderen und wie weit man sich dabei von Python und allgemeinen „best practices“ entfernen kann.
Zeig mir mal einen GuiBuilder, der an das Grid Layout meines GuiDesigners herankommt, oder der alle Layouts, wie pack, place und grid verwirklicht hat. Zeig mir einen, der so ziemlich jede GUI aus einem x-beliebigen Python Programm bearbeiten kann. Es fehlt allerdings noch die Übernahme von tkinter Widgets nach DynTkInter, wenn nicht alle Module DynTkInter verwenden und auch die Details der Treeview habe ich noch nicht implementiert.
BlackJack hat geschrieben:Die Zeilen 6-8 sind kein Quatsch, weil man auf diese Weise eben einfach an die Bestandteile heran kommt aus denen das neue Funktionsobjekt besteht.
Diese Zeilen sind Quatsch, denn func, *args, **keywords sind bereits als Parameter da. Und seltsamerweise greift Zeile 3 auf diesen parameter keyswords zu anstatt auf das völlig überflüssige "newfunc.keywords = keywords". Es ist also wesentlich einfacher, gleich auf die Parameter zuzugreifen anstatt die nochmals in Variablen zu speichern.
BlackJack hat geschrieben:Und selbst nicht wissen was der Punktoperator macht, aber im nächsten Satz den Python-Entwicklern unterstellen das sie nicht viel Ahnung von Python haben ist wieder so ein Klassiker der es echt schwer macht irgendwas von Deinen Aussagen tatsächlich ernst zu nehmen. Das ist schon fast surreal.
Ja toll das mit dem Punktoperator. Geht aber:

Code: Alles auswählen

def my_function(name,vorname,x):
    print(name,vorname,x)
    return 'murks'

def partial(function,*args,**kwargs):
    def execute(*new_args,**new_kwargs):
        dict_kwargs = dict(kwargs)
        dict_kwargs.update(new_kwargs)
        return function(*(args + new_args),**dict_kwargs)
    return execute

my_function.x = 5
print(my_function.x)

a = partial(my_function,'Mittelmeyer','Alfons')
print(a('test'))
my_function.x ist aber jetzt keine globale Variable oder, weil nämlich my_function eine Funktion ist, oder wie ist es jetzt damit?
BlackJack hat geschrieben:Also letztendlich hast Du `partial()` natürlich nicht nachprogrammiert, denn *das* ist wenigstens sinnvoll implementiert. :-)
Ja wenn Du meinst dass völlig überflüssige Zeilen und noch mit so einem komischen Punktoperator auf eine Funktion eine sinnvolle Programmierung sind, dann kannst Du mir nur leid tun.

Ach so, noch eine Frage: bei python doc nehmen sie in Zeile 7 copy. Ich habe aber dict genommen. Was ist nun besser? copy könnte schneller sein, oder was meint Ihr?
Benutzeravatar
noisefloor
User
Beiträge: 3829
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

@Sirius3: der Picasso-Vergleich gefällt mir... werde heute mal Anfangen, die ganze Post mit Code von Alfons Mittelmeyer zu sichern. Vielleicht ist der später ja mal was wert... So in der Art: "hier, guck mal, eines der frühen Werke von Alfons Mittelmeyer. Guck mal, wie innovativ der schon in seinen jungen Jahren war!" ;-)
Ach so, noch eine Frage: bei python doc nehmen sie in Zeile 7 copy. Ich habe aber dict genommen. Was ist nun besser? copy könnte schneller sein, oder was meint Ihr?
Um deiner Linie treu zu bleiben, solltest du selber ein Funktion schreiben, die das testet.

Gruß, noisefloor
BlackJack

@Alfons Mittelmeyer: Man braucht keinen Zugriffsschutz für Kapselung. Wenn man davon ernsthaft überzeugt ist, dann kann man kein Python verwenden. Es sei denn man ist gleichzeitig überzeugt, das man keine Kapselung braucht. :-)

Warum sich einige Sprachen so sehr um Zugriffsschutz bemühen? Weil nicht alle Sprachentwickler oder Entscheider von mündigen und vernünftigen Programmierern ausgehen, sondern Idioten und Vandalen als den Normalfall voraussetzen. Dann muss man natürlich alles gründlich weg schliessen. Allerdings helfen solche Sprachen auch nicht wirklich wenn die Idioten neuen Code schreiben und da alles „public“ machen, oder „private“ und dann für Getter und Setter anbieten und fälschlicherweise denken sie hätten nun gekapselt.

Meine Güte, die Zeilen sind kein Quatsch, Du hast nur immer noch nicht begriffen wofür die da sind. Die ”Bausteine” für dieses Objekt werden hier gerade absichtlich *nicht* in einem Closure versteckt, sondern als Attribute zur Verfügung gestellt, so das man dort auch später jederzeit dran kommen kann. Zum Beispiel praktisch bei der Fehlersuche oder wenn man fremden Code mit `partial`-Objekten live in der Shell untersucht und wissen möchte was für eine Funktion mit welchen durch `partial()` gebundenen Argumenten dahinter steckt. Python ist eben explizit keine Sprache in der man alles versucht zu verstecken, sondern wo man per Introspection an so ziemlich alles heran kommen kann.
Sirius3
User
Beiträge: 17703
Registriert: Sonntag 21. Oktober 2012, 17:20

Alfons Mittelmeyer hat geschrieben:Zeig mir mal einen GuiBuilder, der an das Grid Layout meines GuiDesigners herankommt, oder der alle Layouts, wie pack, place und grid verwirklicht hat. Zeig mir einen, der so ziemlich jede GUI aus einem x-beliebigen Python Programm bearbeiten kann.
Du verwechselst hier Funktionalität mit Qualität. Die meisten Anfänger möchten möglichst schnell möglichst viel in ihr Programm packen, das ist so lange ok, bis man selbst merkt, dass das Programm nicht mehr wartbar ist. Dann schmeißt man alles weg und macht es besser. Ich muß also nur lange genug warten und die Hoffnung nicht aufgeben.
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

BlackJack hat geschrieben:@Alfons Mittelmeyer: Man braucht keinen Zugriffsschutz für Kapselung. Wenn man davon ernsthaft überzeugt ist, dann kann man kein Python verwenden. Es sei denn man ist gleichzeitig überzeugt, das man keine Kapselung braucht. :-)
Braucht man natürlich nicht. Es ging ja auch nur darum, um aufzuzeigen, dass man auch funktionierende Programme schreiben kann, wenn es gar keine ZUgriffsmöglichkeiten von außen gäbe außer einem Signalinterface.
BlackJack hat geschrieben:Warum sich einige Sprachen so sehr um Zugriffsschutz bemühen? Weil nicht alle Sprachentwickler oder Entscheider von mündigen und vernünftigen Programmierern ausgehen, sondern Idioten und Vandalen als den Normalfall voraussetzen. Dann muss man natürlich alles gründlich weg schliessen. Allerdings helfen solche Sprachen auch nicht wirklich wenn die Idioten neuen Code schreiben und da alles „public“ machen, oder „private“ und dann für Getter und Setter anbieten und fälschlicherweise denken sie hätten nun gekapselt.
Wobei die Sprachentwickler natürlich nicht so unrecht haben, denn die gibt es auch zuhauf. Zumindest gab es sie früher zuhauf, als Objektorientierte Programmierung noch ein Fremdwort war. Wahrscheinlich hat sich aber inzwischen das Bewußtsein etwas gewandelt.
BlackJack hat geschrieben:Meine Güte, die Zeilen sind kein Quatsch, Du hast nur immer noch nicht begriffen wofür die da sind. Die ”Bausteine” für dieses Objekt werden hier gerade absichtlich *nicht* in einem Closure versteckt, sondern als Attribute zur Verfügung gestellt, so das man dort auch später jederzeit dran kommen kann. Zum Beispiel praktisch bei der Fehlersuche oder wenn man fremden Code mit `partial`-Objekten live in der Shell untersucht und wissen möchte was für eine Funktion mit welchen durch `partial()` gebundenen Argumenten dahinter steckt. Python ist eben explizit keine Sprache in der man alles versucht zu verstecken, sondern wo man per Introspection an so ziemlich alles heran kommen kann.
Ja, für das normale Funktionieren sind die Zeilen unnötig. Aber wenn sie zum Zweck der Fehlersuche da sind, das ist allerdings ein Grund.

Worum es auch ging, war, eine Möglichkeit aufzuzeigen, wie man auf einfache Weise Zugriff auf andere Komponenten bekommt ohne dass man sich durch einen Attributbaum hangeln muß und sich fast immer auf lokale Widget Referenzen beschränken kann.

Aber wenn man vom ursprünglichen Programmaufbau ausgeht, sieht man, dass es noch etwas wesentlich Schlechteres gibt, als sich durch einen Attributbaum zu hangeln, nämlich alle Komponenten, die gegenseitigen Zugriff brauchen, in eine Klasse zu verwursteln, damit dann der Zugriff einfacher ist.

Hier ging es ja noch, aber lass mal die Ebenen noch unterschiedlicher werden. Ich kann mir gar nicht vorstellen, wie dann so eine Klasse mit der GUI dieser Komponenten aussähe.

Das bitte gar nicht, dafür gibt es überhaupt keinen Grund. Sondern man sollte eine klar und übersichtlich strukturierte GUI haben, damit man sich gut auskennt.

Das Prinzip mit dem Signalinterface funktioniert auch, wenn der GUI Aufbau auf alle möglichen Weisen implementiert ist. Das heißt aber nicht, dass man deshalb auf eine übersichtliche GUI Struktur verzichten sollte, also mit Kassen, Attributen und Methoden. Auch Aufteilung in Module ist eine übersichtliche Aufteilung. Die kann auch über Klassen, etwa Ableitung von einer Basisklasse in einem andern Modul oder auch anders erfolgen. Der GuiDesigner unterstützt da die Ableitung von einer Basisklasse in einem anderen Modul.

Es kann natürlich auch Gründe geben, die dagegen sprechen, aber das ist kein Grund, dass andere sich darüber aufzuregen, wenn ich das in meinen DynTkInter Scripten des GuiDesigners anders handhabe. Denn da erfolgt das Nachladen eines Scripts nicht durch eine Funktion im Script, sondern wird von DynTkInter kontrolliert und erfolgt während dem __init__ eines Containerwidgets. Die Code Ausführung des GUI Codes könnte zeilenweise erfolgen, erfolgt aber beim normalen Laden im GUI Designer abschnittsweise, nämlich bis ein Code Part kommt. Der wird dann im Container Widget als Attribut gesichert und bei der Ausführung übersprungen. Nach Ändern der GUI wird dann beim Speichern, nachdem der Code für die GUI des Containerwidgets generiert ist, dieser Code Teil wieder eingefügt. So habe ich immer alles schön beisammmen und brauche schon einmal nicht doppelt soviele Files machen.
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

Sirius3 hat geschrieben:Du verwechselst hier Funktionalität mit Qualität. Die meisten Anfänger möchten möglichst schnell möglichst viel in ihr Programm packen, das ist so lange ok, bis man selbst merkt, dass das Programm nicht mehr wartbar ist. Dann schmeißt man alles weg und macht es besser. Ich muß also nur lange genug warten und die Hoffnung nicht aufgeben.
Der Anfänger mag zwar wirren Code schreiben, der die GUI erzeugt. Deshalb muss er aber seine GUI nicht wegwerfen, denn die existiert danach unabhängig vom Code, der sie erzeugt hat in tkinter. Und bei Ableitung von DynTkInter kann er sie dann mit tk.exportApplication(filename) in einer übersichtlich strukturierten Weise abspeichern - tkinter bietet leider nicht bereits eine derartige Funktion. Und danach wird auch schnell etwas daraus.
Benutzeravatar
noisefloor
User
Beiträge: 3829
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
aber das ist kein Grund, dass andere sich darüber aufzuregen, wenn ich das in meinen DynTkInter Scripten des GuiDesigners anders handhabe.
Nochmal für dich in hoffentlich verständlichem Klartext: was DU für dich programmierst ist alleine deine Sache, keine Frage. Was aber nicht OK ist, ist, wenn du hier im Brustton der Überzeugung Code propagierst, der einfach nur schlecht ist. Schlecht != lauffähig, schlecht != macht,was er soll. Sondern: schlecht im Sinne von stilistisch grottenschlechtem, nicht-idomatischem Python. Das Problem ist auch dabei nicht, dass dich Python-Programmierer mit Erfahrung dich hier schon lange nicht mehr für voll nehmen (das ist ja auch alleine dein Problem), sondern das du, wie auch BlackJack schon diverse Male gesagt, dass unerfahrene Python-Programmierer das mangels besserem Wissen vielleicht für sich adaptieren. Womit du aktiv dabei mit Hilfst, das der betreffende Programmierer schlecht programmiert.

Das hier ist ein öffentliches Forum, jeder Beitrag ist für jeden sichtbar, inkl. den Suchmaschinen-Bots. Das sollte man und du sich immer vor Augen halten, bevor man hier postet. Möglicher Müll ist dann weltweit verfügbarer Müll. Dieser "Verantwortung" bist du dir in IMHO in keinster Weise bewusst. Bzw. vielleicht bist du dir dessen auch bewusst und hast diabolische Freude an dem rumgetrolle, dass du betreibst.

Gruß, noisefloor
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

noisefloor hat geschrieben:Was aber nicht OK ist, ist, wenn du hier im Brustton der Überzeugung Code propagierst, der einfach nur schlecht ist. Schlecht != lauffähig, schlecht != macht,was er soll. Sondern: schlecht im Sinne von stilistisch grottenschlechtem, nicht-idomatischem Python. Das Problem ist auch dabei nicht, dass dich Python-Programmierer mit Erfahrung dich hier schon lange nicht mehr für voll nehmen (das ist ja auch alleine dein Problem), sondern das du, wie auch BlackJack schon diverse Male gesagt, dass unerfahrene Python-Programmierer das mangels besserem Wissen vielleicht für sich adaptieren. Womit du aktiv dabei mit Hilfst, das der betreffende Programmierer schlecht programmiert.
Ich habe hier überhaupt keinen grottenschlechten Code im Brustton der Überzeugung propagiert. Es ging hier um eine Diskussion, ob und wozu man Klassen und Attribute braucht. Und ich habe Beispiele gebracht, dafür dass es auch ohne geht, wie etwa GUI im XML Stil und dann das auch noch sinnlos als nummerierte Funktionen. Wie kommst Du auf die idiotische Idee, dass es Idioten gäbe, die das als Vorbild für guten Code nähmen und dann ihre GUI so programmieren würden. Wer das glaubt, muß schon selber einer sein.

Normalerweise haben auch viele Anfänger Grips im Kopf um zu sehen und abzuwägen, was nützlich ist. Und der Code den ich propagiere, ist der, den mein GuiDesigner erzeugt. Und das ist dieser: viewtopic.php?f=18&t=41126&start=15#p314186

Untersteh Dich, diese Code Struktur als grottenschlecht anzusehen. Diese Struktur steht im Einklang mit stilistisch gutem Code. Und damit gelingt es leicht, sicher auch zu einer komplexen GUI zu gelangen. Und mit Deinen Unverschämtheiten, wie schlecht und grottenschlecht kannst Du aufhören.
Benutzeravatar
noisefloor
User
Beiträge: 3829
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Untersteh Dich, diese Code Struktur als grottenschlecht anzusehen.
Na ja, das ist halt.... Ansichtssache. Das gute ist ja, das da jeder eine andere Ansicht haben darf.

Gruß, noisefloor
BlackJack

@noisefloor: Also ich finde ja auch das „grottenschlecht” dem nicht gerecht wird… :twisted:
Benutzeravatar
noisefloor
User
Beiträge: 3829
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Also ich finde ja auch das „grottenschlecht” dem nicht gerecht wird… :twisted:
Ja, schon. Aber ich habe halt immer einen Hang zur sozial-verträglichen Kommunikation ;-)

Gruß, noisefloor
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

noisefloor hat geschrieben:Hallo,
Also ich finde ja auch das „grottenschlecht” dem nicht gerecht wird… :twisted:
Ja, schon. Aber ich habe halt immer einen Hang zur sozial-verträglichen Kommunikation ;-)
Gruß, noisefloor
Wenn Euch etwas am generierten Code etwas nicht paßt, dann sagt, was Euch nicht paßt. Haltet ihr so eine Einteilung in Klassen nicht für sinnvoll? Dann schlagt etwas anderes vor.
Benutzeravatar
noisefloor
User
Beiträge: 3829
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
dann sagt, was Euch nicht paßt.
Äh.... das machen doch z.B. BlackJack und Sirius3 und auch andere in diversen Threads?!? Nur hinterlässt du hier dann immer stark den Eindruck der akuten Beratungsresistenz. Denn nach einem Verbesserungsvorschlag stellst du den Vorschlag an sich gerne hochgradig in Frage, weißt alles besser und postest dann zum Schluss gerne auch noch neuen Code von dir, der noch grottiger ist als der vorherige.

Gruß, noisefloor
Antworten