kleine irc lib

[Leonidas]

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

Und wie ordnerst du den NAME-Reply den richtigen Deferred zu? Spätestens wenn jemand einen Channel anfordert und danach alle, weißt du nicht welche Antwort zu welchem Request gehört.

[DasIch]

Warum verwendest du locals?

Das war quick'n'dirty und auf jedenfall kürzer als dein Code

Ersetz doch einfach jeden Namen mit dem fertig konfigurierten Objekt in dem dict. Ausnahmebehandlung geht dann direkt über dict Zugriff.

Bisschen großer Aufwand für Informationen die statisch vorliegen könnten oder?

Und das "copy" Zeug da würd ich in eine "clone" Methode des Exception Prototyps auslagern.

Wieder jede Menge Code dafür

Ü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?)

Ich hatte keine Lust die alle selbst einzutippen. Inzwischen hab ich mir den Code einmal komplett generieren lassen und hab nun ein exc Modul wo die ganzen Exceptions drin sind. War mit einem kleinen Skript schnell erledigt und die Lösung ist imho am sinnvollsten.

Die vielen Strings unbedingt noch in Konstante, globale Variablen umwandeln.

Welche vielen Strings?

Insbesondere "\r\n" macht bei sowas viel Spaß. Ist das eigentlich was IRC internes?

Ja. damit werden die Nachrichten voneinander getrennt, dafür brauche ich aber keine Konstante. Das wäre ja als ob man sich SQL Strings selbst zusammensetzt.

Spätestens wenn jemand einen Channel anfordert und danach alle, weißt du nicht welche Antwort zu welchem Request gehört.

Ich gehe mal davon aus dass der Server die Replys nicht willkürlich durcheinander schickt, dann wäre es tatsächlich unmöglich. Wenn ich die RPL_ENDOFNA MES bekomme sollte es möglich sein die vorher erhaltenen RPL_NAMREPLYs anhand der übergebenen Argumente zuzuordnen.

Wobei ich sowieso vorhabe einfach JOIN, PART und QUIT Nachrichten zu verfolgen und so selbst eine lokale User Liste vorzuhalten für die Channels in denen ich bin. NAMES sendet mir sowieso nur Informationen über User die ich sowieso sehe.
Wenn man eine Liste der Nicks für einen IRC Client oder so haben will, bleibt mir sowieso nichts anderes übrig. Man kann ja schlecht alle paar Minuten ein NAMES an den Server schicken.

[str1442]

Das war quick'n'dirty und auf jedenfall kürzer als dein Code Wink

Und die Ersparnis von vielleicht 10 Zeilen spricht nun für locals? Warum benutzt du dann nicht gleich

Code: Alles auswählen

setattr(__builtins__, numeric_to_symbolic[number], eval("type(%s, (Exception,), {})" % numeric_to_symbolic[number])

.

Ich hatte keine Lust die alle selbst einzutippen. Inzwischen hab ich mir den Code einmal komplett generieren lassen und hab nun ein exc Modul wo die ganzen Exceptions drin sind. War mit einem kleinen Skript schnell erledigt und die Lösung ist imho am sinnvollsten.

Codegenerierung ist idR keine gute Idee. Damit machst du Dinge nur unnötig statisch, unanpassbar, unmaintainable weil groß.
Warum willst du es überhaupt statisch haben?

Ist ja nicht so, das ich hier von 400 extra Zeilen spreche.

Wieder jede Menge Code dafür

14 Zeilen? Erzähl mir nicht, deine Ausflüge in die Metaprogrammierung ergaben kürzeres.

Welche vielen Strings?

In parse(). Gut, globals müssens nicht sein, aber locals vielleicht. ":" und " :" sind zb kontextbehaftet, und sowas sollte man imho immer mit einem Variablennamen versehen, der natürlich auch gut benannt ist. Liest sich besser, macht keinen Aufwand und solltest du die Funktion erweitern wollen, ist das auch einfacher. Dann überprüfst du in "to_irc" direkt mit einem hardgecodeten String, ob eben dieser im Dict zu finden ist. Das ist doch wieder vom Kontext komplett losgelöst. Irgendein Dict kommt rein, irgendein hardgecodeter String wird benutzt, der per se mit dem Rest des Programmes höchstens semantisch etwas zu tun hat. Sowas gehört imho in globale Variablen.

Ja. damit werden die Nachrichten voneinander getrennt, dafür brauche ich aber keine Konstante. Das wäre ja als ob man sich SQL Strings selbst zusammensetzt.

Rein prinzipiell würde ich für sowas Konstanten benutzen. Aus oben genannten Gründen. Was du da machst, ist (wenn im größeren Stil eingesetzt) in etwa so, wie jeden String aus Gründen des Speichersparens in einem Programm komplett auszuschreiben, nur weil man weiß, das höchstwahrscheinlich keine anderen Strings irgendwo ankommen. Oder überall lambda Statements statt Funktionen und die auch nicht in Variablen festzuhalten. Klingt jetzt extrem, aber so rein prinzipiell...

[DasIch]

Codegenerierung ist idR keine gute Idee. Damit machst du Dinge nur unnötig statisch, unanpassbar, unmaintainable weil groß.
Warum willst du es überhaupt statisch haben?

Richtig, aber beim IRC Protokoll wird sich nicht alle paar Wochen was ändern.

Genauso sieht es mit den IRC Messages aus, die werden auch noch ewig so aussehen ohne dass sich daran irgendwas grundlegendes ändert. Statt irgendwelche Konstanten zu verwenden die den Code verständlicher machen sollen, schreibe ich lieber gleich Kommentare, die dass ganze erklären. Dann bekomme ich auch nicht solche Probleme