🌐 Mailman 3 - Pythonmac-SIG - python.org

Mac Python with Tk -- early beta
by Guido van Rossum Feb. 18, 1996

Feb. 18, 1996

I have managed to build a 68K Python with Tk that can run Grail. Download it from ftp://ftp.python.org/pub/mac/beta/, files python68Kgusitk.sit.hqx, README-tk, and Tkinter.py. Here's the README-tk file: Mac Python with Tk -- early beta ================================ The file python68Kgusitk.sit.hqx is a Binhexed, Stuffed Macintosh 68K Python binary that supports John Ousterhout's Tk toolkit. It is just the application binary -- you'll have to get one of the other distributions (1.3 or 1.3.1) to get the Python library code; EXCEPT there's a new version of Tkinter.py, which you *have* to use, sitting (as a separate text file) in this directory. I assume you are already familiar with running Python on your Mac -- if you aren't, you should definitely first download and try the 1.3 or 1.3.1 releases for Mac (this directory or one up). If you can't run the EditPythonPrefs.py script, don't even think about running my version. (Hint: EditPythonPrefs.py and EditPythonPrefs.rsrc must be in the same directory.) There's no PPC binary, because I haven't been able to build and test one one yet. I hope I'll get to that within a few days. In the mean time, the 68K binary *should* work on a PPC in emulation mode, but you can't use Jack's nift applets or synamically loaded extension modules. There are no source patches or project files yet, because I haven't sorted out exactly what I did to make it work. In a while, I hope. This uses the latest Tk beta release: Tcl 7.5b1 and Tk 4.1b1. This is the first version I could get to work with Python on the Mac. I didn't have to make any changes to the Tcl/Tk sources. There are plenty of little bugs in the Tk beta; the most annoying is that it will crash with a bus error if it tries to use font metrics before an "update" or "update idletasks" has been done. For the time being, I make this call in Tkinter.py as soon as the root window is created. This means that you will see an an empty root window when your app comes up, until your app withdraws it or adds widgets and calls update() or mainloop(). This version also uses the GUSI library (Grand Unified Socket Interface, by Matthias Neeracher). This means the full socket and select modules are available. it does mean that all calls to socket.makefile() must be patched to use 'rb' or 'wb' as the file mode (this affects modules like ftplib, httplib, maybe urllib). When using async I/O (select, Tk's createfilehandler()) intensively, I noticed some weird effects where Python, Tk, GUSI and the SIOUX console window seem to be competing for events. I got better results by disabling Python's own event handling with the call MacOS.EnableAppswitch(-1) -- I also added this to Tkinter.py. This means you can't interrupt the Python code with Command-period. With these provisions, it *does* run Grail (a patched version, not yet distributed). it's a memory hog (notice the preferred memory usage of 6Meg). It is slow, though part of that is probably due to my 14k4 modem. It takes about 30 seconds for Grail to start up when all its .pyc files are up-to-date (I ran Tools/scripts/compileall.py in the Grail source directory to do this). Some smaller applets work -- I had trouble with Life and Daleks though. --Guido van Rossum <guido(a)CNRI.Reston.VA.US> URL: <http://www.python.org/~guido/> ================= 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] Backward compatability
by guzdial＠cc.gatech.edu Feb. 8, 1996

Feb. 8, 1996

I vote for compatibility. I don't use these additional features, but I'd like to be able to run some of the other Python code I see/hear about. Mark >Guido suggested (in a private message) to remove the '*' option (open >the resource fork) from open() and replace it by a method >MacOS.openrf() that opens the resource fork. > >Also, he suggested doing away with the extra fields returned by >os.stat() on the mac (the resource fork size, creator and type), to >make stat() compatible across all platforms. > >Will people be seriously bothered by these incompatible changes? > >Also, there are three modules I would like to get rid of, in favour of >bgen-generated modules with the same functionality (but probably a >completely different interface), and again I would like to hear >whether this would hurt people. I want to replace the ctb and speech >interfaces by bgen-generated ones. Also, I want to get rid of >mactcp/macdnr in favor of a socket-like interface. For the latter: if >I do this, are there people who still want the low-level mactcp >interface (or, alternatively, an OpenTransport interface)? > >If you use these interfaces: please reply. Failure to do so will >strengthen me in my conviction that I can toss these without seriously >inconveniencing people... >-- >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 >================= -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html ================= 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] Wanted: Python w/GUSI testers...
by Jack Jansen Feb. 7, 1996

Feb. 7, 1996

Recently, guzdial(a)cc.gatech.edu (Mark Guzdial) said: > I was just playing with them some -- it's really exciting! Here are some > things that I noted: > > (1) I may be using the urllib wrong, but I couldn't get readlines() to work > on the object that urlopen returned > [example deleted] > (2) ftplib worked strange. [example deleted] these two are examples of the same problem: socket.makefile() opens a socket in ascii-mode, not binary mode. The workaround is simple: find all calls to makefile("r") and makefile("w") in the Lib folder (and your own programs) and change them to makefile("rb") and makefile("wb"). Mark has also experienced crashes upon exiting PythonGUSI, and so did I. For now, the workaround appears to be to close all your sockets before exiting. I am suspecting Open Transport of this, so I would be interested in people reporting whether MacTCP machines also crash if they have sockets open upon exiting python. -- 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

Backward compatability
by Jack Jansen Feb. 7, 1996

Feb. 7, 1996

Guido suggested (in a private message) to remove the '*' option (open the resource fork) from open() and replace it by a method MacOS.openrf() that opens the resource fork. Also, he suggested doing away with the extra fields returned by os.stat() on the mac (the resource fork size, creator and type), to make stat() compatible across all platforms. Will people be seriously bothered by these incompatible changes? Also, there are three modules I would like to get rid of, in favour of bgen-generated modules with the same functionality (but probably a completely different interface), and again I would like to hear whether this would hurt people. I want to replace the ctb and speech interfaces by bgen-generated ones. Also, I want to get rid of mactcp/macdnr in favor of a socket-like interface. For the latter: if I do this, are there people who still want the low-level mactcp interface (or, alternatively, an OpenTransport interface)? If you use these interfaces: please reply. Failure to do so will strengthen me in my conviction that I can toss these without seriously inconveniencing people... -- 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

Wanted: Python w/GUSI testers...
by Jack Jansen Feb. 6, 1996

Feb. 6, 1996

I've created Python interpreters that use GUSI, the Grand Unified Socket Interface for their I/O and I would like it very much if some people downloaded these and tested them. Note that the executables are only *very* lightly tested, so expect all sorts of things to fail. GUSI is a unix-like I/O system for mac programs, allowing the use of sockets, select, etc. I've finally been convinced that using GUSI in python is also the only way to get Tcl/Tk to work, and it appears that GUSI may also provide the functionality needed to implement threads on the mac. This release is done to get some idea of where the use of GUSI will mess up the expectancies of the rest of python. You can obtain a 68K or PPC executable from <ftp://ftp.cwi.nl/pub/jack/python/mac/withgusi/>. Note that these files are interpreters only, you're expected to have "the rest" of the python distribution installed already. Also, don't throw away your normal interpreter: I'm pretty sure that these interpreters will have some serious shortcomings. Here are the main differences with a normal 1.3.1 interpreter: - No stdwin, img, mactcp modules - Unix-like socket and select modules - os.stat() returns same info as on unix (no type/creator/resource-size) - no resource-fork opening with open('file', '*r') - (PPC only) The interpreter is statically linked and does not use PythonCore. - (PPC only) Dynamic modules are incompatible (maybe you should remove PlugIns from your sys.path, to be sure). -- 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

Re: [PYTHONMAC-SIG] WPY for the mac?
by jps＠tfs.com Feb. 6, 1996

Feb. 6, 1996

: Is anyone here familiar with WPY? How much work would it be to port : it [to the Mac], and is it worth the trouble (i.e. how good is it)? I *would* like to see wpy on the Mac. There are several desirable Python applications that I haven't ported to the Mac because it suffers from being out of the mainstream of Python GUI options. I've only played with wpy on Solaris, where it was fine for my modest needs. I did see one problem where it would block on input while holding the Python interpreter lock. This blocked the other threads of my application. The fix had to be made within a library routine (whose identity I have forgotten). -jeff stearns P.S. The headers on Jack's message say: To: pythonmac-sig(a)python.org From: Jack Jansen <Jack.Jansen(a)cwi.nl> Thus replies will go to Jack, not to this list. Is this the intended behavior? ================= 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

Tk7.5b1 is out, anyone looking at it?
by Jack Jansen Feb. 6, 1996

Feb. 6, 1996

The next release of Tcl/Tk (beta 1) is out, and from the blurb it looks as though it may be easier to integrate in Python: one of the main differences with alfa 2 is a complete rewrite of the I/O subsystem to be more portable to different platforms. Is anyone going to look into putting this beast into Python, or should I pull the stuff over and have a look (sigh)? -- 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

WPY for the mac?
by Jack Jansen Feb. 6, 1996

Feb. 6, 1996

Tonight I was wondering, looking at the list of systems supported by WPY, whether it would be useful to have a mac port of wpy, and how much work it would be. Lo and behold: 10 seconds later I see another posting of someone asking for a WPY mac port. Is anyone here familiar with WPY? How much work would it be to port it, and is it worth the trouble (i.e. how good is it)? -- 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

What are people doing with MacPython
by powers＠petroglyph.com Jan. 31, 1996

Jan. 31, 1996

Evaluating it :) More to the point, evaluating whether to move ahead with extending the Mac version or the Windows version for use in CD-ROM products. About a year and a half ago I extended Python on an SGI with objects for full screen video playback, sega game controller events, and multiple bitmap animation layers. We then used it for a Pilot of an animated Interactive TV channel for kids. Some of this work can be seen on my web site (at least the visuals) under the tag of the company, daVinci Time and Space [http://www.petroglyph.com]. Earlier I worked on the ill-fated but forward thinking ScriptX from Kaleida Labs. In fact, I just received version 1.5 which they nudged out the door before being sucked back into Apple. Someone at Kaleida should have made an early decision to use Python instead. Now I am moving into the development of PC pased entertainment products. This means extending the language to include the game sdks on Mac or Windows 95. Does anyone have experience on both systems with Python?? Jack, your multimedia work sounds interesting? Can you say more? Michael Petroglyph 940 Scott St Palo Alto, CA 94301 www.petroglyph.com "Incarnation: bodying forth. Is this not our whole concern? The bodying forth of our sense of life? Is this not a sense fully as actual as our sense of touch...That is what form is: the bodying forth. The bodying forth of the living vessel in the shapes of clay." M.C. Richards ================= 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] Some ideas for Mac Python
by Jack Jansen Jan. 31, 1996

Jan. 31, 1996

This is going to be a long reply to a long message (especially since it tackles almost all of the issues in the charter:-). Maybe we should split the discussion into multiple parts? Non-C-hackers: please bear with me, there's some design issues in here as well that I would welcome discussion on. Recently, Guido van Rossum <guido(a)CNRI.Reston.VA.US> said: > Here are some areas where I think MacPython can use some improvement. > > 1) CFM-68K support. This is shared libraries, PPC style, for the > 68K. Guido: the miniPythonCFM68K project in the source tree appeared to work under CW7.5 (with the exception of the math module), so that would probably be a good starting point. Others: if anyone is interested in looking into cfm68k: drop me a note and I'll put the project up for ftp. > 2) GUSI support. Yes, this would definitely be nice, especially since it would probably make the MacTk integration quite a bit easier. The #include <GUSI.h> isn't a problem: put it in the prefix file (mwerks_whatever_config.h). If you (or anyone else) is going to look into it: make sure you check that os.stat() still works as expected afterwards. I had problems with GUSI stat(). > 3) Tk. Definitely! One serious problem with Tk, though, is that it expects malloc to succeed. Always. There is no code whatsoever that checks return values, so tkpython programs running out of memory will have extremely rude things done to them (along the lines of "nobody expects the spanish inquisition":-). > 4) Configure some Mac specific hacks dynamically (at run-time) instead > of through #ifdefs. Yes. I've already created a Python library (similar to PythonCore but as a static library) that I used in my first experimentations with Netscape extensions. Hmm, speaking of that: is anyone willing to take over the work on a python-interpreter netscape extension? > a) Program argument processing. This is fairly simple to fix, by moving the init_mac_stuff() routine to another place and using a different main program that doesn't call the argc/argv emulation routine. There's a related problem, though: the Py_Exit() call in core-python is better split in two: Py_JustBeforeExit() and Py_Exit(). In some cases (such as a netscape extension) you want to do all of the exit processing *except* exiting. > b) Event checking. There is some code that normally checks for > Command-period (turning it into a KeyboardInterrupt exception) > but which can be disabled; it can optionally also check for > other events, passing them to SIOUX (the CodeWarrior stdio > window) or stdwin or elsewhere. I think this should probably be > done in such a way that even in order to enable Command-period > checking the main program would have to register some kind of > callback (even though the callback function could be part of the > standard library). (Of course this interface should still be > accessible from Python code, so Framework.py can take care of > its own needs.) Hmm, not sure I like this one. The callback function is a good idea, I think, but only for programs that know about it. It think that the default behaviour should be as it currently is: if the python program doesn't make any "funny" calls (like the misnamed MacOS.EnableAppswitch, which disables all python's event processing) it should work as it currently does. The issue is, however, tied to the next one. > c) Standard I/O window. I would like to make it possible that an > embedding app can completely disable to console window > (essentially all writes to the C level stdout/stderr would yield > write errors (or be ignored?) and all reads from stdin would > raise EOFError). The app can them use some Python code that > substitutes something else for sys.stdout etc. so that it is > redirected to a window that it manages for itself. This would > be useful for Tk, for instance (Tk dies when you click in the > SIOUX window, but it would be easy to connect the console to a > Tk text widget). Definitely agreed. Here's an idea: - Someone writes a console output window driver (in C). This is something that has an interface similar to the SIOUX low-level interface (writecharstoconsole(), readcharsfromconsole(), etc) but does not ever ever ever look at the event queue itself. CW7 SIOUX was advertised as doing this, but messed some things up (cut/paste handling). Also, the names should, unfortunately, be different so we can't use sioux. Finally, since the driver should never ever read an event the should be a callback (to call from readcharsfromconsole()) which is called until enough events have been passed to handleoneevent() to satisfy the outstanding request. - We create a builtin module that allows access to the functionality of the above. - We write routines writecharstoconsole(), etc. that will call the appropriate python methods of a 'sioux object'. The initial sioux object will, of course, be the thing created previously, so when you start a normal python interpreter everything behaves as it does now. However, there's also an interface that allows a python program (or a C program, if python is embedded in another application) to divert all sioux I/O to your own object. You could even implement your own object using a sioux object (or multiple sioux objects if the implementation in the first step allows it, which would be a big benefit for someone implementing a python IDE). - We redo the event loop (which is used by default, and entered once every umpteen python machine instructions, or when we're waiting for user input) to allow modules (such as the sioux module, or framework, or stdwin) to subscribe to the event loop. When there's an event available everyone subscribed gets a chance to look at it, with the return specifying whether the event has been handled or not. The sioux module will subscribe (if it is active), and also two other modules, one that handles command-dot and one that handle "the outside world", clicks in the desktop, that sort of thing. There's one potential problem: the menu bar. One possibility would be to do a generalized menu interface, but a better (albeit slightly clumsier) one would be to have the event loop peek at the current top window and install the correct menu. This will have the advantage of working better when embedding python. Of course, you can still turn off the event loop and handle all events by yourself, possibly passing events to this code with MacOS.HandleEvent. So what does all this buy us? The main thing is that, given a scriptable external editor, a minimal IDE is now simple. Create a Python program that sets up a few menus and starts the interpreter inside a try/except clause. Upon an exception you point the editor at the offending line with an appleevent. Similarly, if you get a "run script" appleevent you open a window and run the script. Thinking of the rest of the possibilities is left as an exercise to the reader:-) > 5) Preferences. Still not as smooth as could be. I guess that the > run-time options that can currently only be set by hitting Option > while Python is being launched should also be taken care of by a > preferences panel. Definitely, the defaults for the option-launch options should be settable from EditPythonPrefs. Actually, I'm still undecided about the EditPythonPrefs program. Initially the implementation of setting the preference file was completely in C in the interpreter, but I felt that that was a bit silly, so I removed it and created EditPythonPrefs. What do people think: is a separate preference-setting program a good idea or should the code move back into the interpreter? -- 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