[Tutor] [Fwd: Re: trouble with "if"]

[Luke Paireepinart]

Adam Urbas wrote:
> Sorry about all that trouble for you Alan, after I posted that, I
> reformatted my code a bit and updated it to do the defining and then
> the calling, like you said.  The only problem I had, and I was
> probably doing something wrong, was that I would do:
>
> choice()
> if choice in["1","circle"]:
>     circle()
>
> and it wouldn't actually go to circle().  So I had to put the if
> statement somewhere else, can't remember where it was right now and
> don't have time to find out, because I really need to be getting off
> of here.
>
> Thanks for the advice, and if you could, would you mind explaining the
> global variable thing a little more, because I kept getting an error
> message that was saying something to the effect that the global
> variable was not defined.
>
> Thanks,
>
> Au

Adam -
Please realize that I mean this in the nicest way possible, and that 
everyone in this mailing list wishes to see you succeed in all your 
programming endeavors.
Having prefaced with that disclaimer, I must implore that you take 
further steps in your study of basic programming concepts.
While we would love to (and the name of the mailing list seems to imply 
that we do) take every individual from the level of beginner through to a
bona-fide pythonista with personal instruction, there simply isn't 
enough time to do that.
That applies to you as well; while every question you ask seems to get 
you a reply that fixes your problem,
you'll find that you'll continue to run into problems indefinitely.
And if every problem you ever face has a 5-hour delay before you get a 
solution, you'll find your progress to be agonizingly slow.

I would suggest that you consider what you can accomplish with 
programming, and whether you would like to continue to delve into it.
If you decide to, you'll need to take the time to read through more 
tutorials.
In addition to that, you should do any example programs they give you!
(Ideally) the examples in a tutorial will immediately apply the 
knowledge you just gained from reading that section of the tutorial,
and

I know it seems counter-intuitive to go abandon work on a program that 
is doing something useful to you to work on a program that
has no bearing on what you're trying to accomplish (as you would in a 
tutorial), but I truly believe it would be for the better in the long run.

An example of this:

These are the basics of the syntax of a function:
1. a function takes in n arguments (where n is any number, even 0) where 
any of them could have default values.
2. a function is defined by the "def" keyword, followed by the function 
name, then a parenthetical list of all arguments the function takes in 
(or empty parenthesis
if the function takes no arguments), where all of the arguments are 
separated by commas, followed by a colon.
3. the next line of code is indented at least 1 space or 1 tab, and all 
subsequent lines that are indented at the same level or further will be 
part of the function, until there is a line with less indentation.  If 
any lines are indented further than the first line, they must be part of 
another code block ( a function, a loop, a statement, a class, etc.) for 
their indentation to be valid.

you can learn these things by trial and error, but a tutorial will 
explain why all of these are necessary.
If you understand why they are necessary, it will be easier to remember 
them.
for part 1, a function taking arguments, you must understand the purpose 
of a function.

Suppose we had code that calculated the sum of an arithmetic sequence 
(for example 1,2,3,4,5,6,7,8,9,10)
There are many ways to solve this, but the easiest way is to use a 
formula for the sum of an arithmetic sequence.
one such formula is   total sum = half the number of terms in the 
sequence multiplied by the addition of the first and last terms.
In this particular example, this would be 5 * (1 + 10).  The 5 comes 
from the fact that there are 10 terms.
Now when programming this, assuming we know the values of the sequence, 
we could just do
sum = 5 * (1+10)

or even precompute this
sum= 55

but what do we do if we don't know the values in the sequence beforehand?
Say the user inputs the values for the list, and we end up with this list
seq = [1,2,3,4,5,6,7,8,9,10]

We want to know what the sum of it is without having to know what the 
list itself is.
We can use the formula to keep this process abstract, so that the 
solution will work with any sequence of length 10:
sum = ( 10 / 2.0 ) * (seq[0] + seq[9])

Now why all the parenthesis?
That's because of the order of operations.
This is the first part where you'd need advance knowledge to solve the 
problem.
The solution seems trivial looking at it, but if you didn't know that 
the multiplication would take
effect before the addition without the right set of parenthesis, you 
might not even notice, until you needed to use this
value for something and found it to be incorrect.
The order of operations is one thing that you will learn in a tutorial.
Another is that computers index lists starting from 0, not from 1, so 
seq[1] + seq[10] would create an error.

Now what if we want to generalize this further, so that it will work 
with a sequence of any length?
sum = ( len(seq) / 2.0) * (seq[0] + seq[-1])
More things we knew from before: len( some_list) will give you the 
length of the list,  some_list[-1] will give you the last element of the 
list.

Okay, that's handy, but do we really want to copy and paste this after 
every list that we need the sum of?
and if the list is named something else, like 'foobar', we'd have to go 
change all the 'seq's to 'foobar's.
There must be a better way...
and there is!

This brings us to functions.
What we want is a device that will accept any sequence we throw at it 
and give us back whatever the sum is.
It doesn't need to be concerned with how we arrived with the sequence, 
or what we're going to use the sum,
or even where we're going to store the sum.
Think of it like a meat grinder.  We put meat in, and out comes little 
tubes of processed meat at the other end.
It performs a simple task on input which results in output.

What we want our device to input is a sequence, and what we want it to 
output is a sum.
The manner in which we define functions, which was enumerated above, 
starts with a 'def',
which tells python "hey, we're about to define a function!"  followed by 
the function name,
in this case addSequence (we aren't calling it 'sum' because there is 
already a function called 'sum',
and if we call our function 'sum' also, the other 'sum' will no longer 
be accessible) followed by a list of the arguments
(in this case just the sequence name) and finally a colon.
this looks like the following:
def addSequence(seq):

now we are inside the function, so we want to indent our code a bit...
    sum = ( len(seq) / 2.0) * (seq[0] + seq[-1])

and now that we have this value, we want to give it back to whoever 
called the function.
we can do this by using the 'return' keyword.
    return sum

note that that line is indented just as far as the previous line is, 
because they are both part of the same function (addSequence.)

now that we have this function, any time we need the sum of a sequence,
say
foo = [1,2,3,4,5]
bar = [6,7,8,9,10]
foobar = [1,2,3,4,5,6,7,8,9,10]

we can simply pass these values to our function, and store the sum in a 
variable.
foo_sum = addSequence(foo)
bar_sum = addSequence(bar)
foobar_sum = addSequence(foobar)

note that all of these calls to addSequence have a different name.
Specifically, none of them are named 'seq'.
This is because inside of our function definition above, anytime we say 
'seq' we are really referring to the value that was passed
into our function.  'seq' is just another name for 'foo', or for 'bar', 
or for whatever other sequence we happen to have called addSequence with.

The reason I presented this to you was to make it evident that even a 
simple problem, like summing an arithmetic sequence, can be solved in
many ways, and that by learning important things like functions and 
if-statements and loops before you begin writing your own programs,
you will be able to see many of the possible ways to use code to solve a 
particular program, and hopefully which method would be best in your 
situation.
Now I believe that writing your own programs to do what you want is 
definitely a great way to learn,
but it is paramount that you understand the basics before you move onto 
that stage,
and while it is possible to puzzle them out yourself, I strongly suggest 
you don't try to.

I hope this helped you to see the logical process by which we solve 
problems,
and why it's necessary to spend the up-front time to get all of this 
general knowledge into your head about the syntax of the programming 
language, as well as problem-solving patterns that are commonly used.
So while you may certainly continue to ask questions here, and the nice 
folks will continue to answer your questions,
what we all are really hoping is that some day you won't have to.
and I believe the best way for you to get to this point is to work 
through various tutorials (obligatory recommendation of Alan's tutorial 
goes here)
and ask us questions if you get stuck with those.
But really, experimenting within the constraints of the tutorial, to 
begin, will help you to see common problems and things
that frustrate people, and the manner in which to work around them.  
Also, if you're working through a tutorial,
as opposed to learning it by persistence, we will know at what point you 
are, and what you've previously learned,
which will greatly enable us to give you better advice on finding a 
solution than we are now able to.

I apologize for what appears to have turned into a rant, and I hope you 
can find some value in it, Adam.
-Luke