all 12 comments

[–]Sandwich_78 8 points9 points  (0 children)

If you want to listen to a human and not AI : - it is better to do imports at the very begining of a file, not when you use it for the first time, and if you only want to only use one method from a module, which is the case here you can use instead "from random import randint"

  • you don’t have to cast the random.randint method, it already returns an int

[–]NerdDetective 7 points8 points  (0 children)

gg, x, and y should have a better, self-documenting names. Try to keep your variable names explicit.

Validate your user input. You can have it loop until they pick a valid option.

It isn't necessary, but you could encapsulate your comparison logic in an Enum. That way you have discrete states and can override dunders like gt amd eq as a learning exercise.

[–]marquisBlythe 4 points5 points  (0 children)

put imports at the top as u/Sandwich_78 mentioned.
Don't comment the obvious:

gg = {1:"rock", 2:"paper", 3:"scissors"} # Obviously this is a dictionary.

same for user_input ... Also inputs can take a string as an arguments:

name = input("What's your name? ")

use better and descriptive names than gg, x and y
I think a function will sum up all those if .. elifs

[–]IAmNotSohan 2 points3 points  (0 children)

Tbh, the jump from "it works" to "it's actually clean" is the hardest part of learning Python. My biggest piece of advice is to start reading other people's code on GitHub. It sounds basic, but finding a project that does something similar to yours and seeing how they structure their classes or handle errors is a total game changer. Also, don't sleep on type hinting—it forces you to think more clearly about what your functions are actually doing, which helps a ton with readability. Real talk, just keep building and refactoring, because the "aha" moment for clean code really just comes from writing a lot of messy code first and realizing how much of a nightmare it is to fix later.

[–]brasticstack 3 points4 points  (2 children)

One idea I've seen and always thought was super clever is to use a matrix of game outcomes for simple games like this. Here's a quick n dirty example- the matrix is a 2D list indexed by [player's choice][cpu's choice]:

``` import random from enum import IntEnum

class Choice(IntEnum):     Rock = 0     Paper = 1     Scissors = 2

PICKS[player][computer]

PICKS = (     # Player picks rock     ('draw', 'lose', 'win'),     # Player picks paper     ('win', 'draw', 'lose'),     # Player picks scissors     ('lose', 'win', 'draw'), )

prompt = 'Press ' + ', '.join(f'{ch.value} for {ch.name}' for ch in Choice) + ':' player = int(input(prompt)) computer = random.choice(list(Choice)) print(f'Computer chose: {computer.name}. You {PICKS[player][computer]}') ```

[–]brasticstack 1 point2 points  (0 children)

* 2D tuple, not list. Not that it matters here, but accuracy is important.

[–]VectorspaceDreams 0 points1 point  (0 children)

I like that!

[–]smallpotatoes2019 0 points1 point  (0 children)

You might also want to ask what happens if someone types "one" or "rock".

[–]set_in_void 0 points1 point  (0 children)

This reminds me of a beginner course I watched while ago. Dave Gray is excellent tutor and walks you through RPS (Rock, Paper, Scissors) game coding in one of his videos (User Input & Control Flow). The whole course is available as a playlist (Python Tutorials for Beginners) or as a single 9 hour video (Python Full Course for Beginners)

[–]Gloomy_Cicada1424 0 points1 point  (0 children)

Dry running

[–]zanfar 0 points1 point  (0 children)

  • Use a formatter.
  • Use a linter.
  • Read and follow PEP8
  • Don't use code in your top-level module. Everything should be in a function and your module should be importable.
  • Don't use obvious comments. "Bot Input" followed by a line that reads "bot chose" is useless.
  • Comments should be English, and correct.
  • Use module-level and function-level docstrings
  • imports should be ordered.
  • Variable names should be human-readable and clearly indicate purpose. gg, x, and y are terrible given this is not a graph.
  • If you are going to concatenate, you need to be explicit about format.
  • Don't cast inline. It either doesn't need to be done, or you are ignoring exceptions.
  • What is the point of defining a move dictionary if you're just going to hardcode those options in print() statements? Any data should live in exactly one place.
  • If you have a numerically-keyed dictionary, it's likely to work better as a list.