The initial graphics program in Python giving an error "from the stack space"

Question

I am currently learning Python using Zelle's introductory text, and I'm trying to recreate one example program that uses the attached graphics.py file. Since I am using Python 3.1 and the text was written for 2.x, I am using the GraphicsPy3.py file found at http://mcsp.wartburg.edu/zelle/python and rename it to my computer.

A file called futval_graph.py looks like this:

from graphics import * def main(): print("This program plots the growth of a 10-year investment.") principal = eval(input("Enter the initial principal: ")) apr = eval(input("Enter the annualized interest rate: ")) win = GraphWin("Investment Grown Chart", 320, 420) win.setBackground("white") Text(Point(20, 230), ' 0.0K').draw(win) Text(Point(20, 180), ' 2.5K').draw(win) Text(Point(20, 130), ' 5.0K').draw(win) Text(Point(20, 80), ' 7.5K').draw(win) Text(Point(20, 30), '10.0K').draw(win) # Rest of code is here but I've commented it out to isolate the problem. main() 

When I run "import futval_graph" in a new IDLE session, the program simply starts and then freezes after entering "apr" without opening a new graphics window. When I run the program from the command line, I get the following result:

C: \ Python31> futval_graph.py
This program provides for the growth of 10-year investment.
Enter the initial principle: error in the background error handler:
from stack space (infinite loop?)
when executing ":: tcl :: Bgerror {from stack space (endless loop?)} {-code 1-level 0 -errorco de NONE -errorinfo {from stack space (endless loop?)
while execu ... "

Particularly frustrating is the fact that this series of commands works when entering IDLE in a new session. And then when running 'import futval_graph' from IDLE after all the commands have been run independently, futval_graph works correctly.

So my question is: how can I get futval_graph.py to work fine both from the command line and from IDLE? Sorry if my explanation of the problem is a bit scattered. Let me know if any additional information helps clarify.

Answer 1

The problem seems to be related to the graphics.py version of Python 3.

I downloaded the Python 3 version, renamed it graphics.py, then did the following.

 PS C:\Users\jaraco\Desktop> python Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from graphics import * >>> dir() ['BAD_OPTION', 'Circle', 'DEAD_THREAD', 'DEFAULT_CONFIG', 'Entry', 'GraphWin', 'GraphicsError', 'GraphicsObject', 'Image', 'Line', 'OBJ_ALREADY_DRAWN', 'Oval', 'Pixmap', 'Point', 'Polygon', 'Queue', 'Rectangle', 'Text', 'Transform', 'UNSUPPORTED_METHOD', '\_\_builtins\_\_', '\_\_doc\_\_', '\_\_name\_\_', '\_\_package\_\_', 'atexit', 'color_rgb', 'copy', 'os', 'sys', 'test', 'time', 'tk'] >>> error in background error handler: out of stack space (infinite loop?) while executing "::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1 -level 0 -errorcode NONE -errorinfo {out of stack space (infinite loop?) while execu..." 

As you can see, I get the same error, and I didn’t even do anything in the module. It seems that the problem is with the library itself, and not with what you are doing in your code.

I will tell the author about this, as he suggests.

I found that I did not receive an error if I just imported a graphics module.

 >>> import graphics >>> dir(graphics) 

I found that if I did this with your code and then changed the GraphWin links to graphics.GraphWin, Text to graphics.Text and Point to graphics.Point, the problem seemed to disappear and I could run it from the command line.

 import graphics def main(): print("This program plots the growth of a 10-year investment.") principal = eval(input("Enter the initial principal: ")) apr = eval(input("Enter the annualized interest rate: ")) win = graphics.GraphWin("Investment Grown Chart", 320, 420) win.setBackground("white") graphics.Text(graphics.Point(20, 230), ' 0.0K').draw(win) graphics.Text(graphics.Point(20, 180), ' 2.5K').draw(win) graphics.Text(graphics.Point(20, 130), ' 5.0K').draw(win) graphics.Text(graphics.Point(20, 80), ' 7.5K').draw(win) graphics.Text(graphics.Point(20, 30), '10.0K').draw(win) # Rest of code is here but I've commented it out to isolate the problem. main() 

Why should it be? It should not. It seems that the graphics.py module has some side effect that is not working properly.

I suspect that you will not encounter these errors in Python 2.x.

Answer 2

your code has problems with buil-in input when it called with a non-empty string as an argument. I suspect this may have something to do with the flow setting that graphics does.

If you make Tkinter widgets to read these inputs, maybe this will solve your problem.

To be honest, when you load graphicsPy3.py , it says:

Graphics library ported to Python 3.x. Still experimental, please report any problems.

therefore, I suggest that you better follow this recommendation.

Answer 3

After some further research, it seems that a call to the input () method really affects the triggering of unwanted behavior.

I rewrote the program so as not to import the graphics module until the calls to input () are complete. In this case, I could not reproduce the error, and the code seemed to behave normally even when launched from the command line. I was able to get the parameters from the user, then he will start to draw a graph (although with the sample code only very little was done before the application was closed). Perhaps this method is the right solution for your problem.

The main problem seems to be related to how the tkinter module is initialized in a separate thread and some unwanted interactions between threads. I assume that the input () method, when launched from the command line, either blocks the resource or otherwise invokes a behavior that causes the Tk thread to end in an infinite loop.

By performing some searches on the Internet, I see that other users received the same error, but for different reasons. Some got it when tkinter was built without thread support, but I don't think this applies here.