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%
 
Insgesamt abgegebene Stimmen: 11
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

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

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

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

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

@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

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

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:

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

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

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?
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

Ich persönlich find' die momentane RE Engine ziemlich pythonisch. Wär's noch komplexer, könnt' ich doch gleich Perl oder Ruby nehmen oO'...

(Vielleicht ein wenig Krass ausgedrückt...)

Ich hab mit REs noch nicht alzu viel zu tun gehabt, aber wenn ich welche im Quellcode sehe, kann ich die noch recht einfach deuten. Wenn ich die jedoch bei Perl oder Ruby seh', geht's schon nich mehr ganz so einfach... Und eine Sache die ich an Python liebe ist halt:

*in quellcode schau*
"OH GOTT, dass is' ja cool gelöst. Warum bin ich darauf nich gekommen??"

Bei keiner anderen Programmiersprache ging' es mir bisher so...
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

BlackVivi hat geschrieben:Ich hab mit REs noch nicht alzu viel zu tun gehabt, aber wenn ich welche im Quellcode sehe, kann ich die noch recht einfach deuten. Wenn ich die jedoch bei Perl oder Ruby seh', geht's schon nich mehr ganz so einfach...
Seltsam. Dabei ist die momentane Ruby Regexp Engine (die, die du wahrscheinlich gesehen hast) viel limitierter als die Python Engine. Kein Unicode, kein Lookbehind, kein Lookahead, keine Named Groups :-)
TUFKAB – the user formerly known as blackbird
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

blackbird hat geschrieben:
BlackVivi hat geschrieben:Ich hab mit REs noch nicht alzu viel zu tun gehabt, aber wenn ich welche im Quellcode sehe, kann ich die noch recht einfach deuten. Wenn ich die jedoch bei Perl oder Ruby seh', geht's schon nich mehr ganz so einfach...
Seltsam. Dabei ist die momentane Ruby Regexp Engine (die, die du wahrscheinlich gesehen hast) viel limitierter als die Python Engine. Kein Unicode, kein Lookbehind, kein Lookahead, keine Named Groups :-)
Hmpf, vielleicht hab ich mich verguckt oder so. Hab mich mit Ruby nicht alzu doll befasst. Ich zielte eher auf Perl ab...

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

blackbird hat geschrieben: Seltsam. Dabei ist die momentane Ruby Regexp Engine (die, die du wahrscheinlich gesehen hast) viel limitierter als die Python Engine. Kein Unicode, kein Lookbehind, kein Lookahead, keine Named Groups :-)
Nein! ;)
Siehe Punkt 7 http://www.geocities.jp/kosako3/oniguruma/doc/RE.txt
Wenn man sich die liste mal ansieht ist die sogar umfangreicher :roll:

- Es ist voll (so weit ich sehe) POSIX kompatibel was man von SRE nicht sagen kann.
- Es hat Möglichkeit für ``atomic group`` (kein backtrack in subexp, was die Geschwindigkeit erhöht.), hat SRE nicht.
- Es hat back reference mit angebe des Verschachtelungslevel, hat SRE auch nicht => ``\k<name+n>`` wobei n der level ist und +/- = ahead/behind.

Aber was ärgerlich ist, das es keine Conditions hat ``(?(condition)yes-pat|no-pat)``. Da ist Python voraus.

BTW: Falls du Ruby 1.8.x meinst: Kannst oniguruma updaten. Gibts ein Binary/source für...
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

poker hat geschrieben:
blackbird hat geschrieben: Seltsam. Dabei ist die momentane Ruby Regexp Engine (die, die du wahrscheinlich gesehen hast) viel limitierter als die Python Engine. Kein Unicode, kein Lookbehind, kein Lookahead, keine Named Groups :-)
*snip*

BTW: Falls du Ruby 1.8.x meinst: Kannst oniguruma updaten. Gibts ein Binary/source für...
Ich bezweifle, dass ihm durch Zufall Ruby Code untergekommen ist, der Oniguruma nutzt. Was Oniguruma kann weiß ich selber, die Featureliste brauchst du mir nicht in jedem Post einfügen :roll:

Der einzige 1.8 Code, der Oniguruma nutzt ist meines Wissens nach die Testsuite davon und TextPow.
TUFKAB – the user formerly known as blackbird
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

@blackbird:
Hi, bin schon ein wenig weiter. Will das ganze nun auf ner Windows Kiste testen um zu sehen ob es auch darauf Funktioniert. Hast ne Ahnung was ich installieren könnte um bahs, etc auf Windows nutzen zu können? Krieg oniguruma sonst nicht darauf kompiliert.

Hab schon google angeworfen aber werde mit verschiedenen Lösungen konfrontiert. Gibt es ein besonderen geheim Tipp?

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

blackbird hat geschrieben: Was Oniguruma kann weiß ich selber, die Featureliste brauchst du mir nicht in jedem Post einfügen :roll:
Ja. Fühl dich doch nicht gleich angepisst. Das musst du abkönnen, bist ja auch nicht gerade auf den Mund gefallen und hältst hinterm Zaun ;)
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

poker hat geschrieben:@blackbird:
Hi, bin schon ein wenig weiter. Will das ganze nun auf ner Windows Kiste testen um zu sehen ob es auch darauf Funktioniert. Hast ne Ahnung was ich installieren könnte um bahs, etc auf Windows nutzen zu können? Krieg oniguruma sonst nicht darauf kompiliert.
Sofern du nicht im Besitz einer Visual Studio 2005 Lizenz bist eher gar nicht. Installier dir ein Linux in einer vmware box und teste das dort.

//EDIT: Da du meine Post anscheind genauso genau durchliest, wie du es von mir behauptest dürfte mir diese, etwas angebissen Aussage zustehen.
TUFKAB – the user formerly known as blackbird
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

blackbird hat geschrieben: Sofern du nicht im Besitz einer Visual Studio 2005 Lizenz bist eher gar nicht. Installier dir ein Linux in einer vmware box und teste das dort.
Argh. Das ja mist ;( Also brauch ich VS um das ganze auf win kompiliert zu kriegen? Ist aber auch mist, wollte das der oniguruma wrapper auf win und Linux läuft. In das win package wollte ich ne dll integrieren ;(

EDIT:
blackbird hat geschrieben: //EDIT: Da du meine Post anscheind genauso genau durchliest, wie du es von mir behauptest dürfte mir diese, etwas angebissen Aussage zustehen.
Jupp, hast ja auch recht. :) Hatte dein Post fasch interpretiert.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

poker hat geschrieben:
blackbird hat geschrieben: Sofern du nicht im Besitz einer Visual Studio 2005 Lizenz bist eher gar nicht. Installier dir ein Linux in einer vmware box und teste das dort.
Argh. Das ja mist ;( Also brauch ich VS um das ganze auf win kompiliert zu kriegen? Ist aber auch mist, wollte das der oniguruma wrapper auf win und Linux läuft. In das win package wollte ich ne dll integrieren ;(
VS wäre ja nicht das Problem, das bekommst du ja mittlerweile kostenlos. Aber immer nur die aktuelle Version. Und was hindert VS daran, dass deine Library auf Linux läuft? Sofern du deinen Quellcode schön platform unabhängig hälst...
TUFKAB – the user formerly known as blackbird
Antworten