Funktionsdefinition

[mathi]

hallo allerseits,
ich habe folgendes definiert:

Code: Alles auswählen

 

def funk():
       global a
       # berechne a

while True:
    funk()
    foo = ask_raw_input('nochmal? [j/N]? [N]','n') 
     if foo.lower() == 'n' or foo.lower()=='0': 
         break

beim 1. Aufruf klappt es, beim 2. Aufruf wird die Funktion nicht mehr als solche erkannt:

Code: Alles auswählen

Traceback (most recent call last):
  File "e:\Eigene Dateien\Code\beispiel.py", line 2951, in <module>
    funk()
TypeError: 'int' object is not callable

ich möchte die Funktion gerne außerhalb der while-Schleife definieren, da es mehrere Schleifen gibt, die auf die Funktion zugreifen.

[BlackJack]

Es wäre nett, wenn Du keinen Quelltext präsentierst, der das Problem gar nicht hat.

In Deinem *echten* Quelltext wird irgendwo in den mindestens 2951 Zeilen der Name `funk` auf Modulebene an eine ganze Zahl gebunden. Die Ausnahme ist da doch recht deutlich.

[mathi]

Mensch, wirklich wahr (jetzt schäme ich mich)!

und ich dachte funk() wird mangels anderer definition als int erkannt, aber natürlich habe ich in funk() eine funk=int(a)
definiert.
Vielen Dank

P.S. Im übrigen dachte ich, die 2900 Zeilen sind zum posten zu viel und habe eine kürzere Variante versucht. Jaja ich weiß, hätte ich vielleicht besser nachdenken sollen.

[CM]

2900 für ein Modul sind auch so etwas viel. Jedenfalls in den allermeisten Fällen. Ggf. ist das ein Anlaß zum Refaktoring? *winkmitdemzaunpfahl*

[gerold]

2900 für ein Modul sind auch so etwas viel.

Hallo CM!

Finde ich nicht. Ich halte es sogar für umständlich, wenn Teile in Module ausgelagert werden die alleinstehend nicht funktionieren können. -- Aber bei 10000 Zeilen ist auch bei mir Schluss.

Ich hatte am Anfang bei einem meiner Projekte über 15 Module die miteinander zusammen spielten. Ich verlor den Überblick. Erst als ich die vielen kleinen Module in drei mittelgroße Module zusammenpackte, wurde das Projekt wieder durchschaubar.

lg
Gerold

[mathi]

ich finde 3000 auch nicht gerade viel, wenn man es übersichtlich macht!

[Leonidas]

Ich finde 2500 schon ziemlich viel. Eigentlich ist 1000 in aller Regel schon ein Anzeichen, dass es zu lang ist. Wenn es sich nicht aufteilen lässt, also eine Aufteilung "künstlich" erscheint, dann ist das ein Anzeichen dafür, dass Refactoring nötig wäre. Oder dass man lernen sollte, wie Schleifen funktionieren

Module sind ja wie Klassen auch kein Selbstzweck. Sie gruppieren ähnliche Funktionalität, nicht aber grob ähnliche. Ein Programm welches aus riesigen Modulen besteht wird unübersichtlich, unmodular und damit schwer zu warten.

[gerold]

Hallo!

Wenn man GUIs erstellt, dann kommen schon mal ein paar Codezeilen zusammen. Und nur weil die Definition eines Frames, die darin enthaltenen Widgets und die zugehörigen Event-Handler über 3000 Zeilen ausmachen, komme ich nicht im Traum auf die Idee, diese Dinge auseinander reißen zu wollen. -- Weil sich irgendjemand einbildet, dass mehr als 1000 Zeilen (einfach so dahin gesagt) ein Grund für ein Refactoring sein soll? Und die Event-Handler auslagern??? Ich bin doch kein Masochist.

lg
Gerold

[BlackJack]

Ich schliesse mich Leonidas an. Vor allem weil man in Python in 3000 Zeilen echt viel Funktionalität unterbringen kann, die in anderen Sprachen locker mal das doppelte an Zeilen "kostet", selbst wenn Zeilen, die nur eine schliessende geschweifte Klammer enthalten, nicht mitgezählt werden.

Wenn man es übersichtlich macht, *kann* man 3000 Zeilen Python in einem Modul noch rechtfertigen. Nur kann es kaum übersichtlich sein, wenn Funktionen Werte über ``global`` "zurückgeben" und Code auf Modulebene abläuft.

[BlackJack]

@gerold: GUI Code fällt ja auch aus dem Rahmen, weil's in der Regel oft eine Menge *Daten* sind, die sich als Code "verkleiden".

Und ja eigentlich sollte man die Handler davon trennen, zum Beispiel in dem man die GUI wirklich als Daten lädt (Beispiele: Glade XML oder Qt's `*.ui`-Dateien) und im Quelltext dann wirklich nur noch den Code für die Handler stehen hat.

[CM]

2900 für ein Modul sind auch so etwas viel. Jedenfalls in den allermeisten Fällen. Ggf. ist das ein Anlaß zum Refaktoring?

Wollte auch nur anregen - nicht "besserwissen". GUI-Code ist natürlich eine Ausnahme - aber das oben laß sich nicht wie GUI-Code. Letztlich muß mathi das für sich selbst entscheiden. Aber das "global" ließ mich vermuten, daß es durchaus Spielraum für Optimierungen gibt ...

[Leonidas]

Gerold, es gibt durchaus Tools um GUIs zu erstellen, sowohl wxPython als auch PyGTK haben ihre Datenformate dafür (die dir sicherlich auch bekannt ist ). Das muss kein Code sein. Das als Code zu haben lohnt sich eigentlich nur für für ganz ganz kleine Sachen. Oder Dinge die arg kompliziert sind. Aber selbst da kommen keine 3000 Zeilen zustande.

Unter Windows ist es ja in der Regel auch nicht anders - der Hauptdialog einer Applikation ist selbst geschrieben, die Dialoge kommen alle aus den Ressource-Dateien. Wenn man Reshacker mal anwirft, kann man nachsehen, was da so drin ist.

[gerold]

Gerold, es gibt durchaus Tools um GUIs zu erstellen, sowohl wxPython als auch PyGTK haben ihre Datenformate dafür

Hallo Leonidas!

Ich arbeite gerne mit Vererbung. Ich erstelle z.B. ein Panel mit den wichtigsten Dingen und verwende dieses Panel als Basis für die verschiedensten, anderen Widgets. Das ist nur *ein* Beispiel. Das mache ich auch mit Frames und anderen Containern. Das ist genau das, was mir bei Visual Basic 6 so gefehlt hat und was mir beim Programmieren von GUIs mit wxPython so viel Spaß macht. Ich kann die Objekte von einem Container in einen anderen Container hin und her reichen, wie es mit gefällt.

Leider ist diese Art der Wiederverwendung von Objekten mit externen GUI-Beschreibungsdateien nicht so durchschaubar wie gewünscht.

Weiters muss man auf Codevervollständigung verzichten, wenn man externe GUI-Beschreibungsdateien verwendet. Man könnte das bei WingIDE umgehen, wenn man jedes Widget im Quellcode mit ``assert isinstance(...)`` bekannt macht. Aber das ist alles umständlicher als die GUI, wie so schön in "wxPython in Action" beschrieben, im Programm aufzubauen.

Früher, als unerfahrener Programmierer, habe ich mir von Anderen öfter mal etwas einreden lassen, was ich mir später umständlich wieder abgewöhnen musste -- damit die Programme termingerecht fertig werden. Heute habe ich genug Quellcode und Erfahrung auf Lager, um abschätzen zu können, ob es ein Programm verkompliziert oder nicht, wenn ich es aufteile. Wenn ich merke, dass ein Programm durch Aufteilen einfacher wird, dann mache ich das. Wenn ich das Gefühl habe, dass das nicht der Fall ist, dann mache ich es nicht.

Die Entscheidung, ob ich ein Programm aufteile, liegt bei meinem Bauchgefühl und ich bin nicht gewillt, mir von irgendjemandem irgend eine fixe Zeilenzahl einreden zu lassen. Und wenn ich es schaffe, ein Programm mit 20.000 Zeilen (übertrieben) in einer Datei übersichtlich zu halten, dann mache ich das auch.

Nur weil es hier Leute gibt, die nur mit Editoren arbeiten und nicht per Mausklick von einer Funktion in die Nächste oder in eine andere Klasse springen können und im Code keine Breakpoints oder Bookmarks setzen können, muss ich mich ja nicht auf diese Ebene begeben.
Ich arbeite mit Tools, die mir das Programmieren leichter machen und ohne die ich wahrscheinlich keinen Spaß am Programmieren hätte und mit diesen Tools fühlen sich Fleckerlteppich-Programme nicht so gut an, wie ein paar tausend Zeilen gut strukturierter Code.

NUR auf Basis einer Zeilenanzahl zu urteilen, ob ein Programm umstrukturiert werden soll oder nicht? Es wird immer verschiedene Meinungen dazu geben.

lg
Gerold


PS: Na super, das ist heute schon das zweite Forum, in dem ich meine (abweichende) Meinung verteidigen muss.

[lunar]

Also ich muss schon sehr bitten... diese Kritik ist total ungerechtfertigt! Im Gegenteil, gerold hat unseren vollsten Respekt verdient! Dreitausend Zeilen GUI Code müssen ja auch erstmal geschrieben werden! Das ist schon eine Leistung... ich wäre ja vor Langeweile gestorben, aber gerold hat das tapfer durchgehalten. Respekt gerold!

scnr
lunar

PS: Um Missverständnissen vorzubeugen: Natürlich sehe ich die Sache genau so wie Leonidas, und würde nicht mal - wie BlackJack - für GUI-Code eine Ausnahme machen. Zum einen gibt es, wie schon angemerkt wurde, bessere Formate für GUI-Beschreibungen als Python-Code, zum anderen gibt es ja Pakete und somit auch die Möglichkeit, den GUI-Code innerhalb eines gui-Pakets noch weiter zu unterteilen und Widgets so z.B. nach Aufgabenbereichen oder Fensterklassen zu gruppieren.

[BlackJack]

@gerold: Du sagst letztendlich selber, dass der Quelltext unübersichtlich ist, weil Du nicht nach Übersichtlichkeit an sich gehst, sondern nach dem wie Deine IDE am besten damit klar kommt. Offensichtlich kann sie mit einem grossen Modul besser als mit mehreren kleineren. Was dann aber wohl ein Problem der IDE ist. Dass Du semantisch die Unterteilung in mehrere Module manchmal gerne haben würdest, sieht man daran, dass Du es okay findest (statische) Klassen als Namensräume zu missbrauchen.