Magisches Verhalten in Perl und Python

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.
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

sape hat geschrieben:
PmanX hat geschrieben:[...]
Wo ist hier ein erfolgreiches Matching?
Liest du eigentlich was ich schreibe?
Sorry, kann ich nur zurückgeben. Deine zitierte Zeile beschreibt doch Dein Problem.
Warum, frage ich, sollen die Variablen bei einem erfolglosen Matching gesetzt werden?

EDIT:
Warum ist es Haarspalterei, wenn stets von magischer Erzeugung von Variablen gesprochen wird, die nicht erzeugt werden?
Sie sind entweder undefiniert oder mit dem Leerstring besetzt.
Beides ist FALSE und läßt sich wunderbar abfragen.
Zuletzt geändert von PmanX am Samstag 10. Februar 2007, 20:47, insgesamt 1-mal geändert.
BlackJack

PmanX hat geschrieben:Wo ist hier ein erfolgreiches Matching?
Da ist keines, also sind auch die Variablen nicht da. Wäre eines da gewesen, dann wären die Variablen erzeugt worden. Was Du abgestritten hast mit dem Hinweis das setzen != erzeugen sei.

Und das es sich bei dem "matchen" um einen Operator statt eine Funktion handelt, ist irrelevant. Ausser das es bei Operatoren implizite Vorrangregeln gibt, ist so ein Operator auch nur ein Ersatz für einen Funktionsaufruf.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

BlackJack hat geschrieben:
PmanX hat geschrieben:Wo ist hier ein erfolgreiches Matching?
Da ist keines, also sind auch die Variablen nicht da. Wäre eines da gewesen, dann wären die Variablen erzeugt worden. Was Du abgestritten hast mit dem Hinweis das setzen != erzeugen sei.
[...]
Ganz genau das wollte ich aussagen.

Und mehr gibt es, denke ich, dazu auch nicht zu sagen.
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

BlackJack hat geschrieben:
PmanX hat geschrieben:Wo ist hier ein erfolgreiches Matching?
Da ist keines, also sind auch die Variablen nicht da. Wäre eines da gewesen, dann wären die Variablen erzeugt worden. Was Du abgestritten hast mit dem Hinweis das setzen != erzeugen sei.
Falsch. Die Variablen sind da.
BlackJack hat geschrieben: Und das es sich bei dem "matchen" um einen Operator statt eine Funktion handelt, ist irrelevant. Ausser das es bei Operatoren implizite Vorrangregeln gibt, ist so ein Operator auch nur ein Ersatz für einen Funktionsaufruf.
Wenn es um den Gültigkeitsbereich von Variablen geht, ist es für mich nicht irrelevant.
Wie ich im Codebeispiel gezeigt hatte, besitzen die magischen Variablen außerhalb der Funktion EDIT: keinen definierten Wert.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

PmanX hat geschrieben:[...]
Sie sind entweder undefiniert oder mit dem Leerstring besetzt.
Beides ist FALSE und läßt sich wunderbar abfragen.
Ja, stimmt ich vergaß das es diese inkonsistente art in Perl gab.

Code: Alles auswählen

#!/usr/bin/perl
use strict;
use warnings;
 
my $foobar = "bin leer";

#print "$foobar\n";

$foobar =~ /<\/bar>/;
# Huch was ist den das? Wo kommt den $', $` und$& her? Nicht magisch?!
if ($' or $` or $&){
    print "post: $'\n";
    print "pre: $`\n";
    print "this: $&\n"; 
} else {print "blubb";};
man kann auf die "nicht" initialisierte Variable nicht direkt zurückgreifen, außer in einem if-statement. :roll:
Ein print $` bringt ein "Use of uninitialized value in concatenation (.) or string at foobar.pl line 11.".

Ok, sie werden nicht erzeugt sondern "initialisiert" (Was aber schon ein Widerspruch zum aufgezeigten verhalten ist).

Und sowas willst du ernsthaft in Python haben? Nein danke. Wenn du sowas brauchst bleib doch bei Perl :) Ich nutze es auch oft für quick'n'dirty Scripts :)

Hey, schön finde ich ja das Verhalten:

Code: Alles auswählen

#!/usr/bin/perl
use strict;
use warnings;
 
my $foobar = "bin nicht leer </bar>";

#print "$foobar\n";

$foobar =~ /<\/bar>/;
# Huch was ist den das? Wo kommt den $', $` und$& her? Nicht magisch?!
if ($'){
    print "post: $'\n";
    print "pre: $`\n";
    print "this: $&\n"; 
} else {print "blubb";};
Wunderbar, es wird mir blubb ausgegeben obwohl der match erfolgreich war. Warum? empty-string...

ok machen wir daraus ``if ($' or $' eq ''){``: Super geht doch.
Aber moment:

Code: Alles auswählen

#!/usr/bin/perl
use strict;
use warnings;
 
my $foobar = "bin nicht leer";

#print "$foobar\n";

$foobar =~ /<\/bar>/;
# Huch was ist den das? Wo kommt den $', $` und$& her? Nicht magisch?!
if ($' or $' eq ''){
    print "post: $'\n";
    print "pre: $`\n";
    print "this: $&\n"; 
} else {print "blubb";};

Code: Alles auswählen

Use of uninitialized value in string eq at foobar.pl line 11.
Ja, stimt ja sie ist nicht "initialisiert" daher ist ein eq nicht erlaubt :roll:

Also muss man dann doch ``if ($' or $` or $&)`` wie im ersten listning nutzen damit bei einem erfolgreichen match auf jedenfall das if... ausgeführt wird.

Soll ich weiter machen? Ich Könnte den ganzen Abend von der Inkonsistenz von Perl berichten...

lg
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

PmanX hat geschrieben:
BlackJack hat geschrieben: Und das es sich bei dem "matchen" um einen Operator statt eine Funktion handelt, ist irrelevant. Ausser das es bei Operatoren implizite Vorrangregeln gibt, ist so ein Operator auch nur ein Ersatz für einen Funktionsaufruf.
Wenn es um den Gültigkeitsbereich von Variablen geht, ist es für mich nicht irrelevant.
Wie ich im Codebeispiel gezeigt hatte, besitzen die magischen Variablen außerhalb der Funktion EDIT: keinen definierten Wert.
Ist ja schön und gut, aber Du hast nicht verstanden was dieses Script aussagen sollte. Es sollte verdeutlichen das da aus heiterem Himmel auf einmal ``foo`` erzeugt wird mit einer Funktion/Operator/etc... und man danach auf ``foo`` zurückgreifen kann aus dem global namespace (Ok, in dem beispiel der space von __builtins__ der aber global erreichbar ist oder so ähnlich ;) -- Tut aber nichts zur Sache).

So, das =~ /.../ zeigt ein ähnliches Verhalten nach außen hin. Ob die nun initialisiert werden oder erzeugt ist irrelevant für mich. Es passiert dort etwas "magisches" oder besser gesagt implizites, das wir in Python nicht haben wollen.

Mit den Funktionen in Perl oder den Pseudo-Klassen fange ich mal lieber erst garnicht an...
BlackJack

PmanX hat geschrieben:
BlackJack hat geschrieben:
PmanX hat geschrieben:Wo ist hier ein erfolgreiches Matching?
Da ist keines, also sind auch die Variablen nicht da. Wäre eines da gewesen, dann wären die Variablen erzeugt worden. Was Du abgestritten hast mit dem Hinweis das setzen != erzeugen sei.
Falsch. Die Variablen sind da.
Oh bitte, dann gibt es in jedem Perl-Skript Milliarden von Variablen. Die sind alle da, nur eben nicht initialisiert. Das ist jetzt nicht wirklich Dein Argument, oder?
BlackJack hat geschrieben: Und das es sich bei dem "matchen" um einen Operator statt eine Funktion handelt, ist irrelevant. Ausser das es bei Operatoren implizite Vorrangregeln gibt, ist so ein Operator auch nur ein Ersatz für einen Funktionsaufruf.
Wenn es um den Gültigkeitsbereich von Variablen geht, ist es für mich nicht irrelevant.
Wie ich im Codebeispiel gezeigt hatte, besitzen die magischen Variablen außerhalb der Funktion EDIT: keinen definierten Wert.
Um diese Funktion geht es gar nicht. Es geht um das "matchen" das in Perl ausserhalb des Ausdrucks in dem es passiert den Zustand von Variablen verändert, die nicht explizit erwähnt werden. Denn innerhalb der Funktion in Deinem Beispiel passiert genau das. Eine Magie die es bei `re` in Python nicht gibt.
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

BlackJack hat geschrieben: Oh bitte, dann gibt es in jedem Perl-Skript Milliarden von Variablen. Die sind alle da, nur eben nicht initialisiert. Das ist jetzt nicht wirklich Dein Argument, oder?
:shock: Ich sehe keinen entscheidenen Unterschied, ob Python eine neue Match-Instanz bildet oder Perl die Variablen initialisiert.
BlackJack hat geschrieben: Um diese Funktion geht es gar nicht. Es geht um das "matchen" das in Perl ausserhalb des Ausdrucks in dem es passiert den Zustand von Variablen verändert, die nicht explizit erwähnt werden. Denn innerhalb der Funktion in Deinem Beispiel passiert genau das. Eine Magie die es bei `re` in Python nicht gibt.
Die Variablen stehen innerhalb des Blockes zur Verfügung und genau das erwarte ich auch.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

PmanX hat geschrieben:
BlackJack hat geschrieben: Oh bitte, dann gibt es in jedem Perl-Skript Milliarden von Variablen. Die sind alle da, nur eben nicht initialisiert. Das ist jetzt nicht wirklich Dein Argument, oder?
:shock: Ich sehe keinen entscheidenen Unterschied, ob Python eine neue Match-Instanz bildet oder Perl die Variablen initialisiert.
Es ist jedenfalls ein Unterschied da. Wie man den wahrnimmt entscheidet dann eben auch, was man an einer Sprache gut bzw. schlecht findet.
BlackJack hat geschrieben: Um diese Funktion geht es gar nicht. Es geht um das "matchen" das in Perl ausserhalb des Ausdrucks in dem es passiert den Zustand von Variablen verändert, die nicht explizit erwähnt werden. Denn innerhalb der Funktion in Deinem Beispiel passiert genau das. Eine Magie die es bei `re` in Python nicht gibt.
Die Variablen stehen innerhalb des Blockes zur Verfügung und genau das erwarte ich auch.
[/quote]
Ich erwarte dagegen halt, dass ohne eine explizite Zuweisung meinerseits in einem Scope nicht einfach so Variablen "auftauchen". Aber wie oben gesagt, das ist Gewöhnungssache.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

sape:

Code: Alles auswählen

#!/usr/bin/perl
use strict; use warnings;

my $foobar = "bin leer";

print "$foobar\n";

$foobar =~ /<\/bar>/;
if ($' or $` or $&){
    print "post: $'\n";
    print "pre: $`\n";
    print "this: $&\n";
} else { print "blubb" }
Welche Variable soll hier wahr werden?

Code: Alles auswählen

#!/usr/bin/perl
use strict;
use warnings;
 
my $foobar = "bin nicht leer </bar>";

$foobar =~ /<\/bar>/;
if ($'){
    print "post: $'\n";
    print "pre: $`\n";
    print "this: $&\n";
} else {print "blubb";};
Dir ist aufgefallen, dass der Match am Ende des Strings erfolgt. Warum soll das wahr werden?

Code: Alles auswählen

#!/usr/bin/perl
use strict;
use warnings;
 
my $foobar = "bin nicht leer";
$foobar =~ /<\/bar>/;

if ($' or $' eq ''){
    print "post: $'\n";
    print "pre: $`\n";
    print "this: $&\n";
} else {print "blubb";};
Dir ist aufgefallen, dass der Block ausgeführt wird. $' eq '' So könnte man wohl Deine unsinnigen Beispiele weiter kommentieren.
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

birkenfeld hat geschrieben:Es ist jedenfalls ein Unterschied da. Wie man den wahrnimmt entscheidet dann eben auch, was man an einer Sprache gut bzw. schlecht findet.
Ich finde gentoo gut. Nebenbei ein Grund mir Python anzuschauen. Aber es gibt nicht die Distribution. Jede hat Schwächen.
Python hat es doch nicht nötig, dass mit Falschaussagen eine andere Programmiersprache schlecht gemacht wird.
BlackJack

PmanX hat geschrieben:
BlackJack hat geschrieben: Oh bitte, dann gibt es in jedem Perl-Skript Milliarden von Variablen. Die sind alle da, nur eben nicht initialisiert. Das ist jetzt nicht wirklich Dein Argument, oder?
:shock: Ich sehe keinen entscheidenen Unterschied, ob Python eine neue Match-Instanz bildet oder Perl die Variablen initialisiert.
Okay, nochmal von vorne:

Code: Alles auswählen

# Hier ist `match` noch nicht "initialisiert".
match = re.search('(.*)', 'foo')
# Hier ist `match` nun "initialisiert".
Das ist eine ganz normale Zuweisung. Der Name der hier in den Namensraum eingeführt wird, steht klar und deutlich da, das ist die Art wie nicht nur bei regulären Ausdrücken Namen eingeführt werden, und das ist die einzige Änderung im Namensraum. Das ist bei Perl nicht so, da ändern sich mehrere Variablen im Namensraum in dem der Ausdruck ausgewertet wird, die aber nicht in dem Ausdruck selbst explizit erwähnt werden.

Wenn das in Python so wie in Perl funktionieren würde, dann sähe das wahrscheinlich ungefähr so aus:

Code: Alles auswählen

# Hier ist `_1` noch nicht "initialisiert".
re.search('(.*)', 'foo')
# Und jetzt ist `_1` plötzlich an die erste Gruppe gebunden.
print _1
Ich finde das ist ein entscheidender Unterschied. Jetzt würde ich mich nämlich fragen, was da noch alles still und heimlich passiert. Welche Namen ich (selbst) benutzen kann und welche nicht. Und welche Funktionen vielleicht auch so ein Verhalten haben und was die wohl für Namen benutzen.
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

Code: Alles auswählen

>>> m=re.search('(.*)', 'foo') 
>>> m.group(1)
'foo'
>>> m.group(0)
'foo'
>>> 
Etwas mehr passiert hier schon, wenn das Resultat nicht weggeworfen wird.
EDIT:
Da man die Werte ja will, sieht der Unterschied für mich so aus:
Python)
Ich muß die Methoden kennen um die Variablen auszulesen.
Perl)
Ich muß die handvoll ma.. Variablen kennen.

Beides ist entsprechend dokumentiert.
Sorry, jetzt will ich nicht mehr :)
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

PmanX hat geschrieben:Welche Variable soll hier wahr werden?
Siehe hier:
sape hat geschrieben:Also muss man dann doch ``if ($' or $` or $&)`` wie im ersten listning nutzen damit bei einem erfolgreichen match auf jedenfall das if... ausgeführt wird.
PmanX hat geschrieben:Dir ist aufgefallen, dass der Match am Ende des Strings erfolgt. Warum soll das wahr werden?
Siehe hier:
PmanX hat geschrieben:[friedl]Ein erfolgreiches Matching oder eine Substitution setzt (!= erzeugt) eine Reihe von speziellen Variablen ...
Diese Variablen ändern sich nie bei einem erfolgreichen Matching-Versuch, und sie werden immer gesetzt, wenn ein Treffer gefunden wird[/friedl]
Sie ist ja auch gesetzt aber ein vergleich auf True geht dennoch nicht weil:
sape hat geschrieben:Wunderbar, es wird mir blubb ausgegeben obwohl der match erfolgreich war. Warum? empty-string...
Also weil es ein leerer String ist.
PmanX hat geschrieben:Dir ist aufgefallen, dass der Block ausgeführt wird. $' eq '' So könnte man wohl Deine unsinnigen Beispiele weiter kommentieren.
Ja wurde er wirklich ausgeführt oder hat er nicht doch ein "Use of uninitialized value in string eq at foobar.pl line 11." ausgegeben weil ein ``if ($' eq '')`` auf nicht "initialisierte" nicht geht? Aber ein schlichtes ``if ($')`` geht aber auf nicht initialisierte. Sehr konsistent.

Wo wir auch wider bei deiner ersten rethorischen Frage wären:
PmanX hat geschrieben:Welche Variable soll hier wahr werden?
Mit einen ``if ($' or $` or $&)`` kann sichergestellt werden das nach einen erfolgreichen match der if-block immer ausgeführt wird, unabhängig davon ob einer der Variabel ($', $`, $&) ein Leerstring ist.
Wenn eben der match nicht erfolgreich ist, ergibt jede der Variablen false und es wird das else ausgeführt.

Wenn du aber nur auf eine Variabel überprüfen würdest und die zufällig ein Leerstring wäre würde der block halt nicht ausgeführt werden, obwohl der match erfolgreich ist. Ich erwarte aber das nach erfolgreichen match der block ausgeführt wird, unabhängig ob eine der 3 Variablen ein Leerstring ist.

Ist das so unverständlich rüber gekommen? Man muss allerdings auch die posts der anderen verstehen wollen. Und die Betonung liegt ganz klar auf wollen.
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

Endgültig abschließend.
Wenn du aber nur auf eine Variabel überprüfen würdest und die zufällig ein Leerstring wäre würde der block halt nicht ausgeführt werden, obwohl der match erfolgreich ist. Ich erwarte aber das nach erfolgreichen match der block ausgeführt wird, unabhängig ob eine der 3 Variablen ein Leerstring ist.
Ein Leerstring wird nicht wahr, auch wenn Du es nicht verstehen willst.
Wenn Du das Ergebnis eines erfolreichen Matches willst, mußt Du korrekt formulieren

Code: Alles auswählen

if ($foobar =~ /<\/bar>/) { ... }
und nicht eine Variable abfragen, die im entsprechenden Match nie wahr wird.
Eine Mütze Schlaf wird Dir möglicherweise beim verstehen wollen helfen.
rayo
User
Beiträge: 773
Registriert: Mittwoch 5. November 2003, 18:06
Wohnort: Schweiz
Kontaktdaten:

Hi

Es geht nicht darum ob man das Resultat (das Matchobjekt) kennt oder nicht, sondern nur um die Zuweisung geht es.

In Python sieht man durch das "=", dass dem Namen "m" das Resultat des regulären Ausdruckes zugewiesen wird.

Code: Alles auswählen

m = re.search('(.*)', 'foo') # m wird klar definiert
In Perl dagegen wird keine Zuweisung gemacht, nur der reguläre Ausdruck wird gemacht. Danach sind im Namensraum auf einmal $' $` und $& gesetzt, ohne dass diese in dem aktuellen Block jemals zugewiesen wurden.

Code: Alles auswählen

$foobar =~ /<\/bar>/;
Wo seh ich in diesem Block die Zuweisung der $' $` $& Variabeln? Diese wurden in einem tieferen Block erstellt, somit weiterhin gültig anstatt nur im Block in dem diese definiert wurden.

Das ist die Magie.

Gruss
BlackJack

PmanX hat geschrieben:

Code: Alles auswählen

>>> m=re.search('(.*)', 'foo') 
>>> m.group(1)
'foo'
>>> m.group(0)
'foo'
>>> 
Etwas mehr passiert hier schon, wenn das Resultat nicht weggeworfen wird.
EDIT:
Da man die Werte ja will, sieht der Unterschied für mich so aus:
Python)
Ich muß die Methoden kennen um die Variablen auszulesen.
Perl)
Ich muß die handvoll ma.. Variablen kennen.
Also doch Magie, auch wenn Du's nicht ausschreiben magst. Es geht um den Namensraum in dem die dokumentierten Namen sich befinden bzw. auftauchen. Bei Perl muss man die Dokumentation kennen um sich nicht fragen zu müssen was `$1` denn eigentlich ist und welche der vorherigen Zeilen das wohl gesetzt haben mag. Bei Python ist sofort ersichtlich wo `match` seinen Wert herbekommt und das `group()` etwas mit dem `match` zu tun hat. Und wenn man die Begrifflichkeiten von regulären Ausdrücken kennt, weiss man auch schon was mit der Zeile höchstwahrscheinlich gemeint ist.

Dynamische Sichtbarkeitsbereiche werden von den meisten Pythonistas als unsauber angesehen, weil Funktionen, die im Namensraum des Aufrufers machen können was sie wollen, schnell zu Problemen führen können und Quelltext der so etwas benutzt schwerer zu durchschauen ist.
PmanX
User
Beiträge: 123
Registriert: Donnerstag 25. Januar 2007, 13:50
Wohnort: Germany.BB.LOS
Kontaktdaten:

BlackJack hat geschrieben: Also doch Magie, auch wenn Du's nicht ausschreiben magst. Es geht um den Namensraum in dem die dokumentierten Namen sich befinden bzw. auftauchen. Bei Perl muss man die Dokumentation kennen um sich nicht fragen zu müssen was `$1` denn eigentlich ist und welche der vorherigen Zeilen das wohl gesetzt haben mag. Bei Python ist sofort ersichtlich wo `match` seinen Wert herbekommt und das `group()` etwas mit dem `match` zu tun hat. Und wenn man die Begrifflichkeiten von regulären Ausdrücken kennt, weiss man auch schon was mit der Zeile höchstwahrscheinlich gemeint ist.

Dynamische Sichtbarkeitsbereiche werden von den meisten Pythonistas als unsauber angesehen, weil Funktionen, die im Namensraum des Aufrufers machen können was sie wollen, schnell zu Problemen führen können und Quelltext der so etwas benutzt schwerer zu durchschauen ist.
Die Auseinandersetzung mit den regulären Ausdrücken von Perl hat ja was Positives.
Von den 5 Variablen

Code: Alles auswählen

$1, $2, $3 .. $n  # erste, zweite .. Klammerpaar
$+                    # Kopie des letzten Klammerpaars
$&                    # Text der auf gesamte Regex paßt
$`                     # Kopie des Textes davor
$'                      # Kopie des Textes nach dem Treffer
habe ich bisher nur

Code: Alles auswählen

$1 .. $n und $+
benutzt. Diese werden nach einem erfolgreichen Matching im aktuellen Block gesetzt und sind dort gültig. Wenn man diese zwei Sätze nicht versteht, sollte man die Finger von regulären Ausdrücken lassen.
Und ich wage zu behaupten, dass nur ein kleiner Teil der Pythonistas re komplett verstanden hat.

Dieses definierte Verhalten kann man nutzen. Es fällt niemandem auf den Fuß, wenn er es läßt.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Es gibt da zwei Ebenen, die man verstehen muss: zum einen die regulären Ausdrücke selbst, zum anderen die API zur Nutzung.

Das erste ist das, was den meisten anfangs Schwierigkeiten bereitet. Hat man REs verstanden, braucht man nur noch die Funktionen und Klassen des re-Moduls kennen, und die verhalten sich wie die in allen anderen Modulen auch.

Freilich versteht man Perls Verhalten auch nicht erst Wochen später, es geht hier hauptsächlich um die Philosophie.
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:

PmanX hat geschrieben:Die Auseinandersetzung mit den regulären Ausdrücken von Perl hat ja was Positives.
Wir reden nicht von Regulären Ausdrücken sondern vom Konzept eines dynamischen Scopes.
Von den 5 Variablen [...] habe ich bisher nur

Code: Alles auswählen

$1 .. $n und $+
benutzt. Diese werden nach einem erfolgreichen Matching im aktuellen Block gesetzt und sind dort gültig.
Ich geb zu, dass ich von Perl keine Ahnung habe, aber das selbe Konzept haben wir in Ruby auch. Dort verwende ich fast ausschließlich nur $1 - $9, sowie $~, der den letzten Match als MatchData objekt enthält:

Code: Alles auswählen

irb(main):001:0> %r(<([a-z]+)>(.*?)</\1>) =~ "<peter>max and moritz</peter>"
=> 0
irb(main):002:0> $1
=> "peter"
irb(main):003:0> $2
=> "max and moritz"
irb(main):004:0> $~.begin(0)
=> 0
irb(main):005:0> $~.end(0)
=> 29
Damit lassen sich dann tatsächlich auch so tolle Konstrukte bauen wie:

Code: Alles auswählen

return other[$~.start(0)..$~.end(0)] if /.../ =~ blah
(das impliziert halt, dass rubys true/false konzept blöd ist ^^)

Aber weißt du was? Ich finde es deswegen nicht besser. $foobar Variablen sind in Ruby wenigstens durch die Bank "vordefiniert", das heißt auf nicht deklarierte globals zuzugreifen resultiert in nil. Allerdings haben wir soetwas in Python nicht. Und ich sehe auch nur Probleme soetwas einzufügen.

Und mal ehrlich! Wer braucht soetwas?
Wenn man diese zwei Sätze nicht versteht, sollte man die Finger von regulären Ausdrücken lassen.
Dann lass die Finger davon.
Und ich wage zu behaupten, dass nur ein kleiner Teil der Pythonistas re komplett verstanden hat.
Hast du es? Ich bezweilfe es. Und du wirst Recht haben. Die Anzahl der Personen die jeden Kniff der sre Bibliothek kennen wird verdammt klein sein. Gerade re.scanner ist mir nur aufgefallen als ich in den Sourcen nachgesehen habe.
TUFKAB – the user formerly known as blackbird
Antworten