SimpleWikiParser
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Sollte noch was sagen zu ein einzeilern... Ich versuche das immer zu vermeiden, viele Schritte in einer Zeile zu schreiben. Ganz einfach deswegen, weil ein Traceback dann weniger Aussagekräftig sein kann. Wenn ich alles Schritt für Schritt in einer Zeile mache, dann sagt mir ein Traceback besser in welchem Schritt der Fehler vorgekommen ist...
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Damit könnt ihr hier http://www.python-forum.de/topic-9515.html weiter machensape hat geschrieben:Ok, du willst nicht verstehen was ich mit dem Beispiel sagen wollte.birkenfeld hat geschrieben:[...]
Du machst es dir aber auch verdammt schwer.

Danke Jens 
Wollte nur bescheid sagen, das die Standalone-Variante evtl. mitte nächster Woche fertig wird. Bin nu erstma wech... ohne meine Daten :'( ...
Die ist nun schon etwas mächtiger geworden. Die funktionsweise ist jedoch die gleiche geblieben. Der Text wird zeile für Zeile durchgegangen und anhand der 'scan_regex' gescannt und an die entsprechenden 'replacer' Funktionen weitergegeben.
Jedoch sind diese nun sehr viel mächtiger geworden. Sie können z.B. von sich aus auf den kompletten Text zugreifen, auswählen -- gib mir die nächsten 5-10-20 Zeilen... usw. Also der Text wird "zwischengespeichert" und kann jederzeit abgerufen werden.
Des weiteren habe ich die 'Methoden-Cache'-Funktion etwas ausgearbeitet. Sie überprüft nun vorab, anhand der 'scan_re' welche Funktionen eventuell ins dictionary rein kommen. Sollte später eine weitere benötigt werden wird diese auch ins dict eingelagert.
Ob das sich nun später positiv oder negativ auf die Performance auswirkt... muss begutachtet werden. Immo wikt es jedenfalls sehr perfomant und macht ne gute Arbeit
MfG EnTeQuAk

Wollte nur bescheid sagen, das die Standalone-Variante evtl. mitte nächster Woche fertig wird. Bin nu erstma wech... ohne meine Daten :'( ...
Die ist nun schon etwas mächtiger geworden. Die funktionsweise ist jedoch die gleiche geblieben. Der Text wird zeile für Zeile durchgegangen und anhand der 'scan_regex' gescannt und an die entsprechenden 'replacer' Funktionen weitergegeben.
Jedoch sind diese nun sehr viel mächtiger geworden. Sie können z.B. von sich aus auf den kompletten Text zugreifen, auswählen -- gib mir die nächsten 5-10-20 Zeilen... usw. Also der Text wird "zwischengespeichert" und kann jederzeit abgerufen werden.
Des weiteren habe ich die 'Methoden-Cache'-Funktion etwas ausgearbeitet. Sie überprüft nun vorab, anhand der 'scan_re' welche Funktionen eventuell ins dictionary rein kommen. Sollte später eine weitere benötigt werden wird diese auch ins dict eingelagert.
Ob das sich nun später positiv oder negativ auf die Performance auswirkt... muss begutachtet werden. Immo wikt es jedenfalls sehr perfomant und macht ne gute Arbeit

MfG EnTeQuAk
So... wieder zu Hause und neu erstärkt habe ich mich ran gemacht, mich mal wieder an eine neue Version zu machen.
Ausgangsversion war der Standalone-Parser von Jens.
die neueste Version ist immo hier zu sehen:
http://daucms.de/trac/browser/dauCMS/tr ... _parser.py
wird aber mitlerweile auch nochmal kräftig überarbeitet...
u.a werden einige Sachen in die Klasse 'SytaxParser' verlagert... und der ablauf des Parsens wird auch nochma ein wenig beschläunigt.
Das ganze ist nur eine kleine TEstversion und in den nächsten Tagen wird eine erweiterte Version mit mehr Funktionen hochgeladen... doch die ist imho noch stark in Bearbeitung.
Das mit dem Methoden-Caching wird nochmal genauer überlegt bzw. anhand einiger Benchmarks genauer ermittelt, ob es Vorteile bringt oder nicht.
Jedoch verstehe ich dieses 'timit' Modul nicht... sollte jemand da mehr Erfahrung haben, so melde er sich bitte
Also bis denn!
MfG EnTeQuAk
Ausgangsversion war der Standalone-Parser von Jens.
die neueste Version ist immo hier zu sehen:
http://daucms.de/trac/browser/dauCMS/tr ... _parser.py
wird aber mitlerweile auch nochmal kräftig überarbeitet...
u.a werden einige Sachen in die Klasse 'SytaxParser' verlagert... und der ablauf des Parsens wird auch nochma ein wenig beschläunigt.
Das ganze ist nur eine kleine TEstversion und in den nächsten Tagen wird eine erweiterte Version mit mehr Funktionen hochgeladen... doch die ist imho noch stark in Bearbeitung.
Das mit dem Methoden-Caching wird nochmal genauer überlegt bzw. anhand einiger Benchmarks genauer ermittelt, ob es Vorteile bringt oder nicht.
Jedoch verstehe ich dieses 'timit' Modul nicht... sollte jemand da mehr Erfahrung haben, so melde er sich bitte

Also bis denn!
MfG EnTeQuAk
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Also ich denke du solltest erstmal alle Optimierungs-Bemühungen komplett außen vor lassen. Erstmal ist es am wichtigsten das der Parser überhaupt komplett funktioniert.
Dann wäre nicht schlecht, wenn man einen unitest macht. Das ist allerdings für ein Markup nicht so super einfach. Ich hab hier mal einen für tinyTextile gemacht: http://pylucid.net/trac/browser/trunk/t ... Textile.py
Wenn der Unitest fertig ist und bestanden wird, kann man dann erst Gedanken zum Thema Optimierung machen, denke ich...
Dann wäre nicht schlecht, wenn man einen unitest macht. Das ist allerdings für ein Markup nicht so super einfach. Ich hab hier mal einen für tinyTextile gemacht: http://pylucid.net/trac/browser/trunk/t ... Textile.py
Wenn der Unitest fertig ist und bestanden wird, kann man dann erst Gedanken zum Thema Optimierung machen, denke ich...
Ja, das Optimierungen erst nach dem Fertigstellen eingebaut werden ist mir schon klar
(und so denke ich auch)
Unitest is gar keine schlechte Idee
--> Endlich ma ne Möglichkeit, sich mit diesen Dingen zu beschäftigen... damit hab ich imho noch gar nichts gemacht...
Dann kann man eventuell gleich mal dauCMS mit in die tests mit einbeziehen
--> Das wär ne Idee 
Werd ich ma machen...
MfG EnTeQuAk

Unitest is gar keine schlechte Idee

Dann kann man eventuell gleich mal dauCMS mit in die tests mit einbeziehen


Werd ich ma machen...
MfG EnTeQuAk