Re: Rock Paper Scissors Code Bug?

[Thomas Passin]

On 12/17/2025 10:43 PM, Gregg Drennan via Python-list wrote:

The other recommendation i would make is to shorten the response the player
needs to give when choosing their option.  "R", "P", "S" is sufficient to
determine the player's choice.  Making the player enter the whole word
introduces opportunity for misspellings.  I would also allow the player to
enter "Q" in case they decide to stop playing.  And always check to make
sure the player entered something and didn't just hit enter.  Also don't
use .lower() until you check to make sure you have a valid entry, the
player might enter a character that can't be converted to lower case, like
a number or punctuation.


See, here's the problem with relying on a chatbot. Calling lower() works 
fine for a character that doesn't have a lowerclass version.  It just 
returns the original.




while True:
 player_choice = input("Please enter your choice (Rock, Paper, Scissors,
or Quit): "
 If not player_choice or player_choice[0] not in "RPSQrpsq":   # check
if None or invalid choice
 print("Invalid choice...")
 else:
 If player_choice[0].lower() == "q":
  print("Thanks for playing.  Good-bye.")
  break
 # code to score the choices, blah, blah, blah

Good luck with your new version!

On Mon, Dec 8, 2025, 5:37 PM John Smith via Python-list <
python-list@python.org> wrote:


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



--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Rock Paper Scissors Code Bug?

[Mats Wichmann]

On 12/18/25 06:13, Thomas Passin wrote:

On 12/17/2025 10:43 PM, Gregg Drennan via Python-list wrote:
The other recommendation i would make is to shorten the response the 
player

needs to give when choosing their option.  "R", "P", "S" is sufficient to
determine the player's choice.  Making the player enter the whole word
introduces opportunity for misspellings.  I would also allow the 
player to

enter "Q" in case they decide to stop playing.  And always check to make
sure the player entered something and didn't just hit enter.  Also don't
use .lower() until you check to make sure you have a valid entry, the
player might enter a character that can't be converted to lower case, 
like

a number or punctuation.


See, here's the problem with relying on a chatbot. Calling lower() works 
fine for a character that doesn't have a lowerclass version.  It just 
returns the original.
casefold() is more reliable for comparisons for non-ASCII characters. 
Since the set of acceptable strings appears to be bounded, that's 
perhaps an unnecessary detail here.

--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[rbowman]

On Wed, 17 Dec 2025 23:02:24 -0500, c186282 wrote:

>Oh, I usually write "i=i+2". It's a bit more clear and becomes the
>same code anyway. += is more a 'C' thing.

And Python, C#, JavaScript, C++, ...

https://peps.python.org/pep-0008/

"assignment (+=, -= etc.), comparisons (==, <, >, !=, <=, >=, in, not in, 
is, is not), Booleans (and, or, not)."


There's some benighted language that does not have += etc.  Maybe R. I 
looked at that briefly before deciding anything I could do in R I could do 
in Python without learning new weirdness.
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[rbowman]

On Thu, 18 Dec 2025 08:03:47 +0100, Marc Haber wrote:

> rbowman  wrote:
>>I keep it simple and use the first column, s/^/#/  in vim. s/^#// to
>>make them go away.
> 
> Ctrl-V, down, I, '# ', Escape.
> 
> Those block commands are great! How have I ever lived without them?


Learned something new. I seldom, if ever, use the visual mode so I mark 
the end of the block and use the  :.,'as/^/#/  form. Years of muscle 
memory. I have a book on Vim somewhere. What it pointed out to me is how 
much functionality Vim has that I don't use. I learned one way to skin a 
cat long ago and stuck with it. For example I use :new foo.txt to get two 
vertically stacked panes.  I know you can do side by side panes but I 
never do.


-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[rbowman]

On Thu, 18 Dec 2025 04:25:35 -0500, c186282 wrote:

>   But isn't  &&  and  ||  more better ? If the
>meaning is more obscure then it MUST be better !

Perfectly obvious. BTW any language that can't do bit operations should be 
drowned at birth.

>'R' ??? You must have some very special needs !

https://www.anaconda.com/blog/python-vs-r-data-science-ai-workflows

The article is biased but R at one time was more popular for machine 
learning. Python caught up rapidly. One of the problems with R is a sort 
of quirky syntax compared to most languages. With Python you can use 
TensorFlow and even if you don't know much about ML it looks like Python. 

Both are interpreted so aren't the speediest languages. R originally had 
an edge but as Python became more popular for ML packages like numpy were 
optimized. 

Note: I draw a distinction between ML and LLMs. All the hype is for LLMs 
and I'm not sure the balloon won't burst. ML is the poor relation but I 
think it has more real value to offer in many domains. 

-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Rock Paper Scissors Code Bug?

[MRAB]

On 18/12/2025 18:34, Gregg Drennan via Python-list wrote:

No chatbot involved.  I was typing this on my phone in bed last night and
didn't have a Python interpreter handy that I could verify this with.  I
will certainly check this.

In any case, since verifying that a valid choice was made was made is done
in the same IF statement as the check for None, it seems to be a moot
point.

Calling lower() on None will cause an Exception so I would always recommend
making that check on any user input.

The `input` function always returns a string (`str`), so using 
`.lower()` or `.casefold()` on its result will always succeed.

Yes, using casefold to deal with non-ascii characters is a good point.  In
this case, we don't care what the input was if it's not one of the four
valid choices...we just treat it as invalid and prompt the player to enter
a valid choice.


On Thu, Dec 18, 2025, 8:21 AM Thomas Passin  wrote:


On 12/17/2025 10:43 PM, Gregg Drennan via Python-list wrote:

The other recommendation i would make is to shorten the response the

player

needs to give when choosing their option.  "R", "P", "S" is sufficient to
determine the player's choice.  Making the player enter the whole word
introduces opportunity for misspellings.  I would also allow the player

to

enter "Q" in case they decide to stop playing.  And always check to make
sure the player entered something and didn't just hit enter.  Also don't
use .lower() until you check to make sure you have a valid entry, the
player might enter a character that can't be converted to lower case,

like

a number or punctuation.

See, here's the problem with relying on a chatbot. Calling lower() works
fine for a character that doesn't have a lowerclass version.  It just
returns the original.



while True:
  player_choice = input("Please enter your choice (Rock, Paper,

Scissors,

or Quit): "
  If not player_choice or player_choice[0] not in "RPSQrpsq":   #

check

if None or invalid choice
  print("Invalid choice...")
  else:
  If player_choice[0].lower() == "q":
   print("Thanks for playing.  Good-bye.")
   break
  # code to score the choices, blah, blah, blah

Good luck with your new version!

On Mon, Dec 8, 2025, 5:37 PM John Smith via Python-list <
python-list@python.org> wrote:


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


--
https://mail.python.org/mailman3//lists/python-list.python.org



--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[The Natural Philosopher]

On 18/12/2025 10:19, Marc Haber wrote:

The Natural Philosopher  wrote:

#define Bollocks

#ifdef BOLLOCKS
..
...

..
.
#endif


Has the disadvantage of being language specific.


Almost everything is language specific.
Its not as if you are writing for three different languages with the 
same code.



Greetings
Marc


--
“Politics is the art of looking for trouble, finding it everywhere, 
diagnosing it incorrectly and applying the wrong remedies.”

― Groucho Marx
--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[c186282]

On 12/18/25 01:54, rbowman wrote:

On Wed, 17 Dec 2025 23:02:24 -0500, c186282 wrote:


Oh, I usually write "i=i+2". It's a bit more clear and becomes the
same code anyway. += is more a 'C' thing.


And Python, C#, JavaScript, C++, ...


  Well, I know it *works* ... I just choose not
  to do it in Python. Everyone has their 'style'.


https://peps.python.org/pep-0008/

"assignment (+=, -= etc.), comparisons (==, <, >, !=, <=, >=, in, not in,
is, is not), Booleans (and, or, not)."


  But isn't  &&  and  ||  more better ? If the
  meaning is more obscure then it MUST be better !  :-)


There's some benighted language that does not have += etc.  Maybe R. I
looked at that briefly before deciding anything I could do in R I could do
in Python without learning new weirdness.


  'R' ??? You must have some very special needs !
--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Marc Haber]

rbowman  wrote:
>I keep it simple and use the first column, s/^/#/  in vim. s/^#// to make 
>them go away. 

Ctrl-V, down, I, '# ', Escape.

Those block commands are great! How have I ever lived without them?

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Marc Haber]

The Natural Philosopher  wrote:
>#define Bollocks
>
>#ifdef BOLLOCKS
>..
>...
>
>..
>.
>#endif

Has the disadvantage of being language specific.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[rbowman]

On Wed, 17 Dec 2025 22:18:39 -0500, c186282 wrote:

>Both ''' and """ work ... but you need to close the comment block
>with the same thing.
> 
>ANYway, block-comments ARE (at least now) to be had in Python.
> 
>Never used P1 or P2 worth anything, maybe they didn't have block
>comments ???

https://peps.python.org/pep-0257/

Doc strings are a little strange. 'String' is the key word. 

 python3
Python 3.13.7 (main, Nov 24 2025, 20:51:28) [GCC 15.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> # this is a real comment
>>> """this a a multiline
... string
... """
'this a a multiline\nstring\n'
>>> foo = """ more multiline
...   stuff
...   """
>>> print(foo)
 more multiline
  stuff
There are just strings that aren't assigned. 


-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Scott Lurndal]

rbowman  writes:
>On Thu, 18 Dec 2025 08:03:47 +0100, Marc Haber wrote:
>
>> rbowman  wrote:
>>>I keep it simple and use the first column, s/^/#/  in vim. s/^#// to
>>>make them go away.
>> 
>> Ctrl-V, down, I, '# ', Escape.
>> 
>> Those block commands are great! How have I ever lived without them?
>
>
>Learned something new. I seldom, if ever, use the visual mode so I mark 
>the end of the block and use the  :.,'as/^/#/  form. Years of muscle 
>memory. I have a book on Vim somewhere. What it pointed out to me is how 
>much functionality Vim has that I don't use. I learned one way to skin a 
>cat long ago and stuck with it. For example I use :new foo.txt to get two 
>vertically stacked panes.  I know you can do side by side panes but I 
>never do.

:sp[lit]
:vs[plit]

also work.  I generally divide the vim screen into four 100 column wide
panes.
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Peter Flass]

On 12/18/25 11:00, Richard Kettlewell wrote:

Peter Flass  writes:

I comment *A LOT*. When I had to go back and revisit some very old
code, I wished I had commented more. I've almost never looked at a
program and said "I wish it had fewer comments."


Regrettably, I’ve encountered plenty of comments that don’t actually
reflect the code (for a variety of reasons).

If the code is wrong and the comment is right then that’s great, you
have a nice hint about how to fix the code, assuming you realize there’s
a problem at all.

However if the code is right but the comment is wrong then the comment
is worse than nothing. The code would be improved by removing it
(although almost certainly improved even more by correcting it).

I’ve also encountered quite a few comments written by people who had
been instructed to add comments to under-commented code, but didn’t
really understand what they were looking at. The result generally
obscures more than it illuminates.



Since documentation never gets updated, if it's even created at all, 
comments are the best you can get most of the time.

--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Mats Wichmann]

On 12/17/25 17:52, rbowman wrote:

On Wed, 17 Dec 2025 22:13:21 +, Richard Kettlewell wrote:


If you prefer the comment markers to match the indentation of the whole
block, that works too:


I keep it simple and use the first column, s/^/#/  in vim. s/^#// to make
them go away.


You can also select a block with ^V + cursor movement, then

I# 

(capital I for insert-at-start-of-line, that is, and the escape key 
rather than the literal chars, of course)





--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[The Natural Philosopher]

On 18/12/2025 07:03, Marc Haber wrote:

rbowman  wrote:

I keep it simple and use the first column, s/^/#/  in vim. s/^#// to make
them go away.


Ctrl-V, down, I, '# ', Escape.

Those block commands are great! How have I ever lived without them?

Greetings
Marc

#define Bollocks

#ifdef BOLLOCKS
..
...

..
.
#endif

--
Ideas are more powerful than guns. We would not let our enemies have 
guns, why should we let them have ideas?


Josef Stalin
--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Peter Flass]

On 12/17/25 20:10, c186282 wrote:

On 12/17/25 14:17, rbowman wrote:

On Wed, 17 Dec 2025 03:11:09 -0500, c186282 wrote:


    Probably 50% of the text in my code - doesn't matter which lang - is
    'comments'.


I looked at some of my code and it's pretty much comment free. There 
are a

couple of .c files with comments that I reused from another project that
have somebody's comments.

I had a tendency to clone similar projects and inherit some code that I
could tweak so the final executable did one thing well. We had a 
couple of
nightmares that originally did one thing well but for the next project 
the

programmer said 'That's close to what I need. A few configuration values
here and there and it will work.'  The next time around it got some more
configuration values to do something else.  I have a Swiss Army knife I
found; it's in the junk drawer.



   Well ... I'll better understand, and be able to mod, my
   old programs better than you. I find 'excessive' commenting
   anything BUT 'excessive'. I *enjoy* writing out the meaning
   and implications of almost every step.



I comment *A LOT*. When I had to go back and revisit some very old code, 
I wished I had commented more. I've almost never looked at a program and 
said "I wish it had fewer comments."

--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[rbowman]

On Thu, 18 Dec 2025 15:43:49 GMT, Scott Lurndal wrote:

> rbowman  writes:
>>On Thu, 18 Dec 2025 08:03:47 +0100, Marc Haber wrote:
>>
>>> rbowman  wrote:
I keep it simple and use the first column, s/^/#/  in vim. s/^#// to
make them go away.
>>> 
>>> Ctrl-V, down, I, '# ', Escape.
>>> 
>>> Those block commands are great! How have I ever lived without them?
>>
>>
>>Learned something new. I seldom, if ever, use the visual mode so I mark
>>the end of the block and use the  :.,'as/^/#/  form. Years of muscle
>>memory. I have a book on Vim somewhere. What it pointed out to me is how
>>much functionality Vim has that I don't use. I learned one way to skin a
>>cat long ago and stuck with it. For example I use :new foo.txt to get
>>two vertically stacked panes.  I know you can do side by side panes but
>>I never do.
> 
> :sp[lit]
> :vs[plit]
> 
> also work.  I generally divide the vim screen into four 100 column wide
> panes.

I'd screw that up. I use i3/sway and I have a moment of hesitation of 
whether Meta-h or Meta-v is going to split the way I want. 'I want two 
panes stacked vertically so that's 'h'. Or is it 'v'?'

-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[rbowman]

On Thu, 18 Dec 2025 18:00:45 +, Richard Kettlewell wrote:

> I’ve also encountered quite a few comments written by people who had
> been instructed to add comments to under-commented code, but didn’t
> really understand what they were looking at. The result generally
> obscures more than it illuminates.

Many of the comments were by recent graduates/interns who had received 
'Thou Shalt Comment' as the 11th commandment. Ironically when a TA at the 
university who was known to demand extensive commenting was hired we found 
he never commented anything, preferred cryptic variable names not to 
exceed three characters, and did perverted things with the macro processor 
so function names were patched together on the fly rather than existing in 
the code. Then there was the fondness for the big hairy bison to create 
private little languages. 
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Rock Paper Scissors Code Bug?

[Gregg Drennan via Python-list]

No chatbot involved.  I was typing this on my phone in bed last night and
didn't have a Python interpreter handy that I could verify this with.  I
will certainly check this.

In any case, since verifying that a valid choice was made was made is done
in the same IF statement as the check for None, it seems to be a moot
point.

Calling lower() on None will cause an Exception so I would always recommend
making that check on any user input.

Yes, using casefold to deal with non-ascii characters is a good point.  In
this case, we don't care what the input was if it's not one of the four
valid choices...we just treat it as invalid and prompt the player to enter
a valid choice.


On Thu, Dec 18, 2025, 8:21 AM Thomas Passin  wrote:

> On 12/17/2025 10:43 PM, Gregg Drennan via Python-list wrote:
> > The other recommendation i would make is to shorten the response the
> player
> > needs to give when choosing their option.  "R", "P", "S" is sufficient to
> > determine the player's choice.  Making the player enter the whole word
> > introduces opportunity for misspellings.  I would also allow the player
> to
> > enter "Q" in case they decide to stop playing.  And always check to make
> > sure the player entered something and didn't just hit enter.  Also don't
> > use .lower() until you check to make sure you have a valid entry, the
> > player might enter a character that can't be converted to lower case,
> like
> > a number or punctuation.
>
> See, here's the problem with relying on a chatbot. Calling lower() works
> fine for a character that doesn't have a lowerclass version.  It just
> returns the original.
>
>
> > while True:
> >  player_choice = input("Please enter your choice (Rock, Paper,
> Scissors,
> > or Quit): "
> >  If not player_choice or player_choice[0] not in "RPSQrpsq":   #
> check
> > if None or invalid choice
> >  print("Invalid choice...")
> >  else:
> >  If player_choice[0].lower() == "q":
> >   print("Thanks for playing.  Good-bye.")
> >   break
> >  # code to score the choices, blah, blah, blah
> >
> > Good luck with your new version!
> >
> > On Mon, Dec 8, 2025, 5:37 PM John Smith via Python-list <
> > python-list@python.org> wrote:
> >
> >> 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
> >>
>
> --
> https://mail.python.org/mailman3//lists/python-list.python.org
>
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Richard Kettlewell]

Peter Flass  writes:
> I comment *A LOT*. When I had to go back and revisit some very old
> code, I wished I had commented more. I've almost never looked at a
> program and said "I wish it had fewer comments."

Regrettably, I’ve encountered plenty of comments that don’t actually
reflect the code (for a variety of reasons).

If the code is wrong and the comment is right then that’s great, you
have a nice hint about how to fix the code, assuming you realize there’s
a problem at all.

However if the code is right but the comment is wrong then the comment
is worse than nothing. The code would be improved by removing it
(although almost certainly improved even more by correcting it).

I’ve also encountered quite a few comments written by people who had
been instructed to add comments to under-commented code, but didn’t
really understand what they were looking at. The result generally
obscures more than it illuminates.

-- 
https://www.greenend.org.uk/rjk/
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[Alan Gauld via Python-list]

On 18/12/2025 14:40, Peter Flass wrote:

> ...I've almost never looked at a program and 
> said "I wish it had fewer comments."

Sadly I have. In one notable example we sub-contracted
the coding out to an external company and the contract
specified some code "quality metrics" one of these was
the ratio of comments to code.

I  then had the dubious privilege of trying to debug
files with the entire lyrics of "I Did it My Way" in
the header comments. And another that contained lines
like the following:

if incrementNodeValues(theNodes) == None:
   # Scotty: Captain the node value incrementer just failed
   # Kirk:  Can you manually over ride it Mr Scott?
   # Scotty: I cannae override maxint captain!
   raise NodeOverFlowError

Others were more blatant(and honest!):

def someFunc():
# some pointless comments to meet the metrics
# dum
# de
# dum
... etc

I love good comments but comments for the sake of
it not so much!

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[dn via Python-list]

On 19/12/2025 08:52, Peter Flass wrote:

On 12/18/25 11:00, Richard Kettlewell wrote:

Peter Flass  writes:

I comment *A LOT*. When I had to go back and revisit some very old
code, I wished I had commented more. I've almost never looked at a
program and said "I wish it had fewer comments."


Regrettably, I’ve encountered plenty of comments that don’t actually
reflect the code (for a variety of reasons).

If the code is wrong and the comment is right then that’s great, you
have a nice hint about how to fix the code, assuming you realize there’s
a problem at all.

However if the code is right but the comment is wrong then the comment
is worse than nothing. The code would be improved by removing it
(although almost certainly improved even more by correcting it).

I’ve also encountered quite a few comments written by people who had
been instructed to add comments to under-commented code, but didn’t
really understand what they were looking at. The result generally
obscures more than it illuminates.



Since documentation never gets updated, if it's even created at all, 
comments are the best you can get most of the time.


Are your unit and integration tests a form of (technical) documentation 
and a guide for use?


If start from the spec/user story (perhaps as a README.md in tests/) and 
 reproduce appropriate sections (as comments/docstrings, hah!) in each 
test file, then will all flow-through?


--
Regards,
=dn

--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Rock Paper Scissors Code Bug?

[Thomas Passin]

On 12/18/2025 1:34 PM, Gregg Drennan wrote:
No chatbot involved.  I was typing this on my phone in bed last night 
and didn't have a Python interpreter handy that I could verify this 
with.  I will certainly check this.


I apologise.  I thought your post sounded chatbotty, especially at the 
end. I have to admit I only tested with punctuation, not a wide range of 
unicode characters, but heck that's what your post mentioned.


Apparently if you want to use casefold() to compare characters, you 
should call it on both, and not assume it will just give you lowercase. 
There are only a few, very few, characters where casefold() and lower() 
give different results. Rare, but the German ß is one of them.  If you 
program using a German keyboard you probably know this (I don't and didn't).


In any case, since verifying that a valid choice was made was made is 
done in the same IF statement as the check for None, it seems to be a 
moot point.


Calling lower() on None will cause an Exception so I would always 
recommend making that check on any user input.


Yes, using casefold to deal with non-ascii characters is a good point.  
In this case, we don't care what the input was if it's not one of the 
four valid choices...we just treat it as invalid and prompt the player 
to enter a valid choice.



On Thu, Dec 18, 2025, 8:21 AM Thomas Passin > wrote:


On 12/17/2025 10:43 PM, Gregg Drennan via Python-list wrote:
 > The other recommendation i would make is to shorten the response
the player
 > needs to give when choosing their option.  "R", "P", "S" is
sufficient to
 > determine the player's choice.  Making the player enter the whole
word
 > introduces opportunity for misspellings.  I would also allow the
player to
 > enter "Q" in case they decide to stop playing.  And always check
to make
 > sure the player entered something and didn't just hit enter. 
Also don't

 > use .lower() until you check to make sure you have a valid entry, the
 > player might enter a character that can't be converted to lower
case, like
 > a number or punctuation.

See, here's the problem with relying on a chatbot. Calling lower()
works
fine for a character that doesn't have a lowerclass version.  It just
returns the original.


 > while True:
 >      player_choice = input("Please enter your choice (Rock,
Paper, Scissors,
 > or Quit): "
 >      If not player_choice or player_choice[0] not in "RPSQrpsq": 
  # check

 > if None or invalid choice
 >          print("Invalid choice...")
 >      else:
 >          If player_choice[0].lower() == "q":
 >               print("Thanks for playing.  Good-bye.")
 >               break
 >          # code to score the choices, blah, blah, blah
 >
 > Good luck with your new version!
 >
 > On Mon, Dec 8, 2025, 5:37 PM John Smith via Python-list <
 > python-list@python.org > wrote:
 >
 >> 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

 >>

-- 
https://mail.python.org/mailman3//lists/python-list.python.org





--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Rock Paper Scissors Code Bug?

[MRAB]

On 19/12/2025 02:51, Thomas Passin wrote:

On 12/18/2025 1:34 PM, Gregg Drennan wrote:
No chatbot involved.  I was typing this on my phone in bed last night 
and didn't have a Python interpreter handy that I could verify this 
with.  I will certainly check this.


I apologise.  I thought your post sounded chatbotty, especially at the 
end. I have to admit I only tested with punctuation, not a wide range 
of unicode characters, but heck that's what your post mentioned.


Apparently if you want to use casefold() to compare characters, you 
should call it on both, and not assume it will just give you 
lowercase. There are only a few, very few, characters where casefold() 
and lower() give different results. Rare, but the German ß is one of 
them.  If you program using a German keyboard you probably know this 
(I don't and didn't).


Strictly speaking, you might also need to normalise the strings 
(`unicodedata.normalize`) because, for example, "é" can be 1 codepoint 
("LATIN SMALL LETTER E WITH ACUTE") or 2 codepoints ("LATIN SMALL LETTER 
E" followed by "COMBINING ACUTE ACCENT").


[snip]

--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[c186282]

On 12/18/25 13:00, Richard Kettlewell wrote:

Peter Flass  writes:

I comment *A LOT*. When I had to go back and revisit some very old
code, I wished I had commented more. I've almost never looked at a
program and said "I wish it had fewer comments."


Regrettably, I’ve encountered plenty of comments that don’t actually
reflect the code (for a variety of reasons).

If the code is wrong and the comment is right then that’s great, you
have a nice hint about how to fix the code, assuming you realize there’s
a problem at all.


  This is why you don't just blindly cut-n-paste "helpful
  code" you find on the net  :-)

  Often were several versions of it ... but nobody bothered
  to update the comments.


However if the code is right but the comment is wrong then the comment
is worse than nothing. The code would be improved by removing it
(although almost certainly improved even more by correcting it).

I’ve also encountered quite a few comments written by people who had
been instructed to add comments to under-commented code, but didn’t
really understand what they were looking at. The result generally
obscures more than it illuminates.


  If the actual code WRITER doesn't understand his/her/its
  own code ... that's worrisome.

  As I mentioned to someone else, I've got a Python function
  around somewhere with about SIX lines of actual code and
  over THIRTY lines of comment above it explaining why the
  tricky little devil works.
--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[rbowman]

On Thu, 18 Dec 2025 12:52:33 -0700, Peter Flass wrote:

> Since documentation never gets updated, if it's even created at all,
> comments are the best you can get most of the time.

We had a tech writer who was notorious for copying the programmer's fix 
notes and calling it good. It was helpful in a way since we learned to 
write better fix notes. I have worked with tech writers who could 
translate GeekSpeak into English but the good ones are scarce.
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python

[c186282]

On 12/18/25 09:40, Peter Flass wrote:

On 12/17/25 20:10, c186282 wrote:

On 12/17/25 14:17, rbowman wrote:

On Wed, 17 Dec 2025 03:11:09 -0500, c186282 wrote:

    Probably 50% of the text in my code - doesn't matter which lang 
- is

    'comments'.


I looked at some of my code and it's pretty much comment free. There 
are a

couple of .c files with comments that I reused from another project that
have somebody's comments.

I had a tendency to clone similar projects and inherit some code that I
could tweak so the final executable did one thing well. We had a 
couple of
nightmares that originally did one thing well but for the next 
project the

programmer said 'That's close to what I need. A few configuration values
here and there and it will work.'  The next time around it got some more
configuration values to do something else.  I have a Swiss Army knife I
found; it's in the junk drawer.



   Well ... I'll better understand, and be able to mod, my
   old programs better than you. I find 'excessive' commenting
   anything BUT 'excessive'. I *enjoy* writing out the meaning
   and implications of almost every step.



I comment *A LOT*. When I had to go back and revisit some very old code, 
I wished I had commented more. I've almost never looked at a program and 
said "I wish it had fewer comments."


  Ah, you live in the Real World  :-)

  Maybe SOME here have eidetic memory and have
  crystal perfect comprehension about how their
  huge 1975 COBOL opus worked ...

  A few of us need enough detailed comments to
  work us through the steps and reasoning again ...

  Hmm ... have one Python function floating around
  where the actual code is about 6 lines - but
  there's about 30 comment lines above it explaining
  how/why it works AND little helper comments after
  every line  :-)

  It was a really crushed-down way of splicing one
  directory tree into another at the exact right
  place - string+math trix - came to me while riding
  a motorcycle down an interstate highway. Good for
  backup stuff.

  BUT, needed to EXPLAIN it to myself, WHY it worked
  before I forgot, and there's ONE little gotcha that
  needed some elaboration. Did translate it into Pascal
  and 'C', but it's bigger in 'C' because of the ruder
  string-handling.

  I think the Pascal version had a couple extra
  lines to get around the gotcha. Gotta look up
  some of my old stuff again .

  Anyway, FAR easier to UNDER-comment than OVER-comment.

--
https://mail.python.org/mailman3//lists/python-list.python.org