Mailman 3 December 1997 - Pythonmac-SIG

Graphing capablility in Mac Python
by Anthony M. Ingraldi Aug. 23, 1998

Aug. 23, 1998

Hello, Is there a module available that will provide routines for creating simple line graphs and scatter plots? I was thinking of using AppleEvents to send data to KaleidaGraph or some other package but that seems sluggish. Another alternative would be to use a Canvas widget from Tk. I would prefer to use a module designed specifically for plotting rather than writing one via Tkinter. -- Tony Ingraldi | e-mail: A.M.INGRALDI(a)LaRC.NASA.GOV NASA Langley Research Center | Mail Stop 267 | Phone : (757) 864-3039 Hampton, VA 23681-0001 | Fax : (757) 864-7892 _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

3 3

Tkinter Menu Problem with 1.5a4
by Zachary_Roadhouse＠brown.edu Dec. 30, 1997

Dec. 30, 1997

I have Tcl/Tk 8.0p2 and Python 1.5a4 and am experiencing the following problem. None of my menu items appear to work. I opened up the wish application and tested menus there and everything worked fine. However, when I try the new style menu declaration using Tkinter, no menu items work. Help! --Zack /--------------------------------------------------------------------- Zachary F. Roadhouse Home: (401)453-9943 Box 220, Brown University, Providence, RI 02912 Work: (401)863-2177 E-MAIL: Zachary_Roadhouse(a)brown.edu WWW: http://www.techhouse.brown.edu/~zack/ _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

Re: [PYTHONMAC-SIG] Organization of toolbox modules and such
by Jack Jansen Dec. 23, 1997

Dec. 23, 1997

Recently, Jack Jansen <Jack.Jansen(a)cwi.nl> said: > With the new import semantics I am tempted to restructure the toolbox > interfaces, but this will be an incompatible change. Well, I got two negative replies from Just and Guido, who felt that the incompatabilities introduced outweigh any positive effects, and only one positive reply. I'll assume the whole idea was either stupid or it's time has not yet come, and 1.5b2 will be distributed with the folder structure as it was before, only with Mac:Lib:toolbox and scripting renamed to lib-toolbox and lib-scripting. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0

Organization of toolbox modules and such
by Jack Jansen Dec. 17, 1997

Dec. 17, 1997

With the new import semantics I am tempted to restructure the toolbox interfaces, but this will be an incompatible change. I would like some feedback (and reasonably quickly, because this will have to be in 1.5b2 to be tested before a final 1.5 release). I have the following three possibilities: 1) Rename Mac:toolbox and Mac:scripting to Mac:lib-toolbox and Mac:lib-scripting, modify the initial sys.path and be done with it. 2) Remove Mac:toolbox and Mac:scripting from sys.path. Rename the dynamically loaded toolbox interfaces to have an _ prepended to their names, and create new modules like Mac:toolbox:Win.py which import * from _Win and include all the constants that are currently in Window.py. (For compatability Window.py could import * from Win). 3) Same as (2), but also rename Mac:toolbox and Mac:scripting to Mac:macos and Mac:macscript. Rename the builtin module MacOS to macpython (or possibly macsys). (1) doesn't really change anything (except bring the names in line with Guido's new scheme). (2) means people will have to modify their programs, where they have "import Win" currently this will have to change to "from toolbox import Win". My preference would be *not* to do the compatability measure of having Window.py mirror Win.py, because people will have to go into their source to modify it anyway so they might as well do it all at once, but this is open to discussion. (3) is the most incompatible solution, but does leave us with a structure that I find very pleasing. "from macos import Win" is self-documenting also to non-mac programmers. Also, the name of the module MacOS has been bothering me for years, being both wrong and capitalised. Wrong because the functionality is similar to "sys", python-interpreter settings and such, but mac-specific, and the capitalised bit speaks for itself. macos.__init__.py would (if possible) check for being imported as MacOS and scream loudly in that case. Solutions 2 and 3 have the added advantage of shortening sys.path, which is also rather desirable given the already too long import times on the mac. Oh yes, the new name for "scripting" is also open to discussion. "osasuite" or something similar might be a better choice than "macscripting" (since the folder contains suites only), and the latter name might lead people to expect that AE can also be found there. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

3 2

CGI error condition
by Tasselli Marco Dec. 4, 1997

Dec. 4, 1997

Hi, I have a problem dealing with CGI crashes. When the bundled applet used for CGI (compiled with mkapplet) encounter an error condition (outside a try/except clause), it stop executing leaving the stdout window open with a <<terminated>> title. The problem is that there is no way to quit the program, in order to correct it, other than using a command-option-escape sequence and, of course, this is not possible at all if you use Timbuktu to control a remote server. In the case of an unattended remote server this is very dangerous. Is there any way to solve this problem? Or, better yet, any way to directly reload a corrected module in the running CGI application? best regards Tasselli Marco _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

2 1

Re: [PYTHONMAC-SIG] CGI error condition
by Jack Jansen Dec. 4, 1997

Dec. 4, 1997

Recently, Tasselli Marco <ita.mis(a)euro.apple.com> said: > When the bundled applet used for CGI (compiled with mkapplet) encounter > an error condition (outside a try/except clause), it stop executing > leaving the stdout window open with a <<terminated>> title. > The problem is that there is no way to quit the program, in order to > correct it, other than using a command-option-escape sequence and, of > course, this is not possible at all if you use Timbuktu to control a > remote server. Try clearing the "keep console open on normal/error exit" by dropping the applet on editpythonprefs. On a side note: since you seem to be actually *using* the CGI stuff: do you think you could provide me with some reasonably easy to understand (and generally useable) example CGI scripts? I created the framework and did some cursory tests, but never got around to actually exercising the stuff... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig(a)python.org administrivia to: pythonmac-sig-request(a)python.org _______________

1 0