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
SimpleWikiParser
EDIT:
EDIT: Grund, siehe unten.
Hier mal ein Versuch. Hoffe das passt so.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.
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>>
Zuletzt geändert von sape am Montag 12. Februar 2007, 12:41, insgesamt 1-mal geändert.
- 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.
Jepp, habe ich übersehen.birkenfeld hat geschrieben:Du solltest das "_replace_" in den dict-keys gleich weglassen.
Zeile 10:
Code: Alles auswählen
self.cache[elem[0].replace('_replace_', '')] = elem[1]
- 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]?
Weil ich das andre Pythonischer finde. Hast aber eigentlich Recht.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]?
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Das musst du mir aber jetzt erklären.sape hat geschrieben:Weil ich das andre Pythonischer finde.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]?
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.birkenfeld hat geschrieben:Das musst du mir aber jetzt erklären.sape hat geschrieben:Weil ich das andre Pythonischer finde.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]?
wobei es dann nicht mit Pythonischer zu tun hat.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.birkenfeld hat geschrieben:Das musst du mir aber jetzt erklären.sape hat geschrieben:Weil ich das andre Pythonischer finde.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]?
Ok, ein Beispiel was ich meine:
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.
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]
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.
Doch, lesbarer ist pythonischer. IMHO.pyStyler hat geschrieben:wobei es dann nicht mit Pythonischer zu tun hat.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.
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Du machst es dir aber auch verdammt schwer.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]
elem[0][::-1][:9][::-1] == elem[0][-9:]
Das würde ich auch so nie schreiben, siehe oben.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.
Es geht nicht darum, das Gleiche in zwei Weisen auszudrücken. Der Code mit replace() funktioniert anders als der mit Slicing.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.
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.
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
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
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:[...]
Du machst es dir aber auch verdammt schwer.
elem[0][::-1][:9][::-1] == elem[0][-9:]
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:[...]
Es geht nicht darum, das Gleiche in zwei Weisen auszudrücken. Der Code mit replace() funktioniert anders als der mit Slicing.
In der Entwicklungszeiten ist das erstmal irrelevant: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.
http://de.wikipedia.org/wiki/Unix-Philo ... mming_in_C
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!Tony Hoare hat geschrieben: „Zu frühe Optimierung ist die Wurzel allen Übels.“
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
Ups, ich muss mich korrigieren. Ich meinte in meinem ersten Beitrag natürlich Markdown (Original, Python-Paket) und nicht Markup.
Und genau das ist Markdown bereits!EnTeQuAk hat geschrieben:Ziel ist es einen SyntaxParser zu entwickeln, der einfach via Unterklassen erweitert werden kann.
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.
Wobei wir ja keine Syntax neu erfinden, unsere ist mit moin bis auf fett, kursiv und die Links identisch.
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.
Aber hey, solange ihr drüber nachgedacht habt, gut.
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
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
(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
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
[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]
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]