SimpleWikiParser

[jens]

Jens warum?

Hm. Neben dem einsparen des String-Formatings, wäre es auch flexibler. Man könnte die Klasse dann dem Parser übergeben um eine andere Syntax zu nutzten.
OK, jetzt geht's über erben und "überschreiben" der Methoden. Aber was ist, wenn ich eine Methode überhaupt nicht haben will?

Ist es nicht durch eine seperaren Klasse sauberer getrennt: Programmlogik <-> Syntax ???

[rayo]

Hi

Also ich würde das Dict bevorzugen, nur schon aus dem Grund, weil falls mal ein Token ein Sonderzeichen beinhaltet wird dies mit Funktionen nicht funktionieren. Mit einem String als Key würde dies Funktionieren.

Wegen dem Laufzeitverhalten:
Das interessiert mich überhaupt nicht oder ist der Lexer schon jetzt zu langsam? Optimierung immer erst ganz am Schluss wenn es wirklich zu langsam ist.

Immer zuerst das schönere und flexiblere Programmieren.

Gruss

[sape]

Nein sie verbessert sich, weil man nicht jedesmal `type` als Schlüssel formatieren muss. Das sollte mehr Laufzeit und Speicher verbrauchen, als ein einfacher Test auf `None`. Ob das die Laufzeit nun *spürbar* verbessert, keine Ahnung.

Du meinst das hier?: ``_replace_' + type_'``

Ok, wenn alle Iterationen in dem das hier...

Code: Alles auswählen

method = getattr(self, '_replace_' + type_)

...benutzt wird, immer mehr Zeit kostet als das hier...

Code: Alles auswählen

method = self.cache.get(type_)
if method is None:

..dann ok.

Wenn ich dich also richtig versteh stützt dich deine Argumentation darauf das ``_replace_' + type_'`` mehr Zeit kosten würde als obiges, weil eine Konkatenation mehr Zeit beansprucht als ein simples überprüfen auf None. -- Das klingt selbst für **mich** (Und du weißt wie ich drauf bin ^^) nach ziemlich extreme Optimierung an einer stelle wo das unangebracht ist, da keine Verbesserung im Laufzeitverhalten zu erwarten ist.

lg

[BlackJack]

Wie wäre es, wenn man generell eine separate Klasse mit den replacer-Methoden nimmt.
Dann brauchen die auch nicht mehr alle "_%s_replacer" heißen. Man spart sich dadurch die String Formatierung.

Das praktische an dem Entwurfsmuster ist, dass man einfach eine Unterklasse um weitere "replacer" erweitern kann, ohne den Rest anfassen zu müssen. Man könnte auch eine Basisklasse schreiben, die ausschliesslich den Dispatch-Mechanismus enthält und verschiedene Unterklassen für verschiedene Auszeichnungssprachen schreiben. Oder für verschiedene Ausgabesprachen, zum Beispiel RTF oder so.

Ausserdem kann man wirklich alles als Typnamen verwenden, inklusive Schlüsselworte von Python.

Eine weitere Methode es zu beschleunigen ohne eine weitere Klasse einzuführen, wäre vielleicht den Cache in der `__init__()` zu füllen. Einfach alle Attribute von `self` nach dem Muster `_replace_*` absuchen und den Cache entsprechend füllen.

[sape]

[...]
Eine weitere Methode es zu beschleunigen ohne eine weitere Klasse einzuführen, wäre vielleicht den Cache in der `__init__()` zu füllen. Einfach alle Attribute von `self` nach dem Muster `_replace_*` absuchen und den Cache entsprechend füllen.

Joa, sauber! So einfach das wir eigentlich auch drauf hätten kommen müssen!

[EnTeQuAk]

Oha... gut nehmen wir den Kampf gegen die Millisekunden an

Nein mal Ehrlich... das mit dem Cachen ist ne schöne Idee... bringt viellecht auch Geschwindigkeitsvorteile... aber nur sehr gering.

Ich baue grad alles ein wenig um.. -- und bastel den Vorschlag der extra-erweiterungsklassen ein. Mal auf die Performance gesc*****... Das kommt rein, und lässt das ganze wesentlich variabler wirken.

vorher muss aber noch ein anderer Bereich an dauCMS umgeschrieben werden Dann is der SyntaxParser dran


MfG EnTeQuAk

[sape]

EDIT:

[...]
Eine weitere Methode es zu beschleunigen ohne eine weitere Klasse einzuführen, wäre vielleicht den Cache in der `__init__()` zu füllen. Einfach alle Attribute von `self` nach dem Muster `_replace_*` absuchen und den Cache entsprechend füllen.

Hier mal ein Versuch. Hoffe das passt so.

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from inspect import getmembers

class Foo(object):
    def __init__(self):
        self.cache = dict()
        for elem in getmembers(self):
            if elem[0].endswith('_replace_'):
                self.cache[elem[0].replace('_replace_', '')] = elem[1]
        
    def bold_replace_(self):
        pass
    
    def italic_replace_(self):
        pass



foo = Foo()
#Testausgabe:
for k, v in foo.cache.iteritems():
    print k, v

#Output:
# italic <bound method Foo.italic_replace_ of <__main__.Foo object at 0x009E7690>>
# bold <bound method Foo.bold_replace_ of <__main__.Foo object at 0x009E7690>>

EDIT: Grund, siehe unten.

[birkenfeld]

Du solltest das "_replace_" in den dict-keys gleich weglassen.

[sape]

Du solltest das "_replace_" in den dict-keys gleich weglassen.

Jepp, habe ich übersehen.

Zeile 10:

Code: Alles auswählen

self.cache[elem[0].replace('_replace_', '')] = elem[1]

Aber ansonsten passt das so oder gibt es eine schnellere Möglichkeit?

[birkenfeld]

Um "schneller" geht es nicht unbedingt, aber wenn du eh schon weißt, dass der Name auf "_replace_" endet, warum nicht elem[0][:-9]?

[sape]

Um "schneller" geht es nicht unbedingt, aber wenn du eh schon weißt, dass der Name auf "_replace_" endet, warum nicht elem[0][:-9]?

Weil ich das andre Pythonischer finde. Hast aber eigentlich Recht.

[birkenfeld]

Um "schneller" geht es nicht unbedingt, aber wenn du eh schon weißt, dass der Name auf "_replace_" endet, warum nicht elem[0][:-9]?

Weil ich das andre Pythonischer finde.

Das musst du mir aber jetzt erklären.

[jens]

Also ich würde auch nicht die Zahl hardcoden, sondern ehr ein len(PREFIX) nehmen.

[sape]

Um "schneller" geht es nicht unbedingt, aber wenn du eh schon weißt, dass der Name auf "_replace_" endet, warum nicht elem[0][:-9]?

Weil ich das andre Pythonischer finde.

Das musst du mir aber jetzt erklären.

Ich finde es einfach leserlicher und verständlicher als mit zu vielen Indexzugriffen zu arbeiten und vermeide es an jeder stelle wo es geht, wie z.B. oben. Bei recht Komplexen ausdrücken wird das sehr schnell unleserlich. Das ist aber reine Geschmacksache.

[pyStyler]

Um "schneller" geht es nicht unbedingt, aber wenn du eh schon weißt, dass der Name auf "_replace_" endet, warum nicht elem[0][:-9]?

Weil ich das andre Pythonischer finde.

Das musst du mir aber jetzt erklären.

Ich finde es einfach leserlicher und verständlicher als mit zu vielen Indexzugriffen zu arbeiten und vermeide es an jeder stelle wo es geht, wie z.B. oben. Bei recht Komplexen ausdrücken wird das sehr schnell unleserlich. Das ist aber reine Geschmacksache.

wobei es dann nicht mit Pythonischer zu tun hat.

[sape]

Ok, ein Beispiel was ich meine:

Code: Alles auswählen

        for elem in getmembers(self):
            if elem[0].endswith('_replace_'):
                self.cache[elem[0].replace('_replace_', '')] = elem[1]

Code: Alles auswählen

        for elem in getmembers(self):
            if elem[0][::-1][:9][::-1] == '_replace_':
                self.cache[elem[0][:-9]] = elem[1]

Beide if abfragen führen zum gleichen Ziel. Aber dennoch finde ich `` if elem[0].endswith('_replace_')``leichter zu durchschauen als ``if elem[0][::-1][:9][::-1] == '_replace_'`` und daher auch Pythonischer. Und das Beispiel mit ``elem[0][::-1][:9][::-1]`` meinte ich mit komplexen ausdrücken.

Naja, klingt zwar komisch, aber hinzu kommt bei mir auch; Ob der Ausdruck nun komplex ist (elem[0][::-1][:9][::-1]) oder nicht (elem[0][-9]), ich versuche dennoch über all dort wo es eine alternative zur solchem gibt, die auch zu nutzen.

EDIT: Korrektur.

[BlackJack]

Ich finde es einfach leserlicher und verständlicher als mit zu vielen Indexzugriffen zu arbeiten und vermeide es an jeder stelle wo es geht, wie z.B. oben. Bei recht Komplexen ausdrücken wird das sehr schnell unleserlich. Das ist aber reine Geschmacksache.

wobei es dann nicht mit Pythonischer zu tun hat.

Doch, lesbarer ist pythonischer. IMHO.

[birkenfeld]

Ok, ein Beispiel was ich meine:

Code: Alles auswählen

        for elem in getmembers(self):
            if elem[0].endswith('_replace_'):
                self.cache[elem[0].replace('_replace_', '')] = elem[1]

Code: Alles auswählen

        for elem in getmembers(self):
            if elem[0][::-1][:9][::-1] == '_replace_':
                self.cache[elem[0][:-9]] = elem[1]

Du machst es dir aber auch verdammt schwer.
elem[0][::-1][:9][::-1] == elem[0][-9:]

Beide if abfragen führen zum gleichen Ziel. Aber dennoch finde ich `` if elem[0].endswith('_replace_')``leichter zu durchschauen als ``if elem[0][::-1][:9][::-1] == '_replace_'`` und daher auch Pythonischer. Und das Beispiel mit ``elem[0][::-1][:9][::-1]`` meinte ich mit komplexen ausdrücken.

Das würde ich auch so nie schreiben, siehe oben.

Naja, klingt zwar komisch, aber hinzu kommt bei mir auch; Ob der Ausdruck nun komplex ist (elem[0][::-1][:9][::-1]) oder nicht (elem[0][-9]), ich versuche dennoch über all dort wo es eine alternative zur solchem gibt, die auch zu nutzen.

Es geht nicht darum, das Gleiche in zwei Weisen auszudrücken. Der Code mit replace() funktioniert anders als der mit Slicing.
Hier ist es ja noch verhältnismäßig harmlos, aber das nächste Mal ist die Alternative halt zufällig O(n^2), während der "komplexe" Weg O(n) ist. Tja.

[EnTeQuAk]

Hmm... also die standalone Version ist doch etwas komplizierter, als ich erst dachte... ich benötige noch eine extra funktion, die die regex'es zusammensetzt... Ziel ist es einen SyntaxParser zu entwickeln, der einfach via Unterklassen erweitert werden kann.


Es gibt schon eine erste funktionierende Version... nur ist die weder ausgereift noch gut

Es wird also noch ein wenig dauern. Bis dahin sollte die Variante auf der vorigen Seite reichen

desweiteren baue ich grad eure Vorschläge ein... ist einiges sehr interessantes drinne



MfG EnTeQuAk

[sape]

[...]
Du machst es dir aber auch verdammt schwer.
elem[0][::-1][:9][::-1] == elem[0][-9:]

Ok, du willst nicht verstehen was ich mit dem Beispiel sagen wollte. Soll ich jetzt eine halbe stunde überlegen um ein Beispiel zu finden das man nicht auf kleinkarierter weise widerlegen kann um das Auszusagen was diese Beispiel eigentlich schon aussagt!? Wahrscheinlich würde dann aber keine Antwort kommen wenn ich Recht habe und es hätte dann nichts gebracht, weil von gewissen Personen nur Antworten kommen, wenn Sie was widerlegen können und Sie Recht kriegen/behalten. Sachen wie "Ja hast ja Recht" kann man von Solchen Personen nicht erwarten. War das jetzt eine Wertung von mir? Ja, war es, ein explizite anstatt deine ewigen impliziten.

[...]
Es geht nicht darum, das Gleiche in zwei Weisen auszudrücken. Der Code mit replace() funktioniert anders als der mit Slicing.

Ne darum ging es wirklich nicht. Es ging um das warum und die Antwort von mir das ich es als Pythonischer empfinde. -- Dazu sollte das obere Beispiel auch dienen aber wie gesagt, hätte ja nicht ahnen könne (oder hätte ich mal doch), das man das Beispiel wider auf kleinkarierter Art und weiße seziert und in grnde sagt "ne da kannst du auch so machen". Es war nur ein beispiel, mehr nicht!

[...]
Hier ist es ja noch verhältnismäßig harmlos, aber das nächste Mal ist die Alternative halt zufällig O(n^2), während der "komplexe" Weg O(n) ist. Tja.

In der Entwicklungszeiten ist das erstmal irrelevant:
http://de.wikipedia.org/wiki/Unix-Philo ... mming_in_C

„Zu frühe Optimierung ist die Wurzel allen Übels.“

Und Optimierung nimmt man auch nur an den stellen vor an denen das Laufzeitverhalten kritisch ist. Das habe ich glücklicherweise von Leuten wie Leonidas, BlackJack, etc gelernt, da ich vorher an den unmöglichsten stellen versucht habe zu optimieren. Und bitte, verschone mich damit mir wider diesen Wurm in den Kopf zu setzen! Das haben leider genug andere schon getan und es hat gedauert bis ich mich davon wider befreien konnte!

Und das soll nun kein Flammpost sein. Wenn ich das nicht mal anspreche geht dieser Zirkus immer wider von vorne los.

Nichts für ungut, aber dir geht es eigentlich um was anderes.

lg