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
