Das deutsche Python-Forum

Ich hab mir mal eine kleine IRC Lib geschrieben. Zu finden ist sie hier. Das ganze ist größtenteils nur eine Portierung der Twisted IRC Komponente auf sockets mit imho besserer Unterstützung für mehrere Server.

DasIch hat geschrieben:nur eine Portierung der Twisted IRC Komponente

Ich fand Twisted.Words IRC blöd insofern, weil sie im Gegensatz zu Twisted eben keine Deferreds verwendet

Ich hab absolut keine Ahnung was "Deferrds" sind, dass hier?

Wie würdest du dir den Einsatz in dem Zusammenhang vorstellen(Beispiel?)? Da lässt sich ja sicherlich was machen.

DasIch hat geschrieben:Ich hab absolut keine Ahnung was "Deferrds" sind, dass hier?

"Deferred"

In Twisted sieht das in der Regel so aus, dass du eine Aktion ausführst und... sie nicht passiert. Stattdessen bekommst du einen Deferred, das ist ein wenig wie ein Versprechen dass die Aktion irgendwann passiert. An diesen Deferred kannst du nun Callbacks binden, die ausgeführt werden wenn die Aktion fehlerfrei durchläuft (die bekommen dann auch die Rückgabewerte der Aktion) oder auch andere Callbacks binden, die aufgerufen werden, wenn Fehler passieren. Ich habe mal ein wenig an Twisted Words IRC gespielt um zu gucken, wie weit man das inzwischen ergänzen könnte, aber das ist bisher nicht weit gekommen. Das zu Unitttesten war ätzend, insbesondere da Twisted da kein einheitliches Interface bietet.

Ah ok, also man ändert z.B. den Nickname bekommt vom Server eine Antwort wenn alles ok ist und die Callbacks die an dass deferred gebunden sind werden aufgerufen.

Klingt definitiv interessant und sicherlich eine sehr sinnvolle Sache dass zu haben um das ganze einfacher zu machen. Ich denke ich werde damit mal etwas experimentieren.

DasIch hat geschrieben:Ah ok, also man ändert z.B. den Nickname bekommt vom Server eine Antwort wenn alles ok ist und die Callbacks die an dass deferred gebunden sind werden aufgerufen.

Ja. Der Aufruf den Nick zu ändern blockiert in der Zeit nicht, sondern kommt sofort zurück. Man kann natürlich an dieser Stelle nicht davon ausgehen, dass es geklappt hat, aber das kennt man ja aus JavaScript.

So (ungetestet) lib und defer?

Kann natürlich bei weitem nicht soviel wie Twisteds Deferred ist aber imho zumindest momentan noch nicht notwendig.

P.S.:Ja, ich mag Dekoratoren

DasIch hat geschrieben:So (ungetestet) lib und defer?

Wenn ich jetzt mal in den Code schaue: ja, so ähnlich. Das Problem ist an dieser Stelle, dass du die Callbacks in einer globalen Variable hast, womit Multi-Server-Verbindungen im Moment ausgeschlossen sind. Vielleicht interessiert dich ja mein Twisted Branch, wo ich versucht habe Deferreds in Twisted Words IRC reinzupacken. Das Problem ist bei IRC leider das, dass man nicht weiß was da für eine Antwort auf welchen Request kommt. Insbesondere mit NAMES hatte ich recht viel Ärger. Da müsste man ein wenig Arbeit investieren und masochistisch genug sein, die Unittests weiterzuschreiben (man muss eigene Mock-Objekte definieren, weil irgendwie bei Twisted keiner daran gedacht hat, dass sowas nützlich wäre etc).

Ich bin momentan dabei das ganze mal damit neuzuschreiben. Callbacks werde ich in die ServerConnections legen.

Ich werde einfach allen Aktionen die dass möglich machen einen entsprechenden Dekorator verpassen und die Replys bekommen dann einen mit dem Namen der Aktion.

Ich hab erst überlegt die Twisted Deferreds komplett zu portieren aber der Code ist teilweise hässlich, unnötig kompliziert und es wird sich nicht an PEP 8 gehalten. Also eigentlich wie der Rest von Twisted auch. Noch ein paar Jahre und der Code sieht so aus wie ich mir Windows Quellcode vorstelle aber hey es ist abwärtskomptibel.

DasIch hat geschrieben:Ich hab erst überlegt die Twisted Deferreds komplett zu portieren aber der Code ist teilweise hässlich, unnötig kompliziert und es wird sich nicht an PEP 8 gehalten. Also eigentlich wie der Rest von Twisted auch. Noch ein paar Jahre und der Code sieht so aus wie ich mir Windows Quellcode vorstelle aber hey es ist abwärtskomptibel.

Hrhr, das habe ich mir auch irgendwie gedacht

Der Vorteil liegt eben darin, dass es massiv viel Code schon gibt. Auch wenn der großteils ätzend ist - ich habe aber keine Ahnung warum genau, denn die Twisted-Leute scheinen gar nicht so blöd zu sein.

Vergiss bitte bei deiner Reimplementation von Twisted nicht, eine gescheite Unittesting-Möglichkeit zu spendieren

Also irgendwas mit Nose und brauchbarem Mocking.

Code: Alles auswählen

    if not channel[0] in '&#!#':
        return '#' + channel

Warum zwei #?

Ansonsten bist du leider etwas zu spät

Hab mir vor ein paar Tagen selber eine winzige IRC lib geschrieben.

Gruss,
Jonas

PS: Wie siehts eigentlich mit der Lizenz auf?

veers hat geschrieben:PS: Wie siehts eigentlich mit der Lizenz auf?

Do What The Fuck To Public License
Wenn schon FLOSS dann richtig

Danke für den Hinweis zu den zwei #, da bin ich eine Taste zu tief gerutscht.

Da fehlt noch ein "you want"

So da wären wir. Kann man noch nicht viel mit anfangen aber das Prinzip sollte klar sein. Ich werd mir jetzt erstmal die restlichen 4h + 20min Schlaf die mir noch bleiben gönnen

DasIch hat geschrieben:P.S.:Ja, ich mag Dekoratoren

Dann könntest du `functools.wraps()` ganz hilfreich finden.

Danke, dass ist natürlich genial

Leonidas hat geschrieben:Das Problem ist bei IRC leider das, dass man nicht weiß was da für eine Antwort auf welchen Request kommt.

Man kennt ja die Möglichkeiten.

Insbesondere mit NAMES hatte ich recht viel Ärger. Da müsste man ein wenig Arbeit investieren und masochistisch genug sein, die Unittests weiterzuschreiben[...]

Names? Wo ist da die Problematik? Hast du Unittests selbst für die Deferreds bei jedem Befehl?

Momentaner Stand ist dass ich isupport implementiert habe und dabei bin Befehl für Befehl aus dem RFC zu implementieren. Ich muss noch den ganzen Mode Kram implementieren und einige Befehle. Ich möchte vorallem verhindern Dinge an den Server zu senden bei denen ich schon vorher weiß dass dabei nichts bei rum kommt(kicken ohne dass man OP ist usw.).

Nur damit ihr nicht glaubt dass ganze wäre schon Tod

Warum verwendest du locals?

Ersetz doch einfach jeden Namen mit dem fertig konfigurierten Objekt in dem dict. Ausnahmebehandlung geht dann direkt über dict Zugriff. Und das "copy" Zeug da würd ich in eine "clone" Methode des Exception Prototyps auslagern.

Klassen Klonen würde ich so machen:

Code: Alles auswählen

In [6]: class A(object):
    @classmethod
    def clone(cls, name=None):
        if name is None: name = cls.__name__
        cloned = cls.__class__(name, (object,), cls.__dict__.copy())
        return cloned
   ...:     
   ...:     

In [10]: B = A.clone("Fish")

In [11]: B
Out[11]: <class '__main__.Fish'>

Übringens habe ich prototyping durch die Sprache Io vor kurzem zu Schätzen gelernt, insofern empfinde ich das als nichts, wofür man sich entschuldigen müsste (und "to much stupid code" meint wogl zig Subklassen?)

Statt dem hier:

Code: Alles auswählen

    wrapper.__name__ = f.__name__
    wrapper.__doc__ = f.__doc__

kannst du wie weiter oben erwähnt functools.wraps benutzen.

Die vielen Strings unbedingt noch in Konstante, globale Variablen umwandeln. Liest sich besser und ist flexibler. Insbesondere "\r\n" macht bei sowas viel Spaß. Ist das eigentlich was IRC internes? Ansonsten gibts os.linesep.

DasIch hat geschrieben:Man kennt ja die Möglichkeiten.

Eben nicht. Wenn man mehrere Parallele NAMES ausführt, einige für einen Channel, einige führ mehrere Channels und einen für alle Channels kann man nicht mehr zuordnen, welche Antowort zu welchem Reuest passt und kann also nicht zuverlässig die entsprechenden Deferreds auslösen.

DasIch hat geschrieben:Hast du Unittests selbst für die Deferreds bei jedem Befehl?

Natürlich teste ich die Deferreds und gucke ob die richtig ausgelöst werden. Und da teste ich lieber in Unittests als dann die Clients im Real-World Betrieb aufgrund von Race-Conditions nichtreproduzierbaren Müll zurückbekommen.

Leonidas hat geschrieben:Wenn man mehrere Parallele NAMES ausführt[...]

Hm, daran hab ich nicht gedacht, allerdings könnte ich meinen Wrapper anpassen dann passt dass wieder.

Das deutsche Python-Forum

kleine irc lib

kleine irc lib

Re: kleine irc lib