Re: Rock Paper Scissors Code Bug?
On 08/12/2025 21:18, Thomas Passin wrote:
On 12/8/2025 2:49 PM, John Smith via Python-list wrote:
Thanks for the tip. I'll do that here and in future games.
In addition to using constants to parameterize the strings, the whole
game can be made simpler and easier to change when you realize that
the if/else block has a regular construction. Here's a sketch of one
way to take advantage of this structure (untested). You should be
able to fill in the elided code. Use lower case to check the input so
a mistake in capitalization doesn't reject the input. That's a simple
courtesy to the user.
import random #Allows for a random input.
ROCK = 'rock'
PAPER = 'paper'
SCISSORS = 'scissors'
TIE = 'Tie'
ULOSE = 'You Lose'
UWIN = 'You Win'
GAME = {
(ROCK, ROCK): TIE,
(ROCK, PAPER): ULOSE,
# ...
}
OPTIONS = (ROCK, PAPER, SCISSORS)
PROMPT = (f'Welcome to the {ROCK}, {PAPER}, {SCISSORS} game. ' +
'Choose one of the three')
# skipping some code
player_choice = input(PROMPT)
player_choice = player_choice.lower()
if player_choice not in OPTIONS:
print(f'{player_choice} is not an allowed input')
continue
result = GAME[(player_choice, choice)]
print(result)
# ...
There's another way of determining who won.
Give each of the choices a value, such as:
OPTION_VALUES = {ROCK: 0, PAPER: 1, SCISSORS: 2}
Look at the difference between the values of what the bot chose and what
the player chose.
There are 5 possible differences, from -2 to +2.
From that difference you can determine who won or whether it's a tie.
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
On 2025-12-08 at 18:57:34 -0500,
Thomas Passin wrote:
> On 12/8/2025 6:16 PM, MRAB wrote:
> > On 08/12/2025 21:18, Thomas Passin wrote:
[...]
> > There's another way of determining who won.
> >
> > Give each of the choices a value, such as:
> >
> > OPTION_VALUES = {ROCK: 0, PAPER: 1, SCISSORS: 2}
> >
> > Look at the difference between the values of what the bot chose and what
> > the player chose.
> >
> > There are 5 possible differences, from -2 to +2.
> >
> > From that difference you can determine who won or whether it's a tie.
>
> Sure, there are lots of possibilities. Using a little arithmetic would be
> nice and concise and well-suited to a C program or even assembler. It's
> mostly personal taste, and mine is to make the program easy to write and
> later on, read.
I, for one, appreciate (if not revel in) concise, elegant, and superior
algorithms. Bubble and Insertion sorts are easy to write and easy to
read; QuickSort, Gap Sort, and a plethora of others are better sorting
algorithms (although on this list, I have no doubt that someone will
present a specific use case (or an entire class of use cases) in which
Bubble Sort is the most appropriate sorting algorithm).
Has the art of documentation been lost? What about maintainability?
Explain the arithmetic in plain English (or some other language) in a
comment. Take the time to lay out an exhaustive matrix. Set a good
example, not to mention the groundwork for future maintainers (even if
that only means you) to be enlightened (or to have a flash of insight
triggered by a novel solution to an old problem).
The rules of Rock, Paper, Scissors are unlikely to change (Rock, Paper,
Scissors, Lizard, Spock notwithstanding) over time, so there is little
chance that such a comment will fall out of sync with the code.
Hang on... How did that used to go? Oh, yeah
Not As Jokingly As You Think'ly Yours,
Dan
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
Thanks for the recommendations. I'm building a whole new version based on the old one, with simpler code and functions to find win stats. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
On 12/8/2025 6:16 PM, MRAB wrote:
On 08/12/2025 21:18, Thomas Passin wrote:
On 12/8/2025 2:49 PM, John Smith via Python-list wrote:
Thanks for the tip. I'll do that here and in future games.
In addition to using constants to parameterize the strings, the whole
game can be made simpler and easier to change when you realize that
the if/else block has a regular construction. Here's a sketch of one
way to take advantage of this structure (untested). You should be
able to fill in the elided code. Use lower case to check the input so
a mistake in capitalization doesn't reject the input. That's a simple
courtesy to the user.
import random #Allows for a random input.
ROCK = 'rock'
PAPER = 'paper'
SCISSORS = 'scissors'
TIE = 'Tie'
ULOSE = 'You Lose'
UWIN = 'You Win'
GAME = {
(ROCK, ROCK): TIE,
(ROCK, PAPER): ULOSE,
# ...
}
OPTIONS = (ROCK, PAPER, SCISSORS)
PROMPT = (f'Welcome to the {ROCK}, {PAPER}, {SCISSORS} game. ' +
'Choose one of the three')
# skipping some code
player_choice = input(PROMPT)
player_choice = player_choice.lower()
if player_choice not in OPTIONS:
print(f'{player_choice} is not an allowed input')
continue
result = GAME[(player_choice, choice)]
print(result)
# ...
There's another way of determining who won.
Give each of the choices a value, such as:
OPTION_VALUES = {ROCK: 0, PAPER: 1, SCISSORS: 2}
Look at the difference between the values of what the bot chose and what
the player chose.
There are 5 possible differences, from -2 to +2.
From that difference you can determine who won or whether it's a tie.
Sure, there are lots of possibilities. Using a little arithmetic would
be nice and concise and well-suited to a C program or even assembler.
It's mostly personal taste, and mine is to make the program easy to
write and later on, read.
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: A switch somewhere, or bug? CORRECTION
Op 8/12/2025 om 4:40 schreef Michael Torrie via Python-list: On 12/7/25 5:22 AM, Roel Schroeven wrote: > Op 7/12/2025 om 1:54 schreef Thomas Passin: >> As I explained in my last post, that's because in Windows 11 when >> double-clicking, the working directory is the system's Windows >> directory, not the one your program is in. > Irrespective of anything else that's going on, that's not my experience. > I just tried, and double-clicking a python script makes the directory > that I have open in Explorer the current directory. I've seen the same > not just with scripts but also with executables. I don't think this is > the cause. Python from the MS Store or python from python.org? Python from python.org, most likely. Is there a way to know for sure? -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
On Tue, 9 Dec 2025 at 05:29, via Python-list wrote: > > I coded Rock, Paper, Scissors. I added the randomness, made it loop at the > user's request, added win code, no problems there. I changed some strings to > F-strings to practice using them, and now the first "elif" in my if loop > (player chooses rock, bot chooses paper) doesn't work. Any help ideas? I > checked syntax, no error messages other than mine that I added > Pasting code below the line: > > elif player_choice == "Rock " and choice == "Paper": You did a great job of pinning down where the problem is! Now all you need to do is stare at this one line until you see a problem. Space - the final frontier! :) ChrisA -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
On 12/8/2025 2:49 PM, John Smith via Python-list wrote:
Thanks for the tip. I'll do that here and in future games.
In addition to using constants to parameterize the strings, the whole
game can be made simpler and easier to change when you realize that the
if/else block has a regular construction. Here's a sketch of one way to
take advantage of this structure (untested). You should be able to fill
in the elided code. Use lower case to check the input so a mistake in
capitalization doesn't reject the input. That's a simple courtesy to
the user.
import random #Allows for a random input.
ROCK = 'rock'
PAPER = 'paper'
SCISSORS = 'scissors'
TIE = 'Tie'
ULOSE = 'You Lose'
UWIN = 'You Win'
GAME = {
(ROCK, ROCK): TIE,
(ROCK, PAPER): ULOSE,
# ...
}
OPTIONS = (ROCK, PAPER, SCISSORS)
PROMPT = (f'Welcome to the {ROCK}, {PAPER}, {SCISSORS} game. ' +
'Choose one of the three')
# skipping some code
player_choice = input(PROMPT)
player_choice = player_choice.lower()
if player_choice not in OPTIONS:
print(f'{player_choice} is not an allowed input')
continue
result = GAME[(player_choice, choice)]
print(result)
# ...
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
Ah! Found it. I had an extra space in "Rock". Thanks for the help! -- https://mail.python.org/mailman3//lists/python-list.python.org
SQLObject 3.13.1
Hello!
I'm pleased to announce version 3.13.1, the first bugfix release of the
branch 3.13 of SQLObject.
What's new in SQLObject
===
The contributors for this release are:
* Igor Yudytskiy. Thanks for PR #194:
fix: connect to old mssql versions via set tds_version uri parameter.
* Dave Mulligan fixed #195: Minor ``NameError`` in ``pgconnection.py``
when using ``psycopg`` version 1 with a non-default port. Thanks!
* Chris Kauffman found a minor bug in ``UuidValidator``.
* GH user ghaushe-ampere. Thanks for finding an obscure bug!
Bug fixes
-
* ``UuidValidator.from_python()`` now accepts strings as a valid input.
This fixes #199.
* Fixed #197: a bug in ``dbconnection.ConnectionURIOpener.registerConnection``
triggered by non-empty instance's ``name``. The bug was inserted in 2004 so
it seems nobody ever used named instances. Fixed anyway.
* Fixed #195: Minor ``NameError`` in ``pgconnection.py``
when using ``psycopg`` version 1 with a non-default port.
Tests
-
* Tested with Python 3.14.
* Run tests with source-only (non-binary) ``psycopg`` and ``psycopg2``.
For a more complete list, please see the news:
http://sqlobject.org/News.html
What is SQLObject
=
SQLObject is a free and open-source (LGPL) Python object-relational
mapper. Your database tables are described as classes, and rows are
instances of those classes. SQLObject is meant to be easy to use and
quick to get started with.
SQLObject supports a number of backends: MySQL/MariaDB (with a number of
DB API drivers: ``MySQLdb``, ``mysqlclient``, ``mysql-connector``,
``PyMySQL``, ``mariadb``), PostgreSQL (``psycopg``, ``psycopg2``, ``PyGreSQL``,
partially ``pg8000``), SQLite (builtin ``sqlite3``);
connections to other backends - Firebird, Sybase, MSSQL and MaxDB (also
known as SAPDB) - are less debugged).
Python 2.7 or 3.4+ is required.
Where is SQLObject
==
Site:
http://sqlobject.org
Download:
https://pypi.org/project/SQLObject/3.13.1
News and changes:
http://sqlobject.org/News.html
StackOverflow:
https://stackoverflow.com/questions/tagged/sqlobject
Mailing lists:
https://sourceforge.net/p/sqlobject/mailman/
Development:
http://sqlobject.org/devel/
Developer Guide:
http://sqlobject.org/DeveloperGuide.html
Example
===
Install::
$ pip install sqlobject
Create a simple class that wraps a table::
>>> from sqlobject import *
>>>
>>> sqlhub.processConnection = connectionForURI('sqlite:/:memory:')
>>>
>>> class Person(SQLObject):
... fname = StringCol()
... mi = StringCol(length=1, default=None)
... lname = StringCol()
...
>>> Person.createTable()
Use the object::
>>> p = Person(fname="John", lname="Doe")
>>> p
>>> p.fname
'John'
>>> p.mi = 'Q'
>>> p2 = Person.get(1)
>>> p2
>>> p is p2
True
Queries::
>>> p3 = Person.selectBy(lname="Doe")[0]
>>> p3
>>> pc = Person.select(Person.q.lname=="Doe").count()
>>> pc
1
Oleg.
--
Oleg Broytmanhttps://phdru.name/[email protected]
Programmers don't die, they just GOSUB without RETURN.
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
>
>
> I coded Rock, Paper, Scissors. I added the randomness, made it loop at the
> user's request, added win code, no problems there. I changed some strings
> to F-strings to practice using them, and now the first "elif" in my if loop
> (player chooses rock, bot chooses paper) doesn't work. Any help ideas? I
> checked syntax, no error messages other than mine that I added
> Pasting code below the line:
>
> _
> import random #Allows for a random input.
> options = ["Rock", "Paper", "Scissors"] #Tells the computer what its
> options are.
> playerchoices = []
> repeat = True
> while repeat == True:
> rand_choice = random.randint(1,3)
> choice = options[rand_choice-1] #defines player options and selection
> while True:
> player_choice = input("Welcome to Rock, Paper, Scissors. To begin,
> choose Rock, Paper, or Scissors. ")
> if player_choice == "Rock":
> break
> if player_choice == "Paper":
> break
> if player_choice == "Scissors":
>...
>
One practice I follow is declaring strings, _especially_ those used more
than once, at the top:
import random #Allows for a random input.
ROCK = "Rock" # Defined once
PAPER = "Paper" # Defined once
SCISSORS = "Scissors" # Defined once
options = [ROCK, PAPER, SCISSORS] #Tells the computer what its options are.
playerchoices = []
repeat = True
while repeat == True:
rand_choice = random.randint(1,3)
choice = options[rand_choice-1] #defines player options and selection
while True:
player_choice = input("Welcome to Rock, Paper, Scissors. To begin,
choose Rock, Paper, or Scissors. ")
if player_choice == ROCK:
break
if player_choice == PAPER:
break
if player_choice == SCISSORS:
...
The advantage of this approach is misspellings generate compilation errors,
which are easier to catch and fix.
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
Thanks for the tip. I'll do that here and in future games. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
Op 8/12/2025 om 20:43 schreef Jason Friedman via Python-list: One practice I follow is declaring strings, _especially_ those used more than once, at the top: In a case like this, an Enum could probably be even more fitting (or in this case more specifically a StrEnum). See https://docs.python.org/3.13/library/enum.html#enum.StrEnum -- "The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom." -- Isaac Asimov -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Rock Paper Scissors Code Bug?
On 12/8/2025 8:14 PM, Dan Sommers wrote:
On 2025-12-08 at 18:57:34 -0500,
Thomas Passin wrote:
On 12/8/2025 6:16 PM, MRAB wrote:
On 08/12/2025 21:18, Thomas Passin wrote:
[...]
There's another way of determining who won.
Give each of the choices a value, such as:
OPTION_VALUES = {ROCK: 0, PAPER: 1, SCISSORS: 2}
Look at the difference between the values of what the bot chose and what
the player chose.
There are 5 possible differences, from -2 to +2.
From that difference you can determine who won or whether it's a tie.
Sure, there are lots of possibilities. Using a little arithmetic would be
nice and concise and well-suited to a C program or even assembler. It's
mostly personal taste, and mine is to make the program easy to write and
later on, read.
I, for one, appreciate (if not revel in) concise, elegant, and superior
algorithms. Bubble and Insertion sorts are easy to write and easy to
read; QuickSort, Gap Sort, and a plethora of others are better sorting
algorithms (although on this list, I have no doubt that someone will
present a specific use case (or an entire class of use cases) in which
Bubble Sort is the most appropriate sorting algorithm).
There's a time and a place, right? If one needs very good performance,
not all sorts are equivalent. An efficient, elegant algorithm well
executed can be essential and its elegance to be appreciated. In this
(and so many others), the highest performance is not required, so other
considerations can potentially carry more weight.
Has the art of documentation been lost? What about maintainability?
Explain the arithmetic in plain English (or some other language) in a
comment. Take the time to lay out an exhaustive matrix. Set a good
example, not to mention the groundwork for future maintainers (even if
that only means you) to be enlightened (or to have a flash of insight
triggered by a novel solution to an old problem).
Documentation is good, code that is clear enough to be fairly
self-documenting is better. Again, use what's needed where it is needed.
There are well-known drawbacks to documentation: keeping it in sync, and
getting people to read it. But let's not try to lay too much on our OP,
who has been struggling a little bit here.
The rules of Rock, Paper, Scissors are unlikely to change (Rock, Paper,
Scissors, Lizard, Spock notwithstanding) over time, so there is little
chance that such a comment will fall out of sync with the code.
Hang on... How did that used to go? Oh, yeah
Not As Jokingly As You Think'ly Yours,
Dan
--
https://mail.python.org/mailman3//lists/python-list.python.org
Rock Paper Scissors Code Bug?
I coded Rock, Paper, Scissors. I added the randomness, made it loop at the
user's request, added win code, no problems there. I changed some strings to
F-strings to practice using them, and now the first "elif" in my if loop
(player chooses rock, bot chooses paper) doesn't work. Any help ideas? I
checked syntax, no error messages other than mine that I added
Pasting code below the line:
_
import random #Allows for a random input.
options = ["Rock", "Paper", "Scissors"] #Tells the computer what its options
are.
playerchoices = []
repeat = True
while repeat == True:
rand_choice = random.randint(1,3)
choice = options[rand_choice-1] #defines player options and selection
while True:
player_choice = input("Welcome to Rock, Paper, Scissors. To begin, choose
Rock, Paper, or Scissors. ")
if player_choice == "Rock":
break
if player_choice == "Paper":
break
if player_choice == "Scissors":
break
else:
print("Invalid input, try again. Capitalize your response and ensure
proper spelling. ") #Lines 10-19 give the player a choice as to what to pick.
#The code below determines victory status.
if player_choice == "Rock" and choice == options[0]:
print(f"Computer played {options[0]}. Tie.")
playerchoices.append("Rock")
elif player_choice == "Rock " and choice == "Paper":
print(f"Computer played {options[1]}. You lose.")
playerchoices.append("Rock")
elif player_choice == "Rock" and choice == options[2]:
print(f"Computer played {options[2]}. You win.")
playerchoices.append("Rock")
elif player_choice == "Paper" and choice == options[0]:
print(f"Computer played {options[0]}. You win.")
playerchoices.append("Paper")
elif player_choice == "Paper" and choice == options[1]:
print(f"Computer played {options[1]}. Tie.")
playerchoices.append("Paper")
elif player_choice == "Paper" and choice == options[2]:
print(f"Computer played {options[2]} . You lose.")
playerchoices.append("Paper")
elif player_choice == "Scissors" and choice == options[0]:
print(f"Computer played {options[0]}. You lose.")
playerchoices.append("Scissors")
elif player_choice == "Scissors" and choice == options[1]:
print(f"Computer played {options[1]}. You win.")
playerchoices.append("Scissors")
elif player_choice == "Scissors" and choice == options[2]:
print(f"Computer played {options[2]}. Tie.")
playerchoices.append("Scissors")
else:
print("If you're reading this, I messed up somehow")
print(f"Choice: {choice}")
print(f"You played: {player_choice}")
playagain = True
while playagain == True:
ask_repeat = input("Play again? Y/N ")
if ask_repeat == "Y":
print("Restarting... ")
repeat = True
playagain = False
elif ask_repeat == "N":
repeat = False
playagain = False
print("Goodbye.")
else:
playagain = True
repeat = False
print("Error. Input either Y or N. Capitalize and retry.")
--
https://mail.python.org/mailman3//lists/python-list.python.org
