Simple Rock, Paper, Scissors in Python I have looked at many different approaches to this game online, but as someone who isn't very experienced with Python, I may not be aware of what others are doing right.

import random

def RPS():
    print("You are playing Rock Paper Scisscors")
    comp_possible  = 1,2,3
    score = [0,0]
    flag = 0
    while True:
        print("Enter your choice:")
        while True:
            choice = input('-&gt;')
            if choice == 'r' or choice == 'R' or choice == 'Rock' or choice == 'rock' or choice == '1':
                choice_identifier  = 1
                break
            elif choice == 'S' or choice == 's' or choice == 'Scissors' or choice == 'sciccors' or choice == '2':
                choice_identifier =  2
                break
            elif choice == 'P' or choice == 'p' or choice == 'Paper' or choice == 'paper' or choice == '3':
                choice_identifier =  3
                break
            else:
                print('That\'s not an option in this game :)')
                print('Try again:')
                continue

        comp_choice = random.choice(comp_possible)
        if choice_identifier == comp_choice:
            print('It\'s a draw!')
            score[0] = score[0] + 1
            score[1] = score[1] + 1
        elif (choice_identifier == 1 and comp_choice == 2) or (choice_identifier == 2 and comp_choice == 3) or (choice_identifier == 3 and comp_choice == 1):
            print('You win!')
            score[0] = score[0] + 1
        else:
            print('You lose...')
            score[1] = score[1] + 1


        while True:
            answer = input('Play another round?')
            if answer == 'y' or answer == 'Y' or answer == 'yes' or answer == 'Yes' or answer == 'ye' or answer == 'Ye' or answer == 'sure' or answer == 'Sure':
                print(' Current score: You - ',score[0],' Computer - ',  score[1])
                flag = 0
                break
            elif answer == 'n' or answer == 'N' or answer == 'no' or answer == 'No' or answer == 'nah' or answer == 'Nah':
                print('Thanks for playing! Final score: You - ',score[0],' Computer - ',  score[1])
                flag = 1
                break
            else:
                print('Yay or nay...')
                continue
        if flag == 0:
            continue
        else:
            break

RPS()


What things in my code are, for example, horribly inefficient or are bad practices?
The game &quot;Rock Paper Scissors&quot; can be specified in terms of states.
Specification
The game is played by two players, playerA and playerB. Each player selects from among a set of three options {null, rock, paper, scissors}. null is used to represent the state before a player has chosen. Using an ordered pair (playerA_choice, playerB_choice) creates the possible game states:
 (null,    rock)
 (null,    paper)
 (null,    scissors)
 (rock,    null)
 (rock,    rock)
 (rock,    paper)
 (rock,    scissors)
 (paper,   null)
 (paper,   rock)
 (paper,   paper)
 (paper,   scissors)
 (scissors, null)
 (scissors, rock)
 (scissors, paper)
 (scissors, scissors)

There are three final states and three transition functions to them:
playerA_wins = (rock, scissors) | (paper, rock) | (scissors, paper)
playerB_wins = (rock, paper) | (paper, scissors) | (scissors, rock)
draw = (rock, rock) | (paper, paper) | (scissors, scissors)

The start state is:
 (null, null)

The states:
 (null,    rock)
 (null,    paper)
 (null,    scissors)
 (rock,    null)
 (paper,   null)
 (scissors, null)

are blocking and require further input from one of the players.
Implementing The Specification
This is a sketch of the game:
# Some Useful Names
null = &quot;null&quot;
rock = &quot;rock&quot;
paper = &quot;paper&quot;
scissors = &quot;scissors&quot;

# A Thesaurus (implemented as a dictionary)
synonyms = {&quot;rock&quot;: rock,
            &quot;paper&quot;: paper,
            &quot;scissors&quot;: scissors,
            &quot;stone&quot;: rock,
            &quot;vellum&quot;: paper,
            &quot;shears&quot;: scissors}

# Final States
game_is_draw = &quot;Game is a Draw&quot;

playerA_wins = &quot;Player A Wins&quot;

playerB_wins =  &quot;Player B Wins&quot;

# Initial State
both_players_must_choose = &quot;Both Players Must Choose&quot;

# Transition States
playerA_must_choose = &quot;Player A Must Choose&quot;

playerB_must_choose = &quot;Player B Must Choose&quot;

# Transition Table (implemented as a dictionary)
transitions = {(null,    null): both_players_must_choose,
               (null,    rock): playerA_must_choose,
               (null,    paper): playerA_must_choose,
               (null,    scissors): playerA_must_choose,
               (rock,    null): playerB_must_choose,
               (rock,    rock): game_is_draw,
               (rock,    paper): playerB_wins,
               (rock,    scissors): playerA_wins,
               (paper,   null): playerB_must_choose,
               (paper,   rock): playerA_wins,
               (paper,   paper): game_is_draw,
               (paper,   scissors): playerB_wins,
               (scissors, null): playerB_must_choose,
               (scissors, rock): playerB_wins,
               (scissors, paper): playerA_wins,
               (scissors, scissors): game_is_draw}



# Simulate Initialization
playerA_choice = null
playerB_choice = null

# Simulate Players Choosing
playerA_choice = synonyms[&quot;stone&quot;]
playerB_choice = synonyms[&quot;shears&quot;]

# Main Logic
state = (playerA_choice, playerB_choice)
print(outcomes[state])

Details to handle input output should be at a higher layer of abstraction. It shouldn't matter to the game engine if the game is between a human and a computer, two humans, or two computers. It shouldn't matter if it is being played using a laptop or over the internet.
Data Structures
A good rule of thumb is to replace complex logic with a data structure, and
if choice == 'r' or choice == 'R' or choice == 'Rock' or choice == 'rock' or choice == '1':

is the sort of code that is hard to understand and hard to maintain. Perhaps to the point where it is better to forgo the user friendly approach?  Nay! A thesaurus is a good place to look for synonyms. Although, Python lacks Thesauri, a dictionary will probably do. Now the game can be sold at Ye Local Renaissance Faire as Stone, Vellum, Shears!
Indeed, a dictionary is a good way to map each possible game state to the next state. The code does in lieu of directly implementing the logic the specification uses to describe the final states.
The reason is maintainability. The mobile version of the game will offer an upgrade to Rock, Paper, Scissors, Spock, Lizard currently in development. Once we get around to updating the dictionaries synonyms and transitions the game will be done, profits will role in, and we will never have to work again unless sleeping on a stack of money counts as work.
But Really, Why All the Ceremony?
One of the real values that comes from using dictionaries is that a dictionary can be used to dispatch functions.
# Abbreviated Rock Paper Scissors

# Some Useful Names
rock = &quot;rock&quot;
paper = &quot;paper&quot;

def playerA_wins():
    print(&quot;Player A Wins&quot;)

def playerB_wins():
    print(&quot;Player B Wins&quot;)

transitions = {(paper, rock): playerA_wins,
               (rock, paper): playerB_wins}

transitions[(paper, rock)]()
transitions[(rock, paper)]()

Getting user input can be dispatched similarly by the dictionary. However, the initial (null, null) state, threading might be justified so that playerA_choice() doesn't block playerB_choice() or vice versa...that's IO for 'ya.
Recommendations

Better variable names. Write about rocks and paper and scissors: rock = 1 makes the code more readable. Readability particularly helps the person writing the code.
Make the code more modular. Put all the initialization together. Put all the user interface someplace else. Separate out the string matching. Only put high level abstractions in the main loop.
Consider specifying the problem before writing code for a solution. At the core Rock, Paper, Scissors does not deal with synonyms. Writing a specification makes it clear that synonyms are a feature and encourages keeping their logic outside the main loop. This makes the code more readable.