Callmonitor für die FritzBox

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

maxi_king_333 hat geschrieben:Ich finde das mit den Funktionen und den Parametern irgendwie unleserlich
Also wenn's an der `getattr`-Magie liegt, die könntest du auch mit einem Methoden-Lookup-Dictionary ersetzen, das etwa so aussieht:

Code: Alles auswählen

{'ring' : on_ring, 'call' : on_call, ...}
Zur Kontakt-Datenbank: Die "späte" Initialisierung würde ich ganz rausnehmen und dieses bisschen Code auf Modulebene stattfinden lassen.
Verstehe ich leider nicht ganz, soll ich also aus dem ganzen nur Funktionen auf Modulebene machen?
Du hast ja da diese `init_irgendwas`. Nimm den Code und lagere ihn auf Modulebene aus, wodurch die `global`s wegfallen.
maxi_king_333
User
Beiträge: 110
Registriert: Freitag 25. Dezember 2009, 03:42

Also wenn's an der `getattr`-Magie liegt, die könntest du auch mit einem Methoden-Lookup-Dictionary ersetzen, das etwa so aussieht:
Es liegt eher an meiner Logik.
Bei den magischen Zahlen, ist sie folgende:

Code: Alles auswählen

Wenn Feld 1 xyz ist, dann... Zuordnen...
Bei den RegEx:

Code: Alles auswählen

Wenn Feld 1 xyz ist, dann... Dictionary erzeugen/updaten...
Bei den Methoden:

Code: Alles auswählen

Wenn Event xyz ist... dann Methode aufrufen... 
    Dann:
        Incoming oder Outgoing Call mit Paramtern erzeugen...
        Zuordnen...
    Oder:
       connect/disconnect von Call mit Parametern aufrufen...
       Zuordnen...
Will heißen, keine direkte Relation zwischen den Feldern und den Schlüsseln (Namen) im späteren Call-Objekt.
Du hast ja da diese `init_irgendwas`. Nimm den Code und lagere ihn auf Modulebene aus, wodurch die `global`s wegfallen.
Dann müsste ich doch aber die Vorwahl und die Landesvorwahl hart kodieren, oder wie jetzt?
Kann man an ein Modul etwa Parameter übergeben?
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

maxi_king_333 hat geschrieben:

Code: Alles auswählen

Wenn Event xyz ist... dann Methode aufrufen... 
    Dann:
        Incoming oder Outgoing Call mit Paramtern erzeugen...
        Zuordnen...
    Oder:
       connect/disconnect von Call mit Parametern aufrufen...
       Zuordnen...
Will heißen, keine direkte Relation zwischen den Feldern und den Schlüsseln (Namen) im späteren Call-Objekt.
Versteh' ich nicht. Wie wäre es hiermit:

Code: Alles auswählen

...
def on_call(...):
  ...
...
event_handlers = {
  'call' : on_call,
  ...
}

def handle_event(self, event, *args):
  handler = self.event_handlers[event]
  handler(*args)
Du hast ja da diese `init_irgendwas`. Nimm den Code und lagere ihn auf Modulebene aus, wodurch die `global`s wegfallen.
Dann müsste ich doch aber die Vorwahl und die Landesvorwahl hart kodieren, oder wie jetzt?
Kann man an ein Modul etwa Parameter übergeben?
Hm. Das scheint mir ein typischer Fall von "overengineered" zu sein. Die Möglichkeit, andere Vorwahlen etc zu nutzen, benutzt faktisch kein Mensch. Es nützt also genau nichts, sie drin zu haben. Etwas mal einzubauen, weil man es vielleicht möglicherweise irgendwann in ähnlicher Form gebrauchen könnte, ist sinnlos und aufwändig. Meiner Meinung nach ist Software dann perfekt, wenn man nix mehr wegnehmen (darin eingeschlossen: vereinfachen) kann -- alles so simpel wie irgendwie möglich, aber so kompliziert wie nötig.

Ich würde die Einstellung der Vorwahlen höchstens in einer ganz einfachen Konfigurationsdatei anbieten, oder als Parameter der Contacts-Klasse machen.

Noch zwei Dinge: `__init__` hat noch immer Seiteneffekte, ich würde das `read` nicht innerhalb von `__init__` aufrufen, ist aber ne Geschmacksfrage denke ich.

`call_match` ist kein sonderlich guter Name und `functions.py` empfinde ich als überflüssig. Man hat normalerweise ein `utils`-Modul, wo allermöglicher Krams reinkommt, der modulübergreifend benutzt wird. Das trifft aber auf keine der beiden Funktionen da drin zu. Ich würde empfehlen, das Zeuch einfach in die Modul zu stecken, in die es "thematisch" gehört. Und `call_match` einen besseren Namen geben, der suggeriert, dass das Resultat der Funktion ein Boolean ist. Vielleicht könnte man die Funktionalität auch zur Call-Klasse hinzufügen und dann z.B. `matches_filter(s)` nennen. Oder so ähnlich.
maxi_king_333
User
Beiträge: 110
Registriert: Freitag 25. Dezember 2009, 03:42

Dauerbaustelle hat geschrieben:Versteh' ich nicht. Wie wäre es hiermit:
Naja, ist schwer zu erklären, ich finde es einfach irgendwie unleserlich und nicht so schön, wie bei Kunst. ;)
Ich werde trotzdem auf den Rat von Dir hören und meine ästhetischen Bedürfnisse mal vergessen.
Dauerbaustelle hat geschrieben:Hm. Das scheint mir ein typischer Fall von "overengineered" zu sein. Die Möglichkeit, andere Vorwahlen etc zu nutzen, benutzt faktisch kein Mensch. Es nützt also genau nichts, sie drin zu haben. Etwas mal einzubauen, weil man es vielleicht möglicherweise irgendwann in ähnlicher Form gebrauchen könnte, ist sinnlos und aufwändig. Meiner Meinung nach ist Software dann perfekt, wenn man nix mehr wegnehmen (darin eingeschlossen: vereinfachen) kann -- alles so simpel wie irgendwie möglich, aber so kompliziert wie nötig.
Ähm... Ich weiß ja nicht, aber ich schätze, dass wenn das Programm jemand anders benutzt, der nicht zufällig im gleichen Kaff wohnt wie ich, dann hat er ein Problem.
Dauerbaustelle hat geschrieben:Ich würde die Einstellung der Vorwahlen höchstens in einer ganz einfachen Konfigurationsdatei anbieten, oder als Parameter der Contacts-Klasse machen.
Noch extra eine Konfigurations-Datei, das finde ich, ist overkill.
Als Parameter für die Contacts-Klasse macht das auch keinen Sinn, da das Modul nicht gleichzeitig an zwei verschiedenen Standorten geladen wird.

Vielleicht hast Du nicht ganz verstanden, was das mit den Vorwahlen soll:
Wenn Du mich anrufst, erhalte ich (über den Callmonitor) Deine komplette Nummer (mit Vorwahl), egal ob Du im selben Kaff wie ich oder in einem anderen wohnst.
Wenn ich Dich aber anrufe, dann kann ich, sofern Du im selben Kaff wie ich wohnst die Vorwahl wählen oder auch nicht.
Daher brauche ich die Vorwahl, da der Callmonitor die Nummer immer wie gewählt übermittelt und ich nicht extra 2 Einträge (mit und ohne Vorwahl) anlegen will.
Das macht die ganze Sache ja auch so kompliziert, 1 Nummer kann ich in 4 Nummern ausdrücken.
Dauerbaustelle hat geschrieben:Noch zwei Dinge: `__init__` hat noch immer Seiteneffekte, ich würde das `read` nicht innerhalb von `__init__` aufrufen, ist aber ne Geschmacksfrage denke ich.
Also ich meine schon, dass die Datenbank direkt beim erstellen gebaut werden muss, da das Objekt fest einer Datenbank zugeordnet ist.
Dauerbaustelle hat geschrieben:Vielleicht könnte man die Funktionalität auch zur Call-Klasse hinzufügen und dann z.B. `matches_filter(s)` nennen. Oder so ähnlich.
Dauerbaustelle hat geschrieben:Mehr brauchst du in der Datenstruktur erstmal nicht. Die Parsing-Sachen einfach in Funktionen reinstopfen, die haben nicht wirklich was mit der Datenstruktur eines Anrufs zu tun (bin mir da aber nicht 100% sicher :-).
Passt nicht so gut zusammen ;). - Außer Du hast mit Parsing-Sachen nur den Singular gemeint.
Vorher hatte ich das da drin, duration_as_hms gehört ja eigentlich auch dazu.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

maxi_king_333 hat geschrieben:Ähm... Ich weiß ja nicht, aber ich schätze, dass wenn das Programm jemand anders benutzt, der nicht zufällig im gleichen Kaff wohnt wie ich, dann hat er ein Problem.
Hm. Das `init_numbers`, von wo wird das überhaupt aufgerufen? Von einem anderen Tool? Vielleicht wäre es sinnvoller, innerhalb von fbcallnotify nur mit absoluten (also mit Landes- und Ortsvorwahl) Nummern zu arbeiten und im Frontend auch "relative" zu erlauben?
Dauerbaustelle hat geschrieben:Vielleicht könnte man die Funktionalität auch zur Call-Klasse hinzufügen und dann z.B. `matches_filter(s)` nennen. Oder so ähnlich.
Dauerbaustelle hat geschrieben:Mehr brauchst du in der Datenstruktur erstmal nicht. Die Parsing-Sachen einfach in Funktionen reinstopfen, die haben nicht wirklich was mit der Datenstruktur eines Anrufs zu tun (bin mir da aber nicht 100% sicher :-).
Passt nicht so gut zusammen ;). - Außer Du hast mit Parsing-Sachen nur den Singular gemeint.
Vorher hatte ich das da drin, duration_as_hms gehört ja eigentlich auch dazu.
Bei diesem Filter-Matching war ich mir nicht ganz sicher, wo das hinsoll. Ich denke mal, es ist auch in Ordnung, das der Klasse hinzuzufügen. Auf keinen Fall jedenfalls in ein eigenes Utilities-Modul, weil es ja nur einen einzigen Einsatzzweck hat. Utilities nur für Kram, der universell ist. Ein ganz guter Indikator für "universell" ist, ob man den Sinn des Codes versteht, ohne den anderen Code zu kennen. `duration_as_hms` ist eine solch universelle Funktion, könnte damit also in die Utils; aber weil das nur eine einzelne Funktion ist, würde ich die einfach da reinstecken, wo's thematisch am besten passt.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Was mir grade noch auffällt: Auf der Projektwebsite steht Python3, der Code ist aber Python2 (zumindest die `print`-Syntax ist nicht Python3-kompatibel). Wenn du da wirklich Python3 verwendest, kannst du für das Auspacken der Parameter von der FritzBox die neue Unpack-Syntax nutzen (wie in nem früheren Post beschrieben).
maxi_king_333
User
Beiträge: 110
Registriert: Freitag 25. Dezember 2009, 03:42

Dauerbaustelle hat geschrieben:Hm. Das `init_numbers`, von wo wird das überhaupt aufgerufen? Von einem anderen Tool?
FBCallNotify ist als eine Bibliotek zu verstehen, mit der man seinen eigenen Callmonitor aufbauen kann.
Mit eigenen Filtern und eigenen Reaktionen auf Anrufe und co.
Das contacts Modul erlaubt es Kontaktdatenbanken zu benutzen.
Ich habe also in ~/bin meinen eigentlichen Callmonitor.
Dieser benutzt z.B. auch die Banshee-Klasse.
Vielleicht wäre es sinnvoller, innerhalb von fbcallnotify nur mit absoluten (also mit Landes- und Ortsvorwahl) Nummern zu arbeiten und im Frontend auch "relative" zu erlauben?
Genau das kann ich eben nicht machen.
Da von der FritzBox die gewählte Nummer so wie gewählt übermittelt wird, arbeitet die Contacts-Klasse mit relativen Angaben.
(Habe mich vorher ein bisschen blöd ausgedrückt und statt FritzBox Callmonitor geschrieben)
In die Datenbank werden jedoch nur absolute eingetragen, also z.B. +49 1234 123456.
Diese werden dann Verarbeitet, sodass bei passender Vorwahl diese auch weggelassen werden kann.
Dauerbaustelle hat geschrieben:Was mir grade noch auffällt: Auf der Projektwebsite steht Python3, der Code ist aber Python2 (zumindest die `print`-Syntax ist nicht Python3-kompatibel). Wenn du da wirklich Python3 verwendest, kannst du für das Auspacken der Parameter von der FritzBox die neue Unpack-Syntax nutzen (wie in nem früheren Post beschrieben).
Ja, ich weiß, war auch ursprünglich so.
Habe ich nur noch nicht angepasst, ich würde auch gerne Python3 verwenden, wenn es das DBUS-Modul dafür geben würde.

Habe nun einiges geändert.
Mir gefällt es soweit gut, wie gefällt es Dir/Euch?

Vielen Dank und Viele Grüße
Maxi
Antworten