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
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
)
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?
). Man 
