If statement syntax + more


I’m confused as to why when you handle things in an if statement sometimes it has to be like this:

if(len(date) > 10):
Also the lack of space between if and (len has me confused too.

instead of if len(date) > 10:


try_again = raw_input("Try Again? Y for Yes, N for No: ")
try_again = try_again.upper()

why do you need to set try_again = try_again.upper() ?
Why can’t you just do try_again.upper() ?


Whitespace is a style concern, and not really a coding concern. Generally, it is a good idea to leave whitespace around operators, but at the start or end of an argument or parameter list, not.

if ( len(date) > 10 ):

is just fine, however not what we are used to seeing. It definitely is more readable. The space around the operator is to my mind the most important, and the rest, well…

Python does not actually have () in the syntax for if statements…

if len(date) > 10:

is the typical way of writing the line. Parens are ignored.

len() is a built in function that returns the character count of strings, and item count of lists, sets, tuples and dictionaries. It does not work on numbers or booleans.

>>> len(True)
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
TypeError: object of type 'bool' has no len()
>>> len(42)
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
TypeError: object of type 'int' has no len()
>>> len(3.14)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
TypeError: object of type 'float' has no len()

Nothing happens to try_again. The method is not in-place and needs a receiver to hold the returned value. The same variable name makes the change take place on the old value.

In technical terms, the method copies the context object and mutates it, then passes it back to the assignment.

a = "String Song"
a = a.upper()
b = a.lower()
print (a, b)    # STRING SONG string song


Combining those two lines gives you:
try_again = raw_input("Try Again? Y for Yes, N for No: ").upper()
You can do that; it makes it simpler. :slight_smile:


So whenever is see something like this and I assume the parentheses are just added for readability? Also, thank you for clarifying everything else :smiley:

if (red < 0 or red > 255):

it is the same as:

if red < 0 or red > 255:

try_again = raw_input("Try Again? Y for Yes, N for No: ").upper()

Basically means the input for the user is prompted and then the input is converted into uppercase, then stored into




Yeah, basically. raw_input("Try Again? Y for Yes, N for No: ") just records what you type in the console as a string, so using .upper() to convert it is similar to using .upper() on just a regular old string:

my_string = 'a random word'.upper() 
# ^^^ 'a random word' is a string-- the same value raw_input provides
print my_string # prints 'A RANDOM WORD'


Style guides offer the best advice for readability. My opinion is that the less window dressing we use, the easier the real code is to read, so the jury would still be out on that point.

Anything we add to this leans to the subjective. The above is objective.

Parens are sometimes needed when grouping is involved.

return f(n) / f(r) * f(n-r)

is vastly different from,

return f(n) / (f(r) * f(n-r))

Essentially, yes, that is the idea. In any case there has to be an assignment.

Technically speaking, the value is not stored IN the variable, but at an address in memory that the variable has a reference to.


The user input is the context object upon which the upper method is called. It never gets assigned, only the mutation of it does. But, without the assignment, poof! Never happened.

I’m of the opinion that user input should always get cached and a reference maintained until it is absolutely no longer needed.

user_raw = raw_input()
user = user_raw.upper()

If we are disambiguating a phrase with a linter and need to restore all the orginal punctuation and letter case, having the original is essential. Just saying. That’s one possible use. Surely we can justify it in other ways, as well.

It also gives us time to evaluate the raw input before running any methods on it. Why go on with an invalid input?