SimpleWikiParser

Code-Stücke können hier veröffentlicht werden.
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

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

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 :D


MfG EnTeQuAk
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

EDIT:
BlackJack hat geschrieben:[...]
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.
Zuletzt geändert von sape am Montag 12. Februar 2007, 12:41, insgesamt 1-mal geändert.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Du solltest das "_replace_" in den dict-keys gleich weglassen.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

birkenfeld hat geschrieben: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?
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Um "schneller" geht es nicht unbedingt, aber wenn du eh schon weißt, dass der Name auf "_replace_" endet, warum nicht elem[0][:-9]?
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

birkenfeld hat geschrieben: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.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

sape hat geschrieben:
birkenfeld hat geschrieben: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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

birkenfeld hat geschrieben:
sape hat geschrieben:
birkenfeld hat geschrieben: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
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

sape hat geschrieben:
birkenfeld hat geschrieben:
sape hat geschrieben:
birkenfeld hat geschrieben: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. :wink:
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

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

pyStyler hat geschrieben:
sape hat geschrieben: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. :wink:
Doch, lesbarer ist pythonischer. IMHO.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

sape hat geschrieben: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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

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 :D

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



MfG EnTeQuAk
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

birkenfeld hat geschrieben:[...]
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.
birkenfeld hat geschrieben:[...]
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!
birkenfeld hat geschrieben:[...]
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
Tony Hoare hat geschrieben: „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
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Ups, ich muss mich korrigieren. Ich meinte in meinem ersten Beitrag natürlich Markdown (Original, Python-Paket) und nicht Markup.
EnTeQuAk hat geschrieben:Ziel ist es einen SyntaxParser zu entwickeln, der einfach via Unterklassen erweitert werden kann.
Und genau das ist Markdown bereits!
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Darum machen wir sowas selber --> http://www.daucms.de/dokumentation/behinddaucms.html

Wobei wir ja keine Syntax neu erfinden, unsere ist mit moin bis auf fett, kursiv und die Links identisch.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Zugegeben, Programmierer neigen dazu, das Rad neu zu erfinden - und das hat ja auch Vorteile. Aber langfristig muss man gemeinhin lernen und einsehen, dass man oft nur effektiv arbeiten und weiterkommen kann, wenn man auf der Arbeit anderer aufbaut. Und die kann man ja bei OSS-Projekten (und das sind sehr viele Python-Pakete) noch verbessern, wenn man will (und der Hauptentwickler es zulässt und es keine grundsätzlichen Änderungen sind, die ein neues Projekt rechtfertigen oder verlangen).

Aber hey, solange ihr drüber nachgedacht habt, gut.
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Nachgedacht auf alle fälle... Wir haben ja auch schonmal mit dem Gedanken gespielt, mehrere schon fertig imlementierte Syntaxen zu unterstützen.
(komplett Moin Moin, Dokuwiki und einige mehr)...

Doch alles sollte unter einer Oberfläche laufen, was erst jetzt mit dem eigenen Parser möglich ist.


Um wieder zurück zum Thema zu kommen :D

Ich bin mit der Standalone Version sehr viel Weiter gekommen. Desweiteren fließen da viele Verbesserungen ein, die in gestern noch im an dauCMS gekoppelten Parser eingebracht habe.

Mal schaun, wies wird ;)


MfG EnTeQuAk
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

[ot]
Y0Gi das "Ich will es Wissen und daraus Lernen" ist einer der Besten Rechtfertigungen! Ob dabei ein Rad neu erfunden wird ist bei solch einen Beweggrund erstmal irrelevant.

Und soweit ich das damals verstanden habe, ging es primär erstmal nur darum bei dauCMS. --
- Nicht auf vorgefertigte Sache zurückgreifen, sondern sich Gedanken machen wie man sowas selber Realisieren könnte um daraus zu Lernen.
- Erst nach den man selber mit den Problemen die andere Programmierer hatten, konfrontiert wurde, kann man besser die Arbeit der anderen bewerten und hat eine viel "klarerer" Sicht auf die Dinge.

Und wie Snede schon im anderen Thread angedeutet hat, im Gespräch mit Jens, habe Snede und EnTe schon ein wenig Erfahrung sammeln dürfen im Bau von parsen und lexern, durch dauCMS, und wären dann für den bereich in PyLucid zu gebrauchen . Ein Status den man nicht erreicht wenn man sich nur mit Fertigbausätzen beschäftigt und nicht weiß wie sowas eigentlich wirklich funktioniert und realisiert wird.

Und wie ich das richtig lese, werden die beiden ehe nachehr viel mehr externe fertige Lösungen integrieren, wenn sie genug Erfahrung und Wissen gesammelt haben.
[/ot]
Antworten