This is how python is supposed to work. I'm sure not what languages you have used ... it seems that you are expecting some sort rule based system like make, or prolog.
Grab a cup of joe, pull up a chair and let me help you out here. Python is an imperative language, you can envision the presence of a "program counter" that starts at the first line. If my program says: print 1 print 2 print 3 Python will print: 1 2 3 because the program counter (forgive me for calling it that) was at the "print 1" ... its sequential top to bottom. Now the while command means: while <whatever expression is here is true:> Spin around madly and execute all of the commands in this indented section and if you got here then it means that your expression wasn't true anymore . So, what happened is you: >>> x = 1 Obviously the variable x has the value 1. >>> while x == 1: >>> ... Okay, we enter the while loop ... print 'Hello', You tried telling it 2. Well, it didn't jump to 2 because that was a rule, it jumped because after your input x=2, not 1. The while state's expression failed and the control, or your program counter, jumped outside of your first block. When it wandered to your second loop it discoverd "x==2" is a true statement by luck. Had you entered 3, you would never, ever have been told hello again ... if the intiial condition of a while statement is false, then you never enter the while. Now, after leaving your second loop, it isn't going back. The program counter is behind that all, and will never ever go back to the top unless you tell it. And how do you tell it? while True: Things I want done over and over again forever or until I stumble across a break statement I'm going to assume that you are not suffering from the effects of chronic makefile over exposure and send you here http://docs.python.org/tut/tut.html Jordan Greenberg seems to have written what you were trying to do ... but unless you give us a script of what you wanted to see in response to what you entered, then we can't know. Jordan Greenberg's example is right, but I would have written it differently. I would have said: x=1 while x !=3: if x==1: print "Hello" elif x==2: print "Hello again" x = input( 'what is x now?: ') Just a nit pick that is unrelated. One of the principals of clean programming (look up refactoring) is to write things once. When you have two program paths that merge, common code at the end of each should be moved past the merge so its only written once. In your example, or John's, what if you decided that you wanted your input statement to ask the question in Italian? input( "Che cosa ora e' x?: ") Its better to change in one place than to. Lastly, I have a small rant about the input function. Don't use input. Please please promise me the following. Never, never, use the input command in any user facing software. I used to be tempted, well, not since I was 13, especially as BASIC was my first language (TI-994/A home computer) to write programs like this: print "Your first parameter" a = input ... print "Your sencond parameter" b = input If you are at the command line, use getopts, curses, use the plain python shell and call the function myfunc( a=, b= ). Don't write a program that uses input to collect user input on the command line and hand it to somebody at work to use. Especially if the program gives them the appearnce of being in a protected environment. If you were to enter this (please don't, its destructive, it will erase your files and kill your pets): map( __import__('os').unlink, __import__('glob').glob('*') ) instead of 1 or 2, all of your files in your current directory would be deleted instead of printing "hello again." And your dog will run away. Anything that connected the ability to evaluate code is dangerous. This is why we give user mice instead of soldering irons. Please. Don't use input. Think about the children. -- http://mail.python.org/mailman/listinfo/python-list