@Sophus: Ich weiß gar nicht recht, wie in anfangen soll, dir zu helfen. Vielleicht so:
Wenn Begriffe auftauchen wie zB.
List Comprehension, dann haben diese idR. eine genaue und fest begrenzte Bedeutung. Das hier ist eine
List Comprehension:
Das hier nicht:
Im ersten Fall wird die Operation
x + 3 auf jedes Element
x einer Reihe von Werten angewandt, im zweiten Fall stehe Werte explizit im Source Code hintereinander und keine Operation wird darauf angewendet. Damit etwas eine
List Comprehension ist, muss es nicht nur in eckigen Klammern stehen, sondern es muss zudem auch eine spezifische grammatische Struktur besitzen, nämlich diese:
... for ... in ..., mit einem optional folgenden
if ... . An den
... Stellen darf nicht beliebiges stehen. Hier ein paar ungültige Varianten:
Zwischen
for und
in muss ein sog.
L-Value stehen. Letzteres ist ein in vielen Sprachen auftauchendes Konzept, es bezeichnet solche sprachlichen Konstrukte, die links von einem Zuweisungszeichen stehen dürfen.
123 ist kein
L-Value wie man hier sehen kann:
Code: Alles auswählen
>>> 123 = 456
File "<stdin>", line 1
SyntaxError: can't assign to literal
Auch das hier ist keine gültige
List Comprehension:
Weil man über
123 nicht iterieren kann.
Desweiteren fehlen die Klammern in
self.ui_pp_feedback.textEditFeedback.toPlainText, damit die Funktion ausgeführt wird. So, wie der Ausdruck dasteht, benennt er einfach nur ein Ding, welches hier eine Funktion ist. Um das zu verdeutlichen:
Code: Alles auswählen
>>> def foo():
... return 123
...
>>> foo
<function foo at 0xb6eda6a4>
>>> foo()
123
Ich habe dir recht früh schon geschrieben, dass die beste Variante, Strings auf "Leerheit" zu testen diese hier ist:
Du dagegen ersetzt die sehr komplizierte Variante durch eine weniger, aber immer noch zu komplizierte Variante. Ich hatte sogar Yehova gesagt (d.i., ich hab mich auf PEP8 berufen). Wenn du die Ratschläge nicht annimmst, warum fragst du dann überhaupt? Und wenn du jetzt antworten willst "Weil die Vorschläge nicht funktioniert haben", dann solltest du dich ernsthaft fragen, was wahrscheinlicher ist, dass einige Berufsprogrammierer mit zT. mehr als zwanzig Jahren Berufserfahrung dir etwas falsches sagen, oder dass du etwas nicht richtig verstanden hast?
Auch bringst du immer so seltsame Dinge an, die keiner mehr ernsthaft machen würde, wie zB.
Ungarische Notation. Du schriebst, du würdest das wegen der Leserlichkeit tun. Ich kann nichts leserliches an
ui_pp_feedback finden. Was soll denn ein
pp sein?
ui hat vermutlich irgendetwas mit dem User Interface zu tun, aber nachdem hier in QT-Programm geschrieben werden soll, muss man mir das irgendwie nicht noch zusätzlich sagen. Oder findest du, ein Auto wird dadurch besser bedienbar, wenn "Auto" draufsteht? Ich empfehle wirklich, den Aufsatz von Charles Simonyi zu lesen. Dann wirst du sehen, dass du - wie die meisten, die Ungarische Notation zu verwenden glauben -, etwas fundamental falsch verstanden hast. Und auch den von mir verlinkten Spott-Artikel solltest du lesen, darin werden die Probleme der UN deutlich gemacht.
Wenn wir hier von
Idiomen,
Pattern und
Anti-Pattern schreiben, dann meinen wir nicht: "Du musst diese Dinge tun/bleiben lassen, weil du sonst einen fremden Stallgeruch hast und wir dich dann nicht mehr mögen". Was wir meinen ist: "Es haben sich im Laufe der letzten gut zwanzig Jahre seit es Python gibt bestimmte Konstruktionen als in irgendeiner Fom nützlich erwiesen. Wenn du dir dein Leben einfach machen möchtest, verwende diese Konstruktionen." Ich wittere hier ja das Problem des soziologischen Standpunkts. Dieser ist, dass man glaubt, alles aus dem Gruppenverhalten erklären zu können und es folglich daneben keine andere Erklärung geben kann. Etwas ähliches findet man bei Kaufleuten. Wenn man versucht, denen zu erklären, das das, was sie gebaut haben möchten, nicht programmniert werden kann, da der Algorithmus selbst dann länger laufen würde, als das Universum noch leben wird, wenn man alle auf der Welt existierenden Computer gleichzeitig verwenden könnte. Sie hören dann nur "Dieser Programmierer bringt als Verhandlungsmasse ein Techno-Geblubber, damit er irgendwelche Vorteile (mehr Teammitglieder, mehr Zeit, ...) rausschlagen kann." Der kaufmännische Standpunkt ist dabei, dass alles Verhandlungssache ist, weil das Ziel des Kaufmanns der Abschluss eines Vertrages ist, und den muss man eben aushandeln. Programmieren geht aber so nicht.
Übrigens gibt es ähnliches auch bei vielen Programmierern. Programmieren ist die Anwendung der Wissenschaft der Prozesse im allgemeinsten, abstraktesten Sinn von "Prozess". Viele Programmierer können alles nur in diesem Bezugsrahmen interpretieren. Wenn sie vor ein soziales Problem gestellt werden, suchen sie zuerst mal eine technische Lösung dafür. Was natürlich fast nie gelingt.
git oder
mercurial werden zB. nicht helfen, wenn alle Dateien permanent von allen gleichzeitig bearbeiten, weil dann das Mergen mehr Zeit beansprucht, als das VCS einem einspart.
Im übrigen gilt für die Idiome Pythons, dass die wichtigen nicht nur in PEP8 stehen, sondern dort auch illustriert und begründet werden. Würdest du PEP8 mal intensiv durchgehen, würdest du von uns nicht erwarten, dir dieselben Erklärungen hier wieder hinzuschreiben, die dort schon stehen. Wievielen Python-Beginnern meinst du, sollte man das Tutorial, die Dokumentation oder PEP8 hier einzeln schriftlich vorlesen? Weil doch Sekundärliteratur immer besser ist, als das Original? Oder weil nur der ein geeigneter Helfer sein kann, der es dadurch beweist, dass er gut Texte abschreiben kann?
Ein
break ist kein
goto, sonst hieße er
goto. Beim Programmieren muss man genau (ja, spießig) sein, denn Laxheit funktioniert nicht. Wenn ich dem Computer nur so ungefähr sage, was er tun soll, dann wird er auch nur so ungefähr tun, was ich will. Außerdem ist ein
break immer in einer Schleife, alles andere wäre ein Syntaxfehler:
Sophus hat geschrieben:@BlackJack: Das heißt nun was? Der break muss also innerhalb des Schleifenkörpers in den else-Block? Etwa so?
Code: Alles auswählen
if field.trimmed():
print "No error"
else:
self.show_msgbox_error()
break
So liegt der Break nicht in der For-Schleife, sondern im else-Block. Damit wird nur dann abgebrochen, wenn ein Fehler vorliegt.
Wenn du in einem Auto sitzt und dir, sagen wir eine Euromünze in die Hosentasche steckst, ist die Münze dann nicht mehr im Auto?
Sophus hat geschrieben:Code: Alles auswählen
editFields = [self.ui_pp_feedback.textEditFeedback]
for editField in editFields:
self.var_editfield = editField.toPlainText()
print self.var_editfield
Das ist die kompliziertese Weise, die ich je gesehen habe, um das hier zu schreiben:
Code: Alles auswählen
self.var_editfield = self.ui_pp_feedback.textEditFeedback.toPlainText()
print self.var_editfield
Kannst du erklären, warum du eine ein-elementige Liste erzeugst, die du für nichts anderes verwendest, als dafür, das eine Element in einer for-Schleife (die genau einmal durchlaufen wird) auszupacken und dann auf dem vorher eingepackten Element zu operieren? Welchen Vorteil haben dabei die Liste und die Schleife?
Wie würde ich das Problem der Input-Validierung lösen? Vermutlich mit dem Model-View-Controller-Pattern, also zB. so:
http://www.python-forum.de/pastebin.php?mode=view&s=421. Das bitte nur als Illustration eines Konzepts betrachten. GUI-Frameworks haben solche Mechanismen idR. bereits eingebaut, so dass man sie gleich verwenden kann. In
tkinter gibt es zB. Variablen-Klassen wie
StringVar, bei denen man Observer (also Views) mittels
trace() registrieren kann. Ich habe es nur ausprogrammiert, damit man leichter sehen kann, was wie zusammenhängt.
Anscheinend bin ich noch von dieser Thematik weit entfernt. Es ist nur so, dass in VB6 das Überprüfen der Textfelder ein "leichtes" wär, und hier sich wie eine monströse Aufgabe für mich herausstellt. Hättest du denn ein Pseudo-Code, damit ich in meinem Denkanstoß weiterkomme? Ich will keine lauffähige Codes, zumindest nicht in diesem Fall.
Es geht nicht um die strip-Methode, sondern um den Test auf einen leeren String.