Mailman 3 April 2001 - Pythonmac-SIG

Building mxDateTime for Python 2.0
by Vincent Marchetti Sept. 24, 2001

Sept. 24, 2001

I am trying to re-compile the mxDateTime shared library to let me use DateTime in Python 2.0 -- the shared library provided throws exception on import about using the wrong version. I have never compiled any type of shared library before, so girding my loins and firing up CW 5 I set up a shared library project and: 1. included the mxDateTime.c code 2. included stub libraries PythonCore and MSL ShLibRuntime.Lib Result: -- Link failure, could not find function 'floor' I knew this is a standard C function, so I threw the stub MathLib into the pot and cooked. Got a bunch of warnings about duplicate definitions of math functions (in PythonCore and MathLib). Decided to ignore warnings. Successfully made the shared library, successfully imported DateTime into Python 2.0 (actually 2.0b1). However, the test script for mxDateTime failed an assertion. Basically, a function DateTimeFromTicks, which uses the floor function, fails to give predicted results. My question: Am I including the correct library in my project to get the "right" version of floor? Thanks, Vince Marchetti

4 3

Import hook to do end-of-line conversion?
by Jack Jansen May 24, 2001

May 24, 2001

[Oops, try again] There's talk on the PythonMac-SIG to create an import hook that would read modules with either \r, \n or \r\n newlines and convert them to the local convention before feeding them to the rest of the import machinery. The reason this has become interesting is the mixed unixness/macness of MacOSX, where such an import hook could be used to share a Python tree between MacPython and bsd-Python. They would only need a different site.py (probably), living somehwere near the head of sys.path, that would be in local end of line convention and enable the hook. However, it seem that such a module would have a much more general scope, for instance if you're accessing samba partitions from windows, or other foreign file systems, etc. Does this sound like a good idea? And (even better:-) has anyone done this already? Would it be of enough interest to include it in the core Lib? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

17 57

MemoryError Problem
by Richard Gordon May 2, 2001

May 2, 2001

I finally got around to downloading the source code for "Python & Tkinter Programming" and observed that a) there are a lot of files and b) the line endings are \r\n. I have usually just done a batch Find/Replace in BBEdit to deal with things like this, but decided that it was time to sit down and write a python script to change the line endings to \r, so off we go. The code is below and it works pretty good thru about half of the files, then dies with a memory error (using Python 2.1b2). I've tried jacking the interpreter's memory up to 48000 but it still tipped over at about the same point. I couldn't tell you exactly how many files are involved, but it's a lot and most are small. There is a chapter-based directory structure, but it isn't terribly deep and I don't think that this is some kind of recursion limit thing. So does anyone see something here that may be causing the problem? I'm a little suspicious about .xreadlines() but it's really fast and I'd like to use it if possible. Any help will be appreciated. As an aside, I had originally planned to modify the files in place by opening each in read mode, doing xreadlines, then opening it again in write mode and writing the processed lines back into the file. I didn't get any errors when I tried this, but nothing actually was written into the file either, so I wound up renaming the originals and writing a new file out under the old name. This is not an optimal solution and I'd be interested in any suggestions that you may have about editing files in place. Thanks. #code starts here import sys, os from time import time start = time() fcount = 0 def strip(f): global fcount infh = open(f, 'rb').xreadlines() os.rename(f, f +'~') outfh = open(f, 'wb') for line in infh: outfh.write(line.replace('\n','')) outfh.close() fcount =+ 1 return def run(d): names = os.listdir(d) for name in names: f = d + ':' + name if os.path.isfile(f): if os.path.splitext(f)[1]=='.py': strip(f) else: run(f) run('Conkie:python_scripts:PTP') stop = time() elapsed = stop-start print "Changed %d files in %d seconds" % (fcount, elapsed) #eof Richard Gordon -------------------- Gordon Design Web Design/Database Development http://www.richardgordon.net

2 3

Have to run ConfigurePythonCarbon after each reboot
by Kolya April 30, 2001

April 30, 2001

I am new to the delights of Python so please excuse my ignorance. I downloaded MacPython 2.1 on April 27, and it looks great! The only problem is that whenever I try running my one and only applet after starting or restarting the Mac, I get the error message: The application ... could not be opened because PythonCoreCarbon could not be found. Then I run ConfigurePythonCarbon and everything works just fine. Until the next reboot. I am running Mac OS 9.0.4. Am I doing something wrong? Kolya Wolf

1 0

Re: [Pythonmac-SIG] MacPython 2.1 release candidate
by Jack Jansen April 28, 2001

April 28, 2001

There are new final candidate installers in ftp://www.cwi.nl/ftp/jack/python/mac/newer . The only difference is that there is a new _tkinter.ppc.slb module that should have the bugs fixed that Russell reported. Again, I will wait one more day again to let people give this a try and then I'll move it to the standard place and advertise it. Russell: you are morally obliged to try this after causing me all this work:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 4

Re: Python installer results.
by Jack Jansen April 28, 2001

April 28, 2001

Kelvin, I'm sending my reply to the whole list, because your problem has me baffled. Let's see whether anyone else can shed some insight. Recently, Kelvin Chu <kelvin.chu(a)uvm.edu> said: > Hello, Jack; > > Many, many thanks for the hard work you've put in with the MacPython stuff. > I've been using it now for a while on Unix boxes and am delighted to see it > on the Mac. > > I grabbed a copy of the installer from > http://www.cwi.nl/ftp/jack/python/mac/newer/MacPython21full.hqx and ran > into some problems. I'm running on a 450MHz iMac running OSX (10.01, build > 4K78 - updated software from Apple). > > As predicted by the installer, the ConfigurePythonCarbon step fails and I > have to run it by hand. I get the following error. > > Traceback (most recent call last): > File "Moes:SWdev:Jack:Python:Mac:scripts:ConfigurePython.py", line > 199, in ? > File "Moes:SWdev:Jack:Python:Mac:scripts:ConfigurePython.py", line > 162, in main > File "Moes:SWdev:Jack:Python:Mac:scripts:ConfigurePython.py", line > 75, in mkcorealias > file "hatch:users:kelvin:applications:python > 2.1:mac:lib:macostools.py", line 75, in copy > ofp = open(dstfss.as_pathname(), 'wb') > IOError: [Errno 13] Permission denied: > 'Hatch:System:Library:CFMSupport:PythonCore 2.1' What appears to be happening here is that it tries to install PythonCore in the wrong folder. It should put it into /Library/CFMSupport but it tries to put it in /System/Library/CFMSupport. This directory is unwriteable for mere administrators, because it contains Apple's stuff. You might be able to write it as root, but this is not a good idea. For me everything worked fine (also 10.0.0 as admin user). The only thing that I can imagine is that FindFolder has changed between 10.0.0 and 1.0.1 and now it does not create the /Library/CFMSupport folder... Nope, just tried it, it does create it nicely. Hmm, maybe FindFolder fails for some unknown reason on your system. Could you try the following: >>> import macfs >>> import MACFS >>> vrefnum, dirid = macfs.FindFolder(MACFS.kLocalDomain, MACFS.kSharedLibrariesFolderType, 1) >>> fss = macfs.FSSpec((vrefnum, dirid, 'dummy')) >>> print fss.as_pathname() -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Pythonmac-SIG] MacPython 2.1 release candidate
by Jack Jansen April 27, 2001

April 27, 2001

Recently, Russell E Owen <owen(a)astro.washington.edu> said: > At 11:49 PM +0200 2001-04-27, Jack Jansen wrote: > >There are new final candidate installers in > >ftp://www.cwi.nl/ftp/jack/python/mac/newer . > > This URL didn't work for me. I suspect the correct one is: > http://www.cwi.nl/ftp/jack/python/mac/newer You're absolutely right. Silly me... > P.S. Just for the heck of it I tried some code that uses file events > (which are broken in 2.0 and so I didn't expect them to work in 2.1). > In 2.0 the callback function associated with a Tk file event is > silently never called. The same code 2.1 gives a runtime error when I > try to set up the file event: > > Tkinter.tkinter.READABLE, self.__readSocket) > TypeError: object is not callable: None > > This is probably a bit of an improvement -- no more silent failure. Yes, this is a side-effect of the fix I made. I would have expected a NameError, though, on app.createfilehandler(). Oh well, as you say, this is better than it was. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] MacPython 2.1 release candidate
by Russell E Owen April 27, 2001

April 27, 2001

At 11:49 PM +0200 2001-04-27, Jack Jansen wrote: >There are new final candidate installers in >ftp://www.cwi.nl/ftp/jack/python/mac/newer This URL didn't work for me. I suspect the correct one is: http://www.cwi.nl/ftp/jack/python/mac/newer I installed (it politely asked if it should remove my old prefs -- much appreciated as I'd not deinstalled the previous 2.1fc). The Tk stuff I tried (that failed last time) all ran fine this time. Thank you very much for fixing it! -- Russell P.S. Just for the heck of it I tried some code that uses file events (which are broken in 2.0 and so I didn't expect them to work in 2.1). In 2.0 the callback function associated with a Tk file event is silently never called. The same code 2.1 gives a runtime error when I try to set up the file event: Tkinter.tkinter.READABLE, self.__readSocket) TypeError: object is not callable: None This is probably a bit of an improvement -- no more silent failure.

1 0

Re: [Pythonmac-SIG] MacPython 2.1 release candidate
by Jack Jansen April 27, 2001

April 27, 2001

Recently, "Tattoo Mabonzo K." <tmk(a)easynet.be> said: > I must report that running import test.autotest, 2 tests failed > (test_asynchat and test_socket) which never happened with the beta. Maybe > this is due to the fact that my LAN @ home is running on private IP > addresses (the 192.168.xxx.xxx kind) and there're not configured for > reverse lookup? For test_socket you can indeed expect a failure if reverse lookup isn't configured. For test_asynchat I am not sure. Is anyone else seeing this test fail? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] MacPython 2.1 release candidate
by Jack Jansen April 27, 2001

April 27, 2001

> >MacPython 2.1 is ready, as far as I can tell. Please download the installer > >from http://www.cwi.nl/ftp/jack/python/mac/newer and report back > >success/failure. If all goes well I'll put it in the standard place and > >announce it tomorrow. > > I just tested it on a PowerMac G4 running MacOS 9.1. Classic version > (since I use Tk). The basics that I tried work fine -- built in tests > and my own non-Tk code. However, Tk is unfortunately broken. I'm working on this, but it turns out to be painful. There's a couple of new bits in _tkinter that fix the old bug that after Tkinter has done anything at all your Python window doens't work anymore, but they apparently break tkinter itself. I hope to have a new version tonight. Aside from Russel, did anyone else try the new installer? Did it work (except for the Tkinter problem)? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1