Okay danke, ich denke das beantwortet meine Frage
Das Objekt wird als Parameter übergeben und es ist ist relativ ersichtlich, dass das Objekt geändert werden soll.

Wikipedia möchte ein Lexikon sein, keine umfassende kritische Aufarbeitung. Aber unter einem Kritik-Abschnitt könnte man doch auch eine Kritik erwarten, die wenigstens die Zitate im richtigen Kontext bringt, oder? Denn sonst ist das alles andere als Kritik, als viel mehr Propaganda (etwas überspitz...

Hm noch eine andere Frage: Ist es schlechter Stil, dieses Verhalten zu benutzen? Also einfach innerhalb einer Funktion auf ein Objekt außerhalb der Funktion zuzugreifen und zu verändern? Das würde es mir zB ersparen, aufwendig die Rückgabe einer Funktion zu verarbeiten und mit dieser Rückgabe Objekt...

@BlackJack: Wenn deine Vermutungen zutreffen, ist die Kritik im Wikipedia Artikel ziemlich nutzlos und irreführend. Die dort zitierten Aussagen bekommen mit deinen Erklärungen/Vermutungen natürlich eine ganz andere Bedeutung. Das klingt da eher so wie "OOP hört sich gut an, ist aber Scheiße&quo...

Danke für eure Antworten. Ich habe die Frage bewusst provozierend gestellt und habe ja jetzt auch ganz brauchbare Antworten erhalten :) @Leonidas was meinst du mit "eigenem Objektsystem"? Ich kenne Moose oder GObject leider nicht und kann damit also nichts anfangen. Bei dem Produktivitätsa...

Dass OOP nicht immer sinnvoll und notwendig ist, hab ich mittlerweile verstanden, aber was sagt ihr zu dieser Kritik auf Wikipedia? http://de.wikipedia.org/wiki/Objektorientierte_Programmierung#Kritik Richard Stallman schrieb 1995: „Hinzufügen von OOP zu Emacs ist ganz klar keine Verbesserung; ich v...

Ja Tupel oder andere listenähnlichen Typen sind üblich. Aber ich find das total unpraktisch in diesem Fall. Ich versuch's mal schematisch irgendwie darzustellen: Main ------> EventHandler --------> Event -------> Function(args) ------------------> Main ruft auf ruft auf ruft auf Verändert Objekte Al...

Okay, das leuchtet so weit ein.
Ich muss mich nur von dem Gedanken trennen, dass die Namensräume wie in anderen Sprachen funktionieren und mir deine Regel

Eigentlich ist das 'ändern können' die Regel

einprägen

Ja, das Verhalten hab ich mittlerweile erkannt. Neues Objekt an den Namen binden: Nein An den Namen gebundenes Objekt ändern: Ja Das werd ich dann fortan als Tatsache ansehen, mich hat es halt etwas stutzig gemacht. Dass man Objekte von außerhalb lesen kann, war mir schon bekannt und steht an mehrer...

Zu 1: Ich weiß nicht genau, ob ich dein Problem richtig erkannt habe, aber ein Tupel "spam" kannst du mit "*spam" wieder in Parameter umwandeln. Oh man, wie dumm :D Danke, das hab ich eigentlich gesucht. Ich dachte das klappt nur auf umgekehrte Weise. Es geht einfach darum, dass...

Und was ist dann eine "echte" Variable?

Naja, für mich ist das verändert

Dass es kein neues Objekt ist, ist klar, weil das anscheinend das einzige ist, was nicht geht

Ja, der Unterschied zwischen dem, was ich mache ist mir klar. Aber dass ich ein Objekt, welches sich eine Ebene über der Funktion befindet, innerhalb einer Funktion verändern kann, hat mich gewundert. Aber so gesehn ist das Verhalten gar nicht mal schlecht. Wenn man auf objekt.attribut zugreift erhä...

Hm okay.
Wenn das so ist, muss ich's wohl hinnehmen, auch wenn ich das seltsam finde
Ich dachte bisher immer, dass man in Funktionen zwar Variablen aus einer höheren Ebene lesen darf, aber nicht verändern kann.

Hey. Warum ist das so? >>> class foo(): def __init__(self): self.foo = 100 >>> a = foo() >>> b = 100 >>> def bla(): a.foo = 10 >>> def blubb(): b = 10 >>> bla() >>> a.foo 10 >>> blubb() >>> b 100

Danke auch für deine Antwort. Was genau möchtest du mit den Zeilen 4-7 erreichen? Sind die hier nur beispielhhaft oder möchtest du hier alle möglichen Events aufzählen? Letzteres wäre nämlich sehr unflexibel. Beim Ändern nach BlackJacks "Anleitung" hab ich an die Zeilen gar nicht mehr geda...

Ich habe den Code mal überarbeitet und dank deiner Verbesserungsvorschläge kommt mir das ganze schon viel besser vor, danke! :) Der EventHandler ist jetzt beispielweise komplett unabhängig von der konkreten Implementierung des Events und ruft einfach nur die __call__ Methode auf. class EventHandler(...

@Nocta: ``if``/``elif``\s mit Typtests wo dann pro Typ etwas anderes gemacht wird, ist bei OOP ein Code-Smell. Das hat man "vor" OOP gemacht und das hat halt Nachteile. Zum Beispiel das man für jeden neue Typ all diese Tests in Programmen suchen und um den neuen Typ erweitern muss. Ja das...

Danke für deine Antwort. @Nocta: Ich finde die `isinstance()`-Tests und das mit dem Test auf `__call__` "unpythonisch", bzw. das mit dem `isinstance()` auch un"OOP". Sorry, aber was meinst du mit dem Zusatz un"OOP"? (Vielleicht irgendwo verrutscht?) Und was schlägst du ...

Hallo. Ich spiele gerne sinnlos mit Python rum und hab mir jetzt mal ein Eventsystem gebaut, das eben Events verwaltet. Keine Events im Sinne von Partyevents, sondern Auslöser für irgendwelchen Programmcode ;) Beispielsweise für ein Spiel, in dem für jede Aktion theoretisch ein Event ausgelöst werde...