Woher kommt das Type = NoneType?

[Karl]

@Karl: Hör doch mal auf anderen vor zu werfen, sie würden sich nicht mit Deinem Quelltext im Detail beschäftigen wollen und gehe mal auf die direkten Antworten auf das Problem ein. In diesem Quelltext:

Code: Alles auswählen

    def loop_begin(self, i): 
         if self.array[self.pointer] == 0: 
             x = 1 
             for i in xrange(len(self.code)): 
                 if self.code[i] == "[": 
                     x += 1 
                 if self.code[i] == "]": 
                     x -= 1 
                     if x == 0: 
                         return i 
         else: 
             self.tmp.append(i) 
             return i

besteht im ``if``-Zweig die Möglichkeit, dass *kein* ``return`` ausgeführt wird, und dann wird `None` zurückgegeben. Und das trotz Deiner Behauptung das könne nie passieren. Da es aber *doch* passiert, stell doch mal Deine Sicht der Dinge in Frage und nicht die der Leute, deren Sicht mit denen des Python-Interpreters deckt. *Der* hat nämlich immer Recht.

Okay, ich korregiere mich.
Die Möglichkeit besteht tatsächlich, weil ich einen kleinen Fehler eingebaut hab, es müsste x = 0 heißen, keine Ahnung, wie ich auf x = 1 gekommen bin.
Ich war davon überzeugt, dass das if, wenn es aufgerufen wird, zwangsläufig bis zum return durchläuft, aber aufgrund des Fehlers dann eben doch nicht.
Aber mein Vorwurf, dass sich die Leute nicht richtig damit befasst haben, halte ich schon für gerechtfertigt, weil die meisten Antworten irgendwie am Thema vorbeigingen beziehungsweise das Problem falsch interpretiert haben. Ich bin euch aber trotzdem sehr dankbar dafür, dass ihr mir helfen wollt und schätze eure freiwillige Hilfe sehr. Ich bin euch deswegen auch nicht böse, ich will nur eine Tatsache darstellen

@Hyperion: Wie ifs usw funktionieren ist mir eigentlich recht klar
Das Problem lag wie jetzt festgestellt in einem Fehler im Code der ein von mir unerwünschtes Verhalten hervorgebracht hat. Das heißt, es _hätte_ so funktionieren sollen, wie ich es dargestellt habe, aber hat es dann eben doch nicht

Also das Problem ist jetzt gelöst, ich danke nochmal für die Antworten.
Tut mir leid, wenn ich manchmal ein wenig ... unverschämt? rüberkomme und mich nicht so recht belehren lasse :p Das nächste mal versuche ich euch einfach direkt zu glauben
Hier war's nur blöd, dass mein Code ohne das else für alle getesteten Beispiele korrekt funktioniert hat und ich deshalb angenommen hab, dass der Code auch korrekt ist und es am else liegen muss.

[numerix]

@Karl: Hör doch mal auf anderen vor zu werfen, sie würden sich nicht mit Deinem Quelltext im Detail beschäftigen wollen und gehe mal auf die direkten Antworten auf das Problem ein.

Ja, in der Tat, Karl, deine Art des Postens ist nicht erfreulich. Schon die ersten Antworten von Joghurt und mir haben das Problem klar benannt - und das dort benannte Problem ist immer noch da. Deine Lösung mit dem weggelassenen "else" zeigt nur, dass du das Problem noch gar nicht erfasst hast.

Hör doch mal auf mit dem "Trial & Error" und dem überheblichen Ton, als müsstest du etwas unglaublich Kompliziertes für Minderbegabte in kleinen Portionen und gut verdaulich anbieten. WIR haben das Problem ja verstanden, DU musst es noch verstehen.

Du hast ja mittlerweile einige konkrete Tipps bekommen ("binärer Baum" z.B.) und Beispielcode zum Testen hast du auch bekommen.

[Hyperion]

Aber mein Vorwurf, dass sich die Leute nicht richtig damit befasst haben, halte ich schon für gerechtfertigt, weil die meisten Antworten irgendwie am Thema vorbeigingen beziehungsweise das Problem falsch interpretiert haben.

Nein! Da der potenzielle Fehler immer noch besteht (s.u.) und die Antworten zum größten Teil genau auf das immer noch bestehende Problem hingewiesen haben

@Hyperion: Wie ifs usw funktionieren ist mir eigentlich recht klar
Das Problem lag wie jetzt festgestellt in einem Fehler im Code der ein von mir unerwünschtes Verhalten hervorgebracht hat. Das heißt, es _hätte_ so funktionieren sollen, wie ich es dargestellt habe, aber hat es dann eben doch nicht

Ok, aber das Problem besteht immer noch! Schleifen statisch zu verifizieren ist maschinell nicht möglich, da das Problem nur semi-entscheidbar ist. Aber weg von der Theorie. Es mag sein, dass Du in diesem Falle überblickst, dass die Bedingung des if in Zeile 9 auf jeden Fall einmal True ist und somit ein korrektes return stattfindet. Ich kann das so auf die Schnelle nicht und Insofern ist das Konstrukt immer noch unsicher vom Design her und bei größeren Problemen mit Nebeneffekten nicht mehr beherrschbar.
Insofern liegt die Lösung darin, für jeden Fall ein return einzubauen, damit es eben keine unvorhersehbaren Abbrüche geben kann. Natürlich kann ich solche Konstrukte im kleinen so sicher aufbauen, dass auf jeden Fall einmal eine Bedingung True ist und der einzige Ast einer If-Bedingung angesprungen wird, aber das zu beweisen ist alles andere als trivial und bei größeren Problemen nicht mehr praktikabel.

Ich hoffe Du erkennst spätestens nach diesem Posting, wo der (potenzielle) Fehler liegt

[Karl]

Das Problem ist doch schon längst behoben und ich hab's auch vorhin schon benannt
Ich hab mich in einem Punkt getäuscht gehabt, weil ich mein if-Zweig für korrekt gehalten habe, aber er war eben nicht korrekt und hat somit nicht das getan, was ich erwartet habe. Jetzt tut er's aber und jetzt bin ich mir auch sicher, dass in jedem Fall ein return zurückgegeben wird, da zu jedem [ in einem korrektem Brainfuckcode auch ein ] gehört, womit die Bedingung immer True ergibt.
So hatte ich mir das auch vorher gedacht, als der Code noch nicht funktioniert hatte und hab deshalb auch einfach mal ganz dreist behauptet: Der Code im if-Zweig gibt auf jeden Fall ein return zurück.
Kommt mal vor, dass man zu fixiert auf eine Sache ist und dann das eigentliche Problem gar nicht erkennt ... Das tut mir jetzt auch im Nachhinein ein wenig Leid weil das den großteil des Threades überflüssig macht :p Und auch mein genervtes Verhalten. Aber aus meiner Sicht die ich _hatte_, die etwas beschränkt war, weil ich nur auf dieses else fixiert war und angenommen hatte, mein if ist korrekt, sah das ganze eben ein wenig anders aus :p

Also tut mir leid, vielleicht liegt's an Schlafmangel (immer schön alles auf äußere Umstände schieben ) oder sonstigem ... Ich war wie oben gesagt einfach zu sehr auf das else fixiert und hab den Rest gar nicht mehr richtig überdacht.
Ich hab mir ja schon den Vorsatz gefasst euch beim nächsten Mal gleich zu glauben, aber ich änder ihn jetzt einfach mal ein wenig ab: Ich fasse mir den Vorsatz, beim nächsten Mal genauer über das nachzudenken, was ihr sagt und mich erst eine Weile mit etwas anderem zu beschäftigen, damit ich wieder freier denken kann und nicht so engstirnig bin.

Naja lassen wir's einfach auf sich beruhen, kleine Missverständnisse kommen halt vor.

[Hyperion]

Das Problem ist doch schon längst behoben und ich hab's auch vorhin schon benannt

Es ist eben nicht wirklich behoben und wo hast Du es benannt?

Jetzt tut er's aber und jetzt bin ich mir auch sicher, dass in jedem Fall ein return zurückgegeben wird, da zu jedem [ in einem korrektem Brainfuckcode auch ein ] gehört, womit die Bedingung immer True ergibt.

Und bei unkorrektem Brainf**ck? (Was uns der Lösung langsam näher führt)

Ich hab mir ja schon den Vorsatz gefasst euch beim nächsten Mal gleich zu glauben, aber ich änder ihn jetzt einfach mal ein wenig ab: Ich fasse mir den Vorsatz, beim nächsten Mal genauer über das nachzudenken, was ihr sagt und mich erst eine Weile mit etwas anderem zu beschäftigen, damit ich wieder freier denken kann und nicht so engstirnig bin.

hehe ... naja, tus lieber noch weiter hier - auch damit am Ende des Threads etwas brauchbares rauskommt, was Suchende weiterbringt! Also besser noch nicht hier abschalten, sondern noch einmal das eigene "Brain" anstregen, damit der Thread nicht so unbefreidigend offen bleibt

[Karl]

Es ist eben nicht wirklich behoben und wo hast Du es benannt?

In irgend einem vorherigem Post, glaub ich zumindest :p
Jedenfalls sieht's jetzt so aus und funktioniert (bisher) einwandfrei:

Code: Alles auswählen

    def loop_begin(self, i):
        """
        This is called when a loop is starting (or not if the field is 0)
        Brainfuck character: [
        """
        if self.array[self.pointer] == 0:
            x = 0
            while i <= (self.code):
                if self.code[i] == "[":
                    x += 1
                elif self.code[i] == "]":
                    x -= 1
                    if x <= 0:
                        return i
                i += 1
        else:
            self.tmp.append(i)
            return i

Die while-Schleife hab ich jetzt drin, weil ich die Funktion nochmal neugeschrieben hab und's diesmal einfach mit while probiert hab, weil ich dann eher von meiner alten Lösung wegkomme und das Problem freier angehen kann. Hat auch geklappt

Und bei unkorrektem Brainf**ck? (Was uns der Lösung langsam näher führt)

Bei unkorrektem Brainfuck? Tja, da hat derjenige, der kein Brainfuckcode schreiben kann eben pech gehabt
Oder er lässt vorher einfach eine check Syntax Methode drüberlaufen, was ich vielleicht auch noch einbaue.

hehe ... naja, tus lieber noch weiter hier - auch damit am Ende des Threads etwas brauchbares rauskommt, was Suchende weiterbringt! Also besser noch nicht hier abschalten, sondern noch einmal das eigene "Brain" anstregen, damit der Thread nicht so unbefreidigend offen bleibt

Naja ob das hier überhaupt einem Suchendem weiterhelfen kann? Das ist ein ziemlich spezielles Problem, das sich auf ein Logikproblem zurückführen lässt und deshalb wahrscheinlich auch niemandem weiterhilft
Wenn ihr wollt kann ich natürlich auch die ganze Klasse posten ...

Nochmal sorry, dass ich mich wie ein Idiot benommen hab, ist ja echt peinlich [/code]

[Hyperion]

Ok, ohne jetzt noch einmal auf die einzelnen Sachen einzugehen: Tust Du mir bitte bitte bitte einen Gefallen? Male einmal den Verzweigungsbaum deines Codes auf ein Stück Papier bitte! Und dann Schreib an die Blätter ein return hin, wenn eines im Code drin steht. Danach wirst Du die Lücken feststellen und erkennen, wo Dein Code noch Schwachstellen hat.

@all: Hab mich übrigens mit dem Binärbaum geirrt. Ist natürlich bei Sprachen, die "elif" als Konstrukt haben Unsinn. Aber zumindest muss mindestens ein "else"-Zweig da sein und am Ende eines jeden Zweiges muss ein return stehen.

[numerix]

Der Code ist immer noch nicht in Ordnung - dass etwas "funktioniert" ist kein gutes Argument, wenn man nicht weiß warum.

Warum nimmst du (Zeile 8ff) keine Zählschleife?
Möglicherweise braucht es hier überhaupt keine Schleife (aber dazu habe ich mich - und da hast du mal Recht mit einer deiner Äußerungen - zu wenig in Brainfuck bzw. deinen Code hineingedacht), und du kommst mit der count()-Methode von Zeichenketten aus.
Auf jeden Fall: Die Bedingung in der while-Schleife ist unsinnig, weil sie immer True ist: i ist eine Ganzzahl, self.code (warum in Klammern?) eine Zeichenkette. Die Schleife beendet sich nicht, weil die Bedingung irgendwann falsch ist, sondern wenn das abschließende "]" gefunden ist und die Funktion verlassen wird.

Und: Deine Bedingungen im Schleifenkörper sind immer noch so, dass je nach Inhalt von self.code das return gar nicht erreicht wird. Wg. der immer wahren Bedingung erhältst du bei dieser Version dann eine Endlosschleife.

[Hyperion]

So, ich hab mir mal ein wenig Mühe gemacht, um zu verdeutlichen, was an Unwägbarkeiten da drin sind im Moment. Die roten Kästen mit "return" zeigen die fehlenden Anweisungen. die roten "else" zeigen fehlende Äste.



Alles was rot ist, ist da quasi schlecht
(Ich hoffe ich hab im Graf jetzt keine Fehler gemacht)

[Karl]

Sorry, ich find's wirklich nett von euch, dass ihr mir helfen wollt.
Aber wenn ihr euch so viel Mühe macht, dann schaut euch den Code vielleicht nochmal besser an.

Der Code ist immer noch nicht in Ordnung - dass etwas "funktioniert" ist kein gutes Argument, wenn man nicht weiß warum.

Wo schreib ich, dass ich nicht weiß warum? Ich verstehe meinen Code zu 100%. Zugegebenermaßen, ich hab ihn, als er nicht funktionierte nicht verstanden, da ich nicht wusste, wieso er nicht funktioniert
Ich glaube, ihr versteht ihn nicht ganz, drum erläutere ich ihn mal gleich etwas genauer.

Warum nimmst du (Zeile 8ff) keine Zählschleife?
Möglicherweise braucht es hier überhaupt keine Schleife (aber dazu habe ich mich - und da hast du mal Recht mit einer deiner Äußerungen - zu wenig in Brainfuck bzw. deinen Code hineingedacht), und du kommst mit der count()-Methode von Zeichenketten aus.
Auf jeden Fall: Die Bedingung in der while-Schleife ist unsinnig, weil sie immer True ist: i ist eine Ganzzahl, self.code (warum in Klammern?) eine Zeichenkette. Die Schleife beendet sich nicht, weil die Bedingung irgendwann falsch ist, sondern wenn das abschließende "]" gefunden ist und die Funktion verlassen wird.

Du sagst mir, wie unsinnig mein Code ist, aber vorher sagst du "vielleicht hab ich mich zu wenig hineingedacht"?
Du magst recht damit haben, dass man das auch ohne while-Schleife beziehungsweise mit einer Zählschleife (meinst du damit for?) machen könnte, aber das ist mir erstmal relativ egal. Ich hab die while-Schleife genommen, weil ich vorher die for-Schleife hatte, ich dort aber noch den Bug drin hatte, den ich beseitigen wollte. Also habe ich die gesamte Funktion neugeschrieben und um mich nicht wieder im selben Fehler zu verlieren, die while-Schleife genommen, da ich da gezwungen bin, den Code nochmal ein (bisschen) anders zu schreiben. Ich hab mir gedacht, dass mir das eventuell hilft, um nicht wieder denselben Fehler zu machen.
Dass meine Bedingung in der Schleife unsinnig ist, mag auch sein. Ein True würde es auch tun, sofern die Brainfuck-Syntax korrekt ist. Aber ansonsten hätte ich eine Endlosschleife, das wollte ich auch erstmal vermeiden, bis ich eine Methode zum Überprüfen der Syntax habe.
Warum ich die Klammern um self.Code habe, weiß ich nicht mehr, aber ist ja auch eigentlich egal.

Und: Deine Bedingungen im Schleifenkörper sind immer noch so, dass je nach Inhalt von self.code das return gar nicht erreicht wird. Wg. der immer wahren Bedingung erhältst du bei dieser Version dann eine Endlosschleife.

Habe ich ja gerade oben erklärt Die Schleife ist auch nicht endlos, da die Bedingung nicht immer wahr ist. Ich erhöhe ja schließlich i am Ende?

@Hyperion:
Ich hab schon oft genug wiederholt, dass es keine anderen Möglichkeiten für die Funktion gibt, als ein return auszugeben. Okay ... Am Anfang hat's auch nicht gestimmt, aber das war, weil ich einen Bug im Code hatte, der etwas gemacht hat, was ich nicht wollte.
WIE soll denn bitte bei einem korrektem Brainfuck-Programm (davon gehen wir jetzt mal aus) KEIN Schleifenanfang zu einem Schleifenende gehören können?
Der Code macht nur folgendes: Falls das Feld == 0 ist, ignoriere die Schleife -> Suche dazu das passende Ende und springe dorthin, laufe anschließend einfach vom Ende aus weiter.
Da gibt es kein else oder sonst irgendwas.
Ich versteh auch nicht, warum zu jedem if ein return gehören soll. DAS ist doch gerade der Sinn: Wenn dies und das der Fall ist, tue dies und das und dreh noch ne Runde in der Schleife! Was soll da ein return? Das würde doch das Programm direkt beenden ohne dass die Schleife ein zweites Mal durchgelaufen ist. Außer ich habe einen else-Zweig, wenn der aber auch noch n return hat, dann überlebt die Schleife echt keine Runde.

Hier hab ich nochmal ein Beispiel dafür, dass der Code funktioniert:

Code: Alles auswählen

x = Brainfuck()
x.code = ",>++++>+<<[>-<-]>[>-<[-]]>[>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.[-]]"
x.run()
x.reset()
x.code = ",->,>+>>+<<<[>>>[<<<<+>>>>-]<<[-]<<[>>+<<-[>>>>+<<<<-]]>-]>[++++++.[-]]"
x.run()
x.reset()
x.code = """"->+>+++>>+>++>+>+++>>+>++>>>+>+>+>++>+>>>>
+++>+>>++>+>+++>>++>++>>+>>+>++>++>+>>>>+++
>+>>>>++>++>>>>+>>++>+>+++>>>++>>++++++>>+>>
++>+>>>>+++>>+++++>>+>+++>>>++>>++>>+>>++>+>
+++>>>++>>+++++++++++++>>+>>++>+>+++>+>+++>>>
++>>++++>>+>>++>+>>>>+++>>+++++>>>>++>>>>+>+>
++>>+++>+>>>>+++>+>>>>+++>+>>>>+++>>++>++>+>
+++>+>++>++>>>>>>++>+>+++>>>>>+++>>>++>+>+++>
+>+>++>>>>>>++>>>+>>>++>+>>>>+++>+>>>+>>++>+>
++++++++++++++++++>>>>+>+>>>+>>++>+>+++>>>++>
>++++++++>>+>>++>+>>>>+++>>++++++>>>+>++>>+++
>+>+>++>+>+++>>>>>+++>>>+>+>>++>+>+++>>>++>>+
+++++++>>+>>++>+>>>>+++>>++++>>+>+++>>>>>>++>
+>+++>>+>++>>>>+>+>++>+>>>>+++>>+++>>>+[[->>+
<<]<+]+++++[->+++++++++<]>.[+]>>[<<+++++++
[->+++++++++<]>-.------------------->-[-<.<+>>]<[+]<+>>>]
<<<[-[-[-[>>+<++++++[->+++++<]]>++++++++++++++<]>+++
<]++++++[->+++++++<]>+<<<-[->>>++<<<]>[->>.<<]<<]"""
x.run()

Ausgabe:

Code: Alles auswählen

>>> ================================ RESTART ================================
>>> 
4                  # Input zum 1.
T                  # Output zum 1.
23                # Input zum 2.
12                # Input zum 2.
                    # Output zum 2. unten drunter folgt die 3. Ausgabe
->+>+++>>+>++>+>+++>>+>++>>>+>+>+>++>+>>>>+++
>+>>++>+>+++>>++>++>>+>>+>++>++>+>>>>+++>+>>>
>++>++>>>>+>>++>+>+++>>>++>>++++++>>+>>++>+>>
>>+++>>+++++>>+>+++>>>++>>++>>+>>++>+>+++>>>+
+>>+++++++++++++>>+>>++>+>+++>+>+++>>>++>>+++
+>>+>>++>+>>>>+++>>+++++>>>>++>>>>+>+>++>>+++
>+>>>>+++>+>>>>+++>+>>>>+++>>++>++>+>+++>+>++
>++>>>>>>++>+>+++>>>>>+++>>>++>+>+++>+>+>++>>
>>>>++>>>+>>>++>+>>>>+++>+>>>+>>++>+>++++++++
++++++++++>>>>+>+>>>+>>++>+>+++>>>++>>+++++++
+>>+>>++>+>>>>+++>>++++++>>>+>++>>+++>+>+>++>
+>+++>>>>>+++>>>+>+>>++>+>+++>>>++>>++++++++>
>+>>++>+>>>>+++>>++++>>+>+++>>>>>>++>+>+++>>+
>++>>>>+>+>++>+>>>>+++>>+++>>>+[[->>+<<]<+]+++++
[->+++++++++<]>.[+]>>[<<+++++++[->+++++++++
<]>-.------------------->-[-<.<+>>]<[+]<+>>>]<<<[-[-[-[>>+
<++++++[->+++++<]]>++++++++++++++<]>+++<]++++++
[->+++++++<]>+<<<-[->>>++<<<]>[->>.<<]<<]
>>> 

Klar ist das kein Beweis.
Aber imho ist das Programm auch nicht so kompliziert, dass man das mit irgendwelchen besonderen Methoden beweisen müsste.

Edit: Bei der Ausgabe des 2. Brainfuck-Codes wird irgendein Zeichen ausgegeben, das hier nicht dargestellt werden kann, aber es kommt trotzdem eine, was ja auch schon die Leerzeile beweist.

Edit (Georg): BF-Code umbrochen.

[numerix]

Der Code ist immer noch nicht in Ordnung - dass etwas "funktioniert" ist kein gutes Argument, wenn man nicht weiß warum.

Wo schreib ich, dass ich nicht weiß warum? Ich verstehe meinen Code zu 100%.

Nein, du verstehst ihn eben nicht, und zwar immer noch nicht, wie die nachfolgenden Ausführungen zeigen!

Du sagst mir, wie unsinnig mein Code ist, aber vorher sagst du "vielleicht hab ich mich zu wenig hineingedacht"?

Du liest nicht richtig! Das bezog sich nur auf die Idee mit dem count(). Was die Schleife angeht, so braucht man sich da nicht in irgendetwas groß hinzudenken, weil die Bedingung einfach unsinnig ist. Das habe ich dir erklärt und in dem, was du nachfolgend noch äußerst, zeigst du deutlich, dass du es immer noch nicht verstanden hast.

Dass meine Bedingung in der Schleife unsinnig ist, mag auch sein. Ein True würde es auch tun, sofern die Brainfuck-Syntax korrekt ist. Aber ansonsten hätte ich eine Endlosschleife, das wollte ich auch erstmal vermeiden, bis ich eine Methode zum Überprüfen der Syntax habe.

Habe ich ja gerade oben erklärt Die Schleife ist auch nicht endlos, da die Bedingung nicht immer wahr ist. Ich erhöhe ja schließlich i am Ende?

Du HAST eine Endlosschleife mit deiner Bedingung. Das habe ich dir oben erklärt. Du hast es nicht begriffen. Ich für meinen Teil klinke mich jetzt aus ...

[Karl]

Der Code ist immer noch nicht in Ordnung - dass etwas "funktioniert" ist kein gutes Argument, wenn man nicht weiß warum.

Wo schreib ich, dass ich nicht weiß warum? Ich verstehe meinen Code zu 100%.

Nein, du verstehst ihn eben nicht, und zwar immer noch nicht, wie die nachfolgenden Ausführungen zeigen!

Du sagst mir, wie unsinnig mein Code ist, aber vorher sagst du "vielleicht hab ich mich zu wenig hineingedacht"?

Du liest nicht richtig! Das bezog sich nur auf die Idee mit dem count(). Was die Schleife angeht, so braucht man sich da nicht in irgendetwas groß hinzudenken, weil die Bedingung einfach unsinnig ist. Das habe ich dir erklärt und in dem, was du nachfolgend noch äußerst, zeigst du deutlich, dass du es immer noch nicht verstanden hast.

Dass meine Bedingung in der Schleife unsinnig ist, mag auch sein. Ein True würde es auch tun, sofern die Brainfuck-Syntax korrekt ist. Aber ansonsten hätte ich eine Endlosschleife, das wollte ich auch erstmal vermeiden, bis ich eine Methode zum Überprüfen der Syntax habe.

Habe ich ja gerade oben erklärt Die Schleife ist auch nicht endlos, da die Bedingung nicht immer wahr ist. Ich erhöhe ja schließlich i am Ende?

Du HAST eine Endlosschleife mit deiner Bedingung. Das habe ich dir oben erklärt. Du hast es nicht begriffen. Ich für meinen Teil klinke mich jetzt aus ...

Oh, sorry.
JETZT seh ich's auch.
Daher auch die Klammern.
Da stand glaub ich ursprünglich mal ein len().
So steht es auch in der ersten Fassung, die ich hier geschrieben habe:

Code: Alles auswählen

for i in xrange(len(self.code)): 

(auf der 1. Seite)
Ich hab das gerade total verpeilt, dass das nicht len(self.code) ist.
Okay, dann hast du eben doch recht.
Aber in fact ist das trotzdem egal, da die Schleife niemals endlos sein wird, außer der Brainfuck Code ist falsch.
Okay, ich geb zu, das lässt mich gerade etwas dumm dastehen, dass ich dir im Bezug auf die Bedingung widersprochen habe, aber ich hatte echt len(self.code) im Kopf.
Naja ...
Der Ton wird irgendwie wieder zu feindselig, finde ich ...
Das muss ja eigentlich nicht sein. Und nein, ich weise jetzt nicht dir die Schuld zu sondern auch mir.
Wir reden hier alle die ganze Zeit aneinander vorbei, habe ich das Gefühl.
Ich bin jedenfalls davon überzeugt, dass mein Code funktioniert, auch wenn er hier und da vielleicht den einen oder anderen "Schönheitsfehler" hat, wie eben diese Bedingung.
Wir können das Thema auch hier beenden wenn ihr wollt ...
Soll jetzt keine Aufforderung sein, ihr könnt natürlich auch gerne noch weiter schreiben.

[Hyperion]

Naja, auf jeden Fall solltest Du Deine Annahme "es kommt korrekter BF-Code" überdenken - ich persönlich freue mich über jeden Compiler / Interpreter, der mich darauf hinweist, dass ich Mist geschrieben habe. Endet so etwas schlimmsten Falles in einer Endlosschleife wirds noch heftiger, weil ich dann quasi gar keine Chance mehr habe etwas an Debug-Info aus dem Interpreter zu ziehen.

[Karl]

Naja, auf jeden Fall solltest Du Deine Annahme "es kommt korrekter BF-Code" überdenken - ich persönlich freue mich über jeden Compiler / Interpreter, der mich darauf hinweist, dass ich Mist geschrieben habe. Endet so etwas schlimmsten Falles in einer Endlosschleife wirds noch heftiger, weil ich dann quasi gar keine Chance mehr habe etwas an Debug-Info aus dem Interpreter zu ziehen.

Deshalb gibt's doch OOP
def checksyntax blablubb und fertig
Aber finde ich jetzt gut, dass mir mal jemand glaubt, was die Funktionsfähigkeit des Programms angeht :p