Funktionsdefinition

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
mathi
User
Beiträge: 314
Registriert: Dienstag 27. November 2007, 14:30

Funktionsdefinition

Beitragvon mathi » Freitag 22. Februar 2008, 10:20

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. :oops:
BlackJack

Beitragvon BlackJack » Freitag 22. Februar 2008, 10:26

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
User
Beiträge: 314
Registriert: Dienstag 27. November 2007, 14:30

Beitragvon mathi » Freitag 22. Februar 2008, 10:33

Mensch, wirklich wahr :oops: (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 :wink:

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
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Beitragvon CM » Freitag 22. Februar 2008, 10:50

2900 für ein Modul sind auch so etwas viel. Jedenfalls in den allermeisten Fällen. Ggf. ist das ein Anlaß zum Refaktoring? *winkmitdemzaunpfahl*
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Freitag 22. Februar 2008, 11:10

CM hat geschrieben: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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
mathi
User
Beiträge: 314
Registriert: Dienstag 27. November 2007, 14:30

Beitragvon mathi » Freitag 22. Februar 2008, 11:14

ich finde 3000 auch nicht gerade viel, wenn man es übersichtlich macht!
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Freitag 22. Februar 2008, 11:44

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Freitag 22. Februar 2008, 11:59

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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
BlackJack

Beitragvon BlackJack » Freitag 22. Februar 2008, 12:05

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

Beitragvon BlackJack » Freitag 22. Februar 2008, 12:13

@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
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Beitragvon CM » Freitag 22. Februar 2008, 12:58

CM hat geschrieben: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 ...
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Freitag 22. Februar 2008, 13:12

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Freitag 22. Februar 2008, 13:54

Leonidas hat geschrieben: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.
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
lunar

Beitragvon lunar » Freitag 22. Februar 2008, 13:56

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

Beitragvon BlackJack » Freitag 22. Februar 2008, 14:29

@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.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder