Buggy `re`-Engine

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.

Soll das Bestandteil der Engine werden und ein improved-Ticket hinzugefügt werden?

Ja
3
27%
Nein (Begründung bitte im Thread posten)
8
73%
 
Abstimmungen insgesamt: 11
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Sonntag 23. September 2007, 10:43

Ich hab einige Regular Expressions, die das momentane Verhalten erwarten. Wenn man das also ändert bricht man ziemlich viel bestehenden Code. Wenn muss das eine Flag bekommen.
TUFKAB – the user formerly known as blackbird
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Sonntag 23. September 2007, 10:49

blackbird hat geschrieben:Ich hab einige Regular Expressions, die das momentane Verhalten erwarten. Wenn man das also ändert bricht man ziemlich viel bestehenden Code. Wenn muss das eine Flag bekommen.
Hi, siehe hier: http://www.python-forum.de/post-78118.html#78118
poker hat geschrieben: Das Problem könnte man aber umgehen in den man eine neue match Funktion hinzufügt und somit die alten unangetastet lässt (Damit bleibt das bisherige Verhalten gewährleistet).

Die neue match Funktion behandelt die Gruppen dann so wie gefordert.

...
Alles bleibt beim alten nur eine zusätzliche Funktion kommt hinzu :)

BTW: Ich mach mal heute Abend einen neuen Thread auf mit einer passenderen Umfrage. Ich glaube nämlich das noch ein par mehr den von mir verlinkten post übersehen haben.

Der Thread kann dann eigentlich geclosed werden :)

Danke für eure Aufmerksamkeit, mfg
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 23. September 2007, 11:18

poker hat geschrieben:@birekenfeld:
birkenfeld hat geschrieben:Für richtig komplexe Ausdrücke kannst du mit REs eh nichts anfangen.
Ist nicht exakt zutreffend, da Oniguruma eine der Leistungsfähigsten regexp Engines ist und viele Möglichkeiten bietet, die diese Aussage leicht blass aussehen lässt (Hab mal gestern wider seit sehr lange Zeit mit Ruby gespielt und den neusten Snappshot mit Oniguruma getestet :shock:). Man siehe hier. Conditions werden wohl auch bald folgen und hoffentlich viele der Vorschläge von WoNàDo ... Und der nächste schritt wird sicherlich in Zukunft in die Richtung gehen wie ich mir das so gedacht habe.
Klar, man kann mit Res vieles machen. Jedoch sind sie nicht immer die Lösung, besonders wenn es komplizierter wird. In den Rubyforen hat WoNaDo mal einen möglicherweise korrekten URL-Mathcer geschrieben. Aber matcht er korrekt? Weiß niemand, denn niemand versteht ihn, weil es eine Übersetzung eines mehrere tausende Zeichen langen ausdrucks aus Perl ist.

Um mal ein letztjähriges Zitat aus meinen IRC-Logs zu holen:
blackbird hat geschrieben:<mitsuhiko> Leonidas: 2007 programmiert wonado eh nur noch in turing vollständigen regular expressions
Das ist eben das was man in Python nicht haben will - eine Verlagerung der Features der Sprache in die Regex-Engine. "There should be one-- and preferably only one --obvious way to do it."
poker hat geschrieben:BTW: Sehe ich das richtig das allgemein kein bedarf nach komplexeren regexp hier herrscht? Warum? Das Ruby Forum scheint da aufgeschlossener zu sein :?
Weil Ruby von der Perl-Seite her geht, und dort Regular-Expressions sehr oft nötig sind. Für die Anwendungsbereiche für die Perl gedacht ist, stimmt das auch. Für Python ist das hingegen nicht der Fall. Python stellt Klarheit vor möglicherweise kryptischen Ausdrücken und die Leute im Python-Forum bevorzugen auch lieber Python-Code als reguläre Ausdrücke.

Übrigens ist eine neue Funktion blöd, lieber ein Flag, das per default aus ist.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Sonntag 23. September 2007, 11:36

Leonidas hat geschrieben: Klar, man kann mit Res vieles machen. Jedoch sind sie nicht immer die Lösung, besonders wenn es komplizierter wird.
Da will ich dir auch garnicht widersprechen und hast auch meine volle Zustimmung. Aber in maßen eingesetzt ist das eine Feine Sache. Und warum sollte man nur wegen dem **wenn** so ablehnend reagieren?

Beispiel: Ich kann mir eine Klassenhierarchie aufbauen wo die letzte Klasse 100 `ancestors`` hat. Klar ist das scheiße und ein anti pattern. Aber nur **weil das** möglich ist, sagen wir doch nicht auf einmal das Klassen abgeschafft werden sollen? So sehe ich das auch mit den REs. Sparsam eingesetzt ist das ein gute Sache und ich sehe nicht ein warum man den Sprachumfang **kastrieren** sollte nur weil man es übertreiben kann?
Leonidas hat geschrieben: Um mal ein letztjähriges Zitat aus meinen IRC-Logs zu holen:
blackbird hat geschrieben:<mitsuhiko> Leonidas: 2007 programmiert wonado eh nur noch in turing vollständigen regular expressions
Ja irgendwann schaft das noch Wolfgang und hat ne Engine dir Wirklich turing vollständigen ist :D Halte ich persönlich für übertrieben, aber aus seinem Tätigkeitsumfeld absolut nachvollziehbar. Für seine Analysen ist er eben darauf angewiesen; und er ist ja auch ein Meister auf dem Gebiet der REs (Wer oder was ist Fridl!!111!! Frag Wolfgang :D).
Leonidas hat geschrieben: Das ist eben das was man in Python nicht haben will - eine Verlagerung der Features der Sprache in die Regex-Engine. "There should be one-- and preferably only one --obvious way to do it."
O.K. kann ich auch nachvollziehen aus pythonista Sicht, aber finde ich dennoch schade.
Leonidas hat geschrieben: Weil Ruby von der Perl-Seite her geht, und dort Regular-Expressions sehr oft nötig sind. Für die Anwendungsbereiche für die Perl gedacht ist, stimmt das auch. Für Python ist das hingegen nicht der Fall. Python stellt Klarheit vor möglicherweise kryptischen Ausdrücken und die Leute im Python-Forum bevorzugen auch lieber Python-Code als reguläre Ausdrücke.
Naja O.K. dann spare ich mir die Arbeit mit dem neuen Thread und mach mich daran oniguruma für Python zu wrappen :D

mfg
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Sonntag 23. September 2007, 11:42

poker hat geschrieben:
Leonidas hat geschrieben: Weil Ruby von der Perl-Seite her geht, und dort Regular-Expressions sehr oft nötig sind. Für die Anwendungsbereiche für die Perl gedacht ist, stimmt das auch. Für Python ist das hingegen nicht der Fall. Python stellt Klarheit vor möglicherweise kryptischen Ausdrücken und die Leute im Python-Forum bevorzugen auch lieber Python-Code als reguläre Ausdrücke.
Naja O.K. dann spare ich mir die Arbeit mit dem neuen Thread und mach mich daran oniguruma für Python zu wrappen :D
Das ist sicher eine gute Idee. Wenn sich das dann durchsetzt, spricht ja auch nichts gegen eine Aufnahme in die Standardbibliothek.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Sonntag 23. September 2007, 11:43

poker hat geschrieben:O.K. kann ich auch nachvollziehen aus pythonista Sicht, aber finde ich dennoch schade.
Ich hab durch pygments wirklich viel mit komplexen REs zu tun und hatte noch nie das Problem was mit SRE nicht matchen zu können (Ruby Heredocs mal ausgenommen, da braucht es ein Callback). Und die Regexpes von beigesteuerten Code zu verstehen ist manchmal schon gar nicht so einfach. Da braucht man eine Minute bis man was geschnallt hat. Mag sein, dass man mit der Zeit besser wird, aber ich hab da so meine Zweifel...

Ich Gegenteil hätte ich lieber eine zweite, etwas limitiertere Regular Expression Engine, die wirklich nur Regular Expressions verarbeitet. Das wäre dann auch *etwas* schneller.
Leonidas hat geschrieben:Weil Ruby von der Perl-Seite her geht, und dort Regular-Expressions sehr oft nötig sind. Für die Anwendungsbereiche für die Perl gedacht ist, stimmt das auch. Für Python ist das hingegen nicht der Fall. Python stellt Klarheit vor möglicherweise kryptischen Ausdrücken und die Leute im Python-Forum bevorzugen auch lieber Python-Code als reguläre Ausdrücke.
Naja O.K. dann spare ich mir die Arbeit mit dem neuen Thread und mach mich daran oniguruma für Python zu wrappen :D
Hehe. Das hatte ich vor wenigen Wochen mal vor, bin aber nicht dazugekommen das dann auch zu tun. Wäre auf jeden Fall eine praktische Sache.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Sonntag 23. September 2007, 12:06

poker hat geschrieben:So sehe ich das auch mit den REs. Sparsam eingesetzt ist das ein gute Sache und ich sehe nicht ein warum man den Sprachumfang **kastrieren** sollte nur weil man es übertreiben kann?
mfg
Sorry, aber die Argumentation kann ich nicht nachvollziehen. Es ist ja nicht so, dass die Funktionalität mal da war und herausgenommen wurde. Es ist nicht mal so, dass sie in vergleichbaren Implementierungen da war. Pythons RE sind also in dieser Hinsicht nicht kastriert ggü. denen anderer Sprachen.

Natürlich kann man das implementieren, ob es so trivial wäre, wie du meinst, weiß ich nicht. Generell ist Python halt keine Sprache, in der REs einen großen Stellenwert einnehmen, und deswegen hat sich bisher auch niemand gefunden, der dieses Feature vermisst hätte.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Sonntag 23. September 2007, 13:01

birkenfeld hat geschrieben: Das ist sicher eine gute Idee. Wenn sich das dann durchsetzt, spricht ja auch nichts gegen eine Aufnahme in die Standardbibliothek.
blackbird hat geschrieben: Hehe. Das hatte ich vor wenigen Wochen mal vor, bin aber nicht dazugekommen das dann auch zu tun. Wäre auf jeden Fall eine praktische Sache.
Danke euch, das bekräftigt meinen Entschluss :)
Blackbird, vielleicht könne wir dann eventuell zusammen arbeiten. Prob ist halt nur, es existieren kein Dokus und Specs. Also erstmal den C code Analysieren ;)
blackbird hat geschrieben:Da braucht man eine Minute bis man was geschnallt hat. Mag sein, dass man mit der Zeit besser wird, aber ich hab da so meine Zweifel...
Ja das stimmt, ich brauche sogar teilweise **viel** länger. Meine eigenen REs Dokumentiere ich für gewöhnlich, aber auch nur wenn sie wirklich kompliziert sind.
blackbird hat geschrieben: Ich Gegenteil hätte ich lieber eine zweite, etwas limitiertere Regular Expression Engine, die wirklich nur Regular Expressions verarbeitet. Das wäre dann auch *etwas* schneller.
An sowas hatte ich auch mal gedacht, auch wegen der gleichen gründen. Hab aber damals nicht wirklich was schlankes zum wrappen gefunden und fürs schreiben haben dann mein C skills dann doch nicht gereicht.

mfg
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Sonntag 23. September 2007, 13:12

birkenfeld hat geschrieben:Sorry, aber die Argumentation kann ich nicht nachvollziehen. Es ist ja nicht so, dass die Funktionalität mal da war und herausgenommen wurde. Es ist nicht mal so, dass sie in vergleichbaren Implementierungen da war. Pythons RE sind also in dieser Hinsicht nicht kastriert ggü. denen anderer Sprachen.
Mein Fehler. ich stimme dir vollkommen zu. Diesmal hab ich das aus einem anderen Kontext (=Oniguruma) betrachtet. Nobody is perfekt ;)
birkenfeld hat geschrieben: Natürlich kann man das implementieren, ob es so trivial wäre, wie du meinst, weiß ich nicht.
Naja, total trivial vielleicht nicht, aber IMO für Core-Devs, die teilweise komplexeres bewältigen müssen, wären zumindest die Sachen mit den groups nicht so kompliziert. Aber viel mehr Sorgen amchen mir die von BlackJack eingeworfenen Begründungen. Es würde mit Sicherheit "sehr" langsam werden.
birkenfeld hat geschrieben: Generell ist Python halt keine Sprache, in der REs einen großen Stellenwert einnehmen, und deswegen hat sich bisher auch niemand gefunden, der dieses Feature vermisst hätte.
O.K. das akzeptieren ich :)

Ich versuche mal Oniguruma mal zu "decrypte" -- Im wahrsten Sinne; Kosako sagt ja selber das der code wirklich sehr dirty ist.
BlackJack

Sonntag 23. September 2007, 14:07

@poker: Dein Vergleich mit Klassen hinkt IMHO ein wenig. So eine "kaputte" Klassenhierarchie würde ich mit einem nicht besonders "intelligenten" normalen regulärem Ausdruck vergleichen. Verschachtelte Gruppen sind dann schon eher so etwas wie Metaklassen. Und da stellt sich tatsächlich die Frage ob jemand der noch alle x Sinne beisammen hat Metaklassen a) oft verwendet und/oder b) diese auch noch verschachtelt.

Das man das bei Metaklassen machen kann, ist nicht so schlimm weil kaum jemand auf die Idee kommt, aber möglichst viel in reguläre Ausdrücke zu quetschen ist in gewissen Kreisen so 'ne Art Sport. Wenn die Möglichkeit da ist, tun die Leute das auch. Und selbst wenn sie aus ihrer Sicht einfache reguläre Ausdrücke schreiben sind das trotzdem noch Comic-Flüche für die meisten anderen Menschen und das passt IMHO so gar nicht zu Python.

Ich finde das hier '(\<)\s*((?:(?:[0-9]+)(?:\s*))+)(\>)' jedenfalls schon zu kryptisch im Gegensatz zu einer EBNF-artigen Darstellung wo die Einzelteile vernünftige Namen bekommen.
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Sonntag 23. September 2007, 20:17

BlackJack hat geschrieben:@poker: Dein Vergleich mit Klassen hinkt IMHO ein wenig. So eine "kaputte" Klassenhierarchie würde ich mit einem nicht besonders "intelligenten" normalen regulärem Ausdruck vergleichen. Verschachtelte Gruppen sind dann schon eher so etwas wie Metaklassen. Und da stellt sich tatsächlich die Frage ob jemand der noch alle x Sinne beisammen hat Metaklassen a) oft verwendet und/oder b) diese auch noch verschachtelt.
Ich finde Pythons Metaklassen System nützlich, auch wenn es viel Verantwortung mitbringt. Übertreiben sollte man das IMO trotzdem nicht. Hängt aber halt vom Einsatzzweck ab und in der Metaprogrammierung -in Verbindung mit ipython oder IDLE - ungemein nützlich.

BlackJack hat geschrieben: Ich finde das hier '(\<)\s*((?:(?:[0-9]+)(?:\s*))+)(\>)' jedenfalls schon zu kryptisch
Ich eigentlich nicht. Ist relative leicht verständlich - wenn man den die Elemente mal auswendig gelernt hat - und zähle ich sogar noch zu den simpleren REs. Schau dir mal `RubyLexer` von http://dev.pocoo.org/projects/pygments/ ... s/agile.py an. Sind IMO ein par kompliziertere Ausdrücke dabei. Aber denoch, weist du was das komplizierteste an den Lexer ist? Nicht die REs sondern den von blackbird angesprochenen teil für heredoc. ``heredoc_callback`` ist IMO so ziemlich das komplizierteste daran und ist kein RE. Wen SRE mehr möglichkeiten zu lassen würde, hätte man das sicherlich auch ohne ein Callback machen können.
BlackJack

Sonntag 23. September 2007, 20:57

Klar wenn man reguläre Ausdrücke kann sind sie einfach. Quantenphysik ist auch einfach wenn man es kann.

Das ist eine simpler Ausdruck, einfach zu schreiben, aber IMHO nicht einfach zu lesen. Ich müsste da jedenfalls wenn ich das nach einem Jahr wieder lese, erstmal im Kopf Klammern parsen und schauen was da zusammengehört und gematcht wird, während eine "EBNF"-Variante wirklich *lesbar* ist.

Metaklassen und ipython/IDLE? Werden da viele Metaklassen verwendet?
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Sonntag 23. September 2007, 21:01

poker hat geschrieben:http://dev.pocoo.org/projects/pygments/ ... s/agile.py an. Sind IMO ein par kompliziertere Ausdrücke dabei. Aber denoch, weist du was das komplizierteste an den Lexer ist? Nicht die REs sondern den von blackbird angesprochenen teil für heredoc. ``heredoc_callback`` ist IMO so ziemlich das komplizierteste daran und ist kein RE. Wen SRE mehr möglichkeiten zu lassen würde, hätte man das sicherlich auch ohne ein Callback machen können.
Das warge ich jetzt einmal zu bezweifeln. Es sei denn die Regular Expression engine bringt eine interne Queue mit :-)
TUFKAB – the user formerly known as blackbird
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Sonntag 23. September 2007, 21:05

BlackJack hat geschrieben:Quantenphysik ist auch einfach wenn man es kann.
Hmmm.... :P
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Sonntag 23. September 2007, 21:32

BlackJack hat geschrieben: Das ist eine simpler Ausdruck, einfach zu schreiben, aber IMHO nicht einfach zu lesen. Ich müsste da jedenfalls wenn ich das nach einem Jahr wieder lese, erstmal im Kopf Klammern parsen und schauen was da zusammengehört und gematcht wird, während eine "EBNF"-Variante wirklich *lesbar* ist.
Klar die EBNF ist immer leichter. Aber ich habs mir z.B. angewöhnt, das ich meine REs dokumentiere wenn mein Projekt Final Status erreicht hat. Außerdem kann man ja mit ``re.X`` auch Kommentare einbeziehen, alles schön einruck und auch gleich mit inline comments versehen :)
BlackJack hat geschrieben: Metaklassen und ipython/IDLE? Werden da viele Metaklassen verwendet?
Ne so meinte ich das nicht. Ob ipython/IDLE welche nutzen k.A.

Was ich meinte ist, das man IDLE/ipython mit in seinem Arbeitsprozess einbeziehen kann (Also konkret als Arbeitsumgebung nutzt, so wie ein Admin zum Beispiel seine Shell) und oft noch garnicht weiß, wie das Ergebnis danach aussieht bzw. was noch dazu kommt, da es abhängig ist von den restlichen Anforderungen und Informationen die nach und nach eintrudeln. Wehrend dieses Prozesses kann sich also die Struktur ziemlich stark ändern.

Und da kommt hat die Leistungsfähigkeit dynamischer sprachen zu tragen, die richtige Metaprogrammierung erst möglich machen. Und da ist IMO Pythons Metaklassen System ungemein hilfreich damit das System auf bestimmte Änderungen automatisch Reagieren kann (z.B. automatisch Datenstrukturen zur Laufzeit anpassen zu lassen), usw, ohne den kompletten Code anfassen zu müssen.

Das ist aber halt nun ein ganz anderes Einsatzgebiet und hat mit normaler software Programmierung nichts mehr zu tun, sondern könnte man eher als Produktionsumgebung bezeichnen. Das man sich dafür erstmal viel zusätzliches programmieren muss (Eine Engine die den Anforderungen gerecht wird) ist klar. Das auch das seine Grenzen hat ist auch klar.

Kurz gesagt geht es darum, Alltagsprobleme mit bewusster Einbeziehung von ipython/IDLE und Shell zu lösen, aber ohne bereits in ipython reingehackten code neu schreiben zu müssen, sondern das vieles dynamische vonstatten geht, wenn ich die Engine mit neuen Kriterien füttere. Das diese Art der Programmierung auch seine grenzen aht ist klar. Man muss doch noch vieles per Hand ändern, aber das wird dadurch "sehr" stark minimiert.

EDIT:
blackbird hat geschrieben: Das warge ich jetzt einmal zu bezweifeln. Es sei denn die Regular Expression engine bringt eine interne Queue mit :-)
Hehe, das mag gut sein, hab den Code auch nicht wirklich weiter analysiert und verstanden (Müsste mal demnächst nen Debuger rüber laufen lassen). Aber, möglich wäre es vielleicht schon, nur noch nicht jetzt :) WoNaDo hatte da mal ein par nette Vorschläge, das man ähnlich wie in Perl, Funktionen definiert die innerhalb von REs aufgeruffen werden. Seine Überlegungen gingen aber noch weiter als in Perl möglich :D
konkret (Rein hypothetisch):
- Wir führen das ein.
- zusätzlich conditions
- ein callback1 wird definiert das auf eine Queue zugreift und sie mit bestimmten Sachen füttert und bestimmter Abhängigkeit die prozessierten Stack dem RE match zuführt. (k.A. wie ich das nun besser ausdrücken soll :D)

Vorteil: Das callback wird verständlicher (Mutmaßung).
Nachteil: Die REs werden eventuell viel zu komplex als der bisherige Ansatz mit REs und komplizierten callback?
Antworten