this post was submitted on 01 May 2025
24 points (100.0% liked)

Python

7069 readers
17 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 2 years ago
MODERATORS
 

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()
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

What duh eh does standard idiom mean?

In computer programming, a programming idiom, code idiom or simply idiom is a code fragment having a semantic role[1] which recurs frequently across software projects. It often expresses a special feature of a recurring construct in one or more programming languages, frameworks or libraries. This definition is rooted in the linguistic definition of "idiom".

https://en.wikipedia.org/wiki/Programming_idiom

So this term is vague and abstract. Really not a specific term or grouping of related things.

The actual terminology

That standard idiom is called, process guard or simply guard. Learn about this term when doing anything involving multiprocessing.

The if __name__ == "__main__": guard is important when working with multiprocessing in Python. This prevents the creation of duplicate processes when the module is imported.

https://labex.io/tutorials/python-how-to-pass-arguments-in-python-multiprocessing-430780

So it's totally not for what its being described as. Or that's an oversimplification with a loss of vital details of it's actual purpose.

It could be worse

When don't know the name for something, Call it stuff!. Ya know, when really suack at naming things, be unrepentant! Stuff is as bad of a term i could come up with. Means didn't know how to describe it to accurately relate what it is or does, without being vulgar; out of fear the typos author left an Easter egg which is best left lie.

Used this term once, for a SQLAlchemy non-request based router implementation, the Session (term already taken) i call SessionStuff. Doesn't that just scream competence and authoritative implementation?

What do you do for a job? Urrrh ... stuff?

Regretted immediately and still do. Cuz session seems to have three different contexts / meanings.

Oh shit! Used the term, stuff. That's code prefer to not even read. That's a thing of nightmares that haunts our collective waking moments.

[–] [email protected] 2 points 2 days ago (1 children)

You sound angry. Take a breath and grow up.

[–] [email protected] 1 points 1 day ago* (last edited 1 day ago)

That's what code reviews feel like. Don't take it personally. Sugar coating advice is a skill when working in groups.

Evidently i'm not, so got that code review advice the less than tender way.

Everyone one else was not critical and let these avoidable coding mistakes slide. That doesn't fill me with confidence. Should strive to spend more time testing code bases to eventually be able to see and avoid these kinda coding mistakes.

If anyone feels the need to set me on the road to becoming a lovable teddy bear full of positivity and group comradery, jawboning alone is too kind, feel free to put me in the hot chair by reviewing packages have written and published.

Have ordered the packages according to the value you'd gain by learning them.

logging-strict

wreck

pytest-logging-strict

sphinx-external-toc-strict

drain-swamp and drain-swamp-action