There is an issue with the program when the user correctly guesses the number. The program should end when the break statement executes in the while loop found in main(), but instead it times out.
import random
def main():
level = get_level()
number = generate_random_number(level)
while True:
guess = get_guess()
if check_guess(number, guess) == False:
continue
else:
break
def get_level():
while True:
level = input("Level: ")
try:
int(level)
except ValueError:
continue
if int(level) <= 0:
continue
else:
return int(level)
def generate_random_number(level):
number = random.randint(1, level)
return number
def get_guess():
while True:
guess = input("Guess: ")
try:
int(guess)
except ValueError:
continue
if int(guess) <= 0:
continue
else:
return int(guess)
def check_guess(number, guess):
if guess > number:
print("Too large!")
return False
if guess < number:
print("Too small!")
return False
if guess == number:
print("Just right!")
return True
main()
Maybe try using the idiom:
if __name__=="__main__": main()Instead of calling main since the way it’s written now it will always run your code as soon as your module is imported. If the system expects a function named main and calls it, remove your call to main at the end.
My name’s not Shirley nor May. Meaning, the process guard has a name and it’s not idiom.
That passed the test! Thank you!
What happens if you replace the last break in main() with exit()?
Nothing really sticks out. It could also be something about how the automated checker provides input (maybe it expects to not press enter or something and it’s stuck at input()… hard to say)
I personally would install ruff and run “ruff check yourfile.py” and then later “ruff check --select=ALL yourfile.py” and read about everything it complains about.
Google the error codes and find the description and discussion of each and why it is complaining, sometimes they’re not a big deal, sometimes they are aha moments. Ruff has a page discussing each warning and error
Actually I think it may be your get_entry() code. The try traps all non-numbers and restarts the loop for new entry. So like typing “exit” or an empty string or anything that’s not convertible to a number is being trapped by the raise and sent back for reentry. And anything that is a number can’t hit the break. Just my guess.
I second this! Add a print(“invalid number, try again”) or something to verify and avoid silent failures.
probably indentation issue, make sure to have 4 spaces on each indent level
Was using tabs but I went through it to make sure and seemed to be ok.
Don’t think that’s a literal suggestion.
More like a subtle way to portray his frustrations having to look through code example with three while(True) loops?
If you set up ruff you should get autoformatting (and you can enable various lints).
or not introducing another programming language into your toolchain by sticking with black, flake8, isort, and pre-commit
At the user level they’re just tools, not programming languages. Python users are generally moving to
ruff(anduv) because of ergonomics: It works well and really fast which makes for a smooth experience in-editor. Plus using fewer tools to achieve a similar result is generally desirable.And for a complete newbie like someone taking a course, I think there’s no “sticking with” to speak of. Might as well just skip over the tools people are migrating away from and start with the tool people are migrating to.
Can see both the pros and cons.
Looking at existing packages we actually use, it’s a mixed bag. When helping other projects, have not run into the situation where had to use ruff. Do see some uptake. It’s not like a light switch there will be multiple commits before the ruff configuration is right. But i’m sure the configuration is simplier than the rocket science that is: black, flake8, isort, pre-compile, tox configurations.
Overtime expect Rust to bleed into the Python toolchain. The excuse to resist this is there is not enough time in the day for Python let alone other coding languages especially low level languages like Rust and integration of those low level languages and Python. Sounds like a ton of work unless intending to write Rust modules to optimize speed of complex Python apps.
1 2 3 4
1 2 3 4
1 2 3 4 5
1 2 3 4 1 2 3 4 1 2 3
Opps!
deleted by creator
deleted by creator
There’s no
nullin Python. There’sNone, but like the other comment points out, just usingreturnis fine.deleted by creator
… or just trying to identify who will out themselves as Captain Obvious.
went off without a hitch
That was a, sorry not sorry
Just “return” should work too. Does returning null has a perk?
Having multiple return statements in one function is a mistake. There shall ever be only one, unless that’s unworkable due to tons of checks.
Cringe! That’s like watching bad movies for the joy of really really bad movie moments. Watch
Dead Snow IITHENDead Snow I. Both are cringe. Former good cringe later really really bad cringe. Do not watch in chronological order.A return statement within a while loop. Is that good or bad cringe?
Code with multiple return in one function/method screams noob. Especially when its completely unnecessary and avoidable. The return statement in random locations is a close 2nd.
The return statement in a while loop is just eyebrow raising. Like trying to write cringe, but forgot the threadpool, with GIL enabled, within the while on crack cocaine loop.
or avoid the break all together; coverage hates break and continue.
is_found = False while(on crack cocaine): if not is_found: do something is_found = True else: # pragma: no cover pass