🌐 Mailman 3 February 1996 - Pythonmac-SIG - python.org

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. 5, 1996

Feb. 5, 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. 5, 1996

Feb. 5, 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