TypeError (unorderable types: int() <= NoneType())

Question

This is my first time writing code in Python and could use some help. I am using Python 34 and simply cannot understand what is going on.

def roll(v):
    x = input()
    return (x + v)

def startGame():
    v = 0
    while 0 <= v: # error points to this line
        v = roll(v)  

print("Thanks for playing")

I declare v to be an integer with a value of 0. But when I try to compare it to another integer, it gives me the error message unorderable types: int() <= NoneType() I could use some guidance.. Thanks

Solution

I placed the code you posted into a python 3 shell but it fails somewhere else. Your x = input() produces a string, and python doesn't know how to convert strings to numbers unless you explicitly tell it how.

so:

def roll(v)
    # Lets try to parse userinput
    try:
        x = int(input())
    # sometimes users don't get it that "a" is no int
    except ValueError:
        x = 0
    return (x+v)

or

def roll(v)
    hasProducedNumber = False
    x = 0
    # we keep nagging for a number till no valueerror arises
    while not hasProducedNumber:
        try:
            x = int(input())
            hasProducedNumber = True
        except ValueError:
            print("Please provide a number")

    return (x + v)

If this is not a solution to your problem I need relevant code that actually produces your error :)

Comments

[Ashwini Chaudhary]

A flag variable is not required here, better use while True with either break or return (x+v).

[windwarrior]

In my opinion breaks are just as ugly as gotos. Making it verbose like this was completely on purpose.

[user3585138]

Thanks guys windwarrior your solution helped. I had to cast my input as an int

[user3585138]

Thanks M. Adel. This was the solution as well

[windwarrior]

Be sure to also look at the try block around it, it is good practice never to trust input from users and always check that your user fills in ints when he should. This is for example what happened with HeartBleed, the guy responsible for the bug assumed that some data from a user was always correct, but didn't validate it.