Running life.py from the Free Python Games requires
alt-Q twice, and the GUI keeps running after System.exit.

Running life2.py, (which is my clone, and I will happily 
share it if you want a great stress tester that gobbles
100% of a CPU core for as long as you want,) doesn't
respond to alt-Q and requires a force quit.

Please create a small program that reproduces the problem. You should strip out everything that isn't needed. There's no way we can guess the problem without seeing the code.

send to you?

.

> On Nov 10, 2018, at 14:41, Eric V. Smith <report@bugs.python.org> wrote:
> 
> 
> Eric V. Smith <eric@trueblade.com> added the comment:
> 
> Please create a small program that reproduces the problem. You should strip out everything that isn't needed. There's no way we can guess the problem without seeing the code.
> 
> ----------
> nosy: +eric.smith
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue35211>
> _______________________________________

Here is the source, just simply Turtles...

https://github.com/grantjenks/free-python-games <https://github.com/grantjenks/free-python-games>

Attached life.py and life2.py

I don't know what cause the problem. I suspect
there is more of a problem than just alt-Q 

> On Nov 10, 2018, at 15:08, Bob Moth <bmoth@icloud.com> wrote:
> 
> send to you?
> 
> .
> 
> 
>> On Nov 10, 2018, at 14:41, Eric V. Smith <report@bugs.python.org> wrote:
>> 
>> 
>> Eric V. Smith <eric@trueblade.com> added the comment:
>> 
>> Please create a small program that reproduces the problem. You should strip out everything that isn't needed. There's no way we can guess the problem without seeing the code.
>> 
>> ----------
>> nosy: +eric.smith
>> 
>> _______________________________________
>> Python tracker <report@bugs.python.org>
>> <https://bugs.python.org/issue35211>
>> _______________________________________

Please quote only the relevant parts of the original email while replying from email since it duplicates the content and makes your reply hard to read. Also I think the bug tracker doesn't support attachments from email so please attach them here from the UI.

Thanks

looking at the screen snapshot 'life.py alt-q once.jpg' -- the
turtle code keeps running even though System.exit has been completed,
and notice the traceback display in the shell caused by the alt-Q.

a second press of alt-Q terminates the shell and the turtle code.

I rewrote the life2.py using a class in order to eliminate global
variable declarations, and some other things, such as bringing
freegames.util#square() instream to be independent of freegames,
carefully accounting for every pixel output, etc. 

Works a little better but alt-Q has no effect whatsoever and 
it is necessary to Force Quit (mac terminology) or to switch to
the shell window and quit that first. 

Once this bug is fixed, wherever that might be, you might look into
using mylife.py as an turtle example -- with whatever changes you
like -- because it is interesting to use and it exercises the turtle
and tkinter very strenuously. (just leave my name off it...)

Thanks for your hard work.

There seem to be at least two problems here.

One, you say that running the unmodified life.py requires two Quit keyboard shortcuts (usually CMD-Q).  From the shell output you give, that problem is most likely due to the use of -i with python:

'/usr/local/bin/python3' -d -i  '/Users/user2/Downloads/life.py'

-i means that the interpreter should enter its interactive mode after the script exists.  With tkinter-based graphics apps like turtle, you probably do not want to do that as it will inhibit the normal Tk shutdown of the app.

https://docs.python.org/3/using/cmdline.html#cmdoption-i

Without -i, the unmodified life.py terminates fine for me.

Secondly, your modified life2.py does not terminate with a Quit even when running without -i.  (Note that it *does* quit if you select Close from the applications's File menu or if you click on the red close button on the open window.)  From a quick comparison of the unmodified Pygames life.py versus your modified life2.py version, it seems you have changed the order of operations in such a way that the sequence of turtle operations has changed and likely the underlying tkinter event loop is not being called properly thus either ignoring or suppressing the effect of the Quit keyboard shortcut.  Suggest you revise your program to follow the sequence of turtle calls that the original does and be careful if you wish to introduce changes in that.  If you do find what appears to be a bug in turtle or elsewhere in Python, feel free to re-open this with an example and an explanation.  Good luck!

hi - i do not use ‘i’...just drag to
launcher...

and sequence of commands is
a good tip but smells like some
kind of bug to me if the commands
follow written rules. 

thanks for looking -

> 
>

Alas, the Launcher app can be problematic and doesn't get much love.  If you open the Launcher app's Preferences, you'll probably see that the "Interactive mode after acript" option is ticked.  Either unselect it or, if you feel comfortable using a Terminal window, just launch Python directly from a terminal shell:

python3 ~/Downloads/life.py

OK, thanks. The generated launcher shell command generated
includes '-d -i' flags...

so I tried running without those and voila, life.py terminates
normally. Yay. :-)

2nd, I reviewed the order of commands and I saw that
life2.py and mylife.py (the +1 version) did not have a
'done()' or 'mainloop()' as the last line of the program.
I added those, to no effect. Does nothing I can see.
The other turtle commands appear to me to be "ok",
given that the algorithm is different. For example,
clear() used to be done every loop -- to erase the
turtle tracks -- but that is now done just at the start
because only changed cells are updated, and 
new life/new dead are just updated. 

So, 50% solved. It is an interesting problem because
*my* code seems to be working and *python* does
not appear to be working right. 

Thanks for the help. I might try pygame for a gui
instead...this is getting weird.

You may might try asking on the freegames issue tracker or, better, on a more general support forum like Stackoverflow or Python-list. Because of the volume of issues reported here (and we are all volunteers), we really can't spend a lot of time helping debug individual programs.  Sorry!

https://www.python.org/about/help/
https://stackoverflow.com
https://mail.python.org/mailman/listinfo/python-list

Thanks. I appreciate the time and effort. 

But I disagree with the characterization of
this problem as 'Resolved'. Turtle is
supposed to be simple enough for children yet 
no one can fix simple turtle code and stop
an endless loop? 

What is the rush to close issues?

Sorry, there isn't a particular rush to close issues as some of them stay open for years. And that's not good for anyone.  "resolved" on the issue tracking does not necessarily mean a problem is resolved to everyone's satisfaction, it just means that it is no longer active in our backlog (which currently numbers over 6000).  I don't claim to be a turtle expert but the bit of time I spent looking into this issue and my years of triaging Python issues lead me to conclude this is almost certainly a problem with your program and not with Python itself.  We could leave it open but the chances that any other core developer would spend time looking further at it are slim.  That's why I suggested asking on user forums where you are much more likely to get useful and more rapid feedback.  And as I earlier suggested, if it *does* turn out to be a demonstrable problem with turtle or elsewhere in Python, you can easily reopen the issue and we can go from there. I hope that makes some sense!

And, by the way, if it turns out that the problem could have been avoided by better documentation, another option is to re-open the issue with suggested doc changes.  Patches welcome!

Apparently the draw() function must call itself via ontimer.

That is not in the docs. But 56 variations later...I just copied
Grant Jenks. Apparently he knows what's what.

And done() must be the last line.

If first omitted, only one draw loop executed, but it quits itself.
With done(), it loops via ontimer().

<pre><code>
def draw():
    myDrawCells()
    update()
    myComputeOneStep()
    ontimer(draw, LOOP_TIMER)
setup(BOARD_SIDE, BOARD_SIDE, None, None)
hideturtle()
tracer(False)
clear()
myInitialize()
draw()
done()
</code></pre>

So now alt-Q works in life2DEBUG.py. attached.

Here is a debugged version of mylife, which cloned life2.py to
use a class for turtle-ing. Note the difficulties at the
end of the code -- ontimer(fun, delay) calls for a zero arg
function, so draw() cannot be inside the class. Greatly annoying.
But now we know.

mylife3.py is a suitable example, I think. If cleaned up to
standards. I noticed there is a curses life.py example, which
is very interesting and fun, but mylife3.py is more fun...and
it has 2 different board topologies! And
it would make a very good test program. Note that it sets
the random seed which establishes the Cell patterns, so a
test ought to be repeatable, at least on a given machine.
I plan to use mylife3.py instead of a space heater this winter :)