SimpleWikiParser

Code-Stücke können hier veröffentlicht werden.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Montag 12. Februar 2007, 13:04

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

Montag 12. Februar 2007, 13:56

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

Montag 12. Februar 2007, 15:54

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:

Montag 12. Februar 2007, 16:16

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

Montag 12. Februar 2007, 18:45

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

Montag 12. Februar 2007, 18:54

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

Montag 12. Februar 2007, 22:31

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

Montag 12. Februar 2007, 23:09

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:

Dienstag 13. Februar 2007, 08:21

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

Dienstag 13. Februar 2007, 09:42

[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]
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 14. Februar 2007, 10:00

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 15. Februar 2007, 10:29

sape hat geschrieben:
birkenfeld hat geschrieben:[...]
Du machst es dir aber auch verdammt schwer.
Ok, du willst nicht verstehen was ich mit dem Beispiel sagen wollte.
Damit könnt ihr hier http://www.python-forum.de/topic-9515.html weiter machen :roll:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Donnerstag 15. Februar 2007, 14:23

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
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Montag 26. Februar 2007, 11:44

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
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 26. Februar 2007, 11:47

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten