From bbum@codefab.com Sat Feb 1 16:01:25 2003 From: bbum@codefab.com (Bill Bumgarner) Date: Sat, 1 Feb 2003 11:01:25 -0500 Subject: [Pythonmac-SIG] PyObjC Article at O'Reilly Message-ID: <6A45F008-35FE-11D7-8ED2-000393877AE4@codefab.com> > http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html From NetBrick62@aol.com Sat Feb 1 21:21:58 2003 From: NetBrick62@aol.com (NetBrick62@aol.com) Date: Sat, 1 Feb 2003 16:21:58 EST Subject: [Pythonmac-SIG] error using python Message-ID: <8.339c9ce5.2b6d9476@aol.com> Whenever I try to open Python in X11 (or Terminal or XDarwin) I get the following error message: [Bricks-Computer:~] brick% python Python 2.2.1 (#1, 09/14/02, 00:14:43) [GCC Apple devkit-based CPP 6.02] on darwin Type "help", "copyright", "credits" or "license" for more information. dyld: python Undefined symbols: /sw/lib/libreadline.4.2.dylib undefined reference to _tgetent expected to be defined in /usr/lib/libSystem.B.dylib Trace/BPT trap [Bricks-Computer:~] brick% Could anyone over any suggestions, Im using the Carbon Python version now but would like to get back into Unix. Im running Mac OS X 10.2 Jaguar on a G3 Imac. Any help would be appreciated, Thank you for your time. From Jack.Jansen@oratrix.com Sat Feb 1 23:46:10 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 2 Feb 2003 00:46:10 +0100 Subject: [Pythonmac-SIG] error using python In-Reply-To: <8.339c9ce5.2b6d9476@aol.com> Message-ID: <57751AA2-363F-11D7-98AB-000A27B19B96@oratrix.com> On zaterdag, feb 1, 2003, at 22:21 Europe/Amsterdam, NetBrick62@aol.com wrote: > Whenever I try to open Python in X11 (or Terminal or XDarwin) I get the > following error message: > [Bricks-Computer:~] brick% python > Python 2.2.1 (#1, 09/14/02, 00:14:43) > [GCC Apple devkit-based CPP 6.02] on darwin > Type "help", "copyright", "credits" or "license" for more information. > dyld: python Undefined symbols: > /sw/lib/libreadline.4.2.dylib undefined reference to _tgetent expected > to be > defined in /usr/lib/libSystem.B.dylib This is a nasty incompatibility that we can blame on Apple. You're using a version of Python that has been built on OSX 10.1, but you're using it on 10.2. For 10.2 Apple updated their version of curses (a library that is, among other things, used by readline). This is good, but unfortunately they broke any program that depended on the old version of curses. If you're happy with Python 2.2 you can remove the 2.2.1 you installed, as Python 2.2 is shipped by Apple. To find out where your Python 2.2.1 resides type "which python" to the shell. It'll probably be /sw/bin/python (if you installed a fink version) or /usr/local/bin/python. Remove ..../bin/python* and ..../lib/python2.2 (where .... is either /sw or /usr/local). Alternatively you can see if a new Jaguar build (which will probably for 2.2.2) is available from whereever you got your original Python distribution. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Feb 2 22:32:29 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 2 Feb 2003 23:32:29 +0100 Subject: [Pythonmac-SIG] Fwd: [wxPython-mac] downside to just always using pythonw? Message-ID: <36C788E8-36FE-11D7-BAE9-000A27B19B96@oratrix.com> I'm forwarding this message that Kevin Altis sent to the wxPython mailing list earlier today, and I'd like to get feedback on it. On first thought I think I agree with it (the gist is: "make PythonLauncher always use pythonw, so the only difference between its treatment of .py and .pyw files is that the former get a console window"). There are some drawbacks (if you are developing a script that will eventually run in a windowless environment you will not notice it if your script calls to the window manager), but I think the advantage of more comprehensible behavior for novices outweighs that. Note that this would only mean that the default app for .py scripts would change, you'll always be able to change it back. Begin forwarded message: > From: "Kevin Altis" > Date: zon feb 2, 2003 00:00:53 Europe/Amsterdam > To: "Wxpython-Mac" > Subject: [wxPython-mac] downside to just always using pythonw? > Reply-To: wxPython-mac@lists.wxwindows.org > > I know that via the PythonLauncher we can automatically have scripts > with a > .pyw extension run with pythonw. However, most scripts brought over > from > Linux and Windows designed to run with wxPython are unlikely to have > the > .pyw extension set. Normally, the .pyw extension is only useful under > Windows when you want to suppress the console window being displayed > such as > when you run a script from the Explorer by double-clicking the file. > > So, either you train Mac OS X Python users to rename GUI scripts to > .pyw, > provide some utility to do the conversion, or setup PythonLauncher to > run > .py scripts by default with pythonw. The latter seems the simplest. > The vast > majority of the scripts I'll be running are GUI scripts and I also > need to > work on files out of cvs where it is not practical to rename the files > to > .pyw. I can always manually choose to use python instead of pythonw in > the > Terminal or hold down the Option/Alt key to bring up PythonLauncher if > I > specifically need to use /usr/local/bin/python. > > The question then becomes what are the downsides and likely errors that > would occur by just always using /usr/local/bin/pythonw instead of > /usr/local/bin/python? Is it simply a matter of using more memory and > slower > script startup because extra libs are loaded? I think we might want to > make > pythonw the default for even .py scripts if those are the only issues, > the > user can always change the Preference back to python. > > If someone could spell out the differences and/or suggest alternative > approaches to using pythonw and .pyw scripts that would be welcome. > Right > now I forsee endless messages on the mailing lists and c.l.py from > confused > users when scripts don't run or run, but don't work correctly because > parts > of the framework are unavailable. > > ka > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wxPython-mac-unsubscribe@lists.wxwindows.org > For additional commands, e-mail: wxPython-mac-help@lists.wxwindows.org > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From altis@semi-retired.com Sun Feb 2 23:01:02 2003 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 2 Feb 2003 15:01:02 -0800 Subject: [Pythonmac-SIG] RE: [wxPython-mac] downside to just always using pythonw? In-Reply-To: <36C788E8-36FE-11D7-BAE9-000A27B19B96@oratrix.com> Message-ID: Part of my reasoning which I don't think I made clear in the original message is that output from print statements, tracebacks, etc. all seem to go to the Console if you run a script from the Finder. Thus unlike Windows, you always have a "console window" either in the form of the Terminal you run the script from or the Mac OS X Console. You shouldn't ever miss output because of a runtime exception or syntax error. There doesn't seem to be any advantage to wrapping up Finder script launching with a shell script to use the Terminal. Another difference from Windows is that running Python with the -i command-line option to inspect interactively after running script won't do you any good unless you are running from the Terminal; perhaps Linux does something similar? This seems to be the only use for "Run in a Terminal window" option in PythonLauncher; that is if you need a Python interactive prompt after a script runs and you are running the script from the Finder. If you just want to see output, it is all going to go to the Console anyway. If that is not correct, please let me know. ka > -----Original Message----- > From: Jack Jansen [mailto:Jack.Jansen@oratrix.com] > Sent: Sunday, February 02, 2003 2:32 PM > To: pythonmac-sig@python.org > Cc: Kevin Altis > Subject: Fwd: [wxPython-mac] downside to just always using pythonw? > > > I'm forwarding this message that Kevin Altis sent to the wxPython > mailing list earlier today, and I'd like to get feedback on it. > > On first thought I think I agree with it (the gist is: "make > PythonLauncher always use pythonw, so the only difference between its > treatment of .py and .pyw files is that the former get a console > window"). There are some drawbacks (if you are developing a script that > will eventually run in a windowless environment you will not notice it > if your script calls to the window manager), but I think the advantage > of more comprehensible behavior for novices outweighs that. Note that > this would only mean that the default app for .py scripts would change, > you'll always be able to change it back. > > Begin forwarded message: > > > From: "Kevin Altis" > > Date: zon feb 2, 2003 00:00:53 Europe/Amsterdam > > To: "Wxpython-Mac" > > Subject: [wxPython-mac] downside to just always using pythonw? > > Reply-To: wxPython-mac@lists.wxwindows.org > > > > I know that via the PythonLauncher we can automatically have scripts > > with a > > .pyw extension run with pythonw. However, most scripts brought over > > from > > Linux and Windows designed to run with wxPython are unlikely to have > > the > > .pyw extension set. Normally, the .pyw extension is only useful under > > Windows when you want to suppress the console window being displayed > > such as > > when you run a script from the Explorer by double-clicking the file. > > > > So, either you train Mac OS X Python users to rename GUI scripts to > > .pyw, > > provide some utility to do the conversion, or setup PythonLauncher to > > run > > .py scripts by default with pythonw. The latter seems the simplest. > > The vast > > majority of the scripts I'll be running are GUI scripts and I also > > need to > > work on files out of cvs where it is not practical to rename the files > > to > > .pyw. I can always manually choose to use python instead of pythonw in > > the > > Terminal or hold down the Option/Alt key to bring up PythonLauncher if > > I > > specifically need to use /usr/local/bin/python. > > > > The question then becomes what are the downsides and likely errors that > > would occur by just always using /usr/local/bin/pythonw instead of > > /usr/local/bin/python? Is it simply a matter of using more memory and > > slower > > script startup because extra libs are loaded? I think we might want to > > make > > pythonw the default for even .py scripts if those are the only issues, > > the > > user can always change the Preference back to python. > > > > If someone could spell out the differences and/or suggest alternative > > approaches to using pythonw and .pyw scripts that would be welcome. > > Right > > now I forsee endless messages on the mailing lists and c.l.py from > > confused > > users when scripts don't run or run, but don't work correctly because > > parts > > of the framework are unavailable. > > > > ka > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: wxPython-mac-unsubscribe@lists.wxwindows.org > > For additional commands, e-mail: wxPython-mac-help@lists.wxwindows.org > > > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > > From altis@semi-retired.com Mon Feb 3 00:14:45 2003 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 2 Feb 2003 16:14:45 -0800 Subject: [Pythonmac-SIG] more on PythonLauncher Message-ID: Another reason for PythonLauncher to simply default to using pythonw, is that PythonLauncher has no purpose except in the context of the Finder, right? Do tkinter scripts require pythonw? How about PyObjC? In other words, do we have Python scripts that it makes sense to run from the Finder that aren't GUI scripts that require pythonw? Is PythonLauncher ever relevant to command-line scripts or CGI scripts? Would the user run scripts that use something like curses or readline for interactive input from the Finder; wouldn't they just use the Terminal? And again, if pythonw was used to run those types of scripts, what would the downside be? ka From altis@semi-retired.com Mon Feb 3 01:02:57 2003 From: altis@semi-retired.com (Kevin Altis) Date: Sun, 2 Feb 2003 17:02:57 -0800 Subject: [Pythonmac-SIG] fixing the PATH environment variable for 2.3 Message-ID: To simplify using the "right" Python (aka 2.3a1 not Apple's 2.2), I added /usr/local/bin back to the PATH environment variable, by adding PATH to my ~/.MacOSX/environment.plist file. PATH /usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin If you like having your home directory as part of the PATH, you could use: PATH /usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/Users/username substitute your own username for "username" in the string above. See the following link for setting up your ~/.MacOSX/environment.plist file if you haven't already got one. http://www.astro.washington.edu/owen/AquaEnvVar.html I also created a simple .cshrc, since environment.plist doesn't seem to be getting picked up in the Terminal. The ~/.cshrc file just contains: setenv PATH /usr/local/bin:$PATH If you are using the bash shell you should create something similar for your .bashrc. Now you can just type python or pythonw in the Terminal and get the "right" Python. Scripts launched with PythonLauncher will also have the right PATH environment variable because of the environment.plist setting. I'm tempted to have a script that can automatically create these files for users if they don't already have them; those that have them should know enough to munge them if needed. Creating these files as a default part of the MachoPython install seems a bit much, but until Apple is distributing 2.3 (maybe this fall?), developers are probably going to want to modify their PATH. Other suggestions? ka From just@letterror.com Mon Feb 3 10:17:02 2003 From: just@letterror.com (Just van Rossum) Date: Mon, 3 Feb 2003 11:17:02 +0100 Subject: [Pythonmac-SIG] more on PythonLauncher In-Reply-To: Message-ID: Kevin Altis wrote: > Another reason for PythonLauncher to simply default to using pythonw, > is that PythonLauncher has no purpose except in the context of the > Finder, right? Do tkinter scripts require pythonw? How about PyObjC? > In other words, do we have Python scripts that it makes sense to run > from the Finder that aren't GUI scripts that require pythonw? I've personally hardly used PythonLauncher/pythonw yet, and for any GUI things I prefer to build an actual .app bundle (an applet) as it allows you to drop files on it. And for non-GUI things I use Terminal directly. For a Python-Cocoa app (PyObjC) I don't think you can even use pythonw as for even the simplest Cocoa app you need special entries in the Info.plist file. > Is PythonLauncher ever relevant to command-line scripts or CGI > scripts? I don't think so. > Would the user run scripts that use something like curses or > readline for interactive input from the Finder; wouldn't they just > use the Terminal? And again, if pythonw was used to run those types > of scripts, what would the downside be? I've been meaning to update BuildApplet so it uses my bundlebuilder.py module on OSX and while playing with ideas I think it would suffer much of the same problems. One idea that kindof works is: the applet process starts a second process in terminal which will communicate i/o with the real process over a unix domain socket. But I have my doubts about the usability of this and it's also a rather elaborate scheme... A Finder wrapper for a unix scripts is only useful if the script only takes a set of files in argv: as soon is you need any other options you're simply much better off using Terminal directly. Just-thinking-out-loud From p.oberndoerfer@urheberrecht.org Mon Feb 3 17:08:17 2003 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Mon, 03 Feb 2003 18:08:17 +0100 Subject: [Pythonmac-SIG] Detecting serial devices Message-ID: Hello all. It's (again) about detecting currently available serial devices (like modems, IrDA, RS232) on MacOS X. Dan Grassi at dan@grassi.org: > The answer is to use the IORegistry to find a device. Search for > IOSerialBSDClient with a key of IOSerialBSCClientTyle with a value of > IORS232SerialSteeam. Then get the value of the IODialinDevice or > IOCalloutDevice which are respectively (on my system) > /dev/tty.USA191P1.1 and dev/cu.USA191P1.1. Play with > IORegistryExplorer to get a feel for it. :-) This made me indeed curious. So I finally had a small utility that prints a list of available devices including a device's name, basename, suffix, Callout device file, and Dialin device file. The source is 'SerialPorts.sit' at: [It's derived from some Apple sample code. I know it's a mess, but I have never done any C or Objective-C before. So feel free to flame me about programming style etc. ;-) Dan: if you would like to improve this, please do so! Thanks!] If you run it from outside ProjectBuilder you must open Console (/Applications/Utilities) first. My problem is: how can I wrap this snippet so it is accessible from Mac(ho)Python 2.3? Or is there any interest in making the complete IORegistry API available in a systematical way (via bgen, as Jack suggested off list)? Or maybe other parts of IOKit as well? Any help very much appreciated, Pascal MacOS X 10.1.5, Mac(ho)Python 2.3a1, framework install From owen@astro.washington.edu Mon Feb 3 17:26:42 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Mon, 3 Feb 2003 09:26:42 -0800 Subject: [Pythonmac-SIG] environment.plist (was: fixing the PATH environment variable for 2.3) Message-ID: ka wrote: >To simplify using the "right" Python (aka 2.3a1 not Apple's 2.2), I added >/usr/local/bin back to the PATH environment variable, by adding PATH to my >~/.MacOSX/environment.plist file... > >I also created a simple .cshrc, since environment.plist doesn't seem to be >getting picked up in the Terminal...(as >per)...... Did you log out and log back in again after editing environment.plist? That is certainly necessary. After that, I would expect environment variables in environment.plist to show up in Terminal. They certainly do on my system. I define PYTHONPATH, PYTHONSTARTUP and PYTHONDOCS in environment.plist and nowhere else and they show up fine in Terminal (they are listed by the "env" command and they are seen by the command-line version of Python). If this is not the case for others, I'd certainly like to know about it (especially if anybody has an explanation). I wrote the html page in question and would like to correct any false information. But I'm having trouble imagining why it would work fine for me and not others. -- Russell From altis@semi-retired.com Mon Feb 3 17:43:39 2003 From: altis@semi-retired.com (Kevin Altis) Date: Mon, 3 Feb 2003 09:43:39 -0800 Subject: [Pythonmac-SIG] environment.plist (was: fixing the PATH environment variable for 2.3) In-Reply-To: Message-ID: > From: Russell E Owen > > ka wrote: > > >To simplify using the "right" Python (aka 2.3a1 not Apple's 2.2), I added > >/usr/local/bin back to the PATH environment variable, by adding > PATH to my > >~/.MacOSX/environment.plist file... > > > >I also created a simple .cshrc, since environment.plist doesn't > seem to be > >getting picked up in the Terminal...(as > >per)...... > > Did you log out and log back in again after editing > environment.plist? That is certainly necessary. After that, I would > expect environment variables in environment.plist to show up in > Terminal. They certainly do on my system. I define PYTHONPATH, > PYTHONSTARTUP and PYTHONDOCS in environment.plist and nowhere else > and they show up fine in Terminal (they are listed by the "env" > command and they are seen by the command-line version of Python). > > If this is not the case for others, I'd certainly like to know about > it (especially if anybody has an explanation). I wrote the html page > in question and would like to correct any false information. But I'm > having trouble imagining why it would work fine for me and not others. I think the problem is limited to environment variables defined also defined in the shell. I have PYTHONPATH and CVS_RSH keys defined in environment.plist and they work as expected. Bill Bumgarner sent me the following message: > From: Bill Bumgarner > > Anything launched from the Finder [or project builder, whatever], will > inherit your environment.plist. > > Anything launched at the command line will inherit the command line > environment which, unfortunately and by default, overrides > environment.plist. > > That is broken. It should be fixed. I will try to remember to file > a bug. You can test what is picked up by an app run from the terminal or using PythonLauncher from the Finder by printing out os.environ. ka From jharmon@adobe.com Wed Feb 5 00:16:57 2003 From: jharmon@adobe.com (JR) Date: Tue, 04 Feb 2003 16:16:57 -0800 Subject: [Pythonmac-SIG] Transparent methods (and more) in Python... Message-ID: Python linguists and MacPython geeks, I have a few questions that my books and experience aren't answering... 1) If I override __del__ will Python's (normal) garbage collection et al. *still* go off behind it or (since I'm overriding) am I then responsible for manually triggering it. If the later, how does one do so (I saw something about some "super.blah" notation but haven't digested that just yet)? 2) Is there an elegant method of loading CLI args into sys.args in MacPython (not MachO Python) in OS X without employing Apple Events? 3) Is there a transparent assignment op I can override (i.e., the equivalent of what might call __=__ ... no not __eq__)? If not, is there a brief synopsis that describes why the language (seemingly ... at least from my mental vantage point) cannot support he same? Thanks, JR From andrea" ------=_NextPart_000_00E0_31E50A4E.D1073A54 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 KiBSZWR1Y2UgdGhlIGFtb3VudCBvZiBzbGVlcCB5b3UgbmVlZA0KKiBDYXVz ZSB3b3VuZHMgdG8gaGVhbCBmYXN0ZXINCiogTG9zZSB3ZWlnaHQgd2hpbGUg eW91ciBzbGVlcGluZw0KKiBCZWNvbWUgbGVzcyB3aW5kZWQgd2hlbiBleGNl cnNpemluZw0KKiBQdXQgY29sb3IgYmFjayBpbiBncmV5IGhhaXINCiogR3Jv dyBoYWlyIGJhY2sgd2hlcmUgaXQgaGFkIG9uY2UgZmFsbGVuIG91dA0KKiBU aWdodGVuIHNraW4NCiogU3RyZW5ndGhlbiBib25lcw0KKiBCb2R5IGJ1aWxk ZXJzIC0gdXNlIHRoaXMgdG8gYnVpbGQgeW91ciBtdXNjbGVzIHF1aWNrZXIN Ci4uLi4uLi4uLi5UaGUgTGlzdCB0cnVseSBnb2VzIG9uIGFuZCBvbi4uLi4u Li4uLi4NCg0KQXMgc2VlbiBvbiBOQkMsIENCUywgQ05OLCBhbmQgT3ByYWgh IFRoZSBoZWFsdGggZGlzY292ZXJ5IA0KdGhhdCBhY3R1YWxseSByZXZlcnNl cyBhZ2luZyBzeW1wdG9tcyB3aXRob3V0IGRpZXRpbmcgb3IgZXhlcmNpc2Uh IA0KVGhpcyBQUk9WRU4gZGlzY292ZXJ5IGhhcyBiZWVuIHJlcG9ydGVkIG9u IGJ5IHRoZSANCk5ldyBFbmdsYW5kIEpvdXJuYWwgb2YgTWVkaWNpbmUgLSBk b24ndCBqdXN0IHRha2Ugb3VyIHdvcmQgZm9yIGl0Lg0KDQpJbiBmYWN0IHdl J2QgbGlrZSB5b3UgdG8gcmVjZWl2ZSBhIEYuUi5FLkUgdGhpcnR5IGRheSBz dXBwbHk7IGxvb2sgYW5kIGZlZWwgDQp5b3VuZ2VyLCBsb3NlIHdlaWdodCwg cmVkdWNlIHNsZWVwLCBUaGUgbGlzdCBnb2VzIG9uLCB3ZSANCmVuY291cmFn ZSB5b3UgdG8gYXQgbGVhc3QgdGFrZSBhIGxvb2sgYXQgdGhlIGluZm9ybWF0 aW9uIGFzIHRvDQp3aGF0IGVsc2UgaXQgY2FuIGRvDQoNCmh0dHA6Ly9oaWRk ZW4uY29tLm1zLXNjcmlwdC42NTE2ODUuOTg3MzY2MS0wMzMyMTk4NzYzNTEz NTMxODQxLmVuY29kZS40NzYyODg2MjUwNDA0NDQ0Mi5lbHNlLjE0MDU1ODYz NzIwMjU4OTQ2MzAyMTU1MDYzNzMyLm1zL3d3dy5ncm93eW91bmcuY29tLz9s aWZlcw0KDQoNCjkzNjZBdU9ZOC01MTFhV3ZWMTk4M2tOdWgwLTczNnNDUlU1 NDkxY012ZTctOTMzdllCaTIzODFrVHlrMS0yMDJlcGlINjUwMktSdGs1LTI2 bDc1 From Jack.Jansen@cwi.nl Wed Feb 5 10:48:01 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 5 Feb 2003 11:48:01 +0100 Subject: [Pythonmac-SIG] Transparent methods (and more) in Python... In-Reply-To: Message-ID: <4C5712A9-38F7-11D7-AFC9-0030655234CE@cwi.nl> On Wednesday, Feb 5, 2003, at 01:16 Europe/Amsterdam, JR wrote: > Python linguists and MacPython geeks, > > I have a few questions that my books and experience aren't answering... > > 1) If I override __del__ will Python's (normal) garbage collection et > al. > *still* go off behind it or (since I'm overriding) am I then > responsible for > manually triggering it. If the later, how does one do so (I saw > something > about some "super.blah" notation but haven't digested that just yet)? This should be in the books (at least, in the better books:-) but it may be hard to find. Providing an __del__ does *not* alter the normal behaviour of garbage collection. Your method is simply called just before the object goes away. And: you can revive the object if you want, as you can see by running the following code: stash = None class Stasher: def __del__(self): global stash print "About to be deleted:", self stash = self stash = Stasher() stash = None stash = None stash = None > 2) Is there an elegant method of loading CLI args into sys.args in > MacPython > (not MachO Python) in OS X without employing Apple Events? I'm not sure what you mean, but maybe EasyDialogs.GetArgv() is what you want? It allows the user to specify a sys.argv-like list of arguments. > 3) Is there a transparent assignment op I can override (i.e., the > equivalent > of what might call __=__ ... no not __eq__)? If not, is there a brief > synopsis that describes why the language (seemingly ... at least from > my > mental vantage point) cannot support he same? This is more a c.l.p question, but anyway: this can't be done in Python, because assignment in Python is different from assignment in C and such. In Python it is only the binding of a name, not the assignment of a variable. In other words: if you do "i = 1+1" then the interpreter first takes the two objects "1" and "1", adds them giving a new object and finally increments the refcount on that new object and stores a reference in the local variable "i". So assignment isn't really an operator in Python. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From mwh@python.net Wed Feb 5 13:27:27 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 05 Feb 2003 13:27:27 +0000 Subject: [Pythonmac-SIG] Transparent methods (and more) in Python... In-Reply-To: (JR's message of "Tue, 04 Feb 2003 16:16:57 -0800") References: Message-ID: <2mvfzyoo1s.fsf@starship.python.net> JR writes: > Python linguists and MacPython geeks, > > I have a few questions that my books and experience aren't answering... > > 1) If I override __del__ will Python's (normal) garbage collection et al. > *still* go off behind it or (since I'm overriding) am I then responsible for > manually triggering it. If the later, how does one do so (I saw something > about some "super.blah" notation but haven't digested that just yet)? You're confused. You do know how CPython uses reference counts, and that the __del__ method is called when the reference count hits 0? So you see, a __del__ method *can't* affect Python's garbage collection, because it's presence doesn't make a difference until the gc has done it's thing! (Actually, there's a small lie in the above to do with reference cycles, but that probably counts as arcana). Why are you writing a __del__ method anyway? They're often a bad idea, IME. > 2) Is there an elegant method of loading CLI args into sys.args in MacPython > (not MachO Python) in OS X without employing Apple Events? Can't answer this one, > 3) Is there a transparent assignment op I can override (i.e., the equivalent > of what might call __=__ ... no not __eq__)? If not, is there a brief > synopsis that describes why the language (seemingly ... at least from my > mental vantage point) cannot support he same? Try this: http://starship.python.net/crew/mwh/hacks/objectthink.html It's harping on about a slightly different point, but it might still help. Cheers, M. -- Every now and then, Google doesn't throw up what I need so I start checking Altavista, Yahoo, etc. In almost every single case, I am brutally reminded why I use Google in the first place. -- John Riddoch, asr From p.oberndoerfer@urheberrecht.org Wed Feb 5 21:21:55 2003 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Wed, 05 Feb 2003 22:21:55 +0100 Subject: [Pythonmac-SIG] Accessing CoreFoundation/IOKit from inside a module? Message-ID: Hello all. Isn't it possible to use stuff from "#include " from inside a module? Everything compiles and links fine (using "python setup.py build") as long as I don't use for example "CFDictionarySetValue()". If I use it I get the following linking error message: > cc -Wl,-F. -bundle -framework Python build/temp.darwin-5.5-Power > Macintosh-2.3/osxtestmodule.o -o build/lib.darwin-5.5-Power > Macintosh-2.3/osxtest.so > /usr/bin/ld: build/temp.darwin-5.5-Power Macintosh-2.3/osxtestmodule.o illegal > reference to symbol: _CFDictionarySetValue defined in indirectly referenced > dynamic library > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation The same happens with IOKit, of course... > /usr/bin/ld: build/temp.darwin-5.5-Power Macintosh-2.3/osxtestmodule.o illegal > reference to symbol: _IOMasterPort defined in indirectly referenced dynamic > library /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit What am I missing here? Is this a known issue? What's the problem with an "indirectly referenced dynamic library"? Thanks for your help! Pascal And yes, I can access the module from the python interpreter, if the linking doesn't fail. From just@letterror.com Wed Feb 5 21:39:21 2003 From: just@letterror.com (Just van Rossum) Date: Wed, 5 Feb 2003 22:39:21 +0100 Subject: [Pythonmac-SIG] Accessing CoreFoundation/IOKit from inside a module? In-Reply-To: Message-ID: Pascal Oberndoerfer wrote: > Isn't it possible to use stuff from "#include > " from inside a module? Everything > compiles and links fine (using "python setup.py build") as long as I > don't use for example "CFDictionarySetValue()". If I use it I get the > following linking error message: I think you need to add extra_link_args=['-framework', 'CoreFoundation'] to you Extension definition in your setup.py. Just From p.oberndoerfer@urheberrecht.org Thu Feb 6 11:22:53 2003 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Thu, 06 Feb 2003 12:22:53 +0100 Subject: [Pythonmac-SIG] Accessing CoreFoundation/IOKit ... In-Reply-To: Message-ID: Just van Rossum at just@letterror.com: > I think you need to add > > extra_link_args=['-framework', 'CoreFoundation'] > > to you Extension definition in your setup.py. > > Just Just, It works! Thank you. I added extra_link_args=['-framework', 'CoreFoundation', \ '-framework', 'IOKit'] Pascal From p.oberndoerfer@urheberrecht.org Fri Feb 7 15:02:42 2003 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Fri, 07 Feb 2003 16:02:42 +0100 Subject: [Pythonmac-SIG] Osxserialports Message-ID: Hello all. To access a list of currently available serial devices on MacOS X you can now try an extension. The extension is at A short description would be >>>import osxserialports >>>osxserialports.all() # or osxserialports.modems() or osxserialports.rs232() This returns (should return) a list of dictionaries, each dictionary containing some information about a device. The list will be ampty of course if no serial devices were found. There's a test script called osxsp.py as well. I found it useful to solve the problem that you cannot predict what USB port a USB-to-serial adapter will be connected to. Would (interested) people provide feedback on the extension please and maybe what more they'd like to see exposed from IOKit/IORegistry? Cannot promise anything though ;-) Thank you. Pascal From p.oberndoerfer@urheberrecht.org Fri Feb 7 19:05:47 2003 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Fri, 07 Feb 2003 20:05:47 +0100 Subject: [Pythonmac-SIG] PyObjC Article at O'Reilly In-Reply-To: <6A45F008-35FE-11D7-8ED2-000393877AE4@codefab.com> Message-ID: Bill Bumgarner at bbum@codefab.com: >> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html I tried to install PyObjC from the sources for MacOS X 10.1.5 via the usual "python setup.py install". Unfortunately this failed with the following error message: > Modules/objc/register.m:12: warning: function declaration isn't a prototype > Modules/objc/register.m: In function `meth_imp_679': > Modules/objc/register.m:55957: parse error before `const' > Modules/objc/register.m:55959: `errstr' undeclared (first use in this > function) > Modules/objc/register.m:55959: (Each undeclared identifier is reported only > once > Modules/objc/register.m:55959: for each function it appears in.) > Modules/objc/register.m: In function `ObjC_RegisterStdStubs': > Modules/objc/register.m:56720: warning: passing arg 2 of pointer to function > from incompatible pointer type > error: command 'cc' failed with exit status 1 I don't know why this could possibly happen (even after looking at Modules/objc/register.m). Anybody knows about compatibility issues? Any other suggestions? Thank you. Pascal From just@letterror.com Fri Feb 7 19:11:11 2003 From: just@letterror.com (Just van Rossum) Date: Fri, 7 Feb 2003 20:11:11 +0100 Subject: [Pythonmac-SIG] PyObjC Article at O'Reilly In-Reply-To: Message-ID: Pascal Oberndoerfer wrote: > Bill Bumgarner at bbum@codefab.com: > > >> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html > > > I tried to install PyObjC from the sources for MacOS X 10.1.5 via the > usual "python setup.py install". Unfortunately this failed with the > following error message: I don't think PyObjC is compatible with pre-Jaguar out-of-the box. You may want to join the pyobjc-dev list, as this is somewhat off-topic here but more importantly you'll reach more people who may know what to do... It would be interesting to get it to work again on 10.1.x. Just From oussoren@cistron.nl Fri Feb 7 19:40:21 2003 From: oussoren@cistron.nl (Ronald Oussoren) Date: Fri, 7 Feb 2003 20:40:21 +0100 Subject: [Pythonmac-SIG] PyObjC Article at O'Reilly In-Reply-To: Message-ID: On Friday, Feb 7, 2003, at 20:05 Europe/Amsterdam, Pascal Oberndoerfer wrote: > Bill Bumgarner at bbum@codefab.com: > >>> http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html > > > I tried to install PyObjC from the sources for MacOS X 10.1.5 via the > usual > "python setup.py install". Unfortunately this failed with the following > error message: > >> Modules/objc/register.m:12: warning: function declaration isn't a >> prototype >> Modules/objc/register.m: In function `meth_imp_679': >> Modules/objc/register.m:55957: parse error before `const' >> Modules/objc/register.m:55959: `errstr' undeclared (first use in this >> function) >> Modules/objc/register.m:55959: (Each undeclared identifier is >> reported only >> once >> Modules/objc/register.m:55959: for each function it appears in.) >> Modules/objc/register.m: In function `ObjC_RegisterStdStubs': >> Modules/objc/register.m:56720: warning: passing arg 2 of pointer to >> function >> from incompatible pointer type >> error: command 'cc' failed with exit status 1 That's not the way it's supposed to fail on 10.1.5... We don't really support 10.1.x at the moment. I didn't know about the problem your seeing, but later on in the build it will fail again when trying to compile the wrappers for global functions, 10.2 contains a number of functions that are not present on 10.1.5. I'm afraid that support for 10.1.x will stay absent until someone volunteers to do the port. Luckily that shouldn't be too hard. You also try to use the latest version from CVS, this uses libffi (downloadable from our files section of SF) instead of the contents of file that's failing for you. Ronald From tjk@ams.org Fri Feb 7 22:11:06 2003 From: tjk@ams.org (Tom Kacvinsky) Date: Fri, 7 Feb 2003 17:11:06 -0500 (EST) Subject: [Pythonmac-SIG] Weird issues with Python 9.2.x and CarbonLib/Tkinter Message-ID: Hi all, I am using Adobe's OpenType FDK on my PowerBook G4 running MacOS 9.2.2. I have had some weird crashing issues with the interpreter. I am using the class version of Python 9.2.1 and 9.2.2. Everytime I crash, the MacsBug log I get says there is an umapped memory exception in _tkinter.ppc.slb. IF I disable CarbonLib 1.6, the problems go away. Have you heard of this and do you know of a fix (aside from using the MacOS X version of the FDK). I need the Tkinter stuff for the classic FDK, which the 2.3 alpha does not have, nor does the 2.2.1/2.2.2 Carbon version of Python. And I cannot use PYthon 2.1.x because the shared libs in the FDK are compiled for Python 2.2.x. Thanks and regards, Tom From bob@redivi.com Fri Feb 7 22:32:34 2003 From: bob@redivi.com (Bob Ippolito) Date: Fri, 7 Feb 2003 17:32:34 -0500 Subject: [Pythonmac-SIG] python extension namespace clash in jaguar python? Message-ID: <0D55E28A-3AEC-11D7-9779-000A95686CD8@redivi.com> Using the stock python from OS X 10.2, is there a way around the issue where two python extensions with the same name (but in different packages) will cause a clash? I know this has been resolved in later builds of python, but it would be nice to be able to get around this without distributing a custom build. In my particular example, I was seeing how possible it is to port pygame to the stock python using methods similar to what the pyobjc team has done... pygame has a module called time, which clashes with python's time. If I import pygame.time, and then import time, both of them are actually pygame.time, and vice versa if I do it in reverse order. I know I could rename pygame.time (and change inittime) to something else, but that doesn't seem like a very good solution. Are there any alternatives? -bob From ivan@allometra.com Sat Feb 8 01:13:01 2003 From: ivan@allometra.com (Ivan Kozik) Date: Fri, 07 Feb 2003 17:13:01 -0800 Subject: [Pythonmac-SIG] Togl on OS X 10.2 with apple's X11? CONST84_RETURN errors in tk headers Message-ID: <77D3C843-3B02-11D7-AF11-000A9575E01E@allometra.com> Hello, I am trying to compile Togl (a tcl/tk opengl library) on OS X 10.2 because apple's X11 now natively supports opengl. When I run make in the Togl source directory, I get a bunch of CONST84_RETURN errors in the Tk 8.4 distribution: /Library/Frameworks/Tk.framework/Headers//tkDecls.h:237: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:327: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:330: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:410: syntax error, found `CONST84' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:410: illegal function definition, found `)' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:479: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:482: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:484: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:487: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:489: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:491: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:494: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:496: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:499: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:501: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:504: illegal external declaration, missing `;' after `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:513: syntax error, found `CONST84' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:513: illegal function definition, found `)' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:960: syntax error, found `CONST84' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:986: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:986: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1014: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1014: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1015: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1015: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1039: syntax error, found `CONST84' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1061: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1061: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1062: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1062: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1063: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1063: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1064: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1064: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1065: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1065: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1066: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1066: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1067: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1067: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1068: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1068: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1069: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1069: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1070: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1070: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1071: undefined type, found `CONST84_RETURN' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1071: illegal member declaration, missing name, found `char' /Library/Frameworks/Tk.framework/Headers//tkDecls.h:1074: syntax error, found `CONST84' Is there anything I can do to fix them? Are my headers broken? Thanks, Ivan From Jack.Jansen@oratrix.com Sat Feb 8 23:07:20 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 9 Feb 2003 00:07:20 +0100 Subject: [Pythonmac-SIG] Weird issues with Python 9.2.x and CarbonLib/Tkinter In-Reply-To: Message-ID: <131809FD-3BBA-11D7-ABF7-000A27B19B96@oratrix.com> On vrijdag, feb 7, 2003, at 23:11 Europe/Amsterdam, Tom Kacvinsky wrote: > Hi all, > > I am using Adobe's OpenType FDK on my PowerBook G4 running MacOS > 9.2.2. I have had some weird crashing issues with the interpreter. > I am using the class version of Python 9.2.1 and 9.2.2. Everytime > I crash, the MacsBug log I get says there is an umapped memory > exception in _tkinter.ppc.slb. IF I disable CarbonLib 1.6, the > problems go away. Some of the OpenType folks used to be on this list, so they may be able to tell you more, but I think there may be some sort of a mixup between classic and carbon. Tkinter only works in classic, but maybe some other part of OpenType can work both in classic and carbon, and if carbon is available it uses that but thereby breaks classic Python? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tjk@ams.org Sun Feb 9 00:17:36 2003 From: tjk@ams.org (Tom Kacvinsky) Date: Sat, 8 Feb 2003 19:17:36 -0500 (EST) Subject: [Pythonmac-SIG] Weird issues with Python 9.2.x and CarbonLib/Tkinter In-Reply-To: <131809FD-3BBA-11D7-ABF7-000A27B19B96@oratrix.com> References: <131809FD-3BBA-11D7-ABF7-000A27B19B96@oratrix.com> Message-ID: Hi Jack, None of the FDK libs have CarbonLib dependencies (according to the "The Fragmalyzer"). Tom On Sun, 9 Feb 2003, Jack Jansen wrote: > > On vrijdag, feb 7, 2003, at 23:11 Europe/Amsterdam, Tom Kacvinsky wrote: > > > I am using Adobe's OpenType FDK on my PowerBook G4 running MacOS > > 9.2.2. I have had some weird crashing issues with the interpreter. > > I am using the class version of Python 9.2.1 and 9.2.2. Everytime > > I crash, the MacsBug log I get says there is an umapped memory > > exception in _tkinter.ppc.slb. IF I disable CarbonLib 1.6, the > > problems go away. > > Some of the OpenType folks used to be on this list, so they may be able > to tell you more, but I think there may be some sort of a mixup between > classic and carbon. Tkinter only works in classic, but maybe some other > part of OpenType can work both in classic and carbon, and if carbon is > available it uses that but thereby breaks classic Python? From Jack.Jansen@oratrix.com Sun Feb 9 01:02:25 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 9 Feb 2003 02:02:25 +0100 Subject: [Pythonmac-SIG] Weird issues with Python 9.2.x and CarbonLib/Tkinter In-Reply-To: Message-ID: <2726BD0D-3BCA-11D7-ABF7-000A27B19B96@oratrix.com> Then I'm afraid we have to blame it on MacOS9's Tcl/Tk's ever growing list of erratic behaviour... On zondag, feb 9, 2003, at 01:17 Europe/Amsterdam, Tom Kacvinsky wrote: > Hi Jack, > > None of the FDK libs have CarbonLib dependencies (according to the > "The Fragmalyzer"). > > Tom > > On Sun, 9 Feb 2003, Jack Jansen wrote: > >> >> On vrijdag, feb 7, 2003, at 23:11 Europe/Amsterdam, Tom Kacvinsky >> wrote: >> >>> I am using Adobe's OpenType FDK on my PowerBook G4 running MacOS >>> 9.2.2. I have had some weird crashing issues with the interpreter. >>> I am using the class version of Python 9.2.1 and 9.2.2. Everytime >>> I crash, the MacsBug log I get says there is an umapped memory >>> exception in _tkinter.ppc.slb. IF I disable CarbonLib 1.6, the >>> problems go away. >> >> Some of the OpenType folks used to be on this list, so they may be >> able >> to tell you more, but I think there may be some sort of a mixup >> between >> classic and carbon. Tkinter only works in classic, but maybe some >> other >> part of OpenType can work both in classic and carbon, and if carbon is >> available it uses that but thereby breaks classic Python? > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob@redivi.com Sun Feb 9 23:09:05 2003 From: bob@redivi.com (Bob Ippolito) Date: Sun, 9 Feb 2003 18:09:05 -0500 Subject: [Pythonmac-SIG] Building Mac extensions for Apple Python In-Reply-To: Message-ID: <7C3CAE52-3C83-11D7-9779-000A95686CD8@redivi.com> On Friday, Jan 3, 2003, at 16:52 America/New_York, Kevin Ollivier wrote: > Hi Jack, > > Thanks for your help! I am also clueless as to why PyObject_Del would > be causing that error message. Do those extensions get built with a > framework build as well? I did some playing around (removing the > extensions that were not building and changing $(scripts)/Lib/Mac to > its new home), but I'm getting import errors for the mac modules > during the import_BuildApplet phase. It cannot find import macfsn and > EasyDialogs, which are of course in the CVS but the path is probably > not set properly. Are these supposed to be copied over to > /Applications/MacPython-OSX-2.3 before this portion of setup is run? I took a look at this yesterday, as I was trying to do some stuff with quicktime and I thought it'd be nice to be able to backport it to jaguar python. I had some problems with this, because Makefile.jaguar is broken, so I tried doing what I wanted in ctypes, but that gave me bus errors left and right just defining Structures and whatnot, so I had to stop there.. and then I started writing my own python extension, but that started taking too long.. so I think I'm going to try and fix Makefile.jaguar again. Anyways, here's the definition of PyObject_Del: #define PyObject_Del(op) _PyObject_Del((PyObject *)(op)) See the problem is that in the implementation of _AE, and the other modules that cause problems, we're attempting to put this macro inside of a type definition. You can't get a pointer to PyObject_Del because it's not an actual function, it's a macro function. My lazy fix was just to load each file that had this issue and do this (in vim) :%s/(#define.*)\ Message-ID: <83540882-3C90-11D7-9779-000A95686CD8@redivi.com> --Apple-Mail-8--41452356 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Sunday, Feb 9, 2003, at 18:09 America/New_York, Bob Ippolito wrote: > On Friday, Jan 3, 2003, at 16:52 America/New_York, Kevin Ollivier > wrote: > >> Hi Jack, >> >> Thanks for your help! I am also clueless as to why PyObject_Del would >> be causing that error message. Do those extensions get built with a >> framework build as well? I did some playing around (removing the >> extensions that were not building and changing $(scripts)/Lib/Mac to >> its new home), but I'm getting import errors for the mac modules >> during the import_BuildApplet phase. It cannot find import macfsn and >> EasyDialogs, which are of course in the CVS but the path is probably >> not set properly. Are these supposed to be copied over to >> /Applications/MacPython-OSX-2.3 before this portion of setup is run? > > I took a look at this yesterday, as I was trying to do some stuff with > quicktime and I thought it'd be nice to be able to backport it to > jaguar python. I had some problems with this, because Makefile.jaguar > is broken, so I tried doing what I wanted in ctypes, but that gave me > bus errors left and right just defining Structures and whatnot, so I > had to stop there.. and then I started writing my own python > extension, but that started taking too long.. so I think I'm going to > try and fix Makefile.jaguar again. > > Anyways, here's the definition of PyObject_Del: > #define PyObject_Del(op) _PyObject_Del((PyObject *)(op)) > > See the problem is that in the implementation of _AE, and the other > modules that cause problems, we're attempting to put this macro inside > of a type definition. You can't get a pointer to PyObject_Del because > it's not an actual function, it's a macro function. My lazy fix was > just to load each file that had this issue and do this (in vim) > :%s/(#define.*)\ Right now, the problem seems to be that a large number of the Mac > modules are not built at all by Makefile.jaguar, so I'm going to have > to start getting into setup.jaguar.py. > This is my preliminary fix, please be sure to read the updated README.JAGUAR, as two additional steps are necessary (modification to Python.h to get around the lack of bool and add some missing macros, and the and modification to site.py to get around the lack of bool). I don't know how to use any of these modules yet, so I haven't done testing.. but they all compile except Nav, which I had to comment out. It's got some reference to AEDesc_NewBorrowed or something of the like, which is defined as a C function in the module _AE -- but is used as a python function argument in Nav.. so something seems fishy there. Again, I don't know enough about Carbon / Toolbox to figure out what it's trying to do and how to fix it. -bob this is the output of: cvs diff dist/src/Mac > jagfixes.diff --Apple-Mail-8--41452356 Content-Disposition: attachment; filename=jagfixes.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="jagfixes.diff" Index: dist/src/Mac/Modules/ae/_AEmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/ae/_AEmodule.c,v retrieving revision 1.19 diff -r1.19 _AEmodule.c 7d6 < 897c896 < #define AEDesc_tp_free PyObject_Del --- > #define AEDesc_tp_free _PyObject_Del Index: dist/src/Mac/Modules/app/_Appmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/app/_Appmodule.c,v retrieving revision 1.17 diff -r1.17 _Appmodule.c 140c140 < #define ThemeDrawingStateObj_tp_free PyObject_Del --- > #define ThemeDrawingStateObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/carbonevt/_CarbonEvtmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/carbonevt/_CarbonEvtmodule.c,v retrieving revision 1.14 diff -r1.14 _CarbonEvtmodule.c 435c435 < #define EventRef_tp_free PyObject_Del --- > #define EventRef_tp_free _PyObject_Del 655c655 < #define EventQueueRef_tp_free PyObject_Del --- > #define EventQueueRef_tp_free _PyObject_Del 784c784 < #define EventLoopRef_tp_free PyObject_Del --- > #define EventLoopRef_tp_free _PyObject_Del 931c931 < #define EventLoopTimerRef_tp_free PyObject_Del --- > #define EventLoopTimerRef_tp_free _PyObject_Del 1123c1123 < #define EventHandlerRef_tp_free PyObject_Del --- > #define EventHandlerRef_tp_free _PyObject_Del 1255c1255 < #define EventHandlerCallRef_tp_free PyObject_Del --- > #define EventHandlerCallRef_tp_free _PyObject_Del 1409c1409 < #define EventTargetRef_tp_free PyObject_Del --- > #define EventTargetRef_tp_free _PyObject_Del 1538c1538 < #define EventHotKeyRef_tp_free PyObject_Del --- > #define EventHotKeyRef_tp_free _PyObject_Del Index: dist/src/Mac/Modules/cg/_CGmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/cg/_CGmodule.c,v retrieving revision 1.11 diff -r1.11 _CGmodule.c 1293c1293 < #define CGContextRefObj_tp_free PyObject_Del --- > #define CGContextRefObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/cm/_Cmmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/cm/_Cmmodule.c,v retrieving revision 1.15 diff -r1.15 _Cmmodule.c 284c284 < #define CmpInstObj_tp_free PyObject_Del --- > #define CmpInstObj_tp_free _PyObject_Del 717c717 < #define CmpObj_tp_free PyObject_Del --- > #define CmpObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/ctl/_Ctlmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/ctl/_Ctlmodule.c,v retrieving revision 1.24 diff -r1.24 _Ctlmodule.c 3897c3897 < #define CtlObj_tp_free PyObject_Del --- > #define CtlObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/dlg/_Dlgmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/dlg/_Dlgmodule.c,v retrieving revision 1.17 diff -r1.17 _Dlgmodule.c 980c980 < #define DlgObj_tp_free PyObject_Del --- > #define DlgObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/drag/_Dragmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/drag/_Dragmodule.c,v retrieving revision 1.14 diff -r1.14 _Dragmodule.c 767c767 < #define DragObj_tp_free PyObject_Del --- > #define DragObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/file/_Filemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/file/_Filemodule.c,v retrieving revision 1.17 diff -r1.17 _Filemodule.c 415c415 < #define FSCatalogInfo_tp_free PyObject_Del --- > #define FSCatalogInfo_tp_free _PyObject_Del 600c600 < #define FInfo_tp_free PyObject_Del --- > #define FInfo_tp_free _PyObject_Del 946c946 < #define Alias_tp_free PyObject_Del --- > #define Alias_tp_free _PyObject_Del 1405c1405 < #define FSSpec_tp_free PyObject_Del --- > #define FSSpec_tp_free _PyObject_Del 1972c1972 < #define FSRef_tp_free PyObject_Del --- > #define FSRef_tp_free _PyObject_Del Index: dist/src/Mac/Modules/ibcarbon/_IBCarbon.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/ibcarbon/_IBCarbon.c,v retrieving revision 1.7 diff -r1.7 _IBCarbon.c 167c167 < #define IBNibRefObj_tp_free PyObject_Del --- > #define IBNibRefObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/list/_Listmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/list/_Listmodule.c,v retrieving revision 1.16 diff -r1.16 _Listmodule.c 787c787 < #define ListObj_tp_free PyObject_Del --- > #define ListObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/menu/_Menumodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/menu/_Menumodule.c,v retrieving revision 1.17 diff -r1.17 _Menumodule.c 2571c2571 < #define MenuObj_tp_free PyObject_Del --- > #define MenuObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/mlte/_Mltemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/mlte/_Mltemodule.c,v retrieving revision 1.17 diff -r1.17 _Mltemodule.c 1296c1296 < #define TXNObj_tp_free PyObject_Del --- > #define TXNObj_tp_free _PyObject_Del 1449c1449 < #define TXNFontMenuObj_tp_free PyObject_Del --- > #define TXNFontMenuObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/qd/_Qdmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/qd/_Qdmodule.c,v retrieving revision 1.16 diff -r1.16 _Qdmodule.c 1086c1086 < #define GrafObj_tp_free PyObject_Del --- > #define GrafObj_tp_free _PyObject_Del 1284c1284 < #define BMObj_tp_free PyObject_Del --- > #define BMObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/qdoffs/_Qdoffsmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/qdoffs/_Qdoffsmodule.c,v retrieving revision 1.13 diff -r1.13 _Qdoffsmodule.c 158c158 < #define GWorldObj_tp_free PyObject_Del --- > #define GWorldObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/qt/_Qtmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/qt/_Qtmodule.c,v retrieving revision 1.15 diff -r1.15 _Qtmodule.c 1117c1117 < #define MovieCtlObj_tp_free PyObject_Del --- > #define MovieCtlObj_tp_free _PyObject_Del 1605c1605 < #define TimeBaseObj_tp_free PyObject_Del --- > #define TimeBaseObj_tp_free _PyObject_Del 1946c1946 < #define UserDataObj_tp_free PyObject_Del --- > #define UserDataObj_tp_free _PyObject_Del 3158c3158 < #define MediaObj_tp_free PyObject_Del --- > #define MediaObj_tp_free _PyObject_Del 4476c4476 < #define TrackObj_tp_free PyObject_Del --- > #define TrackObj_tp_free _PyObject_Del 6849c6849 < #define MovieObj_tp_free PyObject_Del --- > #define MovieObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/res/_Resmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/res/_Resmodule.c,v retrieving revision 1.19 diff -r1.19 _Resmodule.c 628c628 < #define ResObj_tp_free PyObject_Del --- > #define ResObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/te/_TEmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/te/_TEmodule.c,v retrieving revision 1.15 diff -r1.15 _TEmodule.c 1007c1007 < #define TEObj_tp_free PyObject_Del --- > #define TEObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/waste/wastemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/waste/wastemodule.c,v retrieving revision 1.31 diff -r1.31 wastemodule.c 423c423 < #define WEOObj_tp_free PyObject_Del --- > #define WEOObj_tp_free _PyObject_Del 2172c2172 < #define wasteObj_tp_free PyObject_Del --- > #define wasteObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/win/_Winmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/win/_Winmodule.c,v retrieving revision 1.17 diff -r1.17 _Winmodule.c 2583c2583 < #define WinObj_tp_free PyObject_Del --- > #define WinObj_tp_free _PyObject_Del Index: dist/src/Mac/OSX/Makefile.jaguar =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/Makefile.jaguar,v retrieving revision 1.4 diff -r1.4 Makefile.jaguar 70c70 < $(PYTHON) $(srcdir)/Mac/Lib/bundlebuilder.py -q --link-exec \ --- > $(PYTHON) $(srcdir)/Lib/plat-mac/bundlebuilder.py -q --link-exec \ Index: dist/src/Mac/OSX/README.JAGUAR =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/README.JAGUAR,v retrieving revision 1.1 diff -r1.1 README.JAGUAR 28a29,41 > 3. Add the following to /usr/include/python2.2/Python.h > #define PyDoc_VAR(name) static char name[] > #define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str) > #ifdef WITH_DOC_STRINGS > #define PyDoc_STR(str) str > #else > #define PyDoc_STR(str) "" > #endif > #define PyBool_Check PyObject_IsTrue > #define PyBool_FromLong PyInt_FromLong > 4. Add the following to /usr/lib/python2.2/site.py > __builtin__.True = not 0 > __builtin__.False = not not 0 Index: dist/src/Mac/OSX/setup.jaguar.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/setup.jaguar.py,v retrieving revision 1.3 diff -r1.3 setup.jaguar.py 41c41,92 < --- > > def detect_tkinter_darwin(): > # The _tkinter module, using frameworks. Since frameworks are quite > # different the UNIX search logic is not sharable. > from os.path import join, exists > framework_dirs = [ > '/System/Library/Frameworks/', > '/Library/Frameworks', > join(os.getenv('HOME'), '/Library/Frameworks') > ] > > # Find the directory that contains the Tcl.framwork and Tk.framework > # bundles. > # XXX distutils should support -F! > for F in framework_dirs: > # both Tcl.framework and Tk.framework should be present > for fw in 'Tcl', 'Tk': > if not exists(join(F, fw + '.framework')): > break > else: > # ok, F is now directory with both frameworks. Continure > # building > break > else: > # Tk and Tcl frameworks not found. Normal "unix" tkinter search > # will now resume. > return [] > > # For 8.4a2, we must add -I options that point inside the Tcl and Tk > # frameworks. In later release we should hopefully be able to pass > # the -F option to gcc, which specifies a framework lookup path. > # > include_dirs = [ > join(F, fw + '.framework', H) > for fw in 'Tcl', 'Tk' > for H in 'Headers', 'Versions/Current/PrivateHeaders' > ] > > # For 8.4a2, the X11 headers are not included. Rather than include a > # complicated search, this is a hard-coded path. It could bail out > # if X11 libs are not found... > include_dirs.append('/usr/X11R6/include') > frameworks = ['-framework', 'Tcl', '-framework', 'Tk'] > > return [Extension('_tkinter', [SRCDIR+'/Modules/_tkinter.c', SRCDIR+'/Modules/tkappinit.c'], > define_macros=[('WITH_APPINIT', 1)], > include_dirs = include_dirs, > libraries = [], > extra_compile_args = frameworks, > extra_link_args = frameworks, > )] > 64a116,118 > def find_module(x): > return '%s/Mac/Modules/%s' % (SRCDIR, x) > 66a121,218 > Extension('_CF', [find_module(x) for x in 'cf/_CFmodule.c', 'cf/pycfbridge.c'], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'CoreFoundation']), > Extension('gestalt', [find_module(x) for x in ['gestaltmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('MacOS', [find_module(x) for x in ['macosmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('icglue', [find_module(x) for x in ['icgluemodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Res', [find_module(x) for x in ['res/_Resmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Snd', [find_module(x) for x in ['snd/_Sndmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > #Extension('Nav', [find_module(x) for x in ['Nav.c']], > # include_dirs=[SRCDIR+"/Mac/Include"], > # extra_link_args=['-framework', 'Carbon']), > Extension('_AE', [find_module(x) for x in ['ae/_AEmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_AH', [find_module(x) for x in ['ah/_AHmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_App', [find_module(x) for x in ['app/_Appmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_CarbonEvt', [find_module(x) for x in ['carbonevt/_CarbonEvtmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_CG', [find_module(x) for x in ['cg/_CGmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'ApplicationServices', > '-framework', 'Carbon']), > Extension('_Cm', [find_module(x) for x in ['cm/_Cmmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Ctl', [find_module(x) for x in ['ctl/_Ctlmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Dlg', [find_module(x) for x in ['dlg/_Dlgmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Drag', [find_module(x) for x in ['drag/_Dragmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Evt', [find_module(x) for x in ['evt/_Evtmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_File', [find_module(x) for x in ['file/_Filemodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Folder', [find_module(x) for x in ['folder/_Foldermodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Fm', [find_module(x) for x in ['fm/_Fmmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Help', [find_module(x) for x in ['help/_Helpmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Icn', [find_module(x) for x in ['icn/_Icnmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_IBCarbon', [find_module(x) for x in ['ibcarbon/_IBCarbon.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_List', [find_module(x) for x in ['list/_Listmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Menu', [find_module(x) for x in ['menu/_Menumodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Mlte', [find_module(x) for x in ['mlte/_Mltemodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Qd', [find_module(x) for x in ['qd/_Qdmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Qdoffs', [find_module(x) for x in ['qdoffs/_Qdoffsmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Qt', [find_module(x) for x in ['qt/_Qtmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'QuickTime', > '-framework', 'Carbon']), > Extension('_Scrap', [find_module(x) for x in ['scrap/_Scrapmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_TE', [find_module(x) for x in ['te/_TEmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Win', [find_module(x) for x in ['win/_Winmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), 84,85c236,241 < waste_Extension() < ) \ No newline at end of file --- > waste_Extension() + > detect_tkinter_darwin() > ) > > > --Apple-Mail-8--41452356-- From bob@redivi.com Mon Feb 10 08:33:19 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 10 Feb 2003 03:33:19 -0500 Subject: [Pythonmac-SIG] Building Mac extensions for Apple Python In-Reply-To: <83540882-3C90-11D7-9779-000A95686CD8@redivi.com> Message-ID: <4F02A8F0-3CD2-11D7-9779-000A95686CD8@redivi.com> --Apple-Mail-10--13193347 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Sunday, Feb 9, 2003, at 19:42 America/New_York, Bob Ippolito wrote: > > On Sunday, Feb 9, 2003, at 18:09 America/New_York, Bob Ippolito wrote: > >> On Friday, Jan 3, 2003, at 16:52 America/New_York, Kevin Ollivier >> wrote: >> >>> Hi Jack, >>> >>> Thanks for your help! I am also clueless as to why PyObject_Del >>> would be causing that error message. Do those extensions get built >>> with a framework build as well? I did some playing around (removing >>> the extensions that were not building and changing >>> $(scripts)/Lib/Mac to its new home), but I'm getting import errors >>> for the mac modules during the import_BuildApplet phase. It cannot >>> find import macfsn and EasyDialogs, which are of course in the CVS >>> but the path is probably not set properly. Are these supposed to be >>> copied over to /Applications/MacPython-OSX-2.3 before this portion >>> of setup is run? >> >> I took a look at this yesterday, as I was trying to do some stuff >> with quicktime and I thought it'd be nice to be able to backport it >> to jaguar python. I had some problems with this, because >> Makefile.jaguar is broken, so I tried doing what I wanted in ctypes, >> but that gave me bus errors left and right just defining Structures >> and whatnot, so I had to stop there.. and then I started writing my >> own python extension, but that started taking too long.. so I think >> I'm going to try and fix Makefile.jaguar again. >> >> Anyways, here's the definition of PyObject_Del: >> #define PyObject_Del(op) _PyObject_Del((PyObject *)(op)) >> >> See the problem is that in the implementation of _AE, and the other >> modules that cause problems, we're attempting to put this macro >> inside of a type definition. You can't get a pointer to PyObject_Del >> because it's not an actual function, it's a macro function. My lazy >> fix was just to load each file that had this issue and do this (in >> vim) :%s/(#define.*)\> it. Right now, the problem seems to be that a large number of the >> Mac modules are not built at all by Makefile.jaguar, so I'm going to >> have to start getting into setup.jaguar.py. >> > > This is my preliminary fix, please be sure to read the updated > README.JAGUAR, as two additional steps are necessary (modification to > Python.h to get around the lack of bool and add some missing macros, > and the and modification to site.py to get around the lack of bool). > > I don't know how to use any of these modules yet, so I haven't done > testing.. but they all compile except Nav, which I had to comment out. > It's got some reference to AEDesc_NewBorrowed or something of the > like, which is defined as a C function in the module _AE -- but is > used as a python function argument in Nav.. so something seems fishy > there. Again, I don't know enough about Carbon / Toolbox to figure > out what it's trying to do and how to fix it. > > -bob > > this is the output of: cvs diff dist/src/Mac > jagfixes.diff I've made more changes, it's now possible to create quicktime movies with jaguar Python 2.2 with these fixes (same command line). I basically changed a little bit of the argument parsing, and added a Qt.CompressImage function. Note that it's probably bad form that I'm not doing this in the templates that these files get autogenerated from, but I don't understand that module yet so I went ahead and hacked at the output files by hand. Also attached is a sample python program using Numeric and PIL to create a quicktime (just a video track) from a list of image files (must be same dimensions, and PIL must spit out RGB or RGBA strings from them). I'm a little bit late on the solution, since the question was asked in 2001 ( http://mail.python.org/pipermail/pythonmac-sig/2001-October/004246.html ), but better late than never :) Since it's mostly Python, and it copies a lot of memory around, it's not fast. If we start using this tool regularly in the office I'll probably have to write some Numeric + PIL hacks to swizzle the bits and junk them into the GWorld pixMap with Altivec. -bob --Apple-Mail-10--13193347 Content-Disposition: attachment; filename=jagfixes.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="jagfixes.diff" ? dist/src/Mac/Demo/PICTbrowse/PICTbrowse.rsrc.df.rsrc ? dist/src/Mac/Tools/IDE/PythonIDE.rsrc.df.rsrc ? dist/src/Mac/scripts/BuildApplet.rsrc.df.rsrc Index: dist/src/Mac/Modules/ae/_AEmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/ae/_AEmodule.c,v retrieving revision 1.19 diff -r1.19 _AEmodule.c 7d6 < 897c896 < #define AEDesc_tp_free PyObject_Del --- > #define AEDesc_tp_free _PyObject_Del Index: dist/src/Mac/Modules/app/_Appmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/app/_Appmodule.c,v retrieving revision 1.17 diff -r1.17 _Appmodule.c 140c140 < #define ThemeDrawingStateObj_tp_free PyObject_Del --- > #define ThemeDrawingStateObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/carbonevt/_CarbonEvtmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/carbonevt/_CarbonEvtmodule.c,v retrieving revision 1.14 diff -r1.14 _CarbonEvtmodule.c 435c435 < #define EventRef_tp_free PyObject_Del --- > #define EventRef_tp_free _PyObject_Del 655c655 < #define EventQueueRef_tp_free PyObject_Del --- > #define EventQueueRef_tp_free _PyObject_Del 784c784 < #define EventLoopRef_tp_free PyObject_Del --- > #define EventLoopRef_tp_free _PyObject_Del 931c931 < #define EventLoopTimerRef_tp_free PyObject_Del --- > #define EventLoopTimerRef_tp_free _PyObject_Del 1123c1123 < #define EventHandlerRef_tp_free PyObject_Del --- > #define EventHandlerRef_tp_free _PyObject_Del 1255c1255 < #define EventHandlerCallRef_tp_free PyObject_Del --- > #define EventHandlerCallRef_tp_free _PyObject_Del 1409c1409 < #define EventTargetRef_tp_free PyObject_Del --- > #define EventTargetRef_tp_free _PyObject_Del 1538c1538 < #define EventHotKeyRef_tp_free PyObject_Del --- > #define EventHotKeyRef_tp_free _PyObject_Del Index: dist/src/Mac/Modules/cg/_CGmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/cg/_CGmodule.c,v retrieving revision 1.11 diff -r1.11 _CGmodule.c 1293c1293 < #define CGContextRefObj_tp_free PyObject_Del --- > #define CGContextRefObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/cm/_Cmmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/cm/_Cmmodule.c,v retrieving revision 1.15 diff -r1.15 _Cmmodule.c 284c284 < #define CmpInstObj_tp_free PyObject_Del --- > #define CmpInstObj_tp_free _PyObject_Del 717c717 < #define CmpObj_tp_free PyObject_Del --- > #define CmpObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/ctl/_Ctlmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/ctl/_Ctlmodule.c,v retrieving revision 1.24 diff -r1.24 _Ctlmodule.c 3897c3897 < #define CtlObj_tp_free PyObject_Del --- > #define CtlObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/dlg/_Dlgmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/dlg/_Dlgmodule.c,v retrieving revision 1.17 diff -r1.17 _Dlgmodule.c 980c980 < #define DlgObj_tp_free PyObject_Del --- > #define DlgObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/drag/_Dragmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/drag/_Dragmodule.c,v retrieving revision 1.14 diff -r1.14 _Dragmodule.c 767c767 < #define DragObj_tp_free PyObject_Del --- > #define DragObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/file/_Filemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/file/_Filemodule.c,v retrieving revision 1.17 diff -r1.17 _Filemodule.c 415c415 < #define FSCatalogInfo_tp_free PyObject_Del --- > #define FSCatalogInfo_tp_free _PyObject_Del 600c600 < #define FInfo_tp_free PyObject_Del --- > #define FInfo_tp_free _PyObject_Del 946c946 < #define Alias_tp_free PyObject_Del --- > #define Alias_tp_free _PyObject_Del 1405c1405 < #define FSSpec_tp_free PyObject_Del --- > #define FSSpec_tp_free _PyObject_Del 1972c1972 < #define FSRef_tp_free PyObject_Del --- > #define FSRef_tp_free _PyObject_Del Index: dist/src/Mac/Modules/ibcarbon/_IBCarbon.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/ibcarbon/_IBCarbon.c,v retrieving revision 1.7 diff -r1.7 _IBCarbon.c 167c167 < #define IBNibRefObj_tp_free PyObject_Del --- > #define IBNibRefObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/list/_Listmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/list/_Listmodule.c,v retrieving revision 1.16 diff -r1.16 _Listmodule.c 787c787 < #define ListObj_tp_free PyObject_Del --- > #define ListObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/menu/_Menumodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/menu/_Menumodule.c,v retrieving revision 1.17 diff -r1.17 _Menumodule.c 2571c2571 < #define MenuObj_tp_free PyObject_Del --- > #define MenuObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/mlte/_Mltemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/mlte/_Mltemodule.c,v retrieving revision 1.17 diff -r1.17 _Mltemodule.c 1296c1296 < #define TXNObj_tp_free PyObject_Del --- > #define TXNObj_tp_free _PyObject_Del 1449c1449 < #define TXNFontMenuObj_tp_free PyObject_Del --- > #define TXNFontMenuObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/qd/_Qdmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/qd/_Qdmodule.c,v retrieving revision 1.16 diff -r1.16 _Qdmodule.c 1086c1086 < #define GrafObj_tp_free PyObject_Del --- > #define GrafObj_tp_free _PyObject_Del 1284c1284 < #define BMObj_tp_free PyObject_Del --- > #define BMObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/qdoffs/_Qdoffsmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/qdoffs/_Qdoffsmodule.c,v retrieving revision 1.13 diff -r1.13 _Qdoffsmodule.c 158c158 < #define GWorldObj_tp_free PyObject_Del --- > #define GWorldObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/qt/_Qtmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/qt/_Qtmodule.c,v retrieving revision 1.15 diff -r1.15 _Qtmodule.c 1117c1117 < #define MovieCtlObj_tp_free PyObject_Del --- > #define MovieCtlObj_tp_free _PyObject_Del 1605c1605 < #define TimeBaseObj_tp_free PyObject_Del --- > #define TimeBaseObj_tp_free _PyObject_Del 1946c1946 < #define UserDataObj_tp_free PyObject_Del --- > #define UserDataObj_tp_free _PyObject_Del 3158c3158 < #define MediaObj_tp_free PyObject_Del --- > #define MediaObj_tp_free _PyObject_Del 3764,3765c3764,3765 < Handle dataRef; < OSType dataRefType; --- > Handle dataRef = NULL; > OSType dataRefType = 0; 3769c3769 < if (!PyArg_ParseTuple(_args, "O&lO&O&", --- > if (!PyArg_ParseTuple(_args, "O&l|O&O&", 4476c4476 < #define TrackObj_tp_free PyObject_Del --- > #define TrackObj_tp_free _PyObject_Del 6163c6163 < short resId; --- > short resId = nil; 6168c6168 < if (!PyArg_ParseTuple(_args, "hO&", --- > if (!PyArg_ParseTuple(_args, "hO&|h", 6170c6170,6171 < PyMac_GetStr255, resName)) --- > PyMac_GetStr255, resName, > &resId)) 6781c6782 < PyDoc_STR("(short resRefNum, Str255 resName) -> (short resId)")}, --- > PyDoc_STR("(short resRefNum, Str255 resName, [short resId]) -> (short resId)")}, 6849c6850 < #define MovieObj_tp_free PyObject_Del --- > #define MovieObj_tp_free _PyObject_Del 9495a9497,9585 > /* !!! MODIFIED !!! */ > static PyObject *Qt_GetMaxCompressionSize(PyObject *_self, PyObject *_args) > { > Rect trackFrame; > GWorldPtr gw; > OSErr _err = noErr; > CodecQ codecQuality = codecNormalQuality; > CodecType codecType = kRawCodecType; > CompressorComponent codec = anyCodec; > long size; > #ifndef GetMaxCompressionSize > PyMac_PRECHECK(GetMaxCompressionSize); > #endif > if (!PyArg_ParseTuple(_args, "O&O&|lO&l", > GWorldObj_Convert, &gw, > PyMac_GetRect, &trackFrame, > (long*)&codecQuality, > PyMac_GetOSType, (OSType*)&codecType, > (long*)&codec)) > return NULL; > _err = GetMaxCompressionSize(GetGWorldPixMap(gw), /* Handle to the source image */ > &trackFrame, /* bounds */ > 32, /* let ICM choose depth */ > codecQuality, /* desired image quality */ > codecType, /* compressor type */ > codec, /* compressor identifier */ > &size); /* returned size */ > if (_err != noErr) return PyMac_Error(_err); > return PyInt_FromLong(size); > } > > /* !!! MODIFIED !!! */ > static PyObject *Qt_CompressImage(PyObject *_self, PyObject *_args) > { > GWorldPtr gw; > OSErr _err = noErr; > Rect trackFrame; > CodecQ codecQuality = codecNormalQuality; > CodecType codecType = kRawCodecType; > CompressorComponent codec = anyCodec; > long size; > Handle compressedData = nil; > Ptr compressedDataPtr; > ImageDescriptionHandle imageDesc = nil; > PyObject *_res; > #ifndef CompressImage > PyMac_PRECHECK(CompressImage); > #endif > if (!PyArg_ParseTuple(_args, "O&O&|lO&l", > GWorldObj_Convert, &gw, > PyMac_GetRect, &trackFrame, > (long*)&codecQuality, > PyMac_GetOSType, (OSType*)&codecType, > (long*)&codec)) > return NULL; > _err = GetMaxCompressionSize(GetGWorldPixMap(gw), /* Handle to the source image */ > &trackFrame, /* bounds */ > 32, /* let ICM choose depth */ > codecQuality, /* desired image quality */ > codecType, /* compressor type */ > codec, /* compressor identifier */ > &size); /* returned size */ > if (_err != noErr) return PyMac_Error(_err); > > compressedData = NewHandle(size); > _err = MemError(); > if (_err != noErr) return PyMac_Error(_err); > MoveHHi( compressedData ); > HLock( compressedData ); > compressedDataPtr = *compressedData; > > imageDesc = (ImageDescriptionHandle)NewHandle(4); > _err = MemError(); > if (_err != noErr) return PyMac_Error(_err); > > _err = CompressImage(GetGWorldPixMap(gw), /* source image to compress */ > &trackFrame, /* bounds */ > codecQuality, /* desired image quality */ > codecType, /* compressor identifier */ > imageDesc, /* handle to Image Description Structure; will be resized by call */ > compressedDataPtr); /* pointer to a location to recieve the compressed image data */ > if (_err != noErr) return PyMac_Error(_err); > _res = Py_BuildValue("O&O&l", > ResObj_New, (Handle)imageDesc, > ResObj_New, (Handle)compressedData, > (**imageDesc).dataSize); > return _res; > } > 9710a9801,9805 > /* !!! MODIFIED !!! */ > {"GetMaxCompressionSize", (PyCFunction)Qt_GetMaxCompressionSize, 1, > PyDoc_STR("(GWorldPtr gw, Rect trackFrame, CodecQ codecQuality, OSType codecType, CodecFlags codecFlags) -> int")}, > {"CompressImage", (PyCFunction)Qt_CompressImage, 1, > PyDoc_STR("(GWorldPtr gw, Rect trackFrame, CodecQ codecQuality, OSType codecType, CodecFlags codecFlags) -> (Handle imgDesc, Handle compressedData, int dataSize)")}, 9713,9714d9807 < < Index: dist/src/Mac/Modules/res/_Resmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/res/_Resmodule.c,v retrieving revision 1.19 diff -r1.19 _Resmodule.c 628c628 < #define ResObj_tp_free PyObject_Del --- > #define ResObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/te/_TEmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/te/_TEmodule.c,v retrieving revision 1.15 diff -r1.15 _TEmodule.c 1007c1007 < #define TEObj_tp_free PyObject_Del --- > #define TEObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/waste/wastemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/waste/wastemodule.c,v retrieving revision 1.31 diff -r1.31 wastemodule.c 423c423 < #define WEOObj_tp_free PyObject_Del --- > #define WEOObj_tp_free _PyObject_Del 2172c2172 < #define wasteObj_tp_free PyObject_Del --- > #define wasteObj_tp_free _PyObject_Del Index: dist/src/Mac/Modules/win/_Winmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/Modules/win/_Winmodule.c,v retrieving revision 1.17 diff -r1.17 _Winmodule.c 2583c2583 < #define WinObj_tp_free PyObject_Del --- > #define WinObj_tp_free _PyObject_Del Index: dist/src/Mac/OSX/Makefile.jaguar =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/Makefile.jaguar,v retrieving revision 1.4 diff -r1.4 Makefile.jaguar 70c70 < $(PYTHON) $(srcdir)/Mac/Lib/bundlebuilder.py -q --link-exec \ --- > $(PYTHON) $(srcdir)/Lib/plat-mac/bundlebuilder.py -q --link-exec \ Index: dist/src/Mac/OSX/README.JAGUAR =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/README.JAGUAR,v retrieving revision 1.1 diff -r1.1 README.JAGUAR 28a29,41 > 3. Add the following to /usr/include/python2.2/Python.h > #define PyDoc_VAR(name) static char name[] > #define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str) > #ifdef WITH_DOC_STRINGS > #define PyDoc_STR(str) str > #else > #define PyDoc_STR(str) "" > #endif > #define PyBool_Check PyObject_IsTrue > #define PyBool_FromLong PyInt_FromLong > 4. Add the following to /usr/lib/python2.2/site.py > __builtin__.True = not 0 > __builtin__.False = not not 0 Index: dist/src/Mac/OSX/setup.jaguar.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Mac/OSX/setup.jaguar.py,v retrieving revision 1.3 diff -r1.3 setup.jaguar.py 41c41,92 < --- > > def detect_tkinter_darwin(): > # The _tkinter module, using frameworks. Since frameworks are quite > # different the UNIX search logic is not sharable. > from os.path import join, exists > framework_dirs = [ > '/System/Library/Frameworks/', > '/Library/Frameworks', > join(os.getenv('HOME'), '/Library/Frameworks') > ] > > # Find the directory that contains the Tcl.framwork and Tk.framework > # bundles. > # XXX distutils should support -F! > for F in framework_dirs: > # both Tcl.framework and Tk.framework should be present > for fw in 'Tcl', 'Tk': > if not exists(join(F, fw + '.framework')): > break > else: > # ok, F is now directory with both frameworks. Continure > # building > break > else: > # Tk and Tcl frameworks not found. Normal "unix" tkinter search > # will now resume. > return [] > > # For 8.4a2, we must add -I options that point inside the Tcl and Tk > # frameworks. In later release we should hopefully be able to pass > # the -F option to gcc, which specifies a framework lookup path. > # > include_dirs = [ > join(F, fw + '.framework', H) > for fw in 'Tcl', 'Tk' > for H in 'Headers', 'Versions/Current/PrivateHeaders' > ] > > # For 8.4a2, the X11 headers are not included. Rather than include a > # complicated search, this is a hard-coded path. It could bail out > # if X11 libs are not found... > include_dirs.append('/usr/X11R6/include') > frameworks = ['-framework', 'Tcl', '-framework', 'Tk'] > > return [Extension('_tkinter', [SRCDIR+'/Modules/_tkinter.c', SRCDIR+'/Modules/tkappinit.c'], > define_macros=[('WITH_APPINIT', 1)], > include_dirs = include_dirs, > libraries = [], > extra_compile_args = frameworks, > extra_link_args = frameworks, > )] > 64a116,118 > def find_module(x): > return '%s/Mac/Modules/%s' % (SRCDIR, x) > 66a121,218 > Extension('_CF', [find_module(x) for x in 'cf/_CFmodule.c', 'cf/pycfbridge.c'], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'CoreFoundation']), > Extension('gestalt', [find_module(x) for x in ['gestaltmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('MacOS', [find_module(x) for x in ['macosmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('icglue', [find_module(x) for x in ['icgluemodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Res', [find_module(x) for x in ['res/_Resmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Snd', [find_module(x) for x in ['snd/_Sndmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > #Extension('Nav', [find_module(x) for x in ['Nav.c']], > # include_dirs=[SRCDIR+"/Mac/Include"], > # extra_link_args=['-framework', 'Carbon']), > Extension('_AE', [find_module(x) for x in ['ae/_AEmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_AH', [find_module(x) for x in ['ah/_AHmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_App', [find_module(x) for x in ['app/_Appmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_CarbonEvt', [find_module(x) for x in ['carbonevt/_CarbonEvtmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_CG', [find_module(x) for x in ['cg/_CGmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'ApplicationServices', > '-framework', 'Carbon']), > Extension('_Cm', [find_module(x) for x in ['cm/_Cmmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Ctl', [find_module(x) for x in ['ctl/_Ctlmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Dlg', [find_module(x) for x in ['dlg/_Dlgmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Drag', [find_module(x) for x in ['drag/_Dragmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Evt', [find_module(x) for x in ['evt/_Evtmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_File', [find_module(x) for x in ['file/_Filemodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Folder', [find_module(x) for x in ['folder/_Foldermodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Fm', [find_module(x) for x in ['fm/_Fmmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Help', [find_module(x) for x in ['help/_Helpmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Icn', [find_module(x) for x in ['icn/_Icnmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_IBCarbon', [find_module(x) for x in ['ibcarbon/_IBCarbon.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_List', [find_module(x) for x in ['list/_Listmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Menu', [find_module(x) for x in ['menu/_Menumodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Mlte', [find_module(x) for x in ['mlte/_Mltemodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Qd', [find_module(x) for x in ['qd/_Qdmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Qdoffs', [find_module(x) for x in ['qdoffs/_Qdoffsmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Qt', [find_module(x) for x in ['qt/_Qtmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'QuickTime', > '-framework', 'Carbon']), > Extension('_Scrap', [find_module(x) for x in ['scrap/_Scrapmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_TE', [find_module(x) for x in ['te/_TEmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), > Extension('_Win', [find_module(x) for x in ['win/_Winmodule.c']], > include_dirs=[SRCDIR+"/Mac/Include"], > extra_link_args=['-framework', 'Carbon']), 84,85c236,241 < waste_Extension() < ) \ No newline at end of file --- > waste_Extension() + > detect_tkinter_darwin() > ) > > > --Apple-Mail-10--13193347 Content-Disposition: attachment; filename=makeQt.py Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="makeQt.py" from __future__ import generators import sys # make sure ours get loaded, not 2.2 stock junk sys.path.insert(0, 'lib-dynload') import _Qt from Carbon import Qt, QuickTime, Qd, Qdoffs, QuickDraw, QDOffscreen, Res import Image import Numeric try: import SoftimageImage except: # this is just a PIL codec I wrote to load SoftImage PICT files.. the reason I looked into this junk pass def argDict(**kwargs): return kwargs # compression constants CODECS = argDict( kRawCodecType = 'raw ', kCinepakCodecType = 'cvid', kGraphicsCodecType = 'smc ', kAnimationCodecType = 'rle ', kVideoCodecType = 'rpza', kComponentVideoCodecType = 'yuv2', kJPEGCodecType = 'jpeg', kMotionJPEGACodecType = 'mjpa', kMotionJPEGBCodecType = 'mjpb', kSGICodecType = '.SGI', kPlanarRGBCodecType = '8BPS', kMacPaintCodecType = 'PNTG', kGIFCodecType = 'gif ', kPhotoCDCodecType = 'kpcd', kQuickDrawGXCodecType = 'qdgx', kAVRJPEGCodecType = 'avr ', kOpenDMLJPEGCodecType = 'dmb1', kBMPCodecType = 'WRLE', kWindowsRawCodecType = 'WRAW', kVectorCodecType = 'path', kQuickDrawCodecType = 'qdrw', kWaterRippleCodecType = 'ripl', kFireCodecType = 'fire', kCloudCodecType = 'clou', kH261CodecType = 'h261', kH263CodecType = 'h263', kDVCNTSCCodecType = 'dvc ', kDVCPALCodecType = 'dvcp', kDVCProPALCodecType = 'dvpp', kBaseCodecType = 'base', kFLCCodecType = 'flic', kTargaCodecType = 'tga ', kPNGCodecType = 'png ', kTIFFCodecType = 'tiff', kComponentVideoSigned = 'yuvu', kComponentVideoUnsigned = 'yuvs', kCMYKCodecType = 'cmyk', kMicrosoftVideo1CodecType = 'msvc', kSorensonCodecType = 'SVQ1', kSorenson3CodecType = 'SVQ3', kIndeo4CodecType = 'IV41', kMPEG4VisualCodecType = 'mp4v', k64ARGBCodecType = 'b64a', k48RGBCodecType = 'b48r', k32AlphaGrayCodecType = 'b32a', k16GrayCodecType = 'b16g', kMpegYUV420CodecType = 'myuv', kYUV420CodecType = 'y420', kSorensonYUV9CodecType = 'syv9', k422YpCbCr8CodecType = '2vuy', k444YpCbCr8CodecType = 'v308', k4444YpCbCrA8CodecType = 'v408', k422YpCbCr16CodecType = 'v216', k422YpCbCr10CodecType = 'v210', k444YpCbCr10CodecType = 'v410', k4444YpCbCrA8RCodecType = 'r408') # quality constants CODECQUALITY = argDict( codecLosslessQuality = 0x00000400, codecMaxQuality = 0x000003FF, codecMinQuality = 0x00000000, codecLowQuality = 0x00000100, codecNormalQuality = 0x00000200, codecHighQuality = 0x00000300 ) def to_fps(n): # 1 fps = 600 # 10 fps = 60 return int(600.0 / float(n)) def makeQuicktimeFromFiles(qtFilename, images, codec = CODECS['kRawCodecType'], codecq = CODECQUALITY['codecLosslessQuality'], fps = 30.0): """Returns an iterator that yields for each frame rendered""" size = Image.open(images[0]).size fps = to_fps(fps) left, top, right, bottom = RECT = (0, 0) + size Qt.EnterMovies() open(qtFilename, 'w').close() res, mov = Qt.CreateMovieFile(qtFilename, 'TVOD', -2, 0x80000000 | 0x10000000) track = mov.NewMovieTrack(right, bottom, 0x100) media = track.NewTrackMedia('vide', 600) media.BeginMediaEdits() gworld = Qdoffs.NewGWorld(32, RECT, None, None, 0) Qdoffs.LockPixels(gworld.GetGWorldPixMap()) oldGWorld = Qdoffs.GetGWorld() Qdoffs.SetGWorld(gworld.as_GrafPtr(), None) pixMap = gworld.GetGWorldPixMap() pixRowBytes = Qdoffs.GetPixRowBytes(pixMap) widthBytes = right * 4 output = Numeric.zeros((widthBytes,), 'b') for file in images: inputImg = Image.open(file) assert inputImg.size == size inputStr = inputImg.tostring() inputDepth = len(inputStr) / (right * bottom) del inputImg if inputDepth == 3: input = Numeric.reshape(Numeric.fromstring(inputStr, 'b'), (bottom, right * 3)) output[0::4] = 0xff for scanline in range(bottom): iscan = input[scanline] output[1::4] = iscan[0::3] output[2::4] = iscan[1::3] output[3::4] = iscan[2::3] Qdoffs.PutPixMapBytes(pixMap, scanline * pixRowBytes, output.tostring()) elif inputDepth == 4: input = Numeric.reshape(Numeric.fromstring(inputStr, 'b'), (bottom, widthBytes)) for scanline in range(bottom): iscan = input[scanline] output[0::4] = iscan[3::4] output[1::4] = iscan[0::4] output[2::4] = iscan[1::4] output[3::4] = iscan[2::4] Qdoffs.PutPixMapBytes(pixMap, scanline * pixRowBytes, output.tostring()) else: raise ValueError, 'Must be RGB or RGBA!' imgDescHandle, dataHandle, dataLen = Qt.CompressImage(gworld, RECT, codecq, codec) sampleTime = media.AddMediaSample(dataHandle, 0, dataLen, fps, imgDescHandle, 1, 0) del dataHandle del imgDescHandle yield file Qdoffs.UnlockPixels(gworld.GetGWorldPixMap()) Qdoffs.SetGWorld(*oldGWorld) del gworld del oldGWorld media.EndMediaEdits() track.InsertMediaIntoTrack(0, 0, media.GetMediaDuration(), 1.0) resId = mov.AddMovieResource(res, 'Video', -1) if res: Qt.CloseMovieFile(res) del media del track del mov if __name__ == '__main__': import sys quicktime = sys.argv[1] files = sys.argv[2:] for filename in makeQuicktimeFromFiles(quicktime, files): print filename --Apple-Mail-10--13193347-- From Jack.Jansen@cwi.nl Mon Feb 10 16:07:48 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 10 Feb 2003 17:07:48 +0100 Subject: [Pythonmac-SIG] Install manager engine available Message-ID: Folks, the install manager for Python we discussed last fall is available. At least: the engine is. At least: there's enough of the engine that it managed to install Numeric and PIL, and actually notice it had done so:-) It is called the Package Install Manager for Python and it lives in Lib/plat-mac/pimp.py. If you wonder about the name, think that "it may be shabby, but it gets you what you need" :-) There's docstrings all over the place, and that is also the only documentation. The pimp module has a minimal commandline interface, I'm going to work on a GUI next. It only works for Python 2.3a1 on MacOSX 10.2 at the moment, but I would at least like it to work for older Pythons and older MacOSX releases as well, so any help there is appreciated. I would like it if people could test this with other packages (wxMac, PyOpenGL, PyObjC, etc), and if they could test it with binary packages. For 2.3a2 I would like to have a sizable number of packages in there (at least the 5 mentioned above, maybe more). During development I guess it's probably best if I am the maintainer of the pimp database, but I would like to push that responsibility off as soon as possible, so if anyone feels like doing this: please speak up! If you try this with your favorite package and notice there is functionality missing: speak up! I would like to keep functionality as minimal as possible, but no smaller. (As an example: I had to add the preInstall functionality today because "python setup.py install" isn't enough for PIL. You need to run configure and make too). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From pecora@anvil.nrl.navy.mil Mon Feb 10 16:17:45 2003 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Mon, 10 Feb 2003 11:17:45 -0500 Subject: [Pythonmac-SIG] PLPlot on Mac? Advice. Message-ID: I've looked over PLPlot (see SourceForge) and it looks pretty nice. It's free, but looks well supported. My question: Has anyone actually installed this package on their Mac and used it in Python? The claims in the documentation are that it is doable, but not much info on how, except for the Unix end of things (maybe that means Unix approach using OS X, I don't know). Is this usable in system 9? By compiling with Codewarrior? I've done some Google searching, but haven't come up with much online. Just wondered what people here have done with this package, if anything. Thanks. -- Cheers, Lou Pecora From english@spiritone.com Mon Feb 10 20:58:26 2003 From: english@spiritone.com (Josh English) Date: 10 Feb 2003 12:58:26 -0800 Subject: [Pythonmac-SIG] Accessing the clipboard Message-ID: <3E481271.799AF43E@spiritone.com> I've been reading through the docs but I can't find any method for reading and writing to the Macintosh clipboard. Is this possible with Python 2.2 and Mac OS 9? I am looking specifically for a utility to edit the content of the clipboard, say, change the HTML links to lowercase or remove/add quote symbols and I can't find a decent utility to do this, so I figured I'd try to write one and make a CSM our of it. Thanks, Josh English From Jack.Jansen@cwi.nl Tue Feb 11 09:58:24 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 11 Feb 2003 10:58:24 +0100 Subject: [Pythonmac-SIG] Accessing the clipboard In-Reply-To: <3E481271.799AF43E@spiritone.com> Message-ID: <5C30475C-3DA7-11D7-8CF6-0030655234CE@cwi.nl> On Monday, Feb 10, 2003, at 21:58 Europe/Amsterdam, Josh English wrote: > I've been reading through the docs but I can't find any method for > reading and writing to the Macintosh clipboard. Is this possible with > Python 2.2 and Mac OS 9? > > I am looking specifically for a utility to edit the content of the > clipboard, say, change the HTML links to lowercase or remove/add quote > symbols and I can't find a decent utility to do this, so I figured I'd > try to write one and make a CSM our of it. Look at the Carbon.Scrap module. You should note that this module is completely different under classic PPC and Carbon. And I think that under 2.2 the Carbon version isn't complete (it is under 2.2.2). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From borgempath@Phreaker.net Tue Feb 11 19:13:52 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Wed, 12 Feb 2003 00:43:52 +0530 Subject: [Pythonmac-SIG] open source bbs in Python ? Message-ID: Hello, Does anyone know of any open source bulletin board software written in Python, preferably using PostgreSQL as a backend ? All I seem to be able to find are projects in Perl & PHP, and of course, MySQL. - Joel From Benjamin.Schollnick@usa.xerox.com Tue Feb 11 19:36:46 2003 From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin) Date: Tue, 11 Feb 2003 14:36:46 -0500 Subject: [Pythonmac-SIG] open source bbs in Python ? Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B3573@USAMCMS7> Not that I know of... I keep considering recreating QuickBBS in Python... But have not been able to generate the desire or interest in it... - Benjamin -----Original Message----- From: Joel Rodrigues [mailto:borgempath@Phreaker.net] Sent: Tuesday, February 11, 2003 2:14 PM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] open source bbs in Python ? Hello, Does anyone know of any open source bulletin board software written in Python, preferably using PostgreSQL as a backend ? All I seem to be able to find are projects in Perl & PHP, and of course, MySQL. - Joel _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From ryanwilcox@mac.com Tue Feb 11 19:48:17 2003 From: ryanwilcox@mac.com (Ryan Wilcox) Date: Tue, 11 Feb 2003 14:48:17 -0500 Subject: [Pythonmac-SIG] open source bbs in Python ? In-Reply-To: Message-ID: On Tuesday, February 11, 2003, at 02:13 PM, Joel Rodrigues wrote: > Hello, > > Does anyone know of any open source bulletin board software written in > Python, preferably using PostgreSQL as a backend ? All I seem to be > able to find are projects in Perl & PHP, and of course, MySQL. I was looking for the same thing just yesterday. I settled for the Ultimate PHP Bulletin Board (search sourceforge.net). Ultimately, it wouldn't be _that_ hard to create one in Python -- especially with the anydb module (if it works how I think it works, anyway). HTH, -Ryan Wilcox From bob@redivi.com Wed Feb 12 03:59:31 2003 From: bob@redivi.com (Bob Ippolito) Date: Tue, 11 Feb 2003 22:59:31 -0500 Subject: [Pythonmac-SIG] flat_namespace is _bad_ In-Reply-To: Message-ID: <63EB5B42-3E3E-11D7-8273-000A95686CD8@redivi.com> Just a note that I think you all should know, if you're trying to port *any* python modules to OS X 10.2's Python 2.2, it's a *really good idea* to edit /usr/lib/python2.2/config/Makefile and make this change: LDSHARED= $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/bin/python BLDSHARED= $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/bin/python #LDSHARED= $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined suppress #BLDSHARED= $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined suppress In addition to removing the -arch i386 from elsewhere in the file, which you presumably already have if you've gotten this far. Basically what I really ran into problems with was PyOpenGL, the same symbols were defined in multiple modules.. I could load one, but not the others. Now I can load them all (I'm still not sure if they work or not.. but.. they compile and load now). -bob From petrucha@isnet.sk Wed Feb 12 12:26:53 2003 From: petrucha@isnet.sk (Stefan Petrucha) Date: Wed, 12 Feb 2003 13:26:53 +0100 Subject: [Pythonmac-SIG] Compilation of Core PPC Message-ID: <3E4A3D8D.E9351A46@isnet.sk> (I apologize for bothering again with old stuff.) Were the source packages of MacPython (together with GUSI for MacPython) supposed to build out of the box even the pure-classic version of Python? I had similar problems with sources 2.1.1-2.2.2, mainly: - inconsistency in declarations and definition of the function/procedure sync() - missing library libmoto (What is this library for?) I was able to get it compiled, but back to my first question. Thanks, Stefan Petrucha From boyle5@llnl.gov Wed Feb 12 17:29:30 2003 From: boyle5@llnl.gov (boyle5@llnl.gov) Date: Wed, 12 Feb 2003 09:29:30 -0800 Subject: [Pythonmac-SIG] pyopengl and OS X 10.2.3 Message-ID: <8AEC51DE-3EAF-11D7-B5FE-003065D7F43A@llnl.gov> Has anyone gotten pyOpenGL to run on OS X 10.2.3 with python 2.3? The last posting I was able to find dated from about a year ago, and that only reported limited success for pyOpenGl. I can see that glut is installed as a framework, but I am a bit hazy ( OK, totally ignorant) of how to use this built in capability. My ambition is to get pyopengl + tk(aqua) working. Thanks for any information. Jim From Jack.Jansen@cwi.nl Wed Feb 12 16:40:05 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 12 Feb 2003 17:40:05 +0100 Subject: [Pythonmac-SIG] Install manager - more bits and pieces Message-ID: If you build Python from CVS there's a GUI available to the Package Install Manager for Python. There's a standalone applet PackageManager, and the same interface is accessible through the IDE, with "File"->"Package Manager". -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob@redivi.com Wed Feb 12 17:45:26 2003 From: bob@redivi.com (Bob Ippolito) Date: Wed, 12 Feb 2003 12:45:26 -0500 Subject: [Pythonmac-SIG] pyopengl and OS X 10.2.3 In-Reply-To: <8AEC51DE-3EAF-11D7-B5FE-003065D7F43A@llnl.gov> Message-ID: On Wednesday, Feb 12, 2003, at 12:29 America/New_York, boyle5@llnl.gov wrote: > Has anyone gotten pyOpenGL to run on OS X 10.2.3 with python 2.3? > The last posting I was able to find dated from about a year ago, and > that > only reported limited success for pyOpenGl. > I can see that glut is installed as a framework, but I am a bit hazy ( > OK, totally ignorant) > of how to use this built in capability. > My ambition is to get pyopengl + tk(aqua) working. I just sent a patch to pyopengl's sourceforge page yesterday that gets PyOpenGL working with (apple's stock) python 2.2, my patch integrates jack's older patch and adds some additional niceness. In addition to whatever Jack fixed, my latest patch works around the glutInit problem where the working directory changes, the fact that OS X requires ranlib on static libraries (by poking inside distutils nondestructively, potential for 2.3 to be different about this), and also works around the bug in the 2.2 dynamic loader where two C extensions can't have the same filename (argh!) by renaming all of the __init___.so's to PKGNAME__init___.so.. etc, and creating __init__.py files that do "from PKGNAME__init__ import *" to import the shadow file and get everything out of it. Presumably, it would also work with Python 2.3. Make sure to have Swig 1.3.13 installed, the version is very important.. Jack figured that one out :) -bob From boyle5@llnl.gov Wed Feb 12 22:33:41 2003 From: boyle5@llnl.gov (boyle5@llnl.gov) Date: Wed, 12 Feb 2003 14:33:41 -0800 Subject: [Pythonmac-SIG] pyopengl and OS X 10.2.3 In-Reply-To: Message-ID: <0997C562-3EDA-11D7-B5FE-003065D7F43A@llnl.gov> Bob, Thanks very much for the information. Is there any way of getting your patches , other than the pyopengl SF site? The last patch(as yet unincoporated) for OSX dates back to last June! It appears that there could be a long wait for this patch to be applied. The heads up on Swig version is very useful, I burned an entire afternoon because of this when I built pyopengl on my Linux box. Jim On Wednesday, February 12, 2003, at 09:45 AM, Bob Ippolito wrote: > > I just sent a patch to pyopengl's sourceforge page yesterday that gets > PyOpenGL working with (apple's stock) python 2.2, my patch integrates > jack's older patch and adds some additional niceness. In addition to > whatever Jack fixed, my latest patch works around the glutInit problem > where the working directory changes, the fact that OS X requires > ranlib on static libraries (by poking inside distutils > nondestructively, potential for 2.3 to be different about this), and > also works around the bug in the 2.2 dynamic loader where two C > extensions can't have the same filename (argh!) by renaming all of the > __init___.so's to PKGNAME__init___.so.. etc, and creating __init__.py > files that do "from PKGNAME__init__ import *" to import the shadow > file and get everything out of it. > > Presumably, it would also work with Python 2.3. > > Make sure to have Swig 1.3.13 installed, the version is very > important.. Jack figured that one out :) > > -bob > From bob@redivi.com Wed Feb 12 22:53:22 2003 From: bob@redivi.com (Bob Ippolito) Date: Wed, 12 Feb 2003 17:53:22 -0500 Subject: [Pythonmac-SIG] pyopengl and OS X 10.2.3 In-Reply-To: <0997C562-3EDA-11D7-B5FE-003065D7F43A@llnl.gov> Message-ID: You can download the patch tarball from here: http://sourceforge.net/tracker/ index.php?func=detail&aid=685142&group_id=5988&atid=305988 There's more info about what the patch changes and some useful information regarding how to use it here: http://sourceforge.net/tracker/ index.php?func=detail&aid=544084&group_id=5988&atid=105988 make *sure* that you delete the __init__.i files from interfaces/*/ cause if they compile it's bad news for apple python 2.2. On Wednesday, Feb 12, 2003, at 17:33 America/New_York, boyle5@llnl.gov wrote: > Bob, > > Thanks very much for the information. > > Is there any way of getting your patches , other than the pyopengl SF > site? > The last patch(as yet unincoporated) for OSX dates back to last June! > It appears that there could be a long wait for this patch to be > applied. > > The heads up on Swig version is very useful, I burned an entire > afternoon because of this when I built pyopengl on my Linux box. > > Jim > > On Wednesday, February 12, 2003, at 09:45 AM, Bob Ippolito wrote: >> >> I just sent a patch to pyopengl's sourceforge page yesterday that >> gets PyOpenGL working with (apple's stock) python 2.2, my patch >> integrates jack's older patch and adds some additional niceness. In >> addition to whatever Jack fixed, my latest patch works around the >> glutInit problem where the working directory changes, the fact that >> OS X requires ranlib on static libraries (by poking inside distutils >> nondestructively, potential for 2.3 to be different about this), and >> also works around the bug in the 2.2 dynamic loader where two C >> extensions can't have the same filename (argh!) by renaming all of >> the __init___.so's to PKGNAME__init___.so.. etc, and creating >> __init__.py files that do "from PKGNAME__init__ import *" to import >> the shadow file and get everything out of it. >> >> Presumably, it would also work with Python 2.3. >> >> Make sure to have Swig 1.3.13 installed, the version is very >> important.. Jack figured that one out :) >> >> -bob >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From borgempath@Phreaker.net Thu Feb 13 05:23:40 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Thu, 13 Feb 2003 10:53:40 +0530 Subject: [Pythonmac-SIG] open source bbs in Python ? In-Reply-To: Message-ID: <4FB0EBB4-3F13-11D7-899E-0005024EF27F@Phreaker.net> On Wednesday, February 12, 2003, at 01:18 , Ryan Wilcox wrote: > On Tuesday, February 11, 2003, at 02:13 PM, Joel Rodrigues wrote: > >> Hello, >> >> Does anyone know of any open source bulletin board software >> written in Python, preferably using PostgreSQL as a backend ? >> All I seem to be able to find are projects in Perl & PHP, and >> of course, MySQL. > > I was looking for the same thing just yesterday. I settled for > the Ultimate PHP Bulletin Board (search sourceforge.net). > > Ultimately, it wouldn't be _that_ hard to create one in > Python -- especially with the anydb module (if it works how I > think it works, anyway). Thanks for the info Ryan, Benjamin. If I have no choice, I'd settle for Perl until I can figure out to how / get around write to writing one at least for my own use in Python with PostgreSQL. Not interested in PHP. Cheers, - Joel From pecora@anvil.nrl.navy.mil Thu Feb 13 17:39:49 2003 From: pecora@anvil.nrl.navy.mil (Louis M. Pecora) Date: Thu, 13 Feb 2003 12:39:49 -0500 Subject: [Pythonmac-SIG] PLPlot on Mac? Advice. In-Reply-To: References: Message-ID: > >>I've looked over PLPlot (see SourceForge) and it looks pretty nice. It's free, but looks well supported. >>My question: Has anyone actually installed this package on their Mac and used it in Python? The claims in the documentation are that it is doable, but not much info on how, except for the Unix end of things (maybe that means Unix approach using OS X, I don't know). Is this usable in system 9? By compiling with Codewarrior? >> >>-- > >I did it a few version back with CodeWarrior and had it working with Python. >-- Was it hard? Complicated? Straightforward? Any warnings or words of wisdom? -- Cheers, Lou Pecora From jhrsn@pitt.edu Thu Feb 13 20:49:46 2003 From: jhrsn@pitt.edu (Jim Harrison) Date: Thu, 13 Feb 2003 15:49:46 -0500 Subject: [Pythonmac-SIG] open source bbs in Python ? In-Reply-To: <4FB0EBB4-3F13-11D7-899E-0005024EF27F@Phreaker.net> Message-ID: on 2/13/03 12:23 AM, Joel Rodrigues at borgempath@Phreaker.net wrote: > Thanks for the info Ryan, Benjamin. If I have no choice, I'd > settle for Perl until I can figure out to how / get around > write to writing one at least for my own use in Python with > PostgreSQL. Not interested in PHP. Sorry if this has already been mentioned, but if you don't mind using Zope there are a number of bulletin board products written in python for it (see www.squishdot.org, for example; also www.zopezen.org runs a discussion board based on Zope/Plone which is available as a Plone skin). These are easily modifiable and I've been pretty happy with Zope as a discussion support platform. There is a Postgres adapter for Zope, but existing products typically use Zope's internal object DB. Jim Harrison Univ. of Pittsburgh From jpe@wingide.com Thu Feb 13 20:58:06 2003 From: jpe@wingide.com (John Ehresman) Date: 13 Feb 2003 15:58:06 -0500 Subject: [Pythonmac-SIG] Extension module binary compatibility Message-ID: <1045169886.1854.59.camel@sparrow> Hi, Can extension modules built with python2.2 w/ --enable-framework work with a python built without --enable-framework? I've been trying to go through the mail archives and I thought the answer was no, but I just tried it and it seems to work. Also are there any binary incompatibilities between 2.2.0, 2.2.1, and 2.2.2? Thanks, John From picardo@mac.com Fri Feb 14 01:59:05 2003 From: picardo@mac.com (Leslie Picardo) Date: Thu, 13 Feb 2003 17:59:05 -0800 Subject: [Pythonmac-SIG] Installing mysql-python Message-ID: I am running the Python 2.2.2 binary installation from fink under OS X 10.2.3 I have also succesfully installed Mysql using fink. I've been running into problems in installing the mysql-python package from http://sourceforge.net/projects/mysql-python/ When I try to build > python setup.py build gcc -L/sw/lib -bundle -bundle_loader /sw/bin/python build/temp.darwin-6.3-PowerMacintosh-2.2/_mysql.o -L/sw/lib/mysql -L/sw/lib -L/sw/lib -lmysqlclient -lz -o build/lib.darwin-6.3-PowerMacintosh-2.2/_mysql.so -flat_namespace ld: can't locate file for: -lmysqlclient error: command 'gcc' failed with exit status 1 I looked through google, sourceforge, and this list and a lot of people seem to have hit this problem but no one seems to have posted the solution. I can't figure out where the problem is. Is it because the libmysqlclient.a library is missing ? or do I have some compiler flags missing that would use the dylib file instead ? I am confused. Note that both the fink binary and source installation leave a dangling symbolic link to a non-existant libmysqlclient.a file. >ls -l /sw/lib/libmysqlclient* lrwxr-xr-x 1 picardo admin 22 Feb 13 16:24 /sw/lib/libmysqlclient.a -> mysql/libmysqlclient.a lrwxr-xr-x 1 picardo admin 26 Feb 13 16:24 /sw/lib/libmysqlclient.dylib -> mysql/libmysqlclient.dylib lrwxr-xr-x 1 picardo admin 23 Feb 13 16:24 /sw/lib/libmysqlclient.la -> mysql/libmysqlclient.la >ls -l /sw/lib/mysql total 440 -rwxr-xr-x 1 root admin 220488 Jan 16 07:59 libmysqlclient.10.0.0.dylib lrwxr-xr-x 1 root admin 27 Jan 24 14:55 libmysqlclient.10.dylib -> libmysqlclient.10.0.0.dylib Leslie From bgg@object-craft.com.au Fri Feb 14 08:47:16 2003 From: bgg@object-craft.com.au (Ben Golding) Date: Fri, 14 Feb 2003 19:47:16 +1100 Subject: [Pythonmac-SIG] Installing mysql-python In-Reply-To: Message-ID: On Friday, Feb 14, 2003, at 12:59 Australia/Melbourne, Leslie Picardo wrote: > > python setup.py build > gcc -L/sw/lib -bundle -bundle_loader /sw/bin/python > build/temp.darwin-6.3-PowerMacintosh-2.2/_mysql.o -L/sw/lib/mysql > -L/sw/lib -L/sw/lib -lmysqlclient -lz -o > build/lib.darwin-6.3-PowerMacintosh-2.2/_mysql.so -flat_namespace > ld: can't locate file for: -lmysqlclient > error: command 'gcc' failed with exit status 1 > > > I looked through google, sourceforge, and this list and a lot of > people seem to have hit this problem > but no one seems to have posted the solution. I can't figure out where > the problem is. Is it because the > libmysqlclient.a library is missing ? or do I have some compiler > flags missing that would use the dylib > file instead ? I am confused. > > Note that both the fink binary and source installation leave a > dangling symbolic link to a non-existant > libmysqlclient.a file. > > >ls -l /sw/lib/libmysqlclient* > lrwxr-xr-x 1 picardo admin 22 Feb 13 16:24 /sw/lib/libmysqlclient.a > -> mysql/libmysqlclient.a > lrwxr-xr-x 1 picardo admin 26 Feb 13 16:24 > /sw/lib/libmysqlclient.dylib -> mysql/libmysqlclient.dylib > lrwxr-xr-x 1 picardo admin 23 Feb 13 16:24 > /sw/lib/libmysqlclient.la -> mysql/libmysqlclient.la > > >ls -l /sw/lib/mysql > total 440 > -rwxr-xr-x 1 root admin 220488 Jan 16 07:59 > libmysqlclient.10.0.0.dylib > lrwxr-xr-x 1 root admin 27 Jan 24 14:55 libmysqlclient.10.dylib > -> libmysqlclient.10.0.0.dylib I had this same problem. I thought it was just an artifact of having tried to install MySQLdb a couple of times but perhaps it's actually a problem with the package. The problem was caused by the /sw/lib/libmysqlclient.dylib symbolic link pointing to a non-existent file in the mysql subdirectory. The linker just skips over the invalid link and doesn't complain about it; it probably should. To fix it, you should run: # remove bad symlink rm /sw/lib/libmysqlclient.dylib # recreate it correctly ln -s /sw/lib/mysql/libmysqlclient.10.dylib /sw/lib/libmysqlclient.dylib If you try building MySQLdb after that, it should link correctly. I hope that works. Ben. From SamuelM.Smith Fri Feb 14 21:13:49 2003 From: SamuelM.Smith (SamuelM.Smith) Date: Fri, 14 Feb 2003 14:13:49 -0700 Subject: [Pythonmac-SIG] python module search path in Apache on OSX In-Reply-To: Message-ID: <35D986C8-4061-11D7-85BF-00039346A274@samuelsmith.org> I have OSX 10.2.3 with fink python 2.2.2 installed in /sw and sym links in /usr/local/bin and the default apple python 2.2.0 in /usr/bin. For cgi scripts I put #!/usr/local/bin/python as the first line of the file so that is runs 2.2.2 or so I assume. However when I run a python cgi script using the default Apache 1.3 that comes with OSX I get the following value for sys.path once the script is running: ['/Users/smithsm/Sites/ht/cgi-bin', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] It looks like apache is making my script use the modules for python 2.2 while running 2.2.2 I realize that I can import sys and then insert the correct path which should be ['', '/Users/smithsm/Sites/ht/cgi-bin', '/sw/lib/python2.2', '/sw/lib/python2.2/plat-darwin', '/sw/lib/python2.2/lib-tk', '/sw/lib/python2.2/lib-dynload', '/sw/lib/python2.2/site-packages', '/sw/lib/python2.2/site-packages/Numeric', '/sw/lib/python2.2/site-packages/PIL'] but that still annoys me that I must first import the sys module of 2.2 in order to change the import path. although unlikely it begs the question what if the sys module of version 2.2 is not compatible with version 2.2+. Seems like a potential for problems. Is there any other way to get the path to be the correct one a priori for Apache run cgi scripts? Would putting a .pth file in my cgi-bin directory with the path work? The docs say add path but I need to insert path before the default. I do not have much experience with Apache but I have modified the httpd.conf file on occasion. Is there some directive that would make apache use the right path? What about mod_python? thanks for any help or suggestions. Sam From picardo@mac.com Fri Feb 14 21:49:44 2003 From: picardo@mac.com (Leslie Picardo) Date: Fri, 14 Feb 2003 13:49:44 -0800 Subject: [Pythonmac-SIG] Installing mysql-python In-Reply-To: Message-ID: <3A6B9AAC-4066-11D7-856C-00039348AAEE@mac.com> That fixes it. Thanks! I've sent a bug report to the mysql fink maintainer. In the meantime here's the complete installation process for mysql-python if you have the fink installation of mysql and python on OS X 10.2. A] download and unpack mysql-python from sourceforge http://sourceforge.net/projects/mysql-python/ B] Change the setup.py file to have these lines # set this to YES if you have the thread-safe mysqlclient library thread_safe_library = NO # include files and library locations should cover most platforms include_dirs = [ '/usr/include/mysql', '/usr/local/include/mysql', '/usr/local/mysql/include/mysql' ] library_dirs = [ '/sw/lib/mysql', '/sw/lib' ] C] Fix the missing symbolic link >cd /sw/lib/mysql >sudo ln -s libmysqlclient.10.dylib libmysqlclient.dylib D] >python setup.py build >sudo python setyp.py install E] Check if the installation works >python Python 2.2.2 (#1, 01/12/03, 07:51:34) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MySQLdb >>> F] Stretch. Go have a cold one. On Friday, February 14, 2003, at 12:47 AM, Ben Golding wrote: > > On Friday, Feb 14, 2003, at 12:59 Australia/Melbourne, Leslie Picardo > wrote: > >> > python setup.py build >> gcc -L/sw/lib -bundle -bundle_loader /sw/bin/python >> build/temp.darwin-6.3-PowerMacintosh-2.2/_mysql.o -L/sw/lib/mysql >> -L/sw/lib -L/sw/lib -lmysqlclient -lz -o >> build/lib.darwin-6.3-PowerMacintosh-2.2/_mysql.so -flat_namespace >> ld: can't locate file for: -lmysqlclient >> error: command 'gcc' failed with exit status 1 >> >> >> I looked through google, sourceforge, and this list and a lot of >> people seem to have hit this problem >> but no one seems to have posted the solution. I can't figure out >> where the problem is. Is it because the >> libmysqlclient.a library is missing ? or do I have some compiler >> flags missing that would use the dylib >> file instead ? I am confused. >> >> Note that both the fink binary and source installation leave a >> dangling symbolic link to a non-existant >> libmysqlclient.a file. >> >> >ls -l /sw/lib/libmysqlclient* >> lrwxr-xr-x 1 picardo admin 22 Feb 13 16:24 >> /sw/lib/libmysqlclient.a -> mysql/libmysqlclient.a >> lrwxr-xr-x 1 picardo admin 26 Feb 13 16:24 >> /sw/lib/libmysqlclient.dylib -> mysql/libmysqlclient.dylib >> lrwxr-xr-x 1 picardo admin 23 Feb 13 16:24 >> /sw/lib/libmysqlclient.la -> mysql/libmysqlclient.la >> >> >ls -l /sw/lib/mysql >> total 440 >> -rwxr-xr-x 1 root admin 220488 Jan 16 07:59 >> libmysqlclient.10.0.0.dylib >> lrwxr-xr-x 1 root admin 27 Jan 24 14:55 >> libmysqlclient.10.dylib -> libmysqlclient.10.0.0.dylib > > I had this same problem. I thought it was just an artifact of having > tried to install MySQLdb a couple of times but perhaps it's actually a > problem with the package. > > The problem was caused by the /sw/lib/libmysqlclient.dylib symbolic > link pointing to a non-existent file in the mysql subdirectory. The > linker just skips over the invalid link and doesn't complain about it; > it probably should. > > To fix it, you should run: > > # remove bad symlink > rm /sw/lib/libmysqlclient.dylib > # recreate it correctly > ln -s /sw/lib/mysql/libmysqlclient.10.dylib > /sw/lib/libmysqlclient.dylib > > If you try building MySQLdb after that, it should link correctly. > > I hope that works. > > Ben. > From Jack.Jansen@oratrix.com Sat Feb 15 16:16:11 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 15 Feb 2003 17:16:11 +0100 Subject: [Pythonmac-SIG] python module search path in Apache on OSX In-Reply-To: <35D986C8-4061-11D7-85BF-00039346A274@samuelsmith.org> Message-ID: On vrijdag, feb 14, 2003, at 22:13 Europe/Amsterdam, Samuel M. Smith wrote: > I have OSX 10.2.3 with fink python 2.2.2 installed in /sw and sym > links in /usr/local/bin > and the default apple python 2.2.0 in /usr/bin. > > For cgi scripts I put #!/usr/local/bin/python as the first line of the > file so that is runs 2.2.2 or > so I assume. > > However when I run a python cgi script using the default Apache 1.3 > that comes with OSX I get the following value for sys.path once the > script is running: > > ['/Users/smithsm/Sites/ht/cgi-bin', '/usr/lib/python2.2', > '/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', > '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] You've managed to confuse the Python code that attempts to find sys.path (together with the way the fink folks built the distribution). Python first looks at it's argv[0], which is /usr/local/bin/python in your case. It then removes the "bin/python" bit and appends "lib/python2.2". If this exists it is happy and builds sys.path from here. If it doesn't exist it looks at the location where it thought it was going to be installed when it was built. Apparently for your fink python this was "/usr", so it finds the Apple-installed python lib directory. (Note that the actual process is much more involved, but this is the gist of it). You can fix it by creating a symlink /usr/local/lib/python2.2 pointing to /sw/lib/python2.2. Or, even easier, you could simply put #!/sw/bin/python into your scripts. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From jmillr@umich.edu Sat Feb 15 21:36:53 2003 From: jmillr@umich.edu (John Miller) Date: Sat, 15 Feb 2003 16:36:53 -0500 Subject: [Pythonmac-SIG] (no subject) Message-ID: <9955599C-412D-11D7-86A9-00039303967A@umich.edu> I just downloaded PyXML-0.8.2 and tried to install using the directions in the README. However, the 'build' step failed because of a NameError: """ [moire:/PyXML-0.8.2] jmillr% python setup.py build Traceback (most recent call last): File "setup.py", line 58, in ? if sys.platform[:6] == "darwin" and \ NameError: name 'distutils' is not defined """ After finding the message below in the archives, I commented out the entire four lines in setup.py (lines 58-61): """ #if sys.platform[:6] == "darwin" and \ #distutils.sysconfig.get_config_var("LDSHARED").find("-flat_namespace") == -1: # Mac OS X #LDFLAGS.append('-flat_namespace') """ and installation proceeded to completion (albeit with many warnings of the form): extensions/expat/lib/xmltok.c:116: warning: `regparm' attribute directive ignored Anyway, it seems as though the PyXML distribution still has a broken setup.py for MacOS X. I'm running OSX 10.2.4 with the December 2002 Developer Tools and the stock 2.2 python. John Miller Technology Services School of Education University of Michigan On Tue, 3 Sep 2002 21:51:58 -0400 W.T. Bridgman wrote: > Jack, > > Got it!! :^) > > The alternate user didn't work, nor did the single command line, but > the single command line commenting out the last -flat_namespace does! > > In the setup.py in PyXML, there's a line: > > if sys.platform[:6] == "darwin": # Mac OS X > LDFLAGS.append('-flat_namespace') > > I commented out the LDFLAGS line and that seemed to clear the > problem. I suspect this was added at one time for PyXML but then was > later incorporated into the rest of the distutils package? > > Looks like the rest of the build process worked as well. > > Thanks for the pointer. How does one report this so it is fixed in > the next release? > > Tom From euphoriadj@adamswells.com Sun Feb 16 17:00:30 2003 From: euphoriadj@adamswells.com (Edd Thompson) Date: Sun, 16 Feb 2003 12:00:30 -0500 Subject: [Pythonmac-SIG] updating command line python Message-ID: <278558ED-41D0-11D7-B2EF-000393677BAE@adamswells.com> when I type python in terminal I all I get is this gobbledy-gook error message: # /sw/lib/python2.2/site.pyc matches /sw/lib/python2.2/site.py import site # precompiled from /sw/lib/python2.2/site.pyc # /sw/lib/python2.2/os.pyc matches /sw/lib/python2.2/os.py import os # precompiled from /sw/lib/python2.2/os.pyc import posix # builtin # /sw/lib/python2.2/posixpath.pyc matches /sw/lib/python2.2/posixpath.py import posixpath # precompiled from /sw/lib/python2.2/posixpath.pyc # /sw/lib/python2.2/stat.pyc matches /sw/lib/python2.2/stat.py import stat # precompiled from /sw/lib/python2.2/stat.pyc # /sw/lib/python2.2/UserDict.pyc matches /sw/lib/python2.2/UserDict.py import UserDict # precompiled from /sw/lib/python2.2/UserDict.pyc # /sw/lib/python2.2/copy_reg.pyc matches /sw/lib/python2.2/copy_reg.py import copy_reg # precompiled from /sw/lib/python2.2/copy_reg.pyc # /sw/lib/python2.2/types.pyc matches /sw/lib/python2.2/types.py import types # precompiled from /sw/lib/python2.2/types.pyc # /sw/lib/python2.2/__future__.pyc matches /sw/lib/python2.2/__future__.py import __future__ # precompiled from /sw/lib/python2.2/__future__.pyc Python 2.2.1 (#1, 08/07/02, 23:49:16) [GCC Apple devkit-based CPP 6.0] on darwin Type "help", "copyright", "credits" or "license" for more information. dyld: python Undefined symbols: /sw/lib/libreadline.4.2.dylib undefined reference to _tgetent expected to be defined in /usr/lib/libSystem.B.dylib Trace/BPT trap I just updated to jaguar so I think I need to update python. But do I download the one from python.org or use fink or something else altogether? The Last I played with python there were four different versions for mac and that was almost a year ago. In the mean time I started playing with perl, because I wanted to make use of algorithms in the "algorithms for perl" book and to work with regular expressions. All I can say is perl blow chunks, I'll get by trying to convert C algorithms to python instead and maybe some day I will understand regex but I won't ever under perl the learning curve is too steep right now. The more you know the less you understand. From bbum@codefab.com Sun Feb 16 17:10:15 2003 From: bbum@codefab.com (Bill Bumgarner) Date: Sun, 16 Feb 2003 12:10:15 -0500 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1374 - 2 msgs In-Reply-To: <20030216170004.10770.33208.Mailman@mail.python.org> Message-ID: <84520C1B-41D1-11D7-A5EB-000393877AE4@codefab.com> On Sunday, Feb 16, 2003, at 12:00 US/Eastern, pythonmac-sig-request@python.org wrote: > I just updated to jaguar so I think I need to update python. > But do I download the one from python.org or use fink or something > else altogether? Jaguar ships with Python 2.2 built in. It appears that your python installation is completely hosed. I suggest you blow away everything even remotely related to Python that you installed in pre-OS X 10.2 and start over. Jaguar's python is in /usr/bin/python, /usr/lib/python2.2, and /usr/include/python*. Blow everything else away, including your environment variables. If the built-in Jaguar fits the bill, stick with it. If you need more modules, etc, go with Fink or MacPython (the framework build). b.bum From bob@redivi.com Sun Feb 16 18:22:51 2003 From: bob@redivi.com (Bob Ippolito) Date: Sun, 16 Feb 2003 13:22:51 -0500 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: <278558ED-41D0-11D7-B2EF-000393677BAE@adamswells.com> Message-ID: On Sunday, Feb 16, 2003, at 12:00 America/New_York, Edd Thompson wrote: > I just updated to jaguar so I think I need to update python. > But do I download the one from python.org or use fink or something > else altogether? > > The Last I played with python there were four different versions for > mac and that was almost a year ago. > In the mean time I started playing with perl, because I wanted to make > use of algorithms in the "algorithms for perl" book and to work with > regular expressions. > All I can say is perl blow chunks, I'll get by trying to convert C > algorithms to python instead and maybe some day I will understand > regex but I won't ever under perl the learning curve is too steep > right now. Your problem is already FInk. Apple gives you a (well, mostly) working python 2.2 interpreter with 10.2. Delete or perhaps reinstall fink, and it will work. -bob From bob@redivi.com Sun Feb 16 18:25:21 2003 From: bob@redivi.com (Bob Ippolito) Date: Sun, 16 Feb 2003 13:25:21 -0500 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1374 - 2 msgs In-Reply-To: <84520C1B-41D1-11D7-A5EB-000393877AE4@codefab.com> Message-ID: <023B5628-41DC-11D7-B93C-000A95686CD8@redivi.com> On Sunday, Feb 16, 2003, at 12:10 America/New_York, Bill Bumgarner wrote: > > If the built-in Jaguar fits the bill, stick with it. If you need more > modules, etc, go with Fink or MacPython (the framework build). That's not necessarily true. I have yet to find a useful module that I couldn't backport to Apple's 2.2 in less than a few hours.. I have pygame, pyopengl, PIL, Numeric, MacPython, etc.. -bob From ivan@allometra.com Sun Feb 16 19:06:42 2003 From: ivan@allometra.com (Ivan Kozik) Date: Sun, 16 Feb 2003 11:06:42 -0800 Subject: [Pythonmac-SIG] Tkinter application, duplicate 'Help' menu Message-ID: Hello, I have written an application in Python using Tkinter on OS X 10.2, but because I need to put a 'Help' menu in the menubar, I end up with two 'Help's because Tk adds a blank entry there when I start the program. Is there any way I can remove it or use it? Thanks, Ivan From lpicardo@yahoo.com Sun Feb 16 19:35:11 2003 From: lpicardo@yahoo.com (It's me) Date: Sun, 16 Feb 2003 11:35:11 -0800 (PST) Subject: [Pythonmac-SIG] updating command line python In-Reply-To: <278558ED-41D0-11D7-B2EF-000393677BAE@adamswells.com> Message-ID: <20030216193511.94752.qmail@web41104.mail.yahoo.com> Others have pointed out that Jaguar comes with python pre-installed. If you use python in interactive mode a lot you might find the fink version of python better since you can recall command lines in this version. You can run perl code within python with the pyperl module. This gives you access to the large number of perl modules that have already been written. Instructions on how to install are on my webpage. http://homepage.mac.com/picardo/www/python/bioperl.html > In the mean time I started playing with perl, > because I wanted to make > use of algorithms in the "algorithms for perl" book > and to work with > regular expressions. > All I can say is perl blow chunks, I'll get by > trying to convert C > algorithms to python instead and maybe some day I > will understand regex > but I won't ever under perl the learning curve is > too steep right now. > > > > > The more you know the less you understand. > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From just@letterror.com Sun Feb 16 19:41:24 2003 From: just@letterror.com (Just van Rossum) Date: Sun, 16 Feb 2003 20:41:24 +0100 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: <20030216193511.94752.qmail@web41104.mail.yahoo.com> Message-ID: It's me wrote: > Others have pointed out that Jaguar comes with python > pre-installed. If you use python in interactive mode > a lot you might find the fink version of python better > since you can recall command lines in this version. Well, Bill Bumgarner has a tiny download with which you add the readline module to a stock 2.2, giving you command line history. However, it seems his friday.com server is still down :-( Bill, is there an alternative location for it? It was requested on comp.lang.python the other day as well. Just From bbum@mac.com Sun Feb 16 19:49:18 2003 From: bbum@mac.com (bbum@mac.com) Date: Sun, 16 Feb 2003 14:49:18 -0500 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: Message-ID: Yes, friday.com's primary hard drive melted down. Literally. The drive head touched down and wore a groove into the platter that was quite impressive. Of course, it was a sub-$1000 trash PC that was over 5 years old -- 24/7 for five years was about 10x the MTBF for that box. In any case, I dropped readline and pyssl modules for Apple's python here: http://pyobjc.sourceforge.net/software/ I have heard rumors that readline no longer builds on December Dev tools equipped 10.2 boxes -- but it still builds on my box which may simply be fallout from using a system that has been upgraded through every previous version of the dev tools. If anyone encounters a problem, please let me know and I'll figure out some kind of a workaround. b.bum On Sunday, Feb 16, 2003, at 14:41 US/Eastern, Just van Rossum wrote: > It's me wrote: > >> Others have pointed out that Jaguar comes with python >> pre-installed. If you use python in interactive mode >> a lot you might find the fink version of python better >> since you can recall command lines in this version. > > Well, Bill Bumgarner has a tiny download with which you add the > readline > module to a stock 2.2, giving you command line history. However, it > seems his friday.com server is still down :-( Bill, is there an > alternative location for it? It was requested on comp.lang.python the > other day as well. From deleeuw@stat.ucla.edu Sun Feb 16 20:50:21 2003 From: deleeuw@stat.ucla.edu (Jan de Leeuw) Date: Sun, 16 Feb 2003 12:50:21 -0800 Subject: [Pythonmac-SIG] CVS building problem Message-ID: <43BC7924-41F0-11D7-A776-000393BB6D36@stat.ucla.edu> The latest CVS version, combined with the latest Tcl/Tk CVS version, gives me problems. Something goes wrong when building tkinter (and of course as a consequence most of the stuff in /Applications does not work either). Here is a piece of the make output. ======================================================================== building '_tkinter' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double -no-cpp-precomp -fno-common -dynamic -DWITH_APPINIT=1 -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/include -I. -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src/./Include -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src/./Mac/Include -I/sw/include -I/usr/local/include -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src/Include -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src -c /Users/deleeuw/MyStuff/Developer/Python/python/dist/src/Modules/ _tkinter.c -o build/temp.darwin-6.4-Power_Macintosh-2.3/_tkinter.o -framework Tcl -framework Tk cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /Library/Frameworks/Tk.framework/Headers/tk.h:96, from /Users/deleeuw/MyStuff/Developer/Python/python/dist/src/Modules/ _tkinter.c:66: /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype gcc: -framework: linker input file unused because linking not done gcc: Tcl: linker input file unused because linking not done gcc: -framework: linker input file unused because linking not done gcc: Tk: linker input file unused because linking not done gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double -no-cpp-precomp -fno-common -dynamic -DWITH_APPINIT=1 -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/include -I. -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src/./Include -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src/./Mac/Include -I/sw/include -I/usr/local/include -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src/Include -I/Users/deleeuw/MyStuff/Developer/Python/python/dist/src -c /Users/deleeuw/MyStuff/Developer/Python/python/dist/src/Modules/ tkappinit.c -o build/temp.darwin-6.4-Power_Macintosh-2.3/tkappinit.o -framework Tcl -framework Tk cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory In file included from /Library/Frameworks/Tk.framework/Headers/tk.h:96, from /Users/deleeuw/MyStuff/Developer/Python/python/dist/src/Modules/ tkappinit.c:16: /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:140: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:343: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:462: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:480: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:505: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:506: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:518: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:531: warning: function declaration isn't a prototype /Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1065: warning: function declaration isn't a prototype gcc: -framework: linker input file unused because linking not done gcc: Tcl: linker input file unused because linking not done gcc: -framework: linker input file unused because linking not done gcc: Tk: linker input file unused because linking not done gcc -Wl,-F. -bundle -framework Python build/temp.darwin-6.4-Power_Macintosh-2.3/_tkinter.o build/temp.darwin-6.4-Power_Macintosh-2.3/tkappinit.o -L/sw/lib -L/usr/local/lib -o build/lib.darwin-6.4-Power_Macintosh-2.3/_tkinter.so -framework Tcl -framework Tk running build_scripts === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------ ------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------ ------------------------- From Jack.Jansen@oratrix.com Sun Feb 16 21:39:57 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 16 Feb 2003 22:39:57 +0100 Subject: [Pythonmac-SIG] CVS building problem In-Reply-To: <43BC7924-41F0-11D7-A776-000393BB6D36@stat.ucla.edu> Message-ID: <315D0976-41F7-11D7-BF3F-000A27B19B96@oratrix.com> On zondag, feb 16, 2003, at 21:50 Europe/Amsterdam, Jan de Leeuw wrote: > The latest CVS version, combined with the latest Tcl/Tk CVS version, > gives me problems. Something goes wrong when building tkinter > (and of course as a consequence most of the stuff in /Applications > does not work either). Here is a piece of the make output. Jan, I see a lot of warnings in the output, but no errors. Are you sure Tkinter doesn't build? The last step definitely seems to produce a _tkinter.so without problems. Also, the only thing in /Applications that depends on Tkinter is Idle, the other tools are Carbon-based. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sun Feb 16 22:32:19 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 16 Feb 2003 23:32:19 +0100 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: Message-ID: <824C76AE-41FE-11D7-BF3F-000A27B19B96@oratrix.com> On zondag, feb 16, 2003, at 20:49 Europe/Amsterdam, bbum@mac.com wrote: > In any case, I dropped readline and pyssl modules for Apple's python > here: > > http://pyobjc.sourceforge.net/software/ > > I have heard rumors that readline no longer builds on December Dev > tools equipped 10.2 boxes Don't know about any problems with december devtools, but your readline doesn't build with 2.3. I'm not sure whether it's supposed to, but anyway it doesn't because the signature of PyOS_ReadlineFunctionPointer is different. readline.c has extern DL_IMPORT(char) *(*PyOS_ReadlineFunctionPointer)(char *); and pythonrun.h has PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *); > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bbum@mac.com Sun Feb 16 22:47:04 2003 From: bbum@mac.com (bbum@mac.com) Date: Sun, 16 Feb 2003 17:47:04 -0500 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: <824C76AE-41FE-11D7-BF3F-000A27B19B96@oratrix.com> Message-ID: <91E45B02-4200-11D7-A5EB-000393877AE4@mac.com> On Sunday, Feb 16, 2003, at 17:32 US/Eastern, Jack Jansen wrote: > On zondag, feb 16, 2003, at 20:49 Europe/Amsterdam, bbum@mac.com wrote: >> In any case, I dropped readline and pyssl modules for Apple's python >> here: >> >> http://pyobjc.sourceforge.net/software/ >> >> I have heard rumors that readline no longer builds on December Dev >> tools equipped 10.2 boxes > > Don't know about any problems with december devtools, but your > readline doesn't build with 2.3. I'm not sure whether it's supposed > to, but anyway it doesn't because the signature of > PyOS_ReadlineFunctionPointer is different. readline.c has It isn't, but thank you. The sole purpose for the readline module was to be able to add readline support to Apple's [rather lacking] build of Python 2.2 that shipped with OS X. For any 'normal' Python build, I would think readline would "just work"? Huh. On second thought -- I suppose it requires that readline be built and available on the target system before building Python. Then again, the only person that should find my readline module useful are those that are trying to use readline support after installing a binary version of python that doesn't have readline support compiled in. If that is the case, then I'll punt -- the distributed builds of Python 2.3 should have readline installed, if built properly, correct? b.bum From SamuelM.Smith Mon Feb 17 02:57:23 2003 From: SamuelM.Smith (SamuelM.Smith) Date: Sun, 16 Feb 2003 19:57:23 -0700 Subject: [Pythonmac-SIG] python module search path in Apache on OSX In-Reply-To: Message-ID: <89ED28CC-4223-11D7-90B6-00039346A274@samuelsmith.org> > > You can fix it by creating a symlink /usr/local/lib/python2.2 pointing > to /sw/lib/python2.2. Or, even easier, you could simply put > #!/sw/bin/python into your scripts. Neither of these fixes changed the path at all. =( One other item I forgot to mention is that the PYTHONPATH environment variable has a couple more directories in that get prepended to normal python but are also not in the Apachi CGI invocation of python. I noticed that the python library ref for cgi states. "In particular, don't count on ...the Ptyhon module search path (PYTHONPATH) to be set to anything interesting." > -- > - Jack Jansen > http://www.cwi.nl/~jack - > - If I can't dance I don't want to be part of your revolution -- Emma > Goldman - > From Jack.Jansen@cwi.nl Mon Feb 17 09:30:47 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 17 Feb 2003 10:30:47 +0100 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: <91E45B02-4200-11D7-A5EB-000393877AE4@mac.com> Message-ID: <7EF063C0-425A-11D7-BE39-0030655234CE@cwi.nl> On Sunday, Feb 16, 2003, at 23:47 Europe/Amsterdam, bbum@mac.com wrote: > It isn't, but thank you. The sole purpose for the readline module > was to be able to add readline support to Apple's [rather lacking] > build of Python 2.2 that shipped with OS X. For any 'normal' Python > build, I would think readline would "just work"? > > Huh. On second thought -- I suppose it requires that readline be > built and available on the target system before building Python. > > Then again, the only person that should find my readline module useful > are those that are trying to use readline support after installing a > binary version of python that doesn't have readline support compiled > in. If that is the case, then I'll punt -- the distributed builds of > Python 2.3 should have readline installed, if built properly, correct? No, if ever I do a binary build of MacPython I'm not going to include readline. Because of the GPL license it carries that might infect the whole distribution. And with PackageManager it's easy enough to install it separately (that's how I found out your distribution was 2.2-only). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Mon Feb 17 09:32:41 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 17 Feb 2003 10:32:41 +0100 Subject: [Pythonmac-SIG] python module search path in Apache on OSX In-Reply-To: <89ED28CC-4223-11D7-90B6-00039346A274@samuelsmith.org> Message-ID: On Monday, Feb 17, 2003, at 03:57 Europe/Amsterdam, Samuel M.Smith wrote: >> >> You can fix it by creating a symlink /usr/local/lib/python2.2 >> pointing to /sw/lib/python2.2. Or, even easier, you could simply put >> #!/sw/bin/python into your scripts. > > Neither of these fixes changed the path at all. =( > > One other item I forgot to mention is that the PYTHONPATH environment > variable has a couple more directories in that get prepended to normal > python but are also not in the Apachi CGI invocation of python. > > I noticed that the python library ref for cgi states. "In particular, > don't count on ...the Ptyhon module search path (PYTHONPATH) to be set > to anything interesting." Ah, then I guess I was barking up the wrong tree, and this is an Apache problem. If you do find out what the problem is (or the solution) pleas let us know, -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From borgempath@Phreaker.net Mon Feb 17 10:24:23 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Mon, 17 Feb 2003 15:54:23 +0530 Subject: [Pythonmac-SIG] open source bbs in Python ? In-Reply-To: Message-ID: On Friday, February 14, 2003, at 02:19 , Jim Harrison wrote: > on 2/13/03 12:23 AM, Joel Rodrigues at borgempath@Phreaker.net wrote: > >> Thanks for the info Ryan, Benjamin. If I have no choice, I'd >> settle for Perl until I can figure out to how / get around >> write to writing one at least for my own use in Python with >> PostgreSQL. Not interested in PHP. > > Sorry if this has already been mentioned, but if you don't mind > using Zope > there are a number of bulletin board products written in python > for it (see > www.squishdot.org, for example; also www.zopezen.org runs a > discussion board > based on Zope/Plone which is available as a Plone skin). These > are easily > modifiable and I've been pretty happy with Zope as a discussion support > platform. > > There is a Postgres adapter for Zope, but existing products > typically use > Zope's internal object DB. > > Jim Harrison > Univ. of Pittsburgh Thanks Jim ! Though I'm not keen on using Zope. For me, now, it is an unnecessary layer of complexity. Not inclined at this point to using 'middleware' or application servers, though I can see their purpose. I like putting application logic into PostgreSQL and using minimalist Python scripting to access and interface with data. So, using that path I could probably put together a rudimentary BBS at least. Cheers, Joel From euphoriadj@adamswells.com Mon Feb 17 12:14:17 2003 From: euphoriadj@adamswells.com (Edd Thompson) Date: Mon, 17 Feb 2003 07:14:17 -0500 Subject: [Pythonmac-SIG] ok how about some book suggestions Message-ID: <56028A6E-4271-11D7-B2EF-000393677BAE@adamswells.com> I want to do database work, a little crypto for the math, general internet programing. Are there any books that would fulfill my needs? Can you do 3d graphics with the opengl lib if so where do I begin? I was learning opengl on X windows in C until my Linux machine was stolen. By the way what does everyone do with python? What kind of things do you do with it daily? A motion to adjourn is always in order. From bbum@mac.com Mon Feb 17 15:21:15 2003 From: bbum@mac.com (bbum@mac.com) Date: Mon, 17 Feb 2003 10:21:15 -0500 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: <7EF063C0-425A-11D7-BE39-0030655234CE@cwi.nl> Message-ID: <7464C87B-428B-11D7-A5EB-000393877AE4@mac.com> On Monday, Feb 17, 2003, at 04:30 US/Eastern, Jack Jansen wrote: > No, if ever I do a binary build of MacPython I'm not going to include > readline. Because of the GPL license it carries that might infect the > whole distribution. And with PackageManager it's easy enough to > install it separately (that's how I found out your distribution was > 2.2-only). Ahh... OK. That makes sense. The GPL inconveniences users once again. No surprise. Is there still a useful form of packaging for the readline module? That is, with PackageMaker available, does it still make sense for me to distribute a little bundle of goodness that builds/installs readline? Can it be done in a fashion that is compatible with Apple's Python and with your build? thanks, b.bum From kmarek@sbcglobal.net Mon Feb 17 15:58:34 2003 From: kmarek@sbcglobal.net (Kurt Marek) Date: Mon, 17 Feb 2003 07:58:34 -0800 Subject: [Pythonmac-SIG] So confused! MacPython-OSX 2.3a1, 2.4? Message-ID: I was excited to see mentioned on Jack's page that there was a MacPython-OSX 2.3a1 that includes basically everything (IDE, etc). Unfortunately, there is no link or instructions for installing it. I downloaded the OS9 version and it says to download the OSX version from source and use frameworks, but that is a little over my head without some elaboration on instructions. I then found on this list a mention of a binary on the sourceforge pages. Unfortunately, I found no binary for MacPython-OSX 2.3a1. Instead I found lots of 2.4 stuff including wxPython. I have no idea what that is. I'm assuming that these are the developmental branches. Can someone please help me out with how to proceed? I've been waiting for an OSX version of Python with an IDE that also works with the command line. I'm just getting started and it has been quite frustrating wading through all of these different versions without a clue where to start. thanks, Kurt From Jack.Jansen@cwi.nl Mon Feb 17 16:03:13 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 17 Feb 2003 17:03:13 +0100 Subject: [Pythonmac-SIG] Does the dl module serve a useful purpose on MacOSX? Message-ID: <51BBC134-4291-11D7-8616-0030655234CE@cwi.nl> Folks, does anyone know whether the dl module serves a useful purpose on MacOSX? Somehow fink installed dlfcn.h and libdl.a, and when building Python the main setup.py picks up dlfcn.h but not libdl.a. I either have to add logic to find the latter too, or I have to disable the dl module on MacOSX. What is the best option? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob@redivi.com Mon Feb 17 16:54:03 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 17 Feb 2003 11:54:03 -0500 Subject: [Pythonmac-SIG] Does the dl module serve a useful purpose on MacOSX? In-Reply-To: <51BBC134-4291-11D7-8616-0030655234CE@cwi.nl> Message-ID: <6B4B67B7-4298-11D7-B93C-000A95686CD8@redivi.com> On Monday, Feb 17, 2003, at 11:03 America/New_York, Jack Jansen wrote: > Folks, > does anyone know whether the dl module serves a useful purpose on > MacOSX? > > Somehow fink installed dlfcn.h and libdl.a, and when building Python > the main setup.py picks up dlfcn.h but not libdl.a. I either have to > add > logic to find the latter too, or I have to disable the dl module on > MacOSX. > > What is the best option? > The dl library is part of the Darwin distribution (libcompat). I'm pretty sure it's worthless from Python, I vote to disable the module. libcompat is just a dyld wrapper that exposes a *nix-like libdl API. It was only useful when dynload_next was broken and you were compiling your own Python. It's likely part of Fink to aid porting of other projects that support libdl for loading plug-ins or extensions. -bob From deleeuw@stat.ucla.edu Mon Feb 17 17:08:17 2003 From: deleeuw@stat.ucla.edu (Jan de Leeuw) Date: Mon, 17 Feb 2003 09:08:17 -0800 Subject: [Pythonmac-SIG] IDLE etc build from CVS Message-ID: <6862614C-429A-11D7-B942-000393BB6D36@stat.ucla.edu> When I try to start IDLE from a current CVS build it says in the console > /Applications/MacPython-2.3/IDLE.app/Contents/MacOS/python: can't open > file '/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle' Turns out idle sits in Resources/idlelib, not in Resources itself. Anyone else see this ? Other applets also do not work, although PackageManager and PythonIDE can be fixed (courtesy of Jack Jansen) with sudo chmod 775 /Applications/MacPython-2.3/PackageManager.app/Contents/Resources/ sudo chmod 775 /Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ BuildApplet only writes its usage instructions to the console and then exits. Both IDLE and BuildApplet have generic application icons. PythonLauncher works fine (but that's not an applet but a Cocoa application) === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------ ------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------ ------------------------- From deleeuw@stat.ucla.edu Mon Feb 17 17:18:38 2003 From: deleeuw@stat.ucla.edu (Jan de Leeuw) Date: Mon, 17 Feb 2003 09:18:38 -0800 Subject: [Pythonmac-SIG] dlcompat and readline Message-ID: When building MacPython from CVS I always have to mask fink (by renaming /sw to /sw.tmp), otherwise the Python configure tries to build both the readline and dl modules (and fails on both). Doesn't seem to be harmful but leaves annoying messages in the make log. It would be nice if both were disabled in a framework build. dlcompat is also installed by OpenDarwin and DarwinPorts, so it may also sit in /opt/lib and /usr/local/lib === Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; Editor: Journal of Multivariate Analysis, Journal of Statistical Software US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554 phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu homepage: http://gifi.stat.ucla.edu ------------------------------------------------------------------------ ------------------------- No matter where you go, there you are. --- Buckaroo Banzai http://gifi.stat.ucla.edu/sounds/nomatter.au ------------------------------------------------------------------------ ------------------------- From altis@semi-retired.com Mon Feb 17 17:21:52 2003 From: altis@semi-retired.com (Kevin Altis) Date: Mon, 17 Feb 2003 09:21:52 -0800 Subject: [Pythonmac-SIG] So confused! MacPython-OSX 2.3a1, 2.4? In-Reply-To: Message-ID: I put together the following page to walk people through installing PythonCard on Mac OS X. It includes the steps for installing a disk image of the MacPython framework build, wxPython, and PythonCard, but you can just follow the download links and only install MacPython if you want. http://pythoncard.sourceforge.net/macosx_installation.html The one part I haven't finished yet is dealing with PythonLauncher. If you try and run a wxPython/PythonCard script without changing the PythonLauncher default to use pythonw you typically get a window with no menus and no way of killing the script except using Force Quit. There is also the issue of setting the default action to using PythonLauncher instead of the IDE if you prefer being able to double-click .py files and have them run as apps rather than having them open up in the IDE for editing. I will add something about PythonLauncher this week with some screenshots. I would appreciate feedback and corrections. If the textual descriptions aren't good enough I can add more screenshots. ka > -----Original Message----- > From: pythonmac-sig-admin@python.org > [mailto:pythonmac-sig-admin@python.org]On Behalf Of Kurt Marek > Sent: Monday, February 17, 2003 7:59 AM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] So confused! MacPython-OSX 2.3a1, 2.4? > > > I was excited to see mentioned on Jack's page that there was a > MacPython-OSX 2.3a1 that includes basically everything (IDE, etc). > Unfortunately, there is no link or instructions for installing it. I > downloaded the OS9 version and it says to download the OSX version from > source and use frameworks, but that is a little over my head without > some elaboration on instructions. I then found on this list a mention > of a binary on the sourceforge pages. Unfortunately, I found no binary > for MacPython-OSX 2.3a1. Instead I found lots of 2.4 stuff including > wxPython. I have no idea what that is. I'm assuming that these are the > developmental branches. > > Can someone please help me out with how to proceed? I've been waiting > for an OSX version of Python with an IDE that also works with the > command line. I'm just getting started and it has been quite > frustrating wading through all of these different versions without a > clue where to start. > > thanks, > Kurt From jharmon@adobe.com Mon Feb 17 18:01:55 2003 From: jharmon@adobe.com (Jeff Harmon) Date: Mon, 17 Feb 2003 10:01:55 -0800 Subject: [Pythonmac-SIG] Re: ok how about some book suggestions In-Reply-To: <20030217170012.25554.59989.Mailman@mail.python.org> Message-ID: On Monday, February 17, 2003, at 09:00 AM, pythonmac-sig-request@python.org wrote: > I want to do database work, a little crypto for the math, general > internet programing. Are there any books that would fulfill my needs? Python is rather like a weakly-typed C (this can be good and bad). ...with some forced structure to eliminate the Perl/C-esque "let's see how obtuse we can make this stuff" temptation. One thing that comes out of this forced structure (albeit something you don't tend to see) is that the language is very open to being composed programmatically (a la PostScript). There are services for creating basic OO constructs (but be careful with complex constructs thereof since they may not perform as you expect). The more I use it (Python) the more I like it. One of its strengths is the _large_ collection of std apis. If you know C++ et al. go straight for the best book out there "Python Essential Reference, David Beazley, New Riders, ISBN: 0-7357-1091-0". If you're new to languages (which doesn't seem to the be the case, but...) go to the online docs at python.org. LOTS of the books out there are nothing more than re-prints of the stuff a python.org (with a little window dressing). I find myself using O'Reilly's Python Cookbook and their Python Standard Library book (employing the later as an adjunct to PER). Many of the Python std apis are direct or otherwise higher-level wrappings of other APIs (from other sources). For example, Win32 APIs, Mac Toolbox, POSIX, Unix networking (various RFCs), etc. I haven't played with the crypto APIs. That said, if what you want "isn't there" it's relatively straightforward to add it (either via C++ or Python itself ... or often the best form is a combination of both). Using it for common-codebase, multi-plat test automation, JR Adobe Systems, Inc. From bob@redivi.com Mon Feb 17 18:26:26 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 17 Feb 2003 13:26:26 -0500 Subject: [Pythonmac-SIG] Re: ok how about some book suggestions In-Reply-To: Message-ID: <52FD6EF4-42A5-11D7-B93C-000A95686CD8@redivi.com> On Monday, Feb 17, 2003, at 13:01 America/New_York, Jeff Harmon wrote: > On Monday, February 17, 2003, at 09:00 AM, > pythonmac-sig-request@python.org wrote: > >> I want to do database work, a little crypto for the math, general >> internet programing. Are there any books that would fulfill my needs? > > Python is rather like a weakly-typed C (this can be good and bad). > ...with some forced structure to eliminate the Perl/C-esque "let's see > how obtuse we can make this stuff" temptation. One thing that comes > out of this forced structure (albeit something you don't tend to see) > is that the language is very open to being composed programmatically > (a la PostScript). There are services for creating basic OO > constructs (but be careful with complex constructs thereof since they > may not perform as you expect). The more I use it (Python) the more I > like it. One of its strengths is the _large_ collection of std apis. Well, IMHO, it can do some pretty complex constructs with ease.. however, you do have to construct them differently than elsewhere. You make a good point with the fact that it's easy to compose programmatically -- although, I've never had a specific need to other than win32 COM stuff, which I just used and didn't write myself. > If you know C++ et al. go straight for the best book out there "Python > Essential Reference, David Beazley, New Riders, ISBN: 0-7357-1091-0". > If you're new to languages (which doesn't seem to the be the case, > but...) go to the online docs at python.org. LOTS of the books out > there are nothing more than re-prints of the stuff a python.org (with > a little window dressing). I find myself using O'Reilly's Python > Cookbook and their Python Standard Library book (employing the later > as an adjunct to PER). Many of the Python std apis are direct or > otherwise higher-level wrappings of other APIs (from other sources). > For example, Win32 APIs, Mac Toolbox, POSIX, Unix networking (various > RFCs), etc. I haven't played with the crypto APIs. That said, if > what you want "isn't there" it's relatively straightforward to add it > (either via C++ or Python itself ... or often the best form is a > combination of both). As far as crypto goes, there's a couple hashing algorithms in the std library from what I remember, but what you want for 'real' crypto is PyCrypto ( http://www.amk.ca/python/code/crypto.html ). A full SSH implementation (server and client) using PyCrypto is included in Twisted ( http://www.twistedmatrix.com/ ). Also, if you know C++ you may likely want to look at Boost.Python ( http://www.boost.org/libs/python/doc/index.html ), I've never used it myself but it sounds really slick, especially if you have that need to add functionality. For database work, there's not anything you want in the std library.. you'll need to find a particular 3rd party module for your RDBMS of choice (ODBC, PostgreSQL, etc). They all pretty much conform to the same API though, so that's nice. Google or look in the vaults for those. -bob From petrucha@isnet.sk Mon Feb 17 18:00:41 2003 From: petrucha@isnet.sk (Stefan Petrucha) Date: Mon, 17 Feb 2003 19:00:41 +0100 Subject: [Pythonmac-SIG] Is this a bug? Message-ID: <3E512349.1291844E@isnet.sk> MacPython 2.2.2: Documentation on module sys says that sys.stdout and/or sys.stderr can be any object having method write() taking one string argument. But test.regrtest.main() traces back executing sys.stdout.flush(). (Background: Python is embedded into another application and sys.std* are redirected.) If I remember good MacPython 2.2.1 had no such problem. Can this be considered as a bug? When yes: is it a documentation or test.regrtest bug? Should I log it somewhere (of course by checking first nobody did it already)? Stefan Petrucha From rhett-sutphin@uiowa.edu Mon Feb 17 19:32:55 2003 From: rhett-sutphin@uiowa.edu (Rhett Sutphin) Date: Mon, 17 Feb 2003 13:32:55 -0600 Subject: [Pythonmac-SIG] python module search path in Apache on OSX In-Reply-To: <20030217170012.25554.14713.Mailman@mail.python.org> Message-ID: <9C9FAADE-42AE-11D7-A755-000393D44542@uiowa.edu> Hi, On Monday, February 17, 2003, at 11:00 AM, pythonmac-sig-request@python.org wrote: > From: Jack Jansen > Date: Mon Feb 17, 2003 3:32:41 AM America/Chicago > To: "Samuel M.Smith" > Cc: Jack Jansen , pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] python module search path in Apache on OSX > > On Monday, Feb 17, 2003, at 03:57 Europe/Amsterdam, Samuel M.Smith > wrote: > >>> >>> You can fix it by creating a symlink /usr/local/lib/python2.2 >>> pointing to /sw/lib/python2.2. Or, even easier, you could simply put >>> #!/sw/bin/python into your scripts. >> >> Neither of these fixes changed the path at all. =( >> >> One other item I forgot to mention is that the PYTHONPATH environment >> variable has a couple more directories in that get prepended to >> normal python but are also not in the Apachi CGI invocation of >> python. >> >> I noticed that the python library ref for cgi states. "In particular, >> don't count on ...the Ptyhon module search path (PYTHONPATH) to be >> set to anything interesting." > > Ah, then I guess I was barking up the wrong tree, and this is an > Apache problem. > > If you do find out what the problem is (or the solution) pleas let us > know, I had the same problem when trying to use the pyPgSQL module in CGI scripts. I had installed it in my copy of fink python with no trouble, but the cgi scripts were using the wrong sys.path and therefore not finding it. The solution is to set PYTHONPATH in your apache configuration. Here's how I did it: * First, in /etc/httpd/httpd.conf, enable mod_env by uncommenting the following two lines: LoadModule env_module libexec/httpd/mod_env.so [at around line 200] AddModule mod_env.c [around line 250] (You may note when you do this that the module mod_setenvif is already enabled. I don't know why it is while mod_env is not. Perhaps someone who knows more about apache would have some insight.) * The second step is more variable. The meat of it is that, in an appropriate place, put this directive: SetEnv PYTHONPATH "/sw/lib/python2.2:/sw/lib/python-2.2/plat-darwin:/sw/lib/ python2.2/lib-dynload:/sw/lib/python2.2/site-packages" (All on one line.) What "an appropriate place" means depends on your particular situation. In my case, I only needed python+CGI+PgSQL to work for one user account, so I put it in the Directory block in /etc/httpd/users/username.conf . I imagine you could also put it in the Directory block for the web root (in httpd.conf) or in a .htaccess file in your CGI directory. * Restart the apache service for these changes to take effect. That worked for me. Feel free to ask if anything's unclear. Rhett -- Rhett Sutphin Research Assistant (Software) Coordinated Laboratory for Computational Genomics and the Center for Macular Degeneration University of Iowa - Iowa City, IA 52242 - USA 4111 MEBRF - email: rhett-sutphin@uiowa.edu From francois.granger@free.fr Mon Feb 17 19:24:00 2003 From: francois.granger@free.fr (Francois Granger) Date: Mon, 17 Feb 2003 20:24:00 +0100 Subject: [Pythonmac-SIG] So confused! MacPython-OSX 2.3a1, 2.4? In-Reply-To: References: Message-ID: At 07:58 -0800 17/02/2003, in message [Pythonmac-SIG] So confused! MacPython-OSX 2.3a1, 2.4?, Kurt Marek wrote: [...] the sourceforge pages. Unfortunately, I found no binary for MacPython-OSX 2.3a1. Instead I found lots of 2.4 stuff including wxPython. On that very same page, you have to scroll down to the bottom of the page to find what you are looking for. -- Hofstadter's Law : It always takes longer than you expect, even when you take into account Hofstadter's Law. From tony@lownds.com Mon Feb 17 19:49:37 2003 From: tony@lownds.com (Tony Lownds) Date: Mon, 17 Feb 2003 11:49:37 -0800 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: <6862614C-429A-11D7-B942-000393BB6D36@stat.ucla.edu> References: <6862614C-429A-11D7-B942-000393BB6D36@stat.ucla.edu> Message-ID: At 9:08 AM -0800 2/17/03, Jan de Leeuw wrote: >When I try to start IDLE from a current CVS build it says in the console > >>/Applications/MacPython-2.3/IDLE.app/Contents/MacOS/python: can't >>open file >>'/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle' > >Turns out idle sits in Resources/idlelib, not in Resources itself. >Anyone else see this ? I see the error too. For some reason during the build process BuildApplet.py is not copying Tools/idle/idle to Resources/idle -- this certainly used to work. I'm still debugging... -Tony From bob@redivi.com Mon Feb 17 20:27:15 2003 From: bob@redivi.com (Bob Ippolito) Date: Mon, 17 Feb 2003 15:27:15 -0500 Subject: [Pythonmac-SIG] Is this a bug? In-Reply-To: <3E512349.1291844E@isnet.sk> Message-ID: <3423C6B4-42B6-11D7-B93C-000A95686CD8@redivi.com> On Monday, Feb 17, 2003, at 13:00 America/New_York, Stefan Petrucha wrote: > MacPython 2.2.2: > > Documentation on module sys says that sys.stdout and/or sys.stderr can > be any object having method write() taking one string argument. But > test.regrtest.main() traces back executing sys.stdout.flush(). > (Background: Python is embedded into another application and sys.std* > are redirected.) > > If I remember good MacPython 2.2.1 had no such problem. > > Can this be considered as a bug? When yes: is it a documentation or > test.regrtest bug? Should I log it somewhere (of course by checking > first nobody did it already)? Not speaking specifically for MacPython, but in practice flush is usually expected to be there for stdout (don't often see people flush stderr).. it doesn't actually have to do anything if the meaning doesn't make sense for your file-like object, but probably should be a callable attribute (for example: "sys.stdout.flush = lambda *x:None"). -bob From billb@mousa.demon.co.uk Mon Feb 17 20:31:25 2003 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Mon, 17 Feb 2003 20:31:25 +0000 Subject: [Pythonmac-SIG] So confused! MacPython-OSX 2.3a1, 2.4? Message-ID: At 7:58 am -0800 on 17/02/03 you wrote: >I was excited to see mentioned on Jack's page that there was a >MacPython-OSX 2.3a1 that includes basically everything (IDE, etc). Does MacPython-OSX 2.3a1 work on OSX1.1.x? I tried installing and get these errors when I try to run the IDE dyld: /Applications/Python/PythonIDE.app/Contents/MacOS/python Undefined symbols: Python undefined reference to _getpgid expected to be defined in /usr/lib/libSystem.B.dylib -- Bill Bedford "Nothing is as important as model railways and even that isn't very important" -some wiseguy somewhere From tony@lownds.com Mon Feb 17 21:23:18 2003 From: tony@lownds.com (Tony Lownds) Date: Mon, 17 Feb 2003 13:23:18 -0800 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: References: <6862614C-429A-11D7-B942-000393BB6D36@stat.ucla.edu> Message-ID: At 11:49 AM -0800 2/17/03, Tony Lownds wrote: >At 9:08 AM -0800 2/17/03, Jan de Leeuw wrote: >>When I try to start IDLE from a current CVS build it says in the console >> >>>/Applications/MacPython-2.3/IDLE.app/Contents/MacOS/python: can't >>>open file >>>'/Applications/MacPython-2.3/IDLE.app/Contents/Resources/idle' >> >>Turns out idle sits in Resources/idlelib, not in Resources itself. >>Anyone else see this ? > >I see the error too. For some reason during the build process >BuildApplet.py is not copying Tools/idle/idle to Resources/idle -- >this certainly used to work. > I am going to file a bug on SF. Thanks for reporting this, Jan. Here is the command that is causing trouble: /Library/Frameworks/../../Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/python ../python/dist/src/Mac/scripts/BuildApplet.py --output /Library/Frameworks/../../Applications/MacPython-2.3/IDLE.app --extra ../python/dist/src/Tools/idle ../python/dist/src/Tools/idle/idle or essentially: python Mac/scripts/BuildApplet.py --output IDLE.app --extra Tools/idle Tools/idle/idle The semantics of BuildApplet.py (well, buildtools.py) changed slightly, in a way that upset IDLE's build - it used to copy its argument (the main program file) into Resources/ under a new name - __main__.py. This changed so that the main program file keeps the same file name. For IDLE, the main program is Tools/idle/idle but the Tools/idle directory needs to be copied into the bundle as well; before the slight semantic change in buildtools.py this worked OK but now two things named "idle" are getting copied to Resources/ and its not working. Its hard to argue that BuildApplet really should support an --extra argument with the same basename as the main program file. Perhaps the best fix is to integrate the latest idlefork with Python 2.3 - this would eliminate this problem because the main file for mac applets is not called idle in idlefork. Another way to fix this would be to extend BuildApplet and buildtools and bundlebuilder so that it is possible to specify a new name for the --extra argument, something like: python Mac/scripts/BuildApplet.py --output IDLE.app --extra Tools/idle --rename-extra idlelib Tools/idle/idle But the first fix option seems way more palateable to me. I think there may be another problem with the latest change to applets: The __main__.py file used to be executed with the -psn arguments filtered out, but now the -psn arguments are not getting filtered out. Is -psn argument handling the responsibility of the main program? Or should bundlebuilder take care of that? -Tony From SamuelM.Smith Mon Feb 17 23:51:04 2003 From: SamuelM.Smith (SamuelM.Smith) Date: Mon, 17 Feb 2003 16:51:04 -0700 Subject: [Pythonmac-SIG] python module search path in Apache on OSX In-Reply-To: <9C9FAADE-42AE-11D7-A755-000393D44542@uiowa.edu> Message-ID: Rhett, Thanks, that worked. I had tried the SetEnv directive before but wasn't smart enough to realize I needed the mod_env as well. So when I tried it before Apache wouldn't boot. also the example of how to have more than one directory in the path helped. I also wrapped it in an IfModule block SetEnv PYTHONPATH /Users/smithsm/Development/python:/Users/smithsm/Development/python/ ht:/sw/lib/python2.2:/sw/lib/python2.2/plat-darwin:/sw/lib/python2.2/ lib-tk:/sw/lib/python2.2/lib-dynload:/sw/lib/python2.2/site-packages:/ sw/lib/python2.2/site-packages/Numeric:/sw/lib/python2.2/site-packages/ PIL Note that the quotes around the path portion are optional. I show them left off. The final path that python sees as sys.path is as follows: ['/Users/smithsm/Sites/ht/cgi-bin', '/Users/smithsm/Development/python', '/Users/smithsm/Development/python/ht', '/sw/lib/python2.2', '/sw/lib/python2.2/plat-darwin', '/sw/lib/python2.2/lib-tk', '/sw/lib/python2.2/lib-dynload', '/sw/lib/python2.2/site-packages', '/sw/lib/python2.2/site-packages/Numeric', '/sw/lib/python2.2/site-packages/PIL', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] Notice that the directory wherein resides the cgi script is prepended to the front of the list after the PYTHONPATH is prepended. The undesired default path is still there at the end. Although this solves my problem, it still begs the question of who is making up the default path in the first place. I can't imagine it is Apache, it must be Python. Maybe someone hard coded the default path or did not use a smart algorithm based on where the python executable is found as Jack first postulated? On Monday, February 17, 2003, at 12:32 PM, Rhett Sutphin wrote: > Hi, > > On Monday, February 17, 2003, at 11:00 AM, > pythonmac-sig-request@python.org wrote: >> From: Jack Jansen >> Date: Mon Feb 17, 2003 3:32:41 AM America/Chicago >> To: "Samuel M.Smith" >> Cc: Jack Jansen , pythonmac-sig@python.org >> Subject: Re: [Pythonmac-SIG] python module search path in Apache on >> OSX >> >> On Monday, Feb 17, 2003, at 03:57 Europe/Amsterdam, Samuel M.Smith >> wrote: >> >>>> >>>> You can fix it by creating a symlink /usr/local/lib/python2.2 >>>> pointing to /sw/lib/python2.2. Or, even easier, you could simply >>>> put #!/sw/bin/python into your scripts. >>> >>> Neither of these fixes changed the path at all. =( >>> >>> One other item I forgot to mention is that the PYTHONPATH >>> environment variable has a couple more directories in that get >>> prepended to normal python but are also not in the Apachi CGI >>> invocation of >> python. >>> >>> I noticed that the python library ref for cgi states. "In >>> particular, don't count on ...the Ptyhon module search path >>> (PYTHONPATH) to be set to anything interesting." >> >> Ah, then I guess I was barking up the wrong tree, and this is an >> Apache problem. >> >> If you do find out what the problem is (or the solution) pleas let us >> know, > > I had the same problem when trying to use the pyPgSQL module in CGI > scripts. I had installed it in my copy of fink python with no > trouble, but the cgi scripts were using the wrong sys.path and > therefore not finding it. The solution is to set PYTHONPATH in your > apache configuration. Here's how I did it: > > * First, in /etc/httpd/httpd.conf, enable mod_env by uncommenting the > following two lines: > > LoadModule env_module libexec/httpd/mod_env.so [at around line > 200] > AddModule mod_env.c [around line 250] > > (You may note when you do this that the module mod_setenvif is already > enabled. I don't know why it is while mod_env is not. Perhaps > someone who knows more about apache would have some insight.) > > * The second step is more variable. The meat of it is that, in an > appropriate place, put this directive: > > SetEnv PYTHONPATH > "/sw/lib/python2.2:/sw/lib/python-2.2/plat-darwin:/sw/lib/ > python2.2/lib-dynload:/sw/lib/python2.2/site-packages" > > (All on one line.) What "an appropriate place" means depends on your > particular situation. In my case, I only needed python+CGI+PgSQL to > work for one user account, so I put it in the Directory block in > /etc/httpd/users/username.conf . I imagine you could also put it in > the Directory block for the web root (in httpd.conf) or in a .htaccess > file in your CGI directory. > > * Restart the apache service for these changes to take effect. > > That worked for me. Feel free to ask if anything's unclear. > > Rhett > From kmarek@sbcglobal.net Tue Feb 18 00:55:53 2003 From: kmarek@sbcglobal.net (Kurt Marek) Date: Mon, 17 Feb 2003 16:55:53 -0800 Subject: [Pythonmac-SIG] MacPython-OSX vs. wxPython Message-ID: I tried to install according to Kevin Altis' instructions, but when I installed wxPython it told me that there were errors during the installation and that I should try again. I did so and this time it said it was upgrading (the Install button said Upgrade), but I got the same error. I have a MacPython 2.3 folder in my Applications folder, but I do not have a wxPython folder as the instructions indicated I should. More generally, what exactly is wxPython and how does it relate to MacPython-OSX 2.3? thanks, Kurt From Jack.Jansen@cwi.nl Tue Feb 18 10:00:44 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 18 Feb 2003 11:00:44 +0100 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: <7464C87B-428B-11D7-A5EB-000393877AE4@mac.com> Message-ID: On Monday, Feb 17, 2003, at 16:21 Europe/Amsterdam, bbum@mac.com wrote: > On Monday, Feb 17, 2003, at 04:30 US/Eastern, Jack Jansen wrote: >> No, if ever I do a binary build of MacPython I'm not going to include >> readline. Because of the GPL license it carries that might infect the >> whole distribution. And with PackageManager it's easy enough to >> install it separately (that's how I found out your distribution was >> 2.2-only). > > Ahh... OK. That makes sense. The GPL inconveniences users once > again. No surprise. > > Is there still a useful form of packaging for the readline module? Yes, definitely. The easiest for the scapegoat (also known as the "Pimp Database Maintainer", which for the time being translates to "Jack Jansen":-) is if you make a similar package to the one you have for 2.2 available, i.e. a source distribution with setup.py script. You may want to put some version information in the filename. The scapegoat will then download, build and test the package. If that works s/he adds an entry to the database for the source version of the package (referring to your download URL). Then the scapegoat can also do a "python setup.py bdist", put the resulting archive somewhere on his/her own website, and add an entry to the database for the binary version of the package. So far I've done this for Numeric, PIL, PyOpenGL and the Apple Help Viewer-compatible version of the Python documentation and it all seems to work fine. At least, for me: I haven't had much feedback yet (hint, hint:-). Next on my todo list is an all-singing-all-dancing version of PackageManager (the GUI to pimp) which will use PyOpenGL and which will include the Manager interface (allowing easy creation of binary distributions, computing MD5 checksums, freeing you from having to type XML by hand, etc). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Tue Feb 18 10:23:33 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 18 Feb 2003 11:23:33 +0100 Subject: [Pythonmac-SIG] Re: dlcompat and readline In-Reply-To: Message-ID: <0842DFD0-432B-11D7-B823-0030655234CE@cwi.nl> On Monday, Feb 17, 2003, at 18:18 Europe/Amsterdam, Jan de Leeuw wrote: > When building MacPython from CVS I always have to mask fink > (by renaming /sw to /sw.tmp), otherwise the Python configure > tries to build both the readline and dl modules (and fails on > both). Okay, I've specifically disabled dl. But what is your problem with readline? For me it builds fine... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Tue Feb 18 10:39:10 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 18 Feb 2003 11:39:10 +0100 Subject: [Pythonmac-SIG] Is this a bug? In-Reply-To: <3E512349.1291844E@isnet.sk> Message-ID: <36C3DC1A-432D-11D7-B823-0030655234CE@cwi.nl> On Monday, Feb 17, 2003, at 19:00 Europe/Amsterdam, Stefan Petrucha wrote: > MacPython 2.2.2: > > Documentation on module sys says that sys.stdout and/or sys.stderr can > be any object having method write() taking one string argument. But > test.regrtest.main() traces back executing sys.stdout.flush(). > (Background: Python is embedded into another application and sys.std* > are redirected.) Yes, it's a bug. The documentation indeed unequivocally states that the object only needs a write() method. I'm not sure whether it's the documentation that's in error or the flush() in regrtest, so I've filed a bug report: If you login to sourceforge you can monitor the bug to track its progress. In the mean time you can just take out the flush()es in regrtest, I think. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Tue Feb 18 10:42:52 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 18 Feb 2003 11:42:52 +0100 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: Message-ID: On Tuesday, Feb 18, 2003, at 11:00 Europe/Amsterdam, Jack Jansen wrote: > Next on my todo list is an all-singing-all-dancing version of > PackageManager (the GUI to pimp) which will use PyOpenGL It will, of course, use PyObjC, not PyOpenGL. Just in case people were wondering why I would be doing a 3D graphic interface to an installer. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From just@letterror.com Tue Feb 18 12:29:36 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 18 Feb 2003 13:29:36 +0100 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: Message-ID: Tony Lownds wrote: > I think there may be another problem with the latest change to > applets: The __main__.py file used to be executed with the -psn > arguments filtered out, but now the -psn arguments are not getting > filtered out. > > Is -psn argument handling the responsibility of the main program? Yes. But perhaps BuildApplet can provide a wrapper that handles this. > Or should bundlebuilder take care of that? No, there are cases where the -psn argument is needed by the main program (possibly only apps made with PyObjC). Regarding the Idle problem: I'm not sure why this --extra argument is there in the first place; perhaps it's not needed with the new bundlebuilder-based BuildApplet? Just From Chris.Barker@noaa.gov Tue Feb 18 18:11:48 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 18 Feb 2003 10:11:48 -0800 Subject: [Pythonmac-SIG] Re: ok how about some book suggestions References: Message-ID: <3E527764.6D55B46C@noaa.gov> Jeff Harmon wrote: > > I want to do database work, a little crypto for the math, general > > internet programing. Are there any books that would fulfill my needs? For internet programming, Steve Holden's "Python Web Programming" is excellent. For leaning Python, "Learning Python" from O'Reilly is a good one (in addition to all the stuff on the web) "Python Essential Reference, David Beazley, New Riders, ISBN: 0-7357-1091-0". I agree on tnis one. It is excellent, but it really is a reference, not a tutorial, If you are new to Python, you will need at least something to get up to speed, the "official" tutorial on the python.org site at the very least. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker@noaa.gov Tue Feb 18 18:06:53 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 18 Feb 2003 10:06:53 -0800 Subject: [Pythonmac-SIG] MacPython-OSX vs. wxPython References: Message-ID: <3E52763D.B1938B23@noaa.gov> Kurt Marek wrote: > More generally, what exactly is wxPython and how does it relate to > MacPython-OSX 2.3? wxPython is a platform independent GUI tookit for Python, basesd on the wxWindows C++ library. www.wxpython.org www.wxWindows.org If you want to develop apps with a GUI, and you want them to work in places other than the Mac, then you should consider using it. (the other option is tkInter). If you want to develop mac only apps, or non-gui apps, then you don't need it. That being said, when wxPython gets a little more stable, it may very well be a good option for developing Mac only apps as well, particularly if you want to use PythonCard, which is based on wxPython. pythoncard.sourceforge.net/ -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker@noaa.gov Tue Feb 18 18:08:10 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Tue, 18 Feb 2003 10:08:10 -0800 Subject: [Pythonmac-SIG] So confused! MacPython-OSX 2.3a1, 2.4? References: Message-ID: <3E52768A.2DCA16A8@noaa.gov> Bill Bedford wrote: > Does MacPython-OSX 2.3a1 work on OSX1.1.x? The binary certainly won't. OSX 10.1 and 10.3 are not binary compatible. I don't know if you can build it, but there are a lot of reasons to upgrade to 10.2.* anyway. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From tony@lownds.com Tue Feb 18 20:35:44 2003 From: tony@lownds.com (Tony Lownds) Date: Tue, 18 Feb 2003 12:35:44 -0800 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: References: Message-ID: --============_-1166521948==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi Just, At 1:29 PM +0100 2/18/03, Just van Rossum wrote: >Tony Lownds wrote: > >> I think there may be another problem with the latest change to >> applets: The __main__.py file used to be executed with the -psn >> arguments filtered out, but now the -psn arguments are not getting >> filtered out. >> >> Is -psn argument handling the responsibility of the main program? > >Yes. But perhaps BuildApplet can provide a wrapper that handles this. Since BuildApplet did do so in 2.2, I think providing a wrapper would be a Good Thing. > > Or should bundlebuilder take care of that? > >No, there are cases where the -psn argument is needed by the main >program (possibly only apps made with PyObjC). So it's not bundlebuilder's responsibility, but it may be BuildApplets' responsibility. If the main program intends to ignore the -psn argument, it's easy enough to just do that in the main program: if len(sys.argv) > 1 and sys.argv[1][:4] == '-psn': del sys.argv[1] ...but the wrapper script could also simply drop the "$1" from the exec line too. Handling the -psn argument properly in the main program also seems easy enough: import argvemulator argvemulator.ArgvCollector().mainloop() I'm worried about the extra startup time with argvemulator: it takes 21 seconds on my box, if I don't drop files! And if I do drop files, it breaks: Exception in AE event handler function Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/argvemulator.py", line 89, in callback_wrapper rv = apply(_function, (_object,), _parameters) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/argvemulator.py", line 104, in open_file fss = alias.Resolve()[0] AttributeError: 'Carbon.File.Alias' object has no attribute 'Resolve' AE error: (-1, 'queue element not found during deletion') in High Level Event: '0x61657674' '0x6f646f63' Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/argvemulator.py", line 53, in lowlevelhandler AE.AEProcessAppleEvent(event) Error: (-1, 'queue element not found during deletion') >Regarding the Idle problem: I'm not sure why this --extra argument is >there in the first place; perhaps it's not needed with the new >bundlebuilder-based BuildApplet? I'm passing a directory that needs to go into Resources. Is there is a better option to use than --extra? -Tony --============_-1166521948==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Pythonmac-SIG] IDLE etc build from CVS
Hi Just,

At 1:29 PM +0100 2/18/03, Just van Rossum wrote:
Tony Lownds wrote:

> I think there may be another problem with the latest change to
> applets: The __main__.py file used to be executed with the -psn
> arguments filtered out, but now the -psn arguments are not getting
> filtered out.
>
> Is -psn argument handling the responsibility of the main program?
Yes. But perhaps BuildApplet can provide a wrapper that handles this.

Since BuildApplet did do so in 2.2, I think providing a wrapper would be a Good Thing.

> Or should bundlebuilder take care of that?

No, there are cases where the -psn argument is needed by the main
program (possibly only apps made with PyObjC).

So it's not bundlebuilder's responsibility, but it may be BuildApplets' responsibility.

If the main program intends to ignore the -psn argument, it's easy enough to just do that in the main program:

if len(sys.argv) > 1 and sys.argv[1][:4] == '-psn':
    del sys.argv[1]

...but the wrapper script could also simply drop the "$1" from the exec line too.

Handling the -psn argument properly in the main program also seems easy enough:

import argvemulator
argvemulator.ArgvCollector().mainloop()

I'm worried about the extra startup time with argvemulator: it takes 21 seconds on my box, if I don't drop files! And if I do drop files, it breaks:

Exception in AE event handler function
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/argvemulator.py", line 89, in callback_wrapper
    rv = apply(_function, (_object,), _parameters)
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/argvemulator.py", line 104, in open_file
    fss = alias.Resolve()[0]
AttributeError: 'Carbon.File.Alias' object has no attribute 'Resolve'
AE error:  (-1, 'queue element not found during deletion')
in High Level Event: '0x61657674' '0x6f646f63'
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/argvemulator.py", line 53, in lowlevelhandler
    AE.AEProcessAppleEvent(event)
Error: (-1, 'queue element not found during deletion')

Regarding the Idle problem: I'm not sure why this --extra argument is
there in the first place; perhaps it's not needed with the new
bundlebuilder-based BuildApplet?

I'm passing a directory that needs to go into Resources. Is there is a better option to use than --extra?

-Tony
--============_-1166521948==_ma============-- From bob@redivi.com Tue Feb 18 21:03:31 2003 From: bob@redivi.com (Bob Ippolito) Date: Tue, 18 Feb 2003 16:03:31 -0500 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: Message-ID: <6F3FA3EF-4384-11D7-B93C-000A95686CD8@redivi.com> --Apple-Mail-6-723018133 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Tuesday, Feb 18, 2003, at 15:35 America/New_York, Tony Lownds wrote: > > Is -psn argument handling the responsibility of the main program? > No, there are cases where the -psn argument is needed by the main > program (possibly only apps made with PyObjC). Does PyObjC *actually* need that? I've never seen a Cocoa application break if I execute it from the terminal (without using the "open" command) using just its full path with no argv. Worst case, you could generate the PSN from GetCurrentProcess or GetProcessInfo (with a {0, kCurrentProcess}).. if it's necessary anywhere, that functionality should be added to the Carbon modules. -bob --Apple-Mail-6-723018133 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII On Tuesday, Feb 18, 2003, at 15:35 America/New_York, Tony Lownds wrote: > Is -psn argument handling the responsibility of the main program? No, there are cases where the -psn argument is needed by the main program (possibly only apps made with PyObjC). Does PyObjC *actually* need that? I've never seen a Cocoa application break if I execute it from the terminal (without using the "open" command) using just its full path with no argv. Worst case, you could generate the PSN from GetCurrentProcess or GetProcessInfo (with a {0, kCurrentProcess}).. if it's necessary anywhere, that functionality should be added to the Carbon modules. -bob --Apple-Mail-6-723018133-- From wtbridgman@radix.net Wed Feb 19 01:29:20 2003 From: wtbridgman@radix.net (W.T. Bridgman) Date: Tue, 18 Feb 2003 20:29:20 -0500 Subject: [Pythonmac-SIG] Development Matrix (or "sometimes there's just too many choices...") Message-ID: <91C025FD-43A9-11D7-AFAB-0050E485FC7A@radix.net> I've explored what's on the Mac sites and (casually) follow this group traffic and now find myself wondering just what combinations of python (MacPython, Unix Python), window environments (X11, Aqua, and now Apple X11) and GUIs (Tkinter, wxPython) play well together (twelve possible combinations? which are not viable?). Then there's the installation options - standard Unix (/usr/local/), Framework, and Fink bringing the count up to 36. I assume that the merging of MacPython and Unix Python (still on for v2.3?) will drop this count by half. How many of these installations build 'out-of-the-box', using the instructions in the available README or INSTALL file? My main experience is with Python 2.2 where I've installed Unix (Macho?) Python as a framework. I've been unsuccessful installing any Aqua GUI. There's the additional packages I actively use (Numeric, PyXML, PIL, HTMLgen, ReportLab) and packages I'd like to use but have never had even partial success at installing (PyOpenGL, numarray - does it conflict with Numeric?, pyFITS, VPython, VTK, MayaVi) not to mention some of the support libraries for /usr/local/lib/ such as libjpeg, etc. Are there limitations to which combinations of these components play well together? Should we consider mapping this 'space'? For example, maybe we'd want to build a listing with notes of what combinations have been successfully built and used? Consider something like: Here's some notes based on my newest builds with MacOS 10.2.+ from my configuration journal. * Unix Python v2.2: Framework install per instructions * Aqua Tkinter: per Tony's notes. Result was IDLE window fired up but nothing else * wxPythonOSX 2.3.3.1: built but hangs on demos & samples * Numeric 22.0: per instructions * PyXML 0.8: minor patch needed in setup.py, then builds per instructions. * PIL: couldn't get libjpeg to build, but rest of package built fine without it. * HTMLgen: installs, but all over the site-packages/ level. Need to make this cleaner. * ReportLab 1.10: drop-in with a reportlab.pth file in site-packages/. Additional packages are on my "To Do" list. I recognize I might be a few revs behind, usually because I'm trying to use the installation for my development work rather than trying to keep up with all the updates. :^) Anyone have any thoughts on how we could keep better track of some of these issues? Comments, suggestions, etc. welcome, Tom From jwblist@olympus.net Wed Feb 19 06:22:22 2003 From: jwblist@olympus.net (John W Baxter) Date: Tue, 18 Feb 2003 22:22:22 -0800 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: References: Message-ID: At 11:42 +0100 2/18/2003, Jack Jansen wrote: >Just in case people were >wondering why I would be doing a 3D graphic interface to an installer. Progress spear? --John (who grew up reading Ogden Nash and Richard Armour) From bob@redivi.com Wed Feb 19 06:30:14 2003 From: bob@redivi.com (Bob Ippolito) Date: Wed, 19 Feb 2003 01:30:14 -0500 Subject: [Pythonmac-SIG] updating command line python In-Reply-To: Message-ID: <9AB015FC-43D3-11D7-B93C-000A95686CD8@redivi.com> On Tuesday, Feb 18, 2003, at 05:42 America/New_York, Jack Jansen wrote: > > On Tuesday, Feb 18, 2003, at 11:00 Europe/Amsterdam, Jack Jansen wrote: >> Next on my todo list is an all-singing-all-dancing version of >> PackageManager (the GUI to pimp) which will use PyOpenGL > > It will, of course, use PyObjC, not PyOpenGL. Just in case people were > wondering why I would be doing a 3D graphic interface to an installer. But just think of how useful it would be if you happened to be working for the production team for the sequel to Hackers, Antitrust, or Swordfish! -bob From Jack.Jansen@cwi.nl Wed Feb 19 11:50:18 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 19 Feb 2003 12:50:18 +0100 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: Message-ID: <51415C6E-4400-11D7-B90B-0030655234CE@cwi.nl> Building applets has been fixed in CVS, and so has argvemulator. I haven't looked at the startup time yet, that'll have to wait until after 2.3a2. These long startup times are something that's only started to bother me recently. If you run things with "pythonw -v" it seems that it's always the import of the first Carbon module that causes the delay. I'm not sure why it suddenly appeared, or at least suddenly became more noticeable. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From kevin@macosx.com Wed Feb 19 14:19:05 2003 From: kevin@macosx.com (kevin parks) Date: Wed, 19 Feb 2003 23:19:05 +0900 Subject: [Pythonmac-SIG] Cocoa apps in Python? In-Reply-To: <20030218170002.24317.9605.Mailman@mail.python.org> Message-ID: <1A68AEBE-4415-11D7-BA47-003065555ABC@macosx.com> Perhaps this a remedial question, but i was wondering if it is at all possible to built a cocoa app using Python. I don't know Objective-C (but someday would like to learn it a bit), am allergic to Java, and in love with Python. I know that you can use C, C++, and Java to write Cocoa apps, is there a bridge to use Python? If so, is this really hard to use? Are there any examples/toots/instructions on this? I know that in the long run the answer is to use Objective-C, but i am now really used to Python, love all the built-in goodies, and not looking forward to learning yet another programing language, i just want to wrap-up some shell scripts have an get my feet wet with Cocoa and the interface builder or, is it Project builder? I don't know, i used the NeXT so the names get all jumbled in my head. I am just using the built-in Apple compiled Python (I am waiting for the dust to settle), though i think i've got readlines in there. Cheers, kevin parks seoul, korea From bootsch@acm.org Wed Feb 19 14:34:16 2003 From: bootsch@acm.org (Paul Boots) Date: Wed, 19 Feb 2003 15:34:16 +0100 Subject: [Pythonmac-SIG] Cocoa apps in Python? In-Reply-To: <1A68AEBE-4415-11D7-BA47-003065555ABC@macosx.com> References: <1A68AEBE-4415-11D7-BA47-003065555ABC@macosx.com> Message-ID: Sure is possible, checkout "pyobjc" It binds python to objective c - you can work with the cocoa frameworks, 'foundation' and 'application' It's very cool - there's even a Project Builder template, you build the gui in Interface Builder have fun Paul At 23:19 +0900 19-02-2003, kevin parks wrote: >Perhaps this a remedial question, but i was wondering if it is at all possible to built a cocoa app using Python. I don't know Objective-C (but someday would like to learn it a bit), am allergic to Java, and in love with Python. I know that you can use C, C++, and Java to write Cocoa apps, is there a bridge to use Python? If so, is this really hard to use? Are there any examples/toots/instructions on this? I know that in the long run the answer is to use Objective-C, but i am now really used to Python, love all the built-in goodies, and not looking forward to learning yet another programing language, i just want to wrap-up some shell scripts have an get my feet wet with Cocoa and the interface builder or, is it Project builder? I don't know, i used the NeXT so the names get all jumbled in my head. > >I am just using the built-in Apple compiled Python (I am waiting for the dust to settle), though i think i've got readlines in there. > >Cheers, > >kevin parks >seoul, korea > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig -- ----------------------------------------------------------------------- Paul Boots mailto:bootsch@acm.org PGP Public Key: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0x53184F80 ----------------------------------------------------------------------- From just@letterror.com Wed Feb 19 17:54:03 2003 From: just@letterror.com (Just van Rossum) Date: Wed, 19 Feb 2003 18:54:03 +0100 Subject: [Pythonmac-SIG] Cocoa apps in Python? In-Reply-To: Message-ID: Paul Boots wrote: [PyObjC] > It's very cool - It sure is! > there's even a Project Builder template, > you build the gui in Interface Builder Yes and yes, although these two things are not at all related. You can build apps without Project Builder (using bundlebuilder.py, see the various buildapp.py scripts in the PyObjC Examples section), yet still use Interface Builder. You can create a Python template from a nib with the nibclassbuilder tool. Just From just@letterror.com Wed Feb 19 18:20:00 2003 From: just@letterror.com (Just van Rossum) Date: Wed, 19 Feb 2003 19:20:00 +0100 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: <51415C6E-4400-11D7-B90B-0030655234CE@cwi.nl> Message-ID: Jack Jansen wrote: > These long startup times are something that's only started to bother > me recently. If you run things with "pythonw -v" it seems that it's > always the import of the first Carbon module that causes the delay. > I'm not sure why it suddenly appeared, or at least suddenly became > more noticeable. I've noticed it, too, since fairly recently, and indeed with Carbon modules. But I have also insane startup times with PyObjC apps and I was already blaming my lack of disk space (and likely high fragmentation). Maybe the two issues aren't even related. It's getting quite irritating... Just From tony@lownds.com Wed Feb 19 18:19:24 2003 From: tony@lownds.com (Tony Lownds) Date: Wed, 19 Feb 2003 10:19:24 -0800 Subject: [Pythonmac-SIG] IDLE etc build from CVS In-Reply-To: <51415C6E-4400-11D7-B90B-0030655234CE@cwi.nl> References: <51415C6E-4400-11D7-B90B-0030655234CE@cwi.nl> Message-ID: Cool, works great. I have updated the IDLE bug/patch (IDLE still won't work as built from CVS) http://python.org/sf/688266 A small issue: The __argvemulator_.py is leaving modules in the __main__ namespace. These are visible to IDLE users if they type dir() Instead of: import argvemulator, os argvemulator.ArgvCollector().mainloop() execfile(os.path.join(os.path.split(__file__)[0], "macosx_main.py")) How about: __import__('argvemulator').ArgvCollector().mainloop() execfile( (lambda os=__import__('os'): os.path.join(os.path.dirname(__file__), "macosx_main.py") )() ) Its ugly but keeps __main__ clean. -Tony At 12:50 PM +0100 2/19/03, Jack Jansen wrote: >Building applets has been fixed in CVS, and so has argvemulator. I >haven't looked at the startup time yet, that'll >have to wait until after 2.3a2. > >These long startup times are something that's only started to bother >me recently. If you run things with "pythonw -v" >it seems that it's always the import of the first Carbon module that >causes the delay. I'm not sure why it suddenly appeared, or at least >suddenly became more noticeable. >-- >Jack Jansen, , http://www.cwi.nl/~jack >If I can't dance I don't want to be part of your revolution -- Emma Goldman > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig From dyoo@hkn.eecs.berkeley.edu Wed Feb 19 20:39:21 2003 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Wed, 19 Feb 2003 12:39:21 -0800 (PST) Subject: [Pythonmac-SIG] Cocoa apps in Python? In-Reply-To: Message-ID: On Wed, 19 Feb 2003, Just van Rossum wrote: > Paul Boots wrote: > > [PyObjC] > > It's very cool - > > It sure is! > > > there's even a Project Builder template, you build the gui in > > Interface Builder > > Yes and yes, although these two things are not at all related. You can > build apps without Project Builder (using bundlebuilder.py, see the > various buildapp.py scripts in the PyObjC Examples section), yet still > use Interface Builder. You can create a Python template from a nib with > the nibclassbuilder tool. Hi everyone, Has anyone written any more tutorials on PyObjC? The only one I've seen so far is on Oreilly's macdevcenter.com: http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html I'm just curious if there's a gentler introduction, or if PyObjC is a fast-moving target that introductions are still bound to be outdated in weeks? From just@letterror.com Wed Feb 19 21:41:21 2003 From: just@letterror.com (Just van Rossum) Date: Wed, 19 Feb 2003 22:41:21 +0100 Subject: [Pythonmac-SIG] Cocoa apps in Python? In-Reply-To: Message-ID: Danny Yoo wrote: > Has anyone written any more tutorials on PyObjC? The only one I've > seen so far is on Oreilly's macdevcenter.com: > > http://www.macdevcenter.com/pub/a/mac/2003/01/31/pyobjc_one.html > > I'm just curious if there's a gentler introduction, or if PyObjC is a > fast-moving target that introductions are still bound to be outdated > in weeks? It's moving, but slowing down. Your best bet is to check out the PyObjC examples, and learn how to translate ObjC method syntax to Python: [obj foo:x bar:y] translates to obj.foo_bar_(x, y) # note the funny underscores The canonical way to spell the ObjC method signature is foo:bar: Replacing every : with an _ gets you the Python method name. Methods without arguments don't get funny underscores: [app delegate] becomes app.delegate(). Once you're familiar with this you should be able to use any Cocoa tutorial that uses Objective-C. Also check the pyobjc-dev mailing list archives, there have been other examples posted. Just From bob@redivi.com Wed Feb 19 22:13:33 2003 From: bob@redivi.com (Bob Ippolito) Date: Wed, 19 Feb 2003 17:13:33 -0500 Subject: [Pythonmac-SIG] Cocoa apps in Python? In-Reply-To: Message-ID: <6249B28D-4457-11D7-9123-000A95686CD8@redivi.com> On Wednesday, Feb 19, 2003, at 16:41 America/New_York, Just van Rossum wrote: > > [obj foo:x bar:y] > > translates to > > obj.foo_bar_(x, y) # note the funny underscores > > The canonical way to spell the ObjC method signature is > > foo:bar: While we're on the newbie subject here, how exactly are we supposed to make selectors? I've had no problems just passing 'foo:bar:' - but is there a objc.something('foo:bar'), objc.something(SomeWrapper.foo_bar_), or objc.something(someInstance.foo_bar_) preferred method that I should be aware of? I think we need a Wiki for the FAQ.. so it can write itself, without necessarily giving us all CVS and/or website access. -bob From eppstein@ics.uci.edu Wed Feb 19 23:12:09 2003 From: eppstein@ics.uci.edu (David Eppstein) Date: Wed, 19 Feb 2003 15:12:09 -0800 Subject: [Pythonmac-SIG] Re: Cocoa apps in Python? References: <6249B28D-4457-11D7-9123-000A95686CD8@redivi.com> Message-ID: In article <6249B28D-4457-11D7-9123-000A95686CD8@redivi.com>, Bob Ippolito wrote: > While we're on the newbie subject here, how exactly are we supposed to > make selectors? I've had no problems just passing 'foo:bar:' - but is > there a objc.something('foo:bar'), > objc.something(SomeWrapper.foo_bar_), or > objc.something(someInstance.foo_bar_) preferred method that I should be > aware of? I think you can pass either Python callables (object.method_) or strings ("method:"). -- David Eppstein UC Irvine Dept. of Information & Computer Science eppstein@ics.uci.edu http://www.ics.uci.edu/~eppstein/ From Chris.Barker@noaa.gov Wed Feb 19 22:34:03 2003 From: Chris.Barker@noaa.gov (Chris Barker) Date: Wed, 19 Feb 2003 14:34:03 -0800 Subject: [Pythonmac-SIG] Development Matrix (or "sometimes there's just too many choices...") In-Reply-To: <91C025FD-43A9-11D7-AFAB-0050E485FC7A@radix.net> Message-ID: <3F5AF0BE-445A-11D7-8027-000393A96660@noaa.gov> On Tuesday, February 18, 2003, at 05:29 PM, W.T. Bridgman wrote: > I've explored what's on the Mac sites and (casually) follow this group > traffic and now find myself wondering just what combinations of python > (MacPython, Unix Python), window environments (X11, Aqua, and now > Apple X11) and GUIs (Tkinter, wxPython) play well together (twelve > possible combinations? which are not viable?). Then there's the > installation options - standard Unix (/usr/local/), Framework, and > Fink bringing the count up to 36. I assume that the merging of > MacPython and Unix Python (still on for v2.3?) will drop this count by > half. And the count should drop a lot more as things settle down. As I understand it, when Python 2.3 is out, we should have ONE python for OS-X that can do it all: unix scripting, Carbon development, cocoa development, etc. Then there won't be a need for all those different versions, and we can all focus on getting all the extensions we want to work right. wxPython and aquaTK are in progress, and there are plenty of other folks that want PIL, Numeric, NumArray, mxTools, VTK, PyOpenGL, SciPy, etc, etc. to work. Jack is even putting together a binary package system so that these can all be easy to install. If you are working on something that doesn't have to be production quality for another 5 months or so, I'd go with 2.3a, and work on getting the pieces you want working. You'll have help from this group. -Chris Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob@redivi.com Thu Feb 20 03:18:18 2003 From: bob@redivi.com (Bob Ippolito) Date: Wed, 19 Feb 2003 22:18:18 -0500 Subject: [Pythonmac-SIG] Development Matrix (or "sometimes there's just too many choices...") In-Reply-To: <3F5AF0BE-445A-11D7-8027-000393A96660@noaa.gov> Message-ID: On Wednesday, Feb 19, 2003, at 17:34 America/New_York, Chris Barker wrote: > > On Tuesday, February 18, 2003, at 05:29 PM, W.T. Bridgman wrote: > >> I've explored what's on the Mac sites and (casually) follow this >> group traffic and now find myself wondering just what combinations of >> python (MacPython, Unix Python), window environments (X11, Aqua, and >> now Apple X11) and GUIs (Tkinter, wxPython) play well together >> (twelve possible combinations? which are not viable?). Then there's >> the installation options - standard Unix (/usr/local/), Framework, >> and Fink bringing the count up to 36. I assume that the merging of >> MacPython and Unix Python (still on for v2.3?) will drop this count >> by half. > > And the count should drop a lot more as things settle down. As I > understand it, when Python 2.3 is out, we should have ONE python for > OS-X that can do it all: unix scripting, Carbon development, cocoa > development, etc. Then there won't be a need for all those different > versions, and we can all focus on getting all the extensions we want > to work right. wxPython and aquaTK are in progress, and there are > plenty of other folks that want PIL, Numeric, NumArray, mxTools, VTK, > PyOpenGL, SciPy, etc, etc. to work. Jack is even putting together a > binary package system so that these can all be easy to install. > > If you are working on something that doesn't have to be production > quality for another 5 months or so, I'd go with 2.3a, and work on > getting the pieces you want working. You'll have help from this group. If anyone really needs PIL, Numeric, NumArray, mxTools, PyOpenGL, pygame, Carbon, IDLE, tkinter, etc. I have those compiled/backported and working with the stock 2.2.. I can package that up at some point if there's a need. It's all going to break when apple updates their python though. I'm sure VTK and SciPy would port as well, I just don't use those yet. -bob From cjl@physics.otago.ac.nz Thu Feb 20 04:11:35 2003 From: cjl@physics.otago.ac.nz (Chris Lee) Date: Thu, 20 Feb 2003 17:11:35 +1300 Subject: [Pythonmac-SIG] Development Matrix (or "sometimes there's just too many choices...") Message-ID: <666BEC2B-4489-11D7-A0A6-0003937807FC@physics.otago.ac.nz> I seem to recall trying SciPy. Initially it didn't like g77 and when I told it to do C only it installed all right but didn't actually work. Then like magic the problem I was installing SciPy to fix went away and I lost interest.. Anyway for someone who actually knows something about installing stuff it should work :) Cheers Chris' On Thursday, February 20, 2003, at 04:18 PM, Bob Ippolito wrote: > I'm sure VTK and SciPy would port as well, I just don't use those yet. ################################# Chris Lee Physics Department Otago University PO Box 56 Dunedin New Zealand Phone ++64 3 479 7749 Fax ++64 3 479 0964 ################################# From eppstein@ics.uci.edu Thu Feb 20 07:37:16 2003 From: eppstein@ics.uci.edu (David Eppstein) Date: Wed, 19 Feb 2003 23:37:16 -0800 Subject: [Pythonmac-SIG] Re: Development Matrix (or "sometimes there's just too many choices...") References: <91C025FD-43A9-11D7-AFAB-0050E485FC7A@radix.net> <3F5AF0BE-445A-11D7-8027-000393A96660@noaa.gov> Message-ID: In article <3F5AF0BE-445A-11D7-8027-000393A96660@noaa.gov>, "Chris Barker" wrote: > And the count should drop a lot more as things settle down. As I > understand it, when Python 2.3 is out, we should have ONE python for > OS-X that can do it all: unix scripting, Carbon development, cocoa > development, etc. Well, except that if you want to do standalone application development without bundling python itself as part of your app, you seem to be stuck with the python 2.2 version that apple included with 10.2... -- David Eppstein UC Irvine Dept. of Information & Computer Science eppstein@ics.uci.edu http://www.ics.uci.edu/~eppstein/ From berkowit@silcom.com Thu Feb 20 07:49:06 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Wed, 19 Feb 2003 23:49:06 -0800 Subject: [Pythonmac-SIG] Re: Development Matrix (or "sometimes there's just too many choices...") In-Reply-To: Message-ID: On 2/19/03 11:37 PM, "David Eppstein" wrote: > In article <3F5AF0BE-445A-11D7-8027-000393A96660@noaa.gov>, > "Chris Barker" wrote: > >> And the count should drop a lot more as things settle down. As I >> understand it, when Python 2.3 is out, we should have ONE python for >> OS-X that can do it all: unix scripting, Carbon development, cocoa >> development, etc. > > Well, except that if you want to do standalone application development > without bundling python itself as part of your app, you seem to be stuck > with the python 2.2 version that apple included with 10.2... Oh, and then things might change in 10.3... -- Paul Berkowitz From bob@redivi.com Thu Feb 20 10:05:44 2003 From: bob@redivi.com (Bob Ippolito) Date: Thu, 20 Feb 2003 05:05:44 -0500 Subject: [Pythonmac-SIG] Re: Development Matrix (or "sometimes there's just too many choices...") In-Reply-To: Message-ID: On Thursday, Feb 20, 2003, at 02:37 America/New_York, David Eppstein wrote: > In article <3F5AF0BE-445A-11D7-8027-000393A96660@noaa.gov>, > "Chris Barker" wrote: > >> And the count should drop a lot more as things settle down. As I >> understand it, when Python 2.3 is out, we should have ONE python for >> OS-X that can do it all: unix scripting, Carbon development, cocoa >> development, etc. > > Well, except that if you want to do standalone application development > without bundling python itself as part of your app, you seem to be > stuck > with the python 2.2 version that apple included with 10.2... Which you have to execve(...) anyways if you're going to make any use of it for GUI applications, since it's not supplied as a dylib or framework. -bob From deleeuw@stat.ucla.edu Thu Feb 20 19:25:39 2003 From: deleeuw@stat.ucla.edu (Jan de Leeuw) Date: Thu, 20 Feb 2003 11:25:39 -0800 Subject: [Pythonmac-SIG] Python, R, Rpy, wxPython updates on gifi Message-ID: <183EF188-4509-11D7-B2A3-000393860F3C@stat.ucla.edu> --Apple-Mail-2-889946395 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed http://gifi.stat.ucla.edu/pub The update of the macpython-2.3a archive now includes /Applications/wxPythonOSX-2.4.0.2, with an application bundle for pyShell. It also include wxWindowsMac. The framework Python build contains Numeric, numarray, Rpy (0.3.1), wxPython, pyObjc, pygtk. One nice thing about this is that the following sequence actually works (both from pyShell and from PythonIDE) >>> from rpy import * >>> x=r.seq(100) >>> y=r.rnorm(100) >>> r.quartz() >>> r.plot(x,y) It produces a scatterplot in the quartz device window that actually responds to events, i.e. can be brought to the foreground and so on. And you can run >>> r.demo("graphics") Another nice thing, of course, is that you can do wxWindows and Cocoa Programming and R from the same pyShell or PythonIDE window, and every other thing Python. One thing you should NOT do is to try pygtk or the R tcltk package, because they still need X11. My next step is to incorporate PythonCard and build a version of libR.dylib that uses tkAqua (Python already uses tkAqua). I'll remove pygtk, until it can be compiled with the native Carbon gtk. By the way, the IDLE in /Applications/MacPython-2.3a currently does not work. The combined application you have is, of course, a compromise. It has quite a few things (LAPACK, tcl/tk, basic functionality) both on the R and the Python side, which is wasteful. The Carbon stuff in Python seems sort of slow. And Rpy is no speed daemon either. --Apple-Mail-2-889946395 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII http://gifi.stat.ucla.edu/pub The update of the macpython-2.3a archive now includes /Applications/Lucida GrandewxPythonOSX-2.4.0.2, with an application bundle for pyShell. It also include wxWindowsMac. The framework Python build contains Numeric, numarray, Rpy (0.3.1), wxPython, pyObjc, pygtk. One nice thing about this is that the following sequence actually works (both from pyShell and from PythonIDE) >>> from rpy import * >>> x=r.seq(100) >>> y=r.rnorm(100) >>> r.quartz() >>> r.plot(x,y) It produces a scatterplot in the quartz device window that actually responds to events, i.e. can be brought to the foreground and so on. And you can run >>> r.demo("graphics") Another nice thing, of course, is that you can do wxWindows and Cocoa Programming and R from the same pyShell or PythonIDE window, and every other thing Python. One thing you should NOT do is to try pygtk or the R tcltk package, because they still need X11. My next step is to incorporate PythonCard and build a version of libR.dylib that uses tkAqua (Python already uses tkAqua). I'll remove pygtk, until it can be compiled with the native Carbon gtk. By the way, the IDLE in /Applications/MacPython-2.3a currently does not work. The combined application you have is, of course, a compromise. It has quite a few things (LAPACK, tcl/tk, basic functionality) both on the R and the Python side, which is wasteful. The Carbon stuff in Python seems sort of slow. And Rpy is no speed daemon either. --Apple-Mail-2-889946395-- From jpe@wingide.com Thu Feb 20 20:16:25 2003 From: jpe@wingide.com (John Ehresman) Date: 20 Feb 2003 15:16:25 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <1045169886.1854.59.camel@sparrow> References: <1045169886.1854.59.camel@sparrow> Message-ID: <1045772186.1782.42.camel@sparrow> Hi again, I've had a chance to do further testing and it looks like an extension module built against the Python framework will not work with an non-framework interpreter if the framework directory is not present. This means that there probably isn't a way to support the two 2.2 variants with a single extension module file. Is there a way to definitively tell if an interpreter was built with a framework? Also, what happens if an interpreter is built with another framework name? Thanks, John On Thu, 2003-02-13 at 15:58, John Ehresman wrote: > Hi, > > Can extension modules built with python2.2 w/ --enable-framework work > with a python built without --enable-framework? I've been trying to go > through the mail archives and I thought the answer was no, but I just > tried it and it seems to work. > > Also are there any binary incompatibilities between 2.2.0, 2.2.1, and > 2.2.2? > > Thanks, > > John > > From bob@redivi.com Thu Feb 20 20:39:32 2003 From: bob@redivi.com (Bob Ippolito) Date: Thu, 20 Feb 2003 15:39:32 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <1045772186.1782.42.camel@sparrow> Message-ID: <6A6BFAC0-4513-11D7-9123-000A95686CD8@redivi.com> sys.executable is usually enough to tell if it 's framework or not. However, there is only one 2.2 non-framework interpreter around that lives in /usr/bin.. so I would only do binary distributions for the /usr/bin python right now. There's at least 3 other pythons around, and you can pretty much let: (a) the people that compiled their own python compile their own modules (b) let the people distributing their own framework python also distribute all of the binary modules for it (c) let fink maintain their own distribution. This should all be fixed when Python 2.3 comes out, because it has a package management (kinda like CPAN)... as long as the setup.py and build process is fixed for mac users in each case where it breaks. Anyhow, even if you don't use pypi, everyone will presumably be using the same binary distribution at this point anyways, so you could distribute binary packages quite easily. -bob On Thursday, Feb 20, 2003, at 15:16 America/New_York, John Ehresman wrote: > Hi again, > > I've had a chance to do further testing and it looks like an extension > module built against the Python framework will not work with an > non-framework interpreter if the framework directory is not present. > This means that there probably isn't a way to support the two 2.2 > variants with a single extension module file. > > Is there a way to definitively tell if an interpreter was built with a > framework? Also, what happens if an interpreter is built with another > framework name? > > Thanks, > > John > > > On Thu, 2003-02-13 at 15:58, John Ehresman wrote: >> Hi, >> >> Can extension modules built with python2.2 w/ --enable-framework work >> with a python built without --enable-framework? I've been trying to >> go >> through the mail archives and I thought the answer was no, but I just >> tried it and it seems to work. >> >> Also are there any binary incompatibilities between 2.2.0, 2.2.1, and >> 2.2.2? >> >> Thanks, >> >> John >> >> > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Thu Feb 20 20:40:38 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 20 Feb 2003 21:40:38 +0100 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <1045772186.1782.42.camel@sparrow> Message-ID: <91B1F58E-4513-11D7-9870-000A27B19B96@oratrix.com> On donderdag, feb 20, 2003, at 21:16 Europe/Amsterdam, John Ehresman wrote: > Hi again, > > I've had a chance to do further testing and it looks like an extension > module built against the Python framework will not work with an > non-framework interpreter if the framework directory is not present. > This means that there probably isn't a way to support the two 2.2 > variants with a single extension module file. This is actually living *very* dangerously: if you've a module that has been linked against the framework Python and you import that into a non-framework-python there's a good chance you'll end up with two interpreters in one addressspace (both a fully initialized framework Python and a partially initialized framework Python). The bad news is that I don't know how I can detect this situation:-( > Is there a way to definitively tell if an interpreter was built with a > framework? Also, what happens if an interpreter is built with another > framework name? What I do if I need to know is to check with if "Python.framework" in sys.prefix: we are in a framework Python -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From bob@redivi.com Thu Feb 20 21:05:21 2003 From: bob@redivi.com (Bob Ippolito) Date: Thu, 20 Feb 2003 16:05:21 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <91B1F58E-4513-11D7-9870-000A27B19B96@oratrix.com> Message-ID: <05DB0AC1-4517-11D7-9123-000A95686CD8@redivi.com> On Thursday, Feb 20, 2003, at 15:40 America/New_York, Jack Jansen wrote: > What I do if I need to know is to check with > if "Python.framework" in sys.prefix: > we are in a framework Python If you do that, and it works, we are in framework Python 2.3+ ;) -bob From jpe@wingide.com Thu Feb 20 21:15:49 2003 From: jpe@wingide.com (John Ehresman) Date: 20 Feb 2003 16:15:49 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <6A6BFAC0-4513-11D7-9123-000A95686CD8@redivi.com> References: <6A6BFAC0-4513-11D7-9123-000A95686CD8@redivi.com> Message-ID: <1045775750.1782.90.camel@sparrow> On Thu, 2003-02-20 at 15:39, Bob Ippolito wrote: > sys.executable is usually enough to tell if it 's framework or not. Do you look for the substring "Python.framework" in the path of the executable? > However, there is only one 2.2 non-framework interpreter around that > lives in /usr/bin.. so I would only do binary distributions for the > /usr/bin python right now. There's at least 3 other pythons around, > and you can pretty much let: > (a) the people that compiled their own python compile their own modules > (b) let the people distributing their own framework python also > distribute all of the binary modules for it > (c) let fink maintain their own distribution. But then there are people like myself that compile stuff and put it in /usr/local/bin or even somewhere under my home directory (if I didn't have root / administrative privileges). I think it's preferable to not depend on python being in a particular location because then people can have more than one version on their machine; e.g. one with debug symbols, one without. Also, it allows people to ship a version of python with an application. We do this with Wing so a user on Linux who only has 2.2 on his/her machine can run Wing without also installing python version 1.5.2. I don't know if this is possible on OS X, but it's one of the things that nice about the Linux build of Python as opposed to the win32 build, which has some of these same issues. John From jpe@wingide.com Thu Feb 20 21:27:07 2003 From: jpe@wingide.com (John Ehresman) Date: 20 Feb 2003 16:27:07 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <91B1F58E-4513-11D7-9870-000A27B19B96@oratrix.com> References: <91B1F58E-4513-11D7-9870-000A27B19B96@oratrix.com> Message-ID: <1045776427.1782.103.camel@sparrow> On Thu, 2003-02-20 at 15:40, Jack Jansen wrote: > This is actually living *very* dangerously: if you've a module that has > been linked against the framework Python and you import that into a > non-framework-python there's a good chance you'll end up with two > interpreters in one addressspace (both a fully initialized framework > Python and a partially initialized framework Python). The bad news is > that I don't know how I can detect this situation:-( I originally thought it was living dangerously because I've ended up with multiple interpreters in one process on win32 and it's not pretty ;). Can you add a global constant to sys or somewhere else that is set to what framework the interpreter is built against? You possibly can use to this to find mismatches at import time and people who want to distribute multiple extension module binaries could use it to determine which one to load. My current plan to support both versions is to try to load the non-framework one first and then to load one built against the standard Python framework. The flaw I see is that someone who builds with another framework name is potentially going to get 2 interpreters loaded. Do you have any idea how common it is to change the framework name? Thanks, John From bob@redivi.com Thu Feb 20 22:48:31 2003 From: bob@redivi.com (Bob Ippolito) Date: Thu, 20 Feb 2003 17:48:31 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <1045775750.1782.90.camel@sparrow> Message-ID: <6F4EB7AA-4525-11D7-9123-000A95686CD8@redivi.com> On Thursday, Feb 20, 2003, at 16:15 America/New_York, John Ehresman wrote: > On Thu, 2003-02-20 at 15:39, Bob Ippolito wrote: >> sys.executable is usually enough to tell if it 's framework or not. > > Do you look for the substring "Python.framework" in the path of the > executable? > >> However, there is only one 2.2 non-framework interpreter around that >> lives in /usr/bin.. so I would only do binary distributions for the >> /usr/bin python right now. There's at least 3 other pythons around, >> and you can pretty much let: >> (a) the people that compiled their own python compile their own >> modules >> (b) let the people distributing their own framework python also >> distribute all of the binary modules for it >> (c) let fink maintain their own distribution. > > But then there are people like myself that compile stuff and put it in > /usr/local/bin or even somewhere under my home directory (if I didn't > have root / administrative privileges). I think it's preferable to not > depend on python being in a particular location because then people can > have more than one version on their machine; e.g. one with debug > symbols, one without. Also, it allows people to ship a version of > python with an application. We do this with Wing so a user on Linux > who > only has 2.2 on his/her machine can run Wing without also installing > python version 1.5.2. You can depend on Apple Python being at /usr/bin/python, if that's not Apple python, whoever replaced it broke the rules and deserve to learn not to do that :). As I said, leave any other binary distribution of python modules to the maintainers of the distribution... but if you MUST, you can do something like this: # mymodule.py import sys _prefix, _ver, _plat = sys.prefix, sys.version[:3], sys.platform del sys if sys.platform == 'darwin': if (2,3,0) <= _ver < (2,4,0): if _prefix.find('Python.framework') != -1: from py23framework.mymodule import * else: from py23.mymodule import * elif (2,2,0) <= _ver < (2,3,0): if _prefix == '/usr': from py22jaguar.mymodule import * elif _prefix.startswith('/sw'): from py22fink.mymodule import * elif _prefix.find('Python.framework') != -1: from py22framework.mymodule import * else: raise ImportError, "Unknown installation of Python 2.2" else: raise ImportError, "Python %d.%d.%d not supported" % _ver else: raise ImportError, "This module requires OS X" From jpe@wingide.com Thu Feb 20 23:15:16 2003 From: jpe@wingide.com (John Ehresman) Date: 20 Feb 2003 18:15:16 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <6F4EB7AA-4525-11D7-9123-000A95686CD8@redivi.com> References: <6F4EB7AA-4525-11D7-9123-000A95686CD8@redivi.com> Message-ID: <1045782917.5359.74.camel@sparrow> On Thu, 2003-02-20 at 17:48, Bob Ippolito wrote: > As I said, leave any other binary distribution of python modules to the > maintainers of the distribution... but if you MUST, you can do > something like this: > ... Thanks, the example was helpful. Let me just suggest that this is what I, as a distributor of binary modules, would like to see for 2.3: if sys.platform == 'darwin' and sys.osx_framework != None: if sys.osx_framework == 'Python': import module_for_framework module = module_for_framework else: # Ask user to contact us else: import module The name osx_framework can be changed, but what I'm looking for is a way to determine if a framework is used and what it's name is that doesn't depend on pathname conventions. Otherwise, it breaks when a no framework build is put in /home/username/i-like-weird-names.framework Admittedly this is a contrived example, but why not make the framework the executable was compiled with available in the executable? John From bob@redivi.com Thu Feb 20 23:35:04 2003 From: bob@redivi.com (Bob Ippolito) Date: Thu, 20 Feb 2003 18:35:04 -0500 Subject: [Pythonmac-SIG] Re: Extension module binary compatibility In-Reply-To: <1045782917.5359.74.camel@sparrow> Message-ID: On Thursday, Feb 20, 2003, at 18:15 America/New_York, John Ehresman wrote: > On Thu, 2003-02-20 at 17:48, Bob Ippolito wrote: >> As I said, leave any other binary distribution of python modules to >> the >> maintainers of the distribution... but if you MUST, you can do >> something like this: >> ... > > The name osx_framework can be changed, but what I'm looking for is a > way > to determine if a framework is used and what it's name is that doesn't > depend on pathname conventions. Otherwise, it breaks when a no > framework build is put in /home/username/i-like-weird-names.framework > Admittedly this is a contrived example, but why not make the framework > the executable was compiled with available in the executable? In the not too distant future (Python 2.3), everyone on OS X will be using a framework python and/or Apple's jaguar python 2.2. Hopefully Apple will go along with Python 2.3 when it comes out, because they aren't using Python 2.2 for anything as far as I can tell.. not as much as say, Perl 5.6, which happens in scripts, .pkg scripts, mod_perl, and probably other places internally. osx_framework shouldn't be necessary, and should be considered a non-issue for anything but the near term. In any case, whoever renames Python.framework to something else is doing something terrible (almost as bad as replacing /usr/bin/anything).. In any case, you'd have to try really hard to do that *and* have it still work. Assuming Python.framework is in sys.path is very reasonable and shouldn't have any ill consequence.. The only possible scenario I can think of is if someone decided to build a non-framework python and stick it in a subtree with Python.framework in the name. Some of this could be avoided if you do if 'Python.framework' in sys.prefix.split('/') -- but it'd be an extremely rare case where someone would put a non-framewrok python in /somewhere/asdfPython.frameworkasdf/ or /somewhere/Python.framework/usr/lib or what have you. It just won't happen 99.99999% of the time, you'd have to know what you're doing to cause that, and if you know what you're doing you won't do that :) -bob From andrew.straw@adelaide.edu.au Thu Feb 20 23:41:43 2003 From: andrew.straw@adelaide.edu.au (Andrew Straw) Date: Fri, 21 Feb 2003 10:11:43 +1030 Subject: [Pythonmac-SIG] creating package installers for Python variants Message-ID: Question to Mac OS X installer (and Installer.app) gurus: I am distributing a Python package which is largely pure python but has a few C extensions. I would like to create a single .pkg bundle that supports (at least) Python 2.2 framework and Python 2.3 framework in /Libraries. I'm happy to build the extensions for the various Python distributions on my own machine. What I'd like is for both the installation location and the choice of which extensions to use to be user selectable. Does anyone know if this is possible, or should I just make multiple .pkg bundles? This is a rather restricted problem in my case because I do have C extensions. However, for pure Python modules, (at least until PyPI and/or pimp gets up to speed), this could be REALLY useful: The installer could just present a list of Python distributions (found by searching? hardwired? hardwired with a test for actual presence on the machine?) and the user could click on "Python 2.2 (Apple)", "Python 2.2 (Framework)", "Python 2.2 (Fink)", or "Python 2.3 (Framework)" etc. (OK, maybe we shouldn't mess with Fink.) On the other hand, perhaps using the .pkg bundle format isn't appropriate for this task. It does offer the advantage of being familiar to Mac OS X folks, but the possibility for user input may be none. In that case, perhaps creating a custom installer application would do the trick. It might be possible to build this into 2.3 distutils (or 2.4 if it's too late), but because the need for this is now and the future promises to lessen the need, perhaps a standalone application with small footprint to replace Installer.app for this one job might be best. In that case, does anyone know of any projects with an open-source Mac OS X installer application? Cheers! Andrew From Jack.Jansen@cwi.nl Fri Feb 21 09:11:37 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 21 Feb 2003 10:11:37 +0100 Subject: [Pythonmac-SIG] creating package installers for Python variants In-Reply-To: Message-ID: <7ADFDAE8-457C-11D7-B48A-0030655234CE@cwi.nl> On Friday, Feb 21, 2003, at 00:41 Europe/Amsterdam, Andrew Straw wrote: > Question to Mac OS X installer (and Installer.app) gurus: > > I am distributing a Python package which is largely pure python but > has a few C extensions. I would like to create a single .pkg bundle > that supports (at least) Python 2.2 framework and Python 2.3 framework > in /Libraries. I'm happy to build the extensions for the various > Python distributions on my own machine. What I'd like is for both > the installation location and the choice of which extensions to use to > be user selectable. Does anyone know if this is possible, or should I > just make multiple .pkg bundles? I looked at this for a pretty similar reason, but I couldn't find it. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Fri Feb 21 16:27:23 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 21 Feb 2003 17:27:23 +0100 Subject: [Pythonmac-SIG] Found a way to test for the window manager Message-ID: <5B28BA7C-45B9-11D7-B274-0030655234CE@cwi.nl> Folks, I found a way to test for window manager availablity that is fairly cheap and doesn't seem to crash Python under any circumstances. I'm going to add this to MacOS, but I'm not sure about the Python API yet. I can do one of two things (or maybe more, please give alternatives if you have them): 1. A call MacOS.WMAvailable(). Use this something like if MacOS.WMAvailable(): EasyDialogs.Message("This is an important message") else: stderr.write("This is an important message\n") 2. A call MacOS.NeedWM() which would raise an exception if the WM wasn't available. This you would simply call as MacOS.NeedWM() 2 would give a better error message (as it could be encoded in the exception), but simulating 1 with 2 would be expensive/ugly. Opinions? In case people are interested, the trick is twofold. First I call CGMainDisplayID(). This fails with a message (but not an abort) if there isn't a window manager, or if you don't have permission to connect to it. Only if this call succeeds I try to call SetFrontProcess() for the current process. This fails with an error -606 (app is BG-only, and launch flags disallow this) if you're not running from a .app bundle (but it would have abort()ed if you called it from a program in the category above). Oh yes, this whole sequence is only done the first time you call WMAvailable, so the fact the SetFrontProcess pushes you to the front isn't a problem. Actually, it can be seen as a feature, since it'll raise apps to the front also when launched from the terminal window. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From larry.bugbee@boeing.com Fri Feb 21 17:43:48 2003 From: larry.bugbee@boeing.com (Bugbee, Larry) Date: Fri, 21 Feb 2003 09:43:48 -0800 Subject: [Pythonmac-SIG] creating package installers for Python variants Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779FA72CA@XCH-NW-29.nw.nos.boeing.com> FWIW... =20 Consider having the installer find and identify the interpreters = installed. The user would select one and the installer would use a pick = list to install the modules appropriate for that version of the = interpreter. In the event the installer found but one interpreter, it = would simply proceed without user intervention. =20 In some cases the installer would be perhaps a third larger as most = components will be identical for the standard and framework versions, = but there could be but one installer. =20 One could extend the concept a little further and have but one installer = for both 2.2 and 2.3. The user selects the interpreter they want to = update and the installer grabs appropriately from the pick list. Larry -----Original Message----- From: Jack Jansen [mailto:Jack.Jansen@cwi.nl] Sent: Friday, February 21, 2003 1:12 AM To: Andrew Straw Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] creating package installers for Python variants On Friday, Feb 21, 2003, at 00:41 Europe/Amsterdam, Andrew Straw wrote: > Question to Mac OS X installer (and Installer.app) gurus: > > I am distributing a Python package which is largely pure python but=20 > has a few C extensions. I would like to create a single .pkg bundle=20 > that supports (at least) Python 2.2 framework and Python 2.3 framework = > in /Libraries. I'm happy to build the extensions for the various=20 > Python distributions on my own machine. What I'd like is for both=20 > the installation location and the choice of which extensions to use to = > be user selectable. Does anyone know if this is possible, or should I = > just make multiple .pkg bundles? I looked at this for a pretty similar reason, but I couldn't find it. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma=20 Goldman _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From Jack.Jansen@oratrix.com Fri Feb 21 21:56:08 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Fri, 21 Feb 2003 22:56:08 +0100 Subject: [Pythonmac-SIG] MacPython-OS9 2.3a2 available Message-ID: <4892C42E-45E7-11D7-A2A1-000A27B19B96@oratrix.com> MacPython-OS9 2.3a2 is available. As usual, this is for your eyes only for the next day or so and then I'll give it a more widespread distribution. So, please report showstoppers ASAP. Download from http://www.cwi.nl/ftp/jack/python/mac/MacPython23a2active.bin or http://www.cwi.nl/ftp/jack/python/mac/MacPython23a2full.bin or the corresponding HQX files. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@oratrix.com Sat Feb 22 00:00:34 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 22 Feb 2003 01:00:34 +0100 Subject: [Pythonmac-SIG] Slow loading of modules Message-ID: After playing around with DYLD_PRINT_LIBRARIES a bit (setting this environment variable causes the dynamic loader to print out library names as it loads them) I get the impression that I've found the slowdown. It appears that HIToolbox is the main culprit: the first module loading that will stall for approximately 8 seconds on my 400Mhz G3. However, HIToolbox by itself doesn't seem to be the problem. I created a minimal C program that calls SysBeep, and it finished immediately. So, either there's something tricky about using HIToolbox from dynamically loaded code or we're doing something stupid in the way we link to HIToolbox or it has to do with the prebinding or... Just for fun, I modified the Python main program to call SysBeep(), and this significantly lowered the time used. With SysBeep hack: % time ./python.exe -c "import Carbon.AE" 5.640u 0.120s 0:05.99 96.1% 0+0k 0+8io 0pf+0w Without SysBeep hack: % time ./python.exe -c "import Carbon.AE" 8.870u 0.240s 0:09.32 97.7% 0+0k 0+0io 0pf+0w Any suggestions are welcome, -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From uliw@erdw.ethz.ch Sat Feb 22 09:31:27 2003 From: uliw@erdw.ethz.ch (Wortmann, Ulrich) Date: Sat, 22 Feb 2003 10:31:27 +0100 Subject: [Pythonmac-SIG] Out of Office AutoReply: A special funny website Message-ID: Sorry, my e-mail address has changed. Please=20 checkout the following link http://www.utoronto.ca/mailboxsearch.html to find out about my new address. I am sorry for this inconvenience, but = I do recieve more than 100 spam mails a day.... From borgempath@Phreaker.net Sat Feb 22 10:07:04 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Sat, 22 Feb 2003 15:37:04 +0530 Subject: [Pythonmac-SIG] PyXML 0.8.2 build error Message-ID: <64AA73D6-464D-11D7-9DE9-0005024EF27F@Phreaker.net> Thought I'd upgrade to PyXML 0.8.2 just now, and this it the result. I was going to post anyway, but noticed it had already come up, though with a less elegant solution. The problem : python setup.py build Traceback (most recent call last): File "setup.py", line 58, in ? if sys.platform[:6] == "darwin" and \ NameError: name 'distutils' is not defined The solution : Changing the import statement at the top of setup.py from : import sys, os, string to this : import sys, os, string, distutils No errors thereafter, none of the 'extensions/expat/lib/xmltok.c:116: warning: `regparm' attribute directive ignored' that John reported. I'm on OS X v10.1.5. Python 2.2.2 - Joel On Sunday, February 16, 2003, at 03:06 , John Miller wrote: I just downloaded PyXML-0.8.2 and tried to install using the directions in the README. However, the 'build' step failed because of a NameError: """ [moire:/PyXML-0.8.2] jmillr% python setup.py build Traceback (most recent call last): File "setup.py", line 58, in ? if sys.platform[:6] == "darwin" and \ NameError: name 'distutils' is not defined """ After finding the message below in the archives, I commented out the entire four lines in setup.py (lines 58-61): """ #if sys.platform[:6] == "darwin" and \ #distutils.sysconfig.get_config_var("LDSHARED").find ("-flat_namespace") == -1: # Mac OS X #LDFLAGS.append('-flat_namespace') """ and installation proceeded to completion (albeit with many warnings of the form): extensions/expat/lib/xmltok.c:116: warning: `regparm' attribute directive ignored Anyway, it seems as though the PyXML distribution still has a broken setup.py for MacOS X. I'm running OSX 10.2.4 with the December 2002 Developer Tools and the stock 2.2 python. John Miller Technology Services School of Education University of Michigan On Tue, 3 Sep 2002 21:51:58 -0400 W.T. Bridgman wrote: Jack, Got it!! :^) The alternate user didn't work, nor did the single command line, but the single command line commenting out the last -flat_namespace does! In the setup.py in PyXML, there's a line: if sys.platform[:6] == "darwin": # Mac OS X LDFLAGS.append('-flat_namespace') I commented out the LDFLAGS line and that seemed to clear the problem. I suspect this was added at one time for PyXML but then was later incorporated into the rest of the distutils package? Looks like the rest of the build process worked as well. Thanks for the pointer. How does one report this so it is fixed in the next release? Tom From brian_l@mac.com Sat Feb 22 11:10:09 2003 From: brian_l@mac.com (Brian Lenihan) Date: Sat, 22 Feb 2003 03:10:09 -0800 Subject: [Pythonmac-SIG] PyXML 0.8.2 build error In-Reply-To: <64AA73D6-464D-11D7-9DE9-0005024EF27F@Phreaker.net> Message-ID: <3460FE98-4656-11D7-9FA1-000A956B6574@mac.com> On Saturday, February 22, 2003, at 02:07 AM, Joel Rodrigues wrote: > Thought I'd upgrade to PyXML 0.8.2 just now, and this it the result. I > was going to post anyway, but noticed it had already come up, though > with a less elegant solution. > > The problem : > > python setup.py build > Traceback (most recent call last): > File "setup.py", line 58, in ? > if sys.platform[:6] == "darwin" and \ > NameError: name 'distutils' is not defined > > The solution : > > Changing the import statement at the top of setup.py from : > > import sys, os, string > > to this : > > import sys, os, string, distutils That's one way to fix the problem, but the original import line is: from distutils.sysconfig import get_config_vars The author's intention was probably to import config_var, because config_vars will return a list, yet when config_vars is called in setup.py, a string is assumed. The import line then becomes: from distutils.sysconfig import get_config_var And the troublesome line in setup.py: distutils.sysconfig.get_config_var("LDSHARED").find("-flat_namespace") == -1: becomes get_config_var("LDSHARED").find("-flat_namespace") == -1: I filed a bug in the pyxml SourceForge project right after 0.8.2 was released. The SourceForge bug tracker search interface isn't all that great, but it beats searching the archives of this list. If more people would actually file bugs, it would be even easier to track problems like this. Hint, hint. > > No errors thereafter, none of the 'extensions/expat/lib/xmltok.c:116: > warning: `regparm' attribute directive ignored' that John reported. > > I'm on OS X v10.1.5. Python 2.2.2 > > - Joel > > > On Sunday, February 16, 2003, at 03:06 , John Miller wrote: > > I just downloaded PyXML-0.8.2 and tried to install using the > directions in the README. However, the 'build' step failed because of > a NameError: > > """ > [moire:/PyXML-0.8.2] jmillr% python setup.py build > Traceback (most recent call last): > File "setup.py", line 58, in ? > if sys.platform[:6] == "darwin" and \ > NameError: name 'distutils' is not defined > """ > > After finding the message below in the archives, I commented out the > entire four lines in setup.py (lines 58-61): > > """ > #if sys.platform[:6] == "darwin" and \ > #distutils.sysconfig.get_config_var("LDSHARED").find > ("-flat_namespace") == -1: > # Mac OS X > #LDFLAGS.append('-flat_namespace') > """ > > and installation proceeded to completion (albeit with many warnings of > the form): > > extensions/expat/lib/xmltok.c:116: warning: `regparm' attribute > directive ignored > > Anyway, it seems as though the PyXML distribution still has a broken > setup.py for MacOS X. I'm running OSX 10.2.4 with the December 2002 > Developer Tools and the stock 2.2 python. > > John Miller > Technology Services > School of Education > University of Michigan > > On Tue, 3 Sep 2002 21:51:58 -0400 W.T. Bridgman > wrote: > > Jack, > > Got it!! :^) > > The alternate user didn't work, nor did the single command line, but > the single command line commenting out the last -flat_namespace does! > > In the setup.py in PyXML, there's a line: > > if sys.platform[:6] == "darwin": # Mac OS X > LDFLAGS.append('-flat_namespace') > > I commented out the LDFLAGS line and that seemed to clear the > problem. I suspect this was added at one time for PyXML but then was > later incorporated into the rest of the distutils package? > > Looks like the rest of the build process worked as well. > > Thanks for the pointer. How does one report this so it is fixed in > the next release? > > Tom > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From oussoren@cistron.nl Sat Feb 22 15:21:08 2003 From: oussoren@cistron.nl (Ronald Oussoren) Date: Sat, 22 Feb 2003 16:21:08 +0100 Subject: [Pythonmac-SIG] Slow loading of modules In-Reply-To: Message-ID: <4467B072-4679-11D7-B406-0003931CFE24@cistron.nl> On Saturday, Feb 22, 2003, at 01:00 Europe/Amsterdam, Jack Jansen wrote: > After playing around with DYLD_PRINT_LIBRARIES a bit (setting this > environment variable causes the dynamic loader to print out library > names as it loads them) I get the impression that I've found the > slowdown. It appears that HIToolbox is the main culprit: the first > module loading that will stall for approximately 8 seconds on my > 400Mhz G3. I see the same problem here, ktrace says (kdump -T + script to create incremental timestamps): 2178 python 0.420467 CALL load_shared_file(0x93a20420,0x218000,0xe2614,0xbfffd350,0x4,0xbfffd2e0,0 xbfffd354) 2178 python 0.420592 NAMI "/usr/lib/libcrypto.0.9.dylib" 2178 python 0.420825 RET load_shared_file 0 2178 python 0.421384 CALL close(0x5) 2178 python 0.42152 RET close 0 2178 python 6.57782 CALL open(0x430b0,0,0) 2178 python 6.57802 NAMI "/System/Library/Frameworks/Carbon.framework/Versions/Current/ Frameworks/HIToolbox.framework/HIToolbox" 2178 python 6.57818 RET open 5 The process is doing no systems calls for about 6 seconds between loading libcrypto and the HIToolbox. I hope this helps a little, Ronald From borgempath@Phreaker.net Sat Feb 22 17:47:22 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Sat, 22 Feb 2003 23:17:22 +0530 Subject: [Pythonmac-SIG] PyXML 0.8.2 build error In-Reply-To: <3460FE98-4656-11D7-9FA1-000A956B6574@mac.com> Message-ID: On Saturday, February 22, 2003, at 04:40 , Brian Lenihan wrote: >> The solution : >> >> Changing the import statement at the top of setup.py from : >> >> import sys, os, string >> >> to this : >> >> import sys, os, string, distutils > > That's one way to fix the problem, but the original import line is: > > from distutils.sysconfig import get_config_vars > > The author's intention was probably to import config_var, > because config_vars will return a list, yet when config_vars is > called in setup.py, a string is assumed. > > The import line then becomes: > from distutils.sysconfig import get_config_var > > And the troublesome line in setup.py: > distutils.sysconfig.get_config_var("LDSHARED").find > ("-flat_namespace") == -1: > > becomes > get_config_var("LDSHARED").find("-flat_namespace") == -1: > > I filed a bug in the pyxml SourceForge project right after > 0.8.2 was released. The SourceForge bug tracker search > interface isn't all that great, but it beats searching the > archives of this list. If more people would actually file > bugs, it would be even easier to track problems like this. > Hint, hint. ok. I get the hint. As an aside, I think it would be nice to be able to file bug reports via e-mail, and have it parsed and posted automatically. But then maybe one can do this already ? About the PyXML bug, looks like you actually have some idea of what's going on. Me, I'm just glad it (apparently) works. Cheers, Joel From richardac@mac.com Sat Feb 22 20:24:04 2003 From: richardac@mac.com (Richard Collins) Date: Sat, 22 Feb 2003 21:24:04 +0100 Subject: [Pythonmac-SIG] Re: MacPython-OS9 2.3a2 available Message-ID: <9671EE32-46A3-11D7-BF39-000A27B3E504@mac.com> Jack, After getting back to OS9 to test your release here's what I found. The first thing I noticed is that many of the files unpack without an icon position, all of them except these: BuildApplet BuildApplication Documentation - start here.html EditPythonPrefs Installer Log File Python IDE The next thing, which is more serious, is that starting Python IDE terminated with the following: Traceback (most recent call last): File "MacHD1:Applications (Mac OS 9):MacPython-OS9 2.3a2:Mac:Tools:IDE:PythonIDE.py", line 48, in ? init() File "MacHD1:Applications (Mac OS 9):MacPython-OS9 2.3a2:Mac:Tools:IDE:PythonIDE.py", line 15, in init from Carbon import Qd, QuickDraw File "MacHD1:Applications (Mac OS 9):MacPython-OS9 2.3a2:Lib:plat-mac:Carbon:__init__.py", line 3, in ? warnings.filterwarnings("ignore", "", FutureWarning, ".*Controls") AttributeError: 'module' object has no attribute 'filterwarnings' Running ConfigurePython terminated with the following: Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Mac:scripts:ConfigurePython.py", line 12, in ? File "MacHD1:Applications (Mac OS 9):MacPython-OS9 2.3a2:Lib:plat-mac:macfs.py", line 6, in ? import Carbon.Res File "MacHD1:Applications (Mac OS 9):MacPython-OS9 2.3a2:Lib:plat-mac:Carbon:__init__.py", line 3, in ? warnings.filterwarnings("ignore", "", FutureWarning, ".*Controls") AttributeError: 'module' object has no attribute 'filterwarnings' Something makes me think it should not be looking for you hard drive! Hope this helps. best regards Richard Collins From p.oberndoerfer@urheberrecht.org Sat Feb 22 22:24:18 2003 From: p.oberndoerfer@urheberrecht.org (Pascal Oberndoerfer) Date: Sat, 22 Feb 2003 23:24:18 +0100 Subject: [Pythonmac-SIG] MacPython-2.3a2 framework Message-ID: After downloading the sources for 2.3a2 and doing ./configure --enable-framework make make frameworkinstall opening PackageManager and PythonIDE, they start up and shut down again immediately. WASTELib is in ../waste and I did 'ln -s ../waste waste' in the source directory. What am I doing wrong here? Thanks, Pascal From Jack.Jansen@oratrix.com Sun Feb 23 22:12:40 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sun, 23 Feb 2003 23:12:40 +0100 Subject: [Pythonmac-SIG] Slow loading of modules In-Reply-To: Message-ID: On zaterdag, feb 22, 2003, at 12:30 Europe/Amsterdam, Doug Wyatt wrote: > Try this: > > /python.exe -c "import Carbon.AE" & ; sample python.exe 10 10 > > and then look at the sample log written to /tmp Doug, thanks a lot!!!! I looked at this, and it turns out most of the time is spent in _dyld_link_module, and specifically in _resolve_undefineds and _relocate_modules_being_linked. On a hunch I disabled prebinding for the main executable, which I had enabled only a couple of weeks ago. The results are staggering: - With prebinding: % time ./python.exe -c "pass" 0.130u 0.130s 0:00.62 41.9% 0+0k 24+3io 0pf+0w % time ./python.exe -c "import _AE" 8.140u 0.170s 0:08.54 97.3% 0+0k 8+4io 0pf+0w - Without prebinding: % time ./python.exe -c "pass" 0.100u 0.130s 0:00.28 82.1% 0+0k 0+0io 0pf+0w % time ./python.exe -c "import _AE" 1.130u 0.110s 0:01.39 89.2% 0+0k 0+1io 0pf+0w I definitely do remember a speedup for the initial empty startup (I did actually test that -prebind made a difference:-), so the fact that even that is now worse may be an artifact of changes in site.py or something. It appears that a program that does a lot of dynamic loading of code is worse off when linked prebound. Does anyone have a good explanation for this, or should I file an Apple bug report (even only suggesting that they document this)? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From doug@sonosphere.com Sun Feb 23 22:56:01 2003 From: doug@sonosphere.com (Doug Wyatt) Date: Sun, 23 Feb 2003 14:56:01 -0800 Subject: [Pythonmac-SIG] Slow loading of modules In-Reply-To: Message-ID: On Sunday, Feb 23, 2003, at 14:12 US/Pacific, Jack Jansen wrote: > Doug, > thanks a lot!!!! I looked at this, and it turns out most of the time > is spent in _dyld_link_module, and specifically in _resolve_undefineds > and _relocate_modules_being_linked. > > On a hunch I disabled prebinding for the main executable, which I had > enabled only a couple of weeks ago. The results are staggering: > > - With prebinding: > % time ./python.exe -c "pass" > 0.130u 0.130s 0:00.62 41.9% 0+0k 24+3io 0pf+0w > % time ./python.exe -c "import _AE" > 8.140u 0.170s 0:08.54 97.3% 0+0k 8+4io 0pf+0w > > - Without prebinding: > % time ./python.exe -c "pass" > 0.100u 0.130s 0:00.28 82.1% 0+0k 0+0io 0pf+0w > % time ./python.exe -c "import _AE" > 1.130u 0.110s 0:01.39 89.2% 0+0k 0+1io 0pf+0w > > I definitely do remember a speedup for the initial empty startup (I > did actually test that -prebind made a difference:-), so the fact that > even that is now worse may be an artifact of changes in site.py or > something. > > It appears that a program that does a lot of dynamic loading of code > is worse off when linked prebound. Does anyone have a good explanation > for this, or should I file an Apple bug report (even only suggesting > that they document this)? All I know about prebinding is that all sorts of weird things happen when it's not done right and that fix_prebinding can repair them :-) It might be worth running fix_prebinding and re-trying the prebound test. Are you sure that only the main executable and not the .so's are being linked prebound? If the .so's are prebound, then it seems that each of them might have to get relocated when loaded ... You might ask on the darwin list, and yes, write an Apple bug report if you don't get a good answer. hth, Doug From just@letterror.com Mon Feb 24 09:25:18 2003 From: just@letterror.com (Just van Rossum) Date: Mon, 24 Feb 2003 10:25:18 +0100 Subject: [Pythonmac-SIG] Slow loading of modules In-Reply-To: Message-ID: Jack Jansen wrote: > On a hunch I disabled prebinding for the main executable, which I had > enabled only a couple of weeks ago. The results are staggering: Great, this also immensely reduces startup times of PyObjC apps on my box. Thing are back to normal now, thanks! Just From macpython@lopan.dccs.upenn.edu Tue Feb 25 18:53:26 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Tue, 25 Feb 2003 13:53:26 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app Message-ID: <20030225185325.GJ658@isc.upenn.edu> Dear MacPythonistas: I'm about to try bundling up my own python application for MacOS X 10.2. I'd like a little sanity check before I start. My question is: Is this going to work? I want to distribute this as a single application bundle (MyApp.app). I need Tkinter, so I know I'll need to have the TCL and Tk frameworks in my application. Of course it needs Python too. In addition, I need a version of the cyrus-sasl library compiled differently than the one that Apple includes with the OS. So, here's what I imagine it looking like: MyApp.app/ Info.plist MacOS/ MyApp - sh wrapper to launch ../Resources/myapp/myapp.py python -> ../Frameworks/Python.framework/.../python Frameworks/ TCL.framework/ Tk.framework/ Python.framework/ Resources/ myapp - my application modules lib/ libsasl2 Thanks! From bob@redivi.com Tue Feb 25 19:44:10 2003 From: bob@redivi.com (Bob Ippolito) Date: Tue, 25 Feb 2003 14:44:10 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <20030225185325.GJ658@isc.upenn.edu> Message-ID: <82CC40BB-48F9-11D7-B758-000A95686CD8@redivi.com> Yes, it will work, and the application will be gigantic. The linking it will be tricky though. Although, I highly recommend NOT using aquaTk. -bob On Tuesday, Feb 25, 2003, at 13:53 America/New_York, John Speno wrote: > Dear MacPythonistas: > > I'm about to try bundling up my own python application for MacOS X > 10.2. > I'd like a little sanity check before I start. > > My question is: Is this going to work? > > I want to distribute this as a single application bundle (MyApp.app). I > need Tkinter, so I know I'll need to have the TCL and Tk frameworks in > my > application. Of course it needs Python too. In addition, I need a > version > of the cyrus-sasl library compiled differently than the one that Apple > includes with the OS. > > So, here's what I imagine it looking like: > > MyApp.app/ > Info.plist > MacOS/ > MyApp - sh wrapper to launch ../Resources/myapp/myapp.py > python -> ../Frameworks/Python.framework/.../python > Frameworks/ > TCL.framework/ > Tk.framework/ > Python.framework/ > Resources/ > myapp - my application modules > lib/ > libsasl2 > > Thanks! > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From macpython@lopan.dccs.upenn.edu Tue Feb 25 19:52:52 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Tue, 25 Feb 2003 14:52:52 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <82CC40BB-48F9-11D7-B758-000A95686CD8@redivi.com> References: <20030225185325.GJ658@isc.upenn.edu> <82CC40BB-48F9-11D7-B758-000A95686CD8@redivi.com> Message-ID: <20030225195252.GM658@isc.upenn.edu> On Tue, Feb 25, 2003 at 02:44:10PM -0500, Bob Ippolito wrote: > Yes, it will work, and the application will be gigantic. The linking > it will be tricky though. Thanks Bob. I've already faced both of those issues. The size doesn't bother me, but the linking may drive me nuts. I really don't know enough yet to handle that part. Before I go further on that method, I'm going to try getting it working with things in their traditional(?) places, i.e. frameworks in /Library/Frameworks. > Although, I highly recommend NOT using aquaTk. I'll bite: Why not? From Jack.Jansen@oratrix.com Tue Feb 25 21:40:39 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Tue, 25 Feb 2003 22:40:39 +0100 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <20030225185325.GJ658@isc.upenn.edu> Message-ID: On dinsdag, feb 25, 2003, at 19:53 Europe/Amsterdam, John Speno wrote: > Dear MacPythonistas: > > I'm about to try bundling up my own python application for MacOS X > 10.2. > I'd like a little sanity check before I start. > > My question is: Is this going to work? Yes, you should be able to get this to work, but you will have to build the Python.framework yourself. I've been looking at creating the framework in such a way that it would allow just copying /Library/Frameworks/Python.framework into a private frameworks directory, but I haven't gotten it to work. (Or, in other words: if you *did* get this to work I would be very interested). If you could write a howto document for doing this that would be very helpful, I'd love to put such information on the MacPython website. > I want to distribute this as a single application bundle (MyApp.app). I > need Tkinter, so I know I'll need to have the TCL and Tk frameworks in > my > application. Of course it needs Python too. In addition, I need a > version > of the cyrus-sasl library compiled differently than the one that Apple > includes with the OS. > > So, here's what I imagine it looking like: > > MyApp.app/ > Info.plist > MacOS/ > MyApp - sh wrapper to launch ../Resources/myapp/myapp.py > python -> ../Frameworks/Python.framework/.../python > Frameworks/ > TCL.framework/ > Tk.framework/ > Python.framework/ > Resources/ > myapp - my application modules > lib/ > libsasl2 > > Thanks! > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From just@letterror.com Tue Feb 25 21:50:34 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 25 Feb 2003 22:50:34 +0100 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: Message-ID: Jack Jansen wrote: > Yes, you should be able to get this to work, but you will have to > build the Python.framework yourself. I've been looking at creating > the framework in such a way that it would allow just copying > /Library/Frameworks/Python.framework > into a private frameworks directory, but I haven't gotten it to work. > (Or, in other words: if you *did* get this to work I would be very > interested). > > If you could write a howto document for doing this that would be very > helpful, I'd love to put such information on the MacPython website. My request would be simpler: write it down in simple steps so I can automate it in bundlebuilder.py ;-) Just From bob@redivi.com Tue Feb 25 22:14:38 2003 From: bob@redivi.com (Bob Ippolito) Date: Tue, 25 Feb 2003 17:14:38 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <20030225195252.GM658@isc.upenn.edu> Message-ID: <8769269F-490E-11D7-B758-000A95686CD8@redivi.com> On Tuesday, Feb 25, 2003, at 14:52 America/New_York, John Speno wrote: > On Tue, Feb 25, 2003 at 02:44:10PM -0500, Bob Ippolito wrote: >> Yes, it will work, and the application will be gigantic. The linking >> it will be tricky though. > > Thanks Bob. > > I've already faced both of those issues. The size doesn't bother me, > but > the linking may drive me nuts. I really don't know enough yet to handle > that part. > > Before I go further on that method, I'm going to try getting it working > with things in their traditional(?) places, i.e. frameworks in > /Library/Frameworks. Thats the easiest way, it's just the install_path stuff that really needs to be changed when building those libraries.. linking your final executable isn't too big of a deal after all that. Since you're using a framework python you should just make a little C wrapper that embeds a python interpreter ( see: http://www.python.org/doc/current/api/embedding.html ). > >> Although, I highly recommend NOT using aquaTk. > > I'll bite: Why not? It's unstable (something of a late alpha quality) and ugly on OS X, you should use PyObjC if possible, if not, try wxWindows (if the GUI has to be cross-platform) or something.. tkinter is kind of old and convoluted too. -bob From jpetrone@cnri.reston.va.us Tue Feb 25 22:22:12 2003 From: jpetrone@cnri.reston.va.us (Jason Petrone) Date: Tue, 25 Feb 2003 17:22:12 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: References: Message-ID: <20030225222212.GH17602@cnri.reston.va.us> On Tue, Feb 25, 2003 at 10:50:34PM +0100, Just van Rossum wrote: > Jack Jansen wrote: > > Yes, you should be able to get this to work, but you will have to > > build the Python.framework yourself. I've been looking at creating > > the framework in such a way that it would allow just copying > > /Library/Frameworks/Python.framework > > into a private frameworks directory, but I haven't gotten it to work. > > (Or, in other words: if you *did* get this to work I would be very > > interested). > > > > If you could write a howto document for doing this that would be very > > helpful, I'd love to put such information on the MacPython website. > > My request would be simpler: write it down in simple steps so I can > automate it in bundlebuilder.py ;-) I've been distributing a package from a framework build. I might be doing something silly, but it works. I'm also using wxWindows, not Tkinter. Basically, I just use bundlebuilder.py, but with three minor changes: 0) Under MyApp.app/Contents/MacOS I create a directory 'lib' and copy any libraries needed(in my case, /usr/local/lib/libwx_mac-2.4*) 1) Under that new lib dir I also create a subdirectory /Python.framework/Versions/2.3 and copy /Library/Frameworks/Python.framework/Versions/2.3/Python to it. 2) I add the following lines to the start script generated by bundlebuilder: DYLD_LIBRARY_PATH=${execdir}/lib export DYLD_LIBRARY_PATH DYLD_FRAMEWORK_PATH=${execdir}/lib export DYLD_FRAMEWORK_PATH Seems to work fine, and be fully portable. The dmg I distribute is 9MB, vs. 6MB for my win32 pyexe version. Hope we're talking about the same thing here... Jason From macpython@lopan.dccs.upenn.edu Wed Feb 26 19:56:13 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Wed, 26 Feb 2003 14:56:13 -0500 Subject: [Pythonmac-SIG] sanity checks: building MacOS X app In-Reply-To: <8769269F-490E-11D7-B758-000A95686CD8@redivi.com> References: <20030225195252.GM658@isc.upenn.edu> <8769269F-490E-11D7-B758-000A95686CD8@redivi.com> Message-ID: <20030226195613.GI607@isc.upenn.edu> > >>Although, I highly recommend NOT using aquaTk. > > > >I'll bite: Why not? > > It's unstable (something of a late alpha quality) and ugly on OS X, you > should use PyObjC if possible, if not, try wxWindows (if the GUI has to > be cross-platform) or something.. tkinter is kind of old and convoluted > too. If it turns out that aquaTK is really that bad, we'll have to force MacOS X users to use Tkinter under X11 instead. In my testing, that's what I used and it seems just fine. At the time the GUI code was written, it was the only cross platform choice. I'm afraid we won't have time to switch. P.S. I still haven't had time to get everything packaged up yet, but hope to get to it soon. Then there's the windows version...blah. From owen@astro.washington.edu Thu Feb 27 18:00:24 2003 From: owen@astro.washington.edu (Russell E Owen) Date: Thu, 27 Feb 2003 10:00:24 -0800 Subject: [Pythonmac-SIG] aqua Tk Message-ID: > > >>Although, I highly recommend NOT using aquaTk. >> > >> >I'll bite: Why not? >> >> It's unstable (something of a late alpha quality) and ugly on OS X, you >> should use PyObjC if possible, if not, try wxWindows (if the GUI has to >> be cross-platform) or something.. tkinter is kind of old and convoluted > > too... I've personally found aqua Tk 8.4.1 (the current version last I checked) to be just fine. It has a few cosmetic bugs that I've reported (insertion cursor sometimes not shown in a right justified entry widget, lines on canvasses are off by one pixel relative to unix (which was also true in MacOS 9)), but my telescope GUI seems perfectly stable. I don't mean to dismiss your own experience -- my code may well not tickle he bugs you've seen. However, I would be interested in knowing of any serious bugs. And did you see them in 8.4.1 (aqua Tk 8.4 was definitely buggy)? -- Russell From brownr@ucalgary.ca Thu Feb 27 21:10:27 2003 From: brownr@ucalgary.ca (Robb Brown) Date: Thu, 27 Feb 2003 14:10:27 -0700 Subject: [Pythonmac-SIG] aqua Tk In-Reply-To: Message-ID: I'll second that. Tk is very limited (and ugly in some cases). For instance, someone needed a string grid widget the other day. Tk doesn't have it. Wx does, and wx is very nice (it even has RAD tools and such) but wx (at least as of before Christmas) was VERY unstable under Aqua. Plus things like VTK won't work. Hopefully these problems will be ironed out soon, or maybe they already are, but so far we've found Aqua Tk has been the most stable cross platform GUI toolkit for OS X. I'm holding my breath for wx though. On Thursday, February 27, 2003, at 11:00 AM, Russell E Owen wrote: > >> > >>Although, I highly recommend NOT using aquaTk. >>> > >>> >I'll bite: Why not? >>> >>> It's unstable (something of a late alpha quality) and ugly on OS X, >>> you >>> should use PyObjC if possible, if not, try wxWindows (if the GUI >>> has to >>> be cross-platform) or something.. tkinter is kind of old and >>> convoluted >> > too... > > I've personally found aqua Tk 8.4.1 (the current version last I > checked) to be just fine. It has a few cosmetic bugs that I've > reported (insertion cursor sometimes not shown in a right justified > entry widget, lines on canvasses are off by one pixel relative to unix > (which was also true in MacOS 9)), but my telescope GUI seems > perfectly stable. > > I don't mean to dismiss your own experience -- my code may well not > tickle he bugs you've seen. However, I would be interested in knowing > of any serious bugs. And did you see them in 8.4.1 (aqua Tk 8.4 was > definitely buggy)? > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From borgempath@Phreaker.net Fri Feb 28 06:12:46 2003 From: borgempath@Phreaker.net (Joel Rodrigues) Date: Fri, 28 Feb 2003 11:42:46 +0530 Subject: [Pythonmac-SIG] error running test.py in 4Suite-0.12.0a3 Message-ID: Hi, Got another for you. I'm getting a weird error running test.py in 4Suite-0.12.0a3 [localhost:Ft/Share/Tests] mark% python test.py --help Traceback (most recent call last): File "test.py", line 9, in ? packages=['Lib', File "/usr/local/lib/python2.2/site- packages/Ft/Lib/TestSuite/__init__.py", line 45, in Test import TestSuite, Errors File "/usr/local/lib/python2.2/site- packages/Ft/Lib/TestSuite/TestSuite.py", line 16, in ? import TestModule, Tester File "/usr/local/lib/python2.2/site- packages/Ft/Lib/TestSuite/Tester.py", line 40, in ? curses.setupterm() _curses.error: setupterm: could not find terminal And are the demos in Python-2.2.2/Demo/curses supposed to work on Mac OS X v10.1.5, Python 2.2.2 ? This may the source of my problems : ncurses-5.2X.pkg, package built by Chris Roberts. I don't know where I got it. ANyone have a tip on an ncurses to download and for OS X ? - Joel From Jack.Jansen@cwi.nl Fri Feb 28 09:59:00 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 28 Feb 2003 10:59:00 +0100 Subject: [Pythonmac-SIG] error running test.py in 4Suite-0.12.0a3 In-Reply-To: Message-ID: <42C89F17-4B03-11D7-9908-0030655234CE@cwi.nl> On Friday, Feb 28, 2003, at 07:12 Europe/Amsterdam, Joel Rodrigues wrote: > This may the source of my problems : > ncurses-5.2X.pkg, package built by Chris Roberts. I don't know where I > got it. ANyone have a tip on an ncurses to download and for OS X ? There's a good chance you run into errors with curses on MacOSX 10.1. 10.1 ships with an ancient curses, which isn't good enough for the Python curses module, so it is manually disabled. However, the curses implementation lives in libc, and because Python on 10.1 lives with a flat namespace for all globals even installing ncurses yourself and linking the curses module against that isn't guaranteed to work: if another extension module that was loaded earlier somehow refers to the old curses in libc your ncurses module will pick up that symbol and you're going to be hosed. All in all it's a pretty messy situation. All this has been fixed for 10.2, where ncurses is included, it doesn't live in libc anymore and we have two-level namespaces. Each of these alone would have fixed the problem:-) If you do want to try and continue with ncurses on 10.1: I had some success with the fink ncurses at the time. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Fri Feb 28 14:42:14 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 28 Feb 2003 15:42:14 +0100 Subject: [Pythonmac-SIG] MacPython 2.3a2 on OSX 10.1 In-Reply-To: Message-ID: Pascal, John (and others), I think I've found the problem with running applets on 10.1. It seems that the new trick that Just invented, having the applet main program being a python (or shell) bootstrap script with a #! line, and using that script to fire up the real Python script, doesn't work under 10.1. I've tried a couple of #! scripts in .app bundles on 10.1, but they invariably give me an "Error -2857" on the console. So I guess this means that having a script as the main program in a .app bundle doesn't work under 10.1:-( I'm not sure how to proceed. We could scrap 10.1 support for MacPython, but that doesn't seem like a nice option. We could scrap Just's applet mods, but that I'm also not too excited about, the bundlebuilder stuff is a lot nicer than the buildtools hacks I used previously to create OSX applets. Moreover, bundlebuilder is also used for the PyObjC/applet-python-2.2 combo, and it's good to have only one way of doing things. We could replace the #! script by a true executable, but this would mean we'd have to store the boilerplate for that executable somewhere, and one of the nice things about the bundlebuilder solution is that it doesn't need any applet template anymore. Also, a true executable would still have to find out which script to run (although that could be coded in the .plist file, probably). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From just@letterror.com Fri Feb 28 15:13:10 2003 From: just@letterror.com (Just van Rossum) Date: Fri, 28 Feb 2003 16:13:10 +0100 Subject: [Pythonmac-SIG] Re: MacPython 2.3a2 on OSX 10.1 In-Reply-To: Message-ID: Jack Jansen wrote: > I'm not sure how to proceed. We could scrap 10.1 support for > MacPython, but that doesn't seem like a nice option. Why not? Unless there's dedicated group of volunteers that test and fix things (which there isn't, as far as I can see) I really don't see the point of even _trying_ to remain compatible with 10.1. I personally don't have the time for it, and I doubt that you do. Python is a volunteers effort (even more so for the Mac) and if we can't get the volunteers to do it, that's just tough luck. We have enough troubles with applets on 10.2... Just From berkowit@silcom.com Fri Feb 28 15:30:27 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Fri, 28 Feb 2003 07:30:27 -0800 Subject: [Pythonmac-SIG] Re: MacPython 2.3a2 on OSX 10.1 In-Reply-To: Message-ID: On 2/28/03 7:13 AM, "Just van Rossum" wrote: > Jack Jansen wrote: > >> I'm not sure how to proceed. We could scrap 10.1 support for >> MacPython, but that doesn't seem like a nice option. > > Why not? Unless there's dedicated group of volunteers that test and fix > things (which there isn't, as far as I can see) I really don't see the > point of even _trying_ to remain compatible with 10.1. I personally > don't have the time for it, and I doubt that you do. Python is a > volunteers effort (even more so for the Mac) and if we can't get the > volunteers to do it, that's just tough luck. We have enough troubles > with applets on 10.2... I think that the fact that OS 10.1 does not come with Python built in, and 10.2 does, should be the determinant here. There's really no point in going to a huge amount of trouble to be compatible for an OS where ordinary users have to do their own Python installation, IMO. I know that almost all of you here have been using just such installations, because you had to, for years. But now that Apple's OS ships with Python, I would have thought that 100% of the effort should be devoted to that OS, and to getting new versions of Python ready to be incorporated in each new major OS version that ships (e.g. OS 10.3). Just my opinion, of course: there may be factors I know nothing about which play a part. -- Paul Berkowitz From jpe@wingide.com Fri Feb 28 15:35:03 2003 From: jpe@wingide.com (John Ehresman) Date: 28 Feb 2003 10:35:03 -0500 Subject: [Pythonmac-SIG] Re: MacPython 2.3a2 on OSX 10.1 In-Reply-To: References: Message-ID: <1046446506.1551.14.camel@sparrow> On Fri, 2003-02-28 at 09:42, Jack Jansen wrote: > I'm not sure how to proceed. We could scrap 10.1 support for MacPython, > but that doesn't seem like a nice option. We could scrap Just's applet > mods, but that I'm also not too excited about, the bundlebuilder stuff > is a lot nicer than the buildtools hacks I used previously to create > OSX applets. It would be nice to support 10.1, particularly since 10.2 is not a free upgrade and some people never upgrade the OS after they buy their computer. I wonder if the applets would work with a simple C program that ran argv[0].py. If someone can point me to an applet example, I'd be willing to try this out. John From just@letterror.com Fri Feb 28 15:48:58 2003 From: just@letterror.com (Just van Rossum) Date: Fri, 28 Feb 2003 16:48:58 +0100 Subject: [Pythonmac-SIG] Re: MacPython 2.3a2 on OSX 10.1 In-Reply-To: <1046446506.1551.14.camel@sparrow> Message-ID: John Ehresman wrote: > It would be nice to support 10.1, particularly since 10.2 is not a > free upgrade and some people never upgrade the OS after they buy > their computer. If we were talking about a commercial application, then yes, it's a sensible thing to do. So indeed it may make more sense to you than to me and Jack... > I wonder if the applets would work with a simple C > program that ran argv[0].py. Should be possible, using execve(). Bill Bumgarner has written a small ObjC program that does this, although it does a bit much to my taste: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/pyobjc/pyobjc/ Project%20Templates/Cocoa-Python%20Application/bin-python-main.m?rev=1.7 I'm not sure this program has ever been tested on 10.1 but it "should work". Or you can translate the Python bootstrap snippet to C: BOOTSTRAP_SCRIPT = """\ #!%(hashbang)s import sys, os execdir = os.path.dirname(sys.argv[0]) executable = os.path.join(execdir, "%(executable)s") resdir = os.path.join(os.path.dirname(execdir), "Resources") mainprogram = os.path.join(resdir, "%(mainprogram)s") sys.argv.insert(1, mainprogram) os.environ["PYTHONPATH"] = resdir os.environ["PYTHONEXECUTABLE"] = executable os.execve(executable, sys.argv, os.environ) """ Note that it's parametrized (sp?), which would be a little harder to do with a C program... > If someone can point me to an applet > example, I'd be willing to try this out. Check out bundlebuilder.py; with it you can build an applet from anything. Or BuildApplet.py, which uses buildtools.py which uses bundlebuilder.py. Just From kevino@tulane.edu Fri Feb 28 15:48:54 2003 From: kevino@tulane.edu (Kevin Ollivier) Date: Fri, 28 Feb 2003 07:48:54 -0800 Subject: [Pythonmac-SIG] MacPython 2.3a2 on OSX 10.1 References: Message-ID: <02fa01c2df40$e6b381a0$6701a8c0@dellPC> ----- Original Message ----- From: "Jack Jansen" To: "Pascal Oberndoerfer" ; "John Ehresman" ; "Just Rossum, van" Cc: Sent: Friday, February 28, 2003 6:42 AM Subject: [Pythonmac-SIG] MacPython 2.3a2 on OSX 10.1 > Pascal, John (and others), > I think I've found the problem with running applets on 10.1. It seems > that the new trick that Just invented, having the applet main program > being a python (or shell) bootstrap script with a #! line, and using > that script to fire up the real Python script, doesn't work under 10.1. > > I've tried a couple of #! scripts in .app bundles on 10.1, but they > invariably give me an "Error -2857" on the console. > So I guess this means that having a script as the main program in a > .app bundle doesn't work under 10.1:-( Just a thought that crossed my mind - would an Applescript work? =) (I thought Applescript for 10.1 supported sending commands to the shell.) Thanks, Kevin > I'm not sure how to proceed. We could scrap 10.1 support for MacPython, > but that doesn't seem like a nice option. We could scrap Just's applet > mods, but that I'm also not too excited about, the bundlebuilder stuff > is a lot nicer than the buildtools hacks I used previously to create > OSX applets. Moreover, bundlebuilder is also used for the > PyObjC/applet-python-2.2 combo, and it's good to have only one way of > doing things. We could replace the #! script by a true executable, but > this would mean we'd have to store the boilerplate for that executable > somewhere, and one of the nice things about the bundlebuilder solution > is that it doesn't need any applet template anymore. Also, a true > executable would still have to find out which script to run (although > that could be coded in the .plist file, probably). > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From matsakis@mit.edu Fri Feb 28 16:21:00 2003 From: matsakis@mit.edu (Nick Matsakis) Date: Fri, 28 Feb 2003 11:21:00 -0500 (EST) Subject: [Pythonmac-SIG] State of Python on the Mac Message-ID: I've been following this list for the last month or so, and I must admit that as a long time Mac user and a new python programmer, I am still very confused about the state of Python on Mac OS X. I appreciate that a lot of work is going on to build a stable platform for the future, but the documentation is hopelessly out of date. Though the footer says "updated October 14, 2002", the documents at http://www.python.org/doc/current/mac/mac.html say "At the time of this writing Mac OS X had just been released as a Public Beta." Which makes me wonder if I can trust the rest of it at all. however, It doesn't seem like detailed documentation should be a priority now, since there is a lot of good Python documentation out there, and the documentation for Carbon, Cocoa, and other Mac OS X technologies is good and growing. Even Applescript is starting to get there, with the release of the O'Reilly book. Many programmers will be able to take that body of documentation and fill in the blanks. Instead, what I really want is a 1-2 page "state of Python on the Mac" written for a forward-looking programmer who is interested in using Python to script Mac OS X or write Carbon or Cocoa applications. The things it should provide are: 1. A bird's eye view of the APIs. The module list at http://www.python.org/doc/current/ is alphabetized, and thus random. I can make some reasonable intferences, but I really have no idea what modules "go together". If all goes well, a future Mac-python programmer will like have sets of modules that correspond roughly to "Cocoa" (pyobjc), "Carbon" (MacPython), "Applescript/OSA" (MacPython), and "standard python OS abstractions" (os, sys). Which modules belong where, which work well together, and which, if any, are deprecated? 2. A small description of the available and future python runtimes, and what to expect in the future. Apple included Python with 10.2. Why? Because it was in BSD 4.4? Because people asked for it? Has Apple made an official statement about its position on Python, or what versions of Python will be included with future versions of Mac OS X? (frameworks?) These are all important questions for the programmer who is trying to decide whether Python is appropriate for a given project. 3. A small description of the state of using Python as an OSA script. This is actually where _my_ primary interest lies. My impression of OSA is that it is supposed to allow different languages to be used to send and handle Apple Events. I hope that one day I would be able to install a simple component into the system and that suddenly I would be able to use Python as a full peer to Applescript; that is, anywhere that Applescript is used by applications and the system I could plug in Python. (My other impression is that the support may not yet be there from Apple, but that they are working on it, is this true?). 4. A solid answer to the question, "How can I help?" It's clear that documentation and other work is needed. Is the time appropriate to do that? How can documentation efforts be coordinated? I suppose this could be organized into a FAQ-style series of questions and answer, but I think it would be better as well-organized summary of the state of Python on the Mac. Regards, Nick Matsakis From matsakis@mit.edu Fri Feb 28 16:29:14 2003 From: matsakis@mit.edu (Nick Matsakis) Date: Fri, 28 Feb 2003 11:29:14 -0500 (EST) Subject: [Pythonmac-SIG] Re: MacPython 2.3a2 on OSX 10.1 In-Reply-To: <1046446506.1551.14.camel@sparrow> References: <1046446506.1551.14.camel@sparrow> Message-ID: On Fri, 28 Feb 2003, John Ehresman wrote: > It would be nice to support 10.1, particularly since 10.2 is not a free > upgrade and some people never upgrade the OS after they buy their > computer. Some Macs shipped with 10.0. I don't see that as a reason to support it. Mac OS X has developed a lot, but I think it is clear that much has firmed up in 10.2. While I find it very annoying that Apple both charged full price and provided no 10.1 -> 10.2 upgrade path, I think that the installed base will move from 10.1 in short order. So many of Apple's new programs are 10.2 only: Safari, Keynote, X11, etc. and this seems to be the case with a lot of third-party software. I think it will be hard to for many people to stay on 10.1 when 10.2 offers so much. Nick Matsakis From jpe@wingide.com Fri Feb 28 16:44:17 2003 From: jpe@wingide.com (John Ehresman) Date: 28 Feb 2003 11:44:17 -0500 Subject: [Pythonmac-SIG] Re: MacPython 2.3a2 on OSX 10.1 In-Reply-To: References: Message-ID: <1046450657.1664.48.camel@sparrow> On Fri, 2003-02-28 at 10:48, Just van Rossum wrote: > John Ehresman wrote: > > > It would be nice to support 10.1, particularly since 10.2 is not a > > free upgrade and some people never upgrade the OS after they buy > > their computer. > > If we were talking about a commercial application, then yes, it's a > sensible thing to do. So indeed it may make more sense to you than to me > and Jack... The approach may be to not break things that work on 10.1 and accept patches for 10.1, but mark new features / modules as 10.2. Maybe it would be a good thing if most everyone updates to 10.1; my experience is in the win32 world, where many people are still running win98 and some are on win95. I'll take a look at the launch script / program later; is the problem that the first executable run can't be a script or that any executable run can't be a script? Would it be acceptable to create a symbolic link from the main script in Resources to a filename in the bin directory? John From berkowit@silcom.com Fri Feb 28 16:52:50 2003 From: berkowit@silcom.com (Paul Berkowitz) Date: Fri, 28 Feb 2003 08:52:50 -0800 Subject: [Pythonmac-SIG] MacPython 2.3a2 on OSX 10.1 In-Reply-To: <02fa01c2df40$e6b381a0$6701a8c0@dellPC> Message-ID: On 2/28/03 7:48 AM, "Kevin Ollivier" wrote: >> I've tried a couple of #! scripts in .app bundles on 10.1, but they >> invariably give me an "Error -2857" on the console. >> So I guess this means that having a script as the main program in a >> .app bundle doesn't work under 10.1:-( > > Just a thought that crossed my mind - would an Applescript work? =) (I > thought Applescript for 10.1 supported sending commands to the shell.) Yes, it does. 'do shell script "whatever"'. I can't recall if 'quoted form of POSIX path' came in with OS 10.2 (AS 1.9) or earlier. I think it was AS 1.8.3, which is a free update to OS 10.1.5, but will work with all versions of 10.1.x. Maybe even AS 1.8.1, which shipped with OS 10.1.2. OS 10.1.0 shipped with AS 1.7, which is not a good version of AS, although I think it had 'do shell script' already. Best would be to require AS 1.8.3 and do all testing in OS 10.1 with that, but you could even go back to 10.1.0 and just not use 'quoted form' but always include all the "\"" or ' quotes yourself. -- Paul Berkowitz From macpython@lopan.dccs.upenn.edu Fri Feb 28 18:24:39 2003 From: macpython@lopan.dccs.upenn.edu (John Speno) Date: Fri, 28 Feb 2003 13:24:39 -0500 Subject: [Pythonmac-SIG] Tkinter and the Help menu Message-ID: <20030228182439.GI1992@isc.upenn.edu> Platform: MacOS X 10.2.4, Python 2.3a2, Tcl and Tk 8.4.1 jaguar. Issue: In my application's Help menu, the first item is an extraneous 'x' which I didn't put there, and can't seem to get rid of. Actually, when I first switch to the application, each item in my Help menu is an 'x'. If I switch to another app then back, my menu items have their names back, and there's still the first mysterious 'x'. Anyone encounter that before? I suppose I can try the TOT build of Tcl/Tk... Thanks! #!/usr/local/bin/pythonw import Tkinter def hello(): print "hello" root = Tkinter.Tk() root.title('menubar test') menubar = Tkinter.Menu(root) helpmenu = Tkinter.Menu(menubar, name='help', tearoff=0) menubar.add_cascade(label="Help", menu=helpmenu, underline=0) addhelp = helpmenu.add_command addhelp(label='Window Help', underline=0, command=hello, state='normal') addhelp(label='Menu Help', underline=9, command=hello, state='normal') helpmenu.add_separator() addhelp(label='About Assignments', underline=0, command=hello) root.configure(menu=menubar) root.mainloop() From wildpixel@mac.com Fri Feb 28 19:21:29 2003 From: wildpixel@mac.com (Daniel Lord) Date: Fri, 28 Feb 2003 11:21:29 -0800 Subject: [Pythonmac-SIG] MacPython 2.3a2 on OSX 10.1 In-Reply-To: <20030228170001.12949.83978.Mailman@mail.python.org> Message-ID: --Apple-Mail-2--566587316 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I can verify that one can use and Applescript in an App bundle to call a python script in it. I created an Applescript Studio GUI as a wrapper for a recursive file renaming and moving Python script and it works very well. You find the path to the script in the bundle and call it as follows: (* Find path to python script *) set POSIXBasePath to POSIX path of (path to me) set scriptPath to (POSIXBasePath & scriptName) set theResult to do shell script ("/usr/local/bin/python " & "'" & scriptPath & "' " & cmdStr & fileArg) as string -- where cmdStr is your options and fileArg contains the command-line args -- this is how I call it, there are other ways Daniel Lord > From: Paul Berkowitz > Date: Fri Feb 28, 2003 08:52:50 US/Pacific > To: PythonMac > Subject: Re: [Pythonmac-SIG] MacPython 2.3a2 on OSX 10.1 > > > On 2/28/03 7:48 AM, "Kevin Ollivier" wrote: > >>> I've tried a couple of #! scripts in .app bundles on 10.1, but they >>> invariably give me an "Error -2857" on the console. >>> So I guess this means that having a script as the main program in a >>> .app bundle doesn't work under 10.1:-( >> >> Just a thought that crossed my mind - would an Applescript work? =) (I >> thought Applescript for 10.1 supported sending commands to the shell.) > > Yes, it does. 'do shell script "whatever"'. > > I can't recall if 'quoted form of POSIX path' came in with OS 10.2 (AS > 1.9) > or earlier. I think it was AS 1.8.3, which is a free update to OS > 10.1.5, > but will work with all versions of 10.1.x. Maybe even AS 1.8.1, which > shipped with OS 10.1.2. OS 10.1.0 shipped with AS 1.7, which is not a > good > version of AS, although I think it had 'do shell script' already. Best > would > be to require AS 1.8.3 and do all testing in OS 10.1 with that, but you > could even go back to 10.1.0 and just not use 'quoted form' but always > include all the "\"" or ' quotes yourself. > > -- > Paul Berkowitz > > > > > > > --Apple-Mail-2--566587316 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I can verify that one can use and Applescript in an App bundle to call a python script in it. I created an Applescript Studio GUI as a wrapper for a recursive file renaming and moving Python script and it works very well. You find the path to the script in the bundle and call it as follows: Geneva (*3333,3333,3333 Find path to python script *) DDDD,0000,0000set 4040,8080,0000POSIXBasePath DDDD,0000,0000to 0000,0000,FFFFPOSIX path DDDD,0000,0000of (0000,0000,FFFFpath to DDDD,0000,0000me) DDDD,0000,0000set 4040,8080,0000scriptPath DDDD,0000,0000to (4040,8080,0000POSIXBasePath & 4040,8080,0000scriptName) DDDD,0000,0000set 4040,8080,0000theResult DDDD,0000,0000to 0000,0000,FFFFdo shell script ("/usr/local/bin/python " & "'" & 403F,807F,0000scriptPath & "' " & 4040,8080,0000cmdStr & 4040,8080,0000fileArg) DDDD,0000,0000as 0000,0000,FFFFstring -- where cmdStr is your options and fileArg contains the command-line args -- this is how I call it, there are other ways Daniel Lord From: Paul Berkowitz < Date: Fri Feb 28, 2003 08:52:50 US/Pacific To: PythonMac < Subject: Re: [Pythonmac-SIG] MacPython 2.3a2 on OSX 10.1 On 2/28/03 7:48 AM, "Kevin Ollivier" < wrote: I've tried a couple of #! scripts in .app bundles on 10.1, but they invariably give me an "Error -2857" on the console. So I guess this means that having a script as the main program in a .app bundle doesn't work under 10.1:-( Just a thought that crossed my mind - would an Applescript work? =) (I thought Applescript for 10.1 supported sending commands to the shell.) Yes, it does. 'do shell script "whatever"'. I can't recall if 'quoted form of POSIX path' came in with OS 10.2 (AS 1.9) or earlier. I think it was AS 1.8.3, which is a free update to OS 10.1.5, but will work with all versions of 10.1.x. Maybe even AS 1.8.1, which shipped with OS 10.1.2. OS 10.1.0 shipped with AS 1.7, which is not a good version of AS, although I think it had 'do shell script' already. Best would be to require AS 1.8.3 and do all testing in OS 10.1 with that, but you could even go back to 10.1.0 and just not use 'quoted form' but always include all the "\"" or ' quotes yourself. -- Paul Berkowitz --Apple-Mail-2--566587316-- From Jack.Jansen@oratrix.com Fri Feb 28 23:44:39 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat, 1 Mar 2003 00:44:39 +0100 Subject: [Pythonmac-SIG] State of Python on the Mac In-Reply-To: Message-ID: <9A06500C-4B76-11D7-9BD7-000A27B19B96@oratrix.com> Nick (and everyone), documentation is what is topmost on my priority list from now until the release of 2.3 final. Or actually I should broaden that a bit: documentation plus a couple of well-chosen examples plus packaging and ease of installation and use. I could definitely use help with this! I'll comment on some of the points you make: > I appreciate that a lot of work is going on to build a stable platform > for > the future, but the documentation is hopelessly out of date. Though > the > footer says "updated October 14, 2002", the documents at > http://www.python.org/doc/current/mac/mac.html say "At the time of this > writing Mac OS X had just been released as a Public Beta." Which makes > me > wonder if I can trust the rest of it at all. If people want to read the "in development" part of the documentation: please do so and let me know the problems. A lot of the stuff is still centered around MacOS9, but at least it should now clearly be flagged as such. > Instead, what I really want is a 1-2 page "state of Python on the Mac" > written for a forward-looking programmer who is interested in using > Python > to script Mac OS X or write Carbon or Cocoa applications. The things it > should provide are: Good idea! Let's muse on this some more: > > 1. A bird's eye view of the APIs. The module list at > http://www.python.org/doc/current/ is alphabetized, and thus random. I > can make some reasonable intferences, but I really have no idea what > modules "go together". If all goes well, a future Mac-python > programmer > will like have sets of modules that correspond roughly to "Cocoa" > (pyobjc), "Carbon" (MacPython), "Applescript/OSA" (MacPython), and > "standard python OS abstractions" (os, sys). Which modules belong > where, > which work well together, and which, if any, are deprecated? Is this the way it should be structured, or would a problem-oriented approach be better? I.e. "learning programming", "web services", "system tools", "scientific programming", etc. Some areas that aren't really domain-related probably deserve a section too (GUI programming springs to mind). > 2. A small description of the available and future python runtimes, and > what to expect in the future. Apple included Python with 10.2. Why? > Because it was in BSD 4.4? Because people asked for it? Has Apple > made an > official statement about its position on Python, or what versions of > Python will be included with future versions of Mac OS X? > (frameworks?) > These are all important questions for the programmer who is trying to > decide whether Python is appropriate for a given project. Good question, and one I haven't found the answer to. I know that some people here might have some insight in this, if they don't feel like answering in public please let me know in private (if it's okay to forward this info anonymized). I did bug Jordan Hubbard about MacPython at a dinner about a year and a half ago, maybe that influenced it:-) > 3. A small description of the state of using Python as an OSA script. > This is actually where _my_ primary interest lies. My impression of > OSA is > that it is supposed to allow different languages to be used to send and > handle Apple Events. I hope that one day I would be able to install a > simple component into the system and that suddenly I would be able to > use > Python as a full peer to Applescript; that is, anywhere that > Applescript > is used by applications and the system I could plug in Python. (My > other > impression is that the support may not yet be there from Apple, but > that > they are working on it, is this true?). Bill Fancher was working on this, but at the moment he is unable to pursue it. I'll try and contact him again. > > 4. A solid answer to the question, "How can I help?" It's clear that > documentation and other work is needed. Is the time appropriate to do > that? How can documentation efforts be coordinated? Primarily reading, and pointing out problems. If people want to go further: context diffs with the documentation LaTex sources are of course always much better than plain old comments, but even the plain old comments are very valuable! [Actually: with fink it is reasonably easy to setup the tools you need to build the documentation from source. It used to be pure hell, but nowadays I think that if you install the latex stuff first there's only one bit missing, and its pretty clear what that is (and its also under fink)] -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -