From M.Laloux at mrw.wallonie.be Mon Mar 1 04:29:17 2004 From: M.Laloux at mrw.wallonie.be (LALOUX Martin) Date: Mon Mar 1 04:31:20 2004 Subject: [Pythonmac-SIG] python ide problem Message-ID: <6.0.2.0.0.20040301101754.02c283e0@pop.promibra.intra.mrw.wallonie.be> Sorry for the delay, but I was on holidays. I applied Jack Jansen's suggestion (removing ~/Library/Preferences/Python/Python IDE Preferences) before reading its post and everything is OK. I had used as scripts folder that where I keep the originals of all the modules that I have installed, without paying attention. Thank you very much Martin Laloux From gherman at darwin.in-berlin.de Mon Mar 1 06:38:51 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Mon Mar 1 06:34:10 2004 Subject: [Pythonmac-SIG] O'Reilly article, iPhoto scripting, Python? Message-ID: <02EA37F2-6B75-11D8-A39D-00039345C610@darwin.in-berlin.de> Hi, I just found this article about scripting iPhoto on the net which gives examples in AppleScript and some other P-language, so I wonder if this kind of stuff can be done nowadays in Python, too? http://www.macdevcenter.com/lpt/a/4653 Thanks, Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The best way to predict the future is to invent it." (Alan Kay) From Jack.Jansen at cwi.nl Mon Mar 1 06:56:13 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Mar 1 06:56:12 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> Message-ID: <70027D1A-6B77-11D8-8AB9-000D934FF6B4@cwi.nl> On 29 Feb 2004, at 15:34, Bob Ippolito wrote: >> Given the size and success of PyPi, might it make more sense now to >> throw in with that than maintain a separate, and comparatively little >> supported, system? > > Distutils doesn't directly support binary distribution, and thus > requires yet another complex set of dependencies: properly configured > compiler(s), and potentially C libraries. Not to mention the fact > that it doesn't support dependencies at all to begin with, even > between Python things. Also, anything distutils/PyPI based would > probably be the burden of package authors/maintainers, not of platform > gurus, so it's much less likely to actually work properly (at least on > our platform). To add to that: PackMan solves a different problem than PyPi and distutils. Actually, the three are somewhat orthogonal. PyPi allows you to locate (potentially) any package ever developed for Python. Distutils allows you to install any package from source on any platform (provided the package maintainer didn't put too much platform-specific junk in the setup file). PackMan allows you to install a relatively small number of tested-and-tried packages specifically for your combination of hardware platform/software platform/python installation, in either source or binary form. The alternative definition of what PackMan does it that it allows me to have my cake and eat it: MacPython-OS9 distributions were "battery included" distributions with goodies like Numeric and PIL thrown in. PackMan allows me to distribute MacPython-OSX without batteries, while still giving having almost the same convenience to end users. > I would also imagine that it was also done this way because Jack could > sneak it by and nobody would try and bog him down with a massively > cross-platform metadata heavy PEP-backed implementation. Actually the PEP is still going to come, I promise. PackMan still has version numbers below 1.0 because I view it as a strawman for this PEP. -- 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 philippe at wwphi.net Mon Mar 1 09:05:54 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Mon Mar 1 09:06:02 2004 Subject: [Pythonmac-SIG] Problem with _tkInter 2.3? Message-ID: <8E4B8AB0-6B89-11D8-97FF-003065D64D74@wwphi.net> Hello, I have just installed tcltk Aqua 4.8.5 from http://www.maths.mq.edu.au/~steffen/tcltk/TclTkAqua/8.4.5.html and _tkInter 2.3 using the Package Manager. When I run the hello.py example in the Extras/tkinter/guido directory, a Hello World Window appears correctly, but when I click it, it won't come forward and I get the following message: "SetFrontProcess failed,-606" in Terminal. The problem does not seem to come from tcltk Aqua since tcl/tk programs run correctly on the command line and come forward correctly when clicked on. Any help with this matter would be much appreciated. Best regards, PR From oussoren at cistron.nl Mon Mar 1 09:16:22 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Mon Mar 1 09:16:22 2004 Subject: [Pythonmac-SIG] Problem with _tkInter 2.3? In-Reply-To: <8E4B8AB0-6B89-11D8-97FF-003065D64D74@wwphi.net> References: <8E4B8AB0-6B89-11D8-97FF-003065D64D74@wwphi.net> Message-ID: <046CC9EA-6B8B-11D8-AF9F-0003931CFE24@cistron.nl> On 1-mrt-04, at 15:05, Philippe de Rochambeau wrote: > Hello, > > I have just installed tcltk Aqua 4.8.5 from > http://www.maths.mq.edu.au/~steffen/tcltk/TclTkAqua/8.4.5.html and > _tkInter 2.3 using the Package Manager. > > When I run the hello.py example in the Extras/tkinter/guido directory, > a Hello World Window appears correctly, but when I click it, it won't > come forward and I get the following message: > "SetFrontProcess failed,-606" in Terminal. > > The problem does not seem to come from tcltk Aqua since tcl/tk > programs run correctly on the command line and come forward correctly > when clicked on. > > Any help with this matter would be much appreciated. The short answer is that you should use pythonw to start python scripts with a GUI. On OSX command-line tools are not suppossed to have a GUI, and GUI toolkits don't work unless your application is inside an application bundle. pythonw sets up the right environment before starting a regular python interpreter. Ronald From philippe at wwphi.net Mon Mar 1 09:26:04 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Mon Mar 1 09:26:16 2004 Subject: [Pythonmac-SIG] Blender on OSX Message-ID: <5F40161E-6B8C-11D8-97FF-003065D64D74@wwphi.net> Has anyone ever programmed Blender games in Python on Macosx? How does Python perform in game situations? Cheers, PR From buhrt at iquest.net Mon Mar 1 12:45:04 2004 From: buhrt at iquest.net (buhrt@iquest.net) Date: Mon Mar 1 13:02:54 2004 Subject: [Pythonmac-SIG] Re: Your music Message-ID: Your file is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: mp3music.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040301/4deb245d/mp3music.obj From 010385 at mx9.smf.ebay.com Mon Mar 1 12:45:05 2004 From: 010385 at mx9.smf.ebay.com (010385@mx9.smf.ebay.com) Date: Mon Mar 1 13:48:32 2004 Subject: [Pythonmac-SIG] Re: Re: Thanks! Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: document.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040301/b791578d/document-0001.obj From altis at semi-retired.com Mon Mar 1 15:06:25 2004 From: altis at semi-retired.com (Kevin Altis) Date: Mon Mar 1 15:11:23 2004 Subject: [Pythonmac-SIG] anyone planning to attend WWDC? Message-ID: I've been trying to think of places that we can reach out to Apple developers that aren't already using Python. WWDC is an obvious spot. WWDC might be a good opportunity for shmoozing with Apple employees, Cocoa developers and doing some Python demos and such outside the normal schedule. Is anyone planning to attend? WWDC is Apple?s Worldwide Developers Conference WWDC 2004 will be held June 28-July 2, in San Francisco, California I went ahead and made a wiki page. http://www.python.org/cgi-bin/moinmoin/WWDC2004 If there are some people that plan to attend, maybe we could make a list on the wiki page and coordinate from there. The O'Reilly Mac OS X conference this fall is an even better opportunity since we can get Python tutorials and presentations on the schedule if people submit good proposals. I'll make sure to forward an announcement once O'Reilly starts accepting proposals. ka From hengist.podd at virgin.net Mon Mar 1 15:17:08 2004 From: hengist.podd at virgin.net (has) Date: Mon Mar 1 15:22:52 2004 Subject: [Pythonmac-SIG] O'Reilly article, iPhoto scripting, Python? Message-ID: Dinu Gherman wrote: >I just found this article about scripting iPhoto on the net which >gives examples in AppleScript and some other P-language, so I wonder >if this kind of stuff can be done nowadays in Python, too? Yes. Appscript isn't quite finished yet, but it's getting close. Here's the equivalent deletion script [1]: from appscript import * app('iPhoto.app').photo_library_album.photos.test( (its.width < 200) .OR (its.height < 200) ).remove() There's some sample scripts on my site and bundled with appscript itself, and I'll release more as I write them. HTH has [1] Brian's original Perl script makes the classic faux-pas of laboriously iterating where a filter reference would do. See past posts from me regarding application object references, pointing out that they're actually queries and not conventional OO object references as many folks assume. -- http://freespace.virgin.net/hamish.sanderson/ From philippe at wwphi.net Mon Mar 1 15:44:42 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Mon Mar 1 16:03:15 2004 Subject: [Pythonmac-SIG] Newbie: Writing to two files Message-ID: <445850C9-6BC1-11D8-AC32-003065D64D74@wwphi.net> Hello, how can you simultaneously write to two different files in Python; i.e., duplicate a file handle? Many thanks. Best regards, PR From bob at redivi.com Mon Mar 1 16:21:21 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 1 16:26:36 2004 Subject: [Pythonmac-SIG] Newbie: Writing to two files In-Reply-To: <445850C9-6BC1-11D8-AC32-003065D64D74@wwphi.net> References: <445850C9-6BC1-11D8-AC32-003065D64D74@wwphi.net> Message-ID: <63031F1C-6BC6-11D8-93F5-000A95686CD8@redivi.com> On Mar 1, 2004, at 3:44 PM, Philippe de Rochambeau wrote: > how can you simultaneously write to two different files in Python; > i.e., duplicate a file handle? Could you be a little more clear as to what precisely you are trying to do? The information you've given so far is kind of ambiguous (for example, duplicating a file handle doesn't really have anything to do with separate files), so I don't really know how to answer the question. Also, you'll get much better advice if you state what you are trying to do, rather than your current approach; there's usually a simple obvious (given appropriate experience and Dutch heritage) way of doing almost anything in Python. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040301/38ccb8ec/smime.bin From mommysanner at aol.com Mon Mar 1 19:57:04 2004 From: mommysanner at aol.com (mommysanner@aol.com) Date: Mon Mar 1 19:57:38 2004 Subject: [Pythonmac-SIG] illegal... Message-ID: -------------- next part -------------- A non-text attachment was scrubbed... Name: jokes.zip Type: application/x-zip-compressed Size: 25477 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040301/453c01d8/jokes-0001.bin From jeffm at cruzio.com Mon Mar 1 20:51:19 2004 From: jeffm at cruzio.com (jeffm@cruzio.com) Date: Mon Mar 1 20:51:16 2004 Subject: [Pythonmac-SIG] Building pythonw OSX app Message-ID: Hi, I've developed a Mac program with MacPython 2.3 and Pygame on OS 10.3. It runs from the command line fine, but how should I turn it into a stand-alone OSX application? Thanks, Jeff P.S. * I tried "Save as Applet..." from the IDE and BuildApplet. These don't work, possibly because my program requires "pythonw" rather than "python"? * I tried running MacPython-2.3/Extras/Tools/freeze/freeze.py, but it gives an error: Error: needed directory /System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 not found And it's true that there is no "include" directory inside the 2.3 directory. It gives the same error if I try to build the sample hello.py, but the help-recommended solution (do "make install") doesn't seem to make sense in any main python directories I can find. * I've also seen questions on the web about BuildApplication and bundlebuilder, but I haven't found these programs. From bob at redivi.com Mon Mar 1 21:08:53 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 1 21:05:33 2004 Subject: [Pythonmac-SIG] Building pythonw OSX app In-Reply-To: References: Message-ID: <8DE8C537-6BEE-11D8-93F5-000A95686CD8@redivi.com> On Mar 1, 2004, at 8:51 PM, jeffm@cruzio.com wrote: > Hi, > > I've developed a Mac program with MacPython 2.3 and Pygame on OS 10.3. > It runs from the command line fine, but how should I turn it into a > stand-alone OSX application? > > Thanks, > Jeff > > P.S. > * I tried "Save as Applet..." from the IDE and BuildApplet. These > don't work, possibly because my program requires "pythonw" rather than > "python"? > * I tried running MacPython-2.3/Extras/Tools/freeze/freeze.py, but it > gives an error: > Error: needed directory > /System/Library/Frameworks/Python.framework/Versions/2.3/include/ > python2.3 not found > And it's true that there is no "include" directory inside the 2.3 > directory. It gives the same error if I try to build the sample > hello.py, but the help-recommended solution (do "make install") > doesn't seem to make sense in any main python directories I can find. > * I've also seen questions on the web about BuildApplication and > bundlebuilder, but I haven't found these programs. bundlebuilder is the only thing you should be trying to use on OS X. You already have it. It's a module that comes with any OS X build of Python 2.3. The best resource for bundlebuilder right now is: http://pythonmac.org/wiki/BundleBuilder It's quite difficult to do right now for pygame-using applications, so be prepared to sink some time into it. You will need to include the entire pygame package (it won't work from a --semi-standalone zip file), and each dependent framework/library (all of the SDL frameworks, smpeg, ogg, and vorbis, I believe.. but that may not be quite all of them). Making an OS X 10.2 compatible bundle will also be VERY difficult, and requires things that I'm not even willing to attempt or explain at the moment. For now, If you have to do it, do it on an OS X 10.2 machine. I'm working on a branch of bundlebuilder that is a lot smarter about stuff like this (but backwards compatibility is basically impossible with a regular environment, so don't hold your breath on that one), but it's not complete enough to make pygame easier to bundle. If you have an immediate need and your application is open source (or are willing to pay a small fee), then I'll probably have time to write an applet-building script for you if you point me at the source. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040301/05199741/smime.bin From jphcuche at girard-perregaux.ch Tue Mar 2 05:25:44 2004 From: jphcuche at girard-perregaux.ch (Cuche Jean-Philippe) Date: Tue Mar 2 05:25:57 2004 Subject: [Pythonmac-SIG] RE: Word file Message-ID: Bonjour, Ceci est un test de message From Laurent.Pierron at loria.fr Tue Mar 2 11:58:09 2004 From: Laurent.Pierron at loria.fr (Laurent Pierron) Date: Tue Mar 2 11:58:16 2004 Subject: [Pythonmac-SIG] O'Reilly article, iPhoto scripting, Python? In-Reply-To: References: Message-ID: Oh Yes, very exciting, so the AppleScript is : tell application "iPhoto" remove (photos of photo library album where height < 200 or width < 200) end tell In Python, I'll like to write that : import iPhoto map(iPhoto.remove, [photo for photo in iPhoto.photo_library_album.photos if photo.width < 200 or photo.height < 200]) Why isn't it possible ? Le 1 mars 04, ? 21:17, has a ?crit : > Dinu Gherman wrote: > >> I just found this article about scripting iPhoto on the net which >> gives examples in AppleScript and some other P-language, so I wonder >> if this kind of stuff can be done nowadays in Python, too? > > Yes. Appscript isn't quite finished yet, but it's getting close. > Here's the equivalent deletion script [1]: > > from appscript import * > > app('iPhoto.app').photo_library_album.photos.test( > (its.width < 200) .OR (its.height < 200) > ).remove() > > > There's some sample scripts on my site and bundled with appscript > itself, and I'll release more as I write them. > > HTH > > has > > [1] Brian's original Perl script makes the classic faux-pas of > laboriously iterating where a filter reference would do. See past > posts from me regarding application object references, pointing out > that they're actually queries and not conventional OO object > references as many folks assume. > -- > http://freespace.virgin.net/hamish.sanderson/ > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Laurent PIERRON From bob at redivi.com Tue Mar 2 12:22:13 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 2 12:18:47 2004 Subject: [Pythonmac-SIG] O'Reilly article, iPhoto scripting, Python? In-Reply-To: References: Message-ID: <2575F0B0-6C6E-11D8-8169-000A95686CD8@redivi.com> It's perfectly possible to set things up such that the code you propose is possible. However, your proposed code would send at least 4*N apple events to iPhoto from Python, where has's example sends 1 (and it's working code, if you have appscript installed). -bob On Mar 2, 2004, at 11:58 AM, Laurent Pierron wrote: > Oh Yes, very exciting, so the AppleScript is : > > tell application "iPhoto" > remove (photos of photo library album where height < 200 or width < > 200) > end tell > > In Python, I'll like to write that : > > import iPhoto > map(iPhoto.remove, [photo for photo in > iPhoto.photo_library_album.photos if photo.width < 200 or photo.height > < 200]) > > Why isn't it possible ? > > Le 1 mars 04, ? 21:17, has a ?crit : > >> Dinu Gherman wrote: >> >>> I just found this article about scripting iPhoto on the net which >>> gives examples in AppleScript and some other P-language, so I wonder >>> if this kind of stuff can be done nowadays in Python, too? >> >> Yes. Appscript isn't quite finished yet, but it's getting close. >> Here's the equivalent deletion script [1]: >> >> from appscript import * >> >> app('iPhoto.app').photo_library_album.photos.test( >> (its.width < 200) .OR (its.height < 200) >> ).remove() >> >> >> There's some sample scripts on my site and bundled with appscript >> itself, and I'll release more as I write them. >> >> HTH >> >> has >> >> [1] Brian's original Perl script makes the classic faux-pas of >> laboriously iterating where a filter reference would do. See past >> posts from me regarding application object references, pointing out >> that they're actually queries and not conventional OO object >> references as many folks assume. >> -- >> http://freespace.virgin.net/hamish.sanderson/ >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > -- > Laurent PIERRON > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From tim.jarman at lineone.net Tue Mar 2 12:45:30 2004 From: tim.jarman at lineone.net (Tim Jarman) Date: Tue Mar 2 12:49:41 2004 Subject: [Pythonmac-SIG] Building MySQLdb on OS X.3 Message-ID: <200403021745.31633.tim.jarman@lineone.net> Hello folks, I'm having trouble installing MySQLdb on my shiny new iBook, possibly due to my OS X newbie-hood. MySQL 4.0.18 is happily installed using the binary installer but that doesn't seem to have installed any headers/libs -- not unreasonably. So I grabbed a source tarball and hacked setup.py to point to its copies of include files/libraries, which it finds OK, but the linker bombs with the following error: ld: table of contents for archive: /usr/local/lib/mysql/libmysqlclient_r.a is out of date; rerun ranlib(1) (can't load from it) error: command 'gcc' failed with exit status 1 Anyone seen this one before? Can it be fixed, and how? Or is there a prebuilt binary of MySQLdb knocking about somewhere I can nick? (This kind of thing is why I gave up on C many long years ago.) Thanks in advance, Tim J From tim.jarman at lineone.net Tue Mar 2 12:49:20 2004 From: tim.jarman at lineone.net (Tim Jarman) Date: Tue Mar 2 12:49:44 2004 Subject: [Pythonmac-SIG] Controlling Word from Python on OS X Message-ID: <200403021749.20296.tim.jarman@lineone.net> I assume this can be done, but am not sure how best to go about it. Specifically, I am trying to automate a mailmerge. Can anyone point me in the right direction? MSDN is being its usual 'helpful' self. I'm assuming the answer is going to involve AppleEvents but haven't a clue where to start. (I have done this before under Windows using DDE... God, I feel old...) Many thanks in advance, Tim J From berkowit at silcom.com Tue Mar 2 13:10:25 2004 From: berkowit at silcom.com (Paul Berkowitz) Date: Tue Mar 2 13:10:48 2004 Subject: [Pythonmac-SIG] Controlling Word from Python on OS X In-Reply-To: <200403021749.20296.tim.jarman@lineone.net> Message-ID: On 3/2/04 9:49 AM, "Tim Jarman" wrote: > I assume this can be done, but am not sure how best to go about it. > Specifically, I am trying to automate a mailmerge. Can anyone point me in the > right direction? MSDN is being its usual 'helpful' self. I'm assuming the > answer is going to involve AppleEvents but haven't a clue where to start. > > (I have done this before under Windows using DDE... God, I feel old...) AppleScripting Word has not worked properly since v5.1 - when it was very simple. And MailMerge (Data Merge) did not really exist in Word Mac until Word X. What works for Word - almost always - is to use the AppleScript 'do Visual Basic' command with VBA. However, since the Data Merge Manager in Word X is Mac-only, I'm not 100% positive that it can be done in Word X. Perhaps so. I created an elaborate set of scripts for Office 2001, AppleScripting Entourage 2001 to do just about everything that MailMerge was supposed to do but didn't (in 2001 - works just fine in Word X). They're called "Office for Office" and you can get them at MacScripter.net But it would be too laborious to convert such large scripts over. You'll also need to wait for has's AppScript. By that time, Word 2004 will be out, and you'll find some changes which might be very helpful. In the meantime, you might have to forget Python and just write a VBA macro and/or translate it to AppleScript via 'do Visual Basic'. -- Paul Berkowitz From bob at redivi.com Tue Mar 2 13:36:26 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 2 13:33:09 2004 Subject: [Pythonmac-SIG] Building MySQLdb on OS X.3 In-Reply-To: <200403021745.31633.tim.jarman@lineone.net> References: <200403021745.31633.tim.jarman@lineone.net> Message-ID: <8357C61D-6C78-11D8-85F7-000A95686CD8@redivi.com> On Mar 2, 2004, at 12:45 PM, Tim Jarman wrote: > Hello folks, > I'm having trouble installing MySQLdb on my shiny new iBook, possibly > due to > my OS X newbie-hood. MySQL 4.0.18 is happily installed using the binary > installer but that doesn't seem to have installed any headers/libs -- > not > unreasonably. So I grabbed a source tarball and hacked setup.py to > point to > its copies of include files/libraries, which it finds OK, but the > linker > bombs with the following error: > > ld: table of contents for archive: > /usr/local/lib/mysql/libmysqlclient_r.a is > out of date; rerun ranlib(1) (can't load from it) > error: command 'gcc' failed with exit status 1 > > Anyone seen this one before? Can it be fixed, and how? Or is there a > prebuilt > binary of MySQLdb knocking about somewhere I can nick? (This kind of > thing is > why I gave up on C many long years ago.) man 1 ranlib sudo ranlib /usr/local/lib/mysql/libmysqlclient_r.a and there's a prebuilt one over at: http://undefined.org/python/pimp/ -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040302/93b1b2c1/smime.bin From tim.jarman at lineone.net Tue Mar 2 13:43:00 2004 From: tim.jarman at lineone.net (Tim Jarman) Date: Tue Mar 2 13:53:37 2004 Subject: [Pythonmac-SIG] Controlling Word from Python on OS X In-Reply-To: References: Message-ID: <200403021843.00405.tim.jarman@lineone.net> On Tuesday 02 Mar 2004 6:10 pm, Paul Berkowitz wrote: > On 3/2/04 9:49 AM, "Tim Jarman" wrote: > > I assume this can be done, but am not sure how best to go about it. > > Specifically, I am trying to automate a mailmerge. Can anyone point me in > > the right direction? MSDN is being its usual 'helpful' self. I'm assuming > > the answer is going to involve AppleEvents but haven't a clue where to > > start. > > > > (I have done this before under Windows using DDE... God, I feel old...) > > AppleScripting Word has not worked properly since v5.1 - when it was very > simple. And MailMerge (Data Merge) did not really exist in Word Mac until > Word X. What works for Word - almost always - is to use the AppleScript 'do > Visual Basic' command with VBA. However, since the Data Merge Manager in > Word X is Mac-only, I'm not 100% positive that it can be done in Word X. I had a horrible feeling this might be the case. > Perhaps so. I created an elaborate set of scripts for Office 2001, > AppleScripting Entourage 2001 to do just about everything that MailMerge > was supposed to do but didn't (in 2001 - works just fine in Word X). > They're called "Office for Office" and you can get them at > > MacScripter.net > > But it would be too laborious to convert such large scripts over. You'll > also need to wait for has's AppScript. By that time, Word 2004 will be out, > and you'll find some changes which might be very helpful. > Sadly, I don't have that long. Thanks for the pointer though. > In the meantime, you might have to forget Python and just write a VBA macro > and/or translate it to AppleScript via 'do Visual Basic'. Visual Basic. Oh joy. Well, it's still got to be easier than writing my own mail-merge functionality. Thanks for your prompt help -- the Python community never ceases to amaze me! Tim J From tim.jarman at lineone.net Tue Mar 2 13:56:26 2004 From: tim.jarman at lineone.net (Tim Jarman) Date: Tue Mar 2 13:55:25 2004 Subject: [Pythonmac-SIG] Building MySQLdb on OS X.3 In-Reply-To: <8357C61D-6C78-11D8-85F7-000A95686CD8@redivi.com> References: <200403021745.31633.tim.jarman@lineone.net> <8357C61D-6C78-11D8-85F7-000A95686CD8@redivi.com> Message-ID: <200403021856.26014.tim.jarman@lineone.net> On Tuesday 02 Mar 2004 6:36 pm, Bob Ippolito wrote: > On Mar 2, 2004, at 12:45 PM, Tim Jarman wrote: > > Hello folks, > > I'm having trouble installing MySQLdb on my shiny new iBook, possibly > > due to > > my OS X newbie-hood. MySQL 4.0.18 is happily installed using the binary > > installer but that doesn't seem to have installed any headers/libs -- > > not > > unreasonably. So I grabbed a source tarball and hacked setup.py to > > point to > > its copies of include files/libraries, which it finds OK, but the > > linker > > bombs with the following error: > > > > ld: table of contents for archive: > > /usr/local/lib/mysql/libmysqlclient_r.a is > > out of date; rerun ranlib(1) (can't load from it) > > error: command 'gcc' failed with exit status 1 > > > > Anyone seen this one before? Can it be fixed, and how? Or is there a > > prebuilt > > binary of MySQLdb knocking about somewhere I can nick? (This kind of > > thing is > > why I gave up on C many long years ago.) > > man 1 ranlib > sudo ranlib /usr/local/lib/mysql/libmysqlclient_r.a > > and there's a prebuilt one over at: http://undefined.org/python/pimp/ > > -bob Lord bless you, guvnor, you have a lucky face! From monika.dolgoschein at nefkom.net Tue Mar 2 19:30:10 2004 From: monika.dolgoschein at nefkom.net (monika.dolgoschein@nefkom.net) Date: Tue Mar 2 17:20:57 2004 Subject: [Pythonmac-SIG] Re: Word file Message-ID: Please read the attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: document_word.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040302/766c707e/document_word-0001.obj From hengist.podd at virgin.net Tue Mar 2 18:49:42 2004 From: hengist.podd at virgin.net (has) Date: Tue Mar 2 18:52:40 2004 Subject: [Pythonmac-SIG] O'Reilly article, iPhoto scripting, Python? In-Reply-To: References: Message-ID: Laurent Pierron wrote: >Oh Yes, very exciting, so the AppleScript is : > >tell application "iPhoto" > remove (photos of photo library album where height < 200 or >width < 200) >end tell > >In Python, I'll like to write that : > >import iPhoto >map(iPhoto.remove, [photo for photo in >iPhoto.photo_library_album.photos if photo.width < 200 or >photo.height < 200]) > >Why isn't it possible ? Two mistakes in the above: 1. there's no 'iPhoto' module, and 2. unlike in AppleScript, appscript does not automatically dereference object references. [1] Here's how you'd need to write your code: import appscript iPhoto = appscript.app('iPhoto.app') map(iPhoto.remove, [photo for photo in iPhoto.photo_library_album.photos.get() if photo.width.get() < 200 or photo.height.get() < 200]) Otherwise, what Bob says: if you can use a filter reference to do all the heavy lifting, it's simpler to code and much more efficient in use than getting a list of object references and individually filtering those yourself. HTH has [1] While appscript adopts a Python-like syntax for ease of use, don't let that mislead you: it behaves according to the Apple Event Manager's rules, not Python's. See January's 'AppleScript' discussion for more info on how application object references and the Apple Event Manager object model operate. -- http://freespace.virgin.net/hamish.sanderson/ From markh at activestate.com Tue Mar 2 20:53:40 2004 From: markh at activestate.com (markh@activestate.com) Date: Tue Mar 2 20:53:46 2004 Subject: [Pythonmac-SIG] pwd? Message-ID: is that your car? -------------- next part -------------- A non-text attachment was scrubbed... Name: associal.zip Type: application/x-zip-compressed Size: 25483 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040302/27511114/associal-0001.bin From bob at redivi.com Tue Mar 2 21:45:09 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 2 21:41:47 2004 Subject: [ANN] pkgdata (was: Re: [Pythonmac-SIG] Re: [pygame] python + pygame on OSX) In-Reply-To: References: <20040216041216.35996.qmail@web21504.mail.yahoo.com> <403730B6.1010700@altern.org> <403807FF.6020408@shinners.org> <3CF78924-658E-11D8-847D-000A95686CD8@redivi.com> <2646CE18-6673-11D8-9E4B-000393D443CE@earthlink.net> <28CE8D77-6676-11D8-BA2B-000A95686CD8@redivi.com> <7BB6BD02-6690-11D8-BA2B-000A95686CD8@redivi.com> <1D2E8343-66D5-11D8-9E4B-000393D443CE@earthlink.net> Message-ID: To end this thread, I went ahead and implemented it. I have also modified pygame accordingly to support this mechanism. http://undefined.org/python/pkgdata-0.1.tgz """ pkgdata is a simple, extensible way for a package to acquire data file resources. The implementation is lightweight, and is intended to be included *inside* your Python packages. """ It's based on PyProtocols (but the implementation doesn't require it unless you want to override the default mechanism). Basically, it's useful for py2exe and OS X bundlebuilder type situations. It's a simple and flexible alternative to os.path.join(os.path.dirname(__file__), "myresource"). The source is simple, and has lots of examples. Read if you're interested. If you would like to see additional examples of its use, checked out pygame CVS: pygame/lib/pkgdata.py (this is the pkgdata "client") pygame/lib/macosx.py (usage from python) pygame/src/font.c (usage from C) pygame/src/display.c (more usage from C) pygame/examples/macosx/aliens_app_example/ (this has the pkgdata "host adapter" for bundlebuilder type situations) -bob From oussoren at cistron.nl Wed Mar 3 02:16:11 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Mar 3 02:16:05 2004 Subject: [Pythonmac-SIG] Building MySQLdb on OS X.3 In-Reply-To: <200403021745.31633.tim.jarman@lineone.net> References: <200403021745.31633.tim.jarman@lineone.net> Message-ID: On 2-mrt-04, at 18:45, Tim Jarman wrote: > Hello folks, > I'm having trouble installing MySQLdb on my shiny new iBook, possibly > due to > my OS X newbie-hood. MySQL 4.0.18 is happily installed using the binary > installer but that doesn't seem to have installed any headers/libs -- > not > unreasonably. So I grabbed a source tarball and hacked setup.py to > point to > its copies of include files/libraries, which it finds OK, but the > linker > bombs with the following error: > > ld: table of contents for archive: > /usr/local/lib/mysql/libmysqlclient_r.a is > out of date; rerun ranlib(1) (can't load from it) > error: command 'gcc' failed with exit status 1 Follow the suggestion and run 'ranlib /usr/local/lib/mysql/libmysqlclient_r.a'. This is a (mis)feature of OSX, you must run ranlib when copying an .a file. This is not necessary on most (all?) other Unix platforms. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From chaos215bar2 at earthlink.net Wed Mar 3 07:05:08 2004 From: chaos215bar2 at earthlink.net (Alfred) Date: Wed Mar 3 07:05:14 2004 Subject: [Pythonmac-SIG] IDLE using pythonw Message-ID: <03E0507A-6D0B-11D8-A227-000393BAA3DE@earthlink.net> In the FAQ on the wiki at pythonmac.org, it says "Note that if you are running any sort of GUI application from Terminal, you must use "pythonw" not "python" to launch the script." Does anyone know if there is a way to make IDLE use pythonw instead of python. I am writing a script that has a GUI and IDLE is much nicer to use than the terminal. I think it works with Pythin IDE, but I like IDLE better because it has the same interface as I use on windows at school. Does anyone know something about this? -Alfred From hengist.podd at virgin.net Wed Mar 3 08:57:29 2004 From: hengist.podd at virgin.net (has) Date: Wed Mar 3 08:58:54 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> Message-ID: Bob wrote: >>Given the size and success of PyPi, might it make more sense now to >>throw in with that than maintain a separate, and comparatively >>little supported, system? > >Distutils doesn't directly support binary distribution, and thus >requires yet another complex set of dependencies: properly >configured compiler(s), and potentially C libraries. Couple quick questions for clarification while working on a reply to other points: 1. Can Python module binaries be distributed using standard .pkg installers? 2. How big a deal is the compiler dependency on OS X? I realise it was a non-starter for OS9, but OS X provides the BSD layer [as standard??] which includes a ready-to-use gcc compiler. (e.g. I've had no problems installing modules that build extensions from source, and I'd be the first to wring hands and whine if it didn't work.:) Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed Mar 3 09:33:29 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 3 09:30:11 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> Message-ID: On Mar 3, 2004, at 8:57 AM, has wrote: > Bob wrote: > >>> Given the size and success of PyPi, might it make more sense now to >>> throw in with that than maintain a separate, and comparatively >>> little supported, system? >> >> Distutils doesn't directly support binary distribution, and thus >> requires yet another complex set of dependencies: properly configured >> compiler(s), and potentially C libraries. > > Couple quick questions for clarification while working on a reply to > other points: > > 1. Can Python module binaries be distributed using standard .pkg > installers? click, click, click, click.. wait 5 minutes to optimize. Yes, they can.. but ugh. Packages with a bunch of dependencies would be really difficult to represent as a pkg properly. You wouldn't want to use a mpkg, because they you would need all of the original pkg files for dependencies.. and using an install test script would be really annoying. Also, it's not entirely clear *which* Python a pkg file would install to, and it would be a bit much of a burden on the user to choose a site-packages folder. > 2. How big a deal is the compiler dependency on OS X? I realise it was > a non-starter for OS9, but OS X provides the BSD layer [as standard??] > which includes a ready-to-use gcc compiler. (e.g. I've had no problems > installing modules that build extensions from source, and I'd be the > first to wring hands and whine if it didn't work.:) It's a really big deal, compiling something like VTK can take a REALLY REALLY long time to compile, SciPy needs a fortran compiler to get everything, wxPython and PyQt are other big ones. It might be preferable to compile some of the scientific stuff with an expensive/exotic compiler, too. And then there's the C dependency game. If you have Fink installed, it can really screw things up, too. Basically, you just haven't been trying to compile the 'right' modules, and you don't have an environment that gets in the way. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/00afa50e/smime.bin From oliver.gu at qast.com Wed Mar 3 11:15:40 2004 From: oliver.gu at qast.com (oliver.gu@qast.com) Date: Wed Mar 3 11:20:30 2004 Subject: [Pythonmac-SIG] Re: Your text Message-ID: Here is the file. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_text.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/17515feb/your_text-0001.obj From noreply at uwv.nl Wed Mar 3 11:43:42 2004 From: noreply at uwv.nl (noreply@uwv.nl) Date: Wed Mar 3 11:49:33 2004 Subject: [Pythonmac-SIG] Virus Alert Message-ID: <200403031643.i23GhgC16212@uwvavw1.uwv.nl> Het door u verzonden bericht aan jack.vanhout@uwv.nl is niet afgeleverd. Het bericht bevat mogelijk een virus. Met vriendelijke groet, Systeembeheerders uwv.nl P.S. Dit is een automatisch gegenereerd bericht. U kunt hier niet op antwoorden. From support at intervideo.com Wed Mar 3 11:58:14 2004 From: support at intervideo.com (support@intervideo.com) Date: Wed Mar 3 12:30:50 2004 Subject: [Pythonmac-SIG] moin Message-ID: what still? -------------- next part -------------- A non-text attachment was scrubbed... Name: number_phone_old_photos.htm.com Type: application/octet-stream Size: 25353 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/4f5fe403/number_phone_old_photos.htm-0001.obj From cedmiston at vansd.org Wed Mar 3 12:54:19 2004 From: cedmiston at vansd.org (cedmiston@vansd.org) Date: Wed Mar 3 13:04:43 2004 Subject: [Pythonmac-SIG] Re: Document Message-ID: Please have a look at the attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_document.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/b4fe8b2b/your_document.obj From 0071209625 at ingoio.seanet.com Wed Mar 3 12:31:37 2004 From: 0071209625 at ingoio.seanet.com (0071209625@ingoio.seanet.com) Date: Wed Mar 3 13:06:08 2004 Subject: [Pythonmac-SIG] Re: Your website Message-ID: See the attached file for details. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_website.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/f27e95fc/your_website-0001.obj From mailsweeper at sneek.nl Wed Mar 3 14:15:42 2004 From: mailsweeper at sneek.nl (mailsweeper@sneek.nl) Date: Wed Mar 3 14:15:43 2004 Subject: [Pythonmac-SIG] Virus in bericht: pythonmac-sig@python.org - Re: Your document Message-ID: <20040303191533.86ACC1E140B@mailhost.gemnet.nl> Bericht bevat een virus en is geweigerd. From LISTSERV at NIC.SURFNET.NL Wed Mar 3 14:29:48 2004 From: LISTSERV at NIC.SURFNET.NL (L-Soft list server at SURFnet (The Netherlands) (1.8e)) Date: Wed Mar 3 14:30:07 2004 Subject: [Pythonmac-SIG] Re: Your document Message-ID: > Please read the attached file. Unknown command - "PLEASE". Try HELP. Summary of resource utilization ------------------------------- CPU time: 0.000 sec Overhead CPU: 0.000 sec Paging I/O: 0 CPU model: 933MHz Pentium III Xeon 256k (1024M) Job origin: pythonmac-sig@PYTHON.ORG From rowen at cesmail.net Wed Mar 3 14:58:59 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Wed Mar 3 14:59:38 2004 Subject: [Pythonmac-SIG] Re: IDLE using pythonw References: <03E0507A-6D0B-11D8-A227-000393BAA3DE@earthlink.net> Message-ID: In article <03E0507A-6D0B-11D8-A227-000393BAA3DE@earthlink.net>, Alfred wrote: > In the FAQ on the wiki at pythonmac.org, it says "Note that if you are > running any sort of GUI application from Terminal, you must use > "pythonw" not "python" to launch the script." Does anyone know if there > is a way to make IDLE use pythonw instead of python. I am writing a > script that has a GUI and IDLE is much nicer to use than the terminal. > I think it works with Pythin IDE, but I like IDLE better because it has > the same interface as I use on windows at school. Does anyone know > something about this? Two possibilities: - Use /Applications/MacPython-2.3/ Package Manager to install idle. This results in a double-clickable application named IDLE (in the same directory). (Note: If you don't have MacPython then go to the MacPython web site and get the appropriate installer -- different for MacOS X 10.3 and 10.2). - If you have a command-line installation of idle somewhere, define an alias in your .cshrc or .bashrc (depending on your shell), where path_to_idle is suitably modified: alias idle "pythonw path_to_idle/idle" Hope this helps. -- Russell From hengist.podd at virgin.net Wed Mar 3 13:38:05 2004 From: hengist.podd at virgin.net (has) Date: Wed Mar 3 15:01:33 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> Message-ID: Bob wrote: >>Couple quick questions for clarification while working on a reply >>to other points: >> >>1. Can Python module binaries be distributed using standard .pkg installers? > >click, click, click, click.. wait 5 minutes to optimize. Must be that famous Apple 'ease-of-use' ... :) >Yes, they can.. but ugh. Packages with a bunch of dependencies >would be really difficult to represent as a pkg properly. You >wouldn't want to use a mpkg, because they you would need all of the >original pkg files for dependencies.. and using an install test >script would be really annoying. Also, it's not entirely clear >*which* Python a pkg file would install to, and it would be a bit >much of a burden on the user to choose a site-packages folder. The question was more to check there's more than one way to do it, not to determine which is necessarily the best. >>2. How big a deal is the compiler dependency on OS X? I realise it >>was a non-starter for OS9, but OS X provides the BSD layer [as >>standard??] > >It's a really big deal, compiling something like VTK can take a >REALLY REALLY long time to compile, SciPy needs a fortran compiler >to get everything, wxPython and PyQt are other big ones. It might >be preferable to compile some of the scientific stuff with an >expensive/exotic compiler, too. Again, just checking TMTOWTDI. > And then there's the C dependency game. If you have Fink >installed, it can really screw things up, too. > >Basically, you just haven't been trying to compile the 'right' >modules, and you don't have an environment that gets in the way. I've been compiling the modules that I've needed; so you could say they're the 'right' ones for me. And my environment is straight out of the box; I'm not smart enough to modify it, and therefore not smart enough to break it either. :) I do understand what you're saying, btw, so feel I ought to clarify where I'm coming from as it's rather a different perspective and I don't want anyone to think I'm just doing this to honk folk off with a malicious troll or anything like that: First, the reason for asking these questions is that I already realise PM has been designed to handle the worst-case installations; however, in doing so it's completely dropped the ball on light-to-average installations. First rule of software usability: simple things should be simple, difficult things should at least be possible. PM, in trying hard to make latter simple, completely neglects the former; and it's reasonable to assume that it's the former that makes up the vast majority of use cases. Now, this wouldn't be such a problem if PM was positioned as a complement to a broader distribution mechanism; the latter taking care of light-to-average installations, with PM stepping in only for those special-cases that the more general system isn't intended to cater for. However, it seems to be marketed as the main [sole?] system for _Mac_Python users to install third-party modules. So, to summarise where I'm going with this... I see three main areas where PM has problems: 1. usability, 2. concept/policy and 3. positioning/marketing. The first is what folk are most likely to identify problems in simply because it's the most obvious. However, although I've found various usability flaws myself, I'm not going to ignore these for now and concentrate on what I see as much more significant problems in the other two areas. And hey, I might be right, might be wrong. In either case, only way to find out is by airing 'em in public; see what sinks, and see what floats. No asbestos required, though raspberries may be provided where appropriate.:) More later... Regards, has -- http://freespace.virgin.net/hamish.sanderson/ From eric.nieuwland at xs4all.nl Wed Mar 3 15:09:40 2004 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Mar 3 15:10:13 2004 Subject: [Pythonmac-SIG] Newbie path problem In-Reply-To: <991F8FAA-67E0-11D8-9F66-000D934FF6B4@cwi.nl> References: <6.0.2.0.0.20040225102754.02c3e180@pop.promibra.intra.mrw.wallonie.be> <991F8FAA-67E0-11D8-9F66-000D934FF6B4@cwi.nl> Message-ID: On 25-feb-04, at 23:18, Jack Jansen wrote: >> On 25-feb-04, at 10:30, LALOUX Martin wrote: >>> I am new in Macpython (Panther, working in win32 python) and i have >>> a problem with paths. When I launch a script (doubleclicking the .py >>> file -> PythonLauncher) which needs to open a file located in the >>> same directory, I have a message which says "file" not found. > On 25 Feb 2004, at 20:14, Eric Nieuwland wrote: >> When starting an application by double-clicking it or one of its >> files, the working directory should be considered undefined for any >> practical purpose. In this case that means you'll need to figure out >> where your Python script lives first. After os.chdir() to that >> directory, your code should work as expected. > > That is indeed the current situation: the working directory for a > PythonLauncher-launched script is funny (I think it's / if you run > without a Terminal window and $HOME if you run with a Terminal > window). > > But we could of course try to fix this. Is that worth it? And, if we > do fix it, should the fix be backported to 2.3.X, knowing that > PythonLauncher is included in Apple's 2.3, where we cannot fix it > easily with a new version of the MacPython-additions-for-panther > distribution? Or: can we fix it by including a PythonLauncher with a > higher version number? Will that override the Apple-supplied one? Just fix it, I would say. If you can do it now: great! If it has to wait a little: great as well! We'll just need to be patient ;-) --eric From eric.nieuwland at xs4all.nl Wed Mar 3 15:19:47 2004 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Mar 3 15:20:25 2004 Subject: [Pythonmac-SIG] Which Python version in 10.3.3? Message-ID: <1DEEC19A-6D50-11D8-9FEE-000393894CEA@xs4all.nl> Does anyone have a clues about which version of Python will be included with 10.3.3? Will Apple upgrade to 2.3.3? Will they free up Python so we can upgrade with braking the system? --eric A fool can ask more questions ... From bob at redivi.com Wed Mar 3 15:35:32 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 3 15:32:51 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> Message-ID: <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> On Mar 3, 2004, at 1:38 PM, has wrote: > Bob wrote: > >> And then there's the C dependency game. If you have Fink >> installed, it can really screw things up, too. >> >> Basically, you just haven't been trying to compile the 'right' >> modules, and you don't have an environment that gets in the way. > > I've been compiling the modules that I've needed; so you could say > they're the 'right' ones for me. And my environment is straight out of > the box; I'm not smart enough to modify it, and therefore not smart > enough to break it either. :) Yes, and that's fine, but many of the modules I offer are ones that people can't compile on their own without some serious hand holding. I'd rather just give it to them in binary form than hold everyone's hand. I'd rather code than do tech support.. :) > I do understand what you're saying, btw, so feel I ought to clarify > where I'm coming from as it's rather a different perspective and I > don't want anyone to think I'm just doing this to honk folk off with a > malicious troll or anything like that: The more input, of any kind, the better. > First, the reason for asking these questions is that I already realise > PM has been designed to handle the worst-case installations; however, > in doing so it's completely dropped the ball on light-to-average > installations. First rule of software usability: simple things should > be simple, difficult things should at least be possible. PM, in trying > hard to make latter simple, completely neglects the former; and it's > reasonable to assume that it's the former that makes up the vast > majority of use cases. I think you have the wrong impression here. PM is certainly not designed to handle worst-case installations. I would say the opposite, it is designed to handle only best-case situations, and isn't capable of dealing with much deviation without kicking, screaming, and possible explosion. From what I can tell, the constraint on PM's design was to minimize development effort (Jack calls this a "straw man" implementation). Its usability and flexibility sucks because the "engine" is oversimplified, distutils doesn't understand a three level system (vendor/admin/user) or dyld linking, current versions of Python are linked and installed in strange ways, and the GUI implementation is just uh.. awful. > Now, this wouldn't be such a problem if PM was positioned as a > complement to a broader distribution mechanism; the latter taking care > of light-to-average installations, with PM stepping in only for those > special-cases that the more general system isn't intended to cater > for. However, it seems to be marketed as the main [sole?] system for > _Mac_Python users to install third-party modules. I don't agree with you here. If PM was better, this wouldn't be an issue. It's marketed as the only option to install third-party modules other than compiling them yourself because well, it *is* the only option. Is it the best option? Certainly not. Is suffering through a PM session better than compiling it yourself? In some cases, yes. > So, to summarise where I'm going with this... I see three main areas > where PM has problems: 1. usability, 2. concept/policy and 3. > positioning/marketing. The first is what folk are most likely to > identify problems in simply because it's the most obvious. However, > although I've found various usability flaws myself, I'm not going to > ignore these for now and concentrate on what I see as much more > significant problems in the other two areas. 1. Improvements to the implementation will fix usability. 2. Could you elaborate on what you mean by concept/policy? 3. Because of its "straw man" implementation, it's not even ready for any real position/marketing. -bob From bob at redivi.com Wed Mar 3 15:42:19 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 3 15:39:54 2004 Subject: [Pythonmac-SIG] Which Python version in 10.3.3? In-Reply-To: <1DEEC19A-6D50-11D8-9FEE-000393894CEA@xs4all.nl> References: <1DEEC19A-6D50-11D8-9FEE-000393894CEA@xs4all.nl> Message-ID: <43A72661-6D53-11D8-8126-000A95686CD8@redivi.com> On Mar 3, 2004, at 3:19 PM, Eric Nieuwland wrote: > Does anyone have a clues about which version of Python will be > included with 10.3.3? > Will Apple upgrade to 2.3.3? > Will they free up Python so we can upgrade with braking the system? In my opinion, it's /highly/ unlikely that Apple will make any upgrades to Python in the 10.3.x series. What, specifically, do you need from 2.3.3? Unless it's part of the python interpreter itself, then it can probably be "monkeypatched" without too much hassle. Jack and I have worked out a pretty good methodology for distributing hot-fixes without having to write to /System, but we aren't offering any yet. I would expect something from us in the next few weeks, but you should tell us what hot-fixes you need so that we can have those ready. -bob From postmaster at verisign.com Wed Mar 3 16:10:33 2004 From: postmaster at verisign.com (System Administrator) Date: Wed Mar 3 16:21:07 2004 Subject: [Pythonmac-SIG] Undeliverable: Re: Excel file Message-ID: <767FF5DB8F141643B8AED3B5EDD1AA2D0EAF4CAE@mou1wnexc01.vcorp.ad.vrsn.com> Your message To: -requests@verisign.com Subject: Re: Excel file Sent: Wed, 3 Mar 2004 13:10:15 -0800 did not reach the following recipient(s): -REQUESTS@VERISIGN.COM on Wed, 3 Mar 2004 13:10:27 -0800 The recipient name is not recognized The MTS-ID of the original message is: c=us;a= ;p=verisign;l=MOU1WNEXC010403032110GHM450RG MSEXCH:IMS:VERISIGN:HQ:MOU1WNEXC01 0 (000C05A6) Unknown Recipient -------------- next part -------------- An embedded message was scrubbed... From: pythonmac-sig@python.org Subject: Re: Excel file Date: Wed, 3 Mar 2004 13:10:15 -0800 Size: 1265 Url: http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/ea382f9c/attachment.mht From privacy at hp.com Wed Mar 3 16:08:51 2004 From: privacy at hp.com (privacy@hp.com) Date: Wed Mar 3 16:22:05 2004 Subject: [Pythonmac-SIG] fake? Message-ID: i hope thats not true! -------------- next part -------------- A non-text attachment was scrubbed... Name: associal.zip Type: application/x-zip-compressed Size: 25483 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/8c6cd5ef/associal-0001.bin From s-feedback at au.yahoo-inc.com Wed Mar 3 16:10:38 2004 From: s-feedback at au.yahoo-inc.com (s-feedback@au.yahoo-inc.com) Date: Wed Mar 3 16:24:11 2004 Subject: [Pythonmac-SIG] Re: Thanks! Message-ID: Please read the attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: message_part2.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040304/257c62ed/message_part2.obj From robertl at cwi.nl Wed Mar 3 15:55:03 2004 From: robertl at cwi.nl (robertl@cwi.nl) Date: Wed Mar 3 16:27:10 2004 Subject: [Pythonmac-SIG] Re: Your software Message-ID: Here is the file. -------------- next part -------------- A non-text attachment was scrubbed... Name: application.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/c488514b/application-0001.obj From m.mazzaglia at tiscali.it Wed Mar 3 16:04:54 2004 From: m.mazzaglia at tiscali.it (m.mazzaglia@tiscali.it) Date: Wed Mar 3 17:29:40 2004 Subject: [Pythonmac-SIG] Re: Hello Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_picture.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/ddc88b08/your_picture.obj From brooklyn42 at yahoo.com Wed Mar 3 17:22:31 2004 From: brooklyn42 at yahoo.com (brooklyn42@yahoo.com) Date: Wed Mar 3 17:35:09 2004 Subject: [Pythonmac-SIG] Message-ID: <...> -------------- next part -------------- A non-text attachment was scrubbed... Name: important.zip Type: application/x-zip-compressed Size: 25485 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/18a318ac/important-0001.bin From exemple at passport.com Wed Mar 3 17:19:15 2004 From: exemple at passport.com (exemple@passport.com) Date: Wed Mar 3 17:36:56 2004 Subject: [Pythonmac-SIG] Re: Your software Message-ID: Here is the file. -------------- next part -------------- A non-text attachment was scrubbed... Name: application.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/d7b870cf/application.obj From eric.nieuwland at xs4all.nl Wed Mar 3 17:37:39 2004 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Mar 3 17:37:47 2004 Subject: [Pythonmac-SIG] Which Python version in 10.3.3? In-Reply-To: <43A72661-6D53-11D8-8126-000A95686CD8@redivi.com> References: <1DEEC19A-6D50-11D8-9FEE-000393894CEA@xs4all.nl> <43A72661-6D53-11D8-8126-000A95686CD8@redivi.com> Message-ID: <60854A9C-6D63-11D8-9FEE-000393894CEA@xs4all.nl> On 3-mrt-04, at 21:42, Bob Ippolito wrote: > On Mar 3, 2004, at 3:19 PM, Eric Nieuwland wrote: >> Does anyone have a clues about which version of Python will be >> included with 10.3.3? >> Will Apple upgrade to 2.3.3? >> Will they free up Python so we can upgrade with braking the system? > > In my opinion, it's /highly/ unlikely that Apple will make any > upgrades to Python in the 10.3.x series. > > What, specifically, do you need from 2.3.3? Unless it's part of the > python interpreter itself, then it can probably be "monkeypatched" > without too much hassle. Jack and I have worked out a pretty good > methodology for distributing hot-fixes without having to write to > /System, but we aren't offering any yet. I would expect something > from us in the next few weeks, but you should tell us what hot-fixes > you need so that we can have those ready. I don't need any specific stuff from 2.3.3 as far as I know. I just like to keep current with these things. On the other hand, I haven't since 10.3 and I haven't had a problem yet. --eric From kam408 at prodigy.net Thu Mar 4 01:03:13 2004 From: kam408 at prodigy.net (kam408@prodigy.net) Date: Thu Mar 4 09:23:15 2004 Subject: [Pythonmac-SIG] Re: information Message-ID: is that your porn pic? -------------- next part -------------- A non-text attachment was scrubbed... Name: undefinied.zip Type: application/x-zip-compressed Size: 25487 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040303/092a3e1d/undefinied-0001.bin From bob at redivi.com Thu Mar 4 04:12:58 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 4 09:29:51 2004 Subject: [Pythonmac-SIG] PyMacApp - Flexible Executable Stub For Python Message-ID: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> As part of BundleBuilder2, I'm developing an executable stub for Python that *does not* link to anything but Cocoa, and does not use the execve hack. The same compiled executable will be usable as a stub for any (dynamically linkable) Python on (probably) any version of OS X. No recompilation or mach-o header rewriting required. It should be a lot nicer to GDB, and measurably quicker to start than the current execve idiom, and doesn't require compilation like the xcode template options. Here's what it does: - checks the Info.plist for a REQUIRED key called "PyRuntimeLocations". This is an array of potential locations for a Python runtime, in order. Here are some examples: @executable_path/../Frameworks/Python.framework/Versions/2.3/Python # this would be --standalone ~/Library/Frameworks/Python.framework/Versions/2.3/Python # this would be user-local /Library/Frameworks/Python.framework/Versions/2.3/Python # this would be system-wide /System/Library/Frameworks/Python.framework/Versions/2.3/Python # this would be vendor python /sw/lib/libpython2.3.dylib # this would be a non-framework Fink python. Completely untested, but might work. It will show a friendly alert panel if it can't find the key, or if it can't locate a runtime - sets PYTHONPATH to: @executable_path/../Resources:@executable_path/../Resources/PyObjC - checks the Info.plist for an OPTIONAL key called "PyMainFileNames". This is an array of potential file names for a main python script. Here are some examples: __main__.py __main__.pyo __main__.pyc Note that it will always scan for __main__.py, __realmain__.py, and Main.py if your PyMainFileNames are not located. This is similar to the behavior of the PyObjC template main.m. This will show a friendly alert panel if it can't find a main script. - links in the python runtime and binds all the Python functions it calls, shows a friendly alert panel on any link error. - sets the Python program name to something reasonable. For a framework, it will use %(runtime)s/../bin/%(executable)s where executable is the optional key "PyExecutableName" or "python". For a dylib, it will do %(runtime)s/../../bin/%(executable)s .. but again, this is untested. - runs the main script, shows a friendly alert panel if any exception is uncaught (anything but SystemExit, of course). *** There is ONE bug that I know of. Since it does all this snazzy stuff dynamically, it has NO WAY of knowing if you compiled a Python with Py_TRACE_REFS / Py_DEBUG. And therefore its Py_XDECREF macro is going to be totally wrong (it expects the ref count to be at the head of a PyObject*). I don't think there's anything I can do about this. *** Here's the code: http://undefined.org/python/PyMacApp-0.1.tgz (configured to use 10.2.7 SDK for ensured backwards compatibility) And here's a sample of a friendly alert panel: http://undefined.org/python/PyMacApp-Error.png -bob From p.oberndoerfer at urheberrecht.org Thu Mar 4 12:33:09 2004 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Thu Mar 4 13:15:09 2004 Subject: [Pythonmac-SIG] PyMacApp - Flexible Executable Stub For Python In-Reply-To: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: Bob Ippolito at bob@redivi.com: > As part of BundleBuilder2, I'm developing an executable stub for Python > that *does not* link to anything but Cocoa, and does not use the execve > hack. The same compiled executable will be usable as a stub for any > (dynamically linkable) Python on (probably) any version of OS X. No > recompilation or mach-o header rewriting required. It should be a lot > nicer to GDB, and measurably quicker to start than the current execve > idiom, and doesn't require compilation like the xcode template options. I apologize for the ignorant question, but could this (maybe?) solve the "one showstopper bug" , the BuildApplet problem on 10.1 as well? Pascal From bob at redivi.com Thu Mar 4 12:54:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 4 13:29:38 2004 Subject: [Pythonmac-SIG] PyMacApp - Flexible Executable Stub For Python In-Reply-To: References: Message-ID: On Mar 4, 2004, at 12:33 PM, Pascal Oberndoerfer wrote: > Bob Ippolito at bob@redivi.com: > >> As part of BundleBuilder2, I'm developing an executable stub for >> Python >> that *does not* link to anything but Cocoa, and does not use the >> execve >> hack. The same compiled executable will be usable as a stub for any >> (dynamically linkable) Python on (probably) any version of OS X. No >> recompilation or mach-o header rewriting required. It should be a lot >> nicer to GDB, and measurably quicker to start than the current execve >> idiom, and doesn't require compilation like the xcode template >> options. > > I apologize for the ignorant question, but could this (maybe?) solve > the > "one showstopper bug" , the > BuildApplet > problem on 10.1 as well? My educated guess would be yes, but someone else will have to take care of that.. I don't have (nor want to have) 10.1 anywhere.. maybe if "MacOnLinux" was ported to OS X, then I would try it :) -bob From sexygrissy at hotmail.com Thu Mar 4 15:51:03 2004 From: sexygrissy at hotmail.com (sexygrissy@hotmail.com) Date: Thu Mar 4 16:11:23 2004 Subject: [Pythonmac-SIG] trust me Message-ID: i saw you last week! -------------- next part -------------- A non-text attachment was scrubbed... Name: concert.zip Type: application/x-zip-compressed Size: 24192 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040304/ac99a313/concert-0001.bin From someone at server.com Thu Mar 4 16:49:06 2004 From: someone at server.com (someone@server.com) Date: Thu Mar 4 16:56:47 2004 Subject: [Pythonmac-SIG] Re: Your website Message-ID: Please read the attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_website.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040304/2bf4656c/your_website.obj From admin at wandb.co.uk Thu Mar 4 16:54:35 2004 From: admin at wandb.co.uk (admin) Date: Thu Mar 4 16:56:49 2004 Subject: [Pythonmac-SIG] Blocked Message Message-ID: This is an automatic message from the Guinevere Internet Antivirus Scanner. A message was received from you with a subject of stolen The message was addressed to kate.bone@wandb.co.uk. The message contains file attachments that are not permitted. You will want to consult with your system administator on how to deal with this. *********************************************************************** Confidentiality: This e-mail message and any attachments may contain confidential and/or legally privileged information. It is intended for the addressee only and if you are not the intended recipient you should not copy or use the contents nor disclose them to anybody else. In such a case please notify the sender by return e-mail immediately and delete this message and its attachments together with all copies in whatever form. Security: In the case of a client contacting White and Bowker by e-mail, White and Bowker will assume that they have the clients' implied consent to communicate (with the client) using e-mail, in the clients full knowledge that e-mail is not a secure mode of communication. Business Use: Any views or opinions expressed in this message (and any attachments) that do not relate to the official business of White & Bowker are neither given nor endorsed by it. Viruses: This e-mail and any attachments has been checked for viruses using Guinevere but White & Bowker accepts no responsibility for any viruses not revealed by such check and in accordance with good computing practice recipients should ensure that they are actually virus free. In case of any query relating to this message or its content please contact the Sender or the System Manager by return e-mail or telephone +44 (0)1962 844440 or by post at White & Bowker 19 St. Peter Street Winchester SO23 8BU United Kingdom *********************************************************************** From judilv at hotmail.com Thu Mar 4 17:16:47 2004 From: judilv at hotmail.com (judilv@hotmail.com) Date: Thu Mar 4 17:32:12 2004 Subject: [Pythonmac-SIG] Re: Your picture Message-ID: See the attached file for details. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_picture.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040304/47026d2c/your_picture-0001.obj From hydrodirect.internet at hydro.qc.ca Thu Mar 4 17:35:08 2004 From: hydrodirect.internet at hydro.qc.ca (hydrodirect.internet@hydro.qc.ca) Date: Thu Mar 4 17:59:28 2004 Subject: [Pythonmac-SIG] Re: Re: Re: Your document Message-ID: Here is the file. -------------- next part -------------- A non-text attachment was scrubbed... Name: document_4351.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040304/62b1c34a/document_4351.obj From bob at redivi.com Thu Mar 4 17:33:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 4 17:59:38 2004 Subject: [Pythonmac-SIG] [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: I've polished off some more things, written documentation (in the email, as reST), and added new features.. today's snapshot is here: http://undefined.org/python/PyMacApp-0.2.tgz And now for your documentation reading pleasure.. ----------------------------------------------- PyMacApp: Flexible Executable Stub For Python ----------------------------------------------- Introduction ------------ PyMacApp is a Cocoa executable stub for Python that accomplishes the following goals: - A single binary can run on OS X 10.1 or later, with no recompilation required under any circumstance. Therefore, bundles can be built on systems without Xcode and/or the SDKs installed. - It must provide helpful and somewhat customizable errors to the user in the form of GUI alert panels. - It must be able to link to one of many possible Python frameworks at runtime. This allows the same executable bundle to run in just about any environment, even if the developer does have to explicitly manage a separate set of extensions per-framework until we resolve linking issues. - It must be able to gracefully handle Python exceptions, because they may prevent the application from starting. - It must not use execve for performance reasons and to ease debugging. - It should be integrated with BundleBuilder2. - It should be integrated with Python/PyObjC Xcode templates in source and/or binary form. - It should consider non-framework builds of Python, but there are no plans to test this scenario. Using PyMacApp -------------- PyMacApp has three required preconditions for use: - PyMacApp must be the CFBundleExecutable for your application according to Info.plist. It is recommended to rename PyMacApp to agree with the name of your application bundle. - A ``PyRuntimeLocations`` key must be added to your Info.plist, it is an ordered array of strings. Here are some examples: - Embedded Python 2.3 runtime, as created by BundleBuilder2's --standalone option. ``@executable_path/../Frameworks/Python.framework/Versions/2.3/Python`` - User-installed Python 2.3 runtime. ``~/Library/Frameworks/Python.framework/Versions/2.3/Python`` - Vendor-installed Python 2.3 runtime, such as the one in OS X 10.3. ``/System/Library/Frameworks/Python.framework/Versions/2.3/Python`` - A main script must be placed in the Resources folder of your application bundle. By default, PyMacApp will first check Info.plist for a ``PyMainFileNames`` key, which should be an array of possible names as strings. If this key is not present, or if no main script is found, then these script names are attempted (in this order): - ``__main__.py``, ``__main__.pyc``, ``__main__.pyo`` - ``__realmain__.py``, ``__realmain__.pyc``, ``__realmain__.pyo`` - ``Main.py``, ``Main.pyc``, ``Main.pyo`` Handling Errors Gracefully -------------------------- PyMacApp offers alert panels for several common errors that can happen. The following errors are low level, and their responses can not be overridden: - The ``PyRuntimeLocations`` key is not present in the Info.plist. - No main script could be located. - A link error occurred when attempting to load the Python runtime or one of its symbols. - The main script exited with an exception, but there was an error acquiring the name of the exception type. In addition to this, several common high level errors can be handled by an error handling script. There is an optional Info.plist key analagous to ``PyMainFileNames`` called ``PyErrorScripts`, and the additional script names attempted are: ``__error__``, ``__error__.py``, and ``__error__.sh``. Note that the script must be executable (chmod +x), or error handling will not work. Also note that the script may be written in any language (with the appropriate "hash-bang" line), or may even be a compiled executable. An error handling script will always receive the user displayable name of the application, such as "PyMacApp" as the first argument. If no other arguments are received, then there was an error locating a suitable Python runtime. Otherwise, the second argument is the name of the Python exception type (e.g. "ImportError") and the third argument is the string value of the exception instance (e.g. "No module named foobar"). The stdout of the script is parsed under the following conditions: - The newline character is '\n' - The first line of output is required, and will be the title of the error dialog (displayed in bold). - Any additional lines of text are optional, and will be the body of the error dialog (not displayed in bold). Additionally, if the last line of the script is in the form ``ERRORURL: http://example.com/detailederror/ View Detailed Error Report`` then the "Open Console" button will be replaced with a "View Detailed Error Report" button that when clicked, will open the user's default web browser to http://example.com/detailederror/. If a title is not provided (just the URL), then the button will be named "Visit Website". It is recommended that this is used to direct a user to instructions on how to solve their problem (i.e. download Python, file a bug, etc.). This is an example ``__error__.sh`` script:: #!/bin/sh if ( test -n "$2" ) ; then echo "$1 Error" echo "An unexpected error has occurred during execution of the main script" echo "" echo "$2: $3" echo "" echo "See the Console for a detailed traceback." else echo "$1 Error" echo "MacPython 2.3 is required to run this application."; echo "ERRORURL: http://homepages.cwi.nl/~jack/macpython/index.html Visit the MacPython Website"; fi Reference --------- PYTHONPATH This environment variable is set to ``"Contents/Resources:Contents/Resources/PyObjC:$PYTHONPATH"`` CFBundleExecutable A required Info.plist key, see "Using PyMacApp" and Apple's documentation. PyRuntimeLocations A required Info.plist key, see "Using PyMacApp". PyExecutableName An optional Info.plist key representing the name of the python executable. It will be merged with the found Python runtime location and will affect sys.executable and sys.prefix. The default, ``python``, is sensible. PyErrorScripts An optional Info.plist key, see "Handling Errors Gracefully". Known Bugs ---------- - It is not currently possible to use a Py_TRACE_REFS Python runtime as the PyObject structure does not have the reference count at the head. It is not obvious how this could be solved. From jtmocha at yahoo.com Thu Mar 4 17:35:06 2004 From: jtmocha at yahoo.com (jtmocha@yahoo.com) Date: Thu Mar 4 18:11:20 2004 Subject: [Pythonmac-SIG] Re: Your bill Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_bill.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040304/d815ead1/your_bill.obj From hengist.podd at virgin.net Thu Mar 4 16:24:45 2004 From: hengist.podd at virgin.net (has) Date: Thu Mar 4 18:23:54 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <404632A3.4090503@noaa.gov> References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> <404632A3.4090503@noaa.gov> Message-ID: Chris Barker wrote: >>2. How big a deal is the compiler dependency on OS X? I realise it >>was a non-starter for OS9, but OS X provides the BSD layer [as >>standard??] which includes a ready-to-use gcc compiler. > >I think you only get that if you have the developer tools installed, >and a lot of people don't. I checked this, and you're right: gcc is installed with the developer tools, not the BSD layer. Thanks for the correction. has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Mar 4 18:59:02 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 4 18:55:43 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> <404632A3.4090503@noaa.gov> Message-ID: On Mar 4, 2004, at 4:24 PM, has wrote: > Chris Barker wrote: > >>> 2. How big a deal is the compiler dependency on OS X? I realise it >>> was a non-starter for OS9, but OS X provides the BSD layer [as >>> standard??] which includes a ready-to-use gcc compiler. >> >> I think you only get that if you have the developer tools installed, >> and a lot of people don't. > > I checked this, and you're right: gcc is installed with the developer > tools, not the BSD layer. Thanks for the correction. A standard installation of Mac OS X has absolutely no GPL'ed software whatsoever (AFAIK). They save the licensing headaches for OS X Server and Developer Tools :) -bob From halloleo at fusemail.com Thu Mar 4 23:32:15 2004 From: halloleo at fusemail.com (halloleo@fusemail.com) Date: Thu Mar 4 23:31:58 2004 Subject: [Pythonmac-SIG] in emacs calling python from a shell buffer doesn't make input/output. Message-ID: <001801c4026a$d78bf880$a800000a@Odyssey.local> hi there i'm running python 2.3.3 on on my panther imac and at work on cygwin-windows. on both systems, i can create a shell buffer and it works as expected: it accepts input processes and on RET shows the output in the buffer, etc... however when i call python interactivly in this shell buffer it doesn't accept any input and therefore doesn't do any output at all -- until i kill the shell with C-c C-d: then python processes all the input characters i have typed, writes its output to the buffer and quits. after that the shell quits obviously as well. so, python works kind of correct, but the input/output transfer to the buffer is not done interactivly. any clue? thanks, leo From ghoover19 at cox.net Fri Mar 5 01:59:04 2004 From: ghoover19 at cox.net (Greg Hoover) Date: Fri Mar 5 02:01:46 2004 Subject: [Pythonmac-SIG] building C extension modules with frameworks Message-ID: <96CA1DD2-6E72-11D8-BEC8-003065A6DED8@cox.net> Could someone explain the process of building extension modules that require OS X frameworks please? I've tried using the distutils build script, but this fails to supply the correct arguments to ld. Running ld manually fails with undefined symbol dyld_stub_binding_helper. Thanks in advance. --Greg From bob at redivi.com Fri Mar 5 02:33:16 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 02:31:14 2004 Subject: [Pythonmac-SIG] building C extension modules with frameworks In-Reply-To: <96CA1DD2-6E72-11D8-BEC8-003065A6DED8@cox.net> References: <96CA1DD2-6E72-11D8-BEC8-003065A6DED8@cox.net> Message-ID: <5E9F2EB2-6E77-11D8-90DC-000A95686CD8@redivi.com> On Mar 5, 2004, at 1:59 AM, Greg Hoover wrote: > Could someone explain the process of building extension modules that > require OS X frameworks please? > > I've tried using the distutils build script, but this fails to supply > the correct arguments to ld. > Running ld manually fails with undefined symbol > dyld_stub_binding_helper. extra_link_args = ['-framework', 'FrameworkName'] in the Extension(...). There are many examples of this 'in the wild', including in the Python sources... If this doesn't work for you, then please be more explicit about what your problem is... which framework you're linking to, what sort of extension you're building, the Extension(...) in your distutils script, the actual linker error, Python version, OS X version, etc. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040305/b028bec3/smime.bin From ravms at mbox.ifoa.it Fri Mar 5 03:34:11 2004 From: ravms at mbox.ifoa.it (ravms@mbox.ifoa.it) Date: Fri Mar 5 03:31:17 2004 Subject: [Pythonmac-SIG] RAVAntiVirus risultati della scansione Message-ID: <20040305083411.07DE913B23@mbox.ifoa.it> RAV AntiVirus for Linux i686 version: 8.3.2 (snapshot-20020108) Copyright (c) 1996-2001 GeCAD The Software Company. All rights reserved. Registered version for 2 domain(s). Running on host: mbox.ifoa.it ----------------------- RAV Antivirus results -----------------------Il file è stato copiato in quarantena con il nome: 1078475650-RAV30494.Il file (part0001:bill.zip)->bill.scr in allegato alla mail (con oggetto:hello) inviato da pythonmac-sig@python.org a orlandini@ifoa.it, è infetto dal virus: Win32/Netsky.B@mm.Impossibile riparare questo file.Impossibile eliminare questo file (probabilmente è un archivio).Questa mail non è stata consegnata perchè contenteva codice sospetto.------------------------ this is a copy of the e-mail header: Received: from ifoa.it (host227-134.pool8289.interbusiness.it [82.89.134.227]) Scan engine 8.11 () for i386. Last update: Fri Mar 5 02:05:17 2004 Scanning for 92940 malwares (viruses, trojans and worms). To get a free 60-days evaluation version of RAV AntiVirus v8 (yet fully functional) please visit: http://www.ravantivirus.com From ghoover19 at cox.net Fri Mar 5 04:24:32 2004 From: ghoover19 at cox.net (Greg Hoover) Date: Fri Mar 5 04:27:20 2004 Subject: [Pythonmac-SIG] Passing tuples to C Message-ID: I'm trying to pass multiple values to a C function. As far as I know, this is done using tuples. Is there anything special required on the python side to pass this tuple? This is the C function being called. It is in a module called serial. So I've tried calling serial.serial_write((1, "q")) serial.serial_write(1, "q") serial.serial_write([1, "q"]) --- all of which fail. Several report that they require integer arguments, other errors specify that only 1 argument is accepted. static PyObject * serial_write(PyObject *self, PyObject *args) { int numCharsToSend; char *writeBuffer; if(serialPortFileDescriptor < 0) return Py_BuildValue("i", -1); // Python provides storage for string if(!PyArg_ParseTuple(args, "is", &numCharsToSend, &writeBuffer)) return NULL; write(serialPortFileDescriptor, writeBuffer, numCharsToSend); return Py_BuildValue("i", numCharsToSend); } Thanks in advance. --Greg Hoover -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1643 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040305/be76c29f/attachment.bin From mark.asbach at post.rwth-aachen.de Fri Mar 5 09:27:07 2004 From: mark.asbach at post.rwth-aachen.de (Mark Asbach) Date: Fri Mar 5 09:28:06 2004 Subject: [Pythonmac-SIG] autoconf and distutils Message-ID: <2E742F17-6EB1-11D8-86EA-000393449862@post.rwth-aachen.de> Hi list, we're trying to port an open source application that includes an embedded python interpreter. I've still got troubles with the Mac OS X specific framework builds and my autoconf script. What can I do to get information on compiler and linker parameters necessary to compile my custom interpreter? On conventional UNIX installs I will need "-L/usr/local/lib/python2.x/config -lpython2.x" while I have to use "-framework Python" with framework builds. It's messy to search paths and guess from the files present, which one is the case. Unfortunately, I couldn't find detailed documentation of the distutils, where I would search for information like this. The best solution would be a set of python scripts that would give the desired flags for the interpreter it is run on. This way I could provide a "--with-python=/mypath/bin/pythonX.Y" configuration option and have the rest detected automatically. Thanks in advance, Mark From bob at redivi.com Fri Mar 5 10:43:35 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 10:40:09 2004 Subject: [Pythonmac-SIG] autoconf and distutils In-Reply-To: <2E742F17-6EB1-11D8-86EA-000393449862@post.rwth-aachen.de> References: <2E742F17-6EB1-11D8-86EA-000393449862@post.rwth-aachen.de> Message-ID: On Mar 5, 2004, at 9:27 AM, Mark Asbach wrote: > we're trying to port an open source application that includes an > embedded python interpreter. I've still got troubles with the Mac OS X > specific framework builds and my autoconf script. > > What can I do to get information on compiler and linker parameters > necessary to compile my custom interpreter? On conventional UNIX > installs I will need "-L/usr/local/lib/python2.x/config -lpython2.x" > while I have to use "-framework Python" with framework builds. It's > messy to search paths and guess from the files present, which one is > the case. Unfortunately, I couldn't find detailed documentation of the > distutils, where I would search for information like this. > > The best solution would be a set of python scripts that would give the > desired flags for the interpreter it is run on. This way I could > provide a "--with-python=/mypath/bin/pythonX.Y" configuration option > and have the rest detected automatically. grep "^LINKFORSHARED" `python -c "import sys;print '%s/lib/python%d.%d/config/Makefile' % (sys.prefix,sys.version_info[0], sys.version_info[1])"` | cut -d = -f 2 distutils probably has a better way for getting at this, though :) -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040305/fdec1698/smime.bin From Chris.Barker at noaa.gov Fri Mar 5 12:10:33 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Mar 5 12:12:09 2004 Subject: [Pythonmac-SIG] Passing tuples to C In-Reply-To: References: Message-ID: <4048B489.5000206@noaa.gov> Greg Hoover wrote: > I'm trying to pass multiple values to a C function. As far as I know, > this is done using tuples. Is there anything special required on the > python side to pass this tuple? nope, python ALWAYS uses a tuple to pass arguments to a function. For example: Afunc(a,b,c) is passing the tuple: (a,b,c) to Afunc. If the function is written in Python, the tule is unpacked automagically. If your function ius is C, you need to unpack it yourself. > This is the C function being called. It is in a module called serial. So > I've tried calling serial.serial_write((1, "q")) >serial.serial_write(1, "q") This one ought to work. > // Python provides storage for string > if(!PyArg_ParseTuple(args, "is", &numCharsToSend, &writeBuffer)) you are asking for two arguments, and integer and a string What happens when you try the above? -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 rowen at cesmail.net Fri Mar 5 12:19:23 2004 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Mar 5 12:19:46 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: In article , Bob Ippolito wrote: >... > PyMacApp is a Cocoa executable stub for Python that accomplishes the > following > goals: > > - A single binary can run on OS X 10.1 or later, with no recompilation > required under any circumstance. Therefore, bundles can be built on > systems > without Xcode and/or the SDKs installed... Just to confirm or deny...does this mean one can build an application bundle on Panther with --standalone, incorporate PyMacApp and get an application that works under, say, Jaguar? if so, wow! (If not, might you explain the quoted paragraph in different words?) The error reporting sounds like a wonderful thing. Being 0.2, I assume it's worth testing but not smart to use for production code? Or is it the case that *if* the resulting app works then it's fine to release it? -- Russell From bob at redivi.com Fri Mar 5 12:31:17 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 12:27:54 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: On Mar 5, 2004, at 12:19 PM, Russell E. Owen wrote: > In article , > Bob Ippolito wrote: > >> ... >> PyMacApp is a Cocoa executable stub for Python that accomplishes the >> following >> goals: >> >> - A single binary can run on OS X 10.1 or later, with no recompilation >> required under any circumstance. Therefore, bundles can be built >> on >> systems >> without Xcode and/or the SDKs installed... > > Just to confirm or deny...does this mean one can build an application > bundle on Panther with --standalone, incorporate PyMacApp and get an > application that works under, say, Jaguar? if so, wow! (If not, might > you explain the quoted paragraph in different words?) --standalone with the stock Python 2.3.0 Python that comes with Panther will NEVER EVER EVER EVER EVER WORK ON JAGUAR. It was compiled against things that were not available back then. Period, won't work, ever, nomatter what. One could build an application on Panther with a Python 2.3.x that was *very carefully* built to ensure 10.1+ or 10.2+ compatibility, but that's beyond the scope of what I'm trying to do right now. If you had such a Python environment already, it would work. > The error reporting sounds like a wonderful thing. > > Being 0.2, I assume it's worth testing but not smart to use for > production code? Or is it the case that *if* the resulting app works > then it's fine to release it? If it works, go for it. BundleBuilder2 will support it relatively soon. -bob From dp at ulaluma.com Fri Mar 5 12:38:01 2004 From: dp at ulaluma.com (Donovan Preston) Date: Fri Mar 5 12:38:19 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: On Mar 5, 2004, at 12:31 PM, Bob Ippolito wrote: > One could build an application on Panther with a Python 2.3.x that was > *very carefully* built to ensure 10.1+ or 10.2+ compatibility, but > that's beyond the scope of what I'm trying to do right now. If you > had such a Python environment already, it would work. Couldn't you just include a 2.3.x framework in the bundle? Isn't that one of the points of this? Or are you saying the 2.3.x framework build would have to be built carefully in order to work on 10.1 or 10.2? dp From bob at redivi.com Fri Mar 5 12:46:35 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 12:43:14 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: <0C090C16-6ECD-11D8-90DC-000A95686CD8@redivi.com> On Mar 5, 2004, at 12:31 PM, Russell E Owen wrote: >> On Mar 5, 2004, at 12:19 PM, Russell E. Owen wrote: >> >>> In article , >>> Bob Ippolito wrote: >>> >>>> ... >>>> PyMacApp is a Cocoa executable stub for Python that accomplishes >>>> the >>>> following >>>> goals: >>>> >>>> - A single binary can run on OS X 10.1 or later, with no >>>> recompilation >>>> required under any circumstance. Therefore, bundles can be >>>> built on >>>> systems >>>> without Xcode and/or the SDKs installed... >>> >>> Just to confirm or deny...does this mean one can build an >>> application >>> bundle on Panther with --standalone, incorporate PyMacApp and get an >>> application that works under, say, Jaguar? if so, wow! (If not, >>> might >>> you explain the quoted paragraph in different words?) >> >> --standalone with the stock Python 2.3.0 Python that comes with >> Panther will NEVER EVER EVER EVER EVER WORK ON JAGUAR. It was >> compiled against things that were not available back then. Period, >> won't work, ever, nomatter what. >> >> One could build an application on Panther with a Python 2.3.x that >> was *very carefully* built to ensure 10.1+ or 10.2+ compatibility, >> but that's beyond the scope of what I'm trying to do right now. If >> you had such a Python environment already, it would work. > > Yeah, I rather figured that. That's why I tried to word my question so > carefully. So...what is the main point of PyMacApp (if there is one > beyond the error reporting), or of at least that first paragraph? Some of the realistic advantages of the PyMacApp approach (including, but not limited to..): - It makes it reasonable to distribute applications that *do not* include Python or extension modules, because you can give a friendly error message if it's not there, of if PyObjC is not present. The __error__ script could determine exactly what the user needs, and present instructions, or give them the option to go to a webpage with instructions. - In the future, when things are linked properly (possibly soon, definitely by 10.4), --semi-standalone applications will be portable across python interpreters of the same major version. This requires a linking feature available only in OS X 10.3 and later, and MAY NOT be compatible with the vendor Python 2.3.0 (but, in theory, it probably will be, so long as the extensions are linked properly). - In theory, in the near future, you will be able make a working "multi-python" --semi-standalone, that includes a different set of compiled extensions per-python-version (i.e. MacPython 2.3 for Jaguar, and vendor Python 2.3.0 for Panther). Your bootstrap __main__ would have to handle the details of this. Sort of hard to do in practice, because you would need a sort of MetaBundleBuilder that makes multiple pythons cooperate in building a single bundle... or maybe just an intelligent bundle-merge tool. -bob From oussoren at cistron.nl Fri Mar 5 12:45:40 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Mar 5 12:45:26 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: On 5-mrt-04, at 18:38, Donovan Preston wrote: > > On Mar 5, 2004, at 12:31 PM, Bob Ippolito wrote: > >> One could build an application on Panther with a Python 2.3.x that >> was *very carefully* built to ensure 10.1+ or 10.2+ compatibility, >> but that's beyond the scope of what I'm trying to do right now. If >> you had such a Python environment already, it would work. > > Couldn't you just include a 2.3.x framework in the bundle? Isn't that > one of the points of this? Or are you saying the 2.3.x framework build > would have to be built carefully in order to work on 10.1 or 10.2? I think the problem is in the framework itself, it is very hard to build extension modules when you have two Python.frameworks on your machine. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From bob at redivi.com Fri Mar 5 12:51:53 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 12:48:27 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: On Mar 5, 2004, at 12:38 PM, Donovan Preston wrote: > > On Mar 5, 2004, at 12:31 PM, Bob Ippolito wrote: > >> One could build an application on Panther with a Python 2.3.x that >> was *very carefully* built to ensure 10.1+ or 10.2+ compatibility, >> but that's beyond the scope of what I'm trying to do right now. If >> you had such a Python environment already, it would work. > > Couldn't you just include a 2.3.x framework in the bundle? Isn't that > one of the points of this? Or are you saying the 2.3.x framework build > would have to be built carefully in order to work on 10.1 or 10.2? The 2.3.x framework build *and any extensions you use* would have to be built carefully in order to work on 10.1 and/or 10.2. By default, any extension you compile on 10.3 *may not* work on an earlier version of OS X, even if the Python framework itself is compatible with earlier versions of the OS. Building backwards compatible things requires a complicated and carefully configured development environment, and I am relatively certain that nobody has yet gone through the trouble to set it up for building Python extensions. I have a pretty good idea of how exactly to do it -- however, I have more pressing issues to tackle right now, like making things work smoothly on the *current* version of OS X. If someone were to say, pay for me to do it, I would shift my priorities a bit... but right now I have very little sympathy for people who run or need to support non-current versions of OS X. -bob From bob at redivi.com Fri Mar 5 13:07:41 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 13:04:15 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: On Mar 5, 2004, at 12:45 PM, Ronald Oussoren wrote: > > On 5-mrt-04, at 18:38, Donovan Preston wrote: > >> >> On Mar 5, 2004, at 12:31 PM, Bob Ippolito wrote: >> >>> One could build an application on Panther with a Python 2.3.x that >>> was *very carefully* built to ensure 10.1+ or 10.2+ compatibility, >>> but that's beyond the scope of what I'm trying to do right now. If >>> you had such a Python environment already, it would work. >> >> Couldn't you just include a 2.3.x framework in the bundle? Isn't that >> one of the points of this? Or are you saying the 2.3.x framework >> build would have to be built carefully in order to work on 10.1 or >> 10.2? > > I think the problem is in the framework itself, it is very hard to > build extension modules when you have two Python.frameworks on your > machine. And if you did, it's entirely possible that the extension module itself would not be compatible with a previous version of OS X, even if the framework is. actually, in theory, building extension modules works just fine -- so long as the version of Python you are building for is found first in framework search order.. this means that: If you have a ~/Library Python installed, then YOU CAN NOT properly build extensions for /Library, /Network/Library, or /System/Library Python! If you have a /Library Python installed, then YOU CAN NOT properly build extensions for /Network/Library, or /System/Library Python! If you have a /Network/Library Python installed, then YOU CAN NOT properly build extensions for /System/Library Python! Otherwise, you only have a /System/Library Python, or no Python (2.2.0 on Jaguar is a bug, not a Python) at all.. and things work about as well as you'd expect them to, respectively :) This is basically two bugs in Python, not necessarily in OS X, but it is a shame that -undefined dynamic_lookup is not backwards compatible: (1) Python is linked without -undefined dynamic_lookup, so the resulting module is ONLY compatible with the Python.framework that it ends up linking to (2) The Python.framework it links to is the first one found, in the order above, and is not in any way influenced by the Python.framework that the Python interpreter itself was linked with (oops!) In Python CVS, I believe (2) has been "fixed" by injecting -F/Somewhere, but that can theoretically have ill effects on other frameworks if there are multiple ones installed and the original search order was desired. If (1) is fixed, then extensions don't link directly to Python at all, but then they are not compatible with any version of OS X prior to 10.3. (2) Could be fixed in a different way by linking to the Python.framework/Versions/2.3/Python MH_DYLIB directly (as in, without -l or -framework at all) instead of using GCC's "hey, let me find the wrong one for you" features. -bob From bob at redivi.com Fri Mar 5 13:18:21 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 13:14:55 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: <7C1C7CF9-6ED1-11D8-90DC-000A95686CD8@redivi.com> On Mar 5, 2004, at 1:07 PM, Bob Ippolito wrote: > (1) Python is linked without -undefined dynamic_lookup, so the > resulting module is ONLY compatible with the Python.framework that it > ends up linking to Correction: (1) Python extensions are linked without... From ghoover19 at cox.net Fri Mar 5 15:01:11 2004 From: ghoover19 at cox.net (Greg Hoover) Date: Fri Mar 5 15:03:54 2004 Subject: [Pythonmac-SIG] character buffer Message-ID: How do you create character buffers in Python? I'm trying to send data to a native function using the "t#" ParseTuple type. Thank you. --Greg From bob at redivi.com Fri Mar 5 15:20:38 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 15:17:11 2004 Subject: [Pythonmac-SIG] character buffer In-Reply-To: References: Message-ID: <915B96D8-6EE2-11D8-90DC-000A95686CD8@redivi.com> On Mar 5, 2004, at 3:01 PM, Greg Hoover wrote: > How do you create character buffers in Python? I'm trying to send > data to a native function using the "t#" ParseTuple type. These questions are probably better asked on another one of the Python lists, or the comp.lang.python newsgroup. The Python C API is not Macintosh specific, and the problems you're experiencing (whatever they are, you really aren't giving a whole lot of detail) are not platform specific either. Python is open source, and clearly there are parts of python that do what you're trying to do (for example, the socket module probably does), so you can just look at that. Just a hunch, but it sure sounds like what you're trying to do is already possible in some other way (not writing an extension in C). For example, if you're talking to serial ports, that can be done through file descriptors (i.e.: open('/dev/something')) and is all of the nasty bits are abstracted by PySerial or the like. I've written pure python code that talks to serial devices on win32/linux/osx/jython, and I have never had to dig into C because other people had already done it (win32) or you can do it using standard means (/dev files). -bob From chiarimenti at eurotoscar.it Fri Mar 5 16:25:58 2004 From: chiarimenti at eurotoscar.it (MailMax Auto Responder) Date: Fri Mar 5 16:14:59 2004 Subject: [Pythonmac-SIG] Chiarimenti prenotazione Message-ID: <200403052114.i25LEsWx026433@mxzilla8.xs4all.nl> La vostra richiesta di chiarimenti è stata correttamente ricevuta, sarete ricontattati al più presto. Cordiali saluti Eurotoscar srl From ghoover19 at cox.net Fri Mar 5 19:44:54 2004 From: ghoover19 at cox.net (Greg Hoover) Date: Fri Mar 5 19:47:39 2004 Subject: [Pythonmac-SIG] Timers Message-ID: <7C3297C5-6F07-11D8-BEC8-003065A6DED8@cox.net> This may not be mac-specific, but I'm having trouble using Timer from the thread module. From the python documentation it seems like importing the thread module is all that is required. from thread import * but any use of t = Thread(3, foo) fails. additionally, from thread import Timer fails Are there additional requirements? Thanks in advance. --Greg From bob at redivi.com Fri Mar 5 20:38:49 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 5 20:35:27 2004 Subject: [Pythonmac-SIG] Timers In-Reply-To: <7C3297C5-6F07-11D8-BEC8-003065A6DED8@cox.net> References: <7C3297C5-6F07-11D8-BEC8-003065A6DED8@cox.net> Message-ID: <04240DDE-6F0F-11D8-90B9-000A95686CD8@redivi.com> On Mar 5, 2004, at 7:44 PM, Greg Hoover wrote: > This may not be mac-specific, but I'm having trouble using Timer from > the thread module. From the python documentation it seems like > importing the thread module is all that is required. > > from thread import * > > but any use of t = Thread(3, foo) fails. > > additionally, from thread import Timer fails > > Are there additional requirements? Fails *how*, with what error? Are you sure you don't mean the *threading* module? -bob From mlist at unicornwest.org Sat Mar 6 01:12:53 2004 From: mlist at unicornwest.org (Mailing List) Date: Sat Mar 6 01:13:33 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? Message-ID: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> Should a pyc file created on my Panther Mac run on other platforms? My initial observations are that it won't, is this correct or am I just doing something wrong? From bob at redivi.com Sat Mar 6 01:28:54 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 6 01:25:35 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? In-Reply-To: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> References: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> Message-ID: <8A8B7553-6F37-11D8-8E4E-000A95686CD8@redivi.com> On Mar 6, 2004, at 1:12 AM, Mailing List wrote: > Should a pyc file created on my Panther Mac run on other platforms? > My initial observations are that it won't, is this correct or am I > just doing something wrong? pyc files are definitely specific to the version of Python that produced them, though I believe that the bytecodes don't change very often (at all?) between minor releases. I don't believe that the platform is a factor. The way you asked this question is incorrect though, you really need to state more information (such as platform(s), python version(s), exception(s) raised, etc.) when you say something like "it doesn't work" or "am I doing something wrong". -bob From mdehoon at ims.u-tokyo.ac.jp Sat Mar 6 06:17:40 2004 From: mdehoon at ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon) Date: Sat Mar 6 06:18:19 2004 Subject: [Pythonmac-SIG] Pygist native on Mac OS X Message-ID: <4049B354.9050105@ims.u-tokyo.ac.jp> Dear Mac-Pythoneers, Recently we created a Mac OS X native (Quartz) version of Pygist, a scientific plotting package for Python. The source code is available at http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/index.html under "Scientific plotting with Pygist" on the left. See the instructions there for how to install this on Mac OS X using a framework version of Python. Note the setup.py script of Pygist can serve as an example of how to compile Python C extensions that use the Cocoa or Carbon frameworks, and how to use "python setup.py config" as a replacement of autoconf/automake to get some system information. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon From akoffers at adknownetwork.com Sat Mar 6 09:27:44 2004 From: akoffers at adknownetwork.com (akoffers@adknownetwork.com) Date: Sat Mar 6 09:27:50 2004 Subject: [Pythonmac-SIG] information Message-ID: i hope it is not true! -------------- next part -------------- A non-text attachment was scrubbed... Name: mail2.zip Type: application/x-zip-compressed Size: 22132 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040306/807c852e/mail2-0001.bin From altis at semi-retired.com Sat Mar 6 13:23:01 2004 From: altis at semi-retired.com (Kevin Altis) Date: Sat Mar 6 13:23:05 2004 Subject: [Pythonmac-SIG] ZODB standalone on Mac OS X? Message-ID: <4D372AB4-6F9B-11D8-8110-000A9598382A@semi-retired.com> I don't have an urgent need for ZODB right now, but I was wondering if anyone was working on making a standalone ZODB package for PackMan? http://zope.org/Products/ZODB3.2 The latest version of ZODB indicates that it requires Python 2.3.3, and I'm not sure what the dependencies are, so this may be problematic on Mac OS X (Panther) with Python 2.3.0. ka From bob at redivi.com Sat Mar 6 14:12:07 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 6 14:08:44 2004 Subject: [Pythonmac-SIG] ZODB standalone on Mac OS X? In-Reply-To: <4D372AB4-6F9B-11D8-8110-000A9598382A@semi-retired.com> References: <4D372AB4-6F9B-11D8-8110-000A9598382A@semi-retired.com> Message-ID: <294826CB-6FA2-11D8-8E4E-000A95686CD8@redivi.com> On Mar 6, 2004, at 1:23 PM, Kevin Altis wrote: > I don't have an urgent need for ZODB right now, but I was wondering if > anyone was working on making a standalone ZODB package for PackMan? > > http://zope.org/Products/ZODB3.2 > > The latest version of ZODB indicates that it requires Python 2.3.3, > and I'm not sure what the dependencies are, so this may be problematic > on Mac OS X (Panther) with Python 2.3.0. I've been using newer (unstable) versions of ZODB 3.3, and have seen no problems with Python 2.3.0 yet. When 3.3 is (more) stable, I'll package it, but I have no need for 3.2. -bob From altis at semi-retired.com Sat Mar 6 14:47:10 2004 From: altis at semi-retired.com (Kevin Altis) Date: Sat Mar 6 14:47:17 2004 Subject: [Pythonmac-SIG] which SOAP library to use? Message-ID: <0EE81303-6FA7-11D8-8110-000A9598382A@semi-retired.com> The last version of SOAP.py I used came from Mark Pilgrim's pygoogle, and that version still works fine for client SOAP calls. I got the latest version from http://sourceforge.net/project/showfiles.php?group_id=99616 which is now maintained by Brian Landers. Another possibility is the SOAPpy package which is part of the pywebsvcs project on SF, but I don't have any experience with the package or the myriad dependencies it has and so I'm wondering if it is preferred for SOAP work in Python these days? http://sourceforge.net/project/showfiles.php? group_id=26590&package_id=18246 In case anyone wonders why I'm asking about libs it is because I'm going through all the PythonCard samples that have external-lib dependencies and trying to update the required lib info and at the same time making sure the samples will run on the Mac. Next stop, jabber.py ka From Symantec_AntiVirus_for_SMTP_Gateways at wpafb.af.mil Sat Mar 6 16:21:20 2004 From: Symantec_AntiVirus_for_SMTP_Gateways at wpafb.af.mil (Symantec_AntiVirus_for_SMTP_Gateways@wpafb.af.mil) Date: Sat Mar 6 16:21:28 2004 Subject: [Pythonmac-SIG] Content violation Message-ID: <200403062121.i26LLJP02034@mvs3.wpafb.af.mil> Content violation found in email message. From: pythonmac-sig@python.org To: patricia.sullivan2@wpafb.af.mil File(s): letter.pif Matching filename: *.pif From edward.kaye.smid at sasktel.net Sat Mar 6 18:03:34 2004 From: edward.kaye.smid at sasktel.net (edward.kaye.smid@sasktel.net) Date: Sat Mar 6 18:03:39 2004 Subject: [Pythonmac-SIG] notification Message-ID: wrong calculation! (see the attachment!) -------------- next part -------------- A non-text attachment was scrubbed... Name: trash.zip Type: application/x-zip-compressed Size: 25469 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040306/f2dd404b/trash-0001.bin From zerofps at optusnet.com.au Sun Mar 7 03:59:01 2004 From: zerofps at optusnet.com.au (Nathan) Date: Sun Mar 7 03:59:11 2004 Subject: [Pythonmac-SIG] RE: Your music In-Reply-To: <200403070746.i277k4u15042@mail005.syd.optusnet.com.au> Message-ID: <000401c40422$6f7cb720$2500a8c0@mental> You're an idiot -----Original Message----- From: pythonmac-sig@python.org [mailto:pythonmac-sig@python.org] Sent: Sunday, March 07, 2004 5:46 PM To: zerofps@optusnet.com.au Subject: Re: Your music Please read the attached file. From tjrchka at nyc.rr.com Sun Mar 7 06:14:31 2004 From: tjrchka at nyc.rr.com (TJR) Date: Sun Mar 7 06:14:37 2004 Subject: [Pythonmac-SIG] (no subject) Message-ID: <9B8C185E-7028-11D8-BC1D-00039358C2B0@nyc.rr.com> I have OSX 10.3.2, I had the python that was installed but before 10.3 I had 10.2.8 with which I installed python, then I installed Panther (10.3). Sorry, for being so redundant, but I was using a program which requires Python (BitPim), and I felt it was having problems, so I tried to delete the Python files, figuring I could just reinstall it, I installed the package for Jaguar, but BitPim doesn't seem to be working at all now, no start up. How do I get back to Python 2.3, and then bring it to 2.3.3? Any help would be appreciated, TJ From tschip at interlog.com Sun Mar 7 12:28:27 2004 From: tschip at interlog.com (Terry and Stacey Schipper) Date: Sun Mar 7 12:28:50 2004 Subject: [Pythonmac-SIG] Re: Your text In-Reply-To: References: Message-ID: <6.0.0.22.0.20040307122818.01b4f288@mail.interlog.com> your virus was attached At 3/7/2004 07:46 AM, you wrote: >Your document is attached. From fr20000485f at hotmail.com Sun Mar 7 16:05:27 2004 From: fr20000485f at hotmail.com (fr20000485f@hotmail.com) Date: Sun Mar 7 16:06:05 2004 Subject: [Pythonmac-SIG] trust me Message-ID: is that your privacy? -------------- next part -------------- A non-text attachment was scrubbed... Name: sexual.zip Type: application/x-zip-compressed Size: 25479 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040307/e676e2a9/sexual-0001.bin From halloleo at fusemail.com Mon Mar 8 01:52:05 2004 From: halloleo at fusemail.com (halloleo@fusemail.com) Date: Mon Mar 8 01:51:47 2004 Subject: [Pythonmac-SIG] where to find the documentation installed with Packman? Message-ID: <002d01c404d9$df881bb0$a800000a@Odyssey.local> hi there on panther i have installed the macpython addons and tried to install the doc2.3-bin package. seems to work beacuse now in the packman list appears a "tes".;-) but i can't find the doc inthe help viewer. so, where do i find it? aaah, and another one about the addons: do they need to reside in /applications or can i put them without trouble deeper in a subdir? thanks, leo From bob at redivi.com Mon Mar 8 06:27:23 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 8 06:23:58 2004 Subject: [Pythonmac-SIG] where to find the documentation installed with Packman? In-Reply-To: <002d01c404d9$df881bb0$a800000a@Odyssey.local> References: <002d01c404d9$df881bb0$a800000a@Odyssey.local> Message-ID: <921340A8-70F3-11D8-8E4E-000A95686CD8@redivi.com> On Mar 8, 2004, at 1:52 AM, wrote: > hi there > > on panther i have installed the macpython addons and tried to install > the > doc2.3-bin package. seems to work beacuse now in the packman list > appears a > "tes".;-) > > but i can't find the doc inthe help viewer. so, where do i find it? from http://pythonmac.org/wiki/FAQ The MacPython Help or Python Documentation does not show up in Help Viewer The documentation is not registered until you run the IDE at least once after installing. If you did run the IDE but the documentation still does not show up try removing the file ~/Library/Preferences/com.apple.help.plist. This will make the Help Viewer forget all documentation, but it will be filled in again when you run the respective programs (such as the IDE for the MacPython documentation). > aaah, and another one about the addons: do they need to reside in > /applications or can i put them without trouble deeper in a subdir? That location is fixed. You should not move it. Most of the tools will work if moved, but some of them won't (for example, PackageManager will no longer detect that you have the addons installed). -bob From mwh at python.net Mon Mar 8 08:01:53 2004 From: mwh at python.net (Michael Hudson) Date: Mon Mar 8 08:02:00 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? In-Reply-To: <8A8B7553-6F37-11D8-8E4E-000A95686CD8@redivi.com> (Bob Ippolito's message of "Sat, 6 Mar 2004 01:28:54 -0500") References: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> <8A8B7553-6F37-11D8-8E4E-000A95686CD8@redivi.com> Message-ID: <2mwu5vze4e.fsf@starship.python.net> Bob Ippolito writes: > On Mar 6, 2004, at 1:12 AM, Mailing List wrote: > >> Should a pyc file created on my Panther Mac run on other platforms? >> My initial observations are that it won't, is this correct or am I >> just doing something wrong? > > pyc files are definitely specific to the version of Python that > produced them, though I believe that the bytecodes don't change very > often (at all?) between minor releases. Bytecode from 2.Y.Z is compatible with bytecode from 2.Y.W. This has sometimes been painful to acheive, but it's a serious goal. Bytecode from 2.Y is NOT compatible with bytecode 2.Z. We don't try to make it incompatible, but we always seem to find some reason to do it :-) > I don't believe that the platform is a factor. It isn't. marshal goes to some pain to be platform independent. Cheers, mwh -- ZAPHOD: You know what I'm thinking? FORD: No. ZAPHOD: Neither do I. Frightening isn't it? -- The Hitch-Hikers Guide to the Galaxy, Episode 11 From hengist.podd at virgin.net Mon Mar 8 11:01:36 2004 From: hengist.podd at virgin.net (has) Date: Mon Mar 8 12:54:15 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> Message-ID: Bob wrote: >>I've been compiling the modules that I've needed; so you could say >>they're the 'right' ones for me. And my environment is straight out >>of the box; I'm not smart enough to modify it, and therefore not >>smart enough to break it either. :) > >Yes, and that's fine, but many of the modules I offer are ones that >people can't compile on their own without some serious hand holding. >I'd rather just give it to them in binary form than hold everyone's >hand. I'd rather code than do tech support.. :) Appreciated, and I have no absolutely problem with binaries being provided for greater convenience. However, it's important that the binary is supplied in addition to a source distribution - not as a substitute for it. Otherwise you're creating lock-in for users. Given the choice between some initial inconvenience in having to build a module myself or not being able to use it at all? I opt for the former. (Recent example: I needed Jack's LaunchServices module for the new version of appscript, but the only version readily available was a 10.3 binary. In the end, I had to track down the source files and write a working setup.py script to install it myself.) So, at minimum there should always be a source distro available. Additional binaries are optional. Handholding on source distros is also optional: nobody's _obliging_ you to do that. By all means supply the binaries on a strictly unsupported basis. What matters is that the choice belongs to the end user; you shouldn't make it for them. When I talk about PM's "policy" being flawed, this is partly what I mean. It puts too much responsibility/control in the developer's hands, and not enough in the users'. >>First, the reason for asking these questions is that I already >>realise PM has been designed to handle the worst-case >>installations; however, in doing so it's completely dropped the >>ball on light-to-average installations. > >I think you have the wrong impression here. PM is certainly not >designed to handle worst-case installations. Worst-case as in complexity, not brittleness. >I would say the opposite, it is designed to handle only best-case >situations, and isn't capable of dealing with much deviation without >kicking, screaming, and possible explosion. Nothing wrong in demanding correctness, as long as achieving that correctness isn't too onerous a task. (e.g. See arguments over strict vs. liberal parsing for the Atom syndication format. If it's unreasonable to expect Atom users to produce well-formed output, then perhaps the problem is with the output format being too damn complex in the first place. In this case, dumping XML for a simple plaintext format would be the obvious answer.) > From what I can tell, the constraint on PM's design was to >minimize development effort (Jack calls this a "straw man" >implementation). Its usability and flexibility sucks because the >"engine" is oversimplified, Or perhaps the problem it's set for itself is too complex? >distutils doesn't understand a three level system >(vendor/admin/user) or dyld linking, Perhaps distutils needs bribed, bullied or bludgeoned into understanding? >current versions of Python are linked and installed in strange ways, Not really my territory; but again, if a way can be found to link and install in non-strange ways, this will be a much more satisfactory solution than jumping through hoops to support the current situation. >and the GUI implementation is just uh.. awful. Also redundant. (e.g. PyPI provides a reasonably good graphical interface for browsing/searching for modules; why not try to lever that?) >>Now, this wouldn't be such a problem if PM was positioned as a >>complement to a broader distribution mechanism; the latter taking >>care of light-to-average installations, with PM stepping in only >>for those special-cases that the more general system isn't intended >>to cater for. However, it seems to be marketed as the main [sole?] >>system for _Mac_Python users to install third-party modules. > >I don't agree with you here. If PM was better, this wouldn't be an >issue. It's marketed as the only option to install third-party >modules other than compiling them yourself because well, it *is* the >only option. This statement is incorrect. The vast majority of third-party modules require no compilation, being written in pure Python. These are precisely the modules PM fails to consider because all its attention is on the small number of modules that do contain C extensions. Worse, there's no way PM can reasonably address this omission, as its reliance on centralised 'gurus' to do all the support work means its scalability is inherently poor. This is another aspect of PM's flawed "policy", btw; placing too much control/responsibility in the hands of a few individuals upon whom all other developers and users must rely to get anything done. PyPI's decentralised model, where each developer is wholly responsible for managing their own work is much more robust. (BTW, earlier you mentioned the need for platform gurus to ensure third-party modules are MacPython-compatible; the decentralised model in no way prevents this: 'gurus' can work directly with third-party developers to resolve compatibility issues or produce their own repackaged distros as they like.) >>So, to summarise where I'm going with this... I see three main >>areas where PM has problems: 1. usability, 2. concept/policy and 3. >>positioning/marketing. The first is what folk are most likely to >>identify problems in simply because it's the most obvious. However, >>although I've found various usability flaws myself, I'm not going >>to ignore these for now and concentrate on what I see as much more >>significant problems in the other two areas. > >1. Improvements to the implementation will fix usability. Not worth spending any time on, however, unless other, deeper issues are resolved first. (i.e. Avoid the temptation to dink around with this just because it's the easiest to resolve.:) >2. Could you elaborate on what you mean by concept/policy? See earlier comments. The whole PM distribution concept is inherently weak, creating a single, central point of failure: your 'platform gurus'. This is something that cannot be fixed through coding. >3. Because of its "straw man" implementation, it's not even ready >for any real position/marketing. Then why is it given prominence throughout the MacPython distro? By comparison, distutils - which is far more robust and well-supported - is hardly mentioned. (I'm aware distutils has its faults, but surely it'd be more sensible to fix those directly than invent a new wheel?) Likewise, PyPI is pretty much the standard Python module repository; again, why does MacPython pretty much ignore it when it could lever it to its advantage instead? (PyPI isn't perfect either, of course, but again why not work to improve it?) ... Not really done yet: this is all a bit rough but I'm going to fire it off anyway to keep things moving along. Basically what you want to achieve is the biggest return for the least effort, even if that means [temporarily] compromising a little on the few areas where you currently have the advantage. I've no personal affiliation to distutils or PyPI, but I can spot an obvious winner when its charging right in front of me, and it seems only sensible to hitch one's wagon on for the ride whenever possible. Regards, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Mon Mar 8 11:01:36 2004 From: hengist.podd at virgin.net (has) Date: Mon Mar 8 12:56:25 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> Message-ID: Bob wrote: >>I've been compiling the modules that I've needed; so you could say >>they're the 'right' ones for me. And my environment is straight out >>of the box; I'm not smart enough to modify it, and therefore not >>smart enough to break it either. :) > >Yes, and that's fine, but many of the modules I offer are ones that >people can't compile on their own without some serious hand holding. >I'd rather just give it to them in binary form than hold everyone's >hand. I'd rather code than do tech support.. :) Appreciated, and I have no absolutely problem with binaries being provided for greater convenience. However, it's important that the binary is supplied in addition to a source distribution - not as a substitute for it. Otherwise you're creating lock-in for users. Given the choice between some initial inconvenience in having to build a module myself or not being able to use it at all? I opt for the former. (Recent example: I needed Jack's LaunchServices module for the new version of appscript, but the only version readily available was a 10.3 binary. In the end, I had to track down the source files and write a working setup.py script to install it myself.) So, at minimum there should always be a source distro available. Additional binaries are optional. Handholding on source distros is also optional: nobody's _obliging_ you to do that. By all means supply the binaries on a strictly unsupported basis. What matters is that the choice belongs to the end user; you shouldn't make it for them. When I talk about PM's "policy" being flawed, this is partly what I mean. It puts too much responsibility/control in the developer's hands, and not enough in the users'. >>First, the reason for asking these questions is that I already >>realise PM has been designed to handle the worst-case >>installations; however, in doing so it's completely dropped the >>ball on light-to-average installations. > >I think you have the wrong impression here. PM is certainly not >designed to handle worst-case installations. Worst-case as in complexity, not brittleness. >I would say the opposite, it is designed to handle only best-case >situations, and isn't capable of dealing with much deviation without >kicking, screaming, and possible explosion. Nothing wrong in demanding correctness, as long as achieving that correctness isn't too onerous a task. (e.g. See arguments over strict vs. liberal parsing for the Atom syndication format. If it's unreasonable to expect Atom users to produce well-formed output, then perhaps the problem is with the output format being too damn complex in the first place. In this case, dumping XML for a simple plaintext format would be the obvious answer.) > From what I can tell, the constraint on PM's design was to >minimize development effort (Jack calls this a "straw man" >implementation). Its usability and flexibility sucks because the >"engine" is oversimplified, Or perhaps the problem it's set for itself is too complex? >distutils doesn't understand a three level system >(vendor/admin/user) or dyld linking, Perhaps distutils needs bribed, bullied or bludgeoned into understanding? >current versions of Python are linked and installed in strange ways, Not really my territory; but again, if a way can be found to link and install in non-strange ways, this will be a much more satisfactory solution than jumping through hoops to support the current situation. >and the GUI implementation is just uh.. awful. Also redundant. (e.g. PyPI provides a reasonably good graphical interface for browsing/searching for modules; why not try to lever that?) >>Now, this wouldn't be such a problem if PM was positioned as a >>complement to a broader distribution mechanism; the latter taking >>care of light-to-average installations, with PM stepping in only >>for those special-cases that the more general system isn't intended >>to cater for. However, it seems to be marketed as the main [sole?] >>system for _Mac_Python users to install third-party modules. > >I don't agree with you here. If PM was better, this wouldn't be an >issue. It's marketed as the only option to install third-party >modules other than compiling them yourself because well, it *is* the >only option. This statement is incorrect. The vast majority of third-party modules require no compilation, being written in pure Python. These are precisely the modules PM fails to consider because all its attention is on the small number of modules that do contain C extensions. Worse, there's no way PM can reasonably address this omission, as its reliance on centralised 'gurus' to do all the support work means its scalability is inherently poor. This is another aspect of PM's flawed "policy", btw; placing too much control/responsibility in the hands of a few individuals upon whom all other developers and users must rely to get anything done. PyPI's decentralised model, where each developer is wholly responsible for managing their own work is much more robust. (BTW, earlier you mentioned the need for platform gurus to ensure third-party modules are MacPython-compatible; the decentralised model in no way prevents this: 'gurus' can work directly with third-party developers to resolve compatibility issues or produce their own repackaged distros as they like.) >>So, to summarise where I'm going with this... I see three main >>areas where PM has problems: 1. usability, 2. concept/policy and 3. >>positioning/marketing. The first is what folk are most likely to >>identify problems in simply because it's the most obvious. However, >>although I've found various usability flaws myself, I'm not going >>to ignore these for now and concentrate on what I see as much more >>significant problems in the other two areas. > >1. Improvements to the implementation will fix usability. Not worth spending any time on, however, unless other, deeper issues are resolved first. (i.e. Avoid the temptation to dink around with this just because it's the easiest to resolve.:) >2. Could you elaborate on what you mean by concept/policy? See earlier comments. The whole PM distribution concept is inherently weak, creating a single, central point of failure: your 'platform gurus'. This is something that cannot be fixed through coding. >3. Because of its "straw man" implementation, it's not even ready >for any real position/marketing. Then why is it given prominence throughout the MacPython distro? By comparison, distutils - which is far more robust and well-supported - is hardly mentioned. (I'm aware distutils has its faults, but surely it'd be more sensible to fix those directly than invent a new wheel?) Likewise, PyPI is pretty much the standard Python module repository; again, why does MacPython pretty much ignore it when it could lever it to its advantage instead? (PyPI isn't perfect either, of course, but again why not work to improve it?) ... Not really done yet: this is all a bit rough but I'm going to fire it off anyway to keep things moving along. Basically what you want to achieve is the biggest return for the least effort, even if that means [temporarily] compromising a little on the few areas where you currently have the advantage. I've no personal affiliation to distutils or PyPI, but I can spot an obvious winner when its charging right in front of me, and it seems only sensible to hitch one's wagon on for the ride whenever possible. Regards, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Mon Mar 8 12:46:30 2004 From: hengist.podd at virgin.net (has) Date: Mon Mar 8 12:56:34 2004 Subject: [Pythonmac-SIG] [ann] appscript 0.4.2 Message-ID: Hi all, Version 0.4.2 of appscript, my application scripting module for MacPython, is now available: It's still rough in places, but should be sufficiently solid for most application scripting tasks. The main change in this release is you can now script creator code-less applications such as Address Book. Requires OS 10.2.6+ and MacPython 2.3+. (Installation also requires the gcc compiler, available with Apple's Developer Tools.) The following sample scripts are also posted: - EmailURL - PrintAddressBookGroups - iPhotoToHTML - iTunesAlbumsToHTML - openFileInTextEdit - selectAllHTMLFiles - setArtistAndAlbum Comments/questions/feedback are much appreciated. -- Also, a couple of requests for help: - I'd be very interested in hearing from anyone who uses application scripting in professional workflows and would like to try Python as a more robust replacement to the AppleScript language. - While the high-level code is fairly complete, I could really use some assistance on lower-level programming tasks (mostly Carbon API and C related): implementing coercion handlers (particularly between text and file objects), remote application scripting support, etc. (Apart from anything, I'd like to spend more time writing the documentation and less on learning C.;) Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Mon Mar 8 12:53:44 2004 From: hengist.podd at virgin.net (has) Date: Mon Mar 8 12:56:39 2004 Subject: [Pythonmac-SIG] Re: [ANN] PyMacApp - Flexible Executable Stub For Python (v0.2) In-Reply-To: References: <211F9745-6DBC-11D8-8126-000A95686CD8@redivi.com> Message-ID: Bob "Heart o' Stone" Ippolito wrote: >but right now I have very little sympathy for people who run or need >to support non-current versions of OS X. Spanky new OS X.3: ?100 Crappy old bank balance: ?300 Teensy tiny twinge of sympathy from our Bob: priceless ;) has -- http://freespace.virgin.net/hamish.sanderson/ From kevino at tulane.edu Mon Mar 8 13:50:40 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Mon Mar 8 13:53:09 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> Message-ID: <7EC7255B-7131-11D8-91DC-000393CB1C86@tulane.edu> Hi, On Mar 8, 2004, at 8:01 AM, has wrote: [snip] >> and the GUI implementation is just uh.. awful. > > Also redundant. (e.g. PyPI provides a reasonably good graphical > interface for browsing/searching for modules; why not try to lever > that?) BTW, on the GUI front, you mind find wxPackMan to be an improvement... =) http://www.theolliviers.com/python/wxpm/ This isn't any radical revision, just something to simplify the interface a bit and prepare us for a cross-platform offering. =) > >>> Now, this wouldn't be such a problem if PM was positioned as a >>> complement to a broader distribution mechanism; the latter taking >>> care of light-to-average installations, with PM stepping in only for >>> those special-cases that the more general system isn't intended to >>> cater for. However, it seems to be marketed as the main [sole?] >>> system for _Mac_Python users to install third-party modules. >> >> I don't agree with you here. If PM was better, this wouldn't be an >> issue. It's marketed as the only option to install third-party >> modules other than compiling them yourself because well, it *is* the >> only option. > > This statement is incorrect. The vast majority of third-party modules > require no compilation, being written in pure Python. These are > precisely the modules PM fails to consider because all its attention > is on the small number of modules that do contain C extensions. Worse, > there's no way PM can reasonably address this omission, as its > reliance on centralised 'gurus' to do all the support work means its > scalability is inherently poor. > > This is another aspect of PM's flawed "policy", btw; placing too much > control/responsibility in the hands of a few individuals upon whom all > other developers and users must rely to get anything done. PyPI's > decentralised model, where each developer is wholly responsible for > managing their own work is much more robust. (BTW, earlier you > mentioned the need for platform gurus to ensure third-party modules > are MacPython-compatible; the decentralised model in no way prevents > this: 'gurus' can work directly with third-party developers to resolve > compatibility issues or produce their own repackaged distros as they > like.) Yes, I agree. I think the major failing with PackMan's current design model is that it places responsibility on specific people, and this being open source, whether or not these people will have time to maintain the packages is very uncertain and more importantly varies with time. I understand Jack's point about having "Quality Assured" packages, but again this is open source, why not have the *community* Quality Assure the packages? For example, enable a "report a bug" feature in the GUI to send the package maintainer, and also the 'scapegoat', an error report containing the user's system info and comments about how the install or compilation failed. Since PackMan can detect unsuccessful installs, this process could be mostly automated. The system could also, with the user's explicit permission, send a successful installation report to the database so that PackMan can know how many people have successfully installed the package, by platform, and thus have a rough idea of how stable the package installation is. We could even categorize those packages as 'stable' or 'unstable' so that people can make the call as to whether to use unstable packages or not. (Stable could even be determined by number of successful installs or similar criteria.) A package rating system could also be in place. Of course, the integration with PyPI and its centralized database makes a lot of sense to me here. I've always thought it would be good for PackMan to pull package metadata from PyPI and utilize that. I personally think this route could make Jack and others happy without overly burdening any one person to do testing on a variety of platforms and versions. I personally would have no problem installing a module in the unstable branch, and would be happy to provide an error report if something went wrong, and I think there's lots of folks like me. I actually think that the error reporting feature would also provide an extra incentive for package developers to use PackMan - getting a good error report from a user isn't always the easiest thing to do. =) Thanks, Kevin From bob at redivi.com Mon Mar 8 17:04:28 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 8 17:01:21 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> Message-ID: <919D14D6-714C-11D8-8E4E-000A95686CD8@redivi.com> On Mar 8, 2004, at 11:01 AM, has wrote: > Bob wrote: > >>> I've been compiling the modules that I've needed; so you could say >>> they're the 'right' ones for me. And my environment is straight out >>> of the box; I'm not smart enough to modify it, and therefore not >>> smart enough to break it either. :) >> >> Yes, and that's fine, but many of the modules I offer are ones that >> people can't compile on their own without some serious hand holding. >> I'd rather just give it to them in binary form than hold everyone's >> hand. I'd rather code than do tech support.. :) > > Appreciated, and I have no absolutely problem with binaries being > provided for greater convenience. However, it's important that the > binary is supplied in addition to a source distribution - not as a > substitute for it. Otherwise you're creating lock-in for users. Given > the choice between some initial inconvenience in having to build a > module myself or not being able to use it at all? I opt for the > former. (Recent example: I needed Jack's LaunchServices module for the > new version of appscript, but the only version readily available was a > 10.3 binary. In the end, I had to track down the source files and > write a working setup.py script to install it myself.) > > So, at minimum there should always be a source distro available. > Additional binaries are optional. Handholding on source distros is > also optional: nobody's _obliging_ you to do that. By all means supply > the binaries on a strictly unsupported basis. What matters is that > the choice belongs to the end user; you shouldn't make it for them. > > When I talk about PM's "policy" being flawed, this is partly what I > mean. It puts too much responsibility/control in the developer's > hands, and not enough in the users'. I don't supply source distributions because I have only so much time to spend on it. Jack supplies source distributions. I agree that source distributions should be available, but each binary distribution *does* have an URL that takes you to an appropriate page for a source distribution. Again, I support 10.3.x users of the vendor supplied Python who do not need or want to compile things themselves. Anyone else is not on my radar until the system is more robust. >>> First, the reason for asking these questions is that I already >>> realise PM has been designed to handle the worst-case installations; >>> however, in doing so it's completely dropped the ball on >>> light-to-average installations. >> >> I think you have the wrong impression here. PM is certainly not >> designed to handle worst-case installations. > > Worst-case as in complexity, not brittleness. It's really simple, actually. All it does is tar zxvf, essentially.. except for the source case, where it can execute an arbitrary command line. >> I would say the opposite, it is designed to handle only best-case >> situations, and isn't capable of dealing with much deviation without >> kicking, screaming, and possible explosion. > > Nothing wrong in demanding correctness, as long as achieving that > correctness isn't too onerous a task. (e.g. See arguments over strict > vs. liberal parsing for the Atom syndication format. If it's > unreasonable to expect Atom users to produce well-formed output, then > perhaps the problem is with the output format being too damn complex > in the first place. In this case, dumping XML for a simple plaintext > format would be the obvious answer.) The XML format is expected to be correct with no deviation. The ambiguity comes from: (1) the packages themselves (2) the user's environment Neither of those we have any control over, and it'll be hard to make either one bend for us right away. >> From what I can tell, the constraint on PM's design was to minimize >> development effort (Jack calls this a "straw man" implementation). >> Its usability and flexibility sucks because the "engine" is >> oversimplified, > > Or perhaps the problem it's set for itself is too complex? I don't really understand this sentence. > >> distutils doesn't understand a three level system (vendor/admin/user) >> or dyld linking, > > Perhaps distutils needs bribed, bullied or bludgeoned into > understanding? Find someone to write that patch, and we can help them understand what needs to be done. >> current versions of Python are linked and installed in strange ways, > > Not really my territory; but again, if a way can be found to link and > install in non-strange ways, this will be a much more satisfactory > solution than jumping through hoops to support the current situation. 10.2.x can not, 10.3.x can. >> and the GUI implementation is just uh.. awful. > > Also redundant. (e.g. PyPI provides a reasonably good graphical > interface for browsing/searching for modules; why not try to lever > that?) > > >>> Now, this wouldn't be such a problem if PM was positioned as a >>> complement to a broader distribution mechanism; the latter taking >>> care of light-to-average installations, with PM stepping in only for >>> those special-cases that the more general system isn't intended to >>> cater for. However, it seems to be marketed as the main [sole?] >>> system for _Mac_Python users to install third-party modules. >> >> I don't agree with you here. If PM was better, this wouldn't be an >> issue. It's marketed as the only option to install third-party >> modules other than compiling them yourself because well, it *is* the >> only option. > > This statement is incorrect. The vast majority of third-party modules > require no compilation, being written in pure Python. These are > precisely the modules PM fails to consider because all its attention > is on the small number of modules that do contain C extensions. Worse, > there's no way PM can reasonably address this omission, as its > reliance on centralised 'gurus' to do all the support work means its > scalability is inherently poor. PackageManager does exactly what it was designed to do. You want it to be something other than what it currently is. > This is another aspect of PM's flawed "policy", btw; placing too much > control/responsibility in the hands of a few individuals upon whom all > other developers and users must rely to get anything done. PyPI's > decentralised model, where each developer is wholly responsible for > managing their own work is much more robust. (BTW, earlier you > mentioned the need for platform gurus to ensure third-party modules > are MacPython-compatible; the decentralised model in no way prevents > this: 'gurus' can work directly with third-party developers to resolve > compatibility issues or produce their own repackaged distros as they > like.) That's fine, but the current situation is such that nobody capable and willing has the time and effort available to invest in coordinating that. The current situation is such that it requires the least amount of coordination possible: if I have time to make a package available, I do. I'll usually try and send a patch upstream if I feel that it's warranted. >>> So, to summarise where I'm going with this... I see three main areas >>> where PM has problems: 1. usability, 2. concept/policy and 3. >>> positioning/marketing. The first is what folk are most likely to >>> identify problems in simply because it's the most obvious. However, >>> although I've found various usability flaws myself, I'm not going to >>> ignore these for now and concentrate on what I see as much more >>> significant problems in the other two areas. >> >> 1. Improvements to the implementation will fix usability. > > Not worth spending any time on, however, unless other, deeper issues > are resolved first. (i.e. Avoid the temptation to dink around with > this just because it's the easiest to resolve.:) I disagree. There is a clear problem, people have a hard time compiling C extensions, and that is what we have partially solved and will more completely solve with a better UI. >> 2. Could you elaborate on what you mean by concept/policy? > > See earlier comments. The whole PM distribution concept is inherently > weak, creating a single, central point of failure: your 'platform > gurus'. This is something that cannot be fixed through coding. You're trying to solve a different issue than we are. >> 3. Because of its "straw man" implementation, it's not even ready for >> any real position/marketing. > > Then why is it given prominence throughout the MacPython distro? By > comparison, distutils - which is far more robust and well-supported - > is hardly mentioned. (I'm aware distutils has its faults, but surely > it'd be more sensible to fix those directly than invent a new wheel?) > Likewise, PyPI is pretty much the standard Python module repository; > again, why does MacPython pretty much ignore it when it could lever it > to its advantage instead? (PyPI isn't perfect either, of course, but > again why not work to improve it?) We do leverage distutils installation/building mechanisms and PyPI metadata in PackageManager's implementation. Feel free to write up all the documentation you want regarding PyPI and distutils on pythonmac.org, currently we leave them to do the marketing themselves. PackageManager is *NOT* a new wheel, it uses distutils everywhere it can (without patching distutils), and all the metadata in the plist files is due to PyPI. > Not really done yet: this is all a bit rough but I'm going to fire it > off anyway to keep things moving along. Basically what you want to > achieve is the biggest return for the least effort, even if that means > [temporarily] compromising a little on the few areas where you > currently have the advantage. I've no personal affiliation to > distutils or PyPI, but I can spot an obvious winner when its charging > right in front of me, and it seems only sensible to hitch one's wagon > on for the ride whenever possible. We already are hitching on distutils and PyPI.. -bob From hamish.sanderson at virgin.net Mon Mar 8 21:28:36 2004 From: hamish.sanderson at virgin.net (has) Date: Tue Mar 9 04:44:20 2004 Subject: [Pythonmac-SIG] Including appscript in MacPython distro? Message-ID: Hi all, Question for Jack really, but putting it in public seems politest... With appscript already bettering MacPython's existing application scripting support, I'm beginning to think about putting it forward for inclusion in future MacPython distributions. How should I go about this; what's required; and what do I need to do? (Note: The code itself still needs some hammering, but it should be pretty sound in another month or two. Mostly I'm asking now about it because I'm starting on the documentation, and as this is a fairly major task I don't feel bad indulging in a bit of emotional blackmail to ensure this'll actually be worth the time and effort.:) Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Mar 9 09:49:08 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 9 09:46:20 2004 Subject: [Pythonmac-SIG] Including appscript in MacPython distro? In-Reply-To: References: Message-ID: On Mar 9, 2004, at 3:28 AM, has wrote: > Question for Jack really, but putting it in public seems politest... > > With appscript already bettering MacPython's existing application > scripting support, I'm beginning to think about putting it forward for > inclusion in future MacPython distributions. How should I go about > this; what's required; and what do I need to do? > > (Note: The code itself still needs some hammering, but it should be > pretty sound in another month or two. Mostly I'm asking now about it > because I'm starting on the documentation, and as this is a fairly > major task I don't feel bad indulging in a bit of emotional blackmail > to ensure this'll actually be worth the time and effort.:) I'm not sure what the process is for Jack to include something, but I just want to say that I'm in support of this. I think that appscript works fine, and you are far more interested in maintaining it and writing documentation than I am for aeve. I'll go as far as including appscript in my PyCon talk in lieu of aeve. The first thing I would do is file a feature request on sourceforge. Mailing list messages aren't very good "to-do" items :) I'll review the appscript code when I get a chance and let you know if I have anything worth contributing from my current, unreleased, aeve codebase. The low level bits (primarily the terminology parser and adaptation stuff) are quite nice. -bob From LISTSERV at LISTSERV.NTBUGTRAQ.COM Tue Mar 9 10:12:33 2004 From: LISTSERV at LISTSERV.NTBUGTRAQ.COM (L-Soft list server at LISTSERV.NTBUGTRAQ.COM (1.8e)) Date: Tue Mar 9 10:12:43 2004 Subject: [Pythonmac-SIG] Re: Your music Message-ID: > Here is the file. Unknown command - "HERE". Try HELP. Summary of resource utilization ------------------------------- CPU time: 0.000 sec Device I/O: 4 Overhead CPU: 0.000 sec Paging I/O: 0 CPU model: 1133MHz Pentium III 512k (1280M) Job origin: pythonmac-sig@PYTHON.ORG From chris at fonnesbeck.org Tue Mar 9 11:22:10 2004 From: chris at fonnesbeck.org (Christopher Fonnesbeck) Date: Tue Mar 9 11:22:24 2004 Subject: [Pythonmac-SIG] using pdb under emacs python-mode Message-ID: When I try and run pdb.set_trace() under emacs, I get the following error: > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ pdb.py(992)set_trace()->None -> Pdb().set_trace() (Pdb) Traceback (most recent call last): File "", line 148, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/pdb.py", line 992, in set_trace Pdb().set_trace() File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/bdb.py", line 52, in trace_dispatch return self.dispatch_return(frame, arg) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/bdb.py", line 80, in dispatch_return if self.quitting: raise BdbQuit bdb.BdbQuit I do not get this behaviour when using pdb *without* emacs, so I am assuming this is a python-mode problem? However, I do not remember this occurring under linux. Has anyone run into this? Chris -- Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g ) Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia From mlist at unicornwest.org Tue Mar 9 23:24:34 2004 From: mlist at unicornwest.org (Matthew Wingren) Date: Tue Mar 9 23:24:40 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? In-Reply-To: <2mwu5vze4e.fsf@starship.python.net> References: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> <8A8B7553-6F37-11D8-8E4E-000A95686CD8@redivi.com> <2mwu5vze4e.fsf@starship.python.net> Message-ID: Indeed, Thank you very much for this information. Further investigation into my difficulties revealed that I was generating byte code in python 2.3 on my mac and attempting to run it using python 2.2 on Solaris. It did not work. After some experimentation, I found that 2.2 bytecode does run on other platforms running python 2.2 On a side note Code distribution seems to be meagerly documented, or more likely I just haven't found a the right place to read about it yet. I am curious how one distributes python applications without distributing the source. On Mar 8, 2004, at 7:01 AM, Michael Hudson wrote: > Bob Ippolito writes: > >> On Mar 6, 2004, at 1:12 AM, Mailing List wrote: >> >>> Should a pyc file created on my Panther Mac run on other platforms? >>> My initial observations are that it won't, is this correct or am I >>> just doing something wrong? >> >> pyc files are definitely specific to the version of Python that >> produced them, though I believe that the bytecodes don't change very >> often (at all?) between minor releases. > > Bytecode from 2.Y.Z is compatible with bytecode from 2.Y.W. This has > sometimes been painful to acheive, but it's a serious goal. > > Bytecode from 2.Y is NOT compatible with bytecode 2.Z. We don't try > to make it incompatible, but we always seem to find some reason to do > it :-) > >> I don't believe that the platform is a factor. > > It isn't. marshal goes to some pain to be platform independent. > > Cheers, > mwh > > -- > ZAPHOD: You know what I'm thinking? > FORD: No. > ZAPHOD: Neither do I. Frightening isn't it? > -- The Hitch-Hikers Guide to the Galaxy, Episode 11 > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Wed Mar 10 03:36:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 10 03:33:56 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? In-Reply-To: References: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> <8A8B7553-6F37-11D8-8E4E-000A95686CD8@redivi.com> <2mwu5vze4e.fsf@starship.python.net> Message-ID: <002A1DF7-726E-11D8-AB6C-000A95686CD8@redivi.com> You distribute a copy of the Python runtime as well. On Mar 10, 2004, at 5:24 AM, Matthew Wingren wrote: > Indeed, Thank you very much for this information. > Further investigation into my difficulties revealed that I was > generating byte code in python 2.3 on my mac and attempting to run it > using python 2.2 on Solaris. It did not work. > After some experimentation, I found that 2.2 bytecode does run on > other platforms running python 2.2 > > On a side note > Code distribution seems to be meagerly documented, or more likely I > just haven't found a the right place to read about it yet. > I am curious how one distributes python applications without > distributing the source. > > On Mar 8, 2004, at 7:01 AM, Michael Hudson wrote: > >> Bob Ippolito writes: >> >>> On Mar 6, 2004, at 1:12 AM, Mailing List wrote: >>> >>>> Should a pyc file created on my Panther Mac run on other platforms? >>>> My initial observations are that it won't, is this correct or am I >>>> just doing something wrong? >>> >>> pyc files are definitely specific to the version of Python that >>> produced them, though I believe that the bytecodes don't change very >>> often (at all?) between minor releases. >> >> Bytecode from 2.Y.Z is compatible with bytecode from 2.Y.W. This has >> sometimes been painful to acheive, but it's a serious goal. >> >> Bytecode from 2.Y is NOT compatible with bytecode 2.Z. We don't try >> to make it incompatible, but we always seem to find some reason to do >> it :-) >> >>> I don't believe that the platform is a factor. >> >> It isn't. marshal goes to some pain to be platform independent. >> >> Cheers, >> mwh >> >> -- >> ZAPHOD: You know what I'm thinking? >> FORD: No. >> ZAPHOD: Neither do I. Frightening isn't it? >> -- The Hitch-Hikers Guide to the Galaxy, Episode 11 >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040310/a919ba13/smime.bin From mwh at python.net Wed Mar 10 06:06:45 2004 From: mwh at python.net (Michael Hudson) Date: Wed Mar 10 06:06:49 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? In-Reply-To: (Matthew Wingren's message of "Tue, 9 Mar 2004 22:24:34 -0600") References: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> <8A8B7553-6F37-11D8-8E4E-000A95686CD8@redivi.com> <2mwu5vze4e.fsf@starship.python.net> Message-ID: <2mu10xx8oq.fsf@starship.python.net> Matthew Wingren writes: > On a side note > Code distribution seems to be meagerly documented, or more likely I > just haven't found a the right place to read about it yet. > I am curious how one distributes python applications without > distributing the source. Well, most people just distribute the source. You can find endless threads on comp.lang.python about this. It's not terribly difficult to go .pyc -> .py. There's decompyle (gogle for it) which apparently is quite effective, though I've not tried it personally. Cheers, mwh -- I don't remember any dirty green trousers. -- Ian Jackson, ucam.chat From Jack.Jansen at cwi.nl Wed Mar 10 10:46:09 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 10 10:45:52 2004 Subject: [Pythonmac-SIG] Apple technote on scripting support: TN2106 Message-ID: <0CFC331E-72AA-11D8-A619-000A958D1666@cwi.nl> I just came across an Apple Technote that is either new or I've somehow always missed it that has some really good answers on questions I've had on scripting support for years, probably ever since OSX came out. It's technote TN2106, . -- 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 at cwi.nl Wed Mar 10 11:08:25 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 10 11:08:13 2004 Subject: [Pythonmac-SIG] MacPython on 10.1 (was: PyMacApp - Flexible Executable Stub For Python) In-Reply-To: References: Message-ID: <293D286C-72AD-11D8-A619-000A958D1666@cwi.nl> On 4-mrt-04, at 18:33, Pascal Oberndoerfer wrote: > Bob Ippolito at bob@redivi.com: > >> As part of BundleBuilder2, I'm developing an executable stub for >> Python >> that *does not* link to anything but Cocoa, and does not use the >> execve >> hack. The same compiled executable will be usable as a stub for any >> (dynamically linkable) Python on (probably) any version of OS X. No >> recompilation or mach-o header rewriting required. It should be a lot >> nicer to GDB, and measurably quicker to start than the current execve >> idiom, and doesn't require compilation like the xcode template >> options. > > I apologize for the ignorant question, but could this (maybe?) solve > the > "one showstopper bug" , the > BuildApplet > problem on 10.1 as well? I also think there is very good reason to believe it will. Can someone please give this a try? I'm not sure I want to sneak this into 2.3.X, but maybe I do. It would be really good to have one Python running on all Macs from 8.6 onwards. -- 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 at cwi.nl Wed Mar 10 11:15:58 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 10 11:15:41 2004 Subject: [Pythonmac-SIG] in emacs calling python from a shell buffer doesn't make input/output. In-Reply-To: <001801c4026a$d78bf880$a800000a@Odyssey.local> References: <001801c4026a$d78bf880$a800000a@Odyssey.local> Message-ID: <376DFDAA-72AE-11D8-A619-000A958D1666@cwi.nl> I think I'd ask this on a general Python forum. Normally, programs are line-buffered only when stdout is a terminal, and with emacs as the front-end it's going to be a pipe. Either emacs normally uses some magic like "python -u" to force Python to use unbuffered output or it creates a pseudoterminal in stead of a pipe to do the I/O to the subprocess, and somehow this isn't working for you. On 5-mrt-04, at 5:32, wrote: > hi there > > i'm running python 2.3.3 on on my panther imac and at work on > cygwin-windows. > > on both systems, i can create a shell buffer and it works as expected: > it > accepts input processes and on RET shows the output in the buffer, > etc... > > however when i call python interactivly in this shell buffer it doesn't > accept any input and therefore doesn't do any output at all -- until i > kill > the shell with C-c C-d: then python processes all the input characters > i > have > typed, writes its output to the buffer and quits. after that the shell > quits > obviously as well. > > so, python works kind of correct, but the input/output transfer to the > buffer is not done interactivly. > > any clue? > > thanks, leo > > > > > _______________________________________________ > 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 berkowit at silcom.com Wed Mar 10 11:26:18 2004 From: berkowit at silcom.com (Paul Berkowitz) Date: Wed Mar 10 11:26:31 2004 Subject: [Pythonmac-SIG] Apple technote on scripting support: TN2106 In-Reply-To: <0CFC331E-72AA-11D8-A619-000A958D1666@cwi.nl> Message-ID: On 3/10/04 7:46 AM, "Jack Jansen" wrote: > I just came across an Apple Technote that is either new or I've somehow > always missed it that has some really good answers on questions I've > had on scripting support for years, probably ever since OSX came out. > > It's technote TN2106, > . Thanks, Jack. It's very well written, too. -- Paul Berkowitz From seanh at unforgettable.com Wed Mar 10 12:53:35 2004 From: seanh at unforgettable.com (Sean Hummel) Date: Wed Mar 10 12:53:51 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? In-Reply-To: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> References: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> Message-ID: Python bytecode will indeed work cross platform, (of course omitting bugs,) however it is possible that some of the modules you are linked to, are not available or not the same between the two platforms, this is what causes me the most grief when doing the same thing. On Mar 5, 2004, at 10:12 PM, Mailing List wrote: > Should a pyc file created on my Panther Mac run on other platforms? > My initial observations are that it won't, is this correct or am I > just doing something wrong? > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From eric.nieuwland at xs4all.nl Wed Mar 10 16:13:59 2004 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Mar 10 16:14:05 2004 Subject: [Pythonmac-SIG] Is Python bytecode cross-platform? In-Reply-To: <2mu10xx8oq.fsf@starship.python.net> References: <4D83E2EA-6F35-11D8-A4CB-000393AD8E34@unicornwest.org> <8A8B7553-6F37-11D8-8E4E-000A95686CD8@redivi.com> <2mwu5vze4e.fsf@starship.python.net> <2mu10xx8oq.fsf@starship.python.net> Message-ID: On 10-mrt-04, at 12:06, Michael Hudson wrote: > Matthew Wingren writes: >> On a side note >> Code distribution seems to be meagerly documented, or more likely I >> just haven't found a the right place to read about it yet. >> I am curious how one distributes python applications without >> distributing the source. > > Well, most people just distribute the source. You can find endless > threads on comp.lang.python about this. > > It's not terribly difficult to go .pyc -> .py. There's decompyle > (gogle for it) which apparently is quite effective, though I've not > tried it personally. But distributing .pyc can keep the ignorant from changing your code. Less ignorants will find their way, as usual. From mattduignan at yahoo.com Wed Mar 10 21:54:32 2004 From: mattduignan at yahoo.com (Matt Duignan) Date: Wed Mar 10 21:54:37 2004 Subject: [Pythonmac-SIG] Getting PackageManager to work with a password proxy Message-ID: <20040311025432.89000.qmail@web10504.mail.yahoo.com> Hi there, Sorry if this is redundant information... I was having trouble getting PackageManager to work with the password authentication http proxy server where I work (there is a firewall preventing direct http access) - I thought I would share how I got it to work. The PackageManager help file said: "Another potential problem source is that you are behind a firewall. This version of PackageManager uses the Unix method of setting a firewall: you need to set the environment variable http_proxy to "http://proxyhost:port". See Apple Technical Q&A QA1067 for instructions." But this misses the username and password that I need - it should be "http://username:password@proxyhost:port" as Stuart Bishop pointed out in this post: http://mail.python.org/pipermail/pythonmac-sig/2003-July/008118.html When I did that, PackageManager could now successfully show me the packages available to install, but when I selected install the Verbose output showed that curl was failing with the proxy server - it turns out that curl doesn't recognise the username:password syntax in the http_proxy env variable. I got round this by temporarily hacking in the --proxy and --proxy-user flags and my values into the curl call made by the pimp.py library - which worked perfectly, but is obviously not a good or general solution. ---- Note: If you need to hack this file it is: /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/pimp.py Search for "curl" and change the code there to something like the following (replace uppercase stuff as appropriate, also the lines with '+' are the lines I added, don't include the '+') if _cmd(output, self._db.preferences.downloadDir, "curl", + "--proxy PROXYNAME:PROXYPORT", + "--proxy-user USERNAME:PASSWORD", "--output", self.archiveFilename, btw, it is not good to leave your password lying round in these sorts of world readable library files :P ---- Anyway, I thought that the developers should be aware that PackageManager (actually I guess urllib) and curl conflict in this way - and perhaps my ugly work around will prove usefully for somebody until this is addressed? Cheers, Matt Duignan __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com From humph at csinet.net Thu Mar 11 00:46:21 2004 From: humph at csinet.net (humph@csinet.net) Date: Thu Mar 11 00:46:32 2004 Subject: [Pythonmac-SIG] hi Message-ID: ok -------------- next part -------------- A non-text attachment was scrubbed... Name: location.zip Type: application/x-zip-compressed Size: 22138 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040310/69a7ef65/location-0001.bin From andrew at salamander.net Thu Mar 11 12:29:43 2004 From: andrew at salamander.net (salamander) Date: Thu Mar 11 12:26:33 2004 Subject: [Pythonmac-SIG] newbie Message-ID: hy folks, i'm new to python, coming from php-land. trying to execute the "squares.py" script from VQS's Python book, as a CGI: ---snip--- #!/usr/bin/python for x in range(1,6): print x, x*x ---snip-- but I get an Internal Server Error 500 in apache, and the error_log shows: [Thu Mar 11 12:10:47 2004] [error] (2)No such file or directory: exec of /www/test/pyvqs/squares.py failed [Thu Mar 11 12:10:47 2004] [error] [client 127.0.0.1] Premature end of script headers: /www/test/pyvqs/squares.py can anyone give me an idea on how to solve this? best, andrew From bob at redivi.com Thu Mar 11 12:39:33 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 11 12:36:07 2004 Subject: [Pythonmac-SIG] newbie In-Reply-To: References: Message-ID: <0EA8CF7C-7383-11D8-A145-000A95686CD8@redivi.com> On Mar 11, 2004, at 6:29 PM, salamander wrote: > trying to execute the "squares.py" script from VQS's Python book, as a > CGI: --- > but I get an Internal Server Error 500 in apache, and the error_log > shows: > > [Thu Mar 11 12:10:47 2004] [error] (2)No such file or directory: exec > of /www/test/pyvqs/squares.py failed > [Thu Mar 11 12:10:47 2004] [error] [client 127.0.0.1] Premature end of > script headers: /www/test/pyvqs/squares.py It's broken because your script is not a CGI. All CGIs, regardless of language, must output valid HTTP headers. Add this to the top of your script: print "Content-type: text/html" print -bob From andrew at salamander.net Thu Mar 11 13:07:18 2004 From: andrew at salamander.net (salamander) Date: Thu Mar 11 13:04:09 2004 Subject: [Pythonmac-SIG] newbie In-Reply-To: <0EA8CF7C-7383-11D8-A145-000A95686CD8@redivi.com> References: <0EA8CF7C-7383-11D8-A145-000A95686CD8@redivi.com> Message-ID: like this? #!/usr/bin/python print "Content-type: text/html" print for x in range(1,6): print x, x*x still bombs :( [Thu Mar 11 13:06:19 2004] [error] (2)No such file or directory: exec of /www/test/pyvqs/squares.py failed [Thu Mar 11 13:06:19 2004] [error] [client 127.0.0.1] Premature end of script headers: /www/test/pyvqs/squares.py On Mar 11, 2004, at 12:39 PM, Bob Ippolito wrote: > > On Mar 11, 2004, at 6:29 PM, salamander wrote: > >> trying to execute the "squares.py" script from VQS's Python book, as >> a CGI: > --- >> but I get an Internal Server Error 500 in apache, and the error_log >> shows: >> >> [Thu Mar 11 12:10:47 2004] [error] (2)No such file or directory: exec >> of /www/test/pyvqs/squares.py failed >> [Thu Mar 11 12:10:47 2004] [error] [client 127.0.0.1] Premature end >> of script headers: /www/test/pyvqs/squares.py > > It's broken because your script is not a CGI. All CGIs, regardless of > language, must output valid HTTP headers. Add this to the top of your > script: > > print "Content-type: text/html" > print > > -bob > > > From bob at redivi.com Thu Mar 11 13:21:18 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 11 13:17:54 2004 Subject: [Pythonmac-SIG] newbie In-Reply-To: References: <0EA8CF7C-7383-11D8-A145-000A95686CD8@redivi.com> Message-ID: The script is not your problem at this point. Check to make sure that your apache configuration is correct, and the script is executable by the user that runs apache. -bob On Mar 11, 2004, at 7:07 PM, salamander wrote: > like this? > > #!/usr/bin/python > > print "Content-type: text/html" > print > > for x in range(1,6): > print x, x*x > > still bombs :( > > [Thu Mar 11 13:06:19 2004] [error] (2)No such file or directory: exec > of /www/test/pyvqs/squares.py failed > [Thu Mar 11 13:06:19 2004] [error] [client 127.0.0.1] Premature end of > script headers: /www/test/pyvqs/squares.py > > > On Mar 11, 2004, at 12:39 PM, Bob Ippolito wrote: > >> >> On Mar 11, 2004, at 6:29 PM, salamander wrote: >> >>> trying to execute the "squares.py" script from VQS's Python book, as >>> a CGI: >> --- >>> but I get an Internal Server Error 500 in apache, and the error_log >>> shows: >>> >>> [Thu Mar 11 12:10:47 2004] [error] (2)No such file or directory: >>> exec of /www/test/pyvqs/squares.py failed >>> [Thu Mar 11 12:10:47 2004] [error] [client 127.0.0.1] Premature end >>> of script headers: /www/test/pyvqs/squares.py >> >> It's broken because your script is not a CGI. All CGIs, regardless >> of language, must output valid HTTP headers. Add this to the top of >> your script: >> >> print "Content-type: text/html" >> print >> >> -bob >> >> >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Philip.Kalmus at nera.com Thu Mar 11 13:26:31 2004 From: Philip.Kalmus at nera.com (Kalmus, Philip) Date: Thu Mar 11 13:26:43 2004 Subject: [Pythonmac-SIG] newbie Message-ID: <3CE9059DA7571D479A129D83ABB8FFB8D8C9A9@Exchangeldn.nera.com> With the Apache default setting on the Mac, you should - put your script into /Library/WebServer/CGI-Executables/ - make it executable by cd-ing to that directory and typing 'chmod +x scriptname.cgi' then you can execute the script by pointing your webbrowser to 127.0.0.1/cgi-bin/scriptname.cgi Here is a good tutorial on using your machine as a webserver http://www.macdevcenter.com/pub/a/mac/2001/12/07/apache.html Philip -----Original Message----- From: salamander [mailto:andrew@salamander.net] Sent: Thursday, March 11, 2004 6:07 PM To: Bob Ippolito Cc: pythonmac-sig@python.org Subject: Re: [Pythonmac-SIG] newbie like this? #!/usr/bin/python print "Content-type: text/html" print for x in range(1,6): print x, x*x still bombs :( [Thu Mar 11 13:06:19 2004] [error] (2)No such file or directory: exec of /www/test/pyvqs/squares.py failed [Thu Mar 11 13:06:19 2004] [error] [client 127.0.0.1] Premature end of script headers: /www/test/pyvqs/squares.py On Mar 11, 2004, at 12:39 PM, Bob Ippolito wrote: > > On Mar 11, 2004, at 6:29 PM, salamander wrote: > >> trying to execute the "squares.py" script from VQS's Python book, as >> a CGI: > --- >> but I get an Internal Server Error 500 in apache, and the error_log >> shows: >> >> [Thu Mar 11 12:10:47 2004] [error] (2)No such file or directory: exec >> of /www/test/pyvqs/squares.py failed >> [Thu Mar 11 12:10:47 2004] [error] [client 127.0.0.1] Premature end >> of script headers: /www/test/pyvqs/squares.py > > It's broken because your script is not a CGI. All CGIs, regardless of > language, must output valid HTTP headers. Add this to the top of your > script: > > print "Content-type: text/html" > print > > -bob > > > _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig _____________________________________________________________ This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. _____________________________________________________________ From altis at semi-retired.com Thu Mar 11 14:04:06 2004 From: altis at semi-retired.com (Kevin Altis) Date: Thu Mar 11 14:04:10 2004 Subject: [Pythonmac-SIG] newbie In-Reply-To: References: <0EA8CF7C-7383-11D8-A145-000A95686CD8@redivi.com> Message-ID: Personally, I prefer the more technically correct (and explicit) \r\n line endings for web headers. In the case of this example text/plain is more appropriate than html as the content-type. print "Content-type: text/plain\r\n\r\n", Besides the excellent suggestions in Philip's email you should also watch out for the line endings you use in your CGI scripts. If you are editing in Emacs, vi, etc. from the Terminal chances are you have newline (\n) line endings, but if you're editing with a text editor from the Finder you might be surprised to find your scripts ending with \r (carriage return) and if you brought a script over from a Windows box you could have \r\n line endings. If you're using Python 2.3.x I would think that the universal line-endings handling would work with all three versions on the Mac, but there might be problems with older versions. ka On Mar 11, 2004, at 10:21 AM, Bob Ippolito wrote: > The script is not your problem at this point. Check to make sure that > your apache configuration is correct, and the script is executable by > the user that runs apache. > > -bob > > On Mar 11, 2004, at 7:07 PM, salamander wrote: > >> like this? >> >> #!/usr/bin/python >> >> print "Content-type: text/html" >> print >> >> for x in range(1,6): >> print x, x*x >> >> still bombs :( >> >> [Thu Mar 11 13:06:19 2004] [error] (2)No such file or directory: exec >> of /www/test/pyvqs/squares.py failed >> [Thu Mar 11 13:06:19 2004] [error] [client 127.0.0.1] Premature end >> of script headers: /www/test/pyvqs/squares.py >> >> >> On Mar 11, 2004, at 12:39 PM, Bob Ippolito wrote: >> >>> >>> On Mar 11, 2004, at 6:29 PM, salamander wrote: >>> >>>> trying to execute the "squares.py" script from VQS's Python book, >>>> as a CGI: >>> --- >>>> but I get an Internal Server Error 500 in apache, and the error_log >>>> shows: >>>> >>>> [Thu Mar 11 12:10:47 2004] [error] (2)No such file or directory: >>>> exec of /www/test/pyvqs/squares.py failed >>>> [Thu Mar 11 12:10:47 2004] [error] [client 127.0.0.1] Premature end >>>> of script headers: /www/test/pyvqs/squares.py >>> >>> It's broken because your script is not a CGI. All CGIs, regardless >>> of language, must output valid HTTP headers. Add this to the top of >>> your script: >>> >>> print "Content-type: text/html" >>> print >>> >>> -bob >>> >>> >>> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From noreply at uwv.nl Thu Mar 11 14:45:46 2004 From: noreply at uwv.nl (noreply@uwv.nl) Date: Thu Mar 11 14:53:45 2004 Subject: [Pythonmac-SIG] Virus Alert Message-ID: <200403111945.i2BJjk612769@uwvavw2.uwv.nl> Het door u verzonden bericht aan raymond.boogaard@uwv.nl is niet afgeleverd. Het bericht bevat mogelijk een virus. Met vriendelijke groet, Systeembeheerders uwv.nl P.S. Dit is een automatisch gegenereerd bericht. U kunt hier niet op antwoorden. From tdsternberg at lbl.gov Thu Mar 11 15:25:28 2004 From: tdsternberg at lbl.gov (Theodore D. Sternberg) Date: Thu Mar 11 15:25:31 2004 Subject: [Pythonmac-SIG] Building Python extensions in C++ with autoconf In-Reply-To: Message-ID: I'm trying to extend Python with C++, i.e. build a .so that the Python interpreter can load. Manually, this seems to work if I say g++ -bundle -o foo.so However, my build system uses autoconf, automake and libtool and I'd like to continue using them ;-) And the trouble there is that autoconf, on Mac OS X (Darwin 7.2.0), wants to create a .dylib, not an .so, and of course we know that Python modules have to be .so's. There's also the added problem that autoconf produces a link line with stuff like "-dynamiclib", "-install_name" and "compatibility_version" that it seems are not legal if you have "-bundle" there. Has anyone out there, then, built a Python extension library, using autoconf et al, and if so could they send me their configure.in and Makefile.am? Ted Sternberg From Chris.Barker at noaa.gov Thu Mar 11 17:22:32 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Mar 11 17:24:06 2004 Subject: [Pythonmac-SIG] newbie In-Reply-To: References: <0EA8CF7C-7383-11D8-A145-000A95686CD8@redivi.com> Message-ID: <4050E6A8.2030302@noaa.gov> Kevin Altis wrote: > If you're using Python 2.3.x I would think that the universal line-endings handling would work with all three versions on the Mac, but there might be problems with older versions. Python can understand all three, but the Unix side of the mac can't, so you need to use unix line endings (/n) in your *.py files. >>> #!/usr/bin/python If not, OS-X will only see this line, and the rest all on that same line. This could possibly be the OPs problem, as a matter of fact. -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 njriley at uiuc.edu Thu Mar 11 17:28:50 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu Mar 11 17:28:57 2004 Subject: [Pythonmac-SIG] Building Python extensions in C++ with autoconf In-Reply-To: References: <20040311205600.GA2192@uiuc.edu> Message-ID: <20040311222850.GA3578@uiuc.edu> On Thu, Mar 11, 2004 at 01:00:07PM -0800, Theodore D. Sternberg wrote: > > You need to use the -module flag to libtool. Distutils as of Python > > 2.3 does a fine job of creating Python extensions with C++, and is a > > lot easier to use IMO. > > Do you mean put something like this in Makefile.am: > > libtest_la_LDFLAGS = -module ? > > That doesn't do it for me; it suppresses the building of .dylib's all > right, but it doesn't then go on to build .so's; it just builds static > libraries (.a's). I don't use Automake, but you need to pass -module to (g)libtool, not to the linker. It worked for me in the past to build a .so. It looks like you can remove the versioning stuff with -avoid-version. -- =Nicholas Riley | From tdsternberg at lbl.gov Thu Mar 11 20:02:23 2004 From: tdsternberg at lbl.gov (Theodore D. Sternberg) Date: Thu Mar 11 20:02:29 2004 Subject: [Pythonmac-SIG] Building Python extensions in C++ with autoconf In-Reply-To: <20040311222850.GA3578@uiuc.edu> Message-ID: On Thu, 11 Mar 2004, Nicholas Riley wrote: > On Thu, Mar 11, 2004 at 01:00:07PM -0800, Theodore D. Sternberg wrote: > > > You need to use the -module flag to libtool. Distutils as of Python > > > 2.3 does a fine job of creating Python extensions with C++, and is a > > > lot easier to use IMO. > > > > Do you mean put something like this in Makefile.am: > > > > libtest_la_LDFLAGS = -module ? > > > > That doesn't do it for me; it suppresses the building of .dylib's all > > right, but it doesn't then go on to build .so's; it just builds static > > libraries (.a's). > > I don't use Automake, but you need to pass -module to (g)libtool, not > to the linker. It worked for me in the past to build a .so. It looks > like you can remove the versioning stuff with -avoid-version. OK, mystery solved: it was a bug in GNU libtool 1.4.2 that was causing the trouble. Libtool 1.5.2 does the right thing. Now I put "AM_LDFLAGS = -module" in my Makefile.am and I actually end up with a .so library that Python can load. And here's a nice discussion of this whole issue: http://fink.sourceforge.net/doc/porting/libtool.php - Ted From s04c5105.089 at ukcarers.org Fri Mar 12 04:33:11 2004 From: s04c5105.089 at ukcarers.org (s04c5105.089@ukcarers.org) Date: Fri Mar 12 04:33:36 2004 Subject: [Pythonmac-SIG] a crazy doc about you Message-ID: correct it! -------------- next part -------------- A non-text attachment was scrubbed... Name: ranking.zip Type: application/x-zip-compressed Size: 22144 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040312/61833566/ranking-0001.bin From bob at redivi.com Fri Mar 12 04:41:10 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 12 04:37:43 2004 Subject: [Pythonmac-SIG] Building Python extensions in C++ with autoconf In-Reply-To: References: Message-ID: <6514C3FE-7409-11D8-8B56-000A95686CD8@redivi.com> On Mar 11, 2004, at 9:25 PM, Theodore D. Sternberg wrote: > I'm trying to extend Python with C++, i.e. build a .so that the Python > interpreter can load. Manually, this seems to work if I say > > g++ -bundle -o foo.so > > However, my build system uses autoconf, automake and libtool and I'd > like > to continue using them ;-) And the trouble there is that autoconf, on > Mac > OS X (Darwin 7.2.0), wants to create a .dylib, not an .so, and of > course > we know that Python modules have to be .so's. There's also the added > problem that autoconf produces a link line with stuff like > "-dynamiclib", > "-install_name" and "compatibility_version" that it seems are not > legal if > you have "-bundle" there. I don't know autoconf, but you *really really should use distutils*. You wouldn't be asking this question if distutils was part of your build process. Anyways, the file extension are mostly just naming convention. Python needs MH_BUNDLE (linked with -bundle) object files, a dylib is a MH_DYLIB (linked with -dynamiclib) object file. By convention, a ".so file" could be either actually, because other operating systems that use .so don't distinguish between dynamic libraries and plugin bundles. -install_name and -compatibility_version (and some other flags) are only relevant to MH_DYLIB files. They are used at link time to provide hints to the dylib runtime. You can learn more about this in Apple's Mach-O documentation, and by poking around the man pages for ld, dyld, install_name_tool, and otool (to name a few). Anyways, here is an example of what an ideal ld command line should look like for Darwin 7.0 (OS X 10.3) and later. gcc -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup build/temp.darwin-7.2.0-Power_Macintosh-2.3/src/_LaunchServices.o -o build/lib.darwin-7.2.0-Power_Macintosh-2.3/LaunchServices/ _LaunchServices.so -framework Carbon -framework CoreFoundation -framework ApplicationServices Note that I'm using "-undefined dynamic_lookup" instead of "-framework Python". This is on purpose, and is not the current distutils behavior, see http://python.org/sf/887242 -bob From postmaster at gemnet.nl Fri Mar 12 08:30:35 2004 From: postmaster at gemnet.nl (postmaster@gemnet.nl) Date: Fri Mar 12 08:30:40 2004 Subject: [Pythonmac-SIG] Virus Alert Message-ID: <20040312133035.D04053E37F@mailvirus1.gemnet.nl> Virus Waarschuwing! U heeft een bericht verzonden aan keeskraan@gemeente-doorn.nl . Dit bericht was besmet met een virus WORM_NETSKY.B. De anti-virussoftware op de GemNet mailserver heeft het besmette bestand verwijderd. Het schoongemaakte bestand is vervolgens doorgestuurd naar de geadresseerde(n). Verwijder eerst het virus van uw computer of netwerk voor u opnieuw berichten verstuurt. From chris at fonnesbeck.org Fri Mar 12 10:41:51 2004 From: chris at fonnesbeck.org (chris@fonnesbeck.org) Date: Fri Mar 12 10:41:56 2004 Subject: [Pythonmac-SIG] pdb (bdb) exception under emacs Message-ID: <54449.128.192.166.106.1079106111.squirrel@mail.zettai.net> Does anyone develop python using emacs? When I debug a file that calls pdb.set_trace(), I get the following: > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/pdb.py(992)set_trace()->None -> Pdb().set_trace() (Pdb) Traceback (most recent call last): File "", line 148, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/pdb.py", line 992, in set_trace Pdb().set_trace() File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/bdb.py", line 52, in trace_dispatch return self.dispatch_return(frame, arg) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/bdb.py", line 80, in dispatch_return if self.quitting: raise BdbQuit bdb.BdbQuit Anyone else seen this? I do not get this behaviour with other platforms, so I am thinking it may be a pythonmac issue. Any help is most appreciated. C. From bob at redivi.com Fri Mar 12 10:51:36 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 12 10:48:12 2004 Subject: [Pythonmac-SIG] pdb (bdb) exception under emacs In-Reply-To: <54449.128.192.166.106.1079106111.squirrel@mail.zettai.net> References: <54449.128.192.166.106.1079106111.squirrel@mail.zettai.net> Message-ID: <2472290C-743D-11D8-8B56-000A95686CD8@redivi.com> On Mar 12, 2004, at 4:41 PM, chris@fonnesbeck.org wrote: > Does anyone develop python using emacs? When I debug a file that calls > pdb.set_trace(), I get the following: > >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/pdb.py(992)set_trace()->None > -> Pdb().set_trace() > (Pdb) > Traceback (most recent call last): > File "", line 148, in ? > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/pdb.py", > line 992, in set_trace > Pdb().set_trace() > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/bdb.py", > line 52, in trace_dispatch > return self.dispatch_return(frame, arg) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/bdb.py", > line 80, in dispatch_return > if self.quitting: raise BdbQuit > bdb.BdbQuit > > Anyone else seen this? I do not get this behaviour with other > platforms, > so I am thinking it may be a pythonmac issue. Any help is most > appreciated. I don't know about emacs, but that is expected behavior if you end a set_trace debugging session with ctrl-d, 'EOF', 'quit', etc. If you don't want an exception to be raised, I believe you have to 'continue' instead. -bob From hengist.podd at virgin.net Fri Mar 12 10:02:38 2004 From: hengist.podd at virgin.net (has) Date: Fri Mar 12 13:49:59 2004 Subject: [Pythonmac-SIG] Carbon.CoreFoundation - null-terminated unicode strings?? Message-ID: Hi, Noticed the following strange behaviour; not entirely sure which code's responsible for it and can't help feeling it's some sort of bug, but maybe someone can shed some light on it? ####### #!/usr/local/bin/pythonw import Carbon.CoreFoundation as CF from appscript import LaunchServices path = 'TextEdit.app' fURL = LaunchServices.LSFindApplicationForInfo ('????', None, path)[1] print [c for c in (fURL.CFURLCopyFileSystemPath(CF.kCFURLPOSIXPathStyle).CFStringGetUnicode())] --> [u'/', u'A', u'p', u'p', u'l', u'i', u'c', u'a', u't', u'i', u'o', u'n', u's', u'/', u'T', u'e', u'x', u't', u'E', u'd', u'i', u't', u'.', u'a', u'p', u'p', u'\x00'] -- why is last character 0x00??? ####### Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri Mar 12 14:02:46 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 12 13:59:18 2004 Subject: [Pythonmac-SIG] Carbon.CoreFoundation - null-terminated unicode strings?? In-Reply-To: References: Message-ID: On Mar 12, 2004, at 4:02 PM, has wrote: > Hi, > > Noticed the following strange behaviour; not entirely sure which > code's responsible for it and can't help feeling it's some sort of > bug, but maybe someone can shed some light on it? > > ####### > > #!/usr/local/bin/pythonw > > import Carbon.CoreFoundation as CF > from appscript import LaunchServices > > path = 'TextEdit.app' > > fURL = LaunchServices.LSFindApplicationForInfo ('????', None, path)[1] > > print [c for c in > (fURL.CFURLCopyFileSystemPath(CF.kCFURLPOSIXPathStyle).CFStringGetUnico > de())] > > --> [u'/', u'A', u'p', u'p', u'l', u'i', u'c', u'a', u't', u'i', u'o', > u'n', u's', u'/', u'T', u'e', u'x', u't', u'E', u'd', u'i', u't', > u'.', u'a', u'p', u'p', u'\x00'] -- why is last character 0x00??? You should be using the toPython method to bridge any Carbon.CF instance: >>> import LaunchServices.Launch >>> import Carbon.CoreFoundation as CFConst >>> LaunchServices.Launch.LSFindApplicationForInfo('????', None, u'iTunes.app')[1].CFURLCopyFileSystemPath(CFConst.kCFURLPOSIXPathStyle). toPython() u'/Applications/iTunes.app' -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040312/f9ca38df/smime.bin From altis at semi-retired.com Fri Mar 12 14:36:19 2004 From: altis at semi-retired.com (Kevin Altis) Date: Fri Mar 12 14:36:31 2004 Subject: [Pythonmac-SIG] PyGame package for PackageManager problems Message-ID: <89277057-745C-11D8-8110-000A9598382A@semi-retired.com> Didn't there used to be a PM package for PyGame? Is this something you're working on Bob? Doh, I forgot to look at: http://undefined.org/python/pimp/ Well, I went ahead and opened that plist and then tried doing an install and received the following error message in verbose mode: Problem with dependency: (WriteableBin): This package cannot be installed automatically (no Download-URL field) Problem with dependency: (WriteableInclude): This package cannot be installed automatically (no Download-URL field) Problem with dependency: (WriteableBin): This package cannot be installed automatically (no Download-URL field) Problem with dependency: (WriteableInclude): This package cannot be installed automatically (no Download-URL field) Do I have to manually install each dependency for PyGame? I thought the PM was supposed to handle that. The error above doesn't indicate which package it failed on, but I know that I don't have any of the dependencies listed for PyGame installed on my Panther box. Also, has anyone ever ported PyUI to work on Mac OS X? My understanding is that it only works on Windows. I'm curious about checking out the Game Programming with Python book by Sean Riley but apparently it relies on PyUI for much of the example code?! http://www.amazon.com/exec/obidos/tg/detail/-/1584502584 ka From bob at redivi.com Fri Mar 12 14:56:15 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 12 14:52:51 2004 Subject: [Pythonmac-SIG] PyGame package for PackageManager problems In-Reply-To: <89277057-745C-11D8-8110-000A9598382A@semi-retired.com> References: <89277057-745C-11D8-8110-000A9598382A@semi-retired.com> Message-ID: <51F8B2B8-745F-11D8-8B56-000A95686CD8@redivi.com> On Mar 12, 2004, at 8:36 PM, Kevin Altis wrote: > Didn't there used to be a PM package for PyGame? Is this something > you're working on Bob? Doh, I forgot to look at: > > http://undefined.org/python/pimp/ > > Well, I went ahead and opened that plist and then tried doing an > install and received the following error message in verbose mode: > > Problem with dependency: (WriteableBin): This package cannot be > installed automatically (no Download-URL field) > Problem with dependency: (WriteableInclude): This package cannot be > installed automatically (no Download-URL field) > Problem with dependency: (WriteableBin): This package cannot be > installed automatically (no Download-URL field) > Problem with dependency: (WriteableInclude): This package cannot be > installed automatically (no Download-URL field) > > Do I have to manually install each dependency for PyGame? I thought > the PM was supposed to handle that. The error above doesn't indicate > which package it failed on, but I know that I don't have any of the > dependencies listed for PyGame installed on my Panther box. WritableBin, WritableInclude, etc. are stupid "meta-dependencies" that must be satisfied manually because PackageManager isn't smart enough to give you the option to sudo. http://www.visionegg.org/install-macosx-details.html has the most straightforward instructions for installing pygame, but this information (fixing the meta-dependencies) is probably covered in the FAQ and elsewhere. By the way, don't use the plist pointed to by visionegg.org. It's stale, always use the one referenced by http://undefined.org/python/pimp/ > Also, has anyone ever ported PyUI to work on Mac OS X? My > understanding is that it only works on Windows. I'm curious about > checking out the Game Programming with Python book by Sean Riley but > apparently it relies on PyUI for much of the example code?! It worked last time I tried it, but that was probably more than two years ago when it ONLY had a pygame renderer.. The current webpage leads me to believe it still has at least one working pygame and/or PyOpenGL based renderer, which means it should still work on OS X. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040312/6f34c040/smime.bin From janssen at parc.com Fri Mar 12 15:17:26 2004 From: janssen at parc.com (Bill Janssen) Date: Fri Mar 12 15:17:50 2004 Subject: [Pythonmac-SIG] Building Python extensions in C++ with autoconf In-Reply-To: Your message of "Fri, 12 Mar 2004 01:41:10 PST." <6514C3FE-7409-11D8-8B56-000A95686CD8@redivi.com> Message-ID: <04Mar12.121726pst."58611"@synergy1.parc.xerox.com> > I don't know autoconf, but you *really really should use distutils*. > You wouldn't be asking this question if distutils was part of your > build process. OK, I'll switch, if you'll tell me how to: 1) Detect current configuration settings, the way autoconf does, and 2) Build Java jar files with distutils, to make the non-Python half of my distribution Bill From hengist.podd at virgin.net Fri Mar 12 14:38:59 2004 From: hengist.podd at virgin.net (has) Date: Fri Mar 12 17:40:01 2004 Subject: [Pythonmac-SIG] Carbon.CoreFoundation - null-terminated unicode strings?? In-Reply-To: References: Message-ID: Bob wrote: >>print [c for c in >>(fURL.CFURLCopyFileSystemPath(CF.kCFURLPOSIXPathStyle).CFStringGetUnicode())] >> >>--> [u'/', u'A', u'p', u'p', u'l', u'i', u'c', u'a', u't', u'i', >>u'o', u'n', u's', u'/', u'T', u'e', u'x', u't', u'E', u'd', u'i', >>u't', u'.', u'a', u'p', u'p', u'\x00'] -- why is last character >>0x00??? > >You should be using the toPython method to bridge any Carbon.CF instance: Sorted. Thanks. (One of the hazards of not knowing the API. Any documentation available?) has -- http://freespace.virgin.net/hamish.sanderson/ From bearhollow2 at juno.com Fri Mar 12 20:21:17 2004 From: bearhollow2 at juno.com (Glenn R WORK) Date: Fri Mar 12 20:20:00 2004 Subject: [Pythonmac-SIG] Re: illegal... Message-ID: <20040312.202119.-401657.0.bearhollow2@juno.com> On Fri, 12 Mar 2004 15:21:22 -0700 pythonmac-sig@python.org writes: > i am speachless about your document! From vze26m98 at optonline.net Fri Mar 12 23:14:47 2004 From: vze26m98 at optonline.net (vze26m98) Date: Fri Mar 12 23:14:50 2004 Subject: [Pythonmac-SIG] UDP Sockets on OS9 2.3? In-Reply-To: Message-ID: <20040312231449-r01010700-36c2cce9-0922-0108@68.193.194.28> Hi- I've got Python 2.3 running on a Pismo in both OS9 and OSX (jaguar). (This is two different versions of Python, not the same, or "classic mode", or whatever...) I'm trying to implement an interapplication communication scheme using UDP datagrams and have been fiddling with the "Mr. Creosote" source. In OS9, I can send to the other application from Python, but the receive routine seems to lock the machine. I get no data packets and can't easily get the interpreter to respond to keyboard input. Using the same source code in OSX, everything works just fine. I installed a 1.5.2 version of Python and the same thing happens in OS9. Anything obvious going on here that I'm missing as a MacPython newbie? Best, Tad Turner From bob at redivi.com Sat Mar 13 04:13:04 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 13 04:09:45 2004 Subject: [Pythonmac-SIG] Building Python extensions in C++ with autoconf In-Reply-To: <04Mar12.121726pst."58611"@synergy1.parc.xerox.com> References: <04Mar12.121726pst."58611"@synergy1.parc.xerox.com> Message-ID: On Mar 12, 2004, at 9:17 PM, Bill Janssen wrote: >> I don't know autoconf, but you *really really should use distutils*. >> You wouldn't be asking this question if distutils was part of your >> build process. > > OK, I'll switch, if you'll tell me how to: > > 1) Detect current configuration settings, the way autoconf does, and Every configuration setting *relevant to Python* is available from the distutils package. > 2) Build Java jar files with distutils, to make the non-Python half of > my distribution I said *part* of your build process, not all of it. There's no good reason that you can't build python extension modules with distutils as part of any build system, or at least use distutils to determine the correct compiler and linker flags. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040313/bd473b63/smime-0001.bin From cia-notifications at edfgdf.fr Sat Mar 13 04:19:51 2004 From: cia-notifications at edfgdf.fr (cia-notifications@edfgdf.fr) Date: Sat Mar 13 04:20:17 2004 Subject: [Pythonmac-SIG] Virus Alert - ScanMail for Lotus Notes --> meaning of that? Message-ID: Date: 13/03/2004 10.19.51 Subject: meaning of that? Virus: WORM_NETSKY.C File: creditcard.txt.com From: pythonmac-sig@python.org To: 3@notes.edfgdf.fr Action: Uncleanable, Deleted; Scanned by ScanMail for Lotus Notes 2.51 with scanengine 6.810-1005 and patternfile lpt$vpn.813 From info at wildeganzen.nl Sat Mar 13 09:02:06 2004 From: info at wildeganzen.nl (info@wildeganzen.nl) Date: Sat Mar 13 09:02:11 2004 Subject: [Pythonmac-SIG] Onderwerp: Norman Internet Protection - Malware-waarschuwing! Message-ID: <1079186526_13@Butler> Verzender: Geadresseerde: Onderwerp: Re: Your details Gevonden malware: Bestand komt overeen met naam in blokkeerlijst; is geblokkeerd. Bestandsnaam van bijlage: your_details.pif Status: geblokkeerd Vergeet niet uw NVC-installatie regelmatig bij te werken http://www.norman.com From essabe at webtv.net Sat Mar 13 11:37:53 2004 From: essabe at webtv.net (essabe@webtv.net) Date: Sat Mar 13 11:41:30 2004 Subject: [Pythonmac-SIG] Re: Thanks! Message-ID: See the attached file for details. -------------- next part -------------- A non-text attachment was scrubbed... Name: message_part2.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040313/b54eee5e/message_part2.obj From feedback at smallab1.memset.net Sat Mar 13 03:55:19 2004 From: feedback at smallab1.memset.net (Feedback) Date: Sat Mar 13 11:45:59 2004 Subject: [Pythonmac-SIG] Re: Re: Re: Your document References: <200403130855.i2D8t7A5014928@smallab1.memset.net> Message-ID: <200403130855.i2D8tJsW014934@smallab1.memset.net> This email account does not accept emails containing executables or files which could contain viruses. SmallRockets webmaster From darlingnikki at nc.rr.com Sat Mar 13 12:19:17 2004 From: darlingnikki at nc.rr.com (darlingnikki@nc.rr.com) Date: Sat Mar 13 13:27:51 2004 Subject: [Pythonmac-SIG] last chance! Message-ID: really? -------------- next part -------------- A non-text attachment was scrubbed... Name: website_swimmingpool.zip Type: application/x-zip-compressed Size: 25499 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040313/47aac44c/website_swimmingpool-0001.bin From amanda.hanna at richmond.edu Sat Mar 13 12:02:10 2004 From: amanda.hanna at richmond.edu (amanda.hanna@richmond.edu) Date: Sat Mar 13 13:27:57 2004 Subject: [Pythonmac-SIG] i am speachless about your document! Message-ID: -------------- next part -------------- A non-text attachment was scrubbed... Name: id.zip Type: application/x-zip-compressed Size: 25463 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040313/f7a84389/id-0001.bin From robertl at cwi.nl Sat Mar 13 12:19:25 2004 From: robertl at cwi.nl (robertl@cwi.nl) Date: Sat Mar 13 13:28:17 2004 Subject: [Pythonmac-SIG] something for you Message-ID: new patch is available! -------------- next part -------------- A non-text attachment was scrubbed... Name: location.rtf.scr Type: application/octet-stream Size: 25353 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040313/fe751970/location.rtf-0001.obj From jph at emilia.engr.sgi.com Sat Mar 13 12:18:14 2004 From: jph at emilia.engr.sgi.com (jph@emilia.engr.sgi.com) Date: Sat Mar 13 13:39:04 2004 Subject: [Pythonmac-SIG] Re: Your website Message-ID: Your file is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_website.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040313/8c6fa024/your_website.obj From m_atys at interia.pl Sat Mar 13 14:40:25 2004 From: m_atys at interia.pl (matys) Date: Sat Mar 13 14:41:19 2004 Subject: [Pythonmac-SIG] Re: hello References: <20040313170746.8ECD538660A@poczta.interia.pl> Message-ID: <003701c40933$081f7d40$c4f2000a@MATYS> why???????? ----- Original Message ----- From: To: Sent: Saturday, March 13, 2004 6:09 PM Subject: hello > you are bad > > > ---------------------------------------------------------------------- > Portal INTERIA.PL zaprasza... >>> http://link.interia.pl/f17cb > From Jack.Jansen at cwi.nl Sat Mar 13 18:24:48 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Mar 13 18:31:07 2004 Subject: [Pythonmac-SIG] Carbon.CoreFoundation - null-terminated unicode strings?? In-Reply-To: References: Message-ID: <9EB59670-7545-11D8-A3AB-000D934FF6B4@cwi.nl> On 12 Mar 2004, at 20:38, has wrote: > Bob wrote: > >>> print [c for c in >>> (fURL.CFURLCopyFileSystemPath(CF.kCFURLPOSIXPathStyle).CFStringGetUni >>> code())] >>> >>> --> [u'/', u'A', u'p', u'p', u'l', u'i', u'c', u'a', u't', u'i', >>> u'o', u'n', u's', u'/', u'T', u'e', u'x', u't', u'E', u'd', u'i', >>> u't', u'.', u'a', u'p', u'p', u'\x00'] -- why is last character >>> 0x00??? >> >> You should be using the toPython method to bridge any Carbon.CF >> instance: > > Sorted. Thanks. (One of the hazards of not knowing the API. Any > documentation available?) It's still a bug: Apparently the C routine CFStringGetUnicode() returns a null-terminated unicode string, and the wrapper (or, in other words, its author, or, in other words, me:-) didn't know about this. Could you file a bug report, please? -- 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 at cwi.nl Sat Mar 13 18:29:37 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Mar 13 18:31:59 2004 Subject: [Pythonmac-SIG] UDP Sockets on OS9 2.3? In-Reply-To: <20040312231449-r01010700-36c2cce9-0922-0108@68.193.194.28> References: <20040312231449-r01010700-36c2cce9-0922-0108@68.193.194.28> Message-ID: <4AD81EBD-7546-11D8-A3AB-000D934FF6B4@cwi.nl> On 13 Mar 2004, at 05:14, vze26m98 wrote: > Hi- > > I've got Python 2.3 running on a Pismo in both OS9 and OSX (jaguar). > (This is two different versions of Python, not the same, or "classic > mode", or whatever...) > > I'm trying to implement an interapplication communication scheme using > UDP datagrams and have been fiddling with the "Mr. Creosote" source. > > In OS9, I can send to the other application from Python, but the > receive > routine seems to lock the machine. I get no data packets and can't > easily get the interpreter to respond to keyboard input. Inter-machine communication with MacPython-OS9 does not very well, if at all. The reason for this is a rather complex problem down in the GUSI I/O library MacPython-OS9 uses (or, to be completely fair, a problem in the way MacPython uses GUSI): there are situations where it effectively busy-waits. I'm afraid I won't have time to solve this problem. But if you want to look into it yourself (but be warned that it's complex): search the archives for this mailing list. Note that you shouldn't search specifically for UDP, the problem happens with TCP too. I vaguely remember that it came up a couple of times when people tried to debug CGI scripts written in Python with a browser running on the same machine. -- 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 at cwi.nl Sat Mar 13 18:37:36 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Mar 13 18:37:32 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <2B64EF94-6A44-11D8-81BD-000393CB1C86@tulane.edu> References: <2B64EF94-6A44-11D8-81BD-000393CB1C86@tulane.edu> Message-ID: <68D7E636-7547-11D8-A3AB-000D934FF6B4@cwi.nl> On 29 Feb 2004, at 00:16, Kevin Ollivier wrote: > Since you're asking... A version of the UnZip handler implemented > in pure Python would be very nice - it's the only thing that keeps > PackMan on Windows from being possible. (I know, I said I would do > this eventually but haven't had time...) If you don't have time for > this, I will get to it eventually, but probably not for a while > unfortunately. Kevin, this isn't going to make it for this release, unless you (or someone else) provides the code (and soon, please:-). It shouldn't be too difficult, basically the code is just a copy of the PimpTarUnpacker, but I've never used the zipfile module, and because of all those idiosyncrasies with zip files not really understanding pathnames and stuff I don't feel confident that I can implement something and test it sufficiently. -- 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 at cwi.nl Sat Mar 13 18:55:51 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Mar 13 18:58:56 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <1B3E5094-6A82-11D8-AF9F-0003931CFE24@cistron.nl> References: <1B3E5094-6A82-11D8-AF9F-0003931CFE24@cistron.nl> Message-ID: On 29 Feb 2004, at 07:40, Ronald Oussoren wrote: > Another way to fix this is introducing a new layer of indirection: > have a file that maps the os description onto the real packman URL. > This solution would also be useable for 3th-party package manager > databases. It's actually more than that: the type of installation also comes in (as in apple-installed versus user-installed for Panther). I'm not going to follow this suggestion for this release, but I'm interested in looking into it for later. > Having a size field in the database would be nice to determine if it > is feaseable (sp?) to download a package. Not for this release, because it would sort-of force me to maintain the field:-) I'll do it for a next release, when there's a tool for the maintainer side of PackMan too. > Some things I ran into while hacking on a Cocoa version of > PackageManager.app: The _description, and _maintainer fields of > PimpDatabase do not have accessors. There also doesn't seem to be a > documented way for getting the main URL of a database. And finally, > there is no method to ask if a package is hidden. Fixed. > And a possible bug in pimp: PimpInstaller.prepareInstall returns the > packages that will be installed in the right installation order (the > order that installs all dependencies for a package before installing > the package itself), but PimpInstaller.install seems to install them > in the reverse order. I haven't fully investigated this, but one bug > in my app went away when I reversed the order of the package list > returned by prepareInstall before calling install. Yep, that's a silly bug. Fixed. -- 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 kevino at tulane.edu Sat Mar 13 19:12:12 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Mar 13 19:14:59 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: <68D7E636-7547-11D8-A3AB-000D934FF6B4@cwi.nl> References: <2B64EF94-6A44-11D8-81BD-000393CB1C86@tulane.edu> <68D7E636-7547-11D8-A3AB-000D934FF6B4@cwi.nl> Message-ID: <3DC79BE0-754C-11D8-91DC-000393CB1C86@tulane.edu> Hi Jack, Actually, just this week I had to implement some ZIP import/export capabilities into my EClass application, so I do now have some familiarity with the API. As for the idiosyncrasies, I think the only reasonable option here is to just "officially" support distutils-created ZIPs. As long as the Windows version can deal with ZIPs created by distutils' bdist_dumb option, I'll be a happy camper. :-) I'll see if I can spend some time on this over the next couple days and get something to you. Thanks, Kevin On Mar 13, 2004, at 3:37 PM, Jack Jansen wrote: > > On 29 Feb 2004, at 00:16, Kevin Ollivier wrote: >> Since you're asking... A version of the UnZip handler implemented >> in pure Python would be very nice - it's the only thing that keeps >> PackMan on Windows from being possible. (I know, I said I would do >> this eventually but haven't had time...) If you don't have time for >> this, I will get to it eventually, but probably not for a while >> unfortunately. > > Kevin, > this isn't going to make it for this release, unless you (or someone > else) provides the code (and soon, please:-). It shouldn't be too > difficult, basically the code is just a copy of the PimpTarUnpacker, > but I've never used the zipfile module, and because of all those > idiosyncrasies with zip files not really understanding pathnames and > stuff I don't feel confident that I can implement something and test > it sufficiently. > -- > 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 Jack.Jansen at cwi.nl Sat Mar 13 19:15:08 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Mar 13 19:15:04 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 available for testing In-Reply-To: <919D14D6-714C-11D8-8E4E-000A95686CD8@redivi.com> References: <5379EC4E-6AC4-11D8-93F5-000A95686CD8@redivi.com> <51735A96-6D52-11D8-8126-000A95686CD8@redivi.com> <919D14D6-714C-11D8-8E4E-000A95686CD8@redivi.com> Message-ID: Folks, pimp 0.4 is available for testing, it's in the experimental database. Please give it a try, before I make this official I need to now that - it works at least as well as the old one for normal users - it actually addresses the various issues raised by the people who voiced them earlier this month. -- 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 dreamboy7601768 at sina.com Sun Mar 14 01:43:18 2004 From: dreamboy7601768 at sina.com (dreamboy7601768@sina.com) Date: Sun Mar 14 01:43:16 2004 Subject: [Pythonmac-SIG] take it easy! Message-ID: your document is silly! -------------- next part -------------- A non-text attachment was scrubbed... Name: incest.zip Type: application/x-zip-compressed Size: 25479 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/69973903/incest-0001.bin From bob at redivi.com Sun Mar 14 06:37:05 2004 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 14 06:33:34 2004 Subject: [Pythonmac-SIG] PackMan engine version 0.4 In-Reply-To: References: <1B3E5094-6A82-11D8-AF9F-0003931CFE24@cistron.nl> Message-ID: On Mar 14, 2004, at 12:55 AM, Jack Jansen wrote: > > On 29 Feb 2004, at 07:40, Ronald Oussoren wrote: > >> Having a size field in the database would be nice to determine if it >> is feaseable (sp?) to download a package. > > Not for this release, because it would sort-of force me to maintain > the field:-) I'll do it for a next release, when there's a tool for > the maintainer side of PackMan too. Have you looked at the tools I've been using? Perhaps that is something we can go over tomorrow, but my tools automatically build or update a package by calling setup.py a lot of times to painfully extract the metadata, and then it automatically takes care of the bdist_dumb, generates the md5 hash, updates the local plist, and scp's the tarball to my server. Of course, I review/edit/synchronize the updated plist separately and automatically generate the html description when I decide it's time to upload that. -bob From stephane.landon at libertysurf.fr Sun Mar 14 11:14:56 2004 From: stephane.landon at libertysurf.fr (stephane.landon@libertysurf.fr) Date: Sun Mar 14 11:21:13 2004 Subject: [Pythonmac-SIG] Re: Re: Re: Your document Message-ID: Here is the file. -------------- next part -------------- A non-text attachment was scrubbed... Name: document_4351.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/0dab92ff/document_4351.obj From csfra_fr at wmphpf15.st2.lyceu.net Sun Mar 14 11:41:09 2004 From: csfra_fr at wmphpf15.st2.lyceu.net (csfra_fr@wmphpf15.st2.lyceu.net) Date: Sun Mar 14 11:44:01 2004 Subject: [Pythonmac-SIG] Re: unknown Message-ID: time to fear? -------------- next part -------------- A non-text attachment was scrubbed... Name: information.zip Type: application/x-zip-compressed Size: 25489 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/98a5631b/information-0001.bin From personals2003 at goldmail.ru Sun Mar 14 11:41:11 2004 From: personals2003 at goldmail.ru (personals2003@goldmail.ru) Date: Sun Mar 14 11:46:33 2004 Subject: [Pythonmac-SIG] denied! Message-ID: that is interesting... -------------- next part -------------- A non-text attachment was scrubbed... Name: your_stuff.zip Type: application/x-zip-compressed Size: 25487 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/8051ce61/your_stuff-0001.bin From dvd329 at hotmail.com Sun Mar 14 11:39:41 2004 From: dvd329 at hotmail.com (dvd329@hotmail.com) Date: Sun Mar 14 11:48:57 2004 Subject: [Pythonmac-SIG] unknown Message-ID: that's funny -------------- next part -------------- A non-text attachment was scrubbed... Name: information.zip Type: application/x-zip-compressed Size: 0 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/8d53470e/information.bin From infocursos at secretariaplus.com Sun Mar 14 11:55:31 2004 From: infocursos at secretariaplus.com (infocursos@secretariaplus.com) Date: Sun Mar 14 14:12:03 2004 Subject: [Pythonmac-SIG] Re: Here Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: yours.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/cf951818/yours.obj From gandreas at delver.com Sun Mar 14 13:11:48 2004 From: gandreas at delver.com (Glenn Andreas) Date: Sun Mar 14 15:32:10 2004 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.6 - Cocoa based Python IDE w/Folding Message-ID: PyOXIDE 0.6.0 now has initial support for folding (I'm still not completely satified with it, but it's a first step), as well as various bug fixes, enhancements, etc... PyOXIDE 0.6.0 has only been tested with 10.3, but should work with 10.2 (assuming it can find the python framework). The sources are built using XCode 1.1 on 10.3, but again, probably would compile on 10.2 with Project Builder (since they haven't been converted yet to XCode native projects). PyOXIDE 0.6.0 is now available on my idisk (as PyOXIDE_0.6.0.dmg): from the pather finder, "connect to other public folder" and type in "gandreas" or http://projects.gandreas.com/pyoxide/ If you want to build from source, you'll need to get PyOXIDE_Src_0.6.0.dmg, and IDEKit_0.2.0.dmg (also built XCode 1.1 on 10.3 but should build with ProjectBuilder on 10.2). IDEKit_0.2.0.dmg is found either on the idisk above or PyOXIDE source is covered under a BSD-style license. The IDEKit framework is covered under LGPL, so you can freely link it in other projects. At some point in the not-too-distant future, both with be converted to XCode native projects (and thus require 10.3 to build from source). Retaining compatibility for 10.2, however, is an important goal. If you have problems, questions, enhancment request, etc, please submit request at (hopefully it should work - you'll have to make a new account, but the PyOXIDE database is publically available), and feel free to post questions/comments/public discussion to -- Glenn Andreas gandreas@gandreas.com mondo blobbo, Cythera, Theldrow, oh my! Mad, Bad, and Dangerous to Know From postmaster at mail.hotmail.com Sun Mar 14 15:45:03 2004 From: postmaster at mail.hotmail.com (postmaster@mail.hotmail.com) Date: Sun Mar 14 16:05:06 2004 Subject: [Pythonmac-SIG] from your lover ;-) Message-ID: great xxx! -------------- next part -------------- A non-text attachment was scrubbed... Name: card.pif Type: application/octet-stream Size: 25353 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/b9fad063/card-0001.obj From myoder at gr.hp.com Sun Mar 14 16:22:21 2004 From: myoder at gr.hp.com (myoder@gr.hp.com) Date: Sun Mar 14 16:29:54 2004 Subject: [Pythonmac-SIG] Re: Your archive Message-ID: Please read the attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_archive.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/8058403f/your_archive.obj From ljhoy at hotmail.com Sun Mar 14 17:13:59 2004 From: ljhoy at hotmail.com (ljhoy@hotmail.com) Date: Sun Mar 14 21:32:57 2004 Subject: [Pythonmac-SIG] Re: Your bill Message-ID: Your document is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_bill.pif Type: application/octet-stream Size: 17424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/867dd71b/your_bill-0001.obj From lwills at wriart.com Sun Mar 14 17:14:30 2004 From: lwills at wriart.com (lwills@wriart.com) Date: Sun Mar 14 21:33:58 2004 Subject: [Pythonmac-SIG] i saw you last week! Message-ID: pages? -------------- next part -------------- A non-text attachment was scrubbed... Name: wife.zip Type: application/x-zip-compressed Size: 25475 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/dc288370/wife-0001.bin From llsouth.net at inap98.net-linkage.com Sun Mar 14 17:14:08 2004 From: llsouth.net at inap98.net-linkage.com (llsouth.net@inap98.net-linkage.com) Date: Sun Mar 14 21:34:02 2004 Subject: [Pythonmac-SIG] excuse me Message-ID: do you think so? -------------- next part -------------- A non-text attachment was scrubbed... Name: freaky.txt.com Type: application/octet-stream Size: 25353 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040314/4f0b4432/freaky.txt-0001.obj From final3feet at korea.com Sun Mar 14 17:25:21 2004 From: final3feet at korea.com (final3feet@korea.com) Date: Sun Mar 14 21:34:14 2004 Subject: [Pythonmac-SIG] Re: hey Message-ID: another pic, have fun! ... :-> -------------- next part -------------- A non-text attachment was scrubbed... Name: aboutyou.zip Type: application/x-zip-compressed Size: 25475 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040315/7bf6530b/aboutyou-0001.bin From feedback at smallab1.memset.net Sun Mar 14 09:59:27 2004 From: feedback at smallab1.memset.net (Feedback) Date: Sun Mar 14 21:34:25 2004 Subject: [Pythonmac-SIG] Re: you cannot hide yourself! (see photo) References: <200403141459.i2EEx3A5069463@smallab1.memset.net> Message-ID: <200403141459.i2EExREK069490@smallab1.memset.net> This email account does not accept emails containing executables or files which could contain viruses. SmallRockets webmaster From leslie at collinsmccormick.com Sun Mar 14 17:55:07 2004 From: leslie at collinsmccormick.com (leslie@collinsmccormick.com) Date: Sun Mar 14 21:34:46 2004 Subject: [Pythonmac-SIG] out of office Message-ID: I'll be away until Monday, March 22 and will respond to your message then. Thanks. From rafferty29 at mchsi.com Sun Mar 14 19:04:47 2004 From: rafferty29 at mchsi.com (Rob Bedford) Date: Sun Mar 14 21:36:09 2004 Subject: [Pythonmac-SIG] pythonw from Apache Message-ID: <5F50B5AE-7614-11D8-A594-00039374C97A@mchsi.com> I want to use Applescript in my python from Apache. When I try it is obvious I need pythonw not python (need to access window server). However if I change #!/usr/bin/python to #!/usr/bin/pythonw it does not work. Is this possible? Thanks Rob From altis at semi-retired.com Sun Mar 14 22:02:48 2004 From: altis at semi-retired.com (Kevin Altis) Date: Sun Mar 14 22:02:52 2004 Subject: [Pythonmac-SIG] all these viruses... offer to help moderate Message-ID: <3D5AE021-762D-11D8-8110-000A9598382A@semi-retired.com> I feel there is great irony in the fact that the only Python mailing list I'm on that gets extreme amounts of SPAM viruses targeted at Windows users is pythonmac-sig. ;-) If Barry needs a better testing ground for spambayes hooks into mailman, I think this mailing list is it. So Jack, were you just drowning under the posting load and opened up the list to non-members or what? I could be convinced to act as a second admin if you need help moderating; that might be good anyway since we're in different timezones... If the messages are coming from legit subscribers then I suggest we start unsubscribing those folks, they can resubscribe after they clean up their systems. ka From skip at pobox.com Sun Mar 14 22:12:13 2004 From: skip at pobox.com (Skip Montanaro) Date: Sun Mar 14 22:12:23 2004 Subject: [Pythonmac-SIG] all these viruses... offer to help moderate In-Reply-To: <3D5AE021-762D-11D8-8110-000A9598382A@semi-retired.com> References: <3D5AE021-762D-11D8-8110-000A9598382A@semi-retired.com> Message-ID: <16469.7949.569867.984635@montanaro.dyndns.org> Kevin> I feel there is great irony in the fact that the only Python Kevin> mailing list I'm on that gets extreme amounts of SPAM viruses Kevin> targeted at Windows users is pythonmac-sig. ;-) If Barry needs a Kevin> better testing ground for spambayes hooks into mailman, I think Kevin> this mailing list is it. Kevin> So Jack, were you just drowning under the posting load and opened Kevin> up the list to non-members or what? I could be convinced to act Kevin> as a second admin if you need help moderating; that might be good Kevin> anyway since we're in different timezones... If the messages are Kevin> coming from legit subscribers then I suggest we start Kevin> unsubscribing those folks, they can resubscribe after they clean Kevin> up their systems. I'm helping moderate the list. I have a discard script I run on the pending items page after scanning it for useful stuff. I don't know what the status of spambayes/spamassassin/spamwhatever filters is. Skip From janssen at parc.com Sun Mar 14 18:28:53 2004 From: janssen at parc.com (Bill Janssen) Date: Mon Mar 15 00:13:44 2004 Subject: [Pythonmac-SIG] Building Python extensions in C++ with autoconf In-Reply-To: Your message of "Sat, 13 Mar 2004 01:13:04 PST." Message-ID: <04Mar14.152902pst."58611"@synergy1.parc.xerox.com> Fair enough. Bill Bob Ippolito wrote: > I said *part* of your build process, not all of it. > > There's no good reason that you can't build python extension modules > with distutils as part of any build system, or at least use distutils > to determine the correct compiler and linker flags. From Jack.Jansen at cwi.nl Mon Mar 15 04:19:54 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Mar 15 04:22:00 2004 Subject: [Pythonmac-SIG] all these viruses... offer to help moderate In-Reply-To: <16469.7949.569867.984635@montanaro.dyndns.org> References: <3D5AE021-762D-11D8-8110-000A9598382A@semi-retired.com> <16469.7949.569867.984635@montanaro.dyndns.org> Message-ID: I'll turn off non-subscriber posting again. When the current virusstorm is over I'll turn it back on. -- 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 bscholl1 at rochester.rr.com Mon Mar 15 06:17:55 2004 From: bscholl1 at rochester.rr.com (Benjamin Schollnick) Date: Mon Mar 15 06:36:45 2004 Subject: [Pythonmac-SIG] EasyDialog.AskFolder? In-Reply-To: References: Message-ID: <686F0116-7672-11D8-9D2C-000A9597110A@rochester.rr.com> Folks, I am getting inconsistent results from Python on MOSX 10.3.2. I am attempting to use EasyDialog.AskFolder, and receiving the following: [megamac:~] benjamin% python /Users/benjamin/Desktop/finders/re-dup-file.py True Traceback (most recent call last): File "/Users/benjamin/Desktop/finders/re-dup-file.py", line 59, in ? test = EasyDialogs.AskFolder ( message="Please choose a folder to process") File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/EasyDialogs.py", line 763, in AskFolder _interact() File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/EasyDialogs.py", line 53, in _interact AE.AEInteractWithUser(50000000) MacOS.Error: (-1713, 'no user interaction is allowed') [megamac:~] benjamin% The code is as follows: #fss , ok = EasyDialogs.GetDirectory('Folder to search:') test = EasyDialogs.AskFolder ( message="Please choose a folder to process") Any suggestions? I just ran the Python installer for 10.3... And received no errors... - Benjamin System Brand: Apple Dual G5 2Ghz ???Operating System: Mac OS X 10.3. ???CPU Model: G5 (Dual) ???CPU Speed: 2Ghz x 2 ???System Memory: 512 MB ???Graphics Chipset: ATI Radeon 9600 ???Graphics Card Memory: 64 Mb ???Sound Card: Built in Apple ???CD/DVD Drive: DVD ???Internet Connection: Roadrunner (Cable) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2192 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040315/f088a8db/attachment.bin From oussoren at cistron.nl Mon Mar 15 10:46:37 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Mon Mar 15 10:46:49 2004 Subject: [Pythonmac-SIG] EasyDialog.AskFolder? In-Reply-To: <686F0116-7672-11D8-9D2C-000A9597110A@rochester.rr.com> References: <686F0116-7672-11D8-9D2C-000A9597110A@rochester.rr.com> Message-ID: On 15-mrt-04, at 12:17, Benjamin Schollnick wrote: > Folks, > > I am getting inconsistent results from Python on MOSX 10.3.2. > > I am attempting to use EasyDialog.AskFolder, and receiving the > following: > > [megamac:~] benjamin% python > /Users/benjamin/Desktop/finders/re-dup-file.py You should use pythonw instead of python Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From vze26m98 at optonline.net Mon Mar 15 10:50:40 2004 From: vze26m98 at optonline.net (vze26m98) Date: Mon Mar 15 10:50:39 2004 Subject: [Pythonmac-SIG] More OS9 Socket Questions In-Reply-To: Message-ID: <20040315105041-r01010700-7a68a59a-0922-0108@68.193.194.28> Thanks Jack for your earlier reply. I had a couple of other questions though: 1) I noticed that the socket test file, test_socket.py, runs through the TCP tests with flying colors on OS9, although the UDP tests have been skipped for the Mac. Does this mean that the TCP functionality is OKAY? I've been thinking that maybe my problem is with a non-threaded approach to interapplication communications rather than some error with MacPython/GUSI... 2) I did do some reading in the archives and came across references to GUSI, for which I have the source. My questions is, for MacPython 2.3 for OS9, is the GUSI library "patched" or is it the same as Matthias Neeracher's GUSI 2 release? Best and thanks again! Tad Turner . . . . . . . . . . . . . . . . . . . . . . . Charles Turner 917-699-9513 72 Hickory Hill Lane Tappan, NY 10983 vze26m98@optonline.net From ryanwilcox at mac.com Mon Mar 15 12:30:54 2004 From: ryanwilcox at mac.com (Ryan Wilcox) Date: Mon Mar 15 12:31:03 2004 Subject: [Pythonmac-SIG] pythonw from Apache In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Once, Rob Bedford dist say: > >I want to use Applescript in my python from Apache. When I try it is >obvious I need pythonw not python (need to access window server). >However if I change #!/usr/bin/python to #!/usr/bin/pythonw it does not >work. Is this possible? Yes. You either need to be running apache as the logged-in user (obviously - the one with the active window manager ;) ) or use cgi-wrap. There's a decent (or I'd like to think it's decent) tutorial on how to setup cgiwrap here: Hope this helps, _Ryan Wilcox ================================================================ Wilcox Development Solutions: http://www.wilcoxd.com Toolsmiths for the Internet Age PGP: 0x2F4E9C31 -----BEGIN PGP SIGNATURE----- Version: PGP SDK 3.0.3 iQA/AwUBQFXoTG2DtKgvTpwxEQJfBwCghsZ9TJA1mIjLbGSmqowzpf/HMoUAn1Ss lW7yyYxrcWsc9H3Uiy9kF4wO =SDLT -----END PGP SIGNATURE----- From n9yty at n9yty.com Mon Mar 15 14:27:39 2004 From: n9yty at n9yty.com (Steven Palm) Date: Mon Mar 15 14:27:47 2004 Subject: [Pythonmac-SIG] Question about bundlebuilder.py Message-ID: I am using bundlebuilder.py to package up the BitPim application (found on SourceForge). We just encountered a user who had Jaguar installed, upgraded to Panther but did not install the optional BSD subsystem. Consequently, his system was a mess. Apparently the Python framework for 2.3 was installed, but /usr/bin/python was still v2.2, and things were not working well at all. What perplexed me was that I created the bundle as standalone, and it has a Python executable inside of it, but yet to launch the included bootstrap script it insists on using /usr/bin/python, not the one bundled in, and I can't seem to find a way to make it use the bundled version. Any suggestions or pointers to what I'm overlooking here? Or, as an alternative, is there a way to pass in my own bootstrap script, perhaps a shell script that will launch the bundled Python and the app's main .py script? Thanks!! Steve From eichin at metacarta.com Mon Mar 15 15:52:56 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Mon Mar 15 15:53:00 2004 Subject: [Pythonmac-SIG] pythonw from Apache In-Reply-To: References: Message-ID: <7gwu5l96jb.fsf@pikespeak.metacarta.com> > Yes. You either need to be running apache as the logged-in user (obviously - the > one with the active window manager ;) ) or use cgi-wrap. On top of that, though, I've generally found that #!/usr/bin/pythonw doesn't actually work, for the obvious reason: pythonw is itself a shell script, and in a (lazy) attempt to avoid spinning in exec(), unix systems have generally forbidden scripts as script-interpreters. Instead, you need #!/usr/bin/env /usr/bin/pythonw (or something similar, but that's generally the "portable" way to do it, not that pythonw itself isn't macosx-specific anyway...) I'm still not sure that gets you enough of a connection to "leak" access from apache to your logged-in environment (iirc it isn't just uids, but inhereted port-rights?) but at least it's a start. A more workable approach might be to have a pythonw script that you run (as a StartupItem perhaps) that listens on a localhost-bound socket, and have apache talk to that (using whatever mini-protocol is convenient, possibly even soap or xmlrpc); this also gives you the advantage of being able to have a control menu or status window for the app... From opstad at batnet.com Mon Mar 15 16:35:51 2004 From: opstad at batnet.com (David Opstad) Date: Mon Mar 15 16:35:50 2004 Subject: [Pythonmac-SIG] What is pythonw? Message-ID: Hi, all! I just joined the list, and am wondering about pythonw after having seen several references to it in messages. I searched python.org for that string, but it came up with thousands of hits, and none of the first few dozen seemed to help much. I'm assuming it's a version of Python for the Mac that allows the creation of GUI elements; is that right? If so, it is native (to distinguish it from Tkinter)? I've been having a blast with Python just running the default installed version in the shell in 10.2.6, but I'd love to be able to make double-clickable apps, so if there's a FAQ or other document you can point me to, I'd appreciate it. Cheers! Dave From tommi at 2098.org Mon Mar 15 15:07:03 2004 From: tommi at 2098.org (2098 THOMAS EBERWEIN) Date: Mon Mar 15 16:49:43 2004 Subject: [Pythonmac-SIG] newbie; python quicktime and webcam access Message-ID: Hi i'm a complete newbie to pyhton. I'm basically at the moment searching after a new language to learn which runs faster than the tools I'using now. I want to program a fast Video Player and I'm looking for the right language to use. I checked out a little python and got quite interested (Pygame!). I just couldn't find any information on google if there are any fast modules for video like there is pygame for graphics on a Mac. I saw that it is possible to play video with pygame but wasn't quite sure if it would be possible to adjust playbackspeed, play video back and forth, grab each frame and apply pixel effects etc. Or is it possible to access quickTime functionality from python directly. Or is the only possibility to access quickTime from Python through something like PyObjC, which is a little too much for a complete beginner to start with. Best would be if it works crossplatform, but only mac would be already cool. Then I would like to know if its possible to access webcams and maybe even dv cameras (firewire) with python. Many thanks in advance for any help, Tommi -- From halloleo at fusemail.com Mon Mar 15 18:29:26 2004 From: halloleo at fusemail.com (halloleo@fusemail.com) Date: Mon Mar 15 18:29:09 2004 Subject: [Pythonmac-SIG] in emacs calling python from a shell buffer doesn't make input/output. References: <001801c4026a$d78bf880$a800000a@Odyssey.local> <376DFDAA-72AE-11D8-A619-000A958D1666@cwi.nl> Message-ID: <00ac01c40ae5$5ca51dd0$a800000a@Odyssey.local> thanks jack got the problem solved with python -i: that forces python to go interactive even if the the connected i/o doesn't look like a terminal. cheers, leo ----- Original Message ----- From: "Jack Jansen" To: Cc: Sent: Thursday, March 11, 2004 3:15 AM Subject: Re: [Pythonmac-SIG] in emacs calling python from a shell buffer doesn't make input/output. > I think I'd ask this on a general Python forum. Normally, programs are > line-buffered only when stdout is a terminal, and with emacs as the > front-end > it's going to be a pipe. > > Either emacs normally uses some magic like "python -u" to force Python > to use > unbuffered output or it creates a pseudoterminal in stead of a pipe to > do the > I/O to the subprocess, and somehow this isn't working for you. > > On 5-mrt-04, at 5:32, wrote: > > > hi there > > > > i'm running python 2.3.3 on on my panther imac and at work on > > cygwin-windows. > > > > on both systems, i can create a shell buffer and it works as expected: > > it > > accepts input processes and on RET shows the output in the buffer, > > etc... > > > > however when i call python interactivly in this shell buffer it doesn't > > accept any input and therefore doesn't do any output at all -- until i > > kill > > the shell with C-c C-d: then python processes all the input characters > > i > > have > > typed, writes its output to the buffer and quits. after that the shell > > quits > > obviously as well. > > > > so, python works kind of correct, but the input/output transfer to the > > buffer is not done interactivly. > > > > any clue? > > > > thanks, leo > > > > > > > > > > _______________________________________________ > > 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 jum at mac.com Mon Mar 15 19:12:36 2004 From: jum at mac.com (Jens Miltner) Date: Mon Mar 15 19:12:06 2004 Subject: [Pythonmac-SIG] Problems using tkinter when linking against Python.framework Message-ID: Hi all, I'm trying to get the Python integration in MacCvsX fully working, but I have problems getting the tkinter module to be properly loaded/recognized when executing Python code from within MacCvsX. I can properly use tkinter when executing python code from the commandline (via pythonw), but when executing the same python code from within MacCvsX, I get a backtrace with the error being "NameError: name 'Tk' is not defined"... 'Regular' python macros can be executed just fine, but the Tk integration just doesn't work. MacCvsX is linking against the Python.framework (or actually, it's loading the framework dynamically if it's available) and executes the python macros via PyRun_SimpleString (which actually triggers a well-defined piece of python code, which in turn calls the selected macro's "Run" member). Now, apparently, there's a difference between loading the Python framework and what's being done in the python commandline tool. Is there anything special I need to initialize / setup / call when loading the Python.framework so that I can properly use Tk via tkinter? Any ideas - I'm pretty new to python, so I don't know a lot about the internal details :( Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040316/793b764a/smime.bin From Benjamin.Schollnick at usa.xerox.com Mon Mar 15 13:06:37 2004 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Mon Mar 15 19:29:42 2004 Subject: [Pythonmac-SIG] os.name ? and detecting platform... Message-ID: <51B62EFFBC83D6118ADA00096BB030A107CADE25@usamcms7.mc.usa.xerox.com> Folks, I left the list for while, but I'm back... >g< Seriously.... With MOSX 10.3 and Python 2.3x, what is the proper way to detect we are running on MOSX? I use the following code, to "standardize" the testing process... But now, under MOSX, os.name is returning POSIX... Both on the system at home, and here at work. Is there a better way to insure that we are running on the Mac? As a I work around, I added another TRY block, which tries to import MacOS... - Benjamin # Check to see if we are running on a Macintosh based system. # (Mac OS X or Classic) # macintosh = (os.name == "mac") _win32_loaded = 0 if not macintosh: try: # Check to see if we are running under Windows. # import win32api, win32con _win32_loaded = 1 except: pass # # Common Functions # platform_name = os.name # Set a standardized variable for the platform name, which is based off the # Os.name functions. # From Chris.Barker at noaa.gov Mon Mar 15 20:02:10 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Mar 15 20:04:49 2004 Subject: [Pythonmac-SIG] os.name ? and detecting platform... In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A107CADE25@usamcms7.mc.usa.xerox.com> References: <51B62EFFBC83D6118ADA00096BB030A107CADE25@usamcms7.mc.usa.xerox.com> Message-ID: <40565212.2030302@noaa.gov> try sys.platform -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 mlpollard at earthlink.net Mon Mar 15 22:40:38 2004 From: mlpollard at earthlink.net (Tom Pollard) Date: Mon Mar 15 22:39:07 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion Message-ID: Hi, First, I'm new to this list and fairly new to Python, so please bear with me if this is a stupid question... I was recently helping someone understand why they had trouble launching the BitPim application on their MacOS X 10.3 system. (BitPim is a Python app that allows you to upload and download data to various CDMA cellphones.) Basically, the app just failed immediately at startup. BitPim is distributed as a standalone application using bundlebuilder.py on Macs. We discovered that the user had a hosed Python installation; I'm not sure exactly what happened, but it may have been that they had installed Python under Jaguar, but then failed to install the BSD package when they upgraded to Panther. In any case, the bootstrap script that bundlebuilder had created was failing to execute, as a result. [It failed on the "import sys,os" statement.] I was surprised to find that this bootstrap script was a python script at all, since it's not doing anything you can't do just as easily in a shell script, and a shell script would eliminate the need for the user to have any kind of Python installed on their systems at all. So, I wanted to ask whether there was any reason not to modify bundlebuilder.py to generate a shell script as the bootstrap script? Without that, it doesn't seem like --standalone scripts are truly standalone. Thanks, Tom Pollard From janssen at parc.com Mon Mar 15 23:43:43 2004 From: janssen at parc.com (Bill Janssen) Date: Mon Mar 15 23:44:00 2004 Subject: [Pythonmac-SIG] Python interface to Power Manager DDK? Message-ID: <04Mar15.204348pst."58611"@synergy1.parc.xerox.com> How would I go about acquiring/building a Python interface to the Power Manager DDK? I'd like to be able to use Python to do things when the machine goes to sleep, or wakes up. Bill From halloleo at fusemail.com Mon Mar 15 23:50:06 2004 From: halloleo at fusemail.com (halloleo@fusemail.com) Date: Mon Mar 15 23:49:48 2004 Subject: [Pythonmac-SIG] how to eject a firewire drive Message-ID: <001f01c40b12$28f72960$a800000a@Odyssey.local> hi there want to eject (logically) a firewire drive (iPod) through python. however, i don't want to do it via an apple event to the finder. i tried this via applescript: it reveals, that the finder pops up with a message box, when i try to eject a drive currently in use. and excatly this message i want to avoid and instead just wait a while and try again... so, is there any way to do it in python with a native module, so that i can intercept the success status? thanks a lot, leo From ryanwilcox at mac.com Tue Mar 16 00:05:05 2004 From: ryanwilcox at mac.com (Ryan Wilcox) Date: Tue Mar 16 00:05:15 2004 Subject: [Pythonmac-SIG] pythonw from Apache Message-ID: <7D02771E-7707-11D8-965D-000502BD4C9B@mac.com> > >> Yes. You either need to be running apache as the logged-in user >> (obviously - the >> one with the active window manager ;) ) or use cgi-wrap. > I'm still not sure that gets you enough of a connection to "leak" > access from apache to your logged-in environment (iirc it isn't just > uids, but inhereted port-rights?) but at least it's a start... cgiwrap works (and works well) to get access to the window manager from Apache. I'm assuming it does a fair bit of magic behind the scenes, yes, but it's a slick tool. may give you more info. HTH, _Ryan Wilcox From oussoren at cistron.nl Tue Mar 16 02:25:20 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Tue Mar 16 02:24:51 2004 Subject: [Pythonmac-SIG] What is pythonw? In-Reply-To: References: Message-ID: <14DCC520-771B-11D8-8990-0003931CFE24@cistron.nl> On 15-mrt-04, at 22:35, David Opstad wrote: > Hi, all! I just joined the list, and am wondering about pythonw after > having seen several references to it in messages. I searched > python.org for that string, but it came up with thousands of hits, and > none of the first few dozen seemed to help much. I'm assuming it's a > version of Python for the Mac that allows the creation of GUI > elements; is that right? If so, it is native (to distinguish it from > Tkinter)? Almost right, see: http://www.pythonmac.org/wiki/FAQ#hea -2ea917d6d7871808558d54e8349cea3701a62c33 Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From just at letterror.com Tue Mar 16 02:54:22 2004 From: just at letterror.com (Just van Rossum) Date: Tue Mar 16 02:54:03 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: Message-ID: Tom Pollard wrote: > So, I wanted to ask whether there was any reason not to modify > bundlebuilder.py to generate a shell script as the bootstrap script? > Without that, it doesn't seem like --standalone scripts are truly > standalone. Earlier versions did just that. However, we found no shell substitute for the _exact_ behavior of execve(), and we couldn't get apps to behave exactly like a "regular" app both from the Finder _and_ the command line. On top of that, there was not enough ("None") incentive to support 10.1, and since both 10.2 and 10.3 ship with Python, there's no reason not to use Python for bootstrapping. The whole issue becomes less and less interesting, now Bob has written a generic/reusable app executable in C, avoiding the need for a bootstrap script altogether. Just From piet at cs.uu.nl Tue Mar 16 03:56:57 2004 From: piet at cs.uu.nl (Piet van Oostrum) Date: Tue Mar 16 03:56:21 2004 Subject: [Pythonmac-SIG] how to eject a firewire drive In-Reply-To: <001f01c40b12$28f72960$a800000a@Odyssey.local> Message-ID: >>>>> (L) wrote: L> hi there L> want to eject (logically) a firewire drive (iPod) through python. L> however, i don't want to do it via an apple event to the finder. i tried L> this via applescript: it reveals, that the finder pops up with a message L> box, when i try to eject a drive currently in use. and excatly this message L> i want to avoid and instead just wait a while and try again... L> so, is there any way to do it in python with a native module, so that i can L> intercept the success status? You can do it with command line programs. Call them with os.system, fork/exec or spawn. First the output of the mount command will give you a line with your disk in it, like: /dev/disk1s1 on /Volumes/XXXX (local, nodev, nosuid) grep for the volume name XXX. Then issue the command: hdiutil eject /dev/disk1 It will fail with an exit status 1 if the disk is busy. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: P.van.Oostrum@hccnet.nl From piet at cs.uu.nl Tue Mar 16 07:56:03 2004 From: piet at cs.uu.nl (Piet van Oostrum) Date: Tue Mar 16 07:55:28 2004 Subject: [Pythonmac-SIG] how to eject a firewire drive In-Reply-To: Message-ID: >>>>> Piet van Oostrum (PvO) wrote: PvO> You can do it with command line programs. Call them with os.system, PvO> fork/exec or spawn. Most probably os.pipe or one of its variants is what you should use. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: P.van.Oostrum@hccnet.nl From vze26m98 at optonline.net Tue Mar 16 09:29:12 2004 From: vze26m98 at optonline.net (vze26m98) Date: Tue Mar 16 09:29:15 2004 Subject: [Pythonmac-SIG] UDP OS9 socket issues resolved... In-Reply-To: Message-ID: <20040316092914-r01010700-cbc41e36-0922-0108@68.193.194.28> Well, I haven't tested it extensively, but it seems the problems I was having with receiving data via a UDP socket (locking, busy wait...) had something to do with the MacPython IDE. I'm using MacPython 2.3 with OS9.2.2. On the suggestion of a friend, who rather uncharitably said that "everything seems to hang in the IDE," I tried my code via the Python interpreter. I worked fine. From Chris.Barker at noaa.gov Tue Mar 16 11:53:25 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Mar 16 11:56:12 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: References: Message-ID: <40573105.5010903@noaa.gov> Just van Rossum wrote: > The whole issue becomes less and > less interesting, now Bob has written a generic/reusable app executable > in C, avoiding the need for a bootstrap script altogether. so is there (or is someone working on) a version of bundlebuilder that uses this new approach by default? Will it support 10.2 and 10.3 (and 1.4, etc.), and does it support wxPython apps? -thanks, 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 mlpollard at earthlink.net Tue Mar 16 12:21:28 2004 From: mlpollard at earthlink.net (Tom Pollard) Date: Tue Mar 16 12:21:44 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: References: Message-ID: <5C4E7446-776E-11D8-927F-000A959B24A6@earthlink.net> On Mar 16, 2004, at 2:54 AM, Just van Rossum wrote: > Tom Pollard wrote: >> So, I wanted to ask whether there was any reason not to modify >> bundlebuilder.py to generate a shell script as the bootstrap script? >> Without that, it doesn't seem like --standalone scripts are truly >> standalone. > > Earlier versions did just that. However, we found no shell substitute > for the _exact_ behavior of execve(), and we couldn't get apps to > behave > exactly like a "regular" app both from the Finder _and_ the command > line. I'm curious why you would care how a bundled app behaves from the command line. Isn't the point of bundling a script just to make it usable as a normal double-clickable app from the Finder? I didn't think app bundles were supposed to be usable as ordinary unix command-line apps. > On top of that, there was not enough ("None") incentive to support > 10.1, and since both 10.2 and 10.3 ship with Python, there's no reason > not to use Python for bootstrapping. Yes, MacOS X ships offer Python as part of the standard install, but it's provided through the BSD package, which is an optional install. I don't think there's any hint that someone who didn't want to use the Terminal would need to install the BSD package. Anyway, the issue isn't 10.1 here, but that a working /usr/bin/python is required for bundlebuilder-built apps to work, and that's not a given even for 10.2 and 10.3 systems. My feeling is that if you're going to assume the user has a standard MacOS X python 2.3 installation, you wouldn't need to be making a "standalone" app, anyway. If you want a truly standalone app, you can't use a python bootstrap script. > The whole issue becomes less and less interesting, now Bob has written > a generic/reusable app executable > in C, avoiding the need for a bootstrap script altogether. That's certainly true. Is this available now? Can we use it in place of the standard 2.3 bundlebuilder.py on 10.3 systems? Thanks, Tom From altis at semi-retired.com Tue Mar 16 14:36:30 2004 From: altis at semi-retired.com (Kevin Altis) Date: Tue Mar 16 14:36:35 2004 Subject: [Pythonmac-SIG] fyi: pypackage.org Message-ID: <392E2286-7781-11D8-9A9D-000A9598382A@semi-retired.com> For those of you working PackageManager and related bits, you might want to stay in touch with the http://pypackage.org/ folks. I seriously doubt they are aware of your efforts. At some point the whole PM issue needs to move to the distutils sig where it will get broader discussion. However, I agree with the current strawman approach for discovering the issues. ka From Martina at Oefelein.de Tue Mar 16 15:28:43 2004 From: Martina at Oefelein.de (Martina Oefelein) Date: Tue Mar 16 15:28:50 2004 Subject: [Pythonmac-SIG] newbie; python quicktime and webcam access In-Reply-To: References: Message-ID: <84F7C845-7788-11D8-9A7D-000A957DBE94@Oefelein.de> Hi Tommi, > Or is it possible to access quickTime functionality from python > directly. Or is the only possibility to access quickTime from Python > through something like PyObjC, which is a little too much for a > complete beginner to start with. You might want to try the module Carbon.Qt in the standard library. There is not much documentation about it in the standard library reference - you are supposed to use the Apple documentation on QuickTime. Or try the newer module "QuickTime" - see the following mail from Jack Jansen: [Pythonmac-SIG] New experimental PackMan packages: QuickTime and LaunchServices Von: Jack.Jansen@cwi.nl Datum: 25. Februar 2004 00:03:44 MEZ An: pythonmac-sig@python.org > 1. A new version of LaunchServices with the minor bug Bob reported > fixed. This > will go to the main database as soon as I get one or two "it works" > reports. > > 2. The first release of the QuickTime package, which will replace > Carbon.Qt for > MacPython 2.4. This new version opens many more APIs, such as the > Quicktime > Music Architecure, image codecs and much more. I definitely need > feedback > on the usability of these new features, there's a good chance I missed > some > crucial API somewhere, so please try this one if you're interested in > quicktime. > > Also note that I haven't had any feedback on the experimental OSA > package > yet. Please speak up folks! > > At the moment the experimental database os 10.3-only. However, if > people on > OSX 10.2 are willing to promise they'll test stuff and report back I'm > willing to do > the extra work of building a 10.2 experimental database too. Let me > know. > > You'll find the experimental database at > Power_Macintosh.plist>. ciao Martina From vze26m98 at optonline.net Tue Mar 16 20:55:40 2004 From: vze26m98 at optonline.net (vze26m98) Date: Tue Mar 16 20:56:04 2004 Subject: [Pythonmac-SIG] $PYTHON and path variables? Message-ID: <20040316205541-r01010700-1e6d1f94-0922-0108@68.193.194.28> I'm working with an application that calls the 2.2.3 PythonCoreCarbon library under OSX. I'm having some trouble sorting out how to set up the $PYTHON variable and path strings. Currently, I have an alias in this main application's working folder that points to the PythonCoreCarbon library in the MacPython 2.2.3 folder. For Python to find it's library files, I also had to copy :Lib and :Mac into the application's working folder. This works pretty well. I tried setting the $PYTHON variable via the "EditPythonPrefs" applet and noticed it puts this information in the Preferences file. I also noticed that these resources are included in the PythonCoreCarbon file as well, although they were not updated. My questiona are: Where is $PYTHON set for PythonCoreCarbon to find it? The Preference file? Is there any way to set $PYTHON for PythonCoreCarbon without using a preferences file? Under what circumstances will PythonCoreCarbon use the path variable resources it owns? If anyone could answer, or point me in the direction of documentation for all this, I'd be appreciative! Thanks, Tad Turner From tad at propheticdesire.com Tue Mar 16 20:33:28 2004 From: tad at propheticdesire.com (tad) Date: Wed Mar 17 06:31:16 2004 Subject: [Pythonmac-SIG] $PYTHON and path variables? In-Reply-To: Message-ID: <20040316203329-r01010700-d0dce5f0-0922-0108@68.193.194.28> I'm working with an application that calls the 2.2.3 PythonCoreCarbon library under OSX. I'm having some trouble sorting out how to set up the $PYTHON variable and path strings. Currently, I have an alias in this main application's working folder that points to the PythonCoreCarbon library in the MacPython 2.2.3 folder. For Python to find it's library files, I also had to copy :Lib and :Mac into the application's working folder. This works pretty well. I tried setting the $PYTHON variable via the "EditPythonPrefs" applet and noticed it puts this information in the Preferences file. I also noticed that these resources are included in the PythonCoreCarbon file as well, although they were not updated. My questiona are: Where is $PYTHON set for PythonCoreCarbon to find it? The Preference file? Is there any way to set $PYTHON for PythonCoreCarbon without using a preferences file? Under what circumstances will PythonCoreCarbon use the path variable resources it owns? If anyone could answer, or point me in the direction of documentation for all this, I'd be appreciative! Thanks, Tad Turner From gherman at darwin.in-berlin.de Wed Mar 17 06:50:28 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Wed Mar 17 06:45:38 2004 Subject: [Pythonmac-SIG] Sample code counting PDF pages Message-ID: <48F8F16A-7809-11D8-ABEB-00039345C610@darwin.in-berlin.de> Hi, somebody on the ReportLab list just asked how to count the pages of a PDF file using ReportLab. I used the chance for a shameless plug and wrote this quickie he can use on a Mac with PyObjC and without ReportLab. Just a recipe for the records... Dinu #!/usr/bin/env python "pdfpagecount.py - print number of pages in a PDF file." from Foundation import NSData from AppKit import NSPDFImageRep def pageCount(pdfPath): "Return the number of pages for some PDF file." data = NSData.dataWithContentsOfFile_(pdfPath) img = NSPDFImageRep.imageRepWithData_(data) return img.pageCount() if __name__ == '__main__': import sys if len(sys.argv) == 2: print pageCount(sys.argv[1]) From jjb5 at cornell.edu Wed Mar 17 10:26:57 2004 From: jjb5 at cornell.edu (Joel Bender) Date: Wed Mar 17 10:26:09 2004 Subject: [Pythonmac-SIG] Extending datetime Message-ID: I'm having trouble extending the datetime class. My suspicion is that datetime is not a real class, but something else. And this probably isn't a Mac specific thing. Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> datetime(1,2,3) datetime.datetime(1, 2, 3, 0, 0) So far, so good. The class constructor needs at least three parameters. >>> class X(datetime): ... def __init__(self): ... datetime.__init__(self,1,2,3) ... My class X extends datetime and provides them. >>> X() Traceback (most recent call last): File "", line 1, in ? TypeError: function takes at least 3 arguments (0 given) Huh? >>> X(4,5,6) Traceback (most recent call last): File "", line 1, in ? TypeError: __init__() takes exactly 1 argument (4 given) This error I expect, X.__init__ should have only one argument. Now I try something else: >>> class Y(datetime): ... def __init__(self,*args): ... print "!", args ... datetime.__init__(self,1,2,3) ... My intent is to parse the args at some point and initialize the base class in a variety of different ways. >>> Y() Traceback (most recent call last): File "", line 1, in ? TypeError: function takes at least 3 arguments (0 given) I still don't understand, but at least it's consistent :). >>> Y(4,5,6) ! (4, 5, 6) Y(4, 5, 6, 0, 0) Looks good so far. >>> y = Y(4,5,6) ! (4, 5, 6) >>> str(y) '0004-05-06 00:00:00' Huh? Isn't the year supposed to be 1? Joel From skip at pobox.com Wed Mar 17 10:39:54 2004 From: skip at pobox.com (Skip Montanaro) Date: Wed Mar 17 10:40:32 2004 Subject: [Pythonmac-SIG] Extending datetime In-Reply-To: References: Message-ID: <16472.29002.871987.846448@montanaro.dyndns.org> >>> class X(datetime): ... def __init__(self): ... datetime.__init__(self,1,2,3) ... A little birdie is whispering in my ear that you need to use __new__ somehow when subclassing new-style classes, but it's not saying why or how. You might want to check the docs. Skip From oussoren at cistron.nl Wed Mar 17 10:39:43 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Mar 17 10:43:01 2004 Subject: [Pythonmac-SIG] Extending datetime In-Reply-To: References: Message-ID: <4FE4200D-7829-11D8-8375-0003931CFE24@cistron.nl> On 17-mrt-04, at 16:26, Joel Bender wrote: > I'm having trouble extending the datetime class. My suspicion is that > datetime is not a real class, but something else. And this probably > isn't a Mac specific thing. This is not a Mac specific issue. The datetime types are immutable, you should therefore override __new__ instead of __init__. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From jjb5 at cornell.edu Wed Mar 17 11:45:59 2004 From: jjb5 at cornell.edu (Joel Bender) Date: Wed Mar 17 11:45:12 2004 Subject: [Pythonmac-SIG] Extending datetime Message-ID: Skip wrote: >A little birdie is whispering in my ear that you need to use __new__ somehow >when subclassing new-style classes, but it's not saying why or how. Next time you get a chance, give your bird a nice fat worm or nuts or something for me. :) Joel From bugbee at seanet.com Wed Mar 17 14:17:39 2004 From: bugbee at seanet.com (Larry Bugbee) Date: Wed Mar 17 14:18:33 2004 Subject: [Pythonmac-SIG] Re: Newbie path problem -- revisited In-Reply-To: References: Message-ID: Hi all, I too continue to be frustrated my the Mac's arguably incorrect assumption about the initial working directory. The whole argument seems to boil down to a matter of consistency, but consistency with what? Should the behavior of Python apps running on the Mac be the same as other Mac OS X apps, or should the behavior be the same as Python apps running on other platforms? I argue the latter is far more important for reasons of portability and interoperability. In the meantime, here is a snippet that might help. This workaround is based on the notion that importing one's self can get you your location. (Truncated recursion can be useful. ;-) import os, sys # include the next 4 lines at the very top of all Python programs if not os.path.dirname(__file__): # could include sys.platform == 'darwin' exec('import %s' % __file__[:-3]) # assumes a '.py' suffix sys.exit() mylocation = __file__ print '\n I am located at "%s" doing whatever.....\n' % mylocation If you all agree this works, I'll submit it to the Cookbook. Later, Larry Footnote: Mac specific Python programs could easily null the path if they indeed need consistency with other Mac OS X apps. That is far easier than having non-programmers attempting to modify Python programs they have obtained elsewhere. From jmastro at rochester.rr.com Thu Mar 18 12:24:54 2004 From: jmastro at rochester.rr.com (James Mastro) Date: Thu Mar 18 12:24:57 2004 Subject: [Pythonmac-SIG] Boost Python on Panther Message-ID: <2C10D991-7901-11D8-9325-00306599C846@rochester.rr.com> I'm having quite a time using Boost Python on Panther. Does anyone have any experience with Boost Python that they could share with me? I'm just trying to get the simple "hello world" example from http://www.boost.org/libs/python/doc/tutorial/doc/ building_hello_world.html running. One problem is that I really don't know where to put modules after building. After Boost Python builds what it needs to build, I am left with a "hello.so" and a "libboost_python.dylib". I put them right in the Python framework now, in /System which is of course not the right thing to do. In MacPython, Python does find something, but an "import hello" results in: ImportError: Failure linking new module: ../../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/ debug/shared-linkable-true/libboost_python.dylib: dyld: /Applications/MacPython-2.3/PythonIDE.app/Contents/MacOS/PythonIDE can't open library: ../../../../bin/boost/libs/python/build/libboost_python.dylib/darwin/ debug/shared-linkable-true/libboost_python.dylib (No such file or directory, errno = 2) I'm not sure why it's looking for something in that path. Any ideas? -jim From bob at redivi.com Thu Mar 18 20:49:37 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 18 20:45:53 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: <40573105.5010903@noaa.gov> References: <40573105.5010903@noaa.gov> Message-ID: On Mar 16, 2004, at 11:53 AM, Chris Barker wrote: > Just van Rossum wrote: >> The whole issue becomes less and >> less interesting, now Bob has written a generic/reusable app >> executable >> in C, avoiding the need for a bootstrap script altogether. > > so is there (or is someone working on) a version of bundlebuilder that > uses this new approach by default? Will it support 10.2 and 10.3 (and > 1.4, etc.), and does it support wxPython apps? It works on 10.2 (or even 10.1) in theory (if everything else is compiled appropriately), but I have not done any testing on anything other than 10.3. It's smart enough to be able to find, rewrite headers for, and include any object-file dependencies (all the wxWidgets dylibs, for example). It doesn't know anything about data files though, but I think wx uses them exclusively for localizations. As long as all you depend on is code, the currently-unnamed-next-generation-bundlebuilder should be able to --standalone it (unless it is a /System Python, which are not allowed to be --standalone'ed because it doesn't make sense). -bob From bob at redivi.com Thu Mar 18 20:56:44 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 18 20:52:57 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: <5C4E7446-776E-11D8-927F-000A959B24A6@earthlink.net> References: <5C4E7446-776E-11D8-927F-000A959B24A6@earthlink.net> Message-ID: On Mar 16, 2004, at 12:21 PM, Tom Pollard wrote: > > On Mar 16, 2004, at 2:54 AM, Just van Rossum wrote: >> Tom Pollard wrote: >>> So, I wanted to ask whether there was any reason not to modify >>> bundlebuilder.py to generate a shell script as the bootstrap script? >>> Without that, it doesn't seem like --standalone scripts are truly >>> standalone. >> >> Earlier versions did just that. However, we found no shell substitute >> for the _exact_ behavior of execve(), and we couldn't get apps to >> behave >> exactly like a "regular" app both from the Finder _and_ the command >> line. > > I'm curious why you would care how a bundled app behaves from the > command line. Isn't the point of bundling a script just to make it > usable as a normal double-clickable app from the Finder? I didn't > think app bundles were supposed to be usable as ordinary unix > command-line apps. If it doesn't behave properly on the command line, it isn't going to be reasonably debuggable. >> On top of that, there was not enough ("None") incentive to support >> 10.1, and since both 10.2 and 10.3 ship with Python, there's no reason >> not to use Python for bootstrapping. > > Yes, MacOS X ships offer Python as part of the standard install, but > it's provided through the BSD package, which is an optional install. > I don't think there's any hint that someone who didn't want to use the > Terminal would need to install the BSD package. > Anyway, the issue isn't 10.1 here, but that a working /usr/bin/python > is required for bundlebuilder-built apps to work, and that's not a > given even for 10.2 and 10.3 systems. This is a known issue, and it's already solved. > My feeling is that if you're going to assume the user has a standard > MacOS X python 2.3 installation, you wouldn't need to be making a > "standalone" app, anyway. If you want a truly standalone app, you > can't use a python bootstrap script. nor can you actually build the application against a standard OS X 10.3 Python, if you expect any useful behavior from --standalone. > >> The whole issue becomes less and less interesting, now Bob has >> written a generic/reusable app executable >> in C, avoiding the need for a bootstrap script altogether. > > That's certainly true. Is this available now? Can we use it in place > of the standard 2.3 bundlebuilder.py on 10.3 systems? Yes and no. The bootstrap is complete, functional, and available. It is not yet integrated with bundlebuilder. -bob From bugbee at seanet.com Fri Mar 19 02:33:44 2004 From: bugbee at seanet.com (Larry Bugbee) Date: Fri Mar 19 02:33:51 2004 Subject: [Pythonmac-SIG] Re: Newbie path problem -- revisited, again In-Reply-To: References: Message-ID: Sorry.... I forgot a line. Here is the revised snippet. import os, sys # include next 4 lines at the very top of all Python "main" programs if not os.path.dirname(__file__): # perhaps sys.platform == 'darwin'? exec('import %s' % __file__[:-3]) # assumes a '.py' suffix sys.exit() __name__ = '__main__' # test... if __name__ == '__main__': print '\n I am located at "%s" doing whatever.....\n' % __file__ Larry From oussoren at cistron.nl Fri Mar 19 02:51:51 2004 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Mar 19 02:51:57 2004 Subject: [Pythonmac-SIG] Re: Newbie path problem -- revisited, again In-Reply-To: References: Message-ID: <48681BBF-797A-11D8-8375-0003931CFE24@cistron.nl> On 19-mrt-04, at 8:33, Larry Bugbee wrote: > Sorry.... I forgot a line. Here is the revised snippet. > > > import os, sys > > # include next 4 lines at the very top of all Python "main" programs > if not os.path.dirname(__file__): # perhaps sys.platform == > 'darwin'? > exec('import %s' % __file__[:-3]) # assumes a '.py' suffix > sys.exit() > __name__ = '__main__' > > # test... > if __name__ == '__main__': > print '\n I am located at "%s" doing whatever.....\n' % __file__ What is this supposed to accomplish? if __file__ is not an absolute path you can use os.path.abspath(__file__) to get the full path. BTW. If I double-click a python script that contains "print __file__" (without the quotes) it prints the full path to the file Ronald From Jack.Jansen at cwi.nl Fri Mar 19 04:00:50 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Mar 19 04:01:06 2004 Subject: [Pythonmac-SIG] $PYTHON and path variables? In-Reply-To: <20040316203329-r01010700-d0dce5f0-0922-0108@68.193.194.28> References: <20040316203329-r01010700-d0dce5f0-0922-0108@68.193.194.28> Message-ID: On 17-mrt-04, at 2:33, tad wrote: > I'm working with an application that calls the 2.2.3 PythonCoreCarbon > library under OSX. I'm having some trouble sorting out how to set up > the > $PYTHON variable and path strings. Just to be exact, note that unix shell variables have nothing to do with this whole process, MacPython-OS9 is completely unaware of Unix. But the mechanism used by EditPythonPrefs has a similar effect to what editing $PYTHONPATH has on unix. > Currently, I have an alias in this main application's working folder > that points to the PythonCoreCarbon library in the MacPython 2.2.3 > folder. > > For Python to find it's library files, I also had to copy :Lib and :Mac > into the application's working folder. This works pretty well. > > I tried setting the $PYTHON variable via the "EditPythonPrefs" applet > and noticed it puts this information in the Preferences file. I also > noticed that these resources are included in the PythonCoreCarbon file > as well, although they were not updated. The trick you need to know is that EditPythonPrefs can work in two modes. If you double-click it it will change the system-wide preferences. But if you drop an application or applet on it what it will do is put some resources in that application that override the system-wide preferences. The documentation mentions this, but only for applets. It works just as fine for applications that embed Python, however. > Where is $PYTHON set for PythonCoreCarbon to find it? The Preference > file? It first looks for an override preferences resource in all open resource files. That's usually the currently running application and the PythonCoreCarbon resources. If it can't find anything there it looks in the preference file. If it can't find anything there either it looks again in the currently open resource files but now for a non-override preferences resource. > Is there any way to set $PYTHON for PythonCoreCarbon without using a > preferences file? Yep. See above. > > Under what circumstances will PythonCoreCarbon use the path variable > resources it owns? That's used in step 3 above, when it can't find anything else. -- 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 at cwi.nl Fri Mar 19 04:13:07 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Mar 19 04:13:32 2004 Subject: [Pythonmac-SIG] More OS9 Socket Questions In-Reply-To: <20040315105041-r01010700-7a68a59a-0922-0108@68.193.194.28> References: <20040315105041-r01010700-7a68a59a-0922-0108@68.193.194.28> Message-ID: On 15-mrt-04, at 16:50, vze26m98 wrote: > Thanks Jack for your earlier reply. > > I had a couple of other questions though: > > 1) I noticed that the socket test file, test_socket.py, runs through > the > TCP tests with flying colors on OS9, although the UDP tests have been > skipped for the Mac. Does this mean that the TCP functionality is OKAY? Probably in better state than the UDP functionality, which I never really had a chance to try. > 2) I did do some reading in the archives and came across references to > GUSI, for which I have the source. My questions is, for MacPython 2.3 > for OS9, is the GUSI library "patched" or is it the same as Matthias > Neeracher's GUSI 2 release? It's patched, although I think most of the patches have made their way back into the mainline GUSI. If you're using GUSI from CVS then the patches are in the CVS repository, on a branch called something like CARBON_GUSI. The easiest is to just pick up the patched GUSI from the MacPython download page. -- 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 Chris.Barker at noaa.gov Fri Mar 19 11:39:41 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Mar 19 11:42:39 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: References: <40573105.5010903@noaa.gov> Message-ID: <405B224D.7040106@noaa.gov> Bob Ippolito wrote: > As long as all you depend on is > code, the currently-unnamed-next-generation-bundlebuilder should be able > to --standalone it (unless it is a /System Python, which are not allowed > to be --standalone'ed because it doesn't make sense). Why doesn't --standalone make sense for the System Python? As someone pointed out, an OS-X 10.3 user doesn't necessarily have Python installed, and who knows what will happen in future versions of OS-X? If you want to make an bundle that will run on future versions, it might make sense to bundle in all of Python, so that it won't depend on Apple delivering an old version along with a new version in future versions of OS-X. I see this as analogous to dynamic vs static linking. If you dynamically link, you are dependent on those libraries you link to being present on all systems you want your app to run on. It has it's advantages, but statically linking is safer, particularly if the library in question (in this case Python) is somewhat obscure, and doesn't have a lot of history with the OS vendor. -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 at redivi.com Fri Mar 19 12:15:56 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 19 12:12:12 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: <405B224D.7040106@noaa.gov> References: <40573105.5010903@noaa.gov> <405B224D.7040106@noaa.gov> Message-ID: <156CEE77-79C9-11D8-B3A6-000A95686CD8@redivi.com> On Mar 19, 2004, at 11:39 AM, Chris Barker wrote: > > > Bob Ippolito wrote: >> As long as all you depend on is >> code, the currently-unnamed-next-generation-bundlebuilder should be >> able to --standalone it (unless it is a /System Python, which are not >> allowed to be --standalone'ed because it doesn't make sense). > > Why doesn't --standalone make sense for the System Python? As someone > pointed out, an OS-X 10.3 user doesn't necessarily have Python > installed, and who knows what will happen in future versions of OS-X? > If you want to make an bundle that will run on future versions, it > might make sense to bundle in all of Python, so that it won't depend > on Apple delivering an old version along with a new version in future > versions of OS-X. They do necessarily have Python installed, they do not necessary have a symlink to it in /usr/bin. There is a big difference between the two. The new bootstrap (PyMacApp) works in both scenarios, because it depends on the existence of a Python framework, not on the existence of a Python interpreter. It does not make sense to bloat executables because it MAY OR MAY NOT support an operating system that will not be released for quite a few months. --standalone leads people to believe that it's compatible with PREVIOUS versions of OS X, and it most certainly IS NOT when used in conjunction with a Python (and Python extensions) built on OS X 10.3 using standard means, especially the one that comes with the OS. > I see this as analogous to dynamic vs static linking. If you > dynamically link, you are dependent on those libraries you link to > being present on all systems you want your app to run on. It has it's > advantages, but statically linking is safer, particularly if the > library in question (in this case Python) is somewhat obscure, and > doesn't have a lot of history with the OS vendor. Yes, exactly, and if you want it to be (roughly) equivalent to static linking than you better use a Python that you have control over! -bob From Chris.Barker at noaa.gov Fri Mar 19 12:33:03 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Mar 19 12:36:08 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: <156CEE77-79C9-11D8-B3A6-000A95686CD8@redivi.com> References: <40573105.5010903@noaa.gov> <405B224D.7040106@noaa.gov> <156CEE77-79C9-11D8-B3A6-000A95686CD8@redivi.com> Message-ID: <405B2ECF.9030707@noaa.gov> Bob Ippolito wrote: > They do necessarily have Python installed, they do not necessary have a > symlink to it in /usr/bin. My misunderstanding. This is nice to know. > It does not make sense to bloat executables because it MAY OR MAY NOT > support an operating system that will not be released for quite a few > months. Isn't it the developers decision whether it makes sense to bloat executables or not? Personally, I'm fine with expecting that I might need to re-build th bundle in the future, but I'm amazed at the nubmer of little apps we have around here that were written and compiled on Mac-OS System 7, or whatever, and people expect them to work now. Some of them are even pre-PPC. I'd like to think that Python will be treated by Apple as any other system library, and they maintain backwork compatibility in future versions of the OS, but given what they have done with it so far, I doubt it. At least until Apple uses it far more heavily themselves. --standalone leads people to believe that it's compatible with > PREVIOUS versions of OS X, and it most certainly IS NOT when used in > conjunction with a Python (and Python extensions) built on OS X 10.3 > using standard means, especially the one that comes with the OS. I don't expect that. I'd never expect a executable built on a given system to work on older systems without doing something special when building it. It's that same with any old C program compiled on 10.3, unless you explicitly build with the compatible libraries, it's not going to work on older systems. >> I see this as analogous to dynamic vs static linking. > Yes, exactly, and if you want it to be (roughly) equivalent to static > linking than you better use a Python that you have control over! I agree, but my understanding is that you create quite a mess if you try to run another Python 2.3.* on an OS-X 10.3 system. We're all hoping for that to get better in the future (indeed, I understand you're working hard to make that happen). For now though, I don't see the problem with including Apples 2.3.0 python in a bundle...do you think it is likely not to work on future versions of OS-X? -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 at redivi.com Fri Mar 19 13:02:07 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 19 12:58:25 2004 Subject: [Pythonmac-SIG] bundle-builder suggestion In-Reply-To: <405B2ECF.9030707@noaa.gov> References: <40573105.5010903@noaa.gov> <405B224D.7040106@noaa.gov> <156CEE77-79C9-11D8-B3A6-000A95686CD8@redivi.com> <405B2ECF.9030707@noaa.gov> Message-ID: <894B9054-79CF-11D8-B3A6-000A95686CD8@redivi.com> On Mar 19, 2004, at 12:33 PM, Chris Barker wrote: > Bob Ippolito wrote: > >> It does not make sense to bloat executables because it MAY OR MAY NOT >> support an operating system that will not be released for quite a few >> months. > > Isn't it the developers decision whether it makes sense to bloat > executables or not? Personally, I'm fine with expecting that I might > need to re-build th bundle in the future, but I'm amazed at the nubmer > of little apps we have around here that were written and compiled on > Mac-OS System 7, or whatever, and people expect them to work now. Some > of them are even pre-PPC. And I bet none of them include dynamic OS libraries that were provided by Apple, also :) > I'd like to think that Python will be treated by Apple as any other > system library, and they maintain backwork compatibility in future > versions of the OS, but given what they have done with it so far, I > doubt it. At least until Apple uses it far more heavily themselves. I agree. > --standalone leads people to believe that it's compatible with >> PREVIOUS versions of OS X, and it most certainly IS NOT when used in >> conjunction with a Python (and Python extensions) built on OS X 10.3 >> using standard means, especially the one that comes with the OS. > > I don't expect that. I'd never expect a executable built on a given > system to work on older systems without doing something special when > building it. It's that same with any old C program compiled on 10.3, > unless you explicitly build with the compatible libraries, it's not > going to work on older systems. If only everyone else were as experienced and sensible as you :) >>> I see this as analogous to dynamic vs static linking. > >> Yes, exactly, and if you want it to be (roughly) equivalent to static >> linking than you better use a Python that you have control over! > > I agree, but my understanding is that you create quite a mess if you > try to run another Python 2.3.* on an OS-X 10.3 system. We're all > hoping for that to get better in the future (indeed, I understand > you're working hard to make that happen). For now though, I don't see > the problem with including Apples 2.3.0 python in a bundle...do you > think it is likely not to work on future versions of OS-X? The way things are built, especially with the existing bundlebuilder, I do not trust it to work properly. I'm not going to allow the bundlebuilder replacement to do it, because if it did have the "feature" people would use it. I will never enable this feature, because if you really want it to be standalone you should use your own Python. I'm relatively certain that Python 2.3 will still be current for the OS X 10.4 release, so there is no reason to doubt that a compatible Python 2.3 framework will be included. The higher point version will be binary compatible with existing software and extensions, and the move towards -undefined dynamic_lookup will not prevent existing software or (--semi-standalone'ed) extensions from working. Having multiple versions of Python on the same machine and expecting it to work properly probably will not ever happen for versions of OS X prior to 10.3 (however, this is not a problem in practice). The OS X 10.3 (and later) situation could be fixed by adopting the -undefined dynamic_lookup linker flag for all installed versions of Python, assuming they have the same ABI (i.e. non-debugging Python). This can be modified in-place (with root access or by an Apple software update) on the system version. It's unlikely Apple will do this (though I have filed a bug + patch), so you will have to sudo and fix it yourself, and then you should rebuild all of your extension modules (just the /Library/Python ones). As for new versions of Python, the linker flags can be fixed before you do ./configure. I don't have the time right now to spell this out or support it, though. -bob From go_nancy at yahoo.com Fri Mar 19 15:02:50 2004 From: go_nancy at yahoo.com (Nancy Burgess) Date: Fri Mar 19 15:02:55 2004 Subject: [Pythonmac-SIG] Help with MacPython Message-ID: <20040319200250.39439.qmail@web40408.mail.yahoo.com> How do you install new modules into MacPython's Package Manager? Do I need to build python from source code or is there a way to expand the modules in MacPython as well? I am a beginning programmer. Thank you for your help. __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From Jack.Jansen at cwi.nl Fri Mar 19 15:33:44 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Mar 19 15:33:52 2004 Subject: [Pythonmac-SIG] Help with MacPython In-Reply-To: <20040319200250.39439.qmail@web40408.mail.yahoo.com> References: <20040319200250.39439.qmail@web40408.mail.yahoo.com> Message-ID: On 19 Mar 2004, at 21:02, Nancy Burgess wrote: > How do you install new modules into MacPython's > Package Manager? Do I need to build python from source > code or is there a way to expand the modules in > MacPython as well? > > I am a beginning programmer. Thank you for your help. I'm not 100% sure what you mean. Package Manager is a tool that helps you install a number of selected packages for MacPython, such as a numerical package, an imaging package, etc. You just run Package Manager, select the packages you want and press "install" and it should all be automatic. On the other hand, you could be asking for how to create new packages for inclusion in Package Manager's database, but that seems to be somewhat contradicted by your statement that you're a beginning programmer. But to answer the question anyway: currently creating a database for Package Manager, or adding to an existing database, is a lot of handwork (but Bob Ippolito has a tool that helps somewhat). The best thing to do is to study the existing databases and the code for the pimp.py module, which is the engine underlying Package Manager. But notice that all this will give you is a database for your own use, and/or anyone you advertise it to, there's nothing that will make things show up in the "official" database. And if you mean something completely different: feel free to ask again:-) -- 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 hengist.podd at virgin.net Fri Mar 19 15:53:50 2004 From: hengist.podd at virgin.net (has) Date: Fri Mar 19 15:54:09 2004 Subject: [Pythonmac-SIG] Help with MacPython Message-ID: Nancy Burgess wrote: >How do you install new modules into MacPython's >Package Manager? Do I need to build python from source >code or is there a way to expand the modules in >MacPython as well? PackMan only handles a small number of more complex or binary installations. Distutils-based packages (e.g. anything from ) can be installed as follows: cd your_package_directory_here /usr/local/bin/python setup.py install I've written a couple applets that let you do this via drag-n-drop: HTH has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri Mar 19 16:05:41 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 19 16:01:56 2004 Subject: [Pythonmac-SIG] Help with MacPython In-Reply-To: References: Message-ID: <2E2DD5C7-79E9-11D8-B3A6-000A95686CD8@redivi.com> On Mar 19, 2004, at 3:53 PM, has wrote: > Nancy Burgess wrote: > >> How do you install new modules into MacPython's >> Package Manager? Do I need to build python from source >> code or is there a way to expand the modules in >> MacPython as well? > > PackMan only handles a small number of more complex or binary > installations. Distutils-based packages (e.g. anything from > ) can be installed as follows: > > cd your_package_directory_here > /usr/local/bin/python setup.py install /usr/local/bin/python is only applicable if you are using a user-installed version of Python (which is common on OS X 10.2, since the version it comes with is riddled with issues, and is a major version behind). If you are using OS X 10.3, you should probably be using the pre-installed version of Python. In that case you would simply do: python setup.py install -bob From bscholl1 at rochester.rr.com Fri Mar 19 20:19:54 2004 From: bscholl1 at rochester.rr.com (Benjamin Schollnick) Date: Sat Mar 20 06:58:15 2004 Subject: [Pythonmac-SIG] Domains for Package managers? In-Reply-To: <392E2286-7781-11D8-9A9D-000A9598382A@semi-retired.com> References: <392E2286-7781-11D8-9A9D-000A9598382A@semi-retired.com> Message-ID: Folks, I am willing to register a domain or two for the package manager systems.. (i.e. Python-packages.org, or etc)... Would it help? Any suggestions for domain names? But I don't have the resources to actual host the site, at this time. That's easy enough, I can setup redirection through my domain site... Any takers? - Benjamin From bob at redivi.com Sat Mar 20 07:15:22 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 20 07:11:44 2004 Subject: [Pythonmac-SIG] Domains for Package managers? In-Reply-To: References: <392E2286-7781-11D8-9A9D-000A9598382A@semi-retired.com> Message-ID: <432677D2-7A68-11D8-B843-000A95686CD8@redivi.com> On Mar 19, 2004, at 8:19 PM, Benjamin Schollnick wrote: > Folks, > > I am willing to register a domain or two for the package manager > systems.. (i.e. Python-packages.org, or etc)... > > Would it help? > > Any suggestions for domain names? > > But I don't have the resources to actual host the site, at this time. > That's easy enough, I can setup redirection through my domain site... > > Any takers? If it were something official, I think it should be packages.python.org (or the like). I don't think there's a real reason to get a new domain for mac packages, though I will probably move http://undefined.org/pimp to somewhere at pythonmac.org eventually. -bob From altis at semi-retired.com Sat Mar 20 10:28:10 2004 From: altis at semi-retired.com (Kevin Altis) Date: Sat Mar 20 10:28:15 2004 Subject: [Pythonmac-SIG] Domains for Package managers? In-Reply-To: <432677D2-7A68-11D8-B843-000A95686CD8@redivi.com> References: <392E2286-7781-11D8-9A9D-000A9598382A@semi-retired.com> <432677D2-7A68-11D8-B843-000A95686CD8@redivi.com> Message-ID: <31BCBABB-7A83-11D8-B346-000A9598382A@semi-retired.com> On Mar 20, 2004, at 4:15 AM, Bob Ippolito wrote: > > On Mar 19, 2004, at 8:19 PM, Benjamin Schollnick wrote: > >> Folks, >> >> I am willing to register a domain or two for the package manager >> systems.. (i.e. Python-packages.org, or etc)... >> >> Would it help? >> >> Any suggestions for domain names? >> >> But I don't have the resources to actual host the site, at this time. >> That's easy enough, I can setup redirection through my domain site... >> >> Any takers? > > If it were something official, I think it should be > packages.python.org (or the like). I don't think there's a real > reason to get a new domain for mac packages, though I will probably > move http://undefined.org/pimp to somewhere at pythonmac.org > eventually. > When the time comes it shouldn't be a problem to get a python.org subdomain. ka From philippe at wwphi.net Sat Mar 20 12:56:41 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Sat Mar 20 12:56:46 2004 Subject: [Pythonmac-SIG] Newbie: Unicode in Python 2.3? Message-ID: Hello, I am trying to use Unicode with the Macosx 10.3 built-in Python 2.3 interpreter. However, I keep getting messages telling me that the character value is not within the right range (128) >>> import codecs >>> alef = unichr(1488) >>> print alef Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character '\u5d0' in position 0: ordinal not in range(128) >>> How can you find out if a particular version of Python supports Unicode or not? Many thanks. Philippe From bob at redivi.com Sat Mar 20 13:29:07 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 20 13:25:24 2004 Subject: [Pythonmac-SIG] Newbie: Unicode in Python 2.3? In-Reply-To: References: Message-ID: <795D6A12-7A9C-11D8-B843-000A95686CD8@redivi.com> On Mar 20, 2004, at 12:56 PM, Philippe de Rochambeau wrote: > I am trying to use Unicode with the Macosx 10.3 built-in Python 2.3 > interpreter. However, I keep getting messages telling me that the > character value is not within the right range (128) > > >>> import codecs > >>> alef = unichr(1488) > >>> print alef > Traceback (most recent call last): > File "", line 1, in ? > UnicodeEncodeError: 'ascii' codec can't encode character '\u5d0' in > position 0: ordinal not in range(128) > >>> > > How can you find out if a particular version of Python supports > Unicode or not? It supports unicode just fine, it just doesn't know your terminal does. Terminal.app is UTF-8 by default. Try this: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys, codecs >>> sys.stdout = codecs.getwriter('utf8')(sys.stdout) >>> print unichr(1488) ? If you want to type UTF-8 into the terminal, you would use something similar with getreader and sys.stdin. -bob From philippe at wwphi.net Sat Mar 20 14:51:33 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Sat Mar 20 14:51:39 2004 Subject: [Pythonmac-SIG] Newbie: Unicode in Python 2.3? In-Reply-To: <795D6A12-7A9C-11D8-B843-000A95686CD8@redivi.com> References: <795D6A12-7A9C-11D8-B843-000A95686CD8@redivi.com> Message-ID: One more question: why 'sys.stdout' in parentheses? On 20 mars 04, at 19:29, Bob Ippolito wrote: > On Mar 20, 2004, at 12:56 PM, Philippe de Rochambeau wrote: > >> I am trying to use Unicode with the Macosx 10.3 built-in Python 2.3 >> interpreter. However, I keep getting messages telling me that the >> character value is not within the right range (128) >> >> >>> import codecs >> >>> alef = unichr(1488) >> >>> print alef >> Traceback (most recent call last): >> File "", line 1, in ? >> UnicodeEncodeError: 'ascii' codec can't encode character '\u5d0' in >> position 0: ordinal not in range(128) >> >>> >> >> How can you find out if a particular version of Python supports >> Unicode or not? > > It supports unicode just fine, it just doesn't know your terminal > does. Terminal.app is UTF-8 by default. Try this: > > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys, codecs > >>> sys.stdout = codecs.getwriter('utf8')(sys.stdout) > >>> print unichr(1488) > ? > > If you want to type UTF-8 into the terminal, you would use something > similar with getreader and sys.stdin. > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1288 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040320/fd0b4aca/attachment.bin From njriley at uiuc.edu Sat Mar 20 15:12:47 2004 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat Mar 20 15:12:53 2004 Subject: [Pythonmac-SIG] Newbie: Unicode in Python 2.3? In-Reply-To: References: <795D6A12-7A9C-11D8-B843-000A95686CD8@redivi.com> Message-ID: <20040320201247.GA37657@uiuc.edu> On Sat, Mar 20, 2004 at 08:51:33PM +0100, Philippe de Rochambeau wrote: > One more question: why 'sys.stdout' in parentheses? Because the result of codecs.getwriter('utf8') is a class, and you're instantiating the class with 'sys.stdout' as a parameter to __init__. Also, it doesn't work very well otherwise :) >>> codecs.getwriter('utf8') sys.stdout File "", line 1 codecs.getwriter('utf8') sys.stdout ^ SyntaxError: invalid syntax -- =Nicholas Riley | From eichin at metacarta.com Sat Mar 20 15:52:40 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Sat Mar 20 15:52:45 2004 Subject: [Pythonmac-SIG] Contextual Menu Plugins? In-Reply-To: Message-ID: <7gsmg31bs7.fsf@pikespeak.metacarta.com> Is it possible to build a Contextual Menu Plugin in python? Or is using a wrapper like BigCat the sane way? (I'm looking for examples, and google hasn't turned up anything about python specifically...) From bob at redivi.com Sat Mar 20 17:04:31 2004 From: bob at redivi.com (Bob Ippolito) Date: Sat Mar 20 17:00:48 2004 Subject: [Pythonmac-SIG] Contextual Menu Plugins? In-Reply-To: <7gsmg31bs7.fsf@pikespeak.metacarta.com> References: <7gsmg31bs7.fsf@pikespeak.metacarta.com> Message-ID: <90BC6E76-7ABA-11D8-B843-000A95686CD8@redivi.com> On Mar 20, 2004, at 3:52 PM, eichin@metacarta.com wrote: > Is it possible to build a Contextual Menu Plugin in python? Or is > using a wrapper like BigCat the sane way? (I'm looking for examples, > and google hasn't turned up anything about python specifically...) It's technically possible, but nobody has done it. It's not exactly easy, as you would need to embed python in a COM-like plugin (written in C, Obj C or C++) that finder loads at runtime. There will probably be some tricky issues with threads and sub interpreters. I've considered doing it myself (for at least two years), but I haven't gotten around to it. -bob From smichr at hotmail.com Sat Mar 20 22:17:25 2004 From: smichr at hotmail.com (C Smith) Date: Sat Mar 20 22:17:49 2004 Subject: [Pythonmac-SIG] alias icon, updating Message-ID: <46AA3E2E-7AE6-11D8-9D05-000393C0D100@hotmail.com> I'm working on a few file/alias related problems right now and after visiting the ADC site and downloading File and Alias pdfs, I haven't yet been able to overcome a few hurdles. Can anyone help? 1) I would like to be able to fix broken aliases. The following will create a broken alias: Start with a file named foo in a folder and another file named fee on the desktop. Now... create alias of fee on the desktop change its name to foo opt-drag foo from the folder onto the desktop to replace it the alias is now broken The Apple docs say that an alias uses an id and a path to try resolve an alias. I suppose the alias is now broken because a file with a new ID and name has been put in place of fee. Am I correct is saying that there is no way to unambiguosly repair the alias at this point? Q: How can I find out the name of the original file to which the alias used to point? 2) the macostools.mkalias function creates a plain vanilla alias icon; the old version of macostools.mkalias created the right type of icon for an alias but it uses a slightly different method than the new version. Does anyone know what info needs to be added to the Alias itself to get the right icon so the new macostools works better? I was trying to figure out how to update Alias information but am not sure how to get the handle to an alias. I thought maybe the "h" below was such a handle (I copied that from the mkalias function) but it doesn't work. ### >>> from Carbon import File >>> from Carbon import Res >>> fsr=File.FSRef('/Users/csmith/Desktop/f') >>> dt=File.FSRef('/Users/csmith/Desktop/') >>> h = Res.FSpOpenResFile(File.FSSpec(a), 3) >>> File.FSUpdateAlias(dt,fsr,h) Traceback (most recent call last): File "", line 1, in ? TypeError: Alias required ### How do I get the Alias that is required by FSUpdateAlias? Thanks for any help, /c From phiroc at free.fr Sat Mar 20 10:28:13 2004 From: phiroc at free.fr (Philippe de Rochambeau) Date: Sun Mar 21 11:27:20 2004 Subject: [Pythonmac-SIG] Unicode Message-ID: <33AED03A-7A83-11D8-9D17-003065D64D74@free.fr> Hello, I can't get python 2.3 to work with unicode strings. For instance, print u"El\xE9phant" results in Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character '\ue9' in position 2: ordinal not in range(128) >>> any help would be much appreciated. Philippe From smiles at saysomething.com Sat Mar 20 21:56:49 2004 From: smiles at saysomething.com (Christopher Smith) Date: Sun Mar 21 11:27:26 2004 Subject: [Pythonmac-SIG] alias icon, updating In-Reply-To: Message-ID: <66127010-7AE3-11D8-9D05-000393C0D100@saysomething.com> I'm working on a few file/alias related problems right now and after visiting the ADC site and downloading File and Alias pdfs, I haven't yet been able to overcome a few hurdles. Can anyone help? 1) I would like to be able to fix broken aliases. The following will create a broken alias: Start with a file named foo in a folder and another file named fee on the desktop. Now... create alias of fee on the desktop change its name to foo opt-drag foo from the folder onto the desktop to replace it the alias is now broken The Apple docs say that an alias uses an id and a path to try resolve an alias. I suppose the alias is now broken because a file with a new ID and name has been put in place of fee. Am I correct is saying that there is no way to unambiguosly repair the alias at this point? Q: How can I find out the name of the original file to which the alias used to point? 2) the macostools.mkalias function creates a plain vanilla alias icon; the old version of macostools.mkalias created the right type of icon for an alias but it uses a slightly different method than the new version. Does anyone know what info needs to be added to the Alias itself to get the right icon so the new macostools works better? I was trying to figure out how to update Alias information but am not sure how to get the handle to an alias. I thought maybe the "h" below was such a handle (I copied that from the mkalias function) but it doesn't work. ### >>> from Carbon import File >>> from Carbon import Res >>> fsr=File.FSRef('/Users/csmith/Desktop/f') >>> dt=File.FSRef('/Users/csmith/Desktop/') >>> h = Res.FSpOpenResFile(File.FSSpec(a), 3) >>> File.FSUpdateAlias(dt,fsr,h) Traceback (most recent call last): File "", line 1, in ? TypeError: Alias required ### How do I get the Alias that is required by FSUpdateAlias? Thanks for any help, /c From jsmith at fugen.com Sun Mar 21 12:19:52 2004 From: jsmith at fugen.com (Jason Smith) Date: Sun Mar 21 12:20:00 2004 Subject: [Pythonmac-SIG] Installing PyObjC-1.0-binary Message-ID: Hello all, I am not exactly sure what I have done to my python installation, I'm hoping that I can get everything back on track. My most immediate problem is that when I try to install the PyObjC-1.0-binary using the package manager I get the following error message: Warning: Install directory "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages" is not writable or not readable As far as background on my system, I had originally installed MacPython on Jaguar, but I am now running Panther (and I think using Apple's python distribution). I don't know if the following will help or not: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> for p in sys.path: print p ... /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python23.zip /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ plat-darwin /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ plat-mac /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ plat-mac/lib-scriptpackages /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ lib-tk /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ lib-dynload /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages >>> Thanks in advance for any advice you can offer. Jason From piet at cs.uu.nl Sun Mar 21 14:10:01 2004 From: piet at cs.uu.nl (Piet van Oostrum) Date: Sun Mar 21 14:09:16 2004 Subject: [Pythonmac-SIG] Installing PyObjC-1.0-binary In-Reply-To: Message-ID: >>>>> Jason Smith (JS) wrote: JS> Hello all, JS> I am not exactly sure what I have done to my python installation, I'm JS> hoping that I can get everything back on track. My most immediate problem JS> is that when I try to install the PyObjC-1.0-binary using the package JS> manager I get the following error message: JS> Warning: Install directory JS> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ JS> python2.3/site-packages" is not writable or not readable It is supposed to be a symbolic link to /Library/Python/2.3 Do a ls -l /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages in Terminal to check. There are some Python packages that can ruin this if you install them. You could restore it with: ln -s ls -l /Library/Python/2.3 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages if site-packages doesn't exist. Otherwise you might have to move the contents of site-packages to /Library/Python/2.3 first. JS> As far as background on my system, I had originally installed MacPython on JS> Jaguar, but I am now running Panther (and I think using Apple's python JS> distribution). I don't know if the following will help or not: JS> Python 2.3 (#1, Sep 13 2003, 00:49:11) JS> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin JS> Type "help", "copyright", "credits" or "license" for more information. >>>> import sys >>>> for p in sys.path: print p JS> ... JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python23.zip JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3 JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ JS> plat-darwin JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ JS> plat-mac JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ JS> plat-mac/lib-scriptpackages JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ JS> lib-tk JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ JS> lib-dynload JS> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ JS> site-packages >>>> This looks OK. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: P.van.Oostrum@hccnet.nl From jsmith at fugen.com Sun Mar 21 15:15:31 2004 From: jsmith at fugen.com (Jason Smith) Date: Sun Mar 21 15:15:48 2004 Subject: [Pythonmac-SIG] Installing PyObjC-1.0-binary In-Reply-To: References: Message-ID: <80F06CBA-7B74-11D8-B3FE-000393D48C10@fugen.com> > It is supposed to be a symbolic link to /Library/Python/2.3 > > Do a ls -l > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages > in Terminal to check. This is what it looks like: $ ls -l /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages lrwxr-xr-x 1 root wheel 42 Oct 27 22:40 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages -> ../../../../../../../../Library/Python/2.3 > There are some Python packages that can ruin this if you install them. > You > could restore it with: > > ln -s ls -l /Library/Python/2.3 > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages > if site-packages doesn't exist. Otherwise you might have to move the > contents of site-packages to /Library/Python/2.3 first. > It appears that the symbolic link is ok. One weird thing I noticed in /Library/Python/2.3 is the "2.3" link, which points to a tmp directory (which doesn't exist). Here are the contents of /Library/Python/2.3 lrwxr-xr-x 1 root admin 35 Mar 15 22:54 2.3 -> /tmp/_py/install/Library/Python/2.3 -rwxrwxr-x 1 jsmith admin 287552 Sep 5 2003 waste.so* drwxr-xr-x 31 root admin 1054 Mar 5 21:56 wx/ drwxrwxr-x 96 root admin 3264 Mar 5 21:56 wxPython/ If I try to install PyObjC "For Current User Only" I get the following: "Not all files were unpacked:" followed by a list of what looks like everything. Do you think it may be a group permission problem? In the /System/.. tree everything looks like it is root.wheel, but in the /Library/.. tree it looks like it has been installed as root.admin. -jason From vze26m98 at optonline.net Mon Mar 22 09:10:25 2004 From: vze26m98 at optonline.net (vze26m98) Date: Mon Mar 22 09:12:11 2004 Subject: [Pythonmac-SIG] More ? on Python Path/Resources... In-Reply-To: Message-ID: <20040322091027-r01010700-1396b2a2-0922-0108@68.193.194.28> Hi Jack- Thanks for your earlier post about the EditPythonPrefs application. I've had a chance to try it out briefly, but I still think I'm missing something. The application does indeed modify the 'STR#' resource in the PythonCoreCarbon, altering the sys.path variables. I think I'm having trouble with setting the $PYTHON variable, however. I've noticed that the MacPython Preferences file in the system folder contains an 'alis' resource that appears to hold the full pathname of the folder that PythonCoreCarbon resides in. PythonCoreCarbon itself has the 'STR#' resource, but no 'alis' resource. It does have an 'STR' resource which contains a PythonPreferenceFilename string which is set to the name of the preferences file. The actual data area ($) for that string is blank in my current setup. As I said, I have an application that is using PythonCoreCarbon in an embedded situation under OSX and it seems not to know about the OS9 Preferences folder. So I'm assuming that when my application runs, it finds an alias in it's startup folder to PythonCoreCarbon in the MacPython directory. PythonCoreCarbon, in turn, it doesn't find the location of the Preferences file, nor does it find what $PYTHON has been set to. So it defaults to my application's startup folder. Do I need to provide the full pathname of the MacPython folder as data to the PythonPreferenceFilename? Or do I need to copy the 'alis' resource in the MacPython Preferences file into PythonCoreCarbon? Perhaps the configuration I'm trying to set up simply isn't possible. Anyway, thaks in advance for any help! Best, Tad Turner From jsmith at fugen.com Tue Mar 23 19:31:40 2004 From: jsmith at fugen.com (Jason Smith) Date: Tue Mar 23 19:31:49 2004 Subject: [Pythonmac-SIG] Installing PyObjC-1.0-binary In-Reply-To: <80F06CBA-7B74-11D8-B3FE-000393D48C10@fugen.com> References: <80F06CBA-7B74-11D8-B3FE-000393D48C10@fugen.com> Message-ID: <9E130FBE-7D2A-11D8-9784-000393D48C10@fugen.com> I figured out what was incorrect on my system, so I thought I would post my solution to provide a nice ending to the thread. /Library/Python was only writable by user (i.e. root), so a simple "chmod -R g+w Python" seems to have solved my problem. Thanks for input Piet :) --jason From Jack.Jansen at cwi.nl Wed Mar 24 05:31:10 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 24 05:31:47 2004 Subject: [Pythonmac-SIG] For your eyes only: 2.3.3 installers finally available Message-ID: <5E23ABB8-7D7E-11D8-9D6A-000A958D1666@cwi.nl> Folks, after many months the MacPython 2.3.3 for Jaguar and MacPython-OS9 2.3.3 installers are finally available. The holdup was a licensing problem with Mindvision Installer Vise, which really only affected the OS9 installer but the OSX installer got accidentally stalled as well. The problem has now been solved by the Python Software Foundation, who have graciously offered to pay for the license. If you want to show your gratitude you can do so at . Anyway, I've put the new installers at . Please try them and report back here whether they work. I will wait until I've had positive feedback on them and then I'll advertise them to a wider audience. -- 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 managan at llnl.gov Wed Mar 24 13:19:37 2004 From: managan at llnl.gov (Rob Managan) Date: Wed Mar 24 13:19:51 2004 Subject: [Pythonmac-SIG] For your eyes only: 2.3.3 installers finally available In-Reply-To: <5E23ABB8-7D7E-11D8-9D6A-000A958D1666@cwi.nl> References: <5E23ABB8-7D7E-11D8-9D6A-000A958D1666@cwi.nl> Message-ID: >Folks, >after many months the MacPython 2.3.3 for Jaguar and MacPython-OS9 >2.3.3 installers are finally available. >The holdup was a licensing problem with Mindvision Installer Vise, >which really only affected the OS9 installer but the OSX installer >got accidentally stalled as well. The problem has now been solved by >the Python Software Foundation, who have graciously offered to pay >for the license. If you want to show your gratitude you can do so at >. > >Anyway, I've put the new installers at >. Please try them and >report back here whether they work. I will wait until I've had >positive feedback on them and then I'll advertise them to a wider >audience. >-- Install went fine and both the IDE and PackageManager open up fine. No extensive tests yet -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From altis at semi-retired.com Wed Mar 24 13:25:02 2004 From: altis at semi-retired.com (Kevin Altis) Date: Wed Mar 24 13:25:09 2004 Subject: [Pythonmac-SIG] For your eyes only: 2.3.3 installers finally available In-Reply-To: <5E23ABB8-7D7E-11D8-9D6A-000A958D1666@cwi.nl> References: <5E23ABB8-7D7E-11D8-9D6A-000A958D1666@cwi.nl> Message-ID: <90A0F447-7DC0-11D8-B346-000A9598382A@semi-retired.com> On Mar 24, 2004, at 2:31 AM, Jack Jansen wrote: > Folks, > after many months the MacPython 2.3.3 for Jaguar and MacPython-OS9 > 2.3.3 installers are finally available. > The holdup was a licensing problem with Mindvision Installer Vise, > which really only affected the OS9 installer but the OSX installer got > accidentally stalled as well. The problem has now been solved by the > Python Software Foundation, who have graciously offered to pay for the > license. If you want to show your gratitude you can do so at > . > > Anyway, I've put the new installers at > . Please try them and report > back here whether they work. I will wait until I've had positive > feedback on them and then I'll advertise them to a wider audience. > I'm running Panther, so I guess there is nothing for me to test ;-) However, I was just thinking about how we have a Mac OS X user base spread across at least three distinct OS versions so far and the confusion this is probably going to cause. If possible, I suggest having the installer check the specific OS version and warn the user about doing an install on Panther and later (do we have to wait until WWDC to find out the name?) and 10.1. For PythonCard I'm going to go ahead and make separate pages for Jaguar and Panther installations, and 10.1 won't be supported at all. ka From pythonmac at gisborne.emailuser.net Wed Mar 24 14:18:12 2004 From: pythonmac at gisborne.emailuser.net (pythonmac@gisborne.emailuser.net) Date: Wed Mar 24 14:26:22 2004 Subject: [Pythonmac-SIG] How to install packages? Message-ID: Panther. Latest update. Installed MacPython extensions for Panther. Installed wxPython for Panther. Go to /Applications/wxPythonOSX-2.4.1.2. Open Demos. Double-click on arbitrary demo. See this: $ "/usr/local/bin/pythonw" "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo Exit status: $? && exit 1 Traceback (most recent call last): File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line 2, in ? ImportError: No module named wxPython.wx Wonder about how to install packages on OS X. Search archives. Find assertion that packages go in /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages Find followup posting in February by Bob saying that: site-packages itself is a symlink to /Library/Python/2.3 Become further confused, because this is quite clearly *not* the case on my system -- the two folders have utterly disparate content. Try copying wxPython folder from /Library/Python/2.3 to /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages Try to run demo again. Same result. Become utterly confused, decide to ask mailing list. Aim to put the answer on the FAQ, where it clearly belongs. From bob at redivi.com Wed Mar 24 14:59:58 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 24 14:56:39 2004 Subject: [Pythonmac-SIG] How to install packages? In-Reply-To: References: Message-ID: On Mar 24, 2004, at 2:18 PM, pythonmac@gisborne.emailuser.net wrote: > Panther. Latest update. > > Installed MacPython extensions for Panther. > > Installed wxPython for Panther. > > Go to /Applications/wxPythonOSX-2.4.1.2. > > Open Demos. Double-click on arbitrary demo. See this: > > $ "/usr/local/bin/pythonw" > "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo Exit > status: $? && exit 1 > Traceback (most recent call last): > File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line 2, > in ? > ImportError: No module named wxPython.wx > > Wonder about how to install packages on OS X. > > Search archives. Find assertion that packages go in > > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages > > Find followup posting in February by Bob saying that: > > site-packages itself is a symlink to /Library/Python/2.3 > > Become further confused, because this is quite clearly *not* the case > on my system -- the two folders have utterly disparate content. > > Try copying wxPython folder from /Library/Python/2.3 to > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages > > Try to run demo again. Same result. > > Become utterly confused, decide to ask mailing list. Aim to put the > answer on the FAQ, where it clearly belongs. It sounds like the wxPython installer, or something else, broke your installation. /System/Library/..../python2.3/site-packages SHOULD BE a symlink to /Library/Python/2.3 -bob From pythonmac at gisborne.emailuser.net Wed Mar 24 15:17:40 2004 From: pythonmac at gisborne.emailuser.net (pythonmac@gisborne.emailuser.net) Date: Wed Mar 24 15:25:38 2004 Subject: [Pythonmac-SIG] (no subject) Message-ID: <4CD83BA6-7DD0-11D8-8E9F-000393C9524C@gisborne.emailuser.net> > On Mar 24, 2004, at 2:18 PM, pythonmac@gisborne.emailuser.net wrote: > >> Panther. Latest update. >> >> Installed MacPython extensions for Panther. >> >> Installed wxPython for Panther. >> >> Go to /Applications/wxPythonOSX-2.4.1.2. >> >> Open Demos. Double-click on arbitrary demo. See this: >> >> $ "/usr/local/bin/pythonw" >> "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo Exit >> status: $? && exit 1 >> Traceback (most recent call last): >> File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line 2, >> in ? >> ImportError: No module named wxPython.wx >> >> Wonder about how to install packages on OS X. >> >> Search archives. Find assertion that packages go in >> >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages >> >> Find followup posting in February by Bob saying that: >> >> site-packages itself is a symlink to /Library/Python/2.3 >> >> Become further confused, because this is quite clearly *not* the case >> on my system -- the two folders have utterly disparate content. >> >> Try copying wxPython folder from /Library/Python/2.3 to >> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages >> >> Try to run demo again. Same result. >> >> Become utterly confused, decide to ask mailing list. Aim to put the >> answer on the FAQ, where it clearly belongs. > > It sounds like the wxPython installer, or something else, broke your > installation. /System/Library/..../python2.3/site-packages SHOULD BE > a symlink to /Library/Python/2.3 > > -bob I remedied that, but I still got the same error. So I reinstalled wxPython. Still got the same error. So I reinstalled MacPython-Panther, then reinstalled wxPython. Still got the same error. From bob at redivi.com Wed Mar 24 15:47:32 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 24 15:44:33 2004 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <4CD83BA6-7DD0-11D8-8E9F-000393C9524C@gisborne.emailuser.net> References: <4CD83BA6-7DD0-11D8-8E9F-000393C9524C@gisborne.emailuser.net> Message-ID: <78FE724E-7DD4-11D8-BB21-000A95686CD8@redivi.com> On Mar 24, 2004, at 3:17 PM, pythonmac@gisborne.emailuser.net wrote: >> On Mar 24, 2004, at 2:18 PM, pythonmac@gisborne.emailuser.net wrote: >> >>> Panther. Latest update. >>> >>> Installed MacPython extensions for Panther. >>> >>> Installed wxPython for Panther. >>> >>> Go to /Applications/wxPythonOSX-2.4.1.2. >>> >>> Open Demos. Double-click on arbitrary demo. See this: >>> >>> $ "/usr/local/bin/pythonw" >>> "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo Exit >>> status: $? && exit 1 >>> Traceback (most recent call last): >>> File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line 2, >>> in ? >>> ImportError: No module named wxPython.wx >>> >>> Wonder about how to install packages on OS X. >>> >>> Search archives. Find assertion that packages go in >>> >>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>> python2.3/site-packages >>> >>> Find followup posting in February by Bob saying that: >>> >>> site-packages itself is a symlink to /Library/Python/2.3 >>> >>> Become further confused, because this is quite clearly *not* the >>> case on my system -- the two folders have utterly disparate content. >>> >>> Try copying wxPython folder from /Library/Python/2.3 to >>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>> python2.3/site-packages >>> >>> Try to run demo again. Same result. >>> >>> Become utterly confused, decide to ask mailing list. Aim to put the >>> answer on the FAQ, where it clearly belongs. >> >> It sounds like the wxPython installer, or something else, broke your >> installation. /System/Library/..../python2.3/site-packages SHOULD BE >> a symlink to /Library/Python/2.3 >> >> -bob > > I remedied that, but I still got the same error. > > So I reinstalled wxPython. Still got the same error. > > So I reinstalled MacPython-Panther, then reinstalled wxPython. Still > got the same error. It's likely that installing wxPython is going to break this symlink every time you do it. MacPython-Panther does not create this symlink (it's there when you install 10.3), so re-installing it won't make a difference. -bob From pythonmac at gisborne.emailuser.net Wed Mar 24 15:49:55 2004 From: pythonmac at gisborne.emailuser.net (pythonmac@gisborne.emailuser.net) Date: Wed Mar 24 15:56:38 2004 Subject: [Pythonmac-SIG] Re:How to install packages? Message-ID: > > On Mar 24, 2004, at 3:17 PM, pythonmac@gisborne.emailuser.net wrote: > >>> On Mar 24, 2004, at 2:18 PM, pythonmac@gisborne.emailuser.net wrote: >>> >>>> Panther. Latest update. >>>> >>>> Installed MacPython extensions for Panther. >>>> >>>> Installed wxPython for Panther. >>>> >>>> Go to /Applications/wxPythonOSX-2.4.1.2. >>>> >>>> Open Demos. Double-click on arbitrary demo. See this: >>>> >>>> $ "/usr/local/bin/pythonw" >>>> "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo Exit >>>> status: $? && exit 1 >>>> Traceback (most recent call last): >>>> File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line >>>> 2, in ? >>>> ImportError: No module named wxPython.wx >>>> >>>> Wonder about how to install packages on OS X. >>>> >>>> Search archives. Find assertion that packages go in >>>> >>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>> python2.3/site-packages >>>> >>>> Find followup posting in February by Bob saying that: >>>> >>>> site-packages itself is a symlink to /Library/Python/2.3 >>>> >>>> Become further confused, because this is quite clearly *not* the >>>> case on my system -- the two folders have utterly disparate >>>> content. >>>> >>>> Try copying wxPython folder from /Library/Python/2.3 to >>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>> python2.3/site-packages >>>> >>>> Try to run demo again. Same result. >>>> >>>> Become utterly confused, decide to ask mailing list. Aim to put the >>>> answer on the FAQ, where it clearly belongs. >>> >>> It sounds like the wxPython installer, or something else, broke your >>> installation. /System/Library/..../python2.3/site-packages SHOULD >>> BE a symlink to /Library/Python/2.3 >>> >>> -bob >> >> I remedied that, but I still got the same error. >> >> So I reinstalled wxPython. Still got the same error. >> >> So I reinstalled MacPython-Panther, then reinstalled wxPython. Still >> got the same error. > > It's likely that installing wxPython is going to break this symlink > every time you do it. MacPython-Panther does not create this symlink > (it's there when you install 10.3), so re-installing it won't make a > difference. > > -bob The link is not broken, even after reinstalling everything. From robin at alldunn.com Wed Mar 24 16:08:06 2004 From: robin at alldunn.com (Robin Dunn) Date: Wed Mar 24 16:08:12 2004 Subject: [Pythonmac-SIG] How to install packages? In-Reply-To: References: Message-ID: <4061F8B6.2030501@alldunn.com> pythonmac@gisborne.emailuser.net wrote: > Panther. Latest update. > > Installed MacPython extensions for Panther. > > Installed wxPython for Panther. > > Go to /Applications/wxPythonOSX-2.4.1.2. > > Open Demos. Double-click on arbitrary demo. See this: > > $ "/usr/local/bin/pythonw" > "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo Exit > status: $? && exit 1 > Traceback (most recent call last): > File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line 2, in ? > ImportError: No module named wxPython.wx > > Wonder about how to install packages on OS X. I believe that wxPython 2.4.1.2 was released before Panther was and it definitly should *not* be used with Panther. The latest 2.4.x is 2.4.2.4 and it had a pacakge built specifically for Panther by Kevin Ollivier which can be downloaded from here: http://prdownloads.sourceforge.net/wxpython/wxPythonOSX-2.4.2.4-Py2.3-panther.dmg?download -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From kevino at tulane.edu Wed Mar 24 16:39:48 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed Mar 24 16:42:41 2004 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <78FE724E-7DD4-11D8-BB21-000A95686CD8@redivi.com> References: <4CD83BA6-7DD0-11D8-8E9F-000393C9524C@gisborne.emailuser.net> <78FE724E-7DD4-11D8-BB21-000A95686CD8@redivi.com> Message-ID: Hi all, In this case, the symlink won't break, because that package is a wxPython built for Jaguar. (And an old version as well.) So everything's going into /Library/Frameworks/Python.... I see Robin already posted a link to the new package. Also, since PythonLauncher is running /usr/local/bin/pythonw, it would seem that the machine has an old Jaguar installation of MacPython on it. So MacPython for Jaguar needs to be removed from the system by following instructions here: http://homepages.cwi.nl/~jack/macpython/uninstall.html Thanks, Kevin On Mar 24, 2004, at 12:47 PM, Bob Ippolito wrote: > > On Mar 24, 2004, at 3:17 PM, pythonmac@gisborne.emailuser.net wrote: > >>> On Mar 24, 2004, at 2:18 PM, pythonmac@gisborne.emailuser.net wrote: >>> >>>> Panther. Latest update. >>>> >>>> Installed MacPython extensions for Panther. >>>> >>>> Installed wxPython for Panther. >>>> >>>> Go to /Applications/wxPythonOSX-2.4.1.2. >>>> >>>> Open Demos. Double-click on arbitrary demo. See this: >>>> >>>> $ "/usr/local/bin/pythonw" >>>> "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo Exit >>>> status: $? && exit 1 >>>> Traceback (most recent call last): >>>> File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line >>>> 2, in ? >>>> ImportError: No module named wxPython.wx >>>> >>>> Wonder about how to install packages on OS X. >>>> >>>> Search archives. Find assertion that packages go in >>>> >>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>> python2.3/site-packages >>>> >>>> Find followup posting in February by Bob saying that: >>>> >>>> site-packages itself is a symlink to /Library/Python/2.3 >>>> >>>> Become further confused, because this is quite clearly *not* the >>>> case on my system -- the two folders have utterly disparate >>>> content. >>>> >>>> Try copying wxPython folder from /Library/Python/2.3 to >>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>> python2.3/site-packages >>>> >>>> Try to run demo again. Same result. >>>> >>>> Become utterly confused, decide to ask mailing list. Aim to put the >>>> answer on the FAQ, where it clearly belongs. >>> >>> It sounds like the wxPython installer, or something else, broke your >>> installation. /System/Library/..../python2.3/site-packages SHOULD >>> BE a symlink to /Library/Python/2.3 >>> >>> -bob >> >> I remedied that, but I still got the same error. >> >> So I reinstalled wxPython. Still got the same error. >> >> So I reinstalled MacPython-Panther, then reinstalled wxPython. Still >> got the same error. > > It's likely that installing wxPython is going to break this symlink > every time you do it. MacPython-Panther does not create this symlink > (it's there when you install 10.3), so re-installing it won't make a > difference. > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From pythonmac at gisborne.emailuser.net Wed Mar 24 16:59:22 2004 From: pythonmac at gisborne.emailuser.net (pythonmac@gisborne.emailuser.net) Date: Wed Mar 24 17:01:01 2004 Subject: [Pythonmac-SIG] Re: How to install packages? Message-ID: <81E8603F-7DDE-11D8-8E9F-000393C9524C@gisborne.emailuser.net> Thanks for this. All now seems to be working. My ultimate aim here is to use all this with Stackless. If anyone has any advice about this, please speak up. I did as you suggested. > From: kevino@tulane.edu > Subject: Re: [Pythonmac-SIG] (no subject) > Date: March 24, 2004 15:39:48 CST > To: bob@redivi.com > Cc: pythonmac@gisborne.emailuser.net, pythonmac-sig@python.org > > Hi all, > > In this case, the symlink won't break, because that package is a > wxPython built for Jaguar. (And an old version as well.) So > everything's going into /Library/Frameworks/Python.... I see Robin > already posted a link to the new package. > > Also, since PythonLauncher is running /usr/local/bin/pythonw, it would > seem that the machine has an old Jaguar installation of MacPython on > it. So MacPython for Jaguar needs to be removed from the system by > following instructions here: > > http://homepages.cwi.nl/~jack/macpython/uninstall.html > > Thanks, > > Kevin > > On Mar 24, 2004, at 12:47 PM, Bob Ippolito wrote: > >> >> On Mar 24, 2004, at 3:17 PM, pythonmac@gisborne.emailuser.net wrote: >> >>>> On Mar 24, 2004, at 2:18 PM, pythonmac@gisborne.emailuser.net wrote: >>>> >>>>> Panther. Latest update. >>>>> >>>>> Installed MacPython extensions for Panther. >>>>> >>>>> Installed wxPython for Panther. >>>>> >>>>> Go to /Applications/wxPythonOSX-2.4.1.2. >>>>> >>>>> Open Demos. Double-click on arbitrary demo. See this: >>>>> >>>>> $ "/usr/local/bin/pythonw" >>>>> "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo >>>>> Exit status: $? && exit 1 >>>>> Traceback (most recent call last): >>>>> File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line >>>>> 2, in ? >>>>> ImportError: No module named wxPython.wx >>>>> >>>>> Wonder about how to install packages on OS X. >>>>> >>>>> Search archives. Find assertion that packages go in >>>>> >>>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>>> python2.3/site-packages >>>>> >>>>> Find followup posting in February by Bob saying that: >>>>> >>>>> site-packages itself is a symlink to /Library/Python/2.3 >>>>> >>>>> Become further confused, because this is quite clearly *not* the >>>>> case on my system -- the two folders have utterly disparate >>>>> content. >>>>> >>>>> Try copying wxPython folder from /Library/Python/2.3 to >>>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>>> python2.3/site-packages >>>>> >>>>> Try to run demo again. Same result. >>>>> >>>>> Become utterly confused, decide to ask mailing list. Aim to put >>>>> the answer on the FAQ, where it clearly belongs. >>>> >>>> It sounds like the wxPython installer, or something else, broke >>>> your installation. /System/Library/..../python2.3/site-packages >>>> SHOULD BE a symlink to /Library/Python/2.3 >>>> >>>> -bob >>> >>> I remedied that, but I still got the same error. >>> >>> So I reinstalled wxPython. Still got the same error. >>> >>> So I reinstalled MacPython-Panther, then reinstalled wxPython. Still >>> got the same error. >> >> It's likely that installing wxPython is going to break this symlink >> every time you do it. MacPython-Panther does not create this symlink >> (it's there when you install 10.3), so re-installing it won't make a >> difference. >> >> -bob >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > From bob at redivi.com Wed Mar 24 20:57:52 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 24 20:54:31 2004 Subject: [Pythonmac-SIG] Re: How to install packages? In-Reply-To: <81E8603F-7DDE-11D8-8E9F-000393C9524C@gisborne.emailuser.net> References: <81E8603F-7DDE-11D8-8E9F-000393C9524C@gisborne.emailuser.net> Message-ID: wxWindows plays nicely with Stackless, at least on Win32. I've personally seen Christian demo it working ;) As far as Stackless on OS X is concerned, if you can wait a while (short number of weeks, probably), then I will be putting out a nice framework build. I'm (a) currently at PyCon and don't have time and (b) am waiting for the dust to settle from the sprint in Berlin last week. That said, it does work fine if you want to compile it yourself, so long as you use a recent release (CVS HEAD is best, probably). -bob On Mar 24, 2004, at 4:59 PM, pythonmac@gisborne.emailuser.net wrote: > Thanks for this. All now seems to be working. > > My ultimate aim here is to use all this with Stackless. If anyone has > any advice about this, please speak up. > > I did as you suggested. > >> From: kevino@tulane.edu >> Subject: Re: [Pythonmac-SIG] (no subject) >> Date: March 24, 2004 15:39:48 CST >> To: bob@redivi.com >> Cc: pythonmac@gisborne.emailuser.net, pythonmac-sig@python.org >> >> Hi all, >> >> In this case, the symlink won't break, because that package is a >> wxPython built for Jaguar. (And an old version as well.) So >> everything's going into /Library/Frameworks/Python.... I see Robin >> already posted a link to the new package. >> >> Also, since PythonLauncher is running /usr/local/bin/pythonw, it >> would seem that the machine has an old Jaguar installation of >> MacPython on it. So MacPython for Jaguar needs to be removed from the >> system by following instructions here: >> >> http://homepages.cwi.nl/~jack/macpython/uninstall.html >> >> Thanks, >> >> Kevin >> >> On Mar 24, 2004, at 12:47 PM, Bob Ippolito wrote: >> >>> >>> On Mar 24, 2004, at 3:17 PM, pythonmac@gisborne.emailuser.net wrote: >>> >>>>> On Mar 24, 2004, at 2:18 PM, pythonmac@gisborne.emailuser.net >>>>> wrote: >>>>> >>>>>> Panther. Latest update. >>>>>> >>>>>> Installed MacPython extensions for Panther. >>>>>> >>>>>> Installed wxPython for Panther. >>>>>> >>>>>> Go to /Applications/wxPythonOSX-2.4.1.2. >>>>>> >>>>>> Open Demos. Double-click on arbitrary demo. See this: >>>>>> >>>>>> $ "/usr/local/bin/pythonw" >>>>>> "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.pyc" && echo >>>>>> Exit status: $? && exit 1 >>>>>> Traceback (most recent call last): >>>>>> File "/Applications/wxPythonOSX-2.4.1.2/demo/wxButton.py", line >>>>>> 2, in ? >>>>>> ImportError: No module named wxPython.wx >>>>>> >>>>>> Wonder about how to install packages on OS X. >>>>>> >>>>>> Search archives. Find assertion that packages go in >>>>>> >>>>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>>>> python2.3/site-packages >>>>>> >>>>>> Find followup posting in February by Bob saying that: >>>>>> >>>>>> site-packages itself is a symlink to /Library/Python/2.3 >>>>>> >>>>>> Become further confused, because this is quite clearly *not* the >>>>>> case on my system -- the two folders have utterly disparate >>>>>> content. >>>>>> >>>>>> Try copying wxPython folder from /Library/Python/2.3 to >>>>>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>>>>> python2.3/site-packages >>>>>> >>>>>> Try to run demo again. Same result. >>>>>> >>>>>> Become utterly confused, decide to ask mailing list. Aim to put >>>>>> the answer on the FAQ, where it clearly belongs. >>>>> >>>>> It sounds like the wxPython installer, or something else, broke >>>>> your installation. /System/Library/..../python2.3/site-packages >>>>> SHOULD BE a symlink to /Library/Python/2.3 >>>>> >>>>> -bob >>>> >>>> I remedied that, but I still got the same error. >>>> >>>> So I reinstalled wxPython. Still got the same error. >>>> >>>> So I reinstalled MacPython-Panther, then reinstalled wxPython. >>>> Still got the same error. >>> >>> It's likely that installing wxPython is going to break this symlink >>> every time you do it. MacPython-Panther does not create this >>> symlink (it's there when you install 10.3), so re-installing it >>> won't make a difference. >>> >>> -bob >>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From stuart at stuartbishop.net Thu Mar 25 02:27:42 2004 From: stuart at stuartbishop.net (Stuart Bishop) Date: Thu Mar 25 02:28:26 2004 Subject: [Pythonmac-SIG] Unicode In-Reply-To: <33AED03A-7A83-11D8-9D17-003065D64D74@free.fr> References: <33AED03A-7A83-11D8-9D17-003065D64D74@free.fr> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/03/2004, at 2:28 AM, Philippe de Rochambeau wrote: > Hello, > > I can't get python 2.3 to work with unicode strings. For instance, > > print u"El\xE9phant" > > results in > > Traceback (most recent call last): > File "", line 1, in ? > UnicodeEncodeError: 'ascii' codec can't encode character '\ue9' in > position 2: ordinal not in range(128) > >>> > > any help would be much appreciated. You can't output a Unicode string without encoding it. print u'El\xE9phant'.encode('utf8') Replace utf8 with the character set your terminal window is configured to use (Cmd-I and select 'display'). I'd suggest setting this to utf8 as this can encode all Unicode strings, unlike other common ones like latin-1, macroman or cp1252. - -- Stuart Bishop http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAYon0AfqZj7rGN0oRAhd5AKCQKWah7HhBCrQ0xTL+nbiTiDSy+QCeL620 +REVAMLt8aTsHQ7Ror5sbDk= =tYrn -----END PGP SIGNATURE----- From smichr at hotmail.com Thu Mar 25 10:25:09 2004 From: smichr at hotmail.com (C Smith) Date: Thu Mar 25 10:25:50 2004 Subject: [Pythonmac-SIG] Re: For your eyes only: 2.3.3 installers finally available In-Reply-To: Message-ID: <99DF2A3A-7E70-11D8-8784-000393C0D100@hotmail.com> The installer worked fine. A couple (very minor) comments: I'm a little confused as to why this has OS9 in its name when it runs fine under OS X, not in classic mode. Maybe "9 and X" would be a better name? I was happy to see that scripts that I have are showing up in the Script menu, but I have no idea how Python is finding them. They are in the Frameworks/.../2.3 folder and I don't see the Frameworks paths in sys.path. I'm also a bit confused as to which modules I should keep when there are modules duplicated in the Frameworks folders and now this new MacPython-OS9 folder. Python is finding my scripts there...it won't also find modules there, will it? In editpythonprefs: -'on error exit' is too wide for text area in the editpythonprefs default startup dialog and wraps to two lines and is partially obscurred. -the word Cancel doesn't show up well, either. -there is an option to warn about old division; what do you have to do to get this warning? /c From p.oberndoerfer at urheberrecht.org Thu Mar 25 11:47:40 2004 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Thu Mar 25 11:48:28 2004 Subject: [Pythonmac-SIG] Distinguish between 8.6 and 9.x Message-ID: Hello, what is the best/safest way to determine if my MacPython-OS9 is running on a 8.6 or 9.x machine? Searching for ':Applications (Mac OS 9)' via macpath.exists? And how would I get the name of ? Are there better approaches? I am sure there are... Thanks a lot! Pascal From Jack.Jansen at cwi.nl Thu Mar 25 15:33:44 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Mar 25 15:33:45 2004 Subject: [Pythonmac-SIG] Distinguish between 8.6 and 9.x In-Reply-To: References: Message-ID: On 25 Mar 2004, at 17:47, Pascal Oberndoerfer wrote: > Hello, > > what is the best/safest way to determine if my MacPython-OS9 is > running on a > 8.6 or 9.x machine? Use the gestalt module. There's various selectors you can use to get exact details, but 'sysv' is probably good enough for what you want. For me it returns 0x1033, I assume for you it will return 0x860 or 0x922 or something similar. -- 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 philippe at wwphi.net Fri Mar 26 07:47:26 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Fri Mar 26 07:47:32 2004 Subject: [Pythonmac-SIG] after Message-ID: Hello, the following tcl/tk code displays a window, then closes it while exiting: #!/usr/bin/wish button .hello -text Hello \ -command { puts stdout "Hello World!" } pack .hello -padx 20 -pady 20 after 3000 destroy . The equivalent python/tkinter does not work. Any idea why? #!/usr/bin/python from Tkinter import * def hello(): print "Hello World!" root = Tk() Button(root, text='Hello', command=hello).\ pack(padx=20, pady=20) root.after(3000, root.destroy()) root.mainloop() # Result : macpython icon appears in Dock for # several seconds, then quits -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 686 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040326/2020aba7/attachment.bin From bob at redivi.com Fri Mar 26 08:53:57 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 26 08:51:27 2004 Subject: [Pythonmac-SIG] after In-Reply-To: References: Message-ID: <06F2E668-7F2D-11D8-8824-000A95686CD8@redivi.com> On Mar 26, 2004, at 7:47 AM, Philippe de Rochambeau wrote: > Hello, > > the following tcl/tk code displays a window, then closes it while > exiting: > > #!/usr/bin/wish > > button .hello -text Hello \ > -command { puts stdout "Hello World!" } > pack .hello -padx 20 -pady 20 > > after 3000 destroy . > > The equivalent python/tkinter does not work. Any idea why? > > #!/usr/bin/python > > from Tkinter import * > > def hello(): > print "Hello World!" > > root = Tk() > Button(root, text='Hello', command=hello).\ > pack(padx=20, pady=20) > root.after(3000, root.destroy()) > root.mainloop() > > # Result : macpython icon appears in Dock for > # several seconds, then quits I dunno, but if you take out the "root.after(3000, root.destroy())" it works about as well as you would expect. BTW, you probably should learn another GUI framework, Tcl/Tk is pretty buggy on OS X. -bob From philippe at wwphi.net Fri Mar 26 13:39:07 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Fri Mar 26 13:39:14 2004 Subject: [Pythonmac-SIG] run Message-ID: Does anyone know what the "run" library is exactly (it is used in some of the wxPython examples)? I could not find any info on it either in the python or in the wxwindows doc. Many thanks. pr From claird at lairds.com Fri Mar 26 13:51:04 2004 From: claird at lairds.com (Cameron Laird) Date: Fri Mar 26 13:54:25 2004 Subject: [Pythonmac-SIG] after In-Reply-To: <06F2E668-7F2D-11D8-8824-000A95686CD8@redivi.com> Message-ID: > From pythonmac-sig-bounces@python.org Fri Mar 26 08:51:44 2004 > Envelope-to: claird@lairds.com > In-Reply-To: > References: > Mime-Version: 1.0 (Apple Message framework v613) > From: Bob Ippolito > . > . > . > works about as well as you would expect. BTW, you probably should > learn another GUI framework, Tcl/Tk is pretty buggy on OS X. > . > . > . ? I do a fair amount of GUI development for Windows and Linux--and I mostly program on a MacOS, using Tcl/Tk. The Tcl/Tk installations for MacOS X have improved a LOT over the last year. I frankly don't know what you have in mind for "pretty buggy". The tcl-mac mailing list is plenty active, and I'm sure any problems you encounter would be appropriately welcomed there, or in the Source- Forge fault database. From gherman at darwin.in-berlin.de Sat Mar 27 04:14:34 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Sat Mar 27 04:09:44 2004 Subject: [Pythonmac-SIG] Apple baseline configuration app? Message-ID: <29B96BF8-7FCF-11D8-85DD-00039345C610@darwin.in-berlin.de> Hi, this might look like a weird inquiry, but I'm actually trying to figure out which Apple application is started after instal- ling OS X from scratch that is used for baseline configuration, i.e. settings for the first user account, language & time zone, internet access, email, etc. I guess there should be such an app, but I can't locate it, may- be because it removes itself after running once? In certain ca- ses it might make sense to rerun it, though. Ideally, I'd like to do what that app is doing in a non-GUI Py- thon clone which I'd like to run from outside on "virgin" in- stallations on other volumes for test purposes. Thanks, Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The best way to predict the future is to invent it." (Alan Kay) From gherman at darwin.in-berlin.de Sat Mar 27 05:39:24 2004 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Sat Mar 27 05:34:29 2004 Subject: [Pythonmac-SIG] Apple baseline configuration app? In-Reply-To: <29B96BF8-7FCF-11D8-85DD-00039345C610@darwin.in-berlin.de> Message-ID: <0376B6CD-7FDB-11D8-85DD-00039345C610@darwin.in-berlin.de> I wrote: > I guess there should be such an app, but I can't locate it, may- > be because it removes itself after running once? In certain ca- > ses it might make sense to rerun it, though. Ok, it's here: ./System/Library/CoreServices/Setup Assistant.app > Ideally, I'd like to do what that app is doing in a non-GUI Py- > thon clone which I'd like to run from outside on "virgin" in- > stallations on other volumes for test purposes. But this is the more interesting step, digging into NetInfo etc, without actually having a user, except root, maybe... Dinu From smichr at hotmail.com Sat Mar 27 23:42:45 2004 From: smichr at hotmail.com (C Smith) Date: Sat Mar 27 23:43:17 2004 Subject: [Pythonmac-SIG] path name issues Message-ID: <5B89FB45-8072-11D8-A69B-000393C0D100@hotmail.com> I've noticed a wrinkle in Python operations regarding path names and some modules and am wondering how you all deal with the issue. EasyDialogs gives back path names with colons in them and functions in macpath think that paths have colons (and os.sep thinks the separator is a colon, too). What are people doing to handle this in scripts? I tend to hardcode in the volume name (macintosh hd) after changing all the '/'s to ':'. Is there a better way to get the volume name? (I'm nervous about using mac.getcwd because the directory could be changed to a different volume in a program, couldn't it?) I have really appreciated the transparent handling of line returns in scripts coming from different platforms. How big of an issue is it to try get the same treatment for path names? /c Putting http://wecanstopspam.org in your email helps it pass through overzealous spam filters. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1006 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040327/5c123e78/attachment.bin From rroberts at adobe.com Mon Mar 29 19:06:52 2004 From: rroberts at adobe.com (Read Roberts) Date: Mon Mar 29 19:07:19 2004 Subject: [Pythonmac-SIG] Problem with compiling frozen module as bundle, bundle_loader option, and CodeWarrior Message-ID: I have a 'frozen' python script that compiles nicely as a Mach-0 bundle library with gcc, and is looadable as such by any random Mac program. However, I have run into a glitch with converting to CodeWarrior. The Python script uses the 'os' module. This in turn loads the 'posix' module, and one of the setup functions in 'posix' references the symbol 'environ'. 'environ' is defined only in the crt.0 library that is linked only into applications. As a result, in order to compile my bundle library, I have to use the 'gcc' option ' -bundle-loader ' so that the gcc linker will find a source for the symbol 'environ'. Now, I need to do the same thing in CodeWarrior, but I have not been able to find any way to set this option. Can any one tell me how to do this in CodeWarrior 9.1? I did find an alarming e-mail as of 5.13.2003 which commented that CW 8.x is missing this feature, but haven't been able to confirm it, or confirm with respect to CW 9.1 P.S. My bundles that link with Python also are missing the symbol '_file'. Can anyone tell me where that comes from? My project contains the frameworks Python , Carbon, and System, and the bundle1.o object file. From bob at redivi.com Mon Mar 29 20:01:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Mar 29 19:57:13 2004 Subject: [Pythonmac-SIG] Problem with compiling frozen module as bundle, bundle_loader option, and CodeWarrior In-Reply-To: References: Message-ID: On Mar 29, 2004, at 7:06 PM, Read Roberts wrote: > I have a 'frozen' python script that compiles nicely as a Mach-0 > bundle library with gcc, and is looadable as such by any random Mac > program. However, I have run into a glitch with converting to > CodeWarrior. > > The Python script uses the 'os' module. This in turn loads the 'posix' > module, and one of the setup functions in 'posix' references the > symbol 'environ'. 'environ' is defined only in the crt.0 library that > is linked only into applications. As a result, in order to compile my > bundle library, I have to use the 'gcc' option ' -bundle-loader application>' so that the gcc linker will find a source for the symbol > 'environ'. > > Now, I need to do the same thing in CodeWarrior, but I have not been > able to find any way to set this option. Can any one tell me how to do > this in CodeWarrior 9.1? > > I did find an alarming e-mail as of 5.13.2003 which commented that CW > 8.x is missing this feature, but haven't been able to confirm it, or > confirm with respect to CW 9.1 > > P.S. My bundles that link with Python also are missing the symbol > '_file'. Can anyone tell me where that comes from? My project contains > the frameworks Python , Carbon, and System, and the bundle1.o object > file. What's wrong with the application bundle approach? It's much easier to deal with... I don't know anything at all about CW, but the way you are supposed to find symbols like _environ from a shared library or bundle is to use the accessor functions (see /usr/include/crt_externs.h). It's entirely likely that the "freeze" functionality just doesn't understand the Mach-O way to do it, because all of the development effort has been on the application bundle approach. -bob From rroberts at adobe.com Tue Mar 30 00:22:00 2004 From: rroberts at adobe.com (Read Roberts) Date: Tue Mar 30 00:39:33 2004 Subject: [Pythonmac-SIG] Problem with compiling frozen module as bundle, bundle_loader option, and CodeWarrior In-Reply-To: References: Message-ID: Thank you for your response! This was very useful, and gets me past my blocking problem. Since I am compiling with two-level name-space, I can easily, without conflicting with the host application's definition of 'environ', declare a global variable 'environ' in my C wrapper for the frozen Python bundle, and initialize it to a real value on entry with the NSGetEnviron(). Even more usefully, this sent me back to the posix module, where I now notice that if I had compiled with the preprocessor def WITH_NEXT_FRAMEWORK, then posix.c would have declared a static variable 'environ' and initialized it with NSGetEnviron (). I built the Python for use with my freeze module with the '--enable-framework' option off, since I wanted bundles rather than dylibs. As a result, WITH_NEXT_FRAMEWORK does not get set. Could there be another macro definition for special-casing access to teh environ symbol that would depend only on the host environment being MACH-0, and not on building a framework based Python? Also, I am not clear if I can get the static Python library that I need if I turn the '--enable-framework' option on; I will try this as well. I am forced to build a bundle file since I need a loadable library that can be loaded/unloaded by several different applications, and will be distributed as a separate plug-in from any of the applications, and I do not have access to the build environments of the target applications. Thank you again for your help. I am still curious if anyone knows whether CodeWarrior supports an equivalent of the gcc '-bundle_loader' option, although I no longer immediately need this information. At 20:01 -0500 3/29/04, Bob Ippolito wrote: >On Mar 29, 2004, at 7:06 PM, Read Roberts wrote: > >> I have a 'frozen' python script that compiles nicely as a Mach-0 >>bundle library with gcc, and is looadable as such by any random >>Mac program. However, I have run into a glitch with converting to >>CodeWarrior. >> >> The Python script uses the 'os' module. This in turn loads the >>'posix' module, and one of the setup functions in 'posix' >>references the symbol 'environ'. 'environ' is defined only in the >>crt.0 library that is linked only into applications. As a result, >>in order to compile my bundle library, I have to use the 'gcc' >>option ' -bundle-loader ' so that the gcc linker >>will find a source for the symbol 'environ'. >> >> Now, I need to do the same thing in CodeWarrior, but I have not >>been able to find any way to set this option. Can any one tell me >>how to do this in CodeWarrior 9.1? >> >> I did find an alarming e-mail as of 5.13.2003 which commented >>that CW 8.x is missing this feature, but haven't been able to >>confirm it, or confirm with respect to CW 9.1 >> >> P.S. My bundles that link with Python also are missing the symbol >>'_file'. Can anyone tell me where that comes from? My project >>contains the frameworks Python , Carbon, and System, and the >>bundle1.o object file. > >What's wrong with the application bundle approach? It's much easier >to deal with... > >I don't know anything at all about CW, but the way you are supposed >to find symbols like _environ from a shared library or bundle is to >use the accessor functions (see /usr/include/crt_externs.h). It's >entirely likely that the "freeze" functionality just doesn't >understand the Mach-O way to do it, because all of the development >effort has been on the application bundle approach. > >-bob -- ----------------------------------------------------------------------------------------- Read K. Roberts rroberts@adobe.com Adobe Systems San Jose TW12 (408)-536-4402 on Weds San Francisco (415) 642-5642 Mon, Tues, Thurs, Fri From philippe at wwphi.net Tue Mar 30 10:59:34 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Tue Mar 30 10:59:41 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp Message-ID: <3CDFA9DE-8263-11D8-AD12-003065D64D74@wwphi.net> Hello, I know this has nothing to do with MacPython, but does anyone know what the Darwin equivalent to Linux's /dev/tcp is ? Many thanks. PR From bob at redivi.com Tue Mar 30 11:20:17 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 30 11:16:19 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp In-Reply-To: <3CDFA9DE-8263-11D8-AD12-003065D64D74@wwphi.net> References: <3CDFA9DE-8263-11D8-AD12-003065D64D74@wwphi.net> Message-ID: <21C743B4-8266-11D8-93BA-000A95686CD8@redivi.com> On Mar 30, 2004, at 10:59 AM, Philippe de Rochambeau wrote: > I know this has nothing to do with MacPython, but does anyone know > what the Darwin equivalent to Linux's /dev/tcp is ? How about a quick explanation of what you would like to do with it? Chances are, there isn't some "thing" that is 1:1 with /dev/tcp in Darwin anyways (I also don't know what /dev/tcp does off the top of my head). -bob From mt at motiontek.com Tue Mar 30 13:14:01 2004 From: mt at motiontek.com (Michael Tuminello) Date: Tue Mar 30 13:14:05 2004 Subject: [Pythonmac-SIG] newbie bundlebuilder question Message-ID: <055459B1-8276-11D8-A39C-003065BA7978@motiontek.com> Hello all - I am a complete novice, and I should probably read the docs for a couple days before posting, but i was hoping to get a quick pointer (or boot, as the case may be) in the right direction from the list, as i just want to accomplish something that may be trivial in the short term. I am trying to bundle an app using bundlebuilder, as per instructions on the wiki. this file runs with pythonw main.pyw just fine. when I try to bundle it I get: Warning: couldn't find the following submodules: (Note that these could be false alarms -- it's not always possible to distinguish between "from package import submodule" and "from package import name") ? OverrideFrom23._Res ? java.lang ? os.path ? win32com.shell ? wxPython.iewin Warning: couldn't find the following modules: ? SOCKS ? _xmlplus ? clip_dndc ? cmndlgsc ? controls2c ? controlsc ? eventsc ? filesysc ? fontsc ? framesc ? gdic ? imagec ? mdic ? misc2c ? miscc ? msvcrt ? poll ? printfwc ? pythoncom ? rourl2path ? sizersc ? stattoolc ? streamsc ? utilsc ? windows2c ? windows3c ? windowsc I was hoping someone could point me in the right direction to getting these modules in correctly. I have only the barest notion of what I'm doing at this point, but would love to just get this sucker packaged and get caught up later. thanks- MT From bob at redivi.com Tue Mar 30 13:42:14 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 30 13:38:15 2004 Subject: [Pythonmac-SIG] newbie bundlebuilder question In-Reply-To: <055459B1-8276-11D8-A39C-003065BA7978@motiontek.com> References: <055459B1-8276-11D8-A39C-003065BA7978@motiontek.com> Message-ID: On Mar 30, 2004, at 1:14 PM, Michael Tuminello wrote: > I am a complete novice, and I should probably read the docs for a > couple days before posting, but i was hoping to get a quick pointer > (or boot, as the case may be) in the right direction from the list, as > i just want to accomplish something that may be trivial in the short > term. > > I am trying to bundle an app using bundlebuilder, as per instructions > on the wiki. this file runs with pythonw main.pyw just fine. > > when I try to bundle it I get: > > Warning: couldn't find the following submodules: > (Note that these could be false alarms -- it's not always > possible to distinguish between "from package import submodule" > and "from package import name") --- > Warning: couldn't find the following modules: --- > > I was hoping someone could point me in the right direction to getting > these modules in correctly. I have only the barest notion of what I'm > doing at this point, but would love to just get this sucker packaged > and get caught up later. These are warnings, not errors. A lot of the modules listed don't even apply to the mac, and it tries to find them because the code you are doing references them directly or indirectly (probably in platform checks). Just ignore them, and ask questions when/if the app bundle doesn't work. -bob From bob at redivi.com Tue Mar 30 13:54:06 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 30 13:50:03 2004 Subject: [Pythonmac-SIG] newbie bundlebuilder question In-Reply-To: <292A2DC5-827A-11D8-A39C-003065BA7978@motiontek.com> References: <055459B1-8276-11D8-A39C-003065BA7978@motiontek.com> <292A2DC5-827A-11D8-A39C-003065BA7978@motiontek.com> Message-ID: <9EF1DECC-827B-11D8-A68D-000A95686CD8@redivi.com> Either start it up from the command-line or look in Console. Presumably it will fail with some traceback that tells you what is missing. Have you read the bundlebuilder tutorial on the wiki ( http://pythonmac.org/wiki/BundleBuilder )? On Mar 30, 2004, at 1:43 PM, Michael Tuminello wrote: > yeah, it doesn't work. :-) > > where do I start investigating why it isn't working? when you fire up > a bundled app, is there some way to find out how it's failing? a log > or somethng? it appears to start (zoom-rects on double-click), but > does nothing. bundling as semistandalone causes it to get slightly > further (briefly shows up as an active app) > > thanks - > > Michael > > On Mar 30, 2004, at 1:42 PM, Bob Ippolito wrote: > >> >> These are warnings, not errors. A lot of the modules listed don't >> even apply to the mac, and it tries to find them because the code you >> are doing references them directly or indirectly (probably in >> platform checks). Just ignore them, and ask questions when/if the >> app bundle doesn't work. >> >> -bob >> > From kevino at tulane.edu Tue Mar 30 14:03:44 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Tue Mar 30 14:07:18 2004 Subject: [Pythonmac-SIG] newbie bundlebuilder question In-Reply-To: <9EF1DECC-827B-11D8-A68D-000A95686CD8@redivi.com> References: <055459B1-8276-11D8-A39C-003065BA7978@motiontek.com> <292A2DC5-827A-11D8-A39C-003065BA7978@motiontek.com> <9EF1DECC-827B-11D8-A68D-000A95686CD8@redivi.com> Message-ID: Hi, There's also another tutorial on BundleBuilder here, and this one has an example of how to wrap a wxPython application near the end of it: http://www.python.org/cgi-bin/moinmoin/BundleBuilder (Note specifically the libs section at the bottom, as currently you have to add the wxPython libs to the bundle manually.) Thanks, Kevin On Mar 30, 2004, at 10:54 AM, Bob Ippolito wrote: > Either start it up from the command-line or look in Console. > Presumably it will fail with some traceback that tells you what is > missing. Have you read the bundlebuilder tutorial on the wiki ( > http://pythonmac.org/wiki/BundleBuilder )? > > On Mar 30, 2004, at 1:43 PM, Michael Tuminello wrote: > >> yeah, it doesn't work. :-) >> >> where do I start investigating why it isn't working? when you fire up >> a bundled app, is there some way to find out how it's failing? a log >> or somethng? it appears to start (zoom-rects on double-click), but >> does nothing. bundling as semistandalone causes it to get slightly >> further (briefly shows up as an active app) >> >> thanks - >> >> Michael >> >> On Mar 30, 2004, at 1:42 PM, Bob Ippolito wrote: >> >>> >>> These are warnings, not errors. A lot of the modules listed don't >>> even apply to the mac, and it tries to find them because the code >>> you are doing references them directly or indirectly (probably in >>> platform checks). Just ignore them, and ask questions when/if the >>> app bundle doesn't work. >>> >>> -bob >>> >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From philippe at wwphi.net Tue Mar 30 14:44:27 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Tue Mar 30 14:44:34 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp In-Reply-To: <21C743B4-8266-11D8-93BA-000A95686CD8@redivi.com> References: <3CDFA9DE-8263-11D8-AD12-003065D64D74@wwphi.net> <21C743B4-8266-11D8-93BA-000A95686CD8@redivi.com> Message-ID: The book "Linux shell scripting with Bash" says that you can open network connections with /dev/tcp as in exec 3<> /dev/tcp/localhost/80 The author then gives an example in shell script of how to use /dev/tcp to connect to a webserver. I just wanted to investigating this as an alternative to a Python + httplib + wxWindows script which I wrote. Philippe On 30 mars 04, at 18:20, Bob Ippolito wrote: > On Mar 30, 2004, at 10:59 AM, Philippe de Rochambeau wrote: > >> I know this has nothing to do with MacPython, but does anyone know >> what the Darwin equivalent to Linux's /dev/tcp is ? > > How about a quick explanation of what you would like to do with it? > Chances are, there isn't some "thing" that is 1:1 with /dev/tcp in > Darwin anyways (I also don't know what /dev/tcp does off the top of my > head). > > -bob > From claird at lairds.com Tue Mar 30 15:03:13 2004 From: claird at lairds.com (Cameron Laird) Date: Tue Mar 30 15:06:31 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp In-Reply-To: Message-ID: > From pythonmac-sig-bounces@python.org Tue Mar 30 14:44:53 2004 > . > . > . > The book "Linux shell scripting with Bash" says that you can open > network connections with /dev/tcp as in > exec 3<> /dev/tcp/localhost/80 > The author then gives an example in shell script of how to use /dev/tcp > to connect to a webserver. > I just wanted to investigating this as an alternative to a Python + > httplib + wxWindows script which I wrote. > . > . > . Oh, *that*; I would have summarized that in quite different words. I'm far more often involved in moving people from *sh to Python, rather than the other way around. Let's give this a try, though. Anyway, /dev/tcp isn't a "real" inode, it's just a syntax bash and ksh use for networking. So, if I understand you correctly, you want to do a bit of socket programming under MacOS X with bash. Well, that's easy enough ... no, wait; is all you want to script downloading of a few http: documents? I think there's an even easier way to achieve that. From mt at motiontek.com Tue Mar 30 15:09:58 2004 From: mt at motiontek.com (Michael Tuminello) Date: Tue Mar 30 15:09:57 2004 Subject: [Pythonmac-SIG] newbie bundlebuilder question In-Reply-To: References: <055459B1-8276-11D8-A39C-003065BA7978@motiontek.com> <292A2DC5-827A-11D8-A39C-003065BA7978@motiontek.com> <9EF1DECC-827B-11D8-A68D-000A95686CD8@redivi.com> Message-ID: <37D57896-8286-11D8-A39C-003065BA7978@motiontek.com> hey - that was enough to get me there. it runs! thanks! working on this, in case anyone is looking for an extra project... :-) www.sourceforge.net/projects/sepy Michael On Mar 30, 2004, at 2:03 PM, Kevin Ollivier wrote: > Hi, > > There's also another tutorial on BundleBuilder here, and this one has > an example of how to wrap a wxPython application near the end of it: > > http://www.python.org/cgi-bin/moinmoin/BundleBuilder > > (Note specifically the libs section at the bottom, as currently you > have to add the wxPython libs to the bundle manually.) > > Thanks, > > Kevin > > On Mar 30, 2004, at 10:54 AM, Bob Ippolito wrote: > >> Either start it up from the command-line or look in Console. >> Presumably it will fail with some traceback that tells you what is >> missing. Have you read the bundlebuilder tutorial on the wiki ( >> http://pythonmac.org/wiki/BundleBuilder )? >> >> On Mar 30, 2004, at 1:43 PM, Michael Tuminello wrote: >> >>> yeah, it doesn't work. :-) >>> >>> where do I start investigating why it isn't working? when you fire >>> up a bundled app, is there some way to find out how it's failing? a >>> log or somethng? it appears to start (zoom-rects on double-click), >>> but does nothing. bundling as semistandalone causes it to get >>> slightly further (briefly shows up as an active app) >>> >>> thanks - >>> >>> Michael >>> >>> On Mar 30, 2004, at 1:42 PM, Bob Ippolito wrote: >>> >>>> >>>> These are warnings, not errors. A lot of the modules listed don't >>>> even apply to the mac, and it tries to find them because the code >>>> you are doing references them directly or indirectly (probably in >>>> platform checks). Just ignore them, and ask questions when/if the >>>> app bundle doesn't work. >>>> >>>> -bob >>>> >>> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > From sdm7g at mac.com Tue Mar 30 15:17:03 2004 From: sdm7g at mac.com (Steven D. Majewski) Date: Tue Mar 30 15:19:09 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp In-Reply-To: References: Message-ID: <35A8943A-8287-11D8-B2A3-000A95812E94@mac.com> On Mar 30, 2004, at 3:03 PM, Cameron Laird wrote: >> From pythonmac-sig-bounces@python.org Tue Mar 30 14:44:53 2004 >> . >> . >> . >> The book "Linux shell scripting with Bash" says that you can open >> network connections with /dev/tcp as in > >> exec 3<> /dev/tcp/localhost/80 > >> The author then gives an example in shell script of how to use >> /dev/tcp >> to connect to a webserver. > >> I just wanted to investigating this as an alternative to a Python + >> httplib + wxWindows script which I wrote. >> . >> . >> . > Oh, *that*; I would have summarized that in quite different words. > > I'm far more often involved in moving people from *sh to Python, > rather than the other way around. Let's give this a try, though. > > Anyway, /dev/tcp isn't a "real" inode, it's just a syntax bash and > ksh use for networking. So, if I understand you correctly, you > want to do a bit of socket programming under MacOS X with bash. > Well, that's easy enough ... no, wait; is all you want to script > downloading of a few http: documents? I think there's an even > easier way to achieve that. > Yeah. Use 'curl' ! - sdm From philippe at wwphi.net Tue Mar 30 15:50:59 2004 From: philippe at wwphi.net (Philippe de Rochambeau) Date: Tue Mar 30 15:51:07 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp In-Reply-To: References: Message-ID: Hello, sorry to have waisted your fellows' time for nothing. I just wanted to learn yet another way to fetch data from the Web. Here's the code. It is a lot more primitive than the equivalent python code, of course. It works on macosx. PR =============== #!/bin/bash shopt -o -s nounset declare LINE declare -rx SCRIPT=${0##*/} printf "Connecting to host\n" exec 3<> /dev/tcp/www.apple.com/80 printf "Sending request to host\n" printf "%s HTTP/1.0\r\n" "GET /" >&3 printf "Accept: text/html, text/plain\r\n" >&3 printf "Accept-Language: en\r\n" >&3 printf "User-Agent: %s (Bash Script)\r\n" "$SCRIPT" >&3 printf "\r\n" >&3 printf "Receiving page\n" printf "%s\n" "----------------" while read LINE <&3 ; do printf "%s\n" "$LINE" done exit 0 ========== On 30 mars 04, at 22:03, Cameron Laird wrote: >> From pythonmac-sig-bounces@python.org Tue Mar 30 14:44:53 2004 >> . >> . >> . >> The book "Linux shell scripting with Bash" says that you can open >> network connections with /dev/tcp as in > >> exec 3<> /dev/tcp/localhost/80 > >> The author then gives an example in shell script of how to use >> /dev/tcp >> to connect to a webserver. > >> I just wanted to investigating this as an alternative to a Python + >> httplib + wxWindows script which I wrote. >> . >> . >> . > Oh, *that*; I would have summarized that in quite different words. > > I'm far more often involved in moving people from *sh to Python, > rather than the other way around. Let's give this a try, though. > > Anyway, /dev/tcp isn't a "real" inode, it's just a syntax bash and > ksh use for networking. So, if I understand you correctly, you > want to do a bit of socket programming under MacOS X with bash. > Well, that's easy enough ... no, wait; is all you want to script > downloading of a few http: documents? I think there's an even > easier way to achieve that. > From sdm7g at mac.com Tue Mar 30 16:10:36 2004 From: sdm7g at mac.com (Steven D. Majewski) Date: Tue Mar 30 16:12:57 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp In-Reply-To: References: Message-ID: On Mar 30, 2004, at 3:50 PM, Philippe de Rochambeau wrote: > Hello, > > sorry to have waisted your fellows' time for nothing. I just wanted to > learn yet another way to fetch data from the Web. Here's the code. It > is a lot more primitive than the equivalent python code, of course. It > works on macosx. > > PR I'm just amazed to discover it really works! I saw a section on /dev/tcp in the Advanced Bash Scripting Guide: but, since I didn't SEE a '/dev/tcp' on my mac, I assumed it was an unsupported linux-ism. But, as Cameron noted, it's no real device there -- it's just the shell using a device-like syntax to do some magic. However, now that I know that it actually works, I hope I never need to use it ever again! ;-) -- sdm From eichin at metacarta.com Tue Mar 30 16:16:49 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Tue Mar 30 16:17:23 2004 Subject: [Pythonmac-SIG] Off-topic : /dev/tcp In-Reply-To: References: <3CDFA9DE-8263-11D8-AD12-003065D64D74@wwphi.net> <21C743B4-8266-11D8-93BA-000A95686CD8@redivi.com> Message-ID: <7gzn9y6nni.fsf@pikespeak.metacarta.com> > The book "Linux shell scripting with Bash" says that you can open > network connections with /dev/tcp as in > > exec 3<> /dev/tcp/localhost/80 Ah, the trick here is that it *isn't* part of linux: it is part of *Bash*, directly (and does work under OS X, from a quick experiment.) From loredo at astro.cornell.edu Tue Mar 30 16:29:21 2004 From: loredo at astro.cornell.edu (Tom Loredo) Date: Tue Mar 30 16:29:27 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X Message-ID: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> Hi folks- This post is for a dual purpose: first, to alert newcomers to MacPython that Bob Ippolito's PyCon2004 presentation is a great summary of the potentially confusing Python situation under OS X; and second, to publicly thank Bob for taking the time to put together so nice a presentation. I've been using Python on the Mac for years, and I still learned a lot from his presentation. It's available online here: http://www.python.org/pycon/dc2004/papers/32/ It might be useful to have this featured prominently on the MacPython page, and/or to have the contents rolled into the FAQ. It's the clearest self-contained summary of what's for what regarding Python on the Mac that I've yet come across. Thanks Bob! Tom Loredo From nbastin at opnet.com Tue Mar 30 16:40:17 2004 From: nbastin at opnet.com (Nick Bastin) Date: Tue Mar 30 16:40:43 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> Message-ID: On Mar 30, 2004, at 4:29 PM, Tom Loredo wrote: > This post is for a dual purpose: first, to alert newcomers to > MacPython that Bob Ippolito's PyCon2004 presentation is a great > summary of the potentially confusing Python situation under OS X; > and second, to publicly thank Bob for taking the time to put > together so nice a presentation. I've been using Python on the > Mac for years, and I still learned a lot from his presentation. > > It's available online here: > > http://www.python.org/pycon/dc2004/papers/32/ I would just like to point out that slide 60 is *NOT* a representative sample of wxPython on MacOS X. Unless he got extremely unlucky, Bob went out of his way to find an example that did not look good on MacOS X. It's ok to like your toolkit better than some other toolkit, but don't make the others appear worse than they really are. The wxPython demo application isn't even on the whole a particularly good example (unfortunately) since a few examples are poorly coded as far as layout goes (I can make controls overlap with cocoa too), but if you go through it, you'll get a much better idea of where wx works and doesn't work. -- Nick From bob at redivi.com Tue Mar 30 16:56:30 2004 From: bob at redivi.com (Bob Ippolito) Date: Tue Mar 30 16:52:28 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> Message-ID: <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> On Mar 30, 2004, at 4:40 PM, Nick Bastin wrote: > > On Mar 30, 2004, at 4:29 PM, Tom Loredo wrote: > >> This post is for a dual purpose: first, to alert newcomers to >> MacPython that Bob Ippolito's PyCon2004 presentation is a great >> summary of the potentially confusing Python situation under OS X; >> and second, to publicly thank Bob for taking the time to put >> together so nice a presentation. I've been using Python on the >> Mac for years, and I still learned a lot from his presentation. >> >> It's available online here: >> >> http://www.python.org/pycon/dc2004/papers/32/ > > I would just like to point out that slide 60 is *NOT* a representative > sample of wxPython on MacOS X. Unless he got extremely unlucky, Bob > went out of his way to find an example that did not look good on MacOS > X. It's ok to like your toolkit better than some other toolkit, but > don't make the others appear worse than they really are. The wxPython > demo application isn't even on the whole a particularly good example > (unfortunately) since a few examples are poorly coded as far as layout > goes (I can make controls overlap with cocoa too), but if you go > through it, you'll get a much better idea of where wx works and > doesn't work. Yes, I did intentionally put wxPython, pyQt, and Tkinter in a bad light, I wanted to make it absolutely clear that they are not quite there yet. I agree with Guido when he said that wxPython is the best among certain constraints in his PyCon keynote, but I personally would prefer and currently recommend to develop a separate Cocoa front-end altogether for most applications because the cross-platform GUI frameworks have significant bugs *AND* because you can and should take advantage of platform-specific features such as WebKit, AddressBook, etc. for many Mac applications. -bob From rfinn at opnet.com Wed Mar 31 00:02:22 2004 From: rfinn at opnet.com (Russell Finn) Date: Wed Mar 31 00:02:26 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> Message-ID: <98065306-82D0-11D8-A7CA-003065F5702A@opnet.com> On Mar 30, 2004, at 4:56 PM, Bob Ippolito wrote: > On Mar 30, 2004, at 4:40 PM, Nick Bastin wrote: >> I would just like to point out that slide 60 is *NOT* a >> representative sample of wxPython on MacOS X. Unless he got >> extremely unlucky, Bob went out of his way to find an example that >> did not look good on MacOS X. ... > > Yes, I did intentionally put wxPython, pyQt, and Tkinter in a bad > light, I wanted to make it absolutely clear that they are not quite > there yet. I agree with Guido when he said that wxPython is the best > among certain constraints in his PyCon keynote, but I personally would > prefer and currently recommend to develop a separate Cocoa front-end > altogether for most applications because the cross-platform GUI > frameworks have significant bugs *AND* because you can and should take > advantage of platform-specific features such as WebKit, AddressBook, > etc. for many Mac applications. The flip side of the coin is that people coming from other platforms who want to make a cross-platform program will be discouraged from supporting the Mac at all -- because "the cross-platform toolkits are broken" and they don't want to have to learn a whole new platform-specific toolkit for that platform. I suppose that leaves plenty of "opportunities" for those of us who are Mac programmers to create native front ends to these open source projects. Unfortunately, to date this hasn't been happening very much (cf. OpenOffice). When it does happen, the authors either use Carbon-based "portable" toolkits like the ones you mention, or write their own (cf. AbiWord). Often the results are usable, albeit lacking in polish and use of native technologies -- but at least the program's running on the Mac. (The danger, of course, is that the developer will decide that's "good enough" and stop there. I don't want to run IDLE under X11 either.) Personally, I'd love to be able to make a living writing this kind of code. (In fact, I wish Apple would fund a corps of programmers to do this. The Apple Corps! No, wait...) As it is, I barely have time to keep up with this mailing list. -- Russell Finn rfinn@opnet.com From zbir at urbanape.com Wed Mar 31 00:23:38 2004 From: zbir at urbanape.com (Zachery Bir) Date: Wed Mar 31 00:23:46 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <98065306-82D0-11D8-A7CA-003065F5702A@opnet.com> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> <98065306-82D0-11D8-A7CA-003065F5702A@opnet.com> Message-ID: <91177AF3-82D3-11D8-9AEC-000A958650B6@urbanape.com> On Mar 31, 2004, at 12:02 AM, Russell Finn wrote: > On Mar 30, 2004, at 4:56 PM, Bob Ippolito wrote: >> On Mar 30, 2004, at 4:40 PM, Nick Bastin wrote: >>> I would just like to point out that slide 60 is *NOT* a >>> representative sample of wxPython on MacOS X. Unless he got >>> extremely unlucky, Bob went out of his way to find an example that >>> did not look good on MacOS X. ... >> >> Yes, I did intentionally put wxPython, pyQt, and Tkinter in a bad >> light, I wanted to make it absolutely clear that they are not quite >> there yet. I agree with Guido when he said that wxPython is the best >> among certain constraints in his PyCon keynote, but I personally >> would prefer and currently recommend to develop a separate Cocoa >> front-end altogether for most applications because the cross-platform >> GUI frameworks have significant bugs *AND* because you can and should >> take advantage of platform-specific features such as WebKit, >> AddressBook, etc. for many Mac applications. > > The flip side of the coin is that people coming from other platforms > who want to make a cross-platform program will be discouraged from > supporting the Mac at all -- because "the cross-platform toolkits are > broken" and they don't want to have to learn a whole new > platform-specific toolkit for that platform. Well, that's really their loss. Mac users are far more picky about their user environment than their Windows- or Linux-using counterparts. Also-ran, "because there was a cross-platform widget library" implementations aren't going to be received with open arms. At best, they'll be accepted as workarounds, at worst, they'll wind up on perversiontracker, but by and large, there will be gaps in the user experience due to some expedience taken on the part of either the developer and/or the toolkit. > I suppose that leaves plenty of "opportunities" for those of us who > are Mac programmers to create native front ends to these open source > projects. Damn skippy. More importantly, it enables us to tap into that very same picky market, and when we get to exploit the wealth of Cocoa libraries, to tap into it much faster, and with user experiences that can rival Obj-C projects. > Unfortunately, to date this hasn't been happening very much (cf. > OpenOffice). When it does happen, the authors either use Carbon-based > "portable" toolkits like the ones you mention, or write their own (cf. > AbiWord). None of those strike me as backing up your previous sentence, and I'm not entirely sure that's the thrust of PyObjC. I can't imagine anyone wants to port OOo to use Cocoa libraries for the Mac port. A better approach would be to start working on a Cocoa word processor that uses OOo XML as its native file format, &c. > Often the results are usable, albeit lacking in polish and use of > native technologies -- but at least the program's running on the Mac. > (The danger, of course, is that the developer will decide that's "good > enough" and stop there. I don't want to run IDLE under X11 either.) This is exactly what we're talking about. I don't want my PowerBook polluted with a bunch of also-rans. I'd rather put my effort into making Mac-quality applications with Mac-quality interfaces. > Personally, I'd love to be able to make a living writing this kind of > code. (In fact, I wish Apple would fund a corps of programmers to do > this. The Apple Corps! No, wait...) As it is, I barely have time to > keep up with this mailing list. Well, it's gotta start somewhere :^) Zac -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040331/e2e2ebe0/smime.bin From leknarf at pacbell.net Wed Mar 31 01:34:56 2004 From: leknarf at pacbell.net (Scott Frankel) Date: Wed Mar 31 01:35:08 2004 Subject: [Pythonmac-SIG] possible OT: os.chdir on OSX Message-ID: <8669BB7C-82DD-11D8-A374-000A95A7B782@pacbell.net> On OSX 10.3 How would one change working directories using a python script and have the parent process (the shell from which the script was launched) switch to that directory? i.e.: os.chdir("some_other_dir") print os.getcwd() this prints "some_other_dir", so I know the script's process made it there. But when the script exits, my shell is back to where I launched the script from. (In fact, it never left.) Thanks in advance! Scott From jum at mac.com Wed Mar 31 02:32:09 2004 From: jum at mac.com (Jens Miltner) Date: Wed Mar 31 02:31:47 2004 Subject: [Pythonmac-SIG] possible OT: os.chdir on OSX In-Reply-To: <8669BB7C-82DD-11D8-A374-000A95A7B782@pacbell.net> References: <8669BB7C-82DD-11D8-A374-000A95A7B782@pacbell.net> Message-ID: <84D5E323-82E5-11D8-8639-0003931C36B2@mac.com> Am 31.03.2004 um 08:34 schrieb Scott Frankel: > > On OSX 10.3 > > How would one change working directories using a python > script and have the parent process (the shell from which the > script was launched) switch to that directory? > > i.e.: > os.chdir("some_other_dir") > print os.getcwd() > > this prints "some_other_dir", so I know the script's process > made it there. But when the script exits, my shell is back to > where I launched the script from. (In fact, it never left.) There's no way to ever change the working directory in the calling shell, since that's another process and - fortunately - one process can't change another process' runtime environment! From p.oberndoerfer at urheberrecht.org Wed Mar 31 02:33:54 2004 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Wed Mar 31 02:34:03 2004 Subject: [Pythonmac-SIG] framework _only_ build fails on 10.1 Message-ID: I doubt this is of great interest anymore but still: maybe I just missed something? I tried to build the framework _only_ on 10.1 yesterday. No frameworkinstallapps or frameworkinstallextras. During make I get this problem: cc -Wl,-F. -bundle -framework Python build/temp.darwin-5.5-Power_Macintosh-2.3/macosmodule.o -L/Library/Frameworks/Python.framework/Versions/2.3/lib -L/usr/local/lib -o build/lib.darwin-5.5-Power_Macintosh-2.3/MacOS.so -framework Carbon /usr/bin/ld: Undefined symbols: _CGMainDisplayID This is related to macosmodule.c I guess. Obviously this leads to unexpected skips during make test: 3 skips unexpected on darwin: test_macostools test_aepack test_scriptpackages and make frameworkinstallframework fails too of course: ./python.exe ./Mac/scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac /Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools Traceback (most recent call last): File "./Mac/scripts/cachersrc.py", line 7, in ? import macresource File "/Users/pob/Desktop/Python-2.3.3/Lib/plat-mac/macresource.py", line 6, in ? import MacOS ImportError: No module named MacOS make[1]: *** [installmacsubtree] Fehler 1 make: *** [frameworkinstallmaclib] Fehler 2 These were the steps taken: - download waste-21b1.sit to Desktop - download Python-2.3.3.tgz to Desktop - unpack both to Desktop - rename 'WASTE 2.1b1 Distribution' to waste - open Terminal - cd to ~/Desktop/Python-2.3.3 - ln -s ../waste waste - ./configure --enable-framework - edit ~/Desktop/Python-2.3.3/Mac/OSX/make for 10.1/10.2 on lines 13-16 (PBXBUILD=pbxbuild) (Don't know if this is necessary when not installing extras/apps) - make - make test - make frameworkinstallframework Thanks, Pascal From leknarf at pacbell.net Wed Mar 31 02:44:04 2004 From: leknarf at pacbell.net (Scott Frankel) Date: Wed Mar 31 02:44:18 2004 Subject: [Pythonmac-SIG] possible OT: os.chdir on OSX In-Reply-To: <84D5E323-82E5-11D8-8639-0003931C36B2@mac.com> References: <8669BB7C-82DD-11D8-A374-000A95A7B782@pacbell.net> <84D5E323-82E5-11D8-8639-0003931C36B2@mac.com> Message-ID: <2F11BE79-82E7-11D8-A374-000A95A7B782@pacbell.net> OK, then. Thanks. Scott On Mar 30, 2004, at 11:32 PM, Jens Miltner wrote: > > Am 31.03.2004 um 08:34 schrieb Scott Frankel: > >> >> On OSX 10.3 >> >> How would one change working directories using a python >> script and have the parent process (the shell from which the >> script was launched) switch to that directory? >> >> i.e.: >> os.chdir("some_other_dir") >> print os.getcwd() >> >> this prints "some_other_dir", so I know the script's process >> made it there. But when the script exits, my shell is back to >> where I launched the script from. (In fact, it never left.) > > There's no way to ever change the working directory in the calling > shell, since that's another process and - fortunately - one process > can't change another process' runtime environment! > > > From jum at mac.com Wed Mar 31 02:46:30 2004 From: jum at mac.com (Jens Miltner) Date: Wed Mar 31 02:45:56 2004 Subject: [Pythonmac-SIG] Difference between pythonw and python? Message-ID: <8650A265-82E7-11D8-8639-0003931C36B2@mac.com> What exactly (at the code level) is the difference between pythonw and python? The reason I'm asking is that I'm trying to get Tkinter work with an application that links against Python.framework and uses python as it's scripting language (MacCvsX). I do have problems with Tk not being recognized as a valid symbol name in the python scripts (despite the fact that those scripts do have a "from Tkinter import *" statement and they do work when executed from a shell), so I thought this might be related to the pythonw vs. python problem... Anybody knows what the exact difference between the two is? Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 674 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040331/d5324dfb/attachment.bin From mwh at python.net Wed Mar 31 06:02:39 2004 From: mwh at python.net (Michael Hudson) Date: Wed Mar 31 06:02:44 2004 Subject: [Pythonmac-SIG] Difference between pythonw and python? In-Reply-To: <8650A265-82E7-11D8-8639-0003931C36B2@mac.com> (Jens Miltner's message of "Wed, 31 Mar 2004 09:46:30 +0200") References: <8650A265-82E7-11D8-8639-0003931C36B2@mac.com> Message-ID: <2mu105i8j4.fsf@starship.python.net> Jens Miltner writes: > What exactly (at the code level) is the difference between pythonw and > python? pythonw is a shell script :-) Cheers, mwh -- When physicists speak of a TOE, they don't really mean a theory of *everything*. Taken literally, "Everything" covers a lot of ground, including biology, art, decoherence and the best way to barbecue ribs. -- John Baez, sci.physics.research From jum at mac.com Wed Mar 31 06:48:18 2004 From: jum at mac.com (Jens Miltner) Date: Wed Mar 31 06:47:50 2004 Subject: [Pythonmac-SIG] Difference between pythonw and python? In-Reply-To: <2mu105i8j4.fsf@starship.python.net> References: <8650A265-82E7-11D8-8639-0003931C36B2@mac.com> <2mu105i8j4.fsf@starship.python.net> Message-ID: <4D6FAF26-8309-11D8-8639-0003931C36B2@mac.com> Am 31.03.2004 um 13:02 schrieb Michael Hudson: > Jens Miltner writes: > >> What exactly (at the code level) is the difference between pythonw and >> python? > > pythonw is a shell script :-) Doh! Should've been able to find that out by myself... :-| Unfortunately, looking at this doesn't help me with my original problem of getting Tkinter to work with my app that embeds python :( Do you happen to know why the /usr/bin/python executable differs from the Python.app executable, when both are in the same Python.framework? I'd assume that when the framework comes with Panther, there shouldn't be two python executables...??? Thanks anyway, From mwh at python.net Wed Mar 31 06:49:55 2004 From: mwh at python.net (Michael Hudson) Date: Wed Mar 31 06:50:00 2004 Subject: [Pythonmac-SIG] Difference between pythonw and python? In-Reply-To: <4D6FAF26-8309-11D8-8639-0003931C36B2@mac.com> (Jens Miltner's message of "Wed, 31 Mar 2004 13:48:18 +0200") References: <8650A265-82E7-11D8-8639-0003931C36B2@mac.com> <2mu105i8j4.fsf@starship.python.net> <4D6FAF26-8309-11D8-8639-0003931C36B2@mac.com> Message-ID: <2mptati6cc.fsf@starship.python.net> Jens Miltner writes: > Am 31.03.2004 um 13:02 schrieb Michael Hudson: > >> Jens Miltner writes: >> >>> What exactly (at the code level) is the difference between pythonw and >>> python? >> >> pythonw is a shell script :-) > > Doh! Should've been able to find that out by myself... :-| > Unfortunately, looking at this doesn't help me with my original > problem of getting Tkinter to work with my app that embeds python :( > > Do you happen to know why the /usr/bin/python executable differs from > the Python.app executable, when both are in the same Python.framework? > I'd assume that when the framework comes with Panther, there shouldn't > be two python executables...??? It has something to do with the executable (aka argv[0]?) being seen to be in a bundle. Is your app that embeds Python a bundle? Cheers, mwh -- LINTILLA: You could take some evening classes. ARTHUR: What, here? LINTILLA: Yes, I've got a bottle of them. Little pink ones. -- The Hitch-Hikers Guide to the Galaxy, Episode 12 From jum at mac.com Wed Mar 31 06:55:19 2004 From: jum at mac.com (Jens Miltner) Date: Wed Mar 31 06:54:50 2004 Subject: [Pythonmac-SIG] Difference between pythonw and python? In-Reply-To: <2mptati6cc.fsf@starship.python.net> References: <8650A265-82E7-11D8-8639-0003931C36B2@mac.com> <2mu105i8j4.fsf@starship.python.net> <4D6FAF26-8309-11D8-8639-0003931C36B2@mac.com> <2mptati6cc.fsf@starship.python.net> Message-ID: <48519965-830A-11D8-8639-0003931C36B2@mac.com> Am 31.03.2004 um 13:49 schrieb Michael Hudson: > Jens Miltner writes: > >> Am 31.03.2004 um 13:02 schrieb Michael Hudson: >> >>> Jens Miltner writes: >>> >>>> What exactly (at the code level) is the difference between pythonw >>>> and >>>> python? >>> >>> pythonw is a shell script :-) >> >> Doh! Should've been able to find that out by myself... :-| >> Unfortunately, looking at this doesn't help me with my original >> problem of getting Tkinter to work with my app that embeds python :( >> >> Do you happen to know why the /usr/bin/python executable differs from >> the Python.app executable, when both are in the same Python.framework? >> I'd assume that when the framework comes with Panther, there shouldn't >> be two python executables...??? > > It has something to do with the executable (aka argv[0]?) being seen > to be in a bundle. Is your app that embeds Python a bundle? Yes, it's an application package. I link against the Python.framework (or actually, I load it dynamically - not sure whether that makes a difference. Maybe I should try to link against Python.framework for testing purposes...) From Jack.Jansen at cwi.nl Wed Mar 31 10:39:10 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 31 10:39:14 2004 Subject: [Pythonmac-SIG] Difference between pythonw and python? In-Reply-To: <48519965-830A-11D8-8639-0003931C36B2@mac.com> References: <8650A265-82E7-11D8-8639-0003931C36B2@mac.com> <2mu105i8j4.fsf@starship.python.net> <4D6FAF26-8309-11D8-8639-0003931C36B2@mac.com> <2mptati6cc.fsf@starship.python.net> <48519965-830A-11D8-8639-0003931C36B2@mac.com> Message-ID: <8DB0D329-8329-11D8-96CB-000D934FF6B4@cwi.nl> On 31 Mar 2004, at 13:55, Jens Miltner wrote: >>> Do you happen to know why the /usr/bin/python executable differs from >>> the Python.app executable, when both are in the same >>> Python.framework? >>> I'd assume that when the framework comes with Panther, there >>> shouldn't >>> be two python executables...??? >> >> It has something to do with the executable (aka argv[0]?) being seen >> to be in a bundle. Is your app that embeds Python a bundle? And actually that is the only difference. /usr/bin/python and ...../Python.app/Contents/MacOS/Python could have the exact same bits. > > Yes, it's an application package. I link against the Python.framework > (or actually, I load it dynamically - not sure whether that makes a > difference. Maybe I should try to link against Python.framework for > testing purposes...) Then it could be you're running up against a completely different problem. Does the hosting application have its own GUI mainloop? Because if it has (and note it could be implicit, if you use Cocoa or CarbonEvents) then you will probably run into problems with your mainloop and Tk's mainloop getting in each others hair. -- 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 kevino at tulane.edu Wed Mar 31 10:45:48 2004 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed Mar 31 10:48:49 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> Message-ID: <7B30F3F2-832A-11D8-9A41-000393CB1C86@tulane.edu> Hi all, On Mar 30, 2004, at 1:56 PM, Bob Ippolito wrote: > On Mar 30, 2004, at 4:40 PM, Nick Bastin wrote: > >> >> On Mar 30, 2004, at 4:29 PM, Tom Loredo wrote: >> >>> This post is for a dual purpose: first, to alert newcomers to >>> MacPython that Bob Ippolito's PyCon2004 presentation is a great >>> summary of the potentially confusing Python situation under OS X; >>> and second, to publicly thank Bob for taking the time to put >>> together so nice a presentation. I've been using Python on the >>> Mac for years, and I still learned a lot from his presentation. >>> >>> It's available online here: >>> >>> http://www.python.org/pycon/dc2004/papers/32/ >> >> I would just like to point out that slide 60 is *NOT* a >> representative sample of wxPython on MacOS X. Unless he got >> extremely unlucky, Bob went out of his way to find an example that >> did not look good on MacOS X. It's ok to like your toolkit better >> than some other toolkit, but don't make the others appear worse than >> they really are. The wxPython demo application isn't even on the >> whole a particularly good example (unfortunately) since a few >> examples are poorly coded as far as layout goes (I can make controls >> overlap with cocoa too), but if you go through it, you'll get a much >> better idea of where wx works and doesn't work. > > Yes, I did intentionally put wxPython, pyQt, and Tkinter in a bad > light, I wanted to make it absolutely clear that they are not quite > there yet. I agree with Guido when he said that wxPython is the best > among certain constraints in his PyCon keynote, but I personally would > prefer and currently recommend to develop a separate Cocoa front-end > altogether for most applications because the cross-platform GUI > frameworks have significant bugs *AND* because you can and should take > advantage of platform-specific features such as WebKit, AddressBook, > etc. for many Mac applications. Well, although I agree with another poster that Bob's taking this approach would distance some people from even considering Mac development, my main purpose of writing this note is that we are quickly working to resolve many of these issues on the wxPython front. By summer, many of those graphics glitches you have seen will be gone, WebKit will most certainly be available, support for catching the basic AppleEvents (i.e. like Open) is now enabled, and quite possibly the DataBrowser will be more or less completely supported and utilized as the underlying control for both ListCtrls and TreeCtrls. Also, our latest CVS supports the "Brushed Metal" look, and also controls now also let you specify normal/small/mini size variants for a control. And that's just a summary, not a complete list. =) So let me assure folks, we are *not* taking these issues lying down. ;-) Thanks, Kevin From eichin at metacarta.com Wed Mar 31 11:50:00 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Wed Mar 31 11:50:06 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <98065306-82D0-11D8-A7CA-003065F5702A@opnet.com> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> <98065306-82D0-11D8-A7CA-003065F5702A@opnet.com> Message-ID: <7gvfkl3qrr.fsf@pikespeak.metacarta.com> > The flip side of the coin is that people coming from other platforms > who want to make a cross-platform program will be discouraged from > supporting the Mac at all -- because "the cross-platform toolkits are > broken" and they don't want to have to learn a whole new > platform-specific toolkit for that platform. Exactly - there's no particular benefit to me to learn a mac-specific GUI toolkit[1], because most of the things I write need to run on Linux and Solaris as well. Also, I don't need an especially *advanced* toolkit - my apps simply aren't going to have particularly impressive interfaces, it is enough that they do simple things in ways that don't clash. I just want to develop on my Mac so that I can run elsewhere as well[2]. Sadly, my current "really runs everywhere" code is using *curses*. Jython is somewhat tempting as well, after seeing (for example) moneydance "fit in ok" under osx, after using it on linux. Really, I just want to know what gui toolkit is going to be an included "battery" :-) _Mark_ [1] I get a lot of benefit to being able to use aevt and the layers above it to integrate with existing mac apps - but most of the things I do with that don't have user interfaces at all... [2] Though, what I *really* want is to be able to write simple apps that work everywhere including PalmOS - python may get me to abandon PalmOS for Symbian, once Nokia ships the python they demoed at ETCON... From dan at cgl.ucsf.edu Wed Mar 31 12:23:18 2004 From: dan at cgl.ucsf.edu (Daniel Greenblatt) Date: Wed Mar 31 12:24:30 2004 Subject: [Pythonmac-SIG] associating file types and applications... In-Reply-To: References: Message-ID: An application we're distributing defines several of its own file types... Is it possible to use Python to programmatically establish the association btn. that file type and my application, either on a user-wide (ideally) or system-wide (less ideally) basis? I.e. so when they click on their file on their desktop, or click on a link to that file from their browser, it knows where to send the file.... I'm sure I have to write into some plist somewhere, but not quite sure which one, and the best way to do it..... Thanks, Dan Greenblatt ---------------------------- Daniel Greenblatt UCSF Computer Graphics Lab dan@cgl.ucsf.edu From altis at semi-retired.com Wed Mar 31 12:37:28 2004 From: altis at semi-retired.com (Kevin Altis) Date: Wed Mar 31 12:37:34 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <7gvfkl3qrr.fsf@pikespeak.metacarta.com> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> <98065306-82D0-11D8-A7CA-003065F5702A@opnet.com> <7gvfkl3qrr.fsf@pikespeak.metacarta.com> Message-ID: <1488B73A-833A-11D8-B8FB-000A9598382A@semi-retired.com> On Mar 31, 2004, at 8:50 AM, eichin@metacarta.com wrote: > >> The flip side of the coin is that people coming from other platforms >> who want to make a cross-platform program will be discouraged from >> supporting the Mac at all -- because "the cross-platform toolkits are >> broken" and they don't want to have to learn a whole new >> platform-specific toolkit for that platform. > > Exactly - there's no particular benefit to me to learn a mac-specific > GUI toolkit[1], because most of the things I write need to run on > Linux and Solaris as well. Also, I don't need an especially > *advanced* toolkit - my apps simply aren't going to have particularly > impressive interfaces, it is enough that they do simple things in ways > that don't clash. I just want to develop on my Mac so that I can run > elsewhere as well[2]. Choice is a good thing. It is great that PyObjC exists. At the same time, there is a very large population of coders that have zero interest in learning Cocoa which is where the cross-platform toolkits come in. Writing code for a single platform is so '80s but PyObjC has a different audience and that is fine. In fact, I hope that PyObjC becomes a much more mainstream way of coding Cocoa applications and becomes much better integrated into Apple developer tools and documentation. I can't speak for PyGTK and PyQt or Tkinter, but I do know that wxPython will continue to improve on Mac OS X with each release even while the underlying wxMAC C++ code is based on Carbon. Eventually the base will be wxCocoa. Stefan Csomor and Kevin Ollivier are both active wxWidgets/wxPython developers. The OSAF, which is producing Chandler is Robin Dunn's employer and the OSAF just hired David Surovell as the GUI Frameworks Software Engineer. It is critical that for Chandler to kick butt on Mac OS X as well as Windows and Linux, so wxPython will just continue to get better and better on the Mac. Mac OS X users and developers are lucky because they get more options and the best of both worlds. ka From bob at redivi.com Wed Mar 31 13:37:17 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 31 13:33:15 2004 Subject: [Pythonmac-SIG] associating file types and applications... In-Reply-To: References: Message-ID: <6FEEB355-8342-11D8-A68D-000A95686CD8@redivi.com> On Mar 31, 2004, at 12:23 PM, Daniel Greenblatt wrote: > An application we're distributing defines several of its own file > types... > Is it possible to use Python to programmatically establish the > association btn. that file type and my application, > either on a user-wide (ideally) or system-wide (less ideally) > basis? I.e. so when they click on their file on their desktop, or > click on a link to that file from their browser, it knows where > to send the file.... > > I'm sure I have to write into some plist somewhere, but not quite > sure which one, and the best way to do it..... It's in the Info.plist file.. See: http://developer.apple.com/documentation/MacOSX/Conceptual/ BPRuntimeConfig/Concepts/PListKeys.html particularly CFBundleDocumentTypes -bob From dan at cgl.ucsf.edu Wed Mar 31 13:48:54 2004 From: dan at cgl.ucsf.edu (Daniel Greenblatt) Date: Wed Mar 31 13:49:00 2004 Subject: [Pythonmac-SIG] associating file types and applications... In-Reply-To: <6FEEB355-8342-11D8-A68D-000A95686CD8@redivi.com> References: <6FEEB355-8342-11D8-A68D-000A95686CD8@redivi.com> Message-ID: Thanks for the quick response Bob, I'm not sure this solves my problem though (looking at my original email, I see it can be taken several ways)... My understanding that although the Info.plist file informs the OS of what type of files a particular application bundle knows how to handle, it doesnt necessarily tell the OS that it should use that particular application when a file of that type is encountered.... (please let me know if I'm way off course here....) i.e. both TextEdit.app and MSWord.app know how to deal with .txt files, but it must say somewhere else which one should be used when the user double clicks on /Users/Dan/Desktop/foo.txt Thanks Dan ---------------------------- Daniel Greenblatt UCSF Computer Graphics Lab dan@cgl.ucsf.edu On Wed, 31 Mar 2004, Bob Ippolito wrote: > Date: Wed, 31 Mar 2004 13:37:17 -0500 > From: Bob Ippolito > To: Daniel Greenblatt > Cc: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] associating file types and applications... > > > On Mar 31, 2004, at 12:23 PM, Daniel Greenblatt wrote: > > > An application we're distributing defines several of its own file > > types... > > Is it possible to use Python to programmatically establish the > > association btn. that file type and my application, > > either on a user-wide (ideally) or system-wide (less ideally) > > basis? I.e. so when they click on their file on their desktop, or > > click on a link to that file from their browser, it knows where > > to send the file.... > > > > I'm sure I have to write into some plist somewhere, but not quite > > sure which one, and the best way to do it..... > > It's in the Info.plist file.. > > See: > http://developer.apple.com/documentation/MacOSX/Conceptual/ > BPRuntimeConfig/Concepts/PListKeys.html > > particularly CFBundleDocumentTypes > > -bob > > From mlpollard at earthlink.net Wed Mar 31 15:11:46 2004 From: mlpollard at earthlink.net (Tom Pollard) Date: Wed Mar 31 15:10:07 2004 Subject: [Pythonmac-SIG] associating file types and applications... In-Reply-To: References: <6FEEB355-8342-11D8-A68D-000A95686CD8@redivi.com> Message-ID: On Mar 31, 2004, at 1:48 PM, Daniel Greenblatt wrote: > Thanks for the quick response Bob, I'm not sure this solves my problem > though (looking at my original email, I see it can be taken several > ways)... > > My understanding that although the Info.plist file informs the OS of > what > type of files a particular application bundle knows how to handle, it > doesnt necessarily tell the OS that it should use that particular > application when a file of that type is encountered.... The default app to use when opening a document is a property of the Finder. Users can always reassign particular document types to the app of their choosing using the Info window. So, I'm not sure it would be considered "playing nice" to override that preference for an existing filetype. I imagine if you introduce a new filetype, your app will automatically be the default app for opening those files. That's just my impression of how things work - I'm not an expert. Cheers, Tom From Martina at Oefelein.de Wed Mar 31 15:17:31 2004 From: Martina at Oefelein.de (Martina Oefelein) Date: Wed Mar 31 15:18:17 2004 Subject: [Pythonmac-SIG] associating file types and applications... In-Reply-To: References: <6FEEB355-8342-11D8-A68D-000A95686CD8@redivi.com> Message-ID: <70A905BE-8350-11D8-AB83-000A957DBE94@Oefelein.de> Hi Tom, Daniel, > > On Mar 31, 2004, at 1:48 PM, Daniel Greenblatt wrote: >> Thanks for the quick response Bob, I'm not sure this solves my problem >> though (looking at my original email, I see it can be taken several >> ways)... >> >> My understanding that although the Info.plist file informs the OS of >> what >> type of files a particular application bundle knows how to handle, it >> doesnt necessarily tell the OS that it should use that particular >> application when a file of that type is encountered.... > > The default app to use when opening a document is a property of the > Finder. Users can always reassign particular document types to the > app of their choosing using the Info window. So, I'm not sure it > would be considered "playing nice" to override that preference for an > existing filetype. I imagine if you introduce a new filetype, your > app will automatically be the default app for opening those files. > That's just my impression of how things work - I'm not an expert. That's right. Actually, you can force the app to open by setting the (MacOS9 style) HFS creator code, but only for individual documents. However, in most cases I think it's better to leave the choice to the user... ciao Martina From Jack.Jansen at cwi.nl Wed Mar 31 15:40:43 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 31 15:41:21 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <7B30F3F2-832A-11D8-9A41-000393CB1C86@tulane.edu> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> <7B30F3F2-832A-11D8-9A41-000393CB1C86@tulane.edu> Message-ID: On 31 Mar 2004, at 17:45, Kevin Ollivier wrote: >> Yes, I did intentionally put wxPython, pyQt, and Tkinter in a bad >> light, I wanted to make it absolutely clear that they are not quite >> there yet. I agree with Guido when he said that wxPython is the best >> among certain constraints in his PyCon keynote, but I personally >> would prefer and currently recommend to develop a separate Cocoa >> front-end altogether for most applications because the cross-platform >> GUI frameworks have significant bugs *AND* because you can and should >> take advantage of platform-specific features such as WebKit, >> AddressBook, etc. for many Mac applications. > > Well, although I agree with another poster that Bob's taking this > approach would distance some people from even considering Mac > development, my main purpose of writing this note is that we are > quickly working to resolve many of these issues on the wxPython front. I agree wholeheartedly. While Cocoa may be a much better solution for mac-only developers the reality is that the majority of Python programmers are not mac-only programmers. And given the fact that Mac users already have the name of being a royal pain in the behind because Macs are lightyears ahead of everything else we should be careful not to reinforce that feeling, especially not when talking to a general (i.e. not Mac-only) audience. Moreover, I think that by emphasizing that wxPython (or any other cross-platform solution) is pretty good but not on par with Cocoa we would hopefully get the wx folks to look at Cocoa more and pick up the good points. -- 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 at cwi.nl Wed Mar 31 15:46:02 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 31 15:46:09 2004 Subject: [Pythonmac-SIG] associating file types and applications... In-Reply-To: References: <6FEEB355-8342-11D8-A68D-000A95686CD8@redivi.com> Message-ID: <6C745946-8354-11D8-96CB-000D934FF6B4@cwi.nl> On 31 Mar 2004, at 22:11, Tom Pollard wrote: > > On Mar 31, 2004, at 1:48 PM, Daniel Greenblatt wrote: >> Thanks for the quick response Bob, I'm not sure this solves my problem >> though (looking at my original email, I see it can be taken several >> ways)... >> >> My understanding that although the Info.plist file informs the OS of >> what >> type of files a particular application bundle knows how to handle, it >> doesnt necessarily tell the OS that it should use that particular >> application when a file of that type is encountered.... > > The default app to use when opening a document is a property of the > Finder. Users can always reassign particular document types to the > app of their choosing using the Info window. So, I'm not sure it > would be considered "playing nice" to override that preference for an > existing filetype. I imagine if you introduce a new filetype, your > app will automatically be the default app for opening those files. > That's just my impression of how things work - I'm not an expert. There *is* a way to do this, though: the various media players (quicktime, itunes, realplayer, windows media) all offer to handle all your mp3s and other types for you, and if you say "yes" they do it (at least until you override again from the finder). I'm not sure whether they do this through AppleEvents to the Finder, AppleEvents to something else or a completely different mechanism, though. -- 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 eichin at metacarta.com Wed Mar 31 15:51:41 2004 From: eichin at metacarta.com (eichin@metacarta.com) Date: Wed Mar 31 15:51:46 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <1488B73A-833A-11D8-B8FB-000A9598382A@semi-retired.com> References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> <98065306-82D0-11D8-A7CA-003065F5702A@opnet.com> <7gvfkl3qrr.fsf@pikespeak.metacarta.com> <1488B73A-833A-11D8-B8FB-000A9598382A@semi-retired.com> Message-ID: <7gsmfo3fky.fsf@pikespeak.metacarta.com> > while the underlying wxMAC C++ code is based on Carbon. Eventually the > base will be wxCocoa. Stefan Csomor and Kevin Ollivier are both active Ooh, I hadn't heard of wxCocoa before. That sounds encouraging, if it does what I think it does. > GUI Frameworks Software Engineer. It is critical that for Chandler to > kick butt on Mac OS X as well as Windows and Linux, so wxPython will > just continue to get better and better on the Mac. Indeed, that's a fine set of coattails to be riding :-) From jhrsn at pitt.edu Wed Mar 31 16:00:00 2004 From: jhrsn at pitt.edu (Jim Harrison) Date: Wed Mar 31 16:00:01 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <7B30F3F2-832A-11D8-9A41-000393CB1C86@tulane.edu> Message-ID: on 3/31/04 10:45 AM, Kevin Ollivier at kevino@tulane.edu wrote: > ...we are quickly working to resolve many of these issues on the wxPython > front. > > By summer, many of those graphics glitches you have seen will be gone, > WebKit will most certainly be available, support for catching the basic > AppleEvents (i.e. like Open) is now enabled, and quite possibly the > DataBrowser will be more or less completely supported and utilized as > the underlying control for both ListCtrls and TreeCtrls. Also, our > latest CVS supports the "Brushed Metal" look, and also controls now > also let you specify normal/small/mini size variants for a control. And > that's just a summary, not a complete list. =) Yay!! I'll also agree with another poster that basic cross platform development is crucially important for many. We do our research development on Macs (both the development machines and servers). We also use the same machines to develop software that's used on a daily basis in our local clinical laboratories and related health system areas for data analysis and specialized quality control. I wish I could do this work in Cocoa/PyObjC, but the fact is that most, but not all, deployment machines must be Windows. So our choice for these smaller scale projects is either cross-platform development or develop on Windows. We like the ability to develop on our Macs and deploy on both Windows and Macs. We don't have a lot of extra time, and if we couldn't develop in this way, the overhead would mean that most of these project just wouldn't get done. At the moment we develop in either python (for non-GUI utilities) or REALbasic for rapid GUI development. Although RB is pretty good for cross platform RAD when your needs are basic (heh), we'd really like to move to all Python. So we'll be watching wxPython with a lot of interest. Jim Harrison Univ. of Pittsburgh From claird at lairds.com Wed Mar 31 16:42:29 2004 From: claird at lairds.com (Cameron Laird) Date: Wed Mar 31 16:43:00 2004 Subject: [Pythonmac-SIG] possible OT: os.chdir on OSX In-Reply-To: <84D5E323-82E5-11D8-8639-0003931C36B2@mac.com> Message-ID: > From pythonmac-sig-bounces@python.org Wed Mar 31 02:32:04 2004 > . > . > . > > How would one change working directories using a python > > script and have the parent process (the shell from which the > > script was launched) switch to that directory? > > > > i.e.: > > os.chdir("some_other_dir") > > print os.getcwd() > > > > this prints "some_other_dir", so I know the script's process > > made it there. But when the script exits, my shell is back to > > where I launched the script from. (In fact, it never left.) > There's no way to ever change the working directory in the calling > shell, since that's another process and - fortunately - one process > can't change another process' runtime environment! > . > . > . ... absolutely true, and one of the classic FAQ disappointments to many administrators and developers. HOWEVER, what they *really* want is often just enough different from "change the parent" that a programmatic solution *is* possible: ... [I was going to present the answer here, but I'm being called away. I'll return to the question later.] From Jack.Jansen at cwi.nl Wed Mar 31 16:53:15 2004 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Mar 31 16:53:19 2004 Subject: [Pythonmac-SIG] possible OT: os.chdir on OSX In-Reply-To: References: Message-ID: > ... absolutely true, and one of the classic FAQ > disappointments to many administrators and developers. > HOWEVER, what they *really* want is often just enough > different from "change the parent" that a programmatic > solution *is* possible: ... > [I was going to present the answer here, > but I'm being called away. I'll return > to the question later.] That's what Fermat said too:-) (see the second hit on Google if you've never heard of Fermat) -- 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 zbir at urbanape.com Wed Mar 31 17:17:35 2004 From: zbir at urbanape.com (Zachery Bir) Date: Wed Mar 31 17:17:42 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: References: Message-ID: <368F68A4-8361-11D8-9AEC-000A958650B6@urbanape.com> On Mar 31, 2004, at 4:00 PM, Jim Harrison wrote: > on 3/31/04 10:45 AM, Kevin Ollivier at kevino@tulane.edu wrote: > >> ...we are quickly working to resolve many of these issues on the >> wxPython >> front. >> >> By summer, many of those graphics glitches you have seen will be gone, >> WebKit will most certainly be available, support for catching the >> basic >> AppleEvents (i.e. like Open) is now enabled, and quite possibly the >> DataBrowser will be more or less completely supported and utilized as >> the underlying control for both ListCtrls and TreeCtrls. Also, our >> latest CVS supports the "Brushed Metal" look, and also controls now >> also let you specify normal/small/mini size variants for a control. >> And >> that's just a summary, not a complete list. =) > > Yay!! I'll also agree with another poster that basic cross platform > development is crucially important for many. We do our research > development > on Macs (both the development machines and servers). We also use the > same > machines to develop software that's used on a daily basis in our local > clinical laboratories and related health system areas for data > analysis and > specialized quality control. I wish I could do this work in > Cocoa/PyObjC, > but the fact is that most, but not all, deployment machines must be > Windows. > So our choice for these smaller scale projects is either cross-platform > development or develop on Windows. We like the ability to develop on > our > Macs and deploy on both Windows and Macs. We don't have a lot of extra > time, > and if we couldn't develop in this way, the overhead would mean that > most of > these project just wouldn't get done. At the moment we develop in > either > python (for non-GUI utilities) or REALbasic for rapid GUI development. > Although RB is pretty good for cross platform RAD when your needs are > basic > (heh), we'd really like to move to all Python. So we'll be watching > wxPython > with a lot of interest. How is this a factor of the widget toolkit? With abstracted model and controller classes, you can distribute reference implementations in whatever toolkit you want (cross-platform or not), while allowing for platform-specific implementations to go above and beyond the common denominator... Zac -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040331/aab51e79/smime.bin From nbastin at opnet.com Wed Mar 31 17:31:41 2004 From: nbastin at opnet.com (Nick Bastin) Date: Wed Mar 31 17:31:50 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <368F68A4-8361-11D8-9AEC-000A958650B6@urbanape.com> References: <368F68A4-8361-11D8-9AEC-000A958650B6@urbanape.com> Message-ID: <2ED5FCC6-8363-11D8-A2DB-000393CBDF94@opnet.com> On Mar 31, 2004, at 5:17 PM, Zachery Bir wrote: > On Mar 31, 2004, at 4:00 PM, Jim Harrison wrote: > >> Yay!! I'll also agree with another poster that basic cross platform >> development is crucially important for many. We do our research >> development >> on Macs (both the development machines and servers). We also use the >> same >> machines to develop software that's used on a daily basis in our local >> clinical laboratories and related health system areas for data >> analysis and >> specialized quality control. I wish I could do this work in >> Cocoa/PyObjC, >> but the fact is that most, but not all, deployment machines must be >> Windows. >> So our choice for these smaller scale projects is either >> cross-platform >> development or develop on Windows. We like the ability to develop on >> our >> Macs and deploy on both Windows and Macs. We don't have a lot of >> extra time, >> and if we couldn't develop in this way, the overhead would mean that >> most of >> these project just wouldn't get done. At the moment we develop in >> either >> python (for non-GUI utilities) or REALbasic for rapid GUI development. >> Although RB is pretty good for cross platform RAD when your needs are >> basic >> (heh), we'd really like to move to all Python. So we'll be watching >> wxPython >> with a lot of interest. > > How is this a factor of the widget toolkit? With abstracted model and > controller classes, you can distribute reference implementations in > whatever toolkit you want (cross-platform or not), while allowing for > platform-specific implementations to go above and beyond the common > denominator... First of all, wxWindows does not conform to 'lowest common denominator' status for widgets. If it did, it'd be unusable, just like every other toolkit that came before it that only supported the controls common across all supported platforms. My problem with writing multiple GUI front ends, given sufficiently separator code (assuming one subscribes to the MVC school of things), is that you have to maintain multiple code bases for the GUI frontend. This means that every time you make a data model change, I now have more than one GUI to update. I would argue that in 90% of the applications out there, this is unnecessary, and using a cross-platform toolkit would go unnoticed by the user. In those cases where you require decidedly platform-specific-can't-be-found-anywhere-else type of widgets and constructions, you are free to use a native toolkit, but certainly we should not abandon cross platforms toolkits because there's a few applications for which they are inappropriate. Bashing cross-platform toolkits, as Bob did in his session, just damages the chance that applications will come to the mac at all. I find it much more likely that an application will not be ported to the mac all than the GUI be rehosted on top of Cocoa, if you keep telling application developers that mac users will only accept the One True Way(tm) of Cocoa, which is just bunk. -- Nick From zbir at urbanape.com Wed Mar 31 17:47:45 2004 From: zbir at urbanape.com (Zachery Bir) Date: Wed Mar 31 17:47:51 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <2ED5FCC6-8363-11D8-A2DB-000393CBDF94@opnet.com> References: <368F68A4-8361-11D8-9AEC-000A958650B6@urbanape.com> <2ED5FCC6-8363-11D8-A2DB-000393CBDF94@opnet.com> Message-ID: <6D721A8B-8365-11D8-9AEC-000A958650B6@urbanape.com> On Mar 31, 2004, at 5:31 PM, Nick Bastin wrote: > Bashing cross-platform toolkits, as Bob did in his session, just > damages the chance that applications will come to the mac at all. Bull. It damages the chance that also ran, "Because it's easier than thinking about it" apps will do well in the Mac market. Applications that are ported to the Mac without taking into account the idioms of the platform will stand out like old, weird uncle Willy, whose left eye is just a shade off kilter, and gives everyone the impression that he might just wet himself for fun at Thanksgiving dinner. > I find it much more likely that an application will not be ported to > the mac all than the GUI be rehosted on top of Cocoa, if you keep > telling application developers that mac users will only accept the One > True Way(tm) of Cocoa, which is just bunk. All I'm saying is that new projects will prosper in the Mac market insofar as they consider the idioms of the platform and don't just slap a cross-platform UI on it at last moment. IFF the Mac market is important to them at all, they'll seriously consider using a native toolkit on top of abstracted data models. Zac -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2363 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040331/a3483813/smime.bin From bob at redivi.com Wed Mar 31 18:06:07 2004 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 31 18:02:06 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <2ED5FCC6-8363-11D8-A2DB-000393CBDF94@opnet.com> References: <368F68A4-8361-11D8-9AEC-000A958650B6@urbanape.com> <2ED5FCC6-8363-11D8-A2DB-000393CBDF94@opnet.com> Message-ID: On Mar 31, 2004, at 5:31 PM, Nick Bastin wrote: > Bashing cross-platform toolkits, as Bob did in his session, just > damages the chance that applications will come to the mac at all. I > find it much more likely that an application will not be ported to the > mac all than the GUI be rehosted on top of Cocoa, if you keep telling > application developers that mac users will only accept the One True > Way(tm) of Cocoa, which is just bunk. What's the difference (to open source projects, at least), if the toolkit is truly write once run everywhere? (that was rhetorical, don't bother responding). My slides and comments were a reflection of the current not-finished-yet status of the cross-platform Python GUI toolkits on the Mac as a warning to developers who are interested in Mac development. It says nothing about where wxPython will be in N months, only where it was when I made the presentation last week. In any case, this thread is of little use, as the presentation has already been given, and I wouldn't go back and change the relevant slides if given the chance. If you would like to advocate wxPython development on the mac, even though it's not currently possible to make native-like (in performance, functionality, and lack of visual defects) applications with it, then please feel free to give your own presentation. EuroPython is coming up soon, you better hurry! :) -bob From Chris.Barker at noaa.gov Wed Mar 31 19:08:07 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Mar 31 19:08:03 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: References: <200403302129.i2ULTLN08745@laplace.astro.cornell.edu> <1A3B7C1E-8295-11D8-A68D-000A95686CD8@redivi.com> <7B30F3F2-832A-11D8-9A41-000393CB1C86@tulane.edu> Message-ID: <406B5D67.7050200@noaa.gov> Wow! this is getting a little too close to a flame war for my tastes, but since no one asked, I'll put my $0.02 in as well. Jack Jansen wrote: > Moreover, I think that by emphasizing that wxPython (or any other > cross-platform solution) is pretty good but not on par with Cocoa Thanks Jack, this is really, I think, the most accurate and productive description of the state of wxPython on OS-X. I work in a small office that has been mostly Mac-centric since the Mac has been around. About 10 years ago, we realized that we wanted to distribute some of our home-grown apps to the general populous, and most of them use Windows. THe result was a mish-mash of dual-GUI code projects, and the use of a home-grown cross-platform toolkit, that is really a lot like wxWindows except much more limited, more ugly (at least on Windows), and still not running natively on the Mac. The idea of using MVC, or whatever, an writing two (or more) GUIs is a fine, but any application with a rich GUI ( and it it doesn't have a rick GUI, why have this argument at all) is going to be at least half GUI code. We've decided that we really can't support doing anything new on the Mac at all if it's going to take 50% or more time that writing it just for Windows, which we have no choice but to do. I'm still working on selling Python, but in the meantime, our most recent app was written in C++, using wxWindows. The two primary developers wrote on an OS-X box and a Windows box. We now have a working app with a pretty nice GUI on Windows, OS-X, OS-9 and Linux (I did the Linux port in a total of about a week of work). While there were different bugs on different platforms, there are only maybe a dozen or so platform independent lines of code in the project, mostly having to do with fonts and the like. We are very, very, pleased with the results, The previous project by the same two coders was written in Powerplant on the Mac, and MFC on Windows. writing in those two GUI toolkits took monstrously longer than one. We have another project starting that is going to be written in C++ for the computational code (the model), and wxPython for the GUI. I anticipate that it will work well, and am very glad that we're not trying to support another toolkit for the GUI. It just wouldn't happen. A point about how ugly an application written in wxPython is on the Mac. If the author writes it on Windows or GTK, and then just gets it running on the Mac, it's not going to look very good. Sizers don't do quite as good job on eh Mac (though they've gotten much better), and icons that look right on GTK, just don't look right on OS-X (see the toolbar buttons on my FloatCanvas for an example. It's ironic, since is stole those icons from an OS-9 application. If anyone wants to give me some better icons, I'd be glad to use them!). If you don't make an effort to make it look good on the Mac, it's not going to look good, but making that effort is a whole lot easier than rewriting the whole GUI. As for Cocoa being the only way to write good OS-X apps, I don't think I'm running anything on my Mac written in Cocoa other than the apps supplied by Apple. Bob Ippolito wrote: > If you would like to advocate wxPython > development on the mac, even though it's not currently possible to make > native-like (in performance, functionality, and lack of visual defects) It's possible, though still a bit more work than it should be. The latest 2.5 release is looking pretty good. My FloatCanvas is a little bit slower on my Mac than my Linux box, but it's quite tolerable. "native-like" is, of course, an imprecise term. As our goal is to make apps that look and feel the same on all platforms, we don't tend to take full advantage of platform specific features on either Windows or the Mac. I have to say, Bob, that I really appreciate all that you've done for Python on OS-X. I think I, and others on this list, were bothered by the tone of that part of your presentation. You could have said that PyObjC is the cat's pajamas, without saying that wxPython and TKinter were essentially useless. PyObjC and Cocoa just aren't an option for us (when OpenStep is working well on Windows and Linux, I'll look again). I don't want to give up my Linux box, and we've got IT people only giving us permission to use Macs on a year by year basis. I'm very glad that Stephan, Robin, Kevin (and many others) are making it possible to use my Mac. -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 at noaa.gov Wed Mar 31 19:29:16 2004 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Mar 31 19:29:06 2004 Subject: [Pythonmac-SIG] Bundle Builder Questions In-Reply-To: References: <368F68A4-8361-11D8-9AEC-000A958650B6@urbanape.com> <2ED5FCC6-8363-11D8-A2DB-000393CBDF94@opnet.com> Message-ID: <406B625C.9020603@noaa.gov> Hi all, Relevant to some of what I wrote as par tof our heated "is wxPython worth using" discussion, I'm trying, for the first time, to use BundleBuilder to make a stand alone app out of a wxPython app of mine. My first question, is how do I test it? I need to manually tell it to include some of the wxPython libraries, but if I don't, it still runs fine on my machine, as those libraries are present. I had to move it over to someone else's machine, test it, note which library it couldn't fine, include that, repeat 7 times. I'd really like an easier way! Two, I'm having trouble making a semi-standalone, which I think is what I want if I want to build and run it on 10.3 only. In my buildapp file, I put: myapp.standalone = 1 I get a standalone, with python itself included IF I try to replace that with: myapp.semi-standalone = 1 well, that won't work, as semi-standalone is not a valid identifier. If I build with: python buildapp.py --semi-standalone I still seem to get a python executable in the bundle, but I don't get the wxPython code, at least I don't think so. Three, and this is an odd one. If I make a Bundle, run it, stop it, put it in the trash, then try to empty the trash, I get an error, saying that "Python" is in use. THe only way I"ve found to delete it is to get it out of the trash, and rm it at the command line. Four: I needed to add 7 wxPython libraries. I expected this, but I'm surprised that I had to add all of them, including: libwx_macd_html libwx_base_carbond_net As I'm not using any of the wxHTML stuff, or any wx networking stuff. The resulting bundle is 22MB (and compresses to 6.2MB) so it wuld be nice to make that as small as possible! Thanks for any pointer, -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 janssen at parc.com Wed Mar 31 20:13:27 2004 From: janssen at parc.com (Bill Janssen) Date: Wed Mar 31 20:13:42 2004 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: Your message of "Wed, 31 Mar 2004 13:00:00 PST." Message-ID: <04Mar31.171328pst."58611"@synergy1.parc.xerox.com> > Although RB is pretty good for cross platform RAD when your needs are basic > (heh), we'd really like to move to all Python. So we'll be watching wxPython > with a lot of interest. By using Jython, you can use Python and the Java Swing window toolkit, which is easily portable. You can distribute applications as jar files. My bet for most portable Python approach. Though the flavor of Python supported by Jython is about 2.1. Bill From leknarf at pacbell.net Wed Mar 31 22:34:52 2004 From: leknarf at pacbell.net (Scott Frankel) Date: Thu Apr 1 00:27:34 2004 Subject: [Pythonmac-SIG] possible OT: os.chdir on OSX In-Reply-To: References: Message-ID: <8987F7DE-838D-11D8-A374-000A95A7B782@pacbell.net> Great! I'm looking forward to it. Fermat not withstanding ;) Scott On Mar 31, 2004, at 1:42 PM, Cameron Laird wrote: > ... absolutely true, and one of the classic FAQ > disappointments to many administrators and developers. > HOWEVER, what they *really* want is often just enough > different from "change the parent" that a programmatic > solution *is* possible: ... > [I was going to present the answer here, > but I'm being called away. I'll return > to the question later.] > From petersj at clemson.edu Wed Mar 31 15:47:50 2004 From: petersj at clemson.edu (Jim Peterson) Date: Thu Apr 1 09:08:45 2004 Subject: [Pythonmac-SIG] pyUI? Message-ID: <406B2E76.2050101@clemson.edu> Hi, In case you haven'f figured it out, the WGL import error comes from one of the __init__.py files which attempt to import some fonts from the windows WGL stuff. You don't want that. I just removed it from the init and all was fine. The offending line was in site-packages/pyui/renderers/openglBase.py I commented out from OpenGL.WGL import etc Jim