Hab mich jetzt mal rangewagt:
Und hier gibt's den Code: http://paste.pocoo.org/show/163791/
Terminalausgabe bunt machen
-
- User
- Beiträge: 996
- Registriert: Mittwoch 9. Januar 2008, 13:48
Ohje, aber dafür nen XML-Parser laden...? :-)
-
- User
- Beiträge: 996
- Registriert: Mittwoch 9. Januar 2008, 13:48
Wobei das halt sauber und eindeutig ist zur Beschreibung. jagut, man könnte sowas wie **dick** und _underlined_ machen, aber a) hört das bei Farben auf, da würde man dann so Kram wie BB-like-Tag einführen und b) ist das nicht so bequem programmatisch zu erzeugen, würde ich behaupten.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich find die Idee mit den Tags grundsätzlich gut, weil das einfach zu verstehen und nutzen ist (Reportlab nutzt auch so einen Ansatz), allerdings finde ich das mit dem root-Tag nicht so toll. Außerdem hat man bei XML auch wieder Escaping-Probleme so dass ich mir nicht sicher bin ob nicht ein eigenes, tagbasiertes Markup nicht vielleicht doch besser wäre.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ich stand genau vor der gleichen Frage. Hatte mir auch die Syntax vom UU-Forum näher angesehen, weil die mir nach anfänglichen Umstellungsproblemen inzwischen sehr zusagt (bis auf ein paar Kleinigkeiten). Das mit dem Root-Tag nervt wirklich. Farbnamen könnte man ja durchaus in eckige oder geschweifte Klammern einbauen. Ich schaue mir gerade AsciiDoc an. Die Einstellmöglichkeiten scheinen auf dem ersten Blick nicht schlecht zu sein und es ist in Python geschrieben, so dass man damit wohl eine eigene Markup-Sprache entwickeln oder sich zumindest ein paar Sachen abgucken könnte. Werd mich dazu wahrscheinlich in den nächsten Tagen nochmal melden.
EDIT: Ich korrigiere, es sind eher die Beispiele in dem Tarball, die mir zusagen, speziell `code-filter.py`.
EDIT: Ich korrigiere, es sind eher die Beispiele in dem Tarball, die mir zusagen, speziell `code-filter.py`.
Ich würde ehrlich gesagt nicht extra einen XML-Parser bemühen, um Text in spitzen Klammern zu parsen: http://paste.pocoo.org/show/163934/
Man müsste sich noch überlegen, wie man mit einem "<" im Text umgehen will. Escapen wie in XML? Dann muss man noch < und & unterstützen und vielleicht noch &#XXX;. War mir für das RE-Beispiel zu aufwendig.
Stefan
Man müsste sich noch überlegen, wie man mit einem "<" im Text umgehen will. Escapen wie in XML? Dann muss man noch < und & unterstützen und vielleicht noch &#XXX;. War mir für das RE-Beispiel zu aufwendig.
Stefan
Ich denke, ich werde mich doch eher an ein alternatives Markup wagen.
Das möchte ich mal ganz **fett** __unterstreichen__ und daher weder --durchstreichen--, noch [[invertieren]], oder so ähnlich.
Das möchte ich mal ganz **fett** __unterstreichen__ und daher weder --durchstreichen--, noch [[invertieren]], oder so ähnlich.
sma, der Regex-Gott.
Wie würdet ihr Farben parsen? Vielleicht so?
Doof, oder?
Wie würdet ihr Farben parsen? Vielleicht so?
Code: Alles auswählen
Ich bin völlig ~~blue~~besoffen~~blue~~
- Defnull
- User
- Beiträge: 778
- Registriert: Donnerstag 18. Juni 2009, 22:09
- Wohnort: Göttingen
- Kontaktdaten:
Ich wäre für [farbe:text text text] oder so etwas. Meistens will man ja nur kurze Bereiche farbig gestalten. Natürlich wäre ein Support für verschachtelung ([red: bla [green: blub] bla]) interessant.
Bottle: Micro Web Framework + Development Blog
Kennt jemand einen Parser für solche Art von Markup? Ich hab die Klasse aus dem ElementTree-Modul vor allem genutzt, weil ich mir dadurch das Einbinden von Regex-Ausdrücken ersparen konnte. Optimal wäre die Einbindung einer eigenen Grammatik mittels Wörterbuch. Etwa so:
Ich werde mich mal näher mit PyParsing befassen...
Code: Alles auswählen
{'**': self.attr_cache.append(BOLD), '__': self.attr_cache.append(UNDERLINE), ...}
"Interessant" heißt hier vermutlich kompliziert. Aber die Unterstützung von Verschachtelungen ist IMHO definitiv notwenig.Defnull hat geschrieben:Natürlich wäre ein Support für verschachtelung ([red: bla [green: blub] bla]) interessant.
Ich werde mich mal näher mit PyParsing befassen...
Mein zweites Beispiel finde ich ausreichend. Die regulären Ausdrücke aus einer Tabelle von Sonderzeichen und CSI-Sequenzen zu generieren überlasse ich dem Leser. PyParsing finde ich ist overkill.snafu hat geschrieben:Kennt jemand einen Parser für solche Art von Markup? ...
Ich werde mich mal näher mit PyParsing befassen...
Stefan
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Dito, würde nicht als Dependency haben wollen. Davon abgesehen bin ich von PyParsing nur mittelmäßig begeistert.sma hat geschrieben:PyParsing finde ich ist overkill.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Nur hab ich bei PyParsing eben so Dinge wie `nestedExpr()` gesehen. Ich sträube mich ehrlich gesagt ein bißchen, das in regulären Ausdrücken nachzuimplementieren, wenn es doch schon eine Bibliothek gibt, die sowas unterstützt. Sonst heißt es auch immer, man soll das Rad nicht neu erfinden. Bei so ziemlich jedem Thread, der fragt, wie man bestimmte Teile aus dem Quelltext einer Website holen kann, wird sofort auf ElementTree & Co verwiesen und jetzt plötzlich soll es keine gute Idee sein, PyParsing zu verwenden, weil es Overkill ist? Sorry, aber je mehr ich darüber nachdenke, desto weniger kann ich diese Haltung nachvollziehen.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Naja, ElementTree ist teil der Stdlib, daher kostet die verwendung davon nichts, wohingegen PyParsing ein externes Dependency ist.
Also wenn ich sowas machen sollte würde ich mir inzwischen eher funcparserlib, pyPEG oder picoparse anschauen. Wenn ich unbedingt eine Parser-Library nutzen will.
Also wenn ich sowas machen sollte würde ich mir inzwischen eher funcparserlib, pyPEG oder picoparse anschauen. Wenn ich unbedingt eine Parser-Library nutzen will.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Die Sache ist halt, dass ich reinen Regex-Code persönlich schlecht lesbar und somit auch schlecht wartbar sowie fehleranfällig finde, sobald man dann doch mal irgendeinen Fall vergessen hat. Eben ähnlich wie beim Parsen von HTML. Dass solche Module nicht in der Stdlib integriert sind, ist für mich auch wirklich das einzige Gegenargument. Ich denke aber, man kann vom Benutzer in dem Fall ruhig erwarten, dass er ein Modul via Paketmanager bzw easy_install nachinstalliert, denn das Parsen des Markups ist hier ja ein wesentlicher Bestandteil.
Danke übrigens für die Links. PyParsing hatte ich nur aus dem Grund gewählt, weil mir nichts anderes bekannt war.
Danke übrigens für die Links. PyParsing hatte ich nur aus dem Grund gewählt, weil mir nichts anderes bekannt war.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Also ich finde meinen Parser in PyParsing direkt noch schlechter lesbar und wartbar, weil der komische Sachen macht und ich immer dem Autor mailen muss, der mir dann ein noch hässlicher ausschauendes Codeschnippsel zurückmailt, das diesen Bug nicht hat.snafu hat geschrieben:Die Sache ist halt, dass ich reinen Regex-Code persönlich schlecht lesbar und somit auch schlecht wartbar sowie fehleranfällig finde, sobald man dann doch mal irgendeinen Fall vergessen hat.
Wie gesagt: nicht begeistert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Naja, ich werde mir wahrscheinlich `funcparser` näher ansehen. Da gibt es ja sogar ein Tutorial zum Thema Verkettung. Was auch eine Idee wäre: Erstmal mit einem solchen Hilfstool alles aufbauen bis es läuft und anschließend die relevanten Teile rauskopieren. Mir ist besonders beim `picoparser` aufgefallen, dass der relativ simpel strukturiert ist.
Hört sich doch insgesamt ganz okay an.funcparserlib is a library for recursive descent parsing using parser
combinators. The parsers made with its help are LL(*) parsers. It means that
it's very easy to write them without thinking about look-aheads and all that
hardcore parsing stuff. But the recursive descent parsing is a rather slow
method compared to LL(k) or LR(k) algorithms. So the primary domain for
funcparserlib is parsing small languages or external DSLs (domain specific
languages).