From kevino at tulane.edu Sun May 1 07:23:21 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Sun May 1 07:23:26 2005 Subject: [Pythonmac-SIG] site-packages symlink location changed in Tiger? Message-ID: <72C0D5EA-048B-43EA-811B-B52B3BAC2BEF@tulane.edu> Hi all, Like a good Mac citizen, I promptly picked up my copy of Tiger and upgraded yesterday, and I noticed that most of my third-party Python packages weren't being discovered. After re-installing one, I saw what (on my machine) was causing the problem: after upgrading, the location pointed to by the site-packages symlink in Tiger's Python.Framework was moved from "/Library/Python/2.3/" to "Library/ Python/2.3/site-packages/". Has anyone else seen this? I want to make sure I didn't run into some sort of glitch. Thanks, Kevin From njriley at uiuc.edu Sun May 1 07:28:21 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun May 1 07:28:24 2005 Subject: [Pythonmac-SIG] site-packages symlink location changed in Tiger? In-Reply-To: <72C0D5EA-048B-43EA-811B-B52B3BAC2BEF@tulane.edu> References: <72C0D5EA-048B-43EA-811B-B52B3BAC2BEF@tulane.edu> Message-ID: <20050501052821.GA14481@uiuc.edu> On Sat, Apr 30, 2005 at 10:23:21PM -0700, Kevin Ollivier wrote: > Hi all, > > Like a good Mac citizen, I promptly picked up my copy of Tiger and > upgraded yesterday, and I noticed that most of my third-party Python > packages weren't being discovered. After re-installing one, I saw > what (on my machine) was causing the problem: after upgrading, the > location pointed to by the site-packages symlink in Tiger's > Python.Framework was moved from "/Library/Python/2.3/" to "Library/ > Python/2.3/site-packages/". Has anyone else seen this? I want to make > sure I didn't run into some sort of glitch. This was covered on this mailing list a few days ago. -- Nicholas Riley | From ronaldoussoren at mac.com Sun May 1 12:46:16 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun May 1 12:46:33 2005 Subject: [Pythonmac-SIG] Python and Startup Items In-Reply-To: <25c1c2a366a05a92157f9c30f4aae696@mophilly.com> References: <9f8a70b5292f4f3376f990950867825a@mophilly.com> <25c1c2a366a05a92157f9c30f4aae696@mophilly.com> Message-ID: <98E4413E-F89B-4CAF-AD4F-2A2D5B9A1F0E@mac.com> On 29-apr-2005, at 22:04, Mark Phillips wrote: > On Apr 28, 2005, I wrote: > > >> I have created a Startup Item for macos x server 10.3.9 that >> invokes a shell script to start a python process. The startup item >> is called but the script fails. >> > > For anyone who read my query and wondered "yeah, what is the > solution to that"... > > Gary Perez provided the solution I needed: system daemons and > mach_init.d. I don't think mach_init.d is part of the public "API". Why don't you use a StartupItem? My guess is that /usr/bin/env picks up the wrong python. What happens when you change you PATH to be the same as your interactive shell? > > You can read his page regarding Webware for details. Scroll to the > bottom of his page. Worked perfectly. webware/panther.html> > > BTW, I failed to specify in my post that I was concerned with > system services, not user level startup behavior. > > Mark Phillips > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From konrad.hinsen at laposte.net Mon May 2 12:34:23 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon, 2 May 2005 12:34:23 +0200 Subject: [Pythonmac-SIG] py2app question In-Reply-To: References: <20050429203316.GA17364@typhoon.sdsu.edu> Message-ID: <334795797cedb4625957c460c7b737f3@laposte.net> On Apr 29, 2005, at 22:36, Bob Ippolito wrote: > Sounds like you did something really weird. The executable shouldn't > be named starsgui.app?! You're going to have to post more about what > you're doing (i.e. at > Just out of curiosity: what is the function of this executable that py2app creates? And how is it built? Understanding the launch procedure in detail certainly helps with debugging. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From bob at redivi.com Mon May 2 14:47:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 08:47:28 -0400 Subject: [Pythonmac-SIG] py2app question In-Reply-To: <334795797cedb4625957c460c7b737f3@laposte.net> References: <20050429203316.GA17364@typhoon.sdsu.edu> <334795797cedb4625957c460c7b737f3@laposte.net> Message-ID: On May 2, 2005, at 6:34 AM, konrad.hinsen at laposte.net wrote: > On Apr 29, 2005, at 22:36, Bob Ippolito wrote: > > >> Sounds like you did something really weird. The executable shouldn't >> be named starsgui.app?! You're going to have to post more about what >> you're doing (i.e. at >> >> > Just out of curiosity: what is the function of this executable that > py2app creates? And how is it built? Understanding the launch > procedure > in detail certainly helps with debugging. This is what the executable stub is for, it hasn't changed much since it was called PyMacApp: http://mail.python.org/pipermail/pythonmac-sig/2004-March/010475.html (thanks to njr for digging this up and reminding me I wrote this documentation) -bob From fonnesbeck at gmail.com Mon May 2 18:49:15 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Mon, 2 May 2005 12:49:15 -0400 Subject: [Pythonmac-SIG] Tkinter problems Message-ID: <723eb693050502094958395b7f@mail.gmail.com> I am attempting to get Tkinter working on a new Powerbook, but seem unable to do so (works fine on my old 'book). I have installed the Panther add-ons and TclTkAqua (Batteries included). However, nothing involving Tcltk seems to work. Idle dies: Traceback (most recent call last): File "/System/Library/Frameworks/Python.framework/Versions/2.3/bin/idle", line 3, in ? from idlelib.PyShell import main File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/idlelib/PyShell.py", line 19, in ? from Tkinter import * File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/Tkinter.py", line 38, in ? import _tkinter # If this fails your Python may not be configured for Tk ImportError: No module named _tkinter And the package manager comes up empty. Is there any way to fix this? Thanks, C. From bob at redivi.com Mon May 2 18:51:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 12:51:18 -0400 Subject: [Pythonmac-SIG] Tkinter problems In-Reply-To: <723eb693050502094958395b7f@mail.gmail.com> References: <723eb693050502094958395b7f@mail.gmail.com> Message-ID: <1B3F4741-79FB-48F0-9362-9006063C89A9@redivi.com> On May 2, 2005, at 12:49 PM, Chris Fonnesbeck wrote: > I am attempting to get Tkinter working on a new Powerbook, but seem > unable to do so (works fine on my old 'book). I have installed the > Panther add-ons and TclTkAqua (Batteries included). However, nothing > involving Tcltk seems to work. Idle dies: > > Traceback (most recent call last): > File "/System/Library/Frameworks/Python.framework/Versions/2.3/ > bin/idle", > line 3, in ? > from idlelib.PyShell import main > File "/System/Library/Frameworks/Python.framework/Versions/2.3/ > lib/python2.3/idlelib/PyShell.py", > line 19, in ? > from Tkinter import * > File "/System/Library/Frameworks/Python.framework/Versions/2.3/ > lib/python2.3/lib-tk/Tkinter.py", > line 38, in ? > import _tkinter # If this fails your Python may not be > configured for Tk > ImportError: No module named _tkinter > > And the package manager comes up empty. Is there any way to fix this? Get the _tkinter package from the "Mac OS X 10.3 (stock Python 2.3.0)" section at http://pythonmac.org/packages/ -bob From konrad.hinsen at laposte.net Mon May 2 19:17:25 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon, 2 May 2005 19:17:25 +0200 Subject: [Pythonmac-SIG] Distinguishing between Aqua Tk and X11 Tk Message-ID: <9e3152952060fbfe9ad335c878ca3a05@laposte.net> Is there a reliable method to find out at runtime if Tkinter uses Aqua Tk or X11 Tk? I need this to define keyboard shortcuts, they use "Command" with Aqua, but since X11 Tk doesn't seem to support this, they will need "Control" in that case. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From fclee at highstream.net Mon May 2 20:01:04 2005 From: fclee at highstream.net (Frederick C. Lee) Date: Mon, 2 May 2005 11:01:04 -0700 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <4263DA0D.7070600@noaa.gov> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> <4263DA0D.7070600@noaa.gov> Message-ID: <8CC00051-6127-47CA-907B-E5D18BC6DC1C@highstream.net> Greetings all... I'm a Python neophyte and am trying to run packages on the Mac (now 'Tiger'). Structurally, Potentially.... Python is a great scripting software and great for modeling systems being developed into Cocoa/Obj-C. What struck me as a big problem on the OS X is the lack of a universal package-management system. I've been trying to build the Thuban? GIS system that uses wxPython and other packages on my Mac. The Setup.py routine fails to find critical wxPython packages causing the whole build to fail. I tried setting the PYTHONPATH env variable, etc. What I'm trying to do, ultimately, is to create a savvy Cocoa/Obj-C GIS program based on Open-Source software. But it's a royal pain to build native open- source code on the OS X as a model to work from. The main problem is the builder (setup.py) just can find all the necessary stuff (even after ./configure). I'm hitting brick walls here. Ric. Frustrated Mac developer & Oceanographer-wanna-be. On Apr 18, 2005, at 9:02 AM, Chris Barker wrote: > konrad.hinsen at laposte.net wrote: > >>> Can users be trusted to put Python packages in the right place on >>> their own? If they have multiple versions of Python installed? I >>> would say no. >>> >> They do manage for applications, so why wouldn't they for Python >> packages? >> > > No, they don't. Mac users put Applications all over the place on > their systems. In fact, one of the main advantages of the self > contained application bundle is that you can do exactly that: put > it anywhere, and you can click on it to run it. The old Macintosh > was specifically designed to support that kind of behavior. They > advertised the fact that files could be moved all over the place > without disrupting the system (this wasn't entirely true, when it > came to the system folder, but it was a lot more true than with > Unix or DOS/Windows). That legacy lives on. If you don't give Mac > users an installer, many, many, people will drop a bundle some > arbitrary place, and expect it to work. > > That being said, better uninstallation and version managing would > be great. This is one place that Apple is WAY behind the Linux > distros. They all have package managing systems, many of them > pretty darn nice. > > I'd love to see some kind of package versioning management built > into things from the Python side, one that will work across > platforms. wxPython has a pretty good approach: > > http://wiki.wxpython.org/index.cgi/MultiVersionInstalls > > -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 at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From bob at redivi.com Mon May 2 20:05:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 14:05:00 -0400 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <8CC00051-6127-47CA-907B-E5D18BC6DC1C@highstream.net> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> <4263DA0D.7070600@noaa.gov> <8CC00051-6127-47CA-907B-E5D18BC6DC1C@highstream.net> Message-ID: On May 2, 2005, at 2:01 PM, Frederick C. Lee wrote: > Greetings all... > I'm a Python neophyte and am trying to run packages on the Mac > (now 'Tiger'). Structurally, Potentially.... Python is a great > scripting software and great for modeling systems being developed > into Cocoa/Obj-C. What struck me as a big problem on the OS X is > the lack of a universal package-management system. > > I've been trying to build the Thuban? GIS system that uses > wxPython and other packages on my Mac. The Setup.py routine fails > to find critical wxPython packages causing the whole build to fail. > I tried setting the PYTHONPATH env variable, etc. What I'm trying > to do, ultimately, is to create a savvy Cocoa/Obj-C GIS program based > on Open-Source software. But it's a royal pain to build native open- > source code on the OS X as a model to work from. The main problem > is the builder (setup.py) just can find all the necessary stuff (even > after ./configure). > > I'm hitting brick walls here. Well, if it's not finding wxPython, then Thuban's build scripts are broken, because wxPython ships with Tiger. Whether or not a package management solution existed, Thuban would still be broken. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2382 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050502/340848bb/smime.bin From lee_cullens at mac.com Mon May 2 20:56:31 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Mon, 2 May 2005 14:56:31 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1? In-Reply-To: <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> Message-ID: <6d853fba705d109f97af783b4479a908@mac.com> Not being one to jump before I look, I'm waiting on various issues (like DW) before I upgrade to Tiger. Also, since I have alternating external HD duplicates, I have decided a "clean" install would be the most appropriate for going forward. Specific to this list, I will be putting up Bob's MacPython 2.4.1 afterwards. Relative to such, am I correct in believing I will also need TclTkAqua, but will not need any of Jack's setups for 10.3 or Bob's TigerPython23Compat.pkg.zip? I know I will need to reinstall other 2.4 packages. Thanks, Lee C From konrad.hinsen at laposte.net Mon May 2 21:04:13 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon, 2 May 2005 21:04:13 +0200 Subject: [Pythonmac-SIG] py2app question In-Reply-To: References: <20050429203316.GA17364@typhoon.sdsu.edu> <334795797cedb4625957c460c7b737f3@laposte.net> Message-ID: <0456e63c398f46f7c6965ba21d637175@laposte.net> On May 2, 2005, at 14:47, Bob Ippolito wrote: > This is what the executable stub is for, it hasn't changed much since > it was called PyMacApp: > http://mail.python.org/pipermail/pythonmac-sig/2004-March/010475.html Ah, thanks.... This would make a nice addition to the py2app documentation! Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From bob at redivi.com Mon May 2 21:04:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 15:04:55 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1? In-Reply-To: <6d853fba705d109f97af783b4479a908@mac.com> References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> Message-ID: <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> On May 2, 2005, at 2:56 PM, Lee Cullens wrote: > Not being one to jump before I look, I'm waiting on various issues > (like DW) before I upgrade to Tiger. Also, since I have alternating > external HD duplicates, I have decided a "clean" install would be the > most appropriate for going forward. > > Specific to this list, I will be putting up Bob's MacPython 2.4.1 > afterwards. Relative to such, am I correct in believing I will also > need TclTkAqua, but will not need any of Jack's setups for 10.3 or > Bob's TigerPython23Compat.pkg.zip? I know I will need to reinstall > other 2.4 packages. You do not need TclTkAqua, because Tiger ships with it and the _tkinter in Python 2.4.1 will find it in /System/Library/Frameworks after failing to find it in the expected /Library/Frameworks. If you want to develop standalone applications that are compatible with Panther, you will need to install TclTkAqua, because py2app won't embed anything that Apple shipped with your OS. You will want TigerPython24Fix if you plan on building any extensions yourself, because Python 2.4 as configured with GCC 3.x has some GCC 4 incompatibilities, and that package will patch up the header so that GCC 4 will work. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2382 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050502/97ddd10b/smime.bin From sw at wordtech-software.com Mon May 2 21:47:07 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon, 02 May 2005 15:47:07 -0400 Subject: [Pythonmac-SIG] wxPython/Tiger? Message-ID: <427683BB.3000604@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --snip wxPython ships with Tiger. - -bob - --snip Did I read this right? Apple's shipping wxPython with Tiger? What version? (Just out of curiosity, why would they bundle wxPy and NOT PyObjC?...) - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCdoO7JmdQs+6YVcoRAkbzAJ9V4ri8nmlOuGV322nWyk3WKlaa4gCfUC2T ey0pC7R01Ud3ua5MxQ2+vzc= =MsOc -----END PGP SIGNATURE----- From bob at redivi.com Mon May 2 21:53:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 15:53:41 -0400 Subject: [Pythonmac-SIG] wxPython/Tiger? In-Reply-To: <427683BB.3000604@wordtech-software.com> References: <427683BB.3000604@wordtech-software.com> Message-ID: On May 2, 2005, at 3:47 PM, Kevin Walzer wrote: > - --snip > wxPython ships with Tiger. > > - -bob > - --snip > > Did I read this right? Apple's shipping wxPython with Tiger? What > version? From : Ships with a "unicode" build of wxPython 2.5.3. Mac OS X 10.3 did not ship with any wxPython or wxWidgets. I'm not sure whether this is good or bad, wxPython development moves pretty fast and the current Mac version isn't quite up to snuff yet. > (Just out of curiosity, why would they bundle wxPy and NOT PyObjC?...) Bundling a current release of PyObjC with Tiger would've definitely done more harm than good. -bob From njriley at uiuc.edu Mon May 2 22:09:26 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 2 May 2005 15:09:26 -0500 Subject: [Pythonmac-SIG] Distinguishing between Aqua Tk and X11 Tk In-Reply-To: <9e3152952060fbfe9ad335c878ca3a05@laposte.net> References: <9e3152952060fbfe9ad335c878ca3a05@laposte.net> Message-ID: <20050502200926.GB41092@uiuc.edu> On Mon, May 02, 2005 at 07:17:25PM +0200, konrad.hinsen at laposte.net wrote: > Is there a reliable method to find out at runtime if Tkinter uses Aqua > Tk or X11 Tk? I need this to define keyboard shortcuts, they use > "Command" with Aqua, but since X11 Tk doesn't seem to support this, > they will need "Control" in that case. I answered this question for you (!) in September 2004. -- Nicholas Riley | From bob at redivi.com Mon May 2 23:07:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 17:07:31 -0400 Subject: [Pythonmac-SIG] py2app question In-Reply-To: References: <20050429203316.GA17364@typhoon.sdsu.edu> <20050429210940.GC17364@typhoon.sdsu.edu> Message-ID: <8CE797B4-5BBB-4693-9022-7C33B1943354@redivi.com> On Apr 29, 2005, at 5:51 PM, Bob Ippolito wrote: > > On Apr 29, 2005, at 5:09 PM, Serge Rey wrote: > > >> On Fri, Apr 29, 2005 at 04:36:15PM -0400, Bob Ippolito wrote: >> >> >>> >>> On Apr 29, 2005, at 4:33 PM, Serge Rey wrote: >>> >>> >>> >>>> i'm trying to build a tkinter app using py2app and think i'm almost >>>> there but have hit a bit of a bump. >>>> >>>> the app starts but then immediately closes if i start it either >>>> of the >>>> following two ways: >>>> >>>> a. clicking on the starsgui.app icon in finder >>>> b. open starsgui.app (from a shell) >>>> >>>> however, from a shell if i cd into: >>>> starsgui.app/Contents/MacOS >>>> and then >>>> ./starsgui.app >>>> >>>> the built app runs just fine. >>>> >>>> >>>> so my question is, am i neglecting something painfully obvious that >>>> explains why cases a and b don't quite work yet? >>>> >>>> this is all under python 2.4 and py2app 0.1.9 >>>> >>>> >>> >>> Sounds like you did something really weird. The executable >>> shouldn't >>> be named starsgui.app?! You're going to have to post more about >>> what >>> you're doing (i.e. at least your setup.py) before I'd know something >>> definitive. >>> >>> >> >> sorry, the executable is starsgui not starsgui.app >> so the successful start is with ./starsgui >> from within starsgui.app/Contents/MacOs >> >> >> here is setup.py: >> >> from distutils.core import setup >> import py2app >> setup( >> app=['starsgui.py'], >> ) >> > > Perhaps there's something weird about what your application assumes > its environment is going to be? Check /Applications/Utilities/Console OK, the problem is because your application starts up and quits because sys.argv is not empty. Applications launched by LaunchServices receive at least one argument on the argv. Either change the code to ignore such arguments, or use the argv_emulation option. -bob From fclee at highstream.net Mon May 2 23:52:50 2005 From: fclee at highstream.net (Frederick C. Lee) Date: Mon, 2 May 2005 14:52:50 -0700 Subject: [Pythonmac-SIG] How can python incorporate GNU's readline library? Message-ID: <10E6F4C9-1FD9-4E19-BCC9-698AE3F2F6FB@highstream.net> Greetings: I've just installed Tiger (MacOSX 10.4). My current Python version is: [/Users/Ric]python Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin And I also have GNU's readline library via DarwinPorts: [/Users/Ric]port installed The following ports are currently installed: docbook-xml 4.3_0 (active) readline 5.0.005_0 (active) <-------- shapelib 1.2.10_0 (active) sqlite 2.8.15_0 (active) swig 1.3.24_0 (active) [/Users/Ric] But it appears that Python doesn't see the readline library. Typing a ctrl-P at the Python prompt doesn't do anything. How do I make Python aware of GNU's readline library? Thanks. Regards, Ric. From bob at redivi.com Tue May 3 00:10:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 18:10:38 -0400 Subject: [Pythonmac-SIG] How can python incorporate GNU's readline library? In-Reply-To: <10E6F4C9-1FD9-4E19-BCC9-698AE3F2F6FB@highstream.net> References: <10E6F4C9-1FD9-4E19-BCC9-698AE3F2F6FB@highstream.net> Message-ID: On May 2, 2005, at 5:52 PM, Frederick C. Lee wrote: > Greetings: > I've just installed Tiger (MacOSX 10.4). My current Python > version is: > > [/Users/Ric]python > Python 2.3.5 (#1, Mar 20 2005, 20:38:20) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin > > And I also have GNU's readline library via DarwinPorts: > > [/Users/Ric]port installed > The following ports are currently installed: > docbook-xml 4.3_0 (active) > readline 5.0.005_0 (active) <-------- > shapelib 1.2.10_0 (active) > sqlite 2.8.15_0 (active) > swig 1.3.24_0 (active) > [/Users/Ric] > > But it appears that Python doesn't see the readline library. Typing > a ctrl-P at the Python prompt doesn't do anything. > > How do I make Python aware of GNU's readline library? readline needs to be present during the process of building Python, because the readline extension must be built. Simply having readline installed on the system isn't going to do anything. Apple doesn't ship with readline (well it pretends to, but it's just BSD libedit, which isn't good enough for Python). What you want to do is go to http://pythonmac.org/packages/ and install TigerPython23Compat (from "Mac OS X 10.4 (stock Python 2.3.5)") and readline (from "Mac OS X 10.3 (stock Python 2.3.0)"). -bob From sw at wordtech-software.com Tue May 3 04:40:16 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon, 02 May 2005 22:40:16 -0400 Subject: [Pythonmac-SIG] Staying with system Python in Tiger Message-ID: <4276E490.9020102@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After digging more deeply into Tiger and finding that Apple has indeed included wxPython 2.5.3 and added the "build applet" tool to the Developer Tools, I've decided to keep my Python packages based on the Apple system Python. This will require fewer downloads for end users, and mean far less work for me in repackaging things (which means I will get it done much sooner). I will have to assemble a new installer for PyQt-Mac, but migrating my other packages will be trivial. I'll post an announcement when everything is ready. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCduSPJmdQs+6YVcoRAjvpAJ9v6bzAvd3oEA2RPj8EEJhUK0641wCgiLkF Q5KyTiVKeQYSZD2HJNLqN8Q= =XDL5 -----END PGP SIGNATURE----- From janssen at parc.com Tue May 3 05:30:25 2005 From: janssen at parc.com (Bill Janssen) Date: Mon, 2 May 2005 20:30:25 PDT Subject: [Pythonmac-SIG] Staying with system Python in Tiger In-Reply-To: Your message of "Mon, 02 May 2005 19:40:16 PDT." <4276E490.9020102@wordtech-software.com> Message-ID: <05May2.203027pdt."58617"@synergy1.parc.xerox.com> > After digging more deeply into Tiger and finding that Apple has indeed > included wxPython 2.5.3 and added the "build applet" tool to the > Developer Tools, I've decided to keep my Python packages based on the > Apple system Python. Thanks. This makes sense to me. Bill From bob at redivi.com Tue May 3 05:39:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 2 May 2005 23:39:13 -0400 Subject: [Pythonmac-SIG] Staying with system Python in Tiger In-Reply-To: <4276E490.9020102@wordtech-software.com> References: <4276E490.9020102@wordtech-software.com> Message-ID: <68E1C373-783C-4714-88A1-726B5949CC56@redivi.com> On May 2, 2005, at 10:40 PM, Kevin Walzer wrote: > After digging more deeply into Tiger and finding that Apple has indeed > included wxPython 2.5.3 and added the "build applet" tool to the > Developer Tools, I've decided to keep my Python packages based on the > Apple system Python. This will require fewer downloads for end users, > and mean far less work for me in repackaging things (which means I > will > get it done much sooner). I will have to assemble a new installer for > PyQt-Mac, but migrating my other packages will be trivial. I'll > post an > announcement when everything is ready. IIRC, Build Applet was there in 10.3 too... but just because Apple ships something doesn't mean its usable. bundlebuilder is quite flawed, and Build Applet is just a shim on top. -bob From ronaldoussoren at mac.com Tue May 3 13:10:18 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 3 May 2005 13:10:18 +0200 Subject: [Pythonmac-SIG] wxPython/Tiger? In-Reply-To: References: <427683BB.3000604@wordtech-software.com> Message-ID: <3D992CF3-B5BA-4AED-9368-CAC51AFE5766@mac.com> On 2-mei-2005, at 21:53, Bob Ippolito wrote: > > >> (Just out of curiosity, why would they bundle wxPy and NOT >> PyObjC?...) >> > > Bundling a current release of PyObjC with Tiger would've definitely > done more harm than good. That's a bit harsh, but true. PyObjC from before the release of Tiger didn't ship with wrappers for frameworks that were introduced in Tiger (CoreData, QTKit). I'm not unhappy about this situation, this makes it a lot easier to upgrade PyObjC. Upgrading wxPython on a Tiger box will be harder than it was on Panther. Luckily there's only one externe package in the Extras.pth :-) Ronald From charles.hartman at conncoll.edu Tue May 3 13:41:34 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 3 May 2005 07:41:34 -0400 Subject: [Pythonmac-SIG] wxPython/Tiger? In-Reply-To: <3D992CF3-B5BA-4AED-9368-CAC51AFE5766@mac.com> References: <427683BB.3000604@wordtech-software.com> <3D992CF3-B5BA-4AED-9368-CAC51AFE5766@mac.com> Message-ID: <501A5483-7DB3-46A7-BF63-DE405E7B9218@conncoll.edu> On May 3, 2005, at 7:10 AM, Ronald Oussoren wrote: > Upgrading wxPython on a Tiger box will be harder than > it was on Panther. Why? Not that I've tried yet; the first thing I tried when Tiger was through making itself at home was firing up Python (yup: 2.4.1) and importing wx (yup: 2.5.4.1). And that combination should build -- do I have this right yet? -- apps that will run in 10.4 and 10.3? Charles Hartman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050503/603df55b/attachment.html From ronaldoussoren at mac.com Tue May 3 13:58:27 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 3 May 2005 13:58:27 +0200 Subject: [Pythonmac-SIG] wxPython/Tiger? In-Reply-To: <501A5483-7DB3-46A7-BF63-DE405E7B9218@conncoll.edu> References: <427683BB.3000604@wordtech-software.com> <3D992CF3-B5BA-4AED-9368-CAC51AFE5766@mac.com> <501A5483-7DB3-46A7-BF63-DE405E7B9218@conncoll.edu> Message-ID: On 3-mei-2005, at 13:41, Charles Hartman wrote: > On May 3, 2005, at 7:10 AM, Ronald Oussoren wrote: > >> Upgrading wxPython on a Tiger box will be harder than >> it was on Panther. > > Why? This is only relevant when using Apple's version of Python. You'd have to make sure that the new version of wx gets picked when you import wx instead of the one shipped with Tiger. You'd also have to do this without removing or replacing anything in /System, because a software update can replace stuff there. > > Not that I've tried yet; the first thing I tried when Tiger was > through making itself at home was firing up Python (yup: 2.4.1) and > importing wx (yup: 2.5.4.1). And that combination should build -- > do I have this right yet? -- apps that will run in 10.4 and 10.3? If you use a Python framework and extensions that were compiled on Panther the resulting application should run on Panther and Tiger, even if you build it in Tiger. Ronald From konrad.hinsen at laposte.net Tue May 3 14:53:25 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Tue, 3 May 2005 14:53:25 +0200 Subject: [Pythonmac-SIG] Distinguishing between Aqua Tk and X11 Tk In-Reply-To: <20050502200926.GB41092@uiuc.edu> References: <9e3152952060fbfe9ad335c878ca3a05@laposte.net> <20050502200926.GB41092@uiuc.edu> Message-ID: <7a7cf9c8349c74413f57a1ec88343132@laposte.net> On May 2, 2005, at 22:09, Nicholas Riley wrote: > I answered this question for you (!) in September 2004. Oops, sorry.... While typing the message, I remembered the conversation back then and found it in the archives - but apparently I still sent off the message! BTW, it works fine :-) Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From wolfgang.keller.nospam at gmx.de Tue May 3 17:09:47 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Tue, 3 May 2005 17:09:47 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? Message-ID: <1458939782.20050503170947@gmx.de> Hello, has anyone already wrapped the getxattr(), setxattr(), removexattr(), listxattr() functions on MacOS 10.4 for Python? TIA, Best regards Wolfgang Keller -- P.S.: My From-address is correct From wolfgang.keller.nospam at gmx.de Tue May 3 16:47:19 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Tue, 3 May 2005 16:47:19 +0200 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> References: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> Message-ID: <454205626.20050503164719@gmx.de> Hello, > Update the PyOXIDE homepage - What homepage? There is nothing there. - Get rid of the HTTP/HTML forum and use a mailinglist instead. With bi-directional gatewaying to gmane.org, obviously. Best regards Wolfgang Keller -- P.S.: My From-address is correct From ronaldoussoren at mac.com Tue May 3 17:23:02 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 3 May 2005 17:23:02 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <1458939782.20050503170947@gmx.de> References: <1458939782.20050503170947@gmx.de> Message-ID: <12344C33-2F81-4936-8A10-8E68492FEF19@mac.com> On 3-mei-2005, at 17:09, Wolfgang Keller wrote: > Hello, > > has anyone already wrapped the getxattr(), setxattr(), > removexattr(), listxattr() functions on MacOS 10.4 for > Python? > You mean something like this? http://pyxattr.sourceforge.net/xattr.html This is the first hit for 'python xattr', I haven't checked if this actually works on OSX. Ronald From bob at redivi.com Tue May 3 17:46:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 May 2005 11:46:31 -0400 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <12344C33-2F81-4936-8A10-8E68492FEF19@mac.com> References: <1458939782.20050503170947@gmx.de> <12344C33-2F81-4936-8A10-8E68492FEF19@mac.com> Message-ID: <21CD7225-CA5E-42D5-ADFF-FB9B47520861@redivi.com> On May 3, 2005, at 11:23 AM, Ronald Oussoren wrote: > > On 3-mei-2005, at 17:09, Wolfgang Keller wrote: > > >> has anyone already wrapped the getxattr(), setxattr(), >> removexattr(), listxattr() functions on MacOS 10.4 for >> Python? >> >> > > You mean something like this? http://pyxattr.sourceforge.net/ > xattr.html > > This is the first hit for 'python xattr', I haven't checked if this > actually works on OSX. It doesn't, and it's GPL. Better off not looking at it. -bob From janssen at parc.com Tue May 3 19:23:57 2005 From: janssen at parc.com (Bill Janssen) Date: Tue, 3 May 2005 10:23:57 PDT Subject: [Pythonmac-SIG] Writing Automator actions in Python? Message-ID: <05May3.102403pdt."58617"@synergy1.parc.xerox.com> I see that new Actions for Automator can be written in either Applescript or (of course) Objective-C. Any way to slip Python in there, instead? Bill From bob at redivi.com Tue May 3 19:36:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 May 2005 13:36:50 -0400 Subject: [Pythonmac-SIG] Writing Automator actions in Python? In-Reply-To: <05May3.102403pdt."58617"@synergy1.parc.xerox.com> References: <05May3.102403pdt."58617"@synergy1.parc.xerox.com> Message-ID: On May 3, 2005, at 1:23 PM, Bill Janssen wrote: > I see that new Actions for Automator can be written in either > Applescript or (of course) Objective-C. Any way to slip Python in > there, instead? With PyObjC, the same way you'd do it in Objective-C. -bob From rsfinn at gmail.com Tue May 3 22:12:48 2005 From: rsfinn at gmail.com (Russell Finn) Date: Tue, 3 May 2005 16:12:48 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1? In-Reply-To: <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> Message-ID: Allow me to chime in with a couple of related questions: > On May 2, 2005, at 2:56 PM, Lee Cullens wrote: > > > Specific to this list, I will be putting up Bob's MacPython 2.4.1 > > afterwards. Is the 10.3 build of MacPython 2.4.1 still appropriate to install on Tiger? In particular, it looks (from doing Show Files in Installer) that it will apply the PantherPythonFix, and I understood that to be unnecessary (possibly undesirable?) in Tiger. On 5/2/05, Bob Ippolito wrote: > > You will want TigerPython24Fix if you plan on building any extensions > yourself, because Python 2.4 as configured with GCC 3.x has some GCC > 4 incompatibilities, and that package will patch up the header so > that GCC 4 will work. ... but this cannot be installed until after 2.4.1 is installed, right? (It won't install at the moment, and I haven't installed 2.4.1 yet pending the previous issue.) -- Russell From bob at redivi.com Tue May 3 22:25:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 May 2005 16:25:31 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1? In-Reply-To: References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> Message-ID: On May 3, 2005, at 4:12 PM, Russell Finn wrote: > Allow me to chime in with a couple of related questions: > > >> On May 2, 2005, at 2:56 PM, Lee Cullens wrote: >> >> >>> Specific to this list, I will be putting up Bob's MacPython 2.4.1 >>> afterwards. >>> > > Is the 10.3 build of MacPython 2.4.1 still appropriate to install on > Tiger? In particular, it looks (from doing Show Files in Installer) > that it will apply the PantherPythonFix, and I understood that to be > unnecessary (possibly undesirable?) in Tiger. Yes the 10.3 build of MacPython 2.4.1 is still appropriate. It looks like it does have PantherPythonFix embedded in it, but that's harmless. It shouldn't do that, but I didn't write the crazy package-builder scripts for MacPython :) > On 5/2/05, Bob Ippolito wrote: > >> >> You will want TigerPython24Fix if you plan on building any extensions >> yourself, because Python 2.4 as configured with GCC 3.x has some GCC >> 4 incompatibilities, and that package will patch up the header so >> that GCC 4 will work. >> > > ... but this cannot be installed until after 2.4.1 is installed, > right? (It won't install at the moment, and I haven't installed 2.4.1 > yet pending the previous issue.) It is a patch for Python 2.4.1, so it is necessary to have 2.4.1 installed. -bob From bob at redivi.com Tue May 3 23:14:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 May 2005 17:14:05 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1? In-Reply-To: References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> Message-ID: <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> On May 3, 2005, at 4:25 PM, Bob Ippolito wrote: > > On May 3, 2005, at 4:12 PM, Russell Finn wrote: > > >> Allow me to chime in with a couple of related questions: >> >> >> >>> On May 2, 2005, at 2:56 PM, Lee Cullens wrote: >>> >>> >>> >>>> Specific to this list, I will be putting up Bob's MacPython 2.4.1 >>>> afterwards. >>>> >>>> >> >> Is the 10.3 build of MacPython 2.4.1 still appropriate to install on >> Tiger? In particular, it looks (from doing Show Files in Installer) >> that it will apply the PantherPythonFix, and I understood that to be >> unnecessary (possibly undesirable?) in Tiger. >> > > Yes the 10.3 build of MacPython 2.4.1 is still appropriate. > > It looks like it does have PantherPythonFix embedded in it, but > that's harmless. It shouldn't do that, but I didn't write the crazy > package-builder scripts for MacPython :) > > >> On 5/2/05, Bob Ippolito wrote: >> >> >>> >>> You will want TigerPython24Fix if you plan on building any >>> extensions >>> yourself, because Python 2.4 as configured with GCC 3.x has some GCC >>> 4 incompatibilities, and that package will patch up the header so >>> that GCC 4 will work. >>> >>> >> >> ... but this cannot be installed until after 2.4.1 is installed, >> right? (It won't install at the moment, and I haven't installed >> 2.4.1 >> yet pending the previous issue.) >> > > It is a patch for Python 2.4.1, so it is necessary to have 2.4.1 > installed. ... and I just updated TigerPython24Fix such that it undoes the Makefile mangling from PantherPythonFix. It's up at pythonmac packages . -bob From bob at redivi.com Tue May 3 23:25:40 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 May 2005 17:25:40 -0400 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <1458939782.20050503170947@gmx.de> References: <1458939782.20050503170947@gmx.de> Message-ID: On May 3, 2005, at 11:09 AM, Wolfgang Keller wrote: > has anyone already wrapped the getxattr(), setxattr(), > removexattr(), listxattr() functions on MacOS 10.4 for > Python? I took a stab at it today. Get the xattr package from pythonmac packages source: http://svn.red-bean.com/bob/xattr/trunk I don't expose getxattr, etc. as public API, because the options they take don't translate well to Python. Public API is simply an "xattr" type that you can wrap over a path or fd, and then it's used in a dict-like way. There should be enough doc strings to get along. >>> import xattr >>> x = xattr.xattr('Desktop/Untitled.txt') >>> x.items() [(u'com.apple.FinderInfo', '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00')] >>> x['org.pythonmac.encoding'] = 'utf-8' >>> x.items() [(u'com.apple.FinderInfo', '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00'), (u'org.pythonmac.encoding', 'utf-8')] >>> del x['org.pythonmac.encoding'] >>> x.items() [(u'com.apple.FinderInfo', '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00')] -bob From delza at livingcode.org Wed May 4 00:19:31 2005 From: delza at livingcode.org (Dethe Elza) Date: Tue, 3 May 2005 15:19:31 -0700 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: References: <1458939782.20050503170947@gmx.de> Message-ID: Not specifically python, but the xattr program from Big Nerd Ranch looks useful, and could be called easily enough from code. source: http://dev.bignerdranch.com/public/bnr/eXttra.zip binary: http://dev.bignerdranch.com/public/bnr/xattr.dmg --Dethe Simple things should be declarative. Complex things should be procedural. --Adam Bosworth From lee_cullens at mac.com Wed May 4 04:31:45 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 3 May 2005 22:31:45 -0400 Subject: [Pythonmac-SIG] Regular Expression tools? Message-ID: <398c34b360d0b2b09152e6f80430aa67@mac.com> Been here before, but it's been awhile and can't remember what I used, and anyway that was a PC platform. So, if you use a Regular Expression tool (PCRE standard) for Python programming and your development platform is Mac OS X, would you please help narrow down the search for me. All I seem to be finding are other platforms and/or not standalone. Thanks, Lee C From bob at redivi.com Wed May 4 04:46:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 May 2005 22:46:03 -0400 Subject: [Pythonmac-SIG] Regular Expression tools? In-Reply-To: <398c34b360d0b2b09152e6f80430aa67@mac.com> References: <398c34b360d0b2b09152e6f80430aa67@mac.com> Message-ID: On May 3, 2005, at 10:31 PM, Lee Cullens wrote: > Been here before, but it's been awhile and can't remember what I used, > and anyway that was a PC platform. > > So, if you use a Regular Expression tool (PCRE standard) for Python > programming and your development platform is Mac OS X, would you > please > help narrow down the search for me. All I seem to be finding are > other > platforms and/or not standalone. Python doesn't use Perl's Crazy Regular Expressions -- but RegExplor is what you want. I have a very slightly modernized version of the source in my svn at: http://svn.red-bean.com/bob/RegexPlor/trunk Here's a binary that should work on Tiger.. but probably nowhere else, it uses a standalone Python and everything but its PyObjC was built on Tiger: http://undefined.org/python/RegexPlor-20050503-Tiger.zip -bob From lee_cullens at mac.com Wed May 4 05:08:31 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 3 May 2005 23:08:31 -0400 Subject: [Pythonmac-SIG] Regular Expression tools? In-Reply-To: References: <398c34b360d0b2b09152e6f80430aa67@mac.com> Message-ID: <55510814cb08d4d1211d13d951180913@mac.com> On May 3, 2005, at 10:46 PM, Bob Ippolito wrote: > > On May 3, 2005, at 10:31 PM, Lee Cullens wrote: > >> Been here before, but it's been awhile and can't remember what I used, >> and anyway that was a PC platform. >> >> So, if you use a Regular Expression tool (PCRE standard) for Python >> programming and your development platform is Mac OS X, would you >> please >> help narrow down the search for me. All I seem to be finding are >> other >> platforms and/or not standalone. > > Python doesn't use Perl's Crazy Regular Expressions -- but RegExplor > is what you want. > > I have a very slightly modernized version of the source in my svn at: > http://svn.red-bean.com/bob/RegexPlor/trunk > > Here's a binary that should work on Tiger.. but probably nowhere else, > it uses a standalone Python and everything but its PyObjC was built on > Tiger: > http://undefined.org/python/RegexPlor-20050503-Tiger.zip > > -bob > Thanks Bob, Looks like just the thing, when I put Tiger up (waiting for DW and Retrospect). For the moment I just wanted something for a couple days on 10.3.9 that I didn't have to go off on a tangent with to run. Lee C From bob at redivi.com Wed May 4 05:14:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 May 2005 23:14:50 -0400 Subject: [Pythonmac-SIG] Regular Expression tools? In-Reply-To: <55510814cb08d4d1211d13d951180913@mac.com> References: <398c34b360d0b2b09152e6f80430aa67@mac.com> <55510814cb08d4d1211d13d951180913@mac.com> Message-ID: <995FCB62-8809-4590-AAE4-34D00939FCBC@redivi.com> On May 3, 2005, at 11:08 PM, Lee Cullens wrote: > > On May 3, 2005, at 10:46 PM, Bob Ippolito wrote: > > >> >> On May 3, 2005, at 10:31 PM, Lee Cullens wrote: >> >> >>> Been here before, but it's been awhile and can't remember what I >>> used, >>> and anyway that was a PC platform. >>> >>> So, if you use a Regular Expression tool (PCRE standard) for Python >>> programming and your development platform is Mac OS X, would you >>> please >>> help narrow down the search for me. All I seem to be finding are >>> other >>> platforms and/or not standalone. >>> >> >> Python doesn't use Perl's Crazy Regular Expressions -- but RegExplor >> is what you want. >> >> I have a very slightly modernized version of the source in my svn at: >> http://svn.red-bean.com/bob/RegexPlor/trunk >> >> Here's a binary that should work on Tiger.. but probably nowhere >> else, >> it uses a standalone Python and everything but its PyObjC was >> built on >> Tiger: >> http://undefined.org/python/RegexPlor-20050503-Tiger.zip >> > > Looks like just the thing, when I put Tiger up (waiting for DW and > Retrospect). For the moment I just wanted something for a couple days > on 10.3.9 that I didn't have to go off on a tangent with to run. I gave you the URL for the parent site, which should have a binary. The reason I gave a separate URL for Tiger was that RegExplor was built with an old version of PyObjC and is *not* compatible with Tiger... however it should work fine on Jaguar and Panther. -bob From lee_cullens at mac.com Wed May 4 05:30:18 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 3 May 2005 23:30:18 -0400 Subject: [Pythonmac-SIG] Regular Expression tools? Correction In-Reply-To: References: <398c34b360d0b2b09152e6f80430aa67@mac.com> Message-ID: <1bf7ae3f530af1275eb14ef4c6805c02@mac.com> On May 3, 2005, at 10:46 PM, Bob Ippolito wrote: > > On May 3, 2005, at 10:31 PM, Lee Cullens wrote: > >> Been here before, but it's been awhile and can't remember what I used, >> and anyway that was a PC platform. >> >> So, if you use a Regular Expression tool (PCRE standard) for Python >> programming and your development platform is Mac OS X, would you >> please >> help narrow down the search for me. All I seem to be finding are >> other >> platforms and/or not standalone. > > Python doesn't use Perl's Crazy Regular Expressions -- but RegExplor > is what you want. > > I have a very slightly modernized version of the source in my svn at: > http://svn.red-bean.com/bob/RegexPlor/trunk > > Here's a binary that should work on Tiger.. but probably nowhere else, > it uses a standalone Python and everything but its PyObjC was built on > Tiger: > http://undefined.org/python/RegexPlor-20050503-Tiger.zip > > -bob > Bob, Don't you just hate it when you try to help someone and they don't listen :~) Yes, I got the quick (older) app from MacUpdate and it comes up without any prep. Will get your Tiger version when Tiger is up. Sorry to be so dense and thanks again, Lee C From bgranger at scu.edu Wed May 4 07:47:38 2005 From: bgranger at scu.edu (Brian Granger) Date: Tue, 03 May 2005 22:47:38 -0700 Subject: [Pythonmac-SIG] ANN: PyXG = Python + Xgrid Message-ID: Announcing PyXG PyXG = Python + Xgrid Summary: PyXG provides a Python interface to Xgrid, Xgrid is Apple's solution for running jobs on a cluster of Macintosh computers. The main goal of this project is to enable users to submit and manage Xgrid jobs on a cluster of Macs from a Python script or within an interactive Python session. Features: -- Use Xgrid from within python scripts as well as in interactive Python sessions -- Submit and manage simple (one task) and batch (many task) Xgrid jobs -- List available grids and query their status -- List active Xgrid jobs, query their status and perform various actions (delete, restart, etc.) on them -- Easily work with more than one Xgrid controller or grid at the same time. -- Quickly create sets of jobs using Python's powerful syntax The homepage for PyXG is at: http://hammonds.scu.edu/~classes/pyxg.html Apple's description of Xgrid is at: http://www.apple.com/server/macosx/features/xgrid.html Brian Granger Brian E. Granger Assistant Professor of Physics Santa Clara University bgranger at scu.edu Phone: 408-551-1891 Fax: 408-554-6965 From wolfgang.keller.nospam at gmx.de Wed May 4 12:38:20 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Wed, 4 May 2005 12:38:20 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: References: <1458939782.20050503170947@gmx.de> Message-ID: <106945803.20050504123820@gmx.de> Hello, > On May 3, 2005, at 11:09 AM, Wolfgang Keller wrote: >> has anyone already wrapped the getxattr(), setxattr(), >> removexattr(), listxattr() functions on MacOS 10.4 for >> Python? > I took a stab at it today. Hey, I had asked _whether_ someone has done it, I didn't ask you _to_ _do_ _it_! ;-) > Get the xattr package from pythonmac packages > Shame on me, I don't even have MacOS X.4 yet. *drvvf* > I don't expose getxattr, etc. as public API, because the options they > take don't translate well to Python. Public API is simply an "xattr" > type that you can wrap over a path or fd, and then it's used in a > dict-like way. That's _exactly_ the way it should be done. :-) Dumb question: How about integrating it "officially" in the Macpython distribution, so that all file objects on MacOS X.4 automatically have an xattr dict? Best regards, Wolfgang Keller -- P.S.: My From-address is correct From scott_bulkmail at prefab.com Wed May 4 13:17:08 2005 From: scott_bulkmail at prefab.com (Scott Lawton) Date: Wed, 4 May 2005 07:17:08 -0400 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <454205626.20050503164719@gmx.de> References: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> <454205626.20050503164719@gmx.de> Message-ID: Since this thread came up again, I'll take the liberty of adding my own $0.02 (I just joined the list recently): - in addition to reviewing recent threads that covered IDEs, please review threads that describe newbie impressions of MacPython. For example, Troy Rollins's views are quite important IMHO. I've followed MacPython for years, but haven't jumped in since I can't afford the productivity hit. A really good IDE makes a huge difference. - given the wide variety of free IDEs, perhaps its time for a paid one to enter the mix? Presumably that would allow more features in less time. For example, there's now a commercial editor for Perl on the Mac: Affrus from Late Night Software. (I know Mark; he's a great guy, but he didn't pay me to write this! Nor have I tried the product, though his Script Debugger for AppleScript is great.) ... for maximum reach, the IDE could have a dual license, e.g. free for shipping free software, commercial otherwise. There will be *some* complaints from both side, but still may be the best way to crank out the features. - robustness is more important than features! It's fun to add features, but for commercial developers, a few crashes may suffice to move on to something else. Test-driven development seems like a good fit here. - as others have said, please include some real information on your website. People want to have confidence that there's a serious effort to create a real product not just a quick hack for the fun of it. - without reviewing any of the great suggestions in previous threads, here are a few items on my priority list: * never crash * tight integration with Text Wrangler (free) and BBEdit (paid); let them worry about syntax highlighting and otherwise making a cool (if imperfect) editor * a real debugger: single step, breakpoints, step in/out, examine variables in a GUI, change values and continue running * the debugger should allow debugging of code that uses wxPython. And PyObjC to the extent that's possible (probably can't step into the ObjC part) and desirable (does XCode suffice?). * super convenient display of Python help, e.g. command-dbl-click on any keyword to jump right to relevent information about it (e.g. params for a function); perhaps option-dbl-click for a different bit of info (if there are 2 logical targets) -- note that you can probably add this to TextWrangler/BBEdit via AppleEvents and a script menu and/or a plug-in * did I mention "never crash"? - one thing Text Wrangler and BBEdit may not do: command completion. Wonder if it could be done as a plugin, or even via AppleEvents.... - and, one FUTURE: real outlining. That's also been mentioned in recent threads. I'll just add that Frontier is now open source, with an active group of developers. So, anyone can see how it works. (And, Radio UserLand has had a free trial version forever AFAIK.) Note that UserTalk (Frontier's native scripting language) is very much in the spirit of Python (e.g. uses indentation instead of curly braces). And, Frontier allows embedded AppleScript or any other OSA language (or did on OS 9; I haven't check on X). And, there's now an effort to integrate Python. http://www.scriptweb.org/FrontierAsOpenSource.html isn't quite up to date but points to the Yahoo Groups list and such. ... Is that long enough for a first post? cheers, Scott PreFab.com, ScriptWeb.org, etc. From konrad.hinsen at laposte.net Wed May 4 14:28:04 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Wed, 4 May 2005 14:28:04 +0200 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: References: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> <454205626.20050503164719@gmx.de> Message-ID: On May 4, 2005, at 13:17, Scott Lawton wrote: > - given the wide variety of free IDEs, perhaps its time for a paid one > to enter the mix? Presumably that would allow more features in less > time. For example, There is one good commercial IDE for Python, WingIDE. I use it (on a free open-source license) and I like it a lot, especially the debugger. But it's not a native Mac application (it uses Gtk and thus X11), which for Mac purists might be a problem. It does a pretty good job however in using Mac keyboard shortcuts, which for me is the essential compatibility aspect. > * tight integration with Text Wrangler (free) and BBEdit (paid); let > them worry about syntax highlighting and otherwise making a cool (if > imperfect) editor Unless those editors have a generous scripting API, this sounds impossible. You want to set breakpoints with a mouse click and have them marked graphically in the editor, right? How many editors have mechanisms that allow retrofitting such functionality? Other than Emacs, I couldn't name any. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From mwh at python.net Wed May 4 14:29:59 2005 From: mwh at python.net (Michael Hudson) Date: Wed, 04 May 2005 13:29:59 +0100 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <106945803.20050504123820@gmx.de> (Wolfgang Keller's message of "Wed, 4 May 2005 12:38:20 +0200") References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> Message-ID: <2m8y2vyy0o.fsf@starship.python.net> Wolfgang Keller writes: [xattr & co] > Dumb question: How about integrating it "officially" in the Macpython > distribution, so that all file objects on MacOS X.4 automatically have > an xattr dict? Are these functions in any way standard (eg. does FreeBSD have them?). If so, they should probably be detected at configure time. Another question is if empty xattr dicts should appear on platforms with no support for them. Cheers, mwh -- MARVIN: Do you want me to sit in a corner and rust, or just fall apart where I'm standing? -- The Hitch-Hikers Guide to the Galaxy, Episode 2 From konrad.hinsen at laposte.net Wed May 4 14:41:40 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Wed, 4 May 2005 14:41:40 +0200 Subject: [Pythonmac-SIG] Adding missing modules in py2app Message-ID: <54925fa9cff083a3cc1391afd188be0a@laposte.net> I noticed that py2app systematically leaves out some extension modules when I build an application package. I don't really blame it, as they reside in a directory that is only added to sys.path when some other module is imported, but I am looking for a way to tell py2app to include them nevertheless. At first I though the package option would do this, but after some experimentation and an inspection of the examples, it seems that it will only add Python packages (as it does with distutils in general). ext_modules is not what I want either, the modules are already built and installed, I just want them to be included. Is there some other approach that I could try? Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From petrilli at gmail.com Wed May 4 14:54:35 2005 From: petrilli at gmail.com (Christopher Petrilli) Date: Wed, 4 May 2005 08:54:35 -0400 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <2m8y2vyy0o.fsf@starship.python.net> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> Message-ID: <59d991c40505040554911a73@mail.gmail.com> On 5/4/05, Michael Hudson wrote: > Wolfgang Keller writes: > > [xattr & co] > > Dumb question: How about integrating it "officially" in the Macpython > > distribution, so that all file objects on MacOS X.4 automatically have > > an xattr dict? > > Are these functions in any way standard (eg. does FreeBSD have them?). > If so, they should probably be detected at configure time. I don't believe FreeBSD has them, but the SELinux project has them for ACLs, though they are poorly documented. They may also exist in other file systems, such as ReiserFS. Also, the concept exists on Solaris as well. The trick is that on Solaris and SELinux they're purely an ACL issue as far as I know. I believe Tiger is the first OS to fully deploy an abstract meta-data infrastructure in the FS. While ReiserFS has it, from what I'm told, it's not widely deployed. > Another question is if empty xattr dicts should appear on platforms > with no support for them. Yes, they should appear empty, and I would imagine, throw an Exception on any attempt to set them. Chris -- | Christopher Petrilli | petrilli at gmail.com From konrad.hinsen at laposte.net Wed May 4 14:45:16 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Wed, 4 May 2005 14:45:16 +0200 Subject: [Pythonmac-SIG] Some Mac packages for downloading Message-ID: I have started a small collection of Mac packages at http://dirac.cnrs-orleans.fr/MacPackages/ At the moment there is netCDF, ScientificPython, MMTK, and nMOLDYN. netCDF is also available from the netCDF Web site (I sent them my package, they liked it and plan to provide Mac packages themselves in the future). I also keep a copy of Numeric 23.7 around, just in case Bob updates his and I can't follow quickly enough. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From lee_cullens at mac.com Wed May 4 15:58:53 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed, 4 May 2005 09:58:53 -0400 Subject: [Pythonmac-SIG] Some Mac packages for downloading In-Reply-To: References: Message-ID: Konrad, Wanted to say thanks. Not packages I;d use every day :~) (more into engineering modeling) but it looks like things are starting to come together more in the Mac+Python community. Together with what Jack started and Bob is doing now, your work is a real contribution. Maybe at some point we might be able to pull together a more centralized repository for the less "build first" Python Mac users. I know other "software engineers" on Mac that are reluctant to get into Python yet, and though Apple is doing what they see fit it is not enough to encourage more widespread use. I've just gotten started in the Mac and Python environment (in my retirement), but if there is someway I might be able to help I'll give it a shot. At the moment I'm amusing myself with class design pattern methodology. Did more assembler, Fortran and C in my career, and this is a real joy. Anyway, thank you, Lee C On May 4, 2005, at 8:45 AM, konrad.hinsen at laposte.net wrote: > I have started a small collection of Mac packages at > > http://dirac.cnrs-orleans.fr/MacPackages/ > > At the moment there is netCDF, ScientificPython, MMTK, and nMOLDYN. > netCDF is also available from the netCDF Web site (I sent them my > package, they liked it and plan to provide Mac packages themselves in > the future). I also keep a copy of Numeric 23.7 around, just in case > Bob updates his and I can't follow quickly enough. > > Konrad. > -- > --------------------------------------------------------------------- > Konrad Hinsen > Laboratoire L?on Brillouin, CEA Saclay, > 91191 Gif-sur-Yvette Cedex, France > Tel.: +33-1 69 08 79 25 > Fax: +33-1 69 08 82 61 > E-Mail: khinsen at cea.fr > --------------------------------------------------------------------- > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From gary at modernsongs.com Wed May 4 17:15:54 2005 From: gary at modernsongs.com (Gary Poster) Date: Wed, 4 May 2005 11:15:54 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger Message-ID: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 from source. I guess if I were zen-ful about Mac packages I'd be able to figure out the necessary changes from the download...but I'm not. Could anyone help me know what I need to change? Thanks Gary From konrad.hinsen at laposte.net Wed May 4 17:29:08 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Wed, 4 May 2005 17:29:08 +0200 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> Message-ID: <1662a758ffd40d99afd2eecec3d602b0@laposte.net> On May 4, 2005, at 17:15, Gary Poster wrote: > Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a > framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 > from source. I guess if I were zen-ful about Mac packages I'd be > able to figure out the necessary changes from the download...but I'm > not. Could anyone help me know what I need to change? You could get it from Fink, or at least take a look at the Fink info file to see how they build it. However, I suppose that a straight build from the Python sources will yield just what you want, it's probably the Framework build that requires special action. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From bob at redivi.com Wed May 4 18:00:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 12:00:57 -0400 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <106945803.20050504123820@gmx.de> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> Message-ID: <05E6703D-DD72-41EC-ABBF-AF4C5CDF47AB@redivi.com> On May 4, 2005, at 6:38 AM, Wolfgang Keller wrote: >> On May 3, 2005, at 11:09 AM, Wolfgang Keller wrote: >> > > >>> has anyone already wrapped the getxattr(), setxattr(), >>> removexattr(), listxattr() functions on MacOS 10.4 for >>> Python? >>> > > >> I took a stab at it today. >> > > Hey, I had asked _whether_ someone has done it, I didn't ask you > _to_ _do_ _it_! ;-) > > >> Get the xattr package from pythonmac packages > > packages/>> > > Shame on me, I don't even have MacOS X.4 yet. *drvvf* > > >> I don't expose getxattr, etc. as public API, because the options they >> take don't translate well to Python. Public API is simply an "xattr" >> type that you can wrap over a path or fd, and then it's used in a >> dict-like way. >> > > That's _exactly_ the way it should be done. :-) > > Dumb question: How about integrating it "officially" in the Macpython > distribution, so that all file objects on MacOS X.4 automatically have > an xattr dict? Since that would be a feature addition, it wouldn't be able to integrate until Python 2.5 at the earliest. I don't really see the need to add platform-specific things to the file object though. No other platforms do it, and even the HFS stuff you can do with files needs to be done with Carbon.File, etc. In any case, I'd rather take all of the Mac specific stuff *out* of the Python standard library than put more in. -bob From cdamundsen at gmail.com Wed May 4 18:04:58 2005 From: cdamundsen at gmail.com (Craig Amundsen) Date: Wed, 4 May 2005 09:04:58 -0700 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <1662a758ffd40d99afd2eecec3d602b0@laposte.net> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <1662a758ffd40d99afd2eecec3d602b0@laposte.net> Message-ID: <8dc0c28f050504090437d3ac2c@mail.gmail.com> Hi - > However, I suppose that a straight build > from the Python sources will yield just what you want, it's probably > the Framework build that requires special action. That is correct. I built 2.4 from source and had to do a bit of command-line jiggling to get the Framework build instead of the vanilla Unix variety. - Craig From bob at redivi.com Wed May 4 18:15:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 12:15:55 -0400 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: References: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> <454205626.20050503164719@gmx.de> Message-ID: <813FBE34-FD24-41F6-A03A-DC9C91EA742D@redivi.com> On May 4, 2005, at 7:17 AM, Scott Lawton wrote: > - given the wide variety of free IDEs, perhaps its time for a paid > one to enter the mix? Presumably that would allow more features in > less time. For example, there's now a commercial editor for Perl > on the Mac: Affrus from Late Night Software. (I know Mark; he's a > great guy, but he didn't pay me to write this! Nor have I tried > the product, though his Script Debugger for AppleScript is great.) I don't think you have to worry about anyone here buying a Perl IDE :) If I had the time I'd write an IDE, but I have too many other things going on. > ... for maximum reach, the IDE could have a dual license, e.g. free > for shipping free software, commercial otherwise. There will be > *some* complaints from both side, but still may be the best way to > crank out the features. Wing is like this, but you have to "apply" for a free license, and it's X11 only. > - robustness is more important than features! It's fun to add > features, but for commercial developers, a few crashes may suffice > to move on to something else. Test-driven development seems like a > good fit here. I agree. > - without reviewing any of the great suggestions in previous > threads, here are a few items on my priority list: > * a real debugger: single step, breakpoints, step in/out, > examine variables in a GUI, change values and continue running > > * the debugger should allow debugging of code that uses > wxPython. And PyObjC to the extent that's possible (probably can't > step into the ObjC part) and desirable (does XCode suffice?). Wing has both of these, last I checked, because it Does The Right Thing and runs the "client" code in a separate process, and the debugger hooks are done over TCP (or maybe a pipe, but probably TCP). When doing it the right way, it doesn't matter which GUI framework you're using. Xcode (gdb really) can step into the C or Objective-C part of any program, but that's not going to do you much good. When you're coding in PyObjC, you're probably using Apple's frameworks, which are closed source, so stepping into Objective-C code isn't really going to do you any good. However, Xcode doesn't have a public API for debugger plugins (yet?) so nobody outside of Cupertino can currently, reasonably, write a Python debugger plugin. Among other reasons, this makes Xcode mostly unsuitable for Python development unless all you want is a text editor. > * super convenient display of Python help, e.g. command-dbl- > click on any keyword to jump right to relevent information about it > (e.g. params for a function); perhaps option-dbl-click for a > different bit of info (if there are 2 logical targets) -- note that > you can probably add this to TextWrangler/BBEdit via AppleEvents > and a script menu and/or a plug-in Well, in a plugin you can do anything.. but this is pretty hard to do in general unless you're running the Python code at the time. > - one thing Text Wrangler and BBEdit may not do: command > completion. Wonder if it could be done as a plugin, or even via > AppleEvents.... Xcode does this for any code, just by throwing everything it sees into the completion dictionary. It would be trivial for them to add similar support to Text Wrangle, since it is written in Cocoa and NSTextView has completion built-in. It could also be a plugin, I guess, but it would be easier for them to do on their own. If you take a look at PyObjC's PyInterpreter example, it implements completion, and it's not very hard. You can play with the completion, even in TextEdit... just type a partial word and hit opt-esc and it will complete against the dictionary. -bob From bob at redivi.com Wed May 4 18:16:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 12:16:50 -0400 Subject: [Pythonmac-SIG] Adding missing modules in py2app In-Reply-To: <54925fa9cff083a3cc1391afd188be0a@laposte.net> References: <54925fa9cff083a3cc1391afd188be0a@laposte.net> Message-ID: <21A6092B-CDD2-4B81-A9A1-07CFBC3107AD@redivi.com> On May 4, 2005, at 8:41 AM, konrad.hinsen at laposte.net wrote: > I noticed that py2app systematically leaves out some extension modules > when I build an application package. I don't really blame it, as they > reside in a directory that is only added to sys.path when some other > module is imported, but I am looking for a way to tell py2app to > include them nevertheless. > > At first I though the package option would do this, but after some > experimentation and an inspection of the examples, it seems that it > will only add Python packages (as it does with distutils in general). > ext_modules is not what I want either, the modules are already built > and installed, I just want them to be included. > > Is there some other approach that I could try? Modify sys.path in your setup script. -bob From bob at redivi.com Wed May 4 18:19:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 12:19:32 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> Message-ID: <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> On May 4, 2005, at 11:15 AM, Gary Poster wrote: > Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a > framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 > from source. I guess if I were zen-ful about Mac packages I'd be > able to figure out the necessary changes from the download...but I'm > not. Could anyone help me know what I need to change? Building Python 2.4.1 *on* Tiger has no issues, because I fixed that before Python 2.4.1 was released. Python 2.4.1 built on Panther, and moved over to Tiger, *does* have issues, and that's what TigerPython24Fix takes care of (along with another issue that's only relevant to the framework installer package). -bob From bob at redivi.com Wed May 4 18:20:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 12:20:31 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <8dc0c28f050504090437d3ac2c@mail.gmail.com> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <1662a758ffd40d99afd2eecec3d602b0@laposte.net> <8dc0c28f050504090437d3ac2c@mail.gmail.com> Message-ID: <97036CF3-2FE2-46D5-A667-16C72441B581@redivi.com> On May 4, 2005, at 12:04 PM, Craig Amundsen wrote: >> However, I suppose that a straight build >> from the Python sources will yield just what you want, it's probably >> the Framework build that requires special action. >> > > That is correct. I built 2.4 from source and had to do a bit of > command-line jiggling to get the Framework build instead of the > vanilla Unix variety. Where "a lot of command-line jiggling" means typing: ./configure --enable-framework && make && sudo make frameworkinstall instead of: ./configure && make && sudo make install -bob From delza at livingcode.org Wed May 4 18:29:39 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed, 4 May 2005 09:29:39 -0700 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <59d991c40505040554911a73@mail.gmail.com> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> Message-ID: > The trick is that on Solaris and SELinux they're purely an ACL issue > as far as I know. I believe Tiger is the first OS to fully deploy an > abstract meta-data infrastructure in the FS. While ReiserFS has it, > from what I'm told, it's not widely deployed. Not entirely true, BeOS pioneered file metadata infrastructure, as well as multi-fork files, but OS X may well be the first mainstream OS to do so. --Dethe "Why is Virtual Reality always posited in terms of space, when time is the only real commodity left?" --Rich Gold From petrilli at gmail.com Wed May 4 18:32:23 2005 From: petrilli at gmail.com (Christopher Petrilli) Date: Wed, 4 May 2005 12:32:23 -0400 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> Message-ID: <59d991c4050504093274454819@mail.gmail.com> On 5/4/05, Dethe Elza wrote: > > The trick is that on Solaris and SELinux they're purely an ACL issue > > as far as I know. I believe Tiger is the first OS to fully deploy an > > abstract meta-data infrastructure in the FS. While ReiserFS has it, > > from what I'm told, it's not widely deployed. > > Not entirely true, BeOS pioneered file metadata infrastructure, as > well as multi-fork files, but OS X may well be the first mainstream > OS to do so. Not to nit-pick, but multi-fork and metadata have existed on the Mac since HFS's introduction in, I believe 1985/1986 timeframe. BeOS took it much much further, but even the Mac was based on the meta-data ideas that existed in the Star and Alto designs. In many ways, we're still trying to get to the 1970s. Chris -- | Christopher Petrilli | petrilli at gmail.com From ronaldoussoren at mac.com Wed May 4 18:44:24 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 4 May 2005 18:44:24 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <05E6703D-DD72-41EC-ABBF-AF4C5CDF47AB@redivi.com> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <05E6703D-DD72-41EC-ABBF-AF4C5CDF47AB@redivi.com> Message-ID: <1029CF77-34A7-43EF-8FD2-80E0F72A122B@mac.com> On 4-mei-2005, at 18:00, Bob Ippolito wrote: >> >> That's _exactly_ the way it should be done. :-) >> >> Dumb question: How about integrating it "officially" in the >> Macpython >> distribution, so that all file objects on MacOS X.4 automatically >> have >> an xattr dict? >> > > Since that would be a feature addition, it wouldn't be able to > integrate until Python 2.5 at the earliest. I don't really see the > need to add platform-specific things to the file object though. No > other platforms do it, and even the HFS stuff you can do with files > needs to be done with Carbon.File, etc. > > In any case, I'd rather take all of the Mac specific stuff *out* of > the Python standard library than put more in. Agreed. What's needed is an easy interface for adding 3th party packages to an installation, something like the CPAN interface of Perl. That makes it possible to develop python-the-language seperately from packages without inconveniencing the user too much. Ronald From ronaldoussoren at mac.com Wed May 4 19:15:02 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 4 May 2005 19:15:02 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <59d991c4050504093274454819@mail.gmail.com> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> <59d991c4050504093274454819@mail.gmail.com> Message-ID: On 4-mei-2005, at 18:32, Christopher Petrilli wrote: > On 5/4/05, Dethe Elza wrote: > >>> The trick is that on Solaris and SELinux they're purely an ACL issue >>> as far as I know. I believe Tiger is the first OS to fully deploy an >>> abstract meta-data infrastructure in the FS. While ReiserFS has it, >>> from what I'm told, it's not widely deployed. >>> >> >> Not entirely true, BeOS pioneered file metadata infrastructure, as >> well as multi-fork files, but OS X may well be the first mainstream >> OS to do so. >> > > Not to nit-pick, but multi-fork and metadata have existed on the Mac > since HFS's introduction in, I believe 1985/1986 timeframe. BeOS took > it much much further, but even the Mac was based on the meta-data > ideas that existed in the Star and Alto designs. > > In many ways, we're still trying to get to the 1970s. > And the xattr API's were not an Apple invention. SGI seems to have them, Linux has them and there even seems to be a POSIX standard for them. Ronald From gary at modernsongs.com Wed May 4 20:15:27 2005 From: gary at modernsongs.com (Gary Poster) Date: Wed, 4 May 2005 14:15:27 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> Message-ID: On May 4, 2005, at 12:19 PM, Bob Ippolito wrote: > > On May 4, 2005, at 11:15 AM, Gary Poster wrote: > > >> Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a >> framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 >> from source. I guess if I were zen-ful about Mac packages I'd be >> able to figure out the necessary changes from the download...but I'm >> not. Could anyone help me know what I need to change? >> > > Building Python 2.4.1 *on* Tiger has no issues, because I fixed > that before Python 2.4.1 was released. > > Python 2.4.1 built on Panther, and moved over to Tiger, *does* have > issues, and that's what TigerPython24Fix takes care of (along with > another issue that's only relevant to the framework installer > package). Thanks for the reply. Building 2.4.1 on Tiger has issues for me, at least. Here is the problem I'm seeing. After running the following: tar xvzf Python-2.4.1.tgz cd Python-2.4.1 ./configure --prefix=/Users/gary/tmp/ make I then get this output from make: ...snip successful builds... gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include - DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o Modules/posixmodule.c: In function `posix_lchown': Modules/posixmodule.c:1352: warning: implicit declaration of function `lchown' Modules/posixmodule.c:5998:25: sys/statvfs.h: No such file or directory Modules/posixmodule.c: At top level: Modules/posixmodule.c:6001: error: parameter `st' has incomplete type Modules/posixmodule.c: In function `posix_fstatvfs': Modules/posixmodule.c:6047: error: storage size of `st' isn't known Modules/posixmodule.c:6052: warning: implicit declaration of function `fstatvfs'Modules/posixmodule.c:6047: warning: unused variable `st' Modules/posixmodule.c:6063:25: sys/statvfs.h: No such file or directory Modules/posixmodule.c: In function `posix_statvfs': Modules/posixmodule.c:6074: error: storage size of `st' isn't known Modules/posixmodule.c:6078: warning: implicit declaration of function `statvfs' Modules/posixmodule.c:6074: warning: unused variable `st' make: *** [Modules/posixmodule.o] Error 1 The same recipe didn't cause this problem on Panther/gcc 3.x yesterday. Any ideas? Thanks Gary From gary at modernsongs.com Wed May 4 21:21:39 2005 From: gary at modernsongs.com (Gary Poster) Date: Wed, 4 May 2005 15:21:39 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> Message-ID: On May 4, 2005, at 2:15 PM, Gary Poster wrote: > On May 4, 2005, at 12:19 PM, Bob Ippolito wrote: >> Building Python 2.4.1 *on* Tiger has no issues, because I fixed >> that before Python 2.4.1 was released. >> >> Python 2.4.1 built on Panther, and moved over to Tiger, *does* have >> issues, and that's what TigerPython24Fix takes care of (along with >> another issue that's only relevant to the framework installer >> package). > > Thanks for the reply. Building 2.4.1 on Tiger has issues for me, at > least. ... In the "put the finger in the dike" approach, actually modifying Modules/posixmodule.c, adding the following two lines at line 5991 (or anywhere earlier, of course) at least lets "make install" run to completion and more-or-less build: #undef HAVE_FSTATVFS #undef HAVE_STATVFS ...except that Tk appears to be pretty unhappy and I keep on getting /usr/include/AvailabilityMacros.h:101:6: #error MAC_OS_X_VERSION_MAX_ALLOWED must be >= MAC_OS_X_VERSION_MIN_REQUIRED all over the place. argh. Can anyone else who upgraded verify this behavior? The only things that I figure might possibly be affecting me (relatively) uniquely are packages from fink...I guess I'll try retreating from fink entirely next, expecially if no one else can duplicate. :-( Gary From bob at redivi.com Wed May 4 21:29:02 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 15:29:02 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> Message-ID: <57AF2958-A429-4D0A-A057-9D2DC3F43A03@redivi.com> On May 4, 2005, at 2:15 PM, Gary Poster wrote: > On May 4, 2005, at 12:19 PM, Bob Ippolito wrote: > > >> On May 4, 2005, at 11:15 AM, Gary Poster wrote: >> >> >> >>> Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a >>> framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 >>> from source. I guess if I were zen-ful about Mac packages I'd be >>> able to figure out the necessary changes from the download...but I'm >>> not. Could anyone help me know what I need to change? >>> >>> >> >> Building Python 2.4.1 *on* Tiger has no issues, because I fixed >> that before Python 2.4.1 was released. >> >> Python 2.4.1 built on Panther, and moved over to Tiger, *does* have >> issues, and that's what TigerPython24Fix takes care of (along with >> another issue that's only relevant to the framework installer >> package). >> > > Thanks for the reply. Building 2.4.1 on Tiger has issues for me, at > least. Here is the problem I'm seeing. After running the following: > > tar xvzf Python-2.4.1.tgz > cd Python-2.4.1 > ./configure --prefix=/Users/gary/tmp/ > make > > I then get this output from make: Try setting the MACOSX_DEPLOYMENT_TARGET environment variable to 10.4. Anything you build on Tiger isn't going to work prior to that anyway, so setting this can't hurt anything. I tried building 2.4.1 again and it worked just fine: % sw_vers ProductName: Mac OS X ProductVersion: 10.4 BuildVersion: 8A428 % cc --version powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061) ... % echo $MACOSX_DEPLOYMENT_TARGET 10.4 If you set this, and it still doesn't work, there's something else wrong with your configuration that I can't reproduce, so you're on your own if that is the case. I'm not really sure why you're trying not to build a framework Python in the first place, there's no particularly good reason why you'd want a non-framework Python around. -bob From hengist.podd at virgin.net Wed May 4 21:21:10 2005 From: hengist.podd at virgin.net (has) Date: Wed, 4 May 2005 20:21:10 +0100 Subject: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem Message-ID: Hi all, Probably one for Bob, but there's an unpleasant disagreement between Py23Compat and Python 2.4 on where the LaunchServices, OSA, and other new 2.4 modules are located: the former installs them in individual directories of the same name under site-packages, the later keeps them at the top level of plat-mac/Carbon. This means scripts written on Python 2.3 break on 2.4 and vice-versa when importing any of these modules. What's the fix? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed May 4 21:48:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 15:48:03 -0400 Subject: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem In-Reply-To: References: Message-ID: <96C7A633-3493-45D2-A660-9E7B367F84AA@redivi.com> On May 4, 2005, at 3:21 PM, has wrote: > Probably one for Bob, but there's an unpleasant disagreement > between Py23Compat and Python 2.4 on where the LaunchServices, OSA, > and other new 2.4 modules are located: the former installs them in > individual directories of the same name under site-packages, the > later keeps them at the top level of plat-mac/Carbon. This means > scripts written on Python 2.3 break on 2.4 and vice-versa when > importing any of these modules. What's the fix? This is not a bug, you need to write your code such that it accommodates for both: try: from LaunchServices import Launch, LaunchServices except ImportError: from Carbon import Launch, LaunchServices -bob From delza at livingcode.org Wed May 4 22:03:37 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed, 4 May 2005 13:03:37 -0700 Subject: [Pythonmac-SIG] AddressBook wrapper Message-ID: <4C63BFC6-B755-4BA4-A1D5-9A734115D5BA@livingcode.org> The AddressBook wrapper doesn't appear to expose the constants kABShowAsPerson (0), kABShowAsCompany (1), or kABShowAsMask (7). --Dethe Life is extinct on other planets. Thier scientists were more advanced than ours. --Mark Russell From hengist.podd at virgin.net Wed May 4 22:50:06 2005 From: hengist.podd at virgin.net (has) Date: Wed, 4 May 2005 21:50:06 +0100 Subject: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem In-Reply-To: <96C7A633-3493-45D2-A660-9E7B367F84AA@redivi.com> References: <96C7A633-3493-45D2-A660-9E7B367F84AA@redivi.com> Message-ID: Bob wrote: >>Probably one for Bob, but there's an unpleasant disagreement between Py23Compat and Python 2.4 [which] means scripts written on Python 2.3 break on 2.4 and vice-versa when importing any of these modules. What's the fix? > >This is not a bug, Maybe not, but it's hardly good design either. Any time I wish for gratuitous complexity or broken-by-design-ness I can easily use Perl or AppleScript instead. :p >try: > from LaunchServices import Launch, LaunchServices >except ImportError: > from Carbon import Launch, LaunchServices I figured that, but I'd rather hoped a more elegant solution might be forthcoming at source. Is there a good reason why they couldn't both agree on a common location, or at least provide the relevant aliases in 2.4 to preserve Python's much-vaunted backwards compatibility? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed May 4 23:01:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 17:01:09 -0400 Subject: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem In-Reply-To: References: <96C7A633-3493-45D2-A660-9E7B367F84AA@redivi.com> Message-ID: <55ECCD8D-AE70-48DD-ABE7-6F3038BF28F7@redivi.com> On May 4, 2005, at 4:50 PM, has wrote: > Bob wrote: > > >>> Probably one for Bob, but there's an unpleasant disagreement >>> between Py23Compat and Python 2.4 [which] means scripts written >>> on Python 2.3 break on 2.4 and vice-versa when importing any of >>> these modules. What's the fix? >>> >> >> This is not a bug, >> > > Maybe not, but it's hardly good design either. Any time I wish for > gratuitous complexity or broken-by-design-ness I can easily use > Perl or AppleScript instead. :p > >> try: >> from LaunchServices import Launch, LaunchServices >> except ImportError: >> from Carbon import Launch, LaunchServices >> > > I figured that, but I'd rather hoped a more elegant solution might > be forthcoming at source. Is there a good reason why they couldn't > both agree on a common location, or at least provide the relevant > aliases in 2.4 to preserve Python's much-vaunted backwards > compatibility? This is *FORWARDS* compatibility, not backwards. Forwards compatibility is always messy. You have three options: 1) Work around it 2) Require Python 2.4 3) Require the "non-standard-library" components even on 2.4 Pick one, there's nothing that can be done about it. -bob From wolfgang.keller.nospam at gmx.de Wed May 4 23:10:27 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Wed, 4 May 2005 23:10:27 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <59d991c40505040554911a73@mail.gmail.com> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> Message-ID: <128971055.20050504231027@gmx.de> Hello, >> > Dumb question: How about integrating it "officially" in the Macpython >> > distribution, so that all file objects on MacOS X.4 automatically have >> > an xattr dict? >> >> Are these functions in any way standard (eg. does FreeBSD have >> them?). If so, they should probably be detected at configure time. > I don't believe FreeBSD has them, but the SELinux project has them > for ACLs, though they are poorly documented. They may also exist in > other file systems, such as ReiserFS. Also, the concept exists on > Solaris as well. Basically _every_ "modern" file system has extended attributes. > The trick is that on Solaris and SELinux they're purely an ACL issue > as far as I know. The irony is that it seems that currently _no_ OS that supports extended attributes allows the user to actually use them. Because there's no UI. > I believe Tiger is the first OS to fully deploy an abstract > meta-data infrastructure in the FS. Most definitely not. In fact MacOS X actually seems to be (one of) the last OSes which supports user-definable extended attributes. As I've been told, OS/400 had even a real "filebase" including relations etc. for decades. VMS had EAs for decades as well. XFS is probably th eoldest unix filesystem with EAs. OS/2's HPFS has them since it existed etc... BeOS was/is apparently the only OS that allowed end user to actually use extended attributes. Through its "Tracker". While MacOS X.4 doesn't (provide a UI to user-defined extended attributes). Still. BTW: How many years after Jobs generated all hype bubbles to drag Amelio away from Be, hype bubbles which extremely ressembled those that MS created around "Chicago" in order to FUD users and companies away from OS/2...? It's been so long ago I can't even remember it. >> Another question is if empty xattr dicts should appear on platforms >> with no support for them. > Yes, they should appear empty, and I would imagine, throw an > Exception on any attempt to set them. Exactly. And, imho, the API (a dict) should be identical on all platforms that support EAs, not just on MacOS X. Best regards Wolfgang Keller -- P.S.: My From-address is correct From bob at redivi.com Wed May 4 23:30:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 17:30:34 -0400 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <128971055.20050504231027@gmx.de> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> <128971055.20050504231027@gmx.de> Message-ID: On May 4, 2005, at 5:10 PM, Wolfgang Keller wrote: >>>> > Basically _every_ "modern" file system has extended attributes. > >>> Another question is if empty xattr dicts should appear on platforms >>> with no support for them. >>> > > >> Yes, they should appear empty, and I would imagine, throw an >> Exception on any attempt to set them. >> > > And, imho, the API (a dict) should be identical on all platforms that > support EAs, not just on MacOS X. My implementation is open source and liberally licensed. Anyone who cares about extended attributes on other platforms can feel free to submit a patch or fork the code (if I become unresponsive to patches or something). I don't have care about this feature for other platforms, so I'm not going to write that code. -bob From hengist.podd at virgin.net Thu May 5 00:13:26 2005 From: hengist.podd at virgin.net (has) Date: Wed, 4 May 2005 23:13:26 +0100 Subject: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem In-Reply-To: <55ECCD8D-AE70-48DD-ABE7-6F3038BF28F7@redivi.com> References: <96C7A633-3493-45D2-A660-9E7B367F84AA@redivi.com> <55ECCD8D-AE70-48DD-ABE7-6F3038BF28F7@redivi.com> Message-ID: Bob wrote: >>I figured that, but I'd rather hoped a more elegant solution might be forthcoming at source. Is there a good reason why they couldn't both agree on a common location, or at least provide the relevant aliases in 2.4 to preserve Python's much-vaunted backwards compatibility? > >This is *FORWARDS* compatibility, not backwards. Forwards compatibility is always messy. Touch?. ;) >1) Work around it On my todo list. (Requiring 2.4 isn't an option as casual Python users are more likely to be using the stock 2.3.5 and won't want to upgrade just on my account.) Still, can't blame my hoping there might've been a better solution... language warts are always unhappy things, Python warts doubly so. Pity Apple decided to stuff Python.framework into /System instead of /Library, otherwise having Py23Compat install into plat-mac/Carbon might not have been out of the question. I don't suppose Apple would be interested in including these modules (in the correct location) in future Tiger updates...? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu May 5 00:25:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 18:25:48 -0400 Subject: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem In-Reply-To: References: <96C7A633-3493-45D2-A660-9E7B367F84AA@redivi.com> <55ECCD8D-AE70-48DD-ABE7-6F3038BF28F7@redivi.com> Message-ID: <66AC98C8-A6D7-4AD2-BCE1-9A17431CA276@redivi.com> On May 4, 2005, at 6:13 PM, has wrote: > Bob wrote: > > >>> I figured that, but I'd rather hoped a more elegant solution >>> might be forthcoming at source. Is there a good reason why they >>> couldn't both agree on a common location, or at least provide the >>> relevant aliases in 2.4 to preserve Python's much-vaunted >>> backwards compatibility? >>> >> >> This is *FORWARDS* compatibility, not backwards. Forwards >> compatibility is always messy. > > Touch?. ;) > >> 1) Work around it >> > > On my todo list. (Requiring 2.4 isn't an option as casual Python > users are more likely to be using the stock 2.3.5 and won't want to > upgrade just on my account.) > > Still, can't blame my hoping there might've been a better > solution... language warts are always unhappy things, Python warts > doubly so. Pity Apple decided to stuff Python.framework into / > System instead of /Library, otherwise having Py23Compat install > into plat-mac/Carbon might not have been out of the question. I > don't suppose Apple would be interested in including these modules > (in the correct location) in future Tiger updates...? Apple did everything the right way. Why on earth should they put System stuff anywhere but? ... and god I hope they don't start mangling their Python 2.3 distribution *mid-release* to look Python 2.4-ish. This problem wouldn't have existed if these modules weren't part of the standard library and/or they weren't part of the Carbon namespace. Ripping them out or replacing them altogether with something generated in a more modern way is probably the right thing to do, eventually, but so far nobody has cared enough to deal with it. In any case, basically all Mac OS X APIs (LaunchServices included) are better wrapped with PyObjC. The stuff in Carbon is either becoming deprecated or being wrapped by higher-level Objective-C or CoreFoundation-style APIs, both of which PyObjC is much more appropriate for. It's really just a question of when PyObjC's header- parsing capabilities will be able to wrap CoreFoundation-style stuff quickly and correctly. Fortunately Apple isn't shipping PyObjC with Mac OS X, so we actually have the opportunity to implement these things before they become frozen in time. -bob From gary at modernsongs.com Thu May 5 01:15:56 2005 From: gary at modernsongs.com (Gary Poster) Date: Wed, 4 May 2005 19:15:56 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <57AF2958-A429-4D0A-A057-9D2DC3F43A03@redivi.com> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> <57AF2958-A429-4D0A-A057-9D2DC3F43A03@redivi.com> Message-ID: <4A238DC7-5FE1-4D97-98D5-EEB62F3989AB@modernsongs.com> On May 4, 2005, at 3:29 PM, Bob Ippolito wrote: ... > % cc --version > powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple > Computer, Inc. build 4061) ... If I were a more experienced Mac user, I'd probably blush: the problem was that I had assumed my Tiger upgrade would also automatically upgrade my XCode installation. So, for history, if you see symptoms like mine, that means you need to upgrade XCode. After doing so, all appears to be good so far. > I'm not really sure why you're trying not to build a framework > Python in the first place, there's no particularly good reason why > you'd want a non-framework Python around. I'm a Zope developer. I often have multiple Pythons around, one (or sometimes more) for each large project. Framework builds help nothing for Zope, and friends have scared me off from using them except to replace the main Apple Python (which I just did sucessfully with your MacPython and TigerPython24Fix--thanks!). Maybe that's misplaced fear, but working among developers on other platforms, its (mildly) convenient if our buildouts all use the same buildout dance. Thanks for your help, and thanks to all those who replied. Gary From bob at redivi.com Thu May 5 01:30:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 19:30:30 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <4A238DC7-5FE1-4D97-98D5-EEB62F3989AB@modernsongs.com> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> <57AF2958-A429-4D0A-A057-9D2DC3F43A03@redivi.com> <4A238DC7-5FE1-4D97-98D5-EEB62F3989AB@modernsongs.com> Message-ID: On May 4, 2005, at 7:15 PM, Gary Poster wrote: > > On May 4, 2005, at 3:29 PM, Bob Ippolito wrote: > >> I'm not really sure why you're trying not to build a framework >> Python in the first place, there's no particularly good reason why >> you'd want a non-framework Python around. >> > > I'm a Zope developer. I often have multiple Pythons around, one (or > sometimes more) for each large project. Framework builds help > nothing for Zope, and friends have scared me off from using them > except to replace the main Apple Python (which I just did sucessfully > with your MacPython and TigerPython24Fix--thanks!). Maybe that's > misplaced fear, but working among developers on other platforms, its > (mildly) convenient if our buildouts all use the same buildout dance. Well, you don't build your own on Windows, do you? I don't see why you should have to build one on your Mac either. Framework builds are almost entirely self-contained (except for the /usr/local/bin symlinks), similar to a typical Windows install. In other words, why should you need to build Python 2.4.1 when there is already one built and available? I could understand if you were working off of some modified Python or off CVS HEAD or something.. but it seems like you're spending more time than you should have to. As far as friends scaring you off.. I dunno, maybe they didn't know what they were doing when they tried it, or they were bitten by some problem that has been solved long since. The only "incompatibility" with framework builds is that stupid extensions that don't use distutils in their build procedure aren't going to work out of the box, but they're probably not going to work out of the box anyway because Mac OS X's linker takes different options. -bob From mwh at python.net Wed May 4 23:30:24 2005 From: mwh at python.net (Michael Hudson) Date: Wed, 04 May 2005 22:30:24 +0100 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <128971055.20050504231027@gmx.de> (Wolfgang Keller's message of "Wed, 4 May 2005 23:10:27 +0200") References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> <128971055.20050504231027@gmx.de> Message-ID: <2m8y2uy8zz.fsf@starship.python.net> Wolfgang Keller writes: > Hello, > >>> > Dumb question: How about integrating it "officially" in the Macpython >>> > distribution, so that all file objects on MacOS X.4 automatically have >>> > an xattr dict? >>> >>> Are these functions in any way standard (eg. does FreeBSD have >>> them?). If so, they should probably be detected at configure time. > >> I don't believe FreeBSD has them, but the SELinux project has them >> for ACLs, though they are poorly documented. They may also exist in >> other file systems, such as ReiserFS. Also, the concept exists on >> Solaris as well. > > Basically _every_ "modern" file system has extended attributes. That's not quite the point: does "every" system possessing a driver for such a file system use the getxattr &c functions to access these features? > And, imho, the API (a dict) The should be "a mapping". > should be identical on all platforms that support EAs, not just on > MacOS X. Makes sense. Cheers, mwh -- Remember - if all you have is an axe, every problem looks like hours of fun. -- Frossie -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html From dreedmac at columbus.rr.com Thu May 5 01:55:44 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Wed, 4 May 2005 19:55:44 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> <57AF2958-A429-4D0A-A057-9D2DC3F43A03@redivi.com> <4A238DC7-5FE1-4D97-98D5-EEB62F3989AB@modernsongs.com> Message-ID: <1D20AC34-9AEE-43D5-A7AF-886007357842@columbus.rr.com> On May 4, 2005, at 7:30 PM, Bob Ippolito wrote: > > As far as friends scaring you off.. I dunno, maybe they didn't know > what they were doing when they tried it, or they were bitten by some > problem that has been solved long since. The only "incompatibility" > with framework builds is that stupid extensions that don't use > distutils in their build procedure aren't going to work out of the > box, but they're probably not going to work out of the box anyway > because Mac OS X's linker takes different options. > > -bob On a slightly related note, can I add third-party python modules to the framework using the standard Unix install process. For example, I'm using to installing Python modules on Linux using: python setup.py install or occasionally ./configure;make;make install I've installed your python2.4.1 on Tiger and the fix (just yesterday so I think I got the updated fix). I've installed a number of the packages your or someone else already built (Numeric, PyOpenGL, etc.), but what do I do if I want a module someone hasn't built. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2377 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050504/46017278/smime-0001.bin From bob at redivi.com Thu May 5 02:04:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 20:04:53 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: <1D20AC34-9AEE-43D5-A7AF-886007357842@columbus.rr.com> References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> <57AF2958-A429-4D0A-A057-9D2DC3F43A03@redivi.com> <4A238DC7-5FE1-4D97-98D5-EEB62F3989AB@modernsongs.com> <1D20AC34-9AEE-43D5-A7AF-886007357842@columbus.rr.com> Message-ID: On May 4, 2005, at 7:55 PM, David Reed wrote: > > On May 4, 2005, at 7:30 PM, Bob Ippolito wrote: > > >> As far as friends scaring you off.. I dunno, maybe they didn't know >> what they were doing when they tried it, or they were bitten by some >> problem that has been solved long since. The only "incompatibility" >> with framework builds is that stupid extensions that don't use >> distutils in their build procedure aren't going to work out of the >> box, but they're probably not going to work out of the box anyway >> because Mac OS X's linker takes different options. > > > On a slightly related note, can I add third-party python modules to > the framework using the standard Unix install process. For example, > I'm using to installing Python modules on Linux using: > python setup.py install Very likely to work, but the module may not be compatible with Mac OS X at all. > or occasionally ./configure;make;make install Less likely, but maybe. It's a bug if any Python extensions use autoconf to build themselves. They should be using distutils. These extensions probably don't work at all on Mac OS X in the first place. -bob From janssen at parc.com Thu May 5 02:05:40 2005 From: janssen at parc.com (Bill Janssen) Date: Wed, 4 May 2005 17:05:40 PDT Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: Your message of "Wed, 04 May 2005 05:28:04 PDT." Message-ID: <05May4.170546pdt."58617"@synergy1.parc.xerox.com> > How many editors have mechanisms that allow retrofitting such > functionality? Other than Emacs, I couldn't name any. Hey, once you've named Emacs, there's no need to name any others :-). Bill From erik at plastic-idolatry.com Thu May 5 03:51:19 2005 From: erik at plastic-idolatry.com (Erik Osheim) Date: Wed, 4 May 2005 21:51:19 -0400 Subject: [Pythonmac-SIG] getting/setting system volume in OS X with python? Message-ID: <20050505015119.GA2418@cage.plastic-idolatry.com> Hello list, I've been developing a curses-based music player in python for the last couple of years (http://www.bearhome.net/mpy3) and it is getting pretty good these days. I have added keybindings to control volume in linux using the ossaudiodev module found in python. I wanted to do the same thing under OS X which I am now trying to fully support. After some digging, it looked to me like Carbon.Snd was the ticket. However, I can't find any documentation on this module; I did some digging in Apple provided docs, and was able to get a semi-working, semi-broken version of volume control going (mutes one ear, controls the volume of the other), but I am not sure this will do it. My questions are: 1. Does anyone have a good idea how to go about doing this best on OS X? I am not going to be able to support OS 9 (too many unix dependencies) so if there is a cleaner way to do it than Carbon I would be interested. 2. Is there anywhere to get better docs on things like ae*, Carbon.*, etc? It seems like python for mac is incredibly powerful but arcane, and between no documentation and no doc strings I have a hard time figuring out what I can do with it. Please include me in the replies since I am not a subscriber to this list (yet ;) ). Thanks, -- Erik From bob at redivi.com Thu May 5 04:35:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 22:35:53 -0400 Subject: [Pythonmac-SIG] getting/setting system volume in OS X with python? In-Reply-To: <20050505015119.GA2418@cage.plastic-idolatry.com> References: <20050505015119.GA2418@cage.plastic-idolatry.com> Message-ID: <7C9BA3E5-207C-46BD-8242-6AF73B192641@redivi.com> On May 4, 2005, at 9:51 PM, Erik Osheim wrote: > I've been developing a curses-based music player in python for the > last couple of years (http://www.bearhome.net/mpy3) and it is getting > pretty good these days. I have added keybindings to control volume in > linux using the ossaudiodev module found in python. > > I wanted to do the same thing under OS X which I am now trying to > fully support. After some digging, it looked to me like Carbon.Snd was > the ticket. However, I can't find any documentation on this module; I > did some digging in Apple provided docs, and was able to get a > semi-working, semi-broken version of volume control going (mutes one > ear, controls the volume of the other), but I am not sure this will do > it. > > My questions are: > > 1. Does anyone have a good idea how to go about doing this best on OS > X? I am not going to be able to support OS 9 (too many unix > dependencies) so if there is a cleaner way to do it than Carbon I > would be interested. The best way to do it on OS X is to use CoreAudio, but none of that is wrapped in Python. You can, however, find an Objective-C framework that wraps what you need (MTCoreAudio should be able to do it, but there might be something easier) and just call into that with PyObjC. There are a couple other ways, but they're all really, really old and deprecated and they often behave pretty strangely. > 2. Is there anywhere to get better docs on things like ae*, Carbon.*, > etc? It seems like python for mac is incredibly powerful but arcane, > and between no documentation and no doc strings I have a hard time > figuring out what I can do with it. The first thing you should do is look for another way to do it, with PyObjC or some POSIX API (but probably PyObjC). There's a very straightforward translation between Objective-C and Python, so you use Apple's Cocoa docs when developing with PyObjC. If there is no way to do what you need with just PyObjC, you should consider just writing a little Objective-C wrapper that does what you need to do (calling into Carbon, CoreFoundation etc.), and call into that from PyObjC. Use the Apple documentation. Unfortunately this does require knowing C, but the ONLY documentation and the ONLY supported APIs are for C and Objective-C. Most of the time, in my experience, it's just quicker to write and debug the code (i.e. QuickTime related stuff) in Objective-C and call into it from PyObjC. If you still feel the need to try and do it with "pure Python", then read the Apple documentation for the relevant function(s) in C, and then guess at how it would be done from Python. Everything in Carbon.* is automatically generated, but there are a bunch of special cases and the rules are a bit strange. These modules would sooner go away than become documented. Don't be surprised if there's a bug in the wrapper or some function call sequence is impossible because the wrapper won't let you pass NULL somewhere, etc. Writing code using undocumented modules that may be broken is no fun. -bob From brownr at ucalgary.ca Thu May 5 05:07:14 2005 From: brownr at ucalgary.ca (Robert Brown) Date: Wed, 4 May 2005 21:07:14 -0600 Subject: [Pythonmac-SIG] getting/setting system volume in OS X with python? In-Reply-To: <7C9BA3E5-207C-46BD-8242-6AF73B192641@redivi.com> References: <20050505015119.GA2418@cage.plastic-idolatry.com> <7C9BA3E5-207C-46BD-8242-6AF73B192641@redivi.com> Message-ID: <5DE13AF1-5289-469D-8BDF-43B4D774D7C5@ucalgary.ca> You could use Applescript to do it too. But PyObjC is really a wonderful tool. On 4-May-05, at 8:35 PM, Bob Ippolito wrote: > On May 4, 2005, at 9:51 PM, Erik Osheim wrote: > > >> I've been developing a curses-based music player in python for the >> last couple of years (http://www.bearhome.net/mpy3) and it is getting >> pretty good these days. I have added keybindings to control volume in >> linux using the ossaudiodev module found in python. >> >> I wanted to do the same thing under OS X which I am now trying to >> fully support. After some digging, it looked to me like Carbon.Snd >> was >> the ticket. However, I can't find any documentation on this module; I >> did some digging in Apple provided docs, and was able to get a >> semi-working, semi-broken version of volume control going (mutes one >> ear, controls the volume of the other), but I am not sure this >> will do >> it. >> >> My questions are: >> >> 1. Does anyone have a good idea how to go about doing this best on OS >> X? I am not going to be able to support OS 9 (too many unix >> dependencies) so if there is a cleaner way to do it than Carbon I >> would be interested. >> > > The best way to do it on OS X is to use CoreAudio, but none of that > is wrapped in Python. You can, however, find an Objective-C > framework that wraps what you need (MTCoreAudio should be able to do > it, but there might be something easier) and just call into that with > PyObjC. > > There are a couple other ways, but they're all really, really old and > deprecated and they often behave pretty strangely. > > >> 2. Is there anywhere to get better docs on things like ae*, Carbon.*, >> etc? It seems like python for mac is incredibly powerful but arcane, >> and between no documentation and no doc strings I have a hard time >> figuring out what I can do with it. >> > > The first thing you should do is look for another way to do it, with > PyObjC or some POSIX API (but probably PyObjC). There's a very > straightforward translation between Objective-C and Python, so you > use Apple's Cocoa docs when developing with PyObjC. > > If there is no way to do what you need with just PyObjC, you should > consider just writing a little Objective-C wrapper that does what you > need to do (calling into Carbon, CoreFoundation etc.), and call into > that from PyObjC. Use the Apple documentation. Unfortunately this > does require knowing C, but the ONLY documentation and the ONLY > supported APIs are for C and Objective-C. Most of the time, in my > experience, it's just quicker to write and debug the code (i.e. > QuickTime related stuff) in Objective-C and call into it from PyObjC. > > If you still feel the need to try and do it with "pure Python", then > read the Apple documentation for the relevant function(s) in C, and > then guess at how it would be done from Python. Everything in > Carbon.* is automatically generated, but there are a bunch of special > cases and the rules are a bit strange. These modules would sooner go > away than become documented. Don't be surprised if there's a bug in > the wrapper or some function call sequence is impossible because the > wrapper won't let you pass NULL somewhere, etc. Writing code using > undocumented modules that may be broken is no fun. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > --------------------------------------------------- Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050504/3a099182/attachment-0001.htm From bob at redivi.com Thu May 5 05:19:02 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 May 2005 23:19:02 -0400 Subject: [Pythonmac-SIG] getting/setting system volume in OS X with python? In-Reply-To: <5DE13AF1-5289-469D-8BDF-43B4D774D7C5@ucalgary.ca> References: <20050505015119.GA2418@cage.plastic-idolatry.com> <7C9BA3E5-207C-46BD-8242-6AF73B192641@redivi.com> <5DE13AF1-5289-469D-8BDF-43B4D774D7C5@ucalgary.ca> Message-ID: <9375D208-02E5-466F-84C9-A6FB4E3ABBB0@redivi.com> I was thinking specifically of AppleScript and SoundManager when I said "There are a couple other ways, but they're all really, really old and deprecated and often behave strangely". On May 4, 2005, at 11:07 PM, Robert Brown wrote: > You could use Applescript to do it too. But PyObjC is really a > wonderful tool. > > > On 4-May-05, at 8:35 PM, Bob Ippolito wrote: > >> On May 4, 2005, at 9:51 PM, Erik Osheim wrote: >> >> >>> I've been developing a curses-based music player in python for the >>> last couple of years (http://www.bearhome.net/mpy3) and it is >>> getting >>> pretty good these days. I have added keybindings to control >>> volume in >>> linux using the ossaudiodev module found in python. >>> >>> I wanted to do the same thing under OS X which I am now trying to >>> fully support. After some digging, it looked to me like >>> Carbon.Snd was >>> the ticket. However, I can't find any documentation on this >>> module; I >>> did some digging in Apple provided docs, and was able to get a >>> semi-working, semi-broken version of volume control going (mutes one >>> ear, controls the volume of the other), but I am not sure this >>> will do >>> it. >>> >>> My questions are: >>> >>> 1. Does anyone have a good idea how to go about doing this best >>> on OS >>> X? I am not going to be able to support OS 9 (too many unix >>> dependencies) so if there is a cleaner way to do it than Carbon I >>> would be interested. >>> >> >> The best way to do it on OS X is to use CoreAudio, but none of that >> is wrapped in Python. You can, however, find an Objective-C >> framework that wraps what you need (MTCoreAudio should be able to do >> it, but there might be something easier) and just call into that with >> PyObjC. >> >> There are a couple other ways, but they're all really, really old and >> deprecated and they often behave pretty strangely. >> >> >>> 2. Is there anywhere to get better docs on things like ae*, >>> Carbon.*, >>> etc? It seems like python for mac is incredibly powerful but arcane, >>> and between no documentation and no doc strings I have a hard time >>> figuring out what I can do with it. >>> >> >> The first thing you should do is look for another way to do it, with >> PyObjC or some POSIX API (but probably PyObjC). There's a very >> straightforward translation between Objective-C and Python, so you >> use Apple's Cocoa docs when developing with PyObjC. >> >> If there is no way to do what you need with just PyObjC, you should >> consider just writing a little Objective-C wrapper that does what you >> need to do (calling into Carbon, CoreFoundation etc.), and call into >> that from PyObjC. Use the Apple documentation. Unfortunately this >> does require knowing C, but the ONLY documentation and the ONLY >> supported APIs are for C and Objective-C. Most of the time, in my >> experience, it's just quicker to write and debug the code (i.e. >> QuickTime related stuff) in Objective-C and call into it from PyObjC. >> >> If you still feel the need to try and do it with "pure Python", then >> read the Apple documentation for the relevant function(s) in C, and >> then guess at how it would be done from Python. Everything in >> Carbon.* is automatically generated, but there are a bunch of special >> cases and the rules are a bit strange. These modules would sooner go >> away than become documented. Don't be surprised if there's a bug in >> the wrapper or some function call sequence is impossible because the >> wrapper won't let you pass NULL somewhere, etc. Writing code using >> undocumented modules that may be broken is no fun. >> >> -bob >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > --------------------------------------------------- > Robb Brown > Seaman Family MR Research Centre > Calgary, Alberta, Canada > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From ronaldoussoren at mac.com Thu May 5 13:26:12 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 5 May 2005 13:26:12 +0200 Subject: [Pythonmac-SIG] AddressBook wrapper In-Reply-To: <4C63BFC6-B755-4BA4-A1D5-9A734115D5BA@livingcode.org> References: <4C63BFC6-B755-4BA4-A1D5-9A734115D5BA@livingcode.org> Message-ID: On 4-mei-2005, at 22:03, Dethe Elza wrote: > The AddressBook wrapper doesn't appear to expose the constants > kABShowAsPerson (0), kABShowAsCompany (1), or kABShowAsMask (7). It does now (PyObjC repository, revision 1609) Ronald From gary at modernsongs.com Thu May 5 18:55:57 2005 From: gary at modernsongs.com (Gary Poster) Date: Thu, 5 May 2005 12:55:57 -0400 Subject: [Pythonmac-SIG] Tiger hand rolled Python 2.4.1: libxml2 oddities Message-ID: Using Python 2.4.1 compiled on Tiger. This symptom did not occur on Panther. Running my app using one command makes an import of libxml2 succeed: all test pass, including a lot of code that relies on libxml2. Running it with another command makes it fail: *** ImportError: Failure linking new module: /Users/gary/jic/opt/ libxml2/lib/python/libxml2mod.so: Symbol not found: _xmlTextReaderByteConsumed Referenced from: /Users/gary/jic/opt/libxml2/lib/python/libxml2mod.so Expected in: flat namespace I've put a pdb before the import to examine the two environments. I've checked sys.path, os.environ, and sys.getdlopenflags() (recommended by a coworker) and gotten results that were either identical or that (in the case of sys.path) I munged until they were identical, and still one import works, the other doesn't. Can anyone think of something else in the two python contexts to compare? Gary From gary at modernsongs.com Thu May 5 19:01:24 2005 From: gary at modernsongs.com (Gary Poster) Date: Thu, 5 May 2005 13:01:24 -0400 Subject: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger In-Reply-To: References: <1573D6A3-B897-4DE8-BF89-491531C0D11A@modernsongs.com> <88514040-1875-4505-97C4-8A88184C4DAC@redivi.com> <57AF2958-A429-4D0A-A057-9D2DC3F43A03@redivi.com> <4A238DC7-5FE1-4D97-98D5-EEB62F3989AB@modernsongs.com> Message-ID: <99628471-B684-4C41-862E-A43C724E8D62@modernsongs.com> On May 4, 2005, at 7:30 PM, Bob Ippolito wrote: > On May 4, 2005, at 7:15 PM, Gary Poster wrote: >> On May 4, 2005, at 3:29 PM, Bob Ippolito wrote: >>> I'm not really sure why you're trying not to build a framework >>> Python in the first place, there's no particularly good reason why >>> you'd want a non-framework Python around. >> I'm a Zope developer. I often have multiple Pythons around, one (or >> sometimes more) for each large project. Framework builds help >> nothing for Zope, and friends have scared me off from using them >> except to replace the main Apple Python (which I just did sucessfully >> with your MacPython and TigerPython24Fix--thanks!). Maybe that's >> misplaced fear, but working among developers on other platforms, its >> (mildly) convenient if our buildouts all use the same buildout dance. > > Well, you don't build your own on Windows, do you? Yes, we do (see below). > I don't see why you should have to build one on your Mac either. > Framework builds are almost entirely self-contained (except for > the /usr/local/bin symlinks), similar to a typical Windows install. > > In other words, why should you need to build Python 2.4.1 when > there is already one built and available? I could understand if > you were working off of some modified Python or off CVS HEAD or > something.. but it seems like you're spending more time than you > should have to. We need to be able to develop on/support multiple pieces of software, running on multiple versions of Python, with different packages possibly in their own multiple versions. We also don't want to make a developer munge their system Python with requirements for a given buildout. For simpler cases, I agree with you. > As far as friends scaring you off.. I dunno, maybe they didn't know > what they were doing when they tried it, or they were bitten by > some problem that has been solved long since. The only > "incompatibility" with framework builds is that stupid extensions > that don't use distutils in their build procedure aren't going to > work out of the box, but they're probably not going to work out of > the box anyway because Mac OS X's linker takes different options. I wonder if this is what is biting me now (other post about libxml2). The odd thing is that it works when started one way (to run the tests) but not the other (to run the app). ...Not a good sign for our test runner either, I suppose. Gary From bob at redivi.com Thu May 5 20:20:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 5 May 2005 14:20:44 -0400 Subject: [Pythonmac-SIG] Tiger hand rolled Python 2.4.1: libxml2 oddities In-Reply-To: References: Message-ID: <150C767A-B31A-4799-91F0-96D2853F5714@redivi.com> On May 5, 2005, at 12:55 PM, Gary Poster wrote: > Using Python 2.4.1 compiled on Tiger. This symptom did not occur on > Panther. > > Running my app using one command makes an import of libxml2 succeed: > all test pass, including a lot of code that relies on libxml2. > > Running it with another command makes it fail: > > *** ImportError: Failure linking new module: /Users/gary/jic/opt/ > libxml2/lib/python/libxml2mod.so: Symbol not found: > _xmlTextReaderByteConsumed > Referenced from: /Users/gary/jic/opt/libxml2/lib/python/ > libxml2mod.so > Expected in: flat namespace > > I've put a pdb before the import to examine the two environments. > I've checked sys.path, os.environ, and sys.getdlopenflags() > (recommended by a coworker) and gotten results that were either > identical or that (in the case of sys.path) I munged until they were > identical, and still one import works, the other doesn't. It sounds like libxml2 (or the Python extension) uses the linker option flat_namespace .. that's bad. -flat_namespace has been deprecated since 10.2 (maybe earlier) and shouldn't be used for anything. I can't help you though, I don't use libxml2 so I don't know the specifics of why its build/link procedure is broken. -bob From bob at redivi.com Thu May 5 20:31:21 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 5 May 2005 14:31:21 -0400 Subject: [Pythonmac-SIG] Tiger hand rolled Python 2.4.1: libxml2 oddities In-Reply-To: <150C767A-B31A-4799-91F0-96D2853F5714@redivi.com> References: <150C767A-B31A-4799-91F0-96D2853F5714@redivi.com> Message-ID: <835F5CC2-3D0E-4549-9E0D-4440953B09F9@redivi.com> On May 5, 2005, at 2:20 PM, Bob Ippolito wrote: > > On May 5, 2005, at 12:55 PM, Gary Poster wrote: > > >> Using Python 2.4.1 compiled on Tiger. This symptom did not occur on >> Panther. >> >> Running my app using one command makes an import of libxml2 succeed: >> all test pass, including a lot of code that relies on libxml2. >> >> Running it with another command makes it fail: >> >> *** ImportError: Failure linking new module: /Users/gary/jic/opt/ >> libxml2/lib/python/libxml2mod.so: Symbol not found: >> _xmlTextReaderByteConsumed >> Referenced from: /Users/gary/jic/opt/libxml2/lib/python/ >> libxml2mod.so >> Expected in: flat namespace >> >> I've put a pdb before the import to examine the two environments. >> I've checked sys.path, os.environ, and sys.getdlopenflags() >> (recommended by a coworker) and gotten results that were either >> identical or that (in the case of sys.path) I munged until they were >> identical, and still one import works, the other doesn't. >> > > It sounds like libxml2 (or the Python extension) uses the linker > option flat_namespace .. that's bad. -flat_namespace has been > deprecated since 10.2 (maybe earlier) and shouldn't be used for > anything. I can't help you though, I don't use libxml2 so I don't > know the specifics of why its build/link procedure is broken. More specifically, after looking again, "libxml2mod.so" isn't explicitly linking to libxml2 (and may also be using the deprecated - flat_namespace).. Somewhere in your "one command" it's importing something that does explicitly link to libxml2, but your "another command" does not have that side-effect that band-aids the fact that "libxml2mod.so" is linked incorrectly. The solution to this specific problem is to fix whatever builds "libxml2mod.so" so that it links against libxml2 (-lxml2, or adding it to the distutils library list, etc.).. but I have a feeling that's not the ONLY thing wrong with it. It "smells" like one of those horribly broken Python extensions that uses autoconf instead of distutils. -bob From gary at modernsongs.com Thu May 5 22:31:02 2005 From: gary at modernsongs.com (Gary Poster) Date: Thu, 5 May 2005 16:31:02 -0400 Subject: [Pythonmac-SIG] Tiger hand rolled Python 2.4.1: libxml2 oddities In-Reply-To: <835F5CC2-3D0E-4549-9E0D-4440953B09F9@redivi.com> References: <150C767A-B31A-4799-91F0-96D2853F5714@redivi.com> <835F5CC2-3D0E-4549-9E0D-4440953B09F9@redivi.com> Message-ID: On May 5, 2005, at 2:31 PM, Bob Ippolito wrote: > > On May 5, 2005, at 2:20 PM, Bob Ippolito wrote: >> It sounds like libxml2 (or the Python extension) uses the linker >> option flat_namespace .. that's bad. -flat_namespace has been >> deprecated since 10.2 (maybe earlier) and shouldn't be used for >> anything. I can't help you though, I don't use libxml2 so I don't >> know the specifics of why its build/link procedure is broken. >> > > More specifically, after looking again, "libxml2mod.so" isn't > explicitly linking to libxml2 (and may also be using the deprecated > -flat_namespace).. Somewhere in your "one command" it's importing > something that does explicitly link to libxml2, but your "another > command" does not have that side-effect that band-aids the fact > that "libxml2mod.so" is linked incorrectly. The solution to this > specific problem is to fix whatever builds "libxml2mod.so" so that > it links against libxml2 (-lxml2, or adding it to the distutils > library list, etc.).. but I have a feeling that's not the ONLY > thing wrong with it. > > It "smells" like one of those horribly broken Python extensions > that uses autoconf instead of distutils. Your analysis seems to have been dead on for all counts. I have a workaround for now--import a 'good' libxml2 before whatever offending badly linked version comes into the sys.modules--and I really need to actually get some work done. I'll dig into it a bit more when I can and report back if I find anything useful. Thank you! Gary From fclee at highstream.net Thu May 5 23:28:11 2005 From: fclee at highstream.net (Frederick C. Lee) Date: Thu, 5 May 2005 14:28:11 -0700 Subject: [Pythonmac-SIG] How can XCode find Python.h? Message-ID: <3FBADFBE-05E6-42FF-A9DB-D993E8C62350@highstream.net> I'm following an c-module example in 'Programming Python'. The C code depends on 'Python.h'. The first thing I did was use Spotlight to find where 'Python.h' is. I found it: /Developer/SDKs/MacOSX10.4.0.sdk/..../include/python2.3/ Python.h <-- def as PYHEADERS env variable in .login. So I set the 'Header Search Paths' under 'Search Paths' in XCode via $PYHEADERS env variable that I had set in my .login file. But this has no effect within XCode Build. Any ideas? Ric. #include <--- where? "No such file or directory." #include // Modle Functions static PyObject * // returns object. message(PyObject *self, PyObject *args) { // 'self' unused in modules. 'args' from python call. char *fromPython, result[64]; if (!PyArg_Parse(args,"(s)",&fromPython)) return NULL; else { strcpy(result,"Hello, "); // build up C string. strcat(result, fromPython); // add passed Python-string. return Py_BuildValue("s",result); // convert C --> Python. } } // end message() ... etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050505/ad0e8dc9/attachment-0001.html From bob at redivi.com Thu May 5 23:45:02 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 5 May 2005 17:45:02 -0400 Subject: [Pythonmac-SIG] How can XCode find Python.h? In-Reply-To: <3FBADFBE-05E6-42FF-A9DB-D993E8C62350@highstream.net> References: <3FBADFBE-05E6-42FF-A9DB-D993E8C62350@highstream.net> Message-ID: <3259F191-295C-49E3-B8EA-39CC8D8F3C6F@redivi.com> On May 5, 2005, at 5:28 PM, Frederick C. Lee wrote: > I'm following an c-module example in 'Programming Python'. > > The C code depends on 'Python.h'. > > The first thing I did was use Spotlight to find where 'Python.h' is. > I found it: /Developer/SDKs/MacOSX10.4.0.sdk/..../include/ > python2.3/Python.h <-- def as PYHEADERS env variable in .login. > > So I set the 'Header Search Paths' under 'Search Paths' in XCode > via $PYHEADERS env variable that I had set in my .login file. > But this has no effect within XCode Build. It looks like you're trying to develop an extension module. You want to use distutils to build these, not Xcode. If you use Xcode, you will do it wrong. #include is *NEVER* correct, it should always be #include "Python.h", with the appropriate include directory added to the search path. The options required for linking to Python are always available from distutils: >>> import disuttils >>> import pprint >>> pprint.pprint(distutils.sysconfig.get_config_vars()) {.... a very very large dict full of crap from the makefile...} However, using Xcode to build+link extensions is NOT the right way to do it, even if you can deduce the right flags to use by looking at these config vars. If you are *embedding* Python on Mac OS X you probably should consider just writing a PyObjC based plugin that encapsulates what you need Python to do, and then just call into that from your Objective-C application. If you try and embed Python manually you'll probably get it wrong, and PyObjC saves you from having to deal with any of the Python C API. -bob From charles.hartman at conncoll.edu Thu May 5 19:59:37 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 5 May 2005 13:59:37 -0400 Subject: [Pythonmac-SIG] jython alive Message-ID: I know this isn't the list for it -- as far as I can tell there _isn't_ a list for it. Does anyone know if Jython is alive? Progressing? The current version seems to be four years old and corresponds to Python 2.1. If I set out to do some projects in it (because I need to talk to a special set of libraries in Java) would I be riding an endangered horse? Or do I need -- shudder -- to learn Java? Charles Hartman From bob at redivi.com Fri May 6 01:06:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 5 May 2005 19:06:03 -0400 Subject: [Pythonmac-SIG] jython alive In-Reply-To: References: Message-ID: <6025F0F8-DD39-4148-BECA-46DB0CD2A7C7@redivi.com> On May 5, 2005, at 1:59 PM, Charles Hartman wrote: > I know this isn't the list for it -- as far as I can tell there > _isn't_ a list for it. Does anyone know if Jython is alive? > Progressing? The current version seems to be four years old and > corresponds to Python 2.1. If I set out to do some projects in it > (because I need to talk to a special set of libraries in Java) would > I be riding an endangered horse? Or do I need -- shudder -- to learn > Java? Jython is alive, and there are several lists for it . These lists are pretty clearly linked to from the Resources section of the navigation on Jython.org. -bob From sw at wordtech-software.com Fri May 6 07:03:05 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri, 06 May 2005 01:03:05 -0400 Subject: [Pythonmac-SIG] Updated packages for Tiger Message-ID: <427AFA89.3080602@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have updated PyQt-Mac, SPE-OSX, and PyUnitOSX for compatability with Mac OSX 10.4 "Tiger." Please see http://www.wordtech-software.com for more information. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCevqJJmdQs+6YVcoRAqTgAJ9+2+bcrbuuyipTOvjFP+VUHJdhFgCeNRvY w0ukYwo74Neby9Rl66+2naE= =lM1n -----END PGP SIGNATURE----- From wolfgang.keller.nospam at gmx.de Fri May 6 15:37:11 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Fri, 6 May 2005 15:37:11 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <2m8y2uy8zz.fsf@starship.python.net> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> <128971055.20050504231027@gmx.de> <2m8y2uy8zz.fsf@starship.python.net> Message-ID: <311691392.20050506153711@gmx.de> Hello, > does "every" system possessing a driver for such a file system use > the getxattr &c functions to access these features? There is a Posix standard API for extended attributes. And afaik all Linuxes and even Windows are implementing this standard. As for Apple, no clue. The ACLs in MacOS X are Posix however, afaik. Best regards, Wolfgang Keller -- P.S.: My From-address is correct From ronaldoussoren at mac.com Fri May 6 17:06:47 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 6 May 2005 17:06:47 +0200 Subject: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python? In-Reply-To: <311691392.20050506153711@gmx.de> References: <1458939782.20050503170947@gmx.de> <106945803.20050504123820@gmx.de> <2m8y2vyy0o.fsf@starship.python.net> <59d991c40505040554911a73@mail.gmail.com> <128971055.20050504231027@gmx.de> <2m8y2uy8zz.fsf@starship.python.net> <311691392.20050506153711@gmx.de> Message-ID: On 6-mei-2005, at 15:37, Wolfgang Keller wrote: > Hello, > > >> does "every" system possessing a driver for such a file system use >> the getxattr &c functions to access these features? >> > > There is a Posix standard API for extended attributes. And afaik all > Linuxes and even Windows are implementing this standard. As for > Apple, no clue. Are you sure? ... ah, i see: Apple has added some additinal arguments to the Posix functions. That's lame, why couldn't they invent new names for their extension? Ronald From delza at livingcode.org Fri May 6 17:49:58 2005 From: delza at livingcode.org (Dethe Elza) Date: Fri, 6 May 2005 08:49:58 -0700 Subject: [Pythonmac-SIG] AddressBook wrapper In-Reply-To: References: <4C63BFC6-B755-4BA4-A1D5-9A734115D5BA@livingcode.org> Message-ID: <0552C280-9144-4CFA-895E-6615CA4122A7@livingcode.org> You rock. Thanks! --Dethe On 5-May-05, at 4:26 AM, Ronald Oussoren wrote: > > On 4-mei-2005, at 22:03, Dethe Elza wrote: > > >> The AddressBook wrapper doesn't appear to expose the constants >> kABShowAsPerson (0), kABShowAsCompany (1), or kABShowAsMask (7). >> > > It does now (PyObjC repository, revision 1609) > > Ronald > > values of ? will give rise to dom --Unix prehistory From gandreas at gandreas.com Fri May 6 21:17:13 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Fri, 6 May 2005 14:17:13 -0500 Subject: [Pythonmac-SIG] [PyOXIDE] Drop support for 10.2? Message-ID: <4e08a7524ba6694a93f5f0137a7fd844@gandreas.com> So given that 10.4 is currently available, I'm considering dropping support for 10.2 from future versions of PyOXIDE. I'm aware that there is at least one user still on 10.2, not sure about others. Given that I can't easily test 10.2 (short of hooking up a firewire drive to a spare machine), I know that there are 10.2 problems that exist in the current codebase (and more could happen). It seems like there is a movement to only support the latest & greatest (even if it requires users to download a newer version of Python than is on their brand new OS), but I'm trying to resist this temptation at least a little. So any comments/suggestion on the following: Require 10.3 (and Python 2.3 that came with 10.3) Support 10.4 (with both the stock Python and whatever is currently "supported") Require PyObj 1.3 Require py2app 0.1.9 Remove support for bundlebuilder Note that PyOXIDE is built using the framework python, so the embedded interpreter (which is what runs the scripts that make up PyOXIDE) will be whatever /System/Library/Frameworks/Python is (but you can specify any python interpreter for external execution). Glenn Andreas????????????????????? gandreas at gandreas.com? oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From bob at redivi.com Fri May 6 21:37:47 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 6 May 2005 15:37:47 -0400 Subject: [Pythonmac-SIG] [PyOXIDE] Drop support for 10.2? In-Reply-To: <4e08a7524ba6694a93f5f0137a7fd844@gandreas.com> References: <4e08a7524ba6694a93f5f0137a7fd844@gandreas.com> Message-ID: <4CABE46E-1256-4D92-A878-0B332F78B58B@redivi.com> On May 6, 2005, at 3:17 PM, gandreas at gandreas.com wrote: > So given that 10.4 is currently available, I'm considering dropping > support for 10.2 from future versions of PyOXIDE. I'm aware that > there > is at least one user still on 10.2, not sure about others. Given that > I can't easily test 10.2 (short of hooking up a firewire drive to a > spare machine), I know that there are 10.2 problems that exist in the > current codebase (and more could happen). It seems like there is a > movement to only support the latest & greatest (even if it requires > users to download a newer version of Python than is on their brand new > OS), but I'm trying to resist this temptation at least a little. So > any comments/suggestion on the following: > > Require 10.3 (and Python 2.3 that came with 10.3) > Support 10.4 (with both the stock Python and whatever is currently > "supported") > Require PyObj 1.3 > Require py2app 0.1.9 > Remove support for bundlebuilder > > Note that PyOXIDE is built using the framework python, so the embedded > interpreter (which is what runs the scripts that make up PyOXIDE) will > be whatever /System/Library/Frameworks/Python is (but you can specify > any python interpreter for external execution). All of this sounds perfectly good to me. You should probably drop the embedded interpreter (as far as the user can see) entirely, except maybe as an "advanced" feature (i.e. Safari's debug menu) and an implementation detail. -bob From scott_bulkmail at prefab.com Fri May 6 22:12:33 2005 From: scott_bulkmail at prefab.com (Scott Lawton) Date: Fri, 6 May 2005 16:12:33 -0400 Subject: [Pythonmac-SIG] [PyOXIDE] Drop support for 10.2? In-Reply-To: <4e08a7524ba6694a93f5f0137a7fd844@gandreas.com> References: <4e08a7524ba6694a93f5f0137a7fd844@gandreas.com> Message-ID: > Require 10.3 (and Python 2.3 that came with 10.3) > Support 10.4 (with both the stock Python and whatever is currently >"supported") Speaking as someone who still has one machine running 10.2, I still agree that dropping 10.2 is reasonable. It's important to focus limited resources on the main targets. From qdecavel at nordnet.fr Fri May 6 22:45:57 2005 From: qdecavel at nordnet.fr (Quentin DECAVEL) Date: Fri, 6 May 2005 21:45:57 +0100 Subject: [Pythonmac-SIG] Problem with a py2app bundle Message-ID: <20050506204557.M13191@nordnet.fr> Hi, I've tried py2app to create a bundle of the application I'm working on right now. I had no problem during the creation, and the bundle loads fine, but each time I try to quit, I get the same nasty quit and the pop-up from the system to tell me that the application unexpectedly quit. Here is the log that I receive (Greenhouse.creash.log in ~Library/Logs): Host Name: Date/Time: 2005-05-06 22:16:26 +0200 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: Greenhouse Path: ./dist/Greenhouse.app/Contents/MacOS/Greenhouse Version: 0.0 (0.0) PID: 1209 Thread: Unknown Link (dyld) error: dyld: ./dist/Greenhouse.app/Contents/MacOS/Greenhouse NSLookupSymbolInImage() dynamic library: /System/Library/Frameworks/Python.framework/Versions/2.3/Python does not define symbol: _Py_DecRef I tried to launch the app directly with the command line (./dist/Greenhouse.app/Contents/MacOS/Greenhouse) and I could trace the problem a little better: test test2 test3 objc: FREED(id): message release sent to freed object=0x1a588a0 Trace/BPT trap Since "test" happens before the end of the pygame loop and "test3" after the application main loop, I assume that pygame is not at fault, but then the test3 is really the last instruction to be evaluated in the main application file, so I really don't see how this "double free" could happen. Does anybody have an idea on how to solve the problem ? I understand that the logs do not tell much, so if you know some other outputs that I haven't already used, please tell me. Thanks in advance From bob at redivi.com Sat May 7 00:21:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 6 May 2005 18:21:46 -0400 Subject: [Pythonmac-SIG] Problem with a py2app bundle In-Reply-To: <20050506204557.M13191@nordnet.fr> References: <20050506204557.M13191@nordnet.fr> Message-ID: <9B55DED5-697A-4A28-A133-12BE642E3414@redivi.com> On May 6, 2005, at 4:45 PM, Quentin DECAVEL wrote: > I've tried py2app to create a bundle of the application I'm working > on right > now. I had no problem during the creation, and the bundle loads > fine, but each > time I try to quit, I get the same nasty quit and the pop-up from > the system > to tell me that the application unexpectedly quit. > Here is the log that I receive (Greenhouse.creash.log in ~Library/ > Logs): You're going to need to say what version of py2app and pygame you're using. -bob From niko at alum.mit.edu Sat May 7 00:31:17 2005 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 7 May 2005 00:31:17 +0200 Subject: [Pythonmac-SIG] "Trashing" a file Message-ID: <776371c0686cea35e19bfd050913d811@alum.mit.edu> Dear Mailing List, I am working on a python program that needs to trash some files. Ideally, I would like it to move them to the Trash, but I'm not quite sure what the best way to do this is. For context, I am using appscript to talk to iTunes and load its list of songs. This works great. Among other things, the program can then find albums that have multiple copies of the same track and purge them. iTunes gives me back an FSAlias object as the location of the track, which appears to come from the much maligned Carbon standard module. I have tried deleting the file by doing: appscript.app ('Finder').delete (aliasobject) This actually does work --- the Finder makes a little trashing noise, and the file ends up in the trash --- but it also throws an exception, which makes me mildly uncomfortable. Here is the actual output: > ;pythonw test.py > Traceback (most recent call last): > File "test.py", line 11, in ? > app ('finder').delete (tr.location.get()) > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/appscript/specifier.py", line 168, in __call__ > raise CommandError("Can't do command %r(%s)" % (self, args and > kargs and args + ', ' + kargs or args or kargs), err, trace) > appscript.specifier.CommandError: Can't do command > app(u'/System/Library/CoreServices/ > Finder.app').delete([, > ]), Error 0: The operation could > not be completed. > ; I mean, I could just catch and ignore this exception, but that seems bad. Any suggestions on what the Right Thing To Do is? Incidentally, are there searchable archives for this list? I couldn't seem to find any, just the month-by-month browsable ones... thanks, Niko From bob at redivi.com Sat May 7 01:00:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 6 May 2005 19:00:16 -0400 Subject: [Pythonmac-SIG] "Trashing" a file In-Reply-To: <776371c0686cea35e19bfd050913d811@alum.mit.edu> References: <776371c0686cea35e19bfd050913d811@alum.mit.edu> Message-ID: <0D157C85-DB7D-489E-8F5D-3E7D7F04C8CC@redivi.com> On May 6, 2005, at 6:31 PM, Niko Matsakis wrote: > I am working on a python program that needs to trash some files. > Ideally, I would like it to move them to the Trash, but I'm not quite > sure what the best way to do this is. > > For context, I am using appscript to talk to iTunes and load its list > of songs. This works great. Among other things, the program can then > find albums that have multiple copies of the same track and purge > them. > > iTunes gives me back an FSAlias object as the location of the track, > which appears to come from the much maligned Carbon standard module. > > I have tried deleting the file by doing: > > appscript.app ('Finder').delete (aliasobject) > > This actually does work --- the Finder makes a little trashing noise, > and the file ends up in the trash --- but it also throws an exception, > which makes me mildly uncomfortable. Here is the actual output: > > >> ;pythonw test.py >> Traceback (most recent call last): >> File "test.py", line 11, in ? >> app ('finder').delete (tr.location.get()) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/appscript/specifier.py", line 168, in >> __call__ >> raise CommandError("Can't do command %r(%s)" % (self, args and >> kargs and args + ', ' + kargs or args or kargs), err, trace) >> appscript.specifier.CommandError: Can't do command >> app(u'/System/Library/CoreServices/ >> Finder.app').delete([, >> ]), Error 0: The operation could >> not be completed. >> ; >> > > I mean, I could just catch and ignore this exception, but that seems > bad. Any suggestions on what the Right Thing To Do is? I don't like dealing with apple events very much because they tend to be slow and/or unreliable.. but this is the Cocoa way to do it (untested, but should probably work): from AppKit import * import sys import os def groupFiles(files): dirs = {} enc = sys.getfilesystemencoding() for fn in files: if not isinstance(fn, unicode): fn = unicode(fn, enc) fn = os.path.realpath(fn) dirname, basename = os.path.splitext(fn) try: dirs[dirname].append(basename) except KeyError: dirs[dirname] = [basename] return dirs def recycleFiles(files, ws=None): if ws is None: ws = NSWorkspace.sharedWorkspace() results = [] for dirname, files in groupFiles(files).iteritems(): res, tag = ws.performFileOperation_source_destination_files_tag_( NSWorkspaceRecycleOperation, dirname, u'', files) results.append((res, tag, dirname, files)) return results You would need to pass a sequence of paths to recycleFiles .. so you'd need to turn those FSAlias objects into POSIX paths (I don't remember how to do it off the top of my head). > Incidentally, are there searchable archives for this list? I couldn't > seem to find any, just the month-by-month browsable ones... I don't know.. but there's always Google. A query that ends with "pythonmac-sig site:mail.python.org" sans quotes is probably only going to turn up results from this list. -bob From erictexier at sbcglobal.net Sat May 7 07:15:26 2005 From: erictexier at sbcglobal.net (Eric Texier) Date: Fri, 06 May 2005 22:15:26 -0700 Subject: [Pythonmac-SIG] mac newbie... Tix . What is wrong? Message-ID: <427C4EEE.7020407@sbcglobal.net> Here is a simple example that works on linux, but not on MacOSX tigger. Thanks Eric > pythonw Python 2.4.1 (#2, Apr 27 2005, 22:11:31) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Tix >>> >>> def selectedFile(inFile): ... print inFile ... >>> root = Tix.Tk() >>> d = Tix.FileSelectDialog(root,command=selectedFile) Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk/Tix.py", line 815, in __init__ ['options'], cnf, kw) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk/Tix.py", line 307, in __init__ self.tk.call(widgetName, self._w, *extra) _tkinter.TclError: invalid command name "tix" Delete Reply Forward Spam Move... Previous | Next | Back to Messages From rkern at ucsd.edu Sat May 7 07:26:52 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 06 May 2005 22:26:52 -0700 Subject: [Pythonmac-SIG] mac newbie... Tix . What is wrong? In-Reply-To: <427C4EEE.7020407@sbcglobal.net> References: <427C4EEE.7020407@sbcglobal.net> Message-ID: <427C519C.6070106@ucsd.edu> Eric Texier wrote: > Here is a simple example that works on linux, but not on MacOSX > tigger. > Thanks > Eric > > >>pythonw > > Python 2.4.1 (#2, Apr 27 2005, 22:11:31) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin > Type "help", "copyright", "credits" or "license" for more > information. > >>>>import Tix >>>> >>>>def selectedFile(inFile): > > ... print inFile > ... > >>>>root = Tix.Tk() >>>>d = Tix.FileSelectDialog(root,command=selectedFile) > > Traceback (most recent call last): > File "", line 1, in ? > File > "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk/Tix.py", > line 815, in __init__ > ['options'], cnf, kw) > File > "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk/Tix.py", > line 307, in __init__ > self.tk.call(widgetName, self._w, *extra) > _tkinter.TclError: invalid command name "tix" You don't have the Tcl package Tix installed. The Tiger-provided TclTkAqua installation does not come with Tix. I'm not sure, but you can try installing the "Batteries Included" version of TclTkAqua from http://tcltkaqua.sourceforge.net -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From qdecavel at nordnet.fr Sat May 7 09:49:20 2005 From: qdecavel at nordnet.fr (Quentin DECAVEL) Date: Sat, 7 May 2005 08:49:20 +0100 Subject: [Pythonmac-SIG] Problem with a py2app bundle Message-ID: <20050507074920.M4460@nordnet.fr> The py2app version should be 0.1.8 or 0.1.9, pygame is 1.6 From niko at alum.mit.edu Sat May 7 10:00:23 2005 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 7 May 2005 10:00:23 +0200 Subject: [Pythonmac-SIG] "Trashing" a file In-Reply-To: <0D157C85-DB7D-489E-8F5D-3E7D7F04C8CC@redivi.com> References: <776371c0686cea35e19bfd050913d811@alum.mit.edu> <0D157C85-DB7D-489E-8F5D-3E7D7F04C8CC@redivi.com> Message-ID: <03a38b398e3cf231f72ae8bc3c820350@alum.mit.edu> Thanks; I'll give this a try. Converting an Alias to a path isn't too difficult, there's an example in one of the sample appscripts I believe. Niko On May 7, 2005, at 1:00 AM, Bob Ippolito wrote: > On May 6, 2005, at 6:31 PM, Niko Matsakis wrote: > >> I am working on a python program that needs to trash some files. >> Ideally, I would like it to move them to the Trash, but I'm not quite >> sure what the best way to do this is. >> >> For context, I am using appscript to talk to iTunes and load its list >> of songs. This works great. Among other things, the program can then >> find albums that have multiple copies of the same track and purge >> them. >> >> iTunes gives me back an FSAlias object as the location of the track, >> which appears to come from the much maligned Carbon standard module. >> >> I have tried deleting the file by doing: >> >> appscript.app ('Finder').delete (aliasobject) >> >> This actually does work --- the Finder makes a little trashing noise, >> and the file ends up in the trash --- but it also throws an exception, >> which makes me mildly uncomfortable. Here is the actual output: >> >> >>> ;pythonw test.py >>> Traceback (most recent call last): >>> File "test.py", line 11, in ? >>> app ('finder').delete (tr.location.get()) >>> File >>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>> python2.3/site-packages/appscript/specifier.py", line 168, in >>> __call__ >>> raise CommandError("Can't do command %r(%s)" % (self, args and >>> kargs and args + ', ' + kargs or args or kargs), err, trace) >>> appscript.specifier.CommandError: Can't do command >>> app(u'/System/Library/CoreServices/ >>> Finder.app').delete([, >>> ]), Error 0: The operation could >>> not be completed. >>> ; >>> >> >> I mean, I could just catch and ignore this exception, but that seems >> bad. Any suggestions on what the Right Thing To Do is? > > I don't like dealing with apple events very much because they tend to > be slow and/or unreliable.. but this is the Cocoa way to do it > (untested, but should probably work): > > from AppKit import * > import sys > import os > > def groupFiles(files): > dirs = {} > enc = sys.getfilesystemencoding() > for fn in files: > if not isinstance(fn, unicode): > fn = unicode(fn, enc) > fn = os.path.realpath(fn) > dirname, basename = os.path.splitext(fn) > try: > dirs[dirname].append(basename) > except KeyError: > dirs[dirname] = [basename] > return dirs > > def recycleFiles(files, ws=None): > if ws is None: > ws = NSWorkspace.sharedWorkspace() > results = [] > for dirname, files in groupFiles(files).iteritems(): > res, tag = > ws.performFileOperation_source_destination_files_tag_( > NSWorkspaceRecycleOperation, > dirname, > u'', > files) > results.append((res, tag, dirname, files)) > return results > > You would need to pass a sequence of paths to recycleFiles .. so you'd > need to turn those FSAlias objects into POSIX paths (I don't remember > how to do it off the top of my head). > >> Incidentally, are there searchable archives for this list? I couldn't >> seem to find any, just the month-by-month browsable ones... > > I don't know.. but there's always Google. A query that ends with > "pythonmac-sig site:mail.python.org" sans quotes is probably only > going to turn up results from this list. > > -bob > From surf at theflow.de Sat May 7 19:13:19 2005 From: surf at theflow.de (Florian Munz) Date: Sat, 7 May 2005 19:13:19 +0200 Subject: [Pythonmac-SIG] convert binary plist to xml string Message-ID: <1gw7h4h.fxxoe7162k3kuN%surf@theflow.de> Hello, since the format of plist files changed to binary by default on Tiger my little program, which works on xml plists doesn't work anymore. Is there a way to convert a binary plist to xml with Python or PyObjC? I know this on the command line: plutil -convert xml1 Bookmarks.plist but I'm searching a way to do this directly. NSMutableDictionary.dictionaryWithContentsOfFile_(file) doesn't help me in this case. thanks, Florian From njriley at uiuc.edu Sat May 7 19:51:50 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat, 7 May 2005 12:51:50 -0500 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <1gw7h4h.fxxoe7162k3kuN%surf@theflow.de> References: <1gw7h4h.fxxoe7162k3kuN%surf@theflow.de> Message-ID: <20050507175150.GA25530@uiuc.edu> On May 7, 2005, at 12:13 PM, Florian Munz wrote: > since the format of plist files changed to binary by default on > Tiger my little program, which works on xml plists doesn't work > anymore. > > Is there a way to convert a binary plist to xml with Python or PyObjC? > > I know this on the command line: > > plutil -convert xml1 Bookmarks.plist > > but I'm searching a way to do this directly. In [1]: from Foundation import * In [2]: import os In [3]: plist, format, error = NSPropertyListSerialization.propertyListFromData_mutabilityOption_format_errorDescription_(NSData.dataWithContentsOfMappedFile_(os.path.expanduser('~/Library/Preferences/com.apple.keychainsync.plist')), NSPropertyListImmutable, 0) In [4]: plist Out[4]: {KeychainSyncList = (); } In [5]: data, error = NSPropertyListSerialization.dataFromPropertyList_format_errorDescription_(plist, NSPropertyListXMLFormat_v1_0) In [6]: data.writeToFile_atomically_('foo.plist', False) Out[6]: 1 In [7]: print file('foo.plist').read() KeychainSyncList -- Nicholas Riley | 4111 Siebel Center Department of Computer Science | 201 N. Goodwin Ave. and Medical Scholars Program | Urbana, IL 61801-2302 Univ. of Illinois at Urbana-Champaign | +1 217 244 2274 From chris_py006 at psychofx.com Sat May 7 22:57:46 2005 From: chris_py006 at psychofx.com (Chris Miles) Date: Sat, 7 May 2005 21:57:46 +0100 Subject: [Pythonmac-SIG] CD/DVD mount point info Message-ID: What is the best method to determine the current mount point of a CD/ DVD on OS X with Python? Also, if possible, to get information about the disc (size, format, etc) ? Is there an equivalent of os.statvfs() ? Cheers, Chris -- Chris Miles http://chrismiles.info/ From bob at redivi.com Sun May 8 00:13:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 7 May 2005 18:13:52 -0400 Subject: [Pythonmac-SIG] Problem with a py2app bundle In-Reply-To: <20050507074920.M4460@nordnet.fr> References: <20050507074920.M4460@nordnet.fr> Message-ID: <9C1EB475-F440-47E7-B991-82BC011D3625@redivi.com> On May 7, 2005, at 3:49 AM, Quentin DECAVEL wrote: > The py2app version should be 0.1.8 or 0.1.9, pygame is 1.6 Try again with py2app 0.1.9 and pygame 1.7. Installers for both are available at: http://pythonmac.org/packages/ -bob From qdecavel at nordnet.fr Sun May 8 09:45:04 2005 From: qdecavel at nordnet.fr (Quentin DECAVEL) Date: Sun, 8 May 2005 08:45:04 +0100 Subject: [Pythonmac-SIG] Problem with a py2app bundle Message-ID: <20050508074504.M12785@nordnet.fr> Okay I've installed py2app and pygame, plus pyObjC, MacPython 2.4 and the some packages versions that were available on the site (the app complained that it could not find the PyObjC module), and launched a new bundle creation, but this time the application crashed much sooner, and the only trace that I received was no the Console: 2005-05-08 09:35:00.710 Greenhouse[1838] Greenhouse Error 2005-05-08 09:35:00.711 Greenhouse[1838] An unexpected error has occurred during execution of the main script ImportError: No module named rotor See the Console for a detailed traceback. This time no log specific of the app was available to get additional information... From bob at redivi.com Sun May 8 19:41:17 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 8 May 2005 13:41:17 -0400 Subject: [Pythonmac-SIG] Problem with a py2app bundle In-Reply-To: <20050508074504.M12785@nordnet.fr> References: <20050508074504.M12785@nordnet.fr> Message-ID: On May 8, 2005, at 3:45 AM, Quentin DECAVEL wrote: > Okay I've installed py2app and pygame, plus pyObjC, MacPython 2.4 > and the some > packages versions that were available on the site (the app > complained that it > could not find the PyObjC module), and launched a new bundle > creation, but > this time the application crashed much sooner, and the only trace > that I > received was no the Console: pygame requires PyObjC on Mac OS X > 2005-05-08 09:35:00.710 Greenhouse[1838] Greenhouse Error > > 2005-05-08 09:35:00.711 Greenhouse[1838] An unexpected error has > occurred > during execution of the main script > > ImportError: No module named rotor > > See the Console for a detailed traceback. rotor was an insecure encryption module that was deprecated in Python 2.3 (maybe earlier) and removed in Python 2.4. You'll have to figure out where/why your application is using it and make sure it doesn't, or build with python 2.3. -bob From qdecavel at nordnet.fr Sun May 8 23:45:43 2005 From: qdecavel at nordnet.fr (Quentin DECAVEL) Date: Sun, 8 May 2005 22:45:43 +0100 Subject: [Pythonmac-SIG] Problem with a py2app bundle Message-ID: <20050508214543.M34405@nordnet.fr> Well thanks for all your tips Bob, the app nows quits nicely. All I need to do now is to find a replacement for rotor... Another question: I have used python2.4 to create the bundle, which only works with OS X.3. I have understood that bundles created on OS X.3 may not work on previous versions of OS X due to the differences between python versions on the OSes. Have I understood badly, or will I have to compile python2.4 on my OS X.2 so that I can make a bundle working on all OSes ? Thanks in advance From bob at redivi.com Mon May 9 00:04:47 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 8 May 2005 18:04:47 -0400 Subject: [Pythonmac-SIG] Problem with a py2app bundle In-Reply-To: <20050508214543.M34405@nordnet.fr> References: <20050508214543.M34405@nordnet.fr> Message-ID: <1E2F3B6E-4FC6-4FC6-9081-9B2D35276843@redivi.com> On May 8, 2005, at 5:45 PM, Quentin DECAVEL wrote: > Well thanks for all your tips Bob, the app nows quits nicely. All I > need to do > now is to find a replacement for rotor... The standard library has no encryption, so you'll have to look elsewhere (i.e. PyCrypto). > Another question: I have used python2.4 to create the bundle, which > only works > with OS X.3. I have understood that bundles created on OS X.3 may > not work on > previous versions of OS X due to the differences between python > versions on > the OSes. Have I understood badly, or will I have to compile > python2.4 on my > OS X.2 so that I can make a bundle working on all OSes ? > Python 2.4 isn't really supported on Mac OS X 10.2. You'll have to compile it yourself if you want to use it there. There is a build of MacPython 2.3.5 for Mac OS X 10.2 at . -bob From surf at theflow.de Mon May 9 00:40:59 2005 From: surf at theflow.de (Florian Munz) Date: Mon, 9 May 2005 00:40:59 +0200 Subject: [Pythonmac-SIG] convert binary plist to xml string References: <1gw7h4h.fxxoe7162k3kuN%surf@theflow.de> <20050507175150.GA25530@uiuc.edu> Message-ID: <1gw9r2k.1avfudj1ufqgz7N%surf@theflow.de> Nicholas Riley wrote: > In [3]: plist, format, error = >NSPropertyListSerialization.propertyListFromData_mutabilityOption_forma >t_errorDescription_(NSData.dataWithContentsOfMappedFile_(os.path.expand >user('~/Library/Preferences/com.apple.keychainsync.plist')), >NSPropertyListImmutable, 0) > > In [4]: plist Out[4]: {KeychainSyncList = (); } > > In [5]: data, error = > NSPropertyListSerialization.dataFromPropertyList_format_errorDescription_( > plist, NSPropertyListXMLFormat_v1_0) > > [...] thanks, that works exactly the way I need it. I found out you can get the string faster if you convert the NSData right away: s = NSString.alloc().initWithData_encoding_(data, NSUTF8StringEncoding) Florian From bob at redivi.com Mon May 9 01:10:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 8 May 2005 19:10:37 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <1gw9r2k.1avfudj1ufqgz7N%surf@theflow.de> References: <1gw7h4h.fxxoe7162k3kuN%surf@theflow.de> <20050507175150.GA25530@uiuc.edu> <1gw9r2k.1avfudj1ufqgz7N%surf@theflow.de> Message-ID: On May 8, 2005, at 6:40 PM, Florian Munz wrote: > Nicholas Riley wrote: > > >> In [3]: plist, format, error = >> NSPropertyListSerialization.propertyListFromData_mutabilityOption_for >> ma >> t_errorDescription_(NSData.dataWithContentsOfMappedFile_ >> (os.path.expand >> user('~/Library/Preferences/com.apple.keychainsync.plist')), >> NSPropertyListImmutable, 0) >> >> In [4]: plist Out[4]: {KeychainSyncList = (); } >> >> In [5]: data, error = >> NSPropertyListSerialization.dataFromPropertyList_format_errorDescript >> ion_( >> plist, NSPropertyListXMLFormat_v1_0) >> >> [...] >> > > thanks, that works exactly the way I need it. I found out you can get > the string faster if you convert the NSData right away: > > s = NSString.alloc().initWithData_encoding_(data, > NSUTF8StringEncoding) There's plenty of other ways to say that.. In 1.3 you should be able to do this: s = unicode(buffer(data), 'utf-8') Or before you could do: s = unicode(data.bytes(), 'utf-8') -bob From hengist.podd at virgin.net Mon May 9 12:29:58 2005 From: hengist.podd at virgin.net (has) Date: Mon, 9 May 2005 11:29:58 +0100 Subject: [Pythonmac-SIG] [PyOXIDE] Drop support for 10.2? Message-ID: Glenn Andreas wrote: > So given that 10.4 is currently available, I'm considering dropping support for 10.2 from future versions of PyOXIDE. Sounds fine to me. Most folk will be on 10.3/10.4 now so focus your resources where it'll do most good, in this case getting PyOXIDE to a polished, stable 1.0 state. It's reasonable to expect something mature and irreplaceable like Python.framework provide compatibility across several OS versions, but a plain text editor and shell scripts can always stand in for an IDE if push comes to shove. I think if you can manage to support one major OS/Python version behind the current release while still in development then you're doing pretty well. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From konrad.hinsen at laposte.net Mon May 9 16:57:01 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon, 9 May 2005 16:57:01 +0200 Subject: [Pythonmac-SIG] (no subject) Message-ID: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> On 5/4/05, Bob Ippolito wrote: > > will only add Python packages (as it does with distutils in general). > > ext_modules is not what I want either, the modules are already built > > and installed, I just want them to be included. > > > > Is there some other approach that I could try? > > Modify sys.path in your setup script. > Thanks, that does it! For the modules at least... because one module also depends on a dynamic library from /usr/local/lib that is not included. I don't know if it is supposed to be. Would it be sufficient to copy it to "Resources"? Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From bob at redivi.com Mon May 9 17:05:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 9 May 2005 11:05:37 -0400 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> Message-ID: On May 9, 2005, at 10:57 AM, konrad.hinsen at laposte.net wrote: > On 5/4/05, Bob Ippolito wrote: > > >>> will only add Python packages (as it does with distutils in >>> general). >>> ext_modules is not what I want either, the modules are already built >>> and installed, I just want them to be included. >>> >>> Is there some other approach that I could try? >>> >> >> Modify sys.path in your setup script. >> >> > Thanks, that does it! For the modules at least... because one module > also depends on a dynamic library from /usr/local/lib that is not > included. I don't know if it is supposed to be. It should be, are you sure it's not? If the module links to the dylib, it will get picked up.. unless it's happening dynamically at runtime (a la ctypes). You might try setting os.environ ['DYLD_FALLBACK_LIBRARY_PATH'] = '/usr/local/lib' in your setup script, which might help if the module isn't linked correctly. > Would it be sufficient to copy it to "Resources"? No. Libraries and frameworks need to live in the frameworks dir and they need their Mach-O headers rewritten. The frameworks option might work... but it really should get picked up automatically. If it does not get picked up automatically there's something wrong with the extension or py2app.. but I doubt it's py2app's fault. -bob From konrad.hinsen at laposte.net Mon May 9 17:22:36 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon, 9 May 2005 17:22:36 +0200 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> Message-ID: <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> On May 9, 2005, at 17:05, Bob Ippolito wrote: > It should be, are you sure it's not? If the module links to the > dylib, it will get picked Ahh... I found it. It's in "Frameworks", where I wouldn't have expected it, considering that it's not from any framework. But if that's what works, I don't mind :-) The reason my application didn't work was a different one: it picked up inappropriate modules from PYTHONPATH. I fixed this by setting sys.path explicitly in __boot__.py, but I wonder if it wouldn't be a good idea in general to make packaged Python applications ignore PYTHONPATH altogether (by setting it to something empty in the startup stub). I have some good reasons to use PYTHONPATH in my setup, and I know how to handle it, but I don't expect double-clickable applications (about which I normally don't even need to know that they were written in Python) to be affected by it. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From bob at redivi.com Mon May 9 17:45:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 9 May 2005 11:45:20 -0400 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> Message-ID: <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> On May 9, 2005, at 11:22 AM, konrad.hinsen at laposte.net wrote: > On May 9, 2005, at 17:05, Bob Ippolito wrote: > > >> It should be, are you sure it's not? If the module links to the >> dylib, it will get picked >> > > Ahh... I found it. It's in "Frameworks", where I wouldn't have > expected it, considering that it's not from any framework. But if > that's what works, I don't mind :-) Frameworks and dylibs go into the Frameworks directory of an application bundle, it's standard. > The reason my application didn't work was a different one: it > picked up inappropriate modules from PYTHONPATH. I fixed this by > setting sys.path explicitly in __boot__.py, but I wonder if it > wouldn't be a good idea in general to make packaged Python > applications ignore PYTHONPATH altogether (by setting it to > something empty in the startup stub). I have some good reasons to > use PYTHONPATH in my setup, and I know how to handle it, but I > don't expect double-clickable applications (about which I normally > don't even need to know that they were written in Python) to be > affected by it. Well, you might think that you have particularly good reasons to use PYTHONPATH, but pth files can do the same thing in a more predictable way. Perhaps it should ignore PYTHONPATH, but why? NOTHING else does. It targets every single python interpreter in the system, why should this be any different? -bob From mark at mophilly.com Mon May 9 18:12:16 2005 From: mark at mophilly.com (Mark Phillips) Date: Mon, 9 May 2005 09:12:16 -0700 Subject: [Pythonmac-SIG] accounting packages in Python Message-ID: I apologize if this request is a tired, oft-repeated one. I have asked this before but I cannot remember if it was to this list. In any case, I am still seeking the best solution. I am seeking an accounting package that can be modified for a specific business. Open Source or source with license is OK. I would prefer that it be written in Python. I have found very good options written in Perl. However, due to the lack of inheritance and so on in Perl, I would rather not use those solutions. In addition, cross platform support is important for this project. Any ideas, links, etc., are welcome. Mark Phillips Mophilly & Associates On the web at http://www.mophilly.com On the phone at 619 444-9210 From Chris.Barker at noaa.gov Mon May 9 19:55:02 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon, 09 May 2005 10:55:02 -0700 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> Message-ID: <427FA3F6.4000401@noaa.gov> Bob Ippolito wrote: > Well, you might think that you have particularly good reasons to use > PYTHONPATH, but pth files can do the same thing in a more predictable > way. I agree with this...I have NEVER used PYTHONPATH. > Perhaps it should ignore PYTHONPATH, but why? For exactly the reason Konrad gave: An application bundle should run on anyone's system unchanged. The user should not have to know it is written in Python. So the issue is not whether The developer (Konrad, in this case) should use PYTHONPATH, but whether it's possible that someone that wants to run your application bundle is using it, and who the heck knows about that! A user might even have PYTHONPATH altered by some poorly designed application without their knowledge. The truth of the matter is that a lot of Python (and PYTHONPATH is part of this) was not designed from the start to be used to build distributable stand-along applications. Perhaps this will be made easier with Py3k some day, but in the meantime, I think it would be a great idea for Py2App to default to ignoring PYTHONPATH. > NOTHING else does. Would a Python interpreter embedded in a app use it? Not if I wrote that app! -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 at noaa.gov From bob at redivi.com Mon May 9 19:08:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 9 May 2005 13:08:44 -0400 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <427FA3F6.4000401@noaa.gov> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> <427FA3F6.4000401@noaa.gov> Message-ID: <45898987-7E14-4CCC-ABF2-331E3E6BFBE6@redivi.com> On May 9, 2005, at 1:55 PM, Chris Barker wrote: > Bob Ippolito wrote: > >> Well, you might think that you have particularly good reasons to use >> PYTHONPATH, but pth files can do the same thing in a more predictable >> way. > > I agree with this...I have NEVER used PYTHONPATH. Which is the only sane thing to do if you ever have to mess with multiple interpreters.. >> Perhaps it should ignore PYTHONPATH, but why? >> > > For exactly the reason Konrad gave: An application bundle should > run on > anyone's system unchanged. The user should not have to know it is > written in Python. So the issue is not whether The developer > (Konrad, in > this case) should use PYTHONPATH, but whether it's possible that > someone > that wants to run your application bundle is using it, and who the > heck > knows about that! A user might even have PYTHONPATH altered by some > poorly designed application without their knowledge. The truth of the > matter is that a lot of Python (and PYTHONPATH is part of this) was > not > designed from the start to be used to build distributable stand-along > applications. Perhaps this will be made easier with Py3k some day, but > in the meantime, I think it would be a great idea for Py2App to > default > to ignoring PYTHONPATH. As far as the effects of PYTHONPATH is additive. It's just going to search the PYTHONPATH in addition to places it would normally search. You would have to really go out of the way to set PYTHONPATH in an environment to where it mattered for double-click purposes (~/.MacOSX/ environment.plist). If you go through all that trouble, you really should know what you're doing and what the repercussions are. You might even be doing it on purpose to test an application with a newer version of PyObjC than it was built with or something crazy like that. In some cases people *do* want py2app to integrate with their existing environment (site-packages, PYTHONPATH, etc.). It's simply one of those things where you can't please everyone and I'll probably have to add Yet Another Option. The question is whether the option should be default or not (like --argv-emulation or --site-packages, which I've decided are not default). -bob From rswerdlow at goombah.com Mon May 9 22:23:55 2005 From: rswerdlow at goombah.com (Bob Swerdlow) Date: Mon, 9 May 2005 16:23:55 -0400 Subject: [Pythonmac-SIG] PyObjCStrBridgeWarning from NibClassBuilder.extractClasses Message-ID: <044d01c554d5$474d6970$066fa8c0@RSWERDLOW800> I'm still working to get my application running with Py2App. Things look pretty good now, except that at start-up, I still get a PyObjCStrBridgeWarning when the application starts. I stripped my test case down to the point where all it was doing was loading a new NIB (created by saving a new, unchanged InterfaceBuilder .nib file) with import NibClassBuilder NibClassBuilder.extractClasses(u'Test') and I still get the warning. This is on Panther with PyObjC 1.3. How do I fix this? Thanks, Bob From bob at redivi.com Mon May 9 22:43:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 9 May 2005 16:43:26 -0400 Subject: [Pythonmac-SIG] PyObjCStrBridgeWarning from NibClassBuilder.extractClasses In-Reply-To: <044d01c554d5$474d6970$066fa8c0@RSWERDLOW800> References: <044d01c554d5$474d6970$066fa8c0@RSWERDLOW800> Message-ID: <9E7B53CA-08EE-4EB5-BACE-7362F5485581@redivi.com> On May 9, 2005, at 4:23 PM, Bob Swerdlow wrote: > I'm still working to get my application running with Py2App. > Things look > pretty good now, except that at start-up, I still get a > PyObjCStrBridgeWarning when the application starts. I stripped my > test case > down to the point where all it was doing was loading a new NIB > (created by > saving a new, unchanged InterfaceBuilder .nib file) with > import NibClassBuilder > NibClassBuilder.extractClasses(u'Test') > and I still get the warning. > > This is on Panther with PyObjC 1.3. > > How do I fix this? Update to PyObjC from svn -bob From rowen at cesmail.net Tue May 10 01:13:25 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Mon, 09 May 2005 16:13:25 -0700 Subject: [Pythonmac-SIG] Trouble with _readline package Message-ID: I downloaded a few packages today from and installed them (selecting those for MacOS X 10.3 with the built in python). I installed _readlines, _tkinter, _bsddb, py2app and PantherPythonFix (even though I had a working _tkinter and _readlines from Package Manager). After that my startup script (that remembers recent commands between invocations of python) failed with: /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python .app/Contents/MacOS/Python: object: /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/si te-packages/readline.so truncated or malformed object (LC_SEGMENT command 2 fileoff field plus filesize field extends past the end of the file) I used Package Manager to restore _readlines and all seems to be well. By the way, Package Manager's can't find its database again -- presumably due to 10.3.9. (In fact one reason I wanted to have a set of directly downloadable packages instead of using package manager is that the latter often can't find its database without help). -- Russell From bob at redivi.com Tue May 10 02:27:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 9 May 2005 20:27:22 -0400 Subject: [Pythonmac-SIG] Trouble with _readline package In-Reply-To: References: Message-ID: <9A347E2F-8C52-4861-BAD4-9D281519F868@redivi.com> On May 9, 2005, at 7:13 PM, Russell E. Owen wrote: > I downloaded a few packages today from > and installed them (selecting those for MacOS X 10.3 with the built in > python). > > I installed _readlines, _tkinter, _bsddb, py2app and PantherPythonFix > (even though I had a working _tkinter and _readlines from Package > Manager). > > After that my startup script (that remembers recent commands between > invocations of python) failed with: > > /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python > .app/Contents/MacOS/Python: object: > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/si > te-packages/readline.so truncated or malformed object (LC_SEGMENT > command 2 fileoff field plus filesize field extends past the end of > the > file) It sounds like somehow your readline.so got corrupted. The one at is not corrupt, I just checked it. -bob From konrad.hinsen at laposte.net Tue May 10 11:14:23 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Tue, 10 May 2005 11:14:23 +0200 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> Message-ID: <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> Bob Ippolito writes: > Well, you might think that you have particularly good reasons to use > PYTHONPATH, but pth files can do the same thing in a more predictable My particularly good reason is that I set PYTHONPATH differently in different shell environments for testing purposes. Changing links and path files is a lot more work. > way. Perhaps it should ignore PYTHONPATH, but why? NOTHING else does. > It targets every single python interpreter in the system, why should this > be any different? py2app makes a big effort to make the package independent of the particular system environment on which it runs. PYTHONPATH is part of the system environment. From a more pragmatic point of view, I don't see how respecting PYTHONPATH could do anyone any good (except people who intentionally modify the behaviour of an installed package, but they usually know what they are doing), and it can do a lot of harm by executing different code than the packager intended. In the worst case, a system administrator sets PYTHONPATH for whatever reason, and the user who clicks on an application doesn't even know about it. He reports a crash to the developer who doesn't suspect anything either. Konrad. From ronaldoussoren at mac.com Tue May 10 14:30:38 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 10 May 2005 14:30:38 +0200 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> Message-ID: <84FFBF07-173E-4021-9494-C8ECBBFF59A1@mac.com> On 10-mei-2005, at 11:14, konrad.hinsen at laposte.net wrote: > Bob Ippolito writes: > > >> Well, you might think that you have particularly good reasons to use >> PYTHONPATH, but pth files can do the same thing in a more predictable >> > > My particularly good reason is that I set PYTHONPATH differently in > different shell environments for testing purposes. Changing links > and path > files is a lot more work. > > >> way. Perhaps it should ignore PYTHONPATH, but why? NOTHING else >> does. >> It targets every single python interpreter in the system, why >> should this >> be any different? >> > > py2app makes a big effort to make the package independent of the > particular > system environment on which it runs. PYTHONPATH is part of the system > environment. > > From a more pragmatic point of view, I don't see how respecting > PYTHONPATH > could do anyone any good (except people who intentionally modify the > behaviour of an installed package, but they usually know what they are > doing), and it can do a lot of harm by executing different code > than the > packager intended. > > In the worst case, a system administrator sets PYTHONPATH for whatever > reason, and the user who clicks on an application doesn't even know > about > it. He reports a crash to the developer who doesn't suspect > anything either. The same is true for something like DYLD_FRAMEWORK_PATH. This might also be useful for testing but can cause serious problems when you always set it. If you set it globally random application bundles might no longer start. Someone who changes a global search path needs to know what he's doing. An option that tells py2app that PYTHONPATH should be ignored by the created bundle would be nice to have. Ronald From lee_cullens at mac.com Tue May 10 15:25:50 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 10 May 2005 09:25:50 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1 In-Reply-To: <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> Message-ID: Clean Tiger install and all other applications reinstalled. All running well. Slowly getting there. So far I have the following up and haven't encountered a problem yet. MacPython-OSX-2.4.1-1.dmg TigerPython24Fix-r2.zip TigerPython23Compat.pkg RegexPlor-20050503-Tiger.zip Next steps - are the following appropriate? wxPython-2.6unicode-py2.4-macosx10.3.zip (assuming this will work on 10.4) TclTkAquaBI-8.4.9.1.dmg Considering checking out GTK+ also and wondering if anyone else has this up on Tiger yet? Any news on native port to OS X? Have also reinstalled WingIDE which is working well (with Python 2.3.5). Will someone remind me what to point to (in the WingIDE perfs) to use Python 2.4 please? Thanks, Lee C From charles.hartman at conncoll.edu Tue May 10 15:33:51 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 10 May 2005 09:33:51 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1 In-Reply-To: References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> Message-ID: <5DE4B2A2-D346-4A8C-A45C-6E57F396A9CC@conncoll.edu> On May 10, 2005, at 9:25 AM, Lee Cullens wrote: > Have also reinstalled WingIDE which is working well (with Python > 2.3.5). Will someone remind me what to point to (in the WingIDE > perfs) to use Python 2.4 please? In Project menu, Properties, Python Executable -- mine (on Tiger) points to /usr/local/bin/pythonw, which is Python 2.4.1. Charles Hartman From rkern at ucsd.edu Tue May 10 15:43:21 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 10 May 2005 06:43:21 -0700 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1 In-Reply-To: References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> Message-ID: <4280BA79.90703@ucsd.edu> Lee Cullens wrote: > Clean Tiger install and all other applications reinstalled. All > running well. > > Slowly getting there. So far I have the following up and haven't > encountered a problem yet. > MacPython-OSX-2.4.1-1.dmg > TigerPython24Fix-r2.zip > TigerPython23Compat.pkg > RegexPlor-20050503-Tiger.zip > > Next steps - are the following appropriate? > wxPython-2.6unicode-py2.4-macosx10.3.zip (assuming this will > work on 10.4) I believe so. > TclTkAquaBI-8.4.9.1.dmg Tiger comes with TclTkAqua, but not the Batteries Included version, I believe. I'd say, don't bother unless you know that you need a particular battery, like Tix. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From dreedmac at columbus.rr.com Tue May 10 17:16:58 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Tue, 10 May 2005 11:16:58 -0400 Subject: [Pythonmac-SIG] py2app and CLI Python programs Message-ID: I've got a command line Python app that I tried packaging up with py2app. It worked ok - t could cd into the subdir of the .app containing the executable and run it from the command line, but I'm not certain what its current working directory was since when I tried to specify a file on the command line, it didn't find it. I had to specify the full path to the file to make it work. Is there a simple workaround for command line versions - I didn't see anything in the documentation. Thanks, Dave From dreedmac at columbus.rr.com Tue May 10 17:28:33 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Tue, 10 May 2005 11:28:33 -0400 Subject: [Pythonmac-SIG] Spotlight and Python Message-ID: I noticed Spotlight doesn't index Python files. I'm not certain how useful it would be but I was thinking about trying to get spotlight to index the name of classes and functions/methods (i.e., you could enter a class name and spotlight would find the Python file containing the class). I don't care if it does it on the fly as files are updated, but thought it would be nice to be able to run a Python script that would index all Python files in a directory. You could use the inspect module to grab the class/function/method names and tell spotlight to include them. I know there are some command line tools to interact with spotlight, but after a quick look at them, nothing jumped out at me for doing this. Is anyone interested in this (i.e., would you find it useful) and if so, does anyone understand Spotlight well enough to point me in the right direction (pointers to specific documentation are welcome). Thanks, Dave From rkern at ucsd.edu Tue May 10 17:29:55 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 10 May 2005 08:29:55 -0700 Subject: [Pythonmac-SIG] py2app and CLI Python programs In-Reply-To: References: Message-ID: <4280D373.4010108@ucsd.edu> David Reed wrote: > I've got a command line Python app that I tried packaging up with > py2app. It worked ok - t could cd into the subdir of the .app > containing the executable and run it from the command line, but I'm > not certain what its current working directory was since when I tried > to specify a file on the command line, it didn't find it. I had to > specify the full path to the file to make it work. Is there a simple > workaround for command line versions - I didn't see anything in the > documentation. [/some/path] $ /Applications/MyApp.app/Contents/MacOS/MyApp will usually have /some/path as the cwd. However, .app bundles are probably not what you want for CLI apps. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From lee_cullens at mac.com Tue May 10 17:59:39 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 10 May 2005 11:59:39 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1 In-Reply-To: <4280BA79.90703@ucsd.edu> References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> <4280BA79.90703@ucsd.edu> Message-ID: Thanks Robert, I'll give wx a try then, but hold off on TclTkAqua till I see what I need. I thought I remembered Bob saying I might need it, but can't find the note. One tries to make sure they don't leave anything important behind with a "clean" instal, but inevitably does :~) Lee C On May 10, 2005, at 9:43 AM, Robert Kern wrote: > Lee Cullens wrote: > >> Clean Tiger install and all other applications reinstalled. All >> running well. >> >> Slowly getting there. So far I have the following up and haven't >> encountered a problem yet. >> MacPython-OSX-2.4.1-1.dmg >> TigerPython24Fix-r2.zip >> TigerPython23Compat.pkg >> RegexPlor-20050503-Tiger.zip >> >> Next steps - are the following appropriate? >> wxPython-2.6unicode-py2.4-macosx10.3.zip (assuming this will >> work on 10.4) >> > > I believe so. > > >> TclTkAquaBI-8.4.9.1.dmg >> > > Tiger comes with TclTkAqua, but not the Batteries Included version, I > believe. I'd say, don't bother unless you know that you need a > particular battery, like Tix. > > -- > Robert Kern > rkern at ucsd.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jwight_lists at toxicsoftware.com Tue May 10 18:01:03 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Tue, 10 May 2005 12:01:03 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: Message-ID: It's certainly a good idea. Writing a Spotlight plug-in is extremely straight forward - just fire up Xcode 2 and create a new "Metadata Importer" project. You just have one function that you need to provide: Boolean GetMetadataForFile(void* thisInterface, CFMutableDictionaryRef attributes, CFStringRef contentTypeUTI, CFStringRef pathToFile) Don't forget to modify the Info.plist and possibly the schema.xml file. Also - you'll probably need to create an installer for the importer so that when installed it forces a reindex, see: http://www.apple.com/ downloads/macosx/submit/installers.html Now I believe that Spotlight is smart enough to detect when a file is created/written that needs importing so you wont have to manually force any re-indexing yourself. I'm currently writing a spotlight importers for the GPX xml file format and for another inhouse project of mine. Jon. On May 10, 2005, at 11:28, David Reed wrote: > I noticed Spotlight doesn't index Python files. I'm not certain how > useful it would be but I was thinking about trying to get spotlight > to index the name of classes and functions/methods (i.e., you could > enter a class name and spotlight would find the Python file > containing the class). I don't care if it does it on the fly as files > are updated, but thought it would be nice to be able to run a Python > script that would index all Python files in a directory. You could > use the inspect module to grab the class/function/method names and > tell spotlight to include them. I know there are some command line > tools to interact with spotlight, but after a quick look at them, > nothing jumped out at me for doing this. > > Is anyone interested in this (i.e., would you find it useful) and if > so, does anyone understand Spotlight well enough to point me in the > right direction (pointers to specific documentation are welcome). > > Thanks, > Dave From Chris.Barker at noaa.gov Tue May 10 19:00:19 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue, 10 May 2005 10:00:19 -0700 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <84FFBF07-173E-4021-9494-C8ECBBFF59A1@mac.com> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> <84FFBF07-173E-4021-9494-C8ECBBFF59A1@mac.com> Message-ID: <4280E8A3.80008@noaa.gov> Ronald Oussoren wrote: > The same is true for something like DYLD_FRAMEWORK_PATH. This might > also be > useful for testing but can cause serious problems when you always set > it Sure, but no one would mess with DYLD_FRAMEWORK_PATH in nearly so casual a way as people mess with PYTHONPATH. I think the root of the problem here is that in common usage, Python is not considered a core system component. Everyone who uses it tends to behave as though their application is the only one using python on the system. It is not treated as a core system component, like the linker, for instance. This is the case both with folks that put together the os (RedHat, Apple, IBM), who use it and have not taken into consideration that other applications might well want to use different versions, etc, and with application builders, that do things like mess with PYTHONPATH for their own application. I'd like to see Python accepted as a core system component, but this would require more discipline by everyone, as well as a few things we don't have like a standard way to do version management, of both python and python packages. Until then, we're probably better of thinking of python like a statically linked library: each instance should have nothing to do with any other instance, which is why I recommend the Py2App default to ignoring PYTHONPATH. -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 at noaa.gov From rowen at cesmail.net Tue May 10 19:03:13 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Tue, 10 May 2005 10:03:13 -0700 Subject: [Pythonmac-SIG] Trouble with _readline package References: <9A347E2F-8C52-4861-BAD4-9D281519F868@redivi.com> Message-ID: In article <9A347E2F-8C52-4861-BAD4-9D281519F868 at redivi.com>, Bob Ippolito wrote: > On May 9, 2005, at 7:13 PM, Russell E. Owen wrote: > >After...(installing the binary _readline for MacOS X 10.3 with vanilla Python 2.3.0) > >my startup script ...failed. > > It sounds like somehow your readline.so got corrupted. The one at > is not corrupt, I just checked it. I think you are right. I downloaded a new copy and installed that and it seems to work fine now. Thanks! -- Russell From rowen at cesmail.net Tue May 10 19:07:52 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Tue, 10 May 2005 10:07:52 -0700 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1 References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> Message-ID: In article , Lee Cullens wrote: > Next steps - are the following appropriate? > wxPython-2.6unicode-py2.4-macosx10.3.zip (assuming this will > work on 10.4) > TclTkAquaBI-8.4.9.1.dmg TclTkAquaBI-8.4.9.1 has a serious flaw on my MacOS X 10.3 installation: Entry widgets have a large margin around the text. This is new as of 8.4.9.1. If you see this on Tiger as well then I suggest you install 8.4.9.0 instead. Or, as another poster noted, just use the built in Aqua Tcl/Tk (you don't get the Tk/Tcl extensions but if your main interest is python then you may not care). Anyone know what happens if you use the existing TclTkAqua installer to install the extensions but NOT Tcl and Tk? -- Russell From bob at redivi.com Tue May 10 19:21:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 May 2005 13:21:50 -0400 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> Message-ID: <223A88B2-3B2F-4526-ABB7-9984524985DA@redivi.com> On May 10, 2005, at 5:14 AM, konrad.hinsen at laposte.net wrote: > Bob Ippolito writes: > > >> Well, you might think that you have particularly good reasons to use >> PYTHONPATH, but pth files can do the same thing in a more predictable >> > > My particularly good reason is that I set PYTHONPATH differently in > different shell environments for testing purposes. Changing links > and path > files is a lot more work. I use different checkouts (or python interpreters) for different environments... >> way. Perhaps it should ignore PYTHONPATH, but why? NOTHING else >> does. >> It targets every single python interpreter in the system, why >> should this >> be any different? >> > > py2app makes a big effort to make the package independent of the > particular > system environment on which it runs. PYTHONPATH is part of the system > environment. > > From a more pragmatic point of view, I don't see how respecting > PYTHONPATH > could do anyone any good (except people who intentionally modify the > behaviour of an installed package, but they usually know what they are > doing), and it can do a lot of harm by executing different code > than the > packager intended. Well I went ahead and changed the default behavior to ignore PYTHONPATH. > In the worst case, a system administrator sets PYTHONPATH for whatever > reason, and the user who clicks on an application doesn't even know > about > it. He reports a crash to the developer who doesn't suspect > anything either. However, I still don't quite agree with you. There are PLENTY of environment variables that you should only set if you know what you're doing, and you should only set as a software developer. The DYLD variables come to mind. Setting PYTHONPATH is a lot like setting DYLD_LIBRARY_PATH. Both have their obscure uses, and both will explode in your face if you use them naively. A system administrator should never, ever, be setting PYTHONPATH. -bob From bob at redivi.com Tue May 10 19:24:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 May 2005 13:24:49 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1 In-Reply-To: References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> Message-ID: On May 10, 2005, at 9:25 AM, Lee Cullens wrote: > Clean Tiger install and all other applications reinstalled. All > running well. > > Slowly getting there. So far I have the following up and haven't > encountered a problem yet. > MacPython-OSX-2.4.1-1.dmg > TigerPython24Fix-r2.zip > TigerPython23Compat.pkg > RegexPlor-20050503-Tiger.zip > > Next steps - are the following appropriate? > wxPython-2.6unicode-py2.4-macosx10.3.zip (assuming this will > work on 10.4) > TclTkAquaBI-8.4.9.1.dmg That wxPython package should work. TclTkAqua isn't really necessary unless you start using some of the "batteries included" of the package, since Tiger ships with (the normal version of) TclTkAqua. You'll know if you need it. > Considering checking out GTK+ also and wondering if anyone else has > this up on Tiger yet? Any news on native port to OS X? A native port for GTK+ isn't anywhere near close. I wouldn't bother with it unless you care more about Linux/win32 than you do about Mac OS X. -bob From bob at redivi.com Tue May 10 19:28:11 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 May 2005 13:28:11 -0400 Subject: [Pythonmac-SIG] py2app and CLI Python programs In-Reply-To: <4280D373.4010108@ucsd.edu> References: <4280D373.4010108@ucsd.edu> Message-ID: <3C6B5C4A-C1DB-41A3-84E6-8B999FD11DE3@redivi.com> On May 10, 2005, at 11:29 AM, Robert Kern wrote: > David Reed wrote: > >> I've got a command line Python app that I tried packaging up with >> py2app. It worked ok - t could cd into the subdir of the .app >> containing the executable and run it from the command line, but I'm >> not certain what its current working directory was since when I tried >> to specify a file on the command line, it didn't find it. I had to >> specify the full path to the file to make it work. Is there a simple >> workaround for command line versions - I didn't see anything in the >> documentation. >> > > [/some/path] $ /Applications/MyApp.app/Contents/MacOS/MyApp > > will usually have /some/path as the cwd. > > However, .app bundles are probably not what you want for CLI apps. py2app will chdir to /Applications/MyApp.app/Contents/Resources by default, if you specify the --no-chdir option, it will not change the directory (but when started by LaunchServices, the cwd will be /). py2app is the only reliable way to create standalone Python applications on Mac OS X.. it might make sense to write a CLI app with it and throw some symlinks into /usr/local/bin or something.. but you're probably better off just giving them the script and telling them how to get the dependencies. Most people comfortable at a CLI are going to be able to do that. -bob From bob at redivi.com Tue May 10 19:31:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 May 2005 13:31:35 -0400 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <4280E8A3.80008@noaa.gov> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> <84FFBF07-173E-4021-9494-C8ECBBFF59A1@mac.com> <4280E8A3.80008@noaa.gov> Message-ID: <524ACB20-E273-48CD-A281-FC45A9105D94@redivi.com> On May 10, 2005, at 1:00 PM, Chris Barker wrote: > Ronald Oussoren wrote: > >> The same is true for something like DYLD_FRAMEWORK_PATH. This might >> also be >> useful for testing but can cause serious problems when you always set >> it > > Sure, but no one would mess with DYLD_FRAMEWORK_PATH in nearly so > casual > a way as people mess with PYTHONPATH. > > I think the root of the problem here is that in common usage, > Python is > not considered a core system component. Everyone who uses it tends to > behave as though their application is the only one using python on the > system. It is not treated as a core system component, like the linker, > for instance. This is the case both with folks that put together > the os > (RedHat, Apple, IBM), who use it and have not taken into consideration > that other applications might well want to use different versions, > etc, > and with application builders, that do things like mess with > PYTHONPATH > for their own application. > > I'd like to see Python accepted as a core system component, but this > would require more discipline by everyone, as well as a few things we > don't have like a standard way to do version management, of both > python > and python packages. Until then, we're probably better of thinking of > python like a statically linked library: each instance should have > nothing to do with any other instance, which is why I recommend the > Py2App default to ignoring PYTHONPATH. If you're going to treat it like that, then you should definitely stay away from the pre-installed Python and use one of the "third party" Pythons when building your applications. FWIW, all py2app built applications that depend on Apple's Python 2.3 will probably break on Mac OS X 10.5, whenever that comes out, because presumably it will only ship with Python 2.4 (or 2.5). -bob From dreedmac at columbus.rr.com Tue May 10 19:56:34 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Tue, 10 May 2005 13:56:34 -0400 Subject: [Pythonmac-SIG] py2app and CLI Python programs In-Reply-To: <3C6B5C4A-C1DB-41A3-84E6-8B999FD11DE3@redivi.com> References: <4280D373.4010108@ucsd.edu> <3C6B5C4A-C1DB-41A3-84E6-8B999FD11DE3@redivi.com> Message-ID: <06D34311-F191-4A21-958A-4928CD004F28@columbus.rr.com> On May 10, 2005, at 1:28 PM, Bob Ippolito wrote: > On May 10, 2005, at 11:29 AM, Robert Kern wrote: > > >> David Reed wrote: >> >> >>> I've got a command line Python app that I tried packaging up with >>> py2app. It worked ok - t could cd into the subdir of the .app >>> containing the executable and run it from the command line, but I'm >>> not certain what its current working directory was since when I >>> tried >>> to specify a file on the command line, it didn't find it. I had to >>> specify the full path to the file to make it work. Is there a simple >>> workaround for command line versions - I didn't see anything in the >>> documentation. >>> >>> >> >> [/some/path] $ /Applications/MyApp.app/Contents/MacOS/MyApp >> >> will usually have /some/path as the cwd. >> >> However, .app bundles are probably not what you want for CLI apps. >> > > py2app will chdir to /Applications/MyApp.app/Contents/Resources by > default, if you specify the --no-chdir option, it will not change the > directory (but when started by LaunchServices, the cwd will be /). > > py2app is the only reliable way to create standalone Python > applications on Mac OS X.. it might make sense to write a CLI app > with it and throw some symlinks into /usr/local/bin or something.. > but you're probably better off just giving them the script and > telling them how to get the dependencies. Most people comfortable at > a CLI are going to be able to do that. > > -bob Thanks. The program needed PIL and I was just trying to avoid having the person need to install that, but you're right. Dave From lee_cullens at mac.com Tue May 10 20:18:21 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 10 May 2005 14:18:21 -0400 Subject: [Pythonmac-SIG] Clean Tiger install and Python 2.4.1 In-Reply-To: References: <427055A6.2060202@wordtech-software.com> <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> <6d853fba705d109f97af783b4479a908@mac.com> <12D7D454-9862-4AB5-9762-9B59E6D5437E@redivi.com> <0AD0704A-EBD7-43D8-B1C7-7C36AA3C1136@redivi.com> Message-ID: <20104B44-05AA-4D68-958B-1F464C0ADBFE@mac.com> Thanks Bob and Russell, Lee C From dreedmac at columbus.rr.com Tue May 10 20:49:31 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Tue, 10 May 2005 14:49:31 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: Message-ID: On May 10, 2005, at 12:01 PM, Jonathan Wight wrote: > It's certainly a good idea. > > Writing a Spotlight plug-in is extremely straight forward - just > fire up Xcode 2 and create a new "Metadata Importer" project. You > just have one function that you need to provide: > > Boolean GetMetadataForFile(void* thisInterface, > CFMutableDictionaryRef attributes, > CFStringRef contentTypeUTI, > CFStringRef pathToFile) > > Don't forget to modify the Info.plist and possibly the schema.xml > file. > > Also - you'll probably need to create an installer for the importer > so that when installed it forces a reindex, see: http:// > www.apple.com/downloads/macosx/submit/installers.html > > Now I believe that Spotlight is smart enough to detect when a file > is created/written that needs importing so you wont have to > manually force any re-indexing yourself. > > I'm currently writing a spotlight importers for the GPX xml file > format and for another inhouse project of mine. > > Jon. I've looked at the example at: http://developer.apple.com/documentation/Carbon/Conceptual/ MDImporters/Concepts/WritingAnImp.html#//apple_ref/doc/uid/TP40001275- CJBEJBHH I don't yet understand what NSDictionary tempDict contains after it "loads the document at the specified location". My thought would be to read the file and look for def and class and then grab the next word after it and add it to the index. Looks like kMDItemTextContent is what could be used to do that. I could read the file in C and look for def/class and then would just need to figure out how to use the kMDItemTextContent class. Am I on the correct track? Dave From jwight_lists at toxicsoftware.com Tue May 10 21:00:32 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Tue, 10 May 2005 15:00:32 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: Message-ID: On May 10, 2005, at 14:49, David Reed wrote: > I've looked at the example at: > > http://developer.apple.com/documentation/Carbon/Conceptual/ > MDImporters/Concepts/WritingAnImp.html#//apple_ref/doc/uid/ > TP40001275-CJBEJBHH > > I don't yet understand what NSDictionary tempDict contains after it > "loads the document at the specified location". > My thought would be to read the file and look for def and class and > then grab the next word after it and add it to the index. Looks > like kMDItemTextContent is what could be used to do that. > > I could read the file in C and look for def/class and then would > just need to figure out how to use the kMDItemTextContent class. > > Am I on the correct track? See: http://developer.apple.com/documentation/Carbon/Reference/MDItemRef/ Reference/chapter_1.3_section_2.html#//apple_ref/doc/c_ref/ kMDItemTextContent The best way I think would be to create new spotlight metadata attribute types for "Class Name" and "Function Name" (or see if C/ ObjC files already provide similar useful keys (just checked - they don't seem to). Then find all the class/function names in the file and add them to the new attributes. Then you'd join all this data together with whitespace and put it into the kMDItemTextContent attribute. I'm not sure how useful it is to index function & class names though. There could be a heck of a lot of those - most of which might not be too useful. Wouldn't doing something with the Python __doc__ blocks be more useful? Jon. From jacob at jacobian.org Tue May 10 21:57:20 2005 From: jacob at jacobian.org (Jacob Kaplan-Moss) Date: Tue, 10 May 2005 14:57:20 -0500 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: Message-ID: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> On May 10, 2005, at 2:00 PM, Jonathan Wight wrote: > I'm not sure how useful it is to index function & class names though. > Oh, I disagree -- I've got over 100K lines of code, and I would *kill* to be able to find everywhere a particular symbol is used. And yes, I know grep -r will do it for me -- but the more ways to sift through data, the better. Jacob From bob at redivi.com Tue May 10 22:15:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 May 2005 16:15:05 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> Message-ID: On May 10, 2005, at 3:57 PM, Jacob Kaplan-Moss wrote: > On May 10, 2005, at 2:00 PM, Jonathan Wight wrote: > > >> I'm not sure how useful it is to index function & class names though. >> >> > > Oh, I disagree -- I've got over 100K lines of code, and I would > *kill* to be able to find everywhere a particular symbol is used. > And yes, I know grep -r will do it for me -- but the more ways to > sift through data, the better. The cool part about spotlight is that you could probably create the metadata from ASTs such that you could do advanced queries that say something to the effect of give me all python files where this class is defined, or maybe even where this class is subclassed.. stuff like that. -bob From dreedmac at columbus.rr.com Tue May 10 22:22:28 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Tue, 10 May 2005 16:22:28 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> Message-ID: On May 10, 2005, at 3:57 PM, Jacob Kaplan-Moss wrote: > On May 10, 2005, at 2:00 PM, Jonathan Wight wrote: > > >> I'm not sure how useful it is to index function & class names though. >> >> > > Oh, I disagree -- I've got over 100K lines of code, and I would > *kill* to be able to find everywhere a particular symbol is used. > And yes, I know grep -r will do it for me -- but the more ways to > sift through data, the better. > > Jacob > I don't think I'd want all variables/symbols to be indexed, but I think function and class names might be nice and adding the documentation strings might be worthwhile too. It appears I still need to learn more about Objective-C although one of Jonathan's emails makes me think I could just read the file and make a space separated string of the functions and class names and that would about take care of it. If someone who knows more about Objective-C wants to take a stab at this feel free as I probably won't get to learning more about Objective-C for a couple more months. Dave From jwight_lists at toxicsoftware.com Tue May 10 22:58:44 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Tue, 10 May 2005 16:58:44 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> Message-ID: <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> I'll have a play with it later today. I don't think it should be too difficult at all. Jon. On May 10, 2005, at 16:22, David Reed wrote: > I don't think I'd want all variables/symbols to be indexed, but I > think function and class names might be nice and adding the > documentation strings might be worthwhile too. It appears I still > need to learn more about Objective-C although one of Jonathan's > emails makes me think I could just read the file and make a space > separated string of the functions and class names and that would > about take care of it. > > If someone who knows more about Objective-C wants to take a stab at > this feel free as I probably won't get to learning more about > Objective-C for a couple more months. > From rkern at ucsd.edu Tue May 10 23:41:27 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 10 May 2005 14:41:27 -0700 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> Message-ID: <42812A87.2060201@ucsd.edu> Jacob Kaplan-Moss wrote: > On May 10, 2005, at 2:00 PM, Jonathan Wight wrote: > > >>I'm not sure how useful it is to index function & class names though. >> > > > Oh, I disagree -- I've got over 100K lines of code, and I would > *kill* to be able to find everywhere a particular symbol is used. > And yes, I know grep -r will do it for me -- but the more ways to > sift through data, the better. *cough* ctags *cough* http://ctags.sourceforge.net/ -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From keithn at 2xtreme.net Wed May 11 00:03:25 2005 From: keithn at 2xtreme.net (Keith Nemitz) Date: Tue, 10 May 2005 15:03:25 -0700 Subject: [Pythonmac-SIG] [ANN] X-platform GUI made open source for PyGame In-Reply-To: References: Message-ID: <55072F12-C19F-11D9-AF5C-000393DB52E4@2xtreme.net> Mousechief announces publication of open source code of a cross-platform, lightweight GUI, for PyGame. Faces and Features is a small, flexible, and elegant set of fundamental building blocks for game user interfaces. Example code is supplied along with the engine sources. A micro app demonstrates fundamentals, while a full blown arcade game, Fruit-o-Matic, demonstrates many of the wonderful things you can build with the Faces and Features library. [Download the full game separately to get the data required by the sources.] http://www.mousechief.com/ A far more complex game, 'The Witch's Yarn' has also shipped using Faces and Features. Sources not available. Documentation is sparse and support is nil. Sorry. Future releases will improve the former, but nothing short of cash will improve the latter. Keith Nemitz Mousechief Co. www.mousechief.com From jwight_lists at toxicsoftware.com Wed May 11 02:52:47 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Tue, 10 May 2005 20:52:47 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> Message-ID: <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> I've made a first pass at it and have a Spotlight importer that calls a built-in Python function to import a file's metadata. I started to look at module inspect to find out how to extract information from a Python module but then realised that I'd need to import the file the importer is analysing. This would mean it will be executing arbitrary code inside that file. That's got to be a bad thing for security reasons. So instead I'm just going to have to use string processing to scan the file instead. Are there any modules out there for extracting information from Python script files? Jon. On May 10, 2005, at 16:58, Jonathan Wight wrote: > I'll have a play with it later today. I don't think it should be too > difficult at all. > > Jon. > > On May 10, 2005, at 16:22, David Reed wrote: > > > > > > > > >> I don't think I'd want all variables/symbols to be indexed, but I >> think function and class names might be nice and adding the >> documentation strings might be worthwhile too. It appears I still >> need to learn more about Objective-C although one of Jonathan's >> emails makes me think I could just read the file and make a space >> separated string of the functions and class names and that would >> about take care of it. >> >> If someone who knows more about Objective-C wants to take a stab at >> this feel free as I probably won't get to learning more about >> Objective-C for a couple more months. >> >> >> >> From bob at redivi.com Wed May 11 03:52:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 May 2005 21:52:53 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> Message-ID: <09AF8304-24CB-4977-AA6C-63AB4153F603@redivi.com> On May 10, 2005, at 8:52 PM, Jonathan Wight wrote: > I've made a first pass at it and have a Spotlight importer that calls > a built-in Python function to import a file's metadata. > > I started to look at module inspect to find out how to extract > information from a Python module but then realised that I'd need to > import the file the importer is analysing. This would mean it will be > executing arbitrary code inside that file. That's got to be a bad > thing for security reasons. > > So instead I'm just going to have to use string processing to scan > the file instead. Are there any modules out there for extracting > information from Python script files? You want to use the parser module. -bob From dreedmac at columbus.rr.com Wed May 11 03:55:07 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Tue, 10 May 2005 21:55:07 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> Message-ID: On May 10, 2005, at 8:52 PM, Jonathan Wight wrote: > I've made a first pass at it and have a Spotlight importer that > calls a built-in Python function to import a file's metadata. > > I started to look at module inspect to find out how to extract > information from a Python module but then realised that I'd need to > import the file the importer is analysing. This would mean it will > be executing arbitrary code inside that file. That's got to be a > bad thing for security reasons. > > So instead I'm just going to have to use string processing to scan > the file instead. Are there any modules out there for extracting > information from Python script files? > > Jon. It's been a while since I looked at the inspect module - I didn't remember it actually executed code. I'm not aware of any code that processes a python file w/o executing it (I do remember that being a complaint about pychecker). You could rip out code from the Python interpreter, but I could probably write a C or C++ function that read a file and returned the names of the classes and functions/methods in less time than I could find and decipher the Python interpreter code if that would help you. Would you pass it a filename or a file handle and how would you want the data back (an array of strings or one long string separated by spaces, etc.). Does it matter if it's C or could it use C++ features (the C++ string class might be useful). I would just look for "def" or "class" and grab the next word up to a "(" or ":". Dave From bob at redivi.com Wed May 11 04:02:02 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 May 2005 22:02:02 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> Message-ID: <46F7DC5E-A4A4-4546-976F-33CEC7E82D20@redivi.com> On May 10, 2005, at 9:55 PM, David Reed wrote: > > On May 10, 2005, at 8:52 PM, Jonathan Wight wrote: > > >> I've made a first pass at it and have a Spotlight importer that >> calls a built-in Python function to import a file's metadata. >> >> I started to look at module inspect to find out how to extract >> information from a Python module but then realised that I'd need to >> import the file the importer is analysing. This would mean it will >> be executing arbitrary code inside that file. That's got to be a >> bad thing for security reasons. >> >> So instead I'm just going to have to use string processing to scan >> the file instead. Are there any modules out there for extracting >> information from Python script files? > > It's been a while since I looked at the inspect module - I didn't > remember it actually executed code. I'm not aware of any code that > processes a python file w/o executing it (I do remember that being a > complaint about pychecker). You could rip out code from the Python > interpreter, but I could probably write a C or C++ function that read > a file and returned the names of the classes and functions/methods in > less time than I could find and decipher the Python interpreter code > if that would help you. Would you pass it a filename or a file handle > and how would you want the data back (an array of strings or one long > string separated by spaces, etc.). Does it matter if it's C or could > it use C++ features (the C++ string class might be useful). I would > just look for "def" or "class" and grab the next word up to a "(" or > ":". The compiler and parser modules are both standard library bits that parse the AST of python source without executing it. The stuff in parser is fast and weird (since it's effectively a Python interface to the internal parser), and the stuff in compiler is (very) slow and less weird. -bob From janssen at parc.com Wed May 11 04:11:15 2005 From: janssen at parc.com (Bill Janssen) Date: Tue, 10 May 2005 19:11:15 PDT Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: Your message of "Tue, 10 May 2005 17:52:47 PDT." <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> Message-ID: <05May10.191118pdt."58617"@synergy1.parc.xerox.com> If you look at the parser module documentation, there's a section labelled "Information Discovery", which details the process. Bill > Are there any modules out there for extracting > information from Python script files? From python at bostonmacosx.dyndns.org Wed May 11 04:22:12 2005 From: python at bostonmacosx.dyndns.org (RH) Date: Tue, 10 May 2005 22:22:12 -0400 Subject: [Pythonmac-SIG] Newbie.....sorry Message-ID: <22ce9c71cfa5fb7ca9b9155e48bf8c97@bostonmacosx.dyndns.org> Ok so I decided to take the plunge into Python. I'm a fairly advanced PHP developer and am now moving into Python as a next step. I'm on Panther.... I just don't comprehend the packages you add into Python. How can you list what packages are installed. I downloaded the python extras and tried the package manager. I constantly have to manually enter the URL for the plist and then I don't see packages which I've installed such as Numeric. Can anyone explain the package procedure. I've read the wiki and the FAQ and and still am out in the dark. Cheers, Robert From jwight_lists at toxicsoftware.com Wed May 11 04:25:27 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Tue, 10 May 2005 22:25:27 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <09AF8304-24CB-4977-AA6C-63AB4153F603@redivi.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> <09AF8304-24CB-4977-AA6C-63AB4153F603@redivi.com> Message-ID: <06445E55-15D8-4B2B-A764-5501E41A296F@toxicsoftware.com> I looked at parser but discounted it too soon. After a bit of playing I managed to get the following code to provide lists of class names and function names. Thanks Bob! Jon. #!/usr/bin/python import parser import symbol def find(inTuple, inSymbol): theClasses = [] if inTuple[0] == inSymbol: print 'FOUND' theClasses += [ inTuple[2][1] ] for theItem in inTuple[1:]: if type(theItem) == type(()): theClasses += find(theItem, inSymbol) return theClasses theSource = open('/Users/schwa/Desktop/Test.py').read() ast = parser.suite(theSource) tup = ast.totuple() print find(tup, symbol.classdef) print find(tup, symbol.funcdef) On May 10, 2005, at 21:52, Bob Ippolito wrote: > > On May 10, 2005, at 8:52 PM, Jonathan Wight wrote: > > >> I've made a first pass at it and have a Spotlight importer that calls >> a built-in Python function to import a file's metadata. >> >> I started to look at module inspect to find out how to extract >> information from a Python module but then realised that I'd need to >> import the file the importer is analysing. This would mean it will be >> executing arbitrary code inside that file. That's got to be a bad >> thing for security reasons. >> >> So instead I'm just going to have to use string processing to scan >> the file instead. Are there any modules out there for extracting >> information from Python script files? >> > > You want to use the parser module. > > -bob > > From Larry.A.Meyn at nasa.gov Wed May 11 04:35:43 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Tue, 10 May 2005 19:35:43 -0700 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <06445E55-15D8-4B2B-A764-5501E41A296F@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <08C75099-D097-4589-8CDB-A3E57F1D6AB1@toxicsoftware.com> <09AF8304-24CB-4977-AA6C-63AB4153F603@redivi.com> <06445E55-15D8-4B2B-A764-5501E41A296F@toxicsoftware.com> Message-ID: How about using pydoc as a starting point? It parses code and generates API documentation in XML or HTML. Larry On May 10, 2005, at 7:25 PM, Jonathan Wight wrote: > I looked at parser but discounted it too soon. After a bit of playing > I managed to get the following code to provide lists of class names > and function names. > > Thanks Bob! > > Jon. > > #!/usr/bin/python > > import parser > import symbol > > def find(inTuple, inSymbol): > theClasses = [] > if inTuple[0] == inSymbol: > print 'FOUND' > theClasses += [ inTuple[2][1] ] > for theItem in inTuple[1:]: > if type(theItem) == type(()): > theClasses += find(theItem, inSymbol) > return theClasses > > theSource = open('/Users/schwa/Desktop/Test.py').read() > ast = parser.suite(theSource) > tup = ast.totuple() > > print find(tup, symbol.classdef) > print find(tup, symbol.funcdef) > > > > On May 10, 2005, at 21:52, Bob Ippolito wrote: > >> >> On May 10, 2005, at 8:52 PM, Jonathan Wight wrote: >> >> >>> I've made a first pass at it and have a Spotlight importer that calls >>> a built-in Python function to import a file's metadata. >>> >>> I started to look at module inspect to find out how to extract >>> information from a Python module but then realised that I'd need to >>> import the file the importer is analysing. This would mean it will be >>> executing arbitrary code inside that file. That's got to be a bad >>> thing for security reasons. >>> >>> So instead I'm just going to have to use string processing to scan >>> the file instead. Are there any modules out there for extracting >>> information from Python script files? >>> >> >> You want to use the parser module. >> >> -bob >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From lee_cullens at mac.com Wed May 11 04:54:02 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 10 May 2005 22:54:02 -0400 Subject: [Pythonmac-SIG] Newbie.....sorry In-Reply-To: <22ce9c71cfa5fb7ca9b9155e48bf8c97@bostonmacosx.dyndns.org> References: <22ce9c71cfa5fb7ca9b9155e48bf8c97@bostonmacosx.dyndns.org> Message-ID: I'm not much more than a "newbie" than you, but start with: http:// pythonmac.org/packages/ I'm on Tiger ("clean" install from Panther) and working with Python 2.4 so my starting point was: MacPython-OSX-2.4.1-1.dmg TigerPython24Fix-r2.zip TigerPython23Compat.pkg If you can spend a few hours searching back through this forum you might get a better idea. HTH, Lee C On May 10, 2005, at 10:22 PM, RH wrote: > Ok so I decided to take the plunge into Python. > I'm a fairly advanced PHP developer and am now moving into Python as a > next step. > > I'm on Panther.... > > I just don't comprehend the packages you add into Python. > How can you list what packages are installed. > I downloaded the python extras and tried the package manager. > I constantly have to manually enter the URL for the plist and then I > don't see packages which I've installed such as Numeric. > > Can anyone explain the package procedure. I've read the wiki and the > FAQ and and still am out in the dark. > > Cheers, > > Robert > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From dreed at capital.edu Tue May 10 17:22:56 2005 From: dreed at capital.edu (Dave Reed) Date: Tue, 10 May 2005 11:22:56 -0400 Subject: [Pythonmac-SIG] spotlight and Python files Message-ID: I noticed Spotlight doesn't index Python files. I'm not certain how useful it would be but I was thinking about trying to get spotlight to index the name of classes and functions/methods (i.e., you could enter a class name and spotlight would find the Python file containing the class). I don't care if it does it on the fly as files are updated, but thought it would be nice to be able to run a Python script that would index all Python files in a directory. You could use the inspect module to grab the class/function/method names and tell spotlight to include them. I know there are some command line tools to interact with spotlight, but after a quick look at them, nothing jumped out at me for doing this. Is anyone interested in this (i.e., would you find it useful) and if so, does anyone understand Spotlight well enough to point me in the right direction (pointers to specific documentation are welcome). Thanks, Dave From lee_cullens at mac.com Wed May 11 05:05:09 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 10 May 2005 23:05:09 -0400 Subject: [Pythonmac-SIG] Newbie.....sorry In-Reply-To: <22ce9c71cfa5fb7ca9b9155e48bf8c97@bostonmacosx.dyndns.org> References: <22ce9c71cfa5fb7ca9b9155e48bf8c97@bostonmacosx.dyndns.org> Message-ID: <279716F6-B73D-4687-86B1-5CAA199CF7CF@mac.com> Oh, and forget package manager, Also see: http://undefined.org/python/ http://bob.pythonmac.org/archives/category/python/wxpython/ and anywhere else Bob has notes - just do your research before asking a question of him (his bark really is worse than his bite :~) > I'm not much more than a "newbie" than you, but start with: http:// > pythonmac.org/packages/ > > I'm on Tiger ("clean" install from Panther) and working with Python > 2.4 so my starting point was: > MacPython-OSX-2.4.1-1.dmg > TigerPython24Fix-r2.zip > TigerPython23Compat.pkg > > > If you can spend a few hours searching back through this forum you > might get a better idea. > > HTH, > Lee C > > > On May 10, 2005, at 10:22 PM, RH wrote: > > >> Ok so I decided to take the plunge into Python. >> I'm a fairly advanced PHP developer and am now moving into Python >> as a >> next step. >> >> I'm on Panther.... >> >> I just don't comprehend the packages you add into Python. >> How can you list what packages are installed. >> I downloaded the python extras and tried the package manager. >> I constantly have to manually enter the URL for the plist and then I >> don't see packages which I've installed such as Numeric. >> >> Can anyone explain the package procedure. I've read the wiki and the >> FAQ and and still am out in the dark. >> >> Cheers, >> >> Robert >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050510/03b93613/attachment.html From bob at redivi.com Wed May 11 08:20:45 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 11 May 2005 02:20:45 -0400 Subject: [Pythonmac-SIG] Newbie.....sorry In-Reply-To: <279716F6-B73D-4687-86B1-5CAA199CF7CF@mac.com> References: <22ce9c71cfa5fb7ca9b9155e48bf8c97@bostonmacosx.dyndns.org> <279716F6-B73D-4687-86B1-5CAA199CF7CF@mac.com> Message-ID: <5E9B4326-7474-4F43-B563-B393EE34EF57@redivi.com> On May 10, 2005, at 11:05 PM, Lee Cullens wrote: > Oh, and forget package manager, > Also see: > http://undefined.org/python/ > http://bob.pythonmac.org/archives/category/python/wxpython/ > and anywhere else Bob has notes - just do your research before > asking a question of him (his bark really is worse than his bite :~) http://bob.pythonmac.org/ is probably a more appropriate link to my blog than the *wxPython* category. In general, the entries are about 95% Python related, and the rest is Mac OS X related (i.e. new features in Safari, obscure UNIX API, etc.). All of the entries are relevant to software developers, and I don't waste space on politics or meatless links to elsewhere in the blogosphere. I only bother to mention this because very few entries are going to end up in the wxPython category, as I'm not currently very interested in it nor do I currently write/maintain any software that requires it. -bob From jwight_lists at toxicsoftware.com Wed May 11 08:28:20 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Wed, 11 May 2005 02:28:20 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> Message-ID: <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> OK. The first version is online at: http://toxicsoftware.com/_private/Python%20Metadata%20Importer.pkg.zip The installer installs the mdimporter to /Library/Spotlight/ and then calls mdimport -r to force Spotlight to reindex all Python files. You _may_ need Xcode installed to have this work successfully (Apple defines the "public.python-script" UTI type - and it _may_ be defined in Xcode - I need to check). This version scans through .py files looking for function names and class names. It adds them to the file's 'org_python_functions' and 'org_python_classes' metadata attributes respectively You can view the python specific metadata using mdls [schwa at cobweb] Python Metadata Importer$ mdls *.py myimporter.py ------------- kMDItemContentType = "public.python-script" ... other metadata not shown ... kMDItemKind = "Python Script" org_python_functions = (find, main) And find it using mdfind: [schwa at cobweb] Spotlight$ mdfind "org_python_functions == 'main'" | wc -l 41 You can also use the Finder to search for functions/classes: bring up a new search window, then choose "other?" in the attribute menu, in the attribute search window look for the keyword "Python"... It is quite impressive doing a search for python function names from the finder. The importer actually uses an embedded python interpreter to parse the python files (thanks to Bob for suggest the parser module). You can see the python file inside the Resources folder of the importer. The code currently leaks a few PyObjects so I'll be working on that in the next version. Currently I do not add anything to kMDItemTextContent or any other metadata attribute but this kind of stuff should be easy to do (just a one line change to the Python code). Any feedback quite welcome. Cheers. Jon. From konrad.hinsen at laposte.net Wed May 11 16:34:54 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Wed, 11 May 2005 16:34:54 +0200 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: <223A88B2-3B2F-4526-ABB7-9984524985DA@redivi.com> References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> <223A88B2-3B2F-4526-ABB7-9984524985DA@redivi.com> Message-ID: On May 10, 2005, at 19:21, Bob Ippolito wrote: >> My particularly good reason is that I set PYTHONPATH differently in >> different shell environments for testing purposes. Changing links and >> path >> files is a lot more work. > > I use different checkouts (or python interpreters) for different > environments... That's no so straightforward for me as my environment is mixed, Mac and Linux. Much of the code resides on a shared NFS partition. That's why I need the one feature that PYTHONPATH provides and that .pth files don't: environment variables in the path definitions. > Well I went ahead and changed the default behavior to ignore > PYTHONPATH. Great! > However, I still don't quite agree with you. There are PLENTY of > environment variables that you should only set if you know what you're > doing, and you should only set as a software developer. The DYLD > variables come to mind. Setting I even agree - but many others apparently don't. > A system administrator should never, ever, be setting PYTHONPATH. Most of the Unix machines I have worked on have PYTHONPATH set globally to something. I suppose the administrator's point of view is that Python is part of the system, users are not supposed to have their own installation. Which for most users is probably right. I don't know what the typical situation on the Mac is, but I tend to view the Mac as part of the big Unix family. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen at cea.fr --------------------------------------------------------------------- From dreedmac at columbus.rr.com Wed May 11 16:51:34 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Wed, 11 May 2005 10:51:34 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> Message-ID: On May 11, 2005, at 2:28 AM, Jonathan Wight wrote: > OK. The first version is online at: > > http://toxicsoftware.com/_private/Python%20Metadata%20Importer.pkg.zip > > The installer installs the mdimporter to /Library/Spotlight/ and > then calls mdimport -r to force Spotlight to reindex all Python files. > > You _may_ need Xcode installed to have this work successfully > (Apple defines the "public.python-script" UTI type - and it _may_ > be defined in Xcode - I need to check). > > This version scans through .py files looking for function names and > class names. It adds them to the file's 'org_python_functions' and > 'org_python_classes' metadata attributes respectively > > You can view the python specific metadata using mdls > > [schwa at cobweb] Python Metadata Importer$ mdls *.py > myimporter.py ------------- > kMDItemContentType = "public.python-script" > ... other metadata not shown ... > kMDItemKind = "Python Script" > org_python_functions = (find, main) > > And find it using mdfind: > > [schwa at cobweb] Spotlight$ mdfind "org_python_functions == 'main'" | > wc -l > 41 > > You can also use the Finder to search for functions/classes: bring > up a new search window, then choose "other?" in the attribute menu, > in the attribute search window look for the keyword "Python"... It > is quite impressive doing a search for python function names from > the finder. > > The importer actually uses an embedded python interpreter to parse > the python files (thanks to Bob for suggest the parser module). You > can see the python file inside the Resources folder of the > importer. The code currently leaks a few PyObjects so I'll be > working on that in the next version. > > Currently I do not add anything to kMDItemTextContent or any other > metadata attribute but this kind of stuff should be easy to do > (just a one line change to the Python code). > > Any feedback quite welcome. > > Cheers. > > Jon. Thanks for working on this. I'm not certain it is working correctly. I installed it about 3 hours ago so I would think it has had time to index my drive by now. It does seem to have indexed files that are part of python packages but it hasn't index Python files in my home directory and subdirectories. Is it skipping these on purpose or does it somehow not realize they are Python files (most of them were created with emacs and many on Linux systems before I switched to a Mac)? They all do have a .py extension. Also, how do you uninstall your plugin? I do have XCode installed. Dave From jwight_lists at toxicsoftware.com Wed May 11 17:06:39 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Wed, 11 May 2005 11:06:39 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> Message-ID: <2C2CB0C6-4F4B-4E02-B768-A7562343571D@toxicsoftware.com> It is entirely possible I screwed something up and that it doesn't work on anything other than my Powerbook ;-) However: As the last part of the install process the installer kicks off a script to reindex the Python files on the hard drive. This could be failing. To manually reindex runt this: mdimport -r /Library/Spotlight/Python\ Metadata\ Importer.mdimporter/ You should see a response like this: 2005-05-11 10:55:48.004 mdimport[21563] Asking server to reimport files with UTIs: ( "dyn.ah62d4rv4ge81a8k", "dyn.ah62d4rv4gq81k3p2su11upputf4gu55sfz30g6xmsb4a", "public.python-script" ) On my machine with 2748 python files indexable by Spotlight ( mdfind 'kMDItemContentType == "public.python-script' | wc -l ) it seems to take less than 5 minutes with 2 mdimport tasks running at between 30-70% CPU. Note that spotlight doesn't index Python.framework by default - so you'd need to configure that somehow (perhaps via the .Spotlight-V100 directory). To confirm that the Python mdimporter is working run mdimport against a python file (with classes & functions declared) with debugging turned on. You should see something like this, note that mdimport is using the Python mdimporter and that the 'org_python_functions' attribute is present in the output: mdimport -d 2 myimporter.py 2005-05-11 11:03:51.318 mdimport[21650] Import '/Volumes/Home/Users/ schwa/Desktop/Python Metadata Importer/myimporter.py' type 'public.python-script' using 'file://localhost/Library/Spotlight/ Python%20Metadata%20Importer.mdimporter/' 2005-05-11 11:03:51.622 mdimport[21650] Done. 2005-05-11 11:03:51.624 mdimport[21650] Sending attributes of '/ Volumes/Home/Users/schwa/Desktop/Python Metadata Importer/ myimporter.py' to server. Attributes: '{ "com_apple_metadata_modtime" = 137481386; kMDItemContentCreationDate = "2005-05-11 00:03:18 -0400"; kMDItemContentModificationDate = "2005-05-11 01:16:26 -0400"; kMDItemContentType = "public.python-script"; kMDItemContentTypeTree = ( "public.python-script", "public.shell-script", "public.script", "public.source-code", "public.plain-text", "public.text", "public.data", "public.item", "public.content" ); kMDItemDisplayName = {"" = "myimporter.py"; }; kMDItemKind = {"" = "Python Script"; }; "org_python_classes" = (); "org_python_functions" = (find, main); Let me know if this works. Jon. On May 11, 2005, at 10:51, David Reed wrote: > Thanks for working on this. I'm not certain it is working > correctly. I installed it about 3 hours ago so I would think it has > had time to index my drive by now. It does seem to have indexed > files that are part of python packages but it hasn't index Python > files in my home directory and subdirectories. Is it skipping these > on purpose or does it somehow not realize they are Python files > (most of them were created with emacs and many on Linux systems > before I switched to a Mac)? They all do have a .py extension. > > Also, how do you uninstall your plugin? > > I do have XCode installed. From Benjamin.Schollnick at xerox.com Wed May 11 17:16:06 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Wed, 11 May 2005 11:16:06 -0400 Subject: [Pythonmac-SIG] Spotlight and Python Message-ID: <266589E1B9392B4C9195CC25A07C73B9AA508E@usa0300ms04.na.xerox.net> Jon, One important issue... > > had time to index my drive by now. It does seem to have indexed > > files that are part of python packages but it hasn't index Python > > files in my home directory and subdirectories. Is it > skipping these > > on purpose or does it somehow not realize they are Python files > > (most of them were created with emacs and many on Linux systems > > before I switched to a Mac)? They all do have a .py extension. So, to summarize... 1) It has indexed files that are part of Python packages 2) It has not indexed files in his home directory a) Most were created with Emacs / Linux systems So the UTI for python files may not be attached to those files MetaData.... Could that be preventing the indexer from operating? - Benjamin > -----Original Message----- > From: pythonmac-sig-bounces at python.org > [mailto:pythonmac-sig-bounces at python.org] On Behalf Of Jonathan Wight > Sent: Wednesday, May 11, 2005 11:07 AM > To: David Reed > Cc: PythonMac > Subject: Re: [Pythonmac-SIG] Spotlight and Python > > > It is entirely possible I screwed something up and that it doesn't > work on anything other than my Powerbook ;-) > > However: > > As the last part of the install process the installer kicks off a > script to reindex the Python files on the hard drive. This could be > failing. To manually reindex runt this: > > mdimport -r /Library/Spotlight/Python\ Metadata\ Importer.mdimporter/ > > You should see a response like this: > > 2005-05-11 10:55:48.004 mdimport[21563] Asking server to reimport > files with UTIs: ( > "dyn.ah62d4rv4ge81a8k", > "dyn.ah62d4rv4gq81k3p2su11upputf4gu55sfz30g6xmsb4a", > "public.python-script" > ) > > On my machine with 2748 python files indexable by Spotlight ( mdfind > 'kMDItemContentType == "public.python-script' | wc -l ) it seems to > take less than 5 minutes with 2 mdimport tasks running at between > 30-70% CPU. > > Note that spotlight doesn't index Python.framework by default - so > you'd need to configure that somehow (perhaps via the > .Spotlight-V100 > directory). > > To confirm that the Python mdimporter is working run mdimport > against > a python file (with classes & functions declared) with debugging > turned on. You should see something like this, note that mdimport is > using the Python mdimporter and that the 'org_python_functions' > attribute is present in the output: > > mdimport -d 2 myimporter.py > > 2005-05-11 11:03:51.318 mdimport[21650] Import '/Volumes/Home/Users/ > schwa/Desktop/Python Metadata Importer/myimporter.py' type > 'public.python-script' using 'file://localhost/Library/Spotlight/ > Python%20Metadata%20Importer.mdimporter/' > 2005-05-11 11:03:51.622 mdimport[21650] Done. > 2005-05-11 11:03:51.624 mdimport[21650] Sending attributes of '/ > Volumes/Home/Users/schwa/Desktop/Python Metadata Importer/ > myimporter.py' to server. Attributes: '{ > "com_apple_metadata_modtime" = 137481386; > kMDItemContentCreationDate = "2005-05-11 00:03:18 -0400"; > kMDItemContentModificationDate = "2005-05-11 01:16:26 -0400"; > kMDItemContentType = "public.python-script"; > kMDItemContentTypeTree = ( > "public.python-script", > "public.shell-script", > "public.script", > "public.source-code", > "public.plain-text", > "public.text", > "public.data", > "public.item", > "public.content" > ); > kMDItemDisplayName = {"" = "myimporter.py"; }; > kMDItemKind = {"" = "Python Script"; }; > "org_python_classes" = (); > "org_python_functions" = (find, main); > > Let me know if this works. > > Jon. > > On May 11, 2005, at 10:51, David Reed wrote: > > > Thanks for working on this. I'm not certain it is working > > correctly. I installed it about 3 hours ago so I would > think it has > > had time to index my drive by now. It does seem to have indexed > > files that are part of python packages but it hasn't index Python > > files in my home directory and subdirectories. Is it > skipping these > > on purpose or does it somehow not realize they are Python files > > (most of them were created with emacs and many on Linux systems > > before I switched to a Mac)? They all do have a .py extension. > > > > Also, how do you uninstall your plugin? > > > > I do have XCode installed. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From jwight_lists at toxicsoftware.com Wed May 11 17:23:53 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Wed, 11 May 2005 11:23:53 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <266589E1B9392B4C9195CC25A07C73B9AA508E@usa0300ms04.na.xerox.net> References: <266589E1B9392B4C9195CC25A07C73B9AA508E@usa0300ms04.na.xerox.net> Message-ID: <85E93D74-EA46-4DD2-B3CC-872C886F6FB2@toxicsoftware.com> On May 11, 2005, at 11:16, Schollnick, Benjamin wrote: >>> had time to index my drive by now. It does seem to have indexed >>> files that are part of python packages but it hasn't index Python >>> files in my home directory and subdirectories. Is it >>> >> skipping these >> >>> on purpose or does it somehow not realize they are Python files >>> (most of them were created with emacs and many on Linux systems >>> before I switched to a Mac)? They all do have a .py extension. >>> > > So, to summarize... > > 1) It has indexed files that are part of Python packages > 2) It has not indexed files in his home directory > a) Most were created with Emacs / Linux systems > > So the UTI for python files may not be attached to those files > MetaData.... > > Could that be preventing the indexer from operating? I'd be surprised. The python UTI declaration is in the system (not in Xcode as I originally believed) and it looks like this: UTTypeConformsTo public.shell-script UTTypeDescription Python script UTTypeIdentifier public.python-script UTTypeTagSpecification public.filename-extension py public.mime-type text/x-python-script So basically anything with a .py extension should be indexed. Use mdls and mdfind to find out files are not being indexed. Jon. From jwight_lists at toxicsoftware.com Wed May 11 17:24:50 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Wed, 11 May 2005 11:24:50 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> Message-ID: On May 11, 2005, at 10:51, David Reed wrote: > Also, how do you uninstall your plugin? Remove "Python Metadata Importer.mdimporter" from /Library/Spotlight From bob at redivi.com Wed May 11 18:26:43 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 11 May 2005 12:26:43 -0400 Subject: [Pythonmac-SIG] (no subject) In-Reply-To: References: <9222e8a58a32a066df0aaed3c21f3d75@laposte.net> <62c8da0fd7d3880918494cc2d21cf2df@laposte.net> <2D32A4D6-8D55-4893-BE43-A8C901C64A2D@redivi.com> <20050510091423.9EB907875B@dirac.cnrs-orleans.fr> <223A88B2-3B2F-4526-ABB7-9984524985DA@redivi.com> Message-ID: On May 11, 2005, at 10:34 AM, konrad.hinsen at laposte.net wrote: > On May 10, 2005, at 19:21, Bob Ippolito wrote: > >> A system administrator should never, ever, be setting PYTHONPATH. >> > > Most of the Unix machines I have worked on have PYTHONPATH set > globally > to something. I suppose the administrator's point of view is that > Python is part of the system, users are not supposed to have their own > installation. Which for most users is probably right. I have never seen this. There's really no reason to do it, a sysadmin can do what they need to do to site-packages. That's what it's there for. > I don't know what the typical situation on the Mac is, but I tend to > view the Mac as part of the big Unix family. It's the same except when it's not :) This is one of the cases where it's not really, because environment variables don't carry over to the GUI unless you try particularly hard. -bob From dreedmac at columbus.rr.com Wed May 11 19:21:22 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Wed, 11 May 2005 13:21:22 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <2C2CB0C6-4F4B-4E02-B768-A7562343571D@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> <2C2CB0C6-4F4B-4E02-B768-A7562343571D@toxicsoftware.com> Message-ID: <0073D131-2519-4502-A990-1E7B563C90D4@columbus.rr.com> On May 11, 2005, at 11:06 AM, Jonathan Wight wrote: > It is entirely possible I screwed something up and that it doesn't > work on anything other than my Powerbook ;-) > > However: > > As the last part of the install process the installer kicks off a > script to reindex the Python files on the hard drive. This could be > failing. To manually reindex runt this: > > mdimport -r /Library/Spotlight/Python\ Metadata\ Importer.mdimporter/ > > You should see a response like this: > > 2005-05-11 10:55:48.004 mdimport[21563] Asking server to reimport > files with UTIs: ( > "dyn.ah62d4rv4ge81a8k", > "dyn.ah62d4rv4gq81k3p2su11upputf4gu55sfz30g6xmsb4a", > "public.python-script" > ) > > On my machine with 2748 python files indexable by Spotlight > ( mdfind 'kMDItemContentType == "public.python-script' | wc -l ) it > seems to take less than 5 minutes with 2 mdimport tasks running at > between 30-70% CPU. > > Note that spotlight doesn't index Python.framework by default - so > you'd need to configure that somehow (perhaps via the .Spotlight- > V100 directory). > > To confirm that the Python mdimporter is working run mdimport > against a python file (with classes & functions declared) with > debugging turned on. You should see something like this, note that > mdimport is using the Python mdimporter and that the > 'org_python_functions' attribute is present in the output: > > mdimport -d 2 myimporter.py > > 2005-05-11 11:03:51.318 mdimport[21650] Import '/Volumes/Home/Users/ > schwa/Desktop/Python Metadata Importer/myimporter.py' type > 'public.python-script' using 'file://localhost/Library/Spotlight/ > Python%20Metadata%20Importer.mdimporter/' > 2005-05-11 11:03:51.622 mdimport[21650] Done. > 2005-05-11 11:03:51.624 mdimport[21650] Sending attributes of '/ > Volumes/Home/Users/schwa/Desktop/Python Metadata Importer/ > myimporter.py' to server. Attributes: '{ > "com_apple_metadata_modtime" = 137481386; > kMDItemContentCreationDate = "2005-05-11 00:03:18 -0400"; > kMDItemContentModificationDate = "2005-05-11 01:16:26 -0400"; > kMDItemContentType = "public.python-script"; > kMDItemContentTypeTree = ( > "public.python-script", > "public.shell-script", > "public.script", > "public.source-code", > "public.plain-text", > "public.text", > "public.data", > "public.item", > "public.content" > ); > kMDItemDisplayName = {"" = "myimporter.py"; }; > kMDItemKind = {"" = "Python Script"; }; > "org_python_classes" = (); > "org_python_functions" = (find, main); > > Let me know if this works. > > Jon. > It doesn't appear to be working: 510 mac:~/src/CS160/ImageMessage $ mdimport -d 2 bits.py 2005-05-11 13:17:48.498 mdimport[3670] Import '/Users/dreed/src/CS160/ ImageMessage/bits.py' type 'public.python-script' using 'file:// localhost/Library/Spotlight/Python%20Metadata%20Importer.mdimporter/' 2005-05-11 13:17:48.879 mdimport[3670] -[FileProcessor importMetadataFromFileAtP???? ??ot exception Conversion to encoding 30 failed for string "? 2005-05-11 13:17:48.897 mdimport[3670] Import '/Users/dreed/src/CS160/ ImageMessage/bits.py' type 'public.python-script' no mdimporter 2005-05-11 13:17:48.900 mdimport[3670] Sending attributes of '/Users/ dreed/src/CS160/ImageMessage/bits.py' to server. Attributes: '{ "_kMDItemImporterCrashed" = 1; "com_apple_metadata_modtime" = 137504114; kMDItemContentCreationDate = 2005-05-11 07:35:14 -0400; kMDItemContentModificationDate = 2005-05-11 07:35:14 -0400; kMDItemContentType = "public.python-script"; kMDItemContentTypeTree = ( "public.python-script", "public.shell-script", "public.script", "public.source-code", "public.plain-text", "public.text", "public.data", "public.item", "public.content" ); kMDItemDisplayName = {"" = "bits.py"; }; kMDItemKind = { "" = PlainTextType; ca = "Fitxer de Text Planer"; da = "Almindeligt tekstdokument"; de = "Reine Text-Datei"; en = "Plain Text File"; fr = "Fichier texte brut"; ja = "\U6a19\U6e96\U30c6\U30ad\U30b9\U30c8\U66f8\U985e"; ko = "\Uc77c\Ubc18 \Ud14d\Uc2a4\Ud2b8 \Ud30c\Uc77c"; ru = "\U041f\U0440\U043e\U0441\U0442\U043e\U0439 \U0442\U0435 \U043a\U0441\U0442"; "zh-Hant" = "\U7d14\U6587\U5b57\U6a94"; }; }' The bits.py file is just: #!/usr/bin/env python #---------------------------------------------------------------------- # bits.py # Dave Reed # 05/09/2005 #---------------------------------------------------------------------- def get_bits(value, n=8): '''get_bits(value, n): generator to return individual bits in a value of n bits''' pos_value = 2 ** (n-1) # if a single character string, convert to ASCII code try: value = ord(value) except: pass # for each bit for i in range(n): # get bit n bit = value & pos_value # shift so we can get next bit value = value << 1 # if bit is pos_value, that bit was 1 if bit == pos_value: yield 1 else: yield 0 #---------------------------------------------------------------------- def set_lsb(x, b): '''set_lsb(x, b): returns x with lsb of x set to b (b is 0 or 1)''' return (x & 254) | b #---------------------------------------------------------------------- def get_lsb(x): '''get_lsb(x): returns lsb of x (0 or 1)''' return x & 1 #---------------------------------------------------------------------- def value_from_bits(bits): '''value_from_bits(bits): takes a sequence of bit values (each item is 0 or 1) and returns the integer corresponding to that sequence''' value = 0 for b in bits: value = 2 * value + b return value #---------------------------------------------------------------------- Dave From jwight_lists at toxicsoftware.com Wed May 11 20:12:48 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Wed, 11 May 2005 14:12:48 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <0073D131-2519-4502-A990-1E7B563C90D4@columbus.rr.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> <2C2CB0C6-4F4B-4E02-B768-A7562343571D@toxicsoftware.com> <0073D131-2519-4502-A990-1E7B563C90D4@columbus.rr.com> Message-ID: <4449F415-37EF-4596-B5DF-28A31E043FB6@toxicsoftware.com> For me it worked: "org_python_functions" = ("get_bits", "set_lsb", "get_lsb", "value_from_bits"); But then I just made a new BBEdit Bits.py file and pasted your code into it. The importer does seem to be crashing, but I'm not sure whether the python or the ObjC is dying. Is there a crash log in either ~/Library/ Logs/Crash Logs or /Library/Logs/Crash Logs. I'm working on version 0.2 with slightly better error handling and a lot less leaking of PyObject pointers. Jon. On May 11, 2005, at 13:21, David Reed wrote: > It doesn't appear to be working: > > 510 mac:~/src/CS160/ImageMessage $ mdimport -d 2 bits.py > 2005-05-11 13:17:48.498 mdimport[3670] Import '/Users/dreed/src/ > CS160/ImageMessage/bits.py' type 'public.python-script' using > 'file://localhost/Library/Spotlight/Python%20Metadata% > 20Importer.mdimporter/' > 2005-05-11 13:17:48.879 mdimport[3670] -[FileProcessor > importMetadataFromFileAtP???? ??ot exception Conversion to encoding > 30 failed for string "? > 2005-05-11 13:17:48.897 mdimport[3670] Import '/Users/dreed/src/ > CS160/ImageMessage/bits.py' type 'public.python-script' no mdimporter > 2005-05-11 13:17:48.900 mdimport[3670] Sending attributes of '/ > Users/dreed/src/CS160/ImageMessage/bits.py' to server. Attributes: '{ > "_kMDItemImporterCrashed" = 1; > "com_apple_metadata_modtime" = 137504114; > kMDItemContentCreationDate = 2005-05-11 07:35:14 -0400; > kMDItemContentModificationDate = 2005-05-11 07:35:14 -0400; > kMDItemContentType = "public.python-script"; > kMDItemContentTypeTree = ( > "public.python-script", > "public.shell-script", > "public.script", > "public.source-code", > "public.plain-text", > "public.text", > "public.data", > "public.item", > "public.content" > ); > kMDItemDisplayName = {"" = "bits.py"; }; > kMDItemKind = { > "" = PlainTextType; > ca = "Fitxer de Text Planer"; > da = "Almindeligt tekstdokument"; > de = "Reine Text-Datei"; > en = "Plain Text File"; > fr = "Fichier texte brut"; > ja = "\U6a19\U6e96\U30c6\U30ad\U30b9\U30c8\U66f8\U985e"; > ko = "\Uc77c\Ubc18 \Ud14d\Uc2a4\Ud2b8 \Ud30c\Uc77c"; > ru = "\U041f\U0440\U043e\U0441\U0442\U043e\U0439 \U0442 > \U0435\U043a\U0441\U0442"; > "zh-Hant" = "\U7d14\U6587\U5b57\U6a94"; > }; > }' > > > The bits.py file is just: > > #!/usr/bin/env python > > #--------------------------------------------------------------------- > - > # bits.py > # Dave Reed > # 05/09/2005 > #--------------------------------------------------------------------- > - > > def get_bits(value, n=8): > > '''get_bits(value, n): > > generator to return individual bits in a value of n bits''' > > pos_value = 2 ** (n-1) > > # if a single character string, convert to ASCII code > try: > value = ord(value) > except: > pass > > # for each bit > for i in range(n): > # get bit n > bit = value & pos_value > # shift so we can get next bit > value = value << 1 > # if bit is pos_value, that bit was 1 > if bit == pos_value: > yield 1 > else: > yield 0 > > #--------------------------------------------------------------------- > - > > def set_lsb(x, b): > > '''set_lsb(x, b): > > returns x with lsb of x set to b (b is 0 or 1)''' > > return (x & 254) | b > > #--------------------------------------------------------------------- > - > > def get_lsb(x): > > '''get_lsb(x): > > returns lsb of x (0 or 1)''' > > return x & 1 > > #--------------------------------------------------------------------- > - > > def value_from_bits(bits): > > '''value_from_bits(bits): > > takes a sequence of bit values (each item is 0 or 1) and > returns the > integer corresponding to that sequence''' > > value = 0 > for b in bits: > value = 2 * value + b > return value > > #--------------------------------------------------------------------- > - > > > Dave > > > From dreedmac at columbus.rr.com Wed May 11 20:36:38 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Wed, 11 May 2005 14:36:38 -0400 Subject: [Pythonmac-SIG] Spotlight and Python In-Reply-To: <4449F415-37EF-4596-B5DF-28A31E043FB6@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> <2C2CB0C6-4F4B-4E02-B768-A7562343571D@toxicsoftware.com> <0073D131-2519-4502-A990-1E7B563C90D4@columbus.rr.com> <4449F415-37EF-4596-B5DF-28A31E043FB6@toxicsoftware.com> Message-ID: On May 11, 2005, at 2:12 PM, Jonathan Wight wrote: > For me it worked: > > "org_python_functions" = ("get_bits", "set_lsb", "get_lsb", > "value_from_bits"); > > But then I just made a new BBEdit Bits.py file and pasted your code > into it. > > The importer does seem to be crashing, but I'm not sure whether the > python or the ObjC is dying. Is there a crash log in either ~/ > Library/Logs/Crash Logs or /Library/Logs/Crash Logs. > > I'm working on version 0.2 with slightly better error handling and > a lot less leaking of PyObject pointers. > > Jon. > I have a CrashReporter subdir, but not Crash Logs. I see this in the console repeated for a bunch of the OpenGL files: May 11 14:30:56 David-Reeds-Computer mdimportserver[3772]: - [FileProcessor importMetadataFromFileAtPath:] Got exception Conversion to encoding 30 failed for string "?? ??? ??" for path '/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/OpenGL/GL/Autodesk/facet_normal.py' May 11 14:30:56 David-Reeds-Computer mdimportserver[3772]: - [FileProcessor importMetadataFromFileAtPath:] Got exception Conversion to encoding 30 failed for string "?? ??? ??" for path '/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/OpenGL/GL/Autodesk/valid_back_buffer_hint.py' May 11 14:30:56 David-Reeds-Computer mdimportserver[3772]: - [FileProcessor importMetadataFromFileAtPath:] Got exception Conversion to encoding 30 failed for string "?? ??? ??" for path '/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/OpenGL/GL/EXT/_422_pixels.py' May 11 14:30:56 David-Reeds-Computer mdimportserver[3772]: - [FileProcessor importMetadataFromFileAtPath:] Got exception Conversion to encoding 30 failed for string "?? ??? ??" for path '/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/OpenGL/GL/EXT/__init__.py' And then this going on forever: May 11 14:35:45 David-Reeds-Computer mdimportserver[3774]: Done. I'm going to reboot after sending this. I did delete and reinstall your file, but that didn't help. Guess I'll just wait for the next version and try again. Thanks, Dave From rswerdlow at goombah.com Thu May 12 18:50:20 2005 From: rswerdlow at goombah.com (Bob Swerdlow) Date: Thu, 12 May 2005 12:50:20 -0400 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar Message-ID: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> I'm getting an ImportError trying to import WebKit. My configuration is Jaguar with PyObjC 1.2. I have Safari 1.0.3 installed. As far as I can tell from looking at the PyObjC pages, this should work. Where should I find the WebKit module on my machine? Where can I get the WebKit module if is not there? Thanks, Bob From dangoor at gmail.com Thu May 12 21:10:52 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Thu, 12 May 2005 15:10:52 -0400 Subject: [Pythonmac-SIG] EasyDialogs and py2app Message-ID: <3f085ecd050512121079c9bcea@mail.gmail.com> I have an application that uses EasyDialogs and is packaged up with py2app. When I run it, it seems to have trouble finding dialogs.rsrc: File "EasyDialogs.pyc", line 193, in AskYesNoCancel File "EasyDialogs.pyc", line 49, in _initialize File "macresource.pyc", line 63, in need macresource.ResourceFileNotFoundError: dialogs.rsrc I'm using my own Python 2.4 framework build. Should I have to do anything to be sure that this file is included? What's the *right* way to point to the file in my setup? Thanks, Kevin From dangoor at gmail.com Thu May 12 21:18:40 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Thu, 12 May 2005 15:18:40 -0400 Subject: [Pythonmac-SIG] EasyDialogs and py2app In-Reply-To: <3f085ecd050512121079c9bcea@mail.gmail.com> References: <3f085ecd050512121079c9bcea@mail.gmail.com> Message-ID: <3f085ecd050512121828f49315@mail.gmail.com> I should clarify: when I ask "what's the right way to point to the file", I mean rather than hardcoding the path to the file in my Python installation, if anyone knows the correct way to get the file path in Python code. (I could do something like EasyDialogs.__file__ and then grab the directory from there) Kevin On 5/12/05, Kevin Dangoor wrote: > I have an application that uses EasyDialogs and is packaged up with > py2app. When I run it, it seems to have trouble finding dialogs.rsrc: > > File "EasyDialogs.pyc", line 193, in AskYesNoCancel > File "EasyDialogs.pyc", line 49, in _initialize > File "macresource.pyc", line 63, in need > macresource.ResourceFileNotFoundError: dialogs.rsrc > > I'm using my own Python 2.4 framework build. Should I have to do > anything to be sure that this file is included? What's the *right* way > to point to the file in my setup? > > Thanks, > Kevin > From lists at mostrom.pp.se Thu May 12 22:40:07 2005 From: lists at mostrom.pp.se (Jan Erik =?iso-8859-1?Q?Mostr=F6m?=) Date: Thu, 12 May 2005 22:40:07 +0200 Subject: [Pythonmac-SIG] SQLite Message-ID: For various reasons I've always just used the standard installation of python, never installed any non-standard stuff, etc. But now I would like to be able to use SQLite together with python (on Tiger), what is the best way to do this? I've looked around a bit and found the pysqlite project, is this the best way for as a Mac user or should I use some other stuff? jem -- Jan Erik Mostr?m, www.mostrom.pp.se From qdecavel at nordnet.fr Thu May 12 23:15:32 2005 From: qdecavel at nordnet.fr (Quentin DECAVEL) Date: Thu, 12 May 2005 22:15:32 +0100 Subject: [Pythonmac-SIG] Problem with a py2app bundle Message-ID: <20050512211532.M33846@nordnet.fr> Hi again, I have compiled pygame 1.6.2 from source on my OS X.2, and then tried again py2app. The created application is working fine, but each time I try to launch a movie the app quits. The error message tells me that a module is missing: 2005-05-12 23:01:36.303 Greenhouse[480] Greenhouse Error 2005-05-12 23:01:36.304 Greenhouse[480] An unexpected error has occurred during execution of the main script NotImplementedError: movieext module not available Is there a way to correct it ? In the src folder the movieext.c is present, so I assume this is a matter of adding the file name in some configuration file before the compilation, but which one ? Thanks in advance From sw at wordtech-software.com Thu May 12 23:55:15 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu, 12 May 2005 17:55:15 -0400 Subject: [Pythonmac-SIG] Recursion limit in OS X? Message-ID: <4283D0C3.80300@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm working on a port of Boa Constructor to OS X and one of the most common problems (reported often to the main developer) of Boa on the Mac is recursion limits. The application, when opening or saving a file, freezes and crashes frequently, while outputting a message like this: "runtime error: recursion limit exceeded." This is what I've observed as well. While I don't get similar output from the other programs I maintain, including SPE, wxGlade and Eric3, the behavior is similar. I ran across this thread: http://lists.osafoundation.org/pipermail/commits/2005-February/003813.html which indicates to me that conflicts between recursion limits in Python and OS X are a known, documented issue. Does anyone have experience in dealing with this issue? Any workarounds? ~ I'm very interested in working through/around this so that the apps I maintain are actually usable. :-) - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCg9DDJmdQs+6YVcoRApGDAKCEdTo6O5hBR28Qgqf5vTyeZyZhnACfXP8s m6X2XBgz5nqbI5IEdie2bNk= =No36 -----END PGP SIGNATURE----- From skip at pobox.com Fri May 13 00:27:04 2005 From: skip at pobox.com (Skip Montanaro) Date: Thu, 12 May 2005 17:27:04 -0500 Subject: [Pythonmac-SIG] Recursion limit in OS X? In-Reply-To: <4283D0C3.80300@wordtech-software.com> References: <4283D0C3.80300@wordtech-software.com> Message-ID: <17027.55352.566620.597063@montanaro.dyndns.org> Kevin> I ran across this thread: Kevin> http://lists.osafoundation.org/pipermail/commits/2005-February/003813.html Kevin> which indicates to me that conflicts between recursion limits in Kevin> Python and OS X are a known, documented issue. % grep ulimit ~/.bash_profile ulimit -s 8192 Works for me at least. Skip From bob at redivi.com Fri May 13 02:07:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 12 May 2005 20:07:59 -0400 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar In-Reply-To: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> References: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> Message-ID: On May 12, 2005, at 12:50 PM, Bob Swerdlow wrote: > I'm getting an ImportError trying to import WebKit. My > configuration is > Jaguar with PyObjC 1.2. I have Safari 1.0.3 installed. As far as > I can > tell from looking at the PyObjC pages, this should work. > > Where should I find the WebKit module on my machine? Where can I > get the > WebKit module if is not there? You need to install the Safari SDK from in order for the WebKit wrapper to be built. I don't know whether or not the 1.2 distribution for Jaguar shipped with a wrapper or not.. without an ImportError to look at I wouldn't know. Jaguar isn't currently supported in PyObjC, but it might still work. I highly recommend trying it from svn trunk instead. -bob From bob at redivi.com Fri May 13 02:12:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 12 May 2005 20:12:07 -0400 Subject: [Pythonmac-SIG] EasyDialogs and py2app In-Reply-To: <3f085ecd050512121828f49315@mail.gmail.com> References: <3f085ecd050512121079c9bcea@mail.gmail.com> <3f085ecd050512121828f49315@mail.gmail.com> Message-ID: I'll put some hooks into py2app 0.2 to pick these up.. but: from distutils.core import setup import py2app import os import EasyDialogs plat_mac = os.path.dirname(EasyDialogs.__file__) rsrcFile = os.path.join(plat_mac, 'dialogs.rsrc') setup( data_files=[rsrcFile], ... ) On May 12, 2005, at 3:18 PM, Kevin Dangoor wrote: > I should clarify: when I ask "what's the right way to point to the > file", I mean rather than hardcoding the path to the file in my Python > installation, if anyone knows the correct way to get the file path in > Python code. (I could do something like EasyDialogs.__file__ and then > grab the directory from there) > > Kevin > > On 5/12/05, Kevin Dangoor wrote: > >> I have an application that uses EasyDialogs and is packaged up with >> py2app. When I run it, it seems to have trouble finding dialogs.rsrc: >> >> File "EasyDialogs.pyc", line 193, in AskYesNoCancel >> File "EasyDialogs.pyc", line 49, in _initialize >> File "macresource.pyc", line 63, in need >> macresource.ResourceFileNotFoundError: dialogs.rsrc >> >> I'm using my own Python 2.4 framework build. Should I have to do >> anything to be sure that this file is included? What's the *right* >> way >> to point to the file in my setup? >> >> Thanks, >> Kevin >> >> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Fri May 13 02:14:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 12 May 2005 20:14:54 -0400 Subject: [Pythonmac-SIG] SQLite In-Reply-To: References: Message-ID: On May 12, 2005, at 4:40 PM, Jan Erik Mostr?m wrote: > For various reasons I've always just used the standard installation of > python, never installed any non-standard stuff, etc. > > But now I would like to be able to use SQLite together with python (on > Tiger), what is the best way to do this? > > I've looked around a bit and found the pysqlite project, is this the > best way for as a Mac user or should I use some other stuff? > pysqlite and APSW packages are available from http://pythonmac.org/ packages/ For the standard Python, you will need to first install TigerPython23Compat, and then you should install the APSW and/or pysqlite packages under the Mac OS X 10.3 (stock Python 2.3.0) heading. -bob From bob at redivi.com Fri May 13 02:17:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 12 May 2005 20:17:26 -0400 Subject: [Pythonmac-SIG] Problem with a py2app bundle In-Reply-To: <20050512211532.M33846@nordnet.fr> References: <20050512211532.M33846@nordnet.fr> Message-ID: On May 12, 2005, at 5:15 PM, Quentin DECAVEL wrote: > I have compiled pygame 1.6.2 from source on my OS X.2, and then > tried again > py2app. The created application is working fine, but each time I > try to launch > a movie the app quits. The error message tells me that a module is > missing: > > Don't use 1.6.2, use 1.7 (precompiled at http://pythonmac.org/ packages/) or compile from CVS yourself. > 2005-05-12 23:01:36.303 Greenhouse[480] Greenhouse Error > > 2005-05-12 23:01:36.304 Greenhouse[480] An unexpected error has > occurred > during execution of the main script > > NotImplementedError: movieext module not available > > Is there a way to correct it ? In the src folder the movieext.c is > present, so > I assume this is a matter of adding the file name in some > configuration file > before the compilation, but which one ? > > No, movieext is not a supported extension. It's not really available anywhere and it never compiles without jiggering Setup.in. It probably won't be around much longer. [from Setup.in] #experimental new movie movie. requires libavcodec and libavformat. #add any necessary compile flags to this line and uncomment. #movieext src/movie.c src/ffmovie.c $(SDL) -lavcodec -lavformat -bob From dangoor at gmail.com Fri May 13 03:51:54 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Thu, 12 May 2005 21:51:54 -0400 Subject: [Pythonmac-SIG] EasyDialogs and py2app In-Reply-To: References: <3f085ecd050512121079c9bcea@mail.gmail.com> <3f085ecd050512121828f49315@mail.gmail.com> Message-ID: <3f085ecd050512185165b0eb54@mail.gmail.com> Thanks! That's what I figured, but I wanted to be sure I wasn't missnig something. On 5/12/05, Bob Ippolito wrote: > I'll put some hooks into py2app 0.2 to pick these up.. but: > > from distutils.core import setup > import py2app > import os > import EasyDialogs > plat_mac = os.path.dirname(EasyDialogs.__file__) > rsrcFile = os.path.join(plat_mac, 'dialogs.rsrc') > setup( > data_files=[rsrcFile], > ... > ) > > On May 12, 2005, at 3:18 PM, Kevin Dangoor wrote: > > > I should clarify: when I ask "what's the right way to point to the > > file", I mean rather than hardcoding the path to the file in my Python > > installation, if anyone knows the correct way to get the file path in > > Python code. (I could do something like EasyDialogs.__file__ and then > > grab the directory from there) > > > > Kevin > > > > On 5/12/05, Kevin Dangoor wrote: > > > >> I have an application that uses EasyDialogs and is packaged up with > >> py2app. When I run it, it seems to have trouble finding dialogs.rsrc: > >> > >> File "EasyDialogs.pyc", line 193, in AskYesNoCancel > >> File "EasyDialogs.pyc", line 49, in _initialize > >> File "macresource.pyc", line 63, in need > >> macresource.ResourceFileNotFoundError: dialogs.rsrc > >> > >> I'm using my own Python 2.4 framework build. Should I have to do > >> anything to be sure that this file is included? What's the *right* > >> way > >> to point to the file in my setup? > >> > >> Thanks, > >> Kevin > >> > >> > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > From jwight_lists at toxicsoftware.com Fri May 13 06:43:37 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Fri, 13 May 2005 00:43:37 -0400 Subject: [Pythonmac-SIG] [Pythonmac-SIG] Spotlight and Python In-Reply-To: <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> References: <2517EB5C-D4C5-4AB8-B95D-A877E4FF176A@jacobian.org> <4F2F2D64-38AA-473D-9999-0930073C044D@toxicsoftware.com> <4CC41EFF-B708-41ED-83B5-E10A524B4E98@toxicsoftware.com> Message-ID: <0CD67E0D-0CBC-4048-8EB8-4F0F1C1D2DB5@toxicsoftware.com> Version 0.7 is now online at: http://toxicsoftware.com/_private/Python%20Metadata%20Importer/Version %200.7/Python%20Metadata%20Importer.dmg Thanks to David Reed for helping me test and iron out the Unicode problems. This version should work for pretty much anyone (famous last words). I've added added support for Unicode data, NSDate support, more robust error handling. I'm going to add support for file level PythonDoc comments and for the file level python metadata (__author__, __date__ and so on) in the next version. I'll be putting the code online soon. Jon. On May 11, 2005, at 02:28, Jonathan Wight wrote: > OK. The first version is online at: > > http://toxicsoftware.com/_private/Python%20Metadata%20Importer.pkg.zip > > The installer installs the mdimporter to /Library/Spotlight/ and then > calls mdimport -r to force Spotlight to reindex all Python files. > > You _may_ need Xcode installed to have this work successfully (Apple > defines the "public.python-script" UTI type - and it _may_ be defined > in Xcode - I need to check). > > This version scans through .py files looking for function names and > class names. It adds them to the file's 'org_python_functions' and > 'org_python_classes' metadata attributes respectively > > You can view the python specific metadata using mdls > > [schwa at cobweb] Python Metadata Importer$ mdls *.py > myimporter.py ------------- > kMDItemContentType = "public.python-script" > ... other metadata not shown ... > kMDItemKind = "Python Script" > org_python_functions = (find, main) > > And find it using mdfind: > > [schwa at cobweb] Spotlight$ mdfind "org_python_functions == 'main'" | > wc -l > 41 > > You can also use the Finder to search for functions/classes: bring up > a new search window, then choose "other?" in the attribute menu, in > the attribute search window look for the keyword "Python"... It is > quite impressive doing a search for python function names from the > finder. > > The importer actually uses an embedded python interpreter to parse > the python files (thanks to Bob for suggest the parser module). You > can see the python file inside the Resources folder of the importer. > The code currently leaks a few PyObjects so I'll be working on that > in the next version. > > Currently I do not add anything to kMDItemTextContent or any other > metadata attribute but this kind of stuff should be easy to do (just > a one line change to the Python code). > > Any feedback quite welcome. > > Cheers. > > Jon. > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > From ronaldoussoren at mac.com Fri May 13 07:39:12 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 13 May 2005 07:39:12 +0200 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar In-Reply-To: References: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> Message-ID: <77ED13D6-9C0D-48B1-9690-5303BA94B21A@mac.com> On 13-mei-2005, at 2:07, Bob Ippolito wrote: > > Jaguar isn't currently supported in PyObjC, but it might still work. > I highly recommend trying it from svn trunk instead. It isn't supported in the sense that I don't have a machine that's running or even capable of running Jaguar at the moment. Ronald From bob at redivi.com Fri May 13 08:04:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 13 May 2005 02:04:04 -0400 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar In-Reply-To: <77ED13D6-9C0D-48B1-9690-5303BA94B21A@mac.com> References: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> <77ED13D6-9C0D-48B1-9690-5303BA94B21A@mac.com> Message-ID: On May 13, 2005, at 1:39 AM, Ronald Oussoren wrote: > > On 13-mei-2005, at 2:07, Bob Ippolito wrote: > >> >> Jaguar isn't currently supported in PyObjC, but it might still work. >> I highly recommend trying it from svn trunk instead. >> > > It isn't supported in the sense that I don't have a machine that's > running or even capable of running Jaguar at the moment. Neither do I, or anyone else who has any plans to test/fix/commit in the near future. So yes, it is unsupported, but might still work... to some extent. -bob From rswerdlow at goombah.com Fri May 13 15:45:49 2005 From: rswerdlow at goombah.com (Bob Swerdlow) Date: Fri, 13 May 2005 09:45:49 -0400 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar References: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> Message-ID: <00f601c557c2$49330700$066fa8c0@RSWERDLOW800> Bob - Thanks for the response. Unfortunately, it looks like the Safari SK is no longer available at connect.apple.com. Do you know where I can get it? Also, I'm intrigued by your comment: > Jaguar isn't currently supported in PyObjC, but it might still work. > I highly recommend trying it from svn trunk instead. I'm building on Jaguar because that used to be the only way to get a Jaguar-compatible application built with bundlebuilder even though I do my development on Panther. Do I still need to build on Jaguar, or can I now build (using Py2App) on Panther or Tiger and get an application that will work on all versions of Mac OS X back to 10.2? I don't understand the dependencies enough to know. Thanks, Bob ----- Original Message ----- From: "Bob Ippolito" To: "Bob Swerdlow" Cc: Sent: Thursday, May 12, 2005 8:07 PM Subject: Re: [Pythonmac-SIG] WebKit with PyObjC on Jaguar > > On May 12, 2005, at 12:50 PM, Bob Swerdlow wrote: > >> I'm getting an ImportError trying to import WebKit. My configuration is >> Jaguar with PyObjC 1.2. I have Safari 1.0.3 installed. As far as I can >> tell from looking at the PyObjC pages, this should work. >> >> Where should I find the WebKit module on my machine? Where can I get >> the >> WebKit module if is not there? > > You need to install the Safari SDK from in > order for the WebKit wrapper to be built. I don't know whether or not > the 1.2 distribution for Jaguar shipped with a wrapper or not.. without > an ImportError to look at I wouldn't know. > > Jaguar isn't currently supported in PyObjC, but it might still work. I > highly recommend trying it from svn trunk instead. > > -bob > > From hengist.podd at virgin.net Fri May 13 16:10:22 2005 From: hengist.podd at virgin.net (has) Date: Fri, 13 May 2005 15:10:22 +0100 Subject: [Pythonmac-SIG] Carbon.AE problems revisited Message-ID: Hi all, I'm working on the next version of aem/appscript for release later this month, and need some expert advice on the following problem: As some folks will know, some parts of aem rely on patches I've made to Carbon.AE's _AE.so extension that haven't yet been applies to the standard MacPython distribution. Previous aem releases required users to replace the current lib-dynload/_AE.so with this new version, which obviously becomes a bit of an issue when it means patching an Apple-installed Python.framework. To avoid arguments over permissions, it'd be best to put the modified _AE.so into site-packages. However, this means that there's now two _AE.so extensions in use, and therefore two non-interchangeable AEDesc types. This means that Python code that uses one is incompatible with code that uses the other, which is obviously not a good situation either - two AEDesc types is really one too many. Is there an 'official' way to deal with this sort of problem? If not, what other solutions are available to me, and what are the pros and cons of each? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri May 13 20:33:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 13 May 2005 14:33:58 -0400 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar In-Reply-To: <00f601c557c2$49330700$066fa8c0@RSWERDLOW800> References: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> <00f601c557c2$49330700$066fa8c0@RSWERDLOW800> Message-ID: <79915347-5952-4958-8C31-B9814F4D7273@redivi.com> On May 13, 2005, at 9:45 AM, Bob Swerdlow wrote: > Bob - > > Thanks for the response. Unfortunately, it looks like the Safari > SK is no longer available at connect.apple.com. Do you know where > I can get it? Nope. > Also, I'm intrigued by your comment: > >> Jaguar isn't currently supported in PyObjC, but it might still work. >> I highly recommend trying it from svn trunk instead. >> > > I'm building on Jaguar because that used to be the only way to get > a Jaguar-compatible application built with bundlebuilder even > though I do my development on Panther. Do I still need to build on > Jaguar, or can I now build (using Py2App) on Panther or Tiger and > get an application that will work on all versions of Mac OS X back > to 10.2? I don't understand the dependencies enough to know. That is correct. The only way to develop a Jaguar compatible application with Python is to build its components on Jaguar. -bob From konrad.hinsen at laposte.net Fri May 13 22:09:42 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Fri, 13 May 2005 22:09:42 +0200 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar In-Reply-To: <79915347-5952-4958-8C31-B9814F4D7273@redivi.com> References: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> <00f601c557c2$49330700$066fa8c0@RSWERDLOW800> <79915347-5952-4958-8C31-B9814F4D7273@redivi.com> Message-ID: On 13.05.2005, at 20:33, Bob Ippolito wrote: > That is correct. The only way to develop a Jaguar compatible > application with Python is to build its components on Jaguar. Is that also true for Panther/Tiger? Assuming that I update all my machines to Tiger, will I still be able to build packages that work on Panther? Konrad. From bob at redivi.com Fri May 13 22:36:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 13 May 2005 16:36:18 -0400 Subject: [Pythonmac-SIG] WebKit with PyObjC on Jaguar In-Reply-To: References: <088201c55712$bdcaf5b0$066fa8c0@RSWERDLOW800> <00f601c557c2$49330700$066fa8c0@RSWERDLOW800> <79915347-5952-4958-8C31-B9814F4D7273@redivi.com> Message-ID: On May 13, 2005, at 4:09 PM, konrad.hinsen at laposte.net wrote: > On 13.05.2005, at 20:33, Bob Ippolito wrote: > > >> That is correct. The only way to develop a Jaguar compatible >> application with Python is to build its components on Jaguar. >> > > Is that also true for Panther/Tiger? Assuming that I update all my > machines to Tiger, will I still be able to build packages that work on > Panther? Only if all the components of that package were either built on Panther, or are just python code. i.e., if you are careful to only use packages from http://pythonmac.org/packages/ under the Mac OS X 10.3+ section(s) then you will be definitely be in the clear. That said, some extensions compiled on Tiger will work on Panther, but if *all* of your machines are running Tiger, how would you know if it still works on Panther? You're going to need a way to test on your minimum target platform anyhow, so you should keep an install of Panther around (maybe on an old iPod or firewire drive) so that you can test, fix, and build your distribution packages. On the Panther machine you could also build your third party extensions, bdist_mpkg them, and install the packages on your Tiger development machines. That way, you may be able to meet the "everything built on 10.3" requirement that would allow you build the distribution packages on Tiger. -bob From brad.allen at omsdal.com Sat May 14 01:11:13 2005 From: brad.allen at omsdal.com (brad.allen@omsdal.com) Date: Fri, 13 May 2005 18:11:13 -0500 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: Message-ID: Thanks, Florian, for the instructions on how to convert the new binary plist files into something parseable. I'm wondering if it's going to be possible to bundle this sort of functionality into plistlib. Since PyObjC is needed, I guess the normal plistlib won't be able to do it. Maybe a special version of plistlib could be bundled with PyObjC, just to handle this? Meanwhile, what's the best day to detect if a plist file is binary? I guess I could just wrap the normal plistlib parsing in a try block, catch the exception, and try again after converting from binary, but that seems kludgy. Does anybody know why Apple chose to start using binary for plist files? This seems mighty inconvenient. Was it for read/write performance? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050513/c36ed63f/attachment.htm From janssen at parc.com Sat May 14 05:19:57 2005 From: janssen at parc.com (Bill Janssen) Date: Fri, 13 May 2005 20:19:57 PDT Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: Your message of "Fri, 13 May 2005 16:11:13 PDT." Message-ID: <05May13.202002pdt."58617"@synergy1.parc.xerox.com> The binary plist format is also documented on the Web in http://cvs.opendarwin.org/index.cgi/~checkout~/src/CoreFoundation/Parsing.subproj/CFBinaryPList.c?rev=1.1.1.3&content-type=text/plain so a parser could be written for it in pure Python. Bill From bob at redivi.com Sat May 14 06:44:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 14 May 2005 00:44:03 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: References: Message-ID: <0099E06E-BEBF-4E85-9689-C13289A725D7@redivi.com> On May 13, 2005, at 7:11 PM, brad.allen at omsdal.com wrote: > Thanks, Florian, for the instructions on how to convert the new > binary plist files into something parseable. > > I'm wondering if it's going to be possible to bundle this sort of > functionality into plistlib. Since PyObjC is needed, I guess the > normal plistlib won't be able to do it. Maybe a special version of > plistlib could be bundled with PyObjC, just to handle this? I'd rather not see plistlib change. It does the XML stuff properly, doing anything else doesn't really belong in the standard library. I would rather see plistlib move from plat-mac to the standard distribution than have it bring on optional PyObjC dependencies that work sometimes and not others. This is like when it used to have pyxml dependencies (that weren't implemented properly in the first place). I'll go ahead and add some stuff to PyObjCTools.Conversion before 1.3.5 to read and write plists from data and files, but it's not very hard to do this with just raw PyObjC. thePlist = NSDictionary.dictionaryWithContentsOfFile_(somePath) someDict.writeToFile_atomically_(somePath, True) There are already functions in PyObjCTools.Conversion to convert python data structures to/from the Objective-C counterparts (though as long as the outer thing is a NSDictionary, the write will still work, because all the property lists types are bridged). > Meanwhile, what's the best day to detect if a plist file is binary? > I guess I could just wrap the normal plistlib parsing in a try > block, catch the exception, and try again after converting from > binary, but that seems kludgy. Don't. Just load it. > Does anybody know why Apple chose to start using binary for plist > files? This seems mighty inconvenient. Was it for read/write > performance? Yes, it was for performance. -bob From bob at redivi.com Sat May 14 06:57:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 14 May 2005 00:57:23 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <05May13.202002pdt."58617"@synergy1.parc.xerox.com> References: <05May13.202002pdt."58617"@synergy1.parc.xerox.com> Message-ID: <0E61DF00-5F5E-4129-8BE9-3638F4A3162C@redivi.com> On May 13, 2005, at 11:19 PM, Bill Janssen wrote: > The binary plist format is also documented on the Web in > http://cvs.opendarwin.org/index.cgi/~checkout~/src/CoreFoundation/ > Parsing.subproj/CFBinaryPList.c?rev=1.1.1.3&content-type=text/plain > so a parser could be written for it in pure Python. Yeah, the NeXT style plists could be done too. But the question is, why bother? PyObjC does it correctly and quickly :) That code wouldn't be very fun to write in Python. The struct module sucks. -bob From bob at redivi.com Sat May 14 18:58:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 14 May 2005 12:58:57 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <0099E06E-BEBF-4E85-9689-C13289A725D7@redivi.com> References: <0099E06E-BEBF-4E85-9689-C13289A725D7@redivi.com> Message-ID: <0163FDED-C711-4188-9616-D15EC2C1869C@redivi.com> On May 14, 2005, at 12:44 AM, Bob Ippolito wrote: > > On May 13, 2005, at 7:11 PM, brad.allen at omsdal.com wrote: > > >> Thanks, Florian, for the instructions on how to convert the new >> binary plist files into something parseable. >> >> I'm wondering if it's going to be possible to bundle this sort of >> functionality into plistlib. Since PyObjC is needed, I guess the >> normal plistlib won't be able to do it. Maybe a special version of >> plistlib could be bundled with PyObjC, just to handle this? >> > > I'd rather not see plistlib change. It does the XML stuff properly, > doing anything else doesn't really belong in the standard library. I > would rather see plistlib move from plat-mac to the standard > distribution than have it bring on optional PyObjC dependencies that > work sometimes and not others. This is like when it used to have > pyxml dependencies (that weren't implemented properly in the first > place). > > I'll go ahead and add some stuff to PyObjCTools.Conversion before > 1.3.5 to read and write plists from data and files, but it's not very > hard to do this with just raw PyObjC. > > thePlist = NSDictionary.dictionaryWithContentsOfFile_(somePath) > > someDict.writeToFile_atomically_(somePath, True) > > There are already functions in PyObjCTools.Conversion to convert > python data structures to/from the Objective-C counterparts (though > as long as the outer thing is a NSDictionary, the write will still > work, because all the property lists types are bridged). I've added this functionality to PyObjCTools.Conversion, in svn r1644. -bob From antoine.davous at chello.fr Fri May 13 23:04:58 2005 From: antoine.davous at chello.fr (Antoine Davous) Date: Fri, 13 May 2005 23:04:58 +0200 Subject: [Pythonmac-SIG] MacCVSX and Python Message-ID: Hi Steve, I had exactly the same problem (same OS, same softwares, same versions). I solved it (but who knows if it is really correct ?) by : - first installing _tkinter-2.3-binary (you have done it also) - and then by copying the library in the Python main installation's library with command : sudo cp -p /Library/Python/2.3/_tkinter.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ lib-tk/. I decide this by looking paths carefully on error messages. Now, it is working great with no more error message in console. But again, maybe I am totally wrong ? Regards Antoine From janssen at parc.com Mon May 16 00:26:52 2005 From: janssen at parc.com (Bill Janssen) Date: Sun, 15 May 2005 15:26:52 PDT Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: Your message of "Fri, 13 May 2005 21:57:23 PDT." <0E61DF00-5F5E-4129-8BE9-3638F4A3162C@redivi.com> Message-ID: <05May15.152659pdt."58617"@synergy1.parc.xerox.com> > Yeah, the NeXT style plists could be done too. But the question is, > why bother? In case I encounter a file of this format on a non-Apple platform, of course. It's particularly interesting because Safari is now storing web-archive files in this format (binary plist). There's a good chance that those might be copied off-Apple. > The struct module sucks. In what way? I think it works pretty well for what it is. Bill From bob at redivi.com Mon May 16 04:00:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 15 May 2005 22:00:05 -0400 Subject: [Pythonmac-SIG] MacCVSX and Python In-Reply-To: References: Message-ID: On May 13, 2005, at 5:04 PM, Antoine Davous wrote: > I had exactly the same problem (same OS, same softwares, same > versions). > > I solved it (but who knows if it is really correct ?) by : > - first installing _tkinter-2.3-binary (you have done it also) > - and then by copying the library in the Python main installation's > library with command : > > sudo cp -p /Library/Python/2.3/_tkinter.so > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/ > lib-tk/. > > I decide this by looking paths carefully on error messages. Now, it is > working great with no more error message in console. But again, > maybe I > am totally wrong ? Yes, you are wrong. If you build Tkinter apps with py2app, using your hacked configuration, then they will not run on anyone else's machine, since _tkinter will not be included if it's in the system location. The problem is that you installed packages for Mac OS X 10.3 on Mac OS X 10.4 and expected it to Just Work. It doesn't. The path changed, that's why it says "Mac OS X 10.3" instead of "Mac OS X 10.3+". In order for this to work correctly, without mangling your paths and messing up your system, you need to install the TigerPython23Compat package from pythonmac.org packages . -bob From bob at redivi.com Mon May 16 04:01:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 15 May 2005 22:01:52 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <05May15.152659pdt."58617"@synergy1.parc.xerox.com> References: <05May15.152659pdt."58617"@synergy1.parc.xerox.com> Message-ID: <6DCB0C4C-5953-4C8E-9D23-B185177E4FDF@redivi.com> On May 15, 2005, at 6:26 PM, Bill Janssen wrote: >> Yeah, the NeXT style plists could be done too. But the question is, >> why bother? > > In case I encounter a file of this format on a non-Apple platform, of > course. It's particularly interesting because Safari is now storing > web-archive files in this format (binary plist). There's a good > chance that those might be copied off-Apple. > >> The struct module sucks. > > In what way? I think it works pretty well for what it is. If "works pretty well" means that it's one of the most common sources of bugs in the Python standard library (that corrupt data for years before being found), and that it's harder to write struct based code than it is to write the equivalent in C, then sure. -bob From janssen at parc.com Mon May 16 04:22:59 2005 From: janssen at parc.com (Bill Janssen) Date: Sun, 15 May 2005 19:22:59 PDT Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: Your message of "Sun, 15 May 2005 19:01:52 PDT." <6DCB0C4C-5953-4C8E-9D23-B185177E4FDF@redivi.com> Message-ID: <05May15.192304pdt."58617"@synergy1.parc.xerox.com> > If "works pretty well" means that it's one of the most common sources > of bugs in the Python standard library (that corrupt data for years > before being found) Do you mean it contained (contains?) bugs, or that it's easy to misuse and someone misused it in some other part of the std library? I've found it quite handy and efficient in packing and unpacking binary structures. But one does have to pay attention -- I wish the default byte-ordering was network byte order rather than native. > and that it's harder to write struct based code > than it is to write the equivalent in C I wouldn't go that far, but it may be a wash. I try to avoid C, though. Bill From RajaSrinivasan at comcast.net Mon May 16 03:41:26 2005 From: RajaSrinivasan at comcast.net (R Srinivasan) Date: Sun, 15 May 2005 21:41:26 -0400 Subject: [Pythonmac-SIG] mp3 module or lame for imac Message-ID: my searches have not yielded any results hence this request : i am looking for either a mp3 manipulation module for python or a command line version of lame that i can execute. essentially i am looking to downsample some mp3's. any clues would be appreciated. srini From bob at redivi.com Mon May 16 05:22:40 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 15 May 2005 23:22:40 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <05May15.192304pdt."58617"@synergy1.parc.xerox.com> References: <05May15.192304pdt."58617"@synergy1.parc.xerox.com> Message-ID: <0B30681F-C35D-47C4-953A-36626F65600B@redivi.com> On May 15, 2005, at 10:22 PM, Bill Janssen wrote: >> If "works pretty well" means that it's one of the most common sources >> of bugs in the Python standard library (that corrupt data for years >> before being found) > > Do you mean it contained (contains?) bugs, or that it's easy to misuse > and someone misused it in some other part of the std library? I've > found it quite handy and efficient in packing and unpacking binary > structures. But one does have to pay attention -- I wish the default > byte-ordering was network byte order rather than native. I mean misuse causes bugs, primarily of the i vs I order, but there have been others. Recent example: the zipfile module had a bug where 'i' was used instead of 'I', which imposed artificial limits (2G file limit) and deviated from the format documentation. It only took a COUPLE YEARS for someone to figure this out. Here's the kicker though. Neither the person who generated the patch, and the person who audited and committed the patch noticed that there was a bug of the very same kind on the NEXT LINE (same block of code anyway, don't remember specifically). This is still unfixed (each file must start before the 2G boundary, so effectively the 2G file limit still exists unless you only use one file), but I did submit a patch. I just haven't committed it yet. >> and that it's harder to write struct based code >> than it is to write the equivalent in C > > I wouldn't go that far, but it may be a wash. I try to avoid C, > though. I certainly would: first, second, third, fourth, fifth, ..... = struct.unpack ("iiIIiIiiILllfd", data) It is SO EASY to screw this up. Pick the wrong type code, or misalign the type and field. It needs to look more like something sane: class Point(struct.BigEndianStruct): x = struct.SInt32() y = struct.SInt32() This isn't an API proposal, but it needs to be something remotely sane that: - Keeps the types and fields together, for god's sake - Lets you use named fields and nested structs - Uses named types with *precise meanings* and not semi-obscure letters that differ based on the platform - Lets you specify padding.. right now, for packed structs, you need to read EACH ELEMENT SEPARATELY - Can read a struct off of a file-like-object without explicitly calculating the size first There are plenty of other places in the standard library that really suck too, but this is the very worst thing in Python that I have ever needed to use. Specifically, it's the one module I need to use rather often, but ALWAYS have to have the docstrings open to triple- check that it's done right. The C API is also like this to an extent (there should be, but isn't, a naming convention that lets you know when some function is going to borrow or steal a reference)... but that's more or less to be expected out of an ancient C API. -bob From gandreas at gandreas.com Mon May 16 18:35:14 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Mon, 16 May 2005 11:35:14 -0500 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread Message-ID: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> So I'm reworking how debugging is handled in PyOXIDE and I've come to a problem (several, but this is the biggy for the morning). My goal is to separate interacting with the (remote) debugged client in a separate thread, which forwards messages to the main thread as needed to run the debugger UI (since all UI must be done on the main thread). The code is: def runThreadDebugSession(connection): from Foundation import NSAutoreleasePool pool = NSAutoreleasePool.alloc().init() from Foundation import NSLog try: debugger = None while connection.ClientAlive(): NSLog("Servicing threaded debug client") what = connection.ServiceClient() NSLog("Serviced " + what) if connection.IsStopped(): NSLog("Remote client stopped - getting debugger") remoteDebugger = connection.GetDebugger() NSLog("got debugger") if debugger == None: # first time, make the debugger NSLog("building debugger") debugger = PyDebuggerController.alloc() debugger.performSelectorOnMainThread_withObject_waitUntilDone_ ("initWithDebugger:",PyRemoteDebugger(debugger, remoteDebugger, connection),True) debugger.performSelectorOnMainThread_withObject_waitUntilDone_ ("startWithUserLine_",remoteDebugger.curframe) NSLog("Client no longer alive") except: import sys,traceback traceback.print_exc() pass # something went away def spawnRemoteDebugger(connection): # when we get a remote debugger, spawn off in another thread import threading thread = threading.Thread(target = runThreadDebugSession, args= (connection,)) thread.start() When the user says "debug", we launch the separate processes, which includes a stub to open up a TCP connection back to the IDE, which we use to interact with on the main event loop (which was ugly, since it would then nest, well, it was ugly). So now I call the above "spawnRemoteDebugger", it talks with the targeted process, and then at some point that process says "hey, let's start debugging" (and transfers over a proxy object to allow the IDE to interact with something that looks like a pdb object). That's all more or less fine. The problem is that we then allocate and init the debugger controller (PyDebuggerController). Since that needs to be done on the main thread, we use performSelectorOnMainThread. That works fine except that when this debugger controller object gets created, it eventually wants to call the python code associated said object. Of course, since that's on the main thread (and not this other debugger handler thread) it calls PyThread_aquire_lock. But the lock is stuck in the thread that executing the performSelectorOnMainThread line, and everything just stops (the main thread waits on the semaphore which will never be released). So, it appears that performSelectorOnMainThread needs some way to release the lock to let Python code in the main thread be executed. Any suggestions for workarounds? Glenn Andreas gandreas at gandreas.com oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050516/4aa458d2/attachment.htm From bob at redivi.com Mon May 16 18:59:29 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 12:59:29 -0400 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> Message-ID: On May 16, 2005, at 12:35 PM, gandreas at gandreas.com wrote: > So I'm reworking how debugging is handled in PyOXIDE and I've come > to a problem (several, but this is the biggy for the morning). > > My goal is to separate interacting with the (remote) debugged > client in a separate thread, which forwards messages to the main > thread as needed to run the debugger UI (since all UI must be done > on the main thread). --- > When the user says "debug", we launch the separate processes, which > includes a stub to open up a TCP connection back to the IDE, which > we use to interact with on the main event loop (which was ugly, > since it would then nest, well, it was ugly). So now I call the > above "spawnRemoteDebugger", it talks with the targeted process, > and then at some point that process says "hey, let's start > debugging" (and transfers over a proxy object to allow the IDE to > interact with something that looks like a pdb object). That's all > more or less fine. I don't understand why you need to use threads from the host app. The best way I've found to do this is: Host app (debugger/interpreter UI) uses async TCP interleaved with the main runloop (i.e. NSFileHandle, or something else) Debugged app (application or interpreter) uses sync TCP that blocks waiting for interaction from the debugger If you need a way to interrupt the debugged app asynchronously (i.e. ctrl-C in gdb), then set up a signal handler in the debugged app that installs a trace hook from the debugging bootstrap code that makes it go into debugging mode and send it a signal from the host app... but that's not something that's ever very clean in Python. > The problem is that we then allocate and init the debugger > controller (PyDebuggerController). Since that needs to be done on > the main thread, we use performSelectorOnMainThread. That works > fine except that when this debugger controller object gets created, > it eventually wants to call the python code associated said > object. Of course, since that's on the main thread (and not this > other debugger handler thread) it calls PyThread_aquire_lock. But > the lock is stuck in the thread that executing the > performSelectorOnMainThread line, and everything just stops (the > main thread waits on the semaphore which will never be released). > > So, it appears that performSelectorOnMainThread needs some way to > release the lock to let Python code in the main thread be > executed. Any suggestions for workarounds? Update to PyObjC from svn and see if that makes a difference. -bob From janssen at parc.com Mon May 16 19:31:39 2005 From: janssen at parc.com (Bill Janssen) Date: Mon, 16 May 2005 10:31:39 PDT Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: Your message of "Sun, 15 May 2005 20:22:40 PDT." <0B30681F-C35D-47C4-953A-36626F65600B@redivi.com> Message-ID: <05May16.103140pdt."58617"@synergy1.parc.xerox.com> > first, second, third, fourth, fifth, ..... = struct.unpack > ("iiIIiIiiILllfd", data) > > It is SO EASY to screw this up. Pick the wrong type code, or > misalign the type and field. It needs to look more like something sane: > > class Point(struct.BigEndianStruct): > x = struct.SInt32() > y = struct.SInt32() Why not (for yourself) just add a module which addresses some of this? As in: from unpacking import * def getPoint (bvar): unpack = unpacking(bvar) x = unpack(S_INT_32) y = unpack(S_INT_32) ============================== unpacking.py ============================ import struct S_INT_32 = "i" U_INT_32 = "I" ## ... etc. ... class unpacker: def __init__(self, bdata): if type(bdata) != type(''): raise ValueError("type of bdata (%s) should be simple str" % bdata) self.bdata = bdata def unpack(self, typespec): if not self.bdata: raise ValueError("data source exhausted") if len(self.bdata) > 0: valsize = struct.calcsize(typespec) if len(self.bdata) < valsize: raise ValueError("data source exhausted") val = struct.unpack(typespec, self.bdata[:valsize]) self.bdata = self.bdata[valsize:] return val def unpacking(bdata): return (lambda x, y=unpacker(bdata): y.unpack(x)) From bob at redivi.com Mon May 16 19:40:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 13:40:49 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <05May16.103140pdt."58617"@synergy1.parc.xerox.com> References: <05May16.103140pdt."58617"@synergy1.parc.xerox.com> Message-ID: <67370EBD-7DF1-482A-B458-20B068596DEB@redivi.com> On May 16, 2005, at 1:31 PM, Bill Janssen wrote: >> first, second, third, fourth, fifth, ..... = struct.unpack >> ("iiIIiIiiILllfd", data) >> >> It is SO EASY to screw this up. Pick the wrong type code, or >> misalign the type and field. It needs to look more like something >> sane: >> >> class Point(struct.BigEndianStruct): >> x = struct.SInt32() >> y = struct.SInt32() >> > > Why not (for yourself) just add a module which addresses some of this? > As in: > > from unpacking import * > > def getPoint (bvar): > unpack = unpacking(bvar) > x = unpack(S_INT_32) > y = unpack(S_INT_32) I have (sitting in macholib), but it still doesn't address the shortcomings of the struct module. For example, you can use the struct module to unpack unaligned data types but only if you do it one element at a time and you have to break up all the strings, etc. It can't unpack pascal strings, there's no hooks to plug in for variable length data structures, etc. There's also plenty of data types it doesn't cover (bit vectors, whatever else). Anyway, my point was that the struct module is horrible. It's certainly possible to write something better that may or may not use it internally, but such a thing isn't generally available and certainly isn't in the standard library. -bob From gandreas at gandreas.com Mon May 16 20:01:22 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Mon, 16 May 2005 13:01:22 -0500 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> Message-ID: On May 16, 2005, at 11:59 AM, Bob Ippolito wrote: > > On May 16, 2005, at 12:35 PM, gandreas at gandreas.com wrote: > > >> So I'm reworking how debugging is handled in PyOXIDE and I've come >> to a problem (several, but this is the biggy for the morning). >> >> My goal is to separate interacting with the (remote) debugged >> client in a separate thread, which forwards messages to the main >> thread as needed to run the debugger UI (since all UI must be done >> on the main thread). >> > --- > >> When the user says "debug", we launch the separate processes, >> which includes a stub to open up a TCP connection back to the IDE, >> which we use to interact with on the main event loop (which was >> ugly, since it would then nest, well, it was ugly). So now I call >> the above "spawnRemoteDebugger", it talks with the targeted >> process, and then at some point that process says "hey, let's >> start debugging" (and transfers over a proxy object to allow the >> IDE to interact with something that looks like a pdb object). >> That's all more or less fine. >> > > I don't understand why you need to use threads from the host app. > The best way I've found to do this is: > > Host app (debugger/interpreter UI) uses async TCP interleaved with > the main runloop (i.e. NSFileHandle, or something else) > Debugged app (application or interpreter) uses sync TCP that blocks > waiting for interaction from the debugger > The debugged app works like that, but the way that the "remote object" interface works is also designed to use sync TCP on the host side. Since it's pure python, I didn't want to start adding in NSFileHandles, and the obvious solution was "just use threads", and the whole "block on reads" model was much cleaner than any sort of polling. > If you need a way to interrupt the debugged app asynchronously > (i.e. ctrl-C in gdb), then set up a signal handler in the debugged > app that installs a trace hook from the debugging bootstrap code > that makes it go into debugging mode and send it a signal from the > host app... but that's not something that's ever very clean in Python. > I haven't quite figured out a good way to handle that one either, but since the other app is a child, sending a signal should work as good as anything. > >> The problem is that we then allocate and init the debugger >> controller (PyDebuggerController). Since that needs to be done on >> the main thread, we use performSelectorOnMainThread. That works >> fine except that when this debugger controller object gets >> created, it eventually wants to call the python code associated >> said object. Of course, since that's on the main thread (and not >> this other debugger handler thread) it calls >> PyThread_aquire_lock. But the lock is stuck in the thread that >> executing the performSelectorOnMainThread line, and everything >> just stops (the main thread waits on the semaphore which will >> never be released). >> >> So, it appears that performSelectorOnMainThread needs some way to >> release the lock to let Python code in the main thread be >> executed. Any suggestions for workarounds? >> > > Update to PyObjC from svn and see if that makes a difference. > Can't do that - the goal is to provide something that, at worse, requires the user to install a given binary package (PyOXIDE is designed to directly call packman if it detects PyObjC not being installed, to make things as transparent as possible). If I require the user to download the latest sources and compile it, that becomes a nightmare. If I compile it myself from "latest beta" and included it with PyOXIDE, that prevents bug fixed releases (since PyOXIDE would be hardcoded to run on the older, buggier, pre-release version). There's already far too much "well, it will all work great, but first you need to download this (and then compile that, and install this third thing)..." in the MacPython world that it makes me cringe (and certainly the choice of versions of Python included with the OS don't make the problem less either). Unfortunately, I can't think up a good way to solve that problem so I just cringe a lot and try to not make anything worse... After a good burrito for lunch, I'm thinking that adding an unlockPythonAndPerformSelectorOnMainThread(andRelockAfterwards) method might be the best way to handle this - at least it's something easy that I can add as part of PyOXIDE... Glenn Andreas gandreas at gandreas.com oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From janssen at parc.com Mon May 16 20:08:15 2005 From: janssen at parc.com (Bill Janssen) Date: Mon, 16 May 2005 11:08:15 PDT Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: Your message of "Mon, 16 May 2005 10:40:49 PDT." <67370EBD-7DF1-482A-B458-20B068596DEB@redivi.com> Message-ID: <05May16.110825pdt."58617"@synergy1.parc.xerox.com> Pascal data structures?! Bill From bob at redivi.com Mon May 16 20:22:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 14:22:41 -0400 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> Message-ID: On May 16, 2005, at 2:01 PM, gandreas at gandreas.com wrote: > On May 16, 2005, at 11:59 AM, Bob Ippolito wrote: > > >> On May 16, 2005, at 12:35 PM, gandreas at gandreas.com wrote: >> >>> So I'm reworking how debugging is handled in PyOXIDE and I've come >>> to a problem (several, but this is the biggy for the morning). >>> >>> My goal is to separate interacting with the (remote) debugged >>> client in a separate thread, which forwards messages to the main >>> thread as needed to run the debugger UI (since all UI must be done >>> on the main thread). >>> >>> >> --- >> >> >>> When the user says "debug", we launch the separate processes, >>> which includes a stub to open up a TCP connection back to the IDE, >>> which we use to interact with on the main event loop (which was >>> ugly, since it would then nest, well, it was ugly). So now I call >>> the above "spawnRemoteDebugger", it talks with the targeted >>> process, and then at some point that process says "hey, let's >>> start debugging" (and transfers over a proxy object to allow the >>> IDE to interact with something that looks like a pdb object). >>> That's all more or less fine. >>> >>> >> >> I don't understand why you need to use threads from the host app. >> The best way I've found to do this is: >> >> Host app (debugger/interpreter UI) uses async TCP interleaved with >> the main runloop (i.e. NSFileHandle, or something else) >> Debugged app (application or interpreter) uses sync TCP that blocks >> waiting for interaction from the debugger >> >> > > The debugged app works like that, but the way that the "remote > object" interface works is also designed to use sync TCP on the host > side. Since it's pure python, I didn't want to start adding in > NSFileHandles, and the obvious solution was "just use threads", and > the whole "block on reads" model was much cleaner than any sort of > polling. This isn't a very good argument since you're already using plenty of Objective-C code in there. Anyway, there's Twisted, asyncore/medusa, etc. for non-blocking Python IO... but NSFileHandle or the like is going to be the simplest thing that's going to work. >> If you need a way to interrupt the debugged app asynchronously >> (i.e. ctrl-C in gdb), then set up a signal handler in the debugged >> app that installs a trace hook from the debugging bootstrap code >> that makes it go into debugging mode and send it a signal from the >> host app... but that's not something that's ever very clean in >> Python. > > I haven't quite figured out a good way to handle that one either, but > since the other app is a child, sending a signal should work as good > as anything. There's a "you probably shouldn't use this" function in the C API that lets you write an extension module that sends an exception to another thread, so in theory you could start a background thread that sits on this and waits for a "signal" over TCP or the like from the parent and then uses that to break into the main thread. Don't do this though, there's a lot of reasons not to. Alternatively, you could start up a second socket on another thread and use it to send a signal to its own pid if it hears from the host. This would facilitate true remote debugging. >>> The problem is that we then allocate and init the debugger >>> controller (PyDebuggerController). Since that needs to be done on >>> the main thread, we use performSelectorOnMainThread. That works >>> fine except that when this debugger controller object gets >>> created, it eventually wants to call the python code associated >>> said object. Of course, since that's on the main thread (and not >>> this other debugger handler thread) it calls >>> PyThread_aquire_lock. But the lock is stuck in the thread that >>> executing the performSelectorOnMainThread line, and everything >>> just stops (the main thread waits on the semaphore which will >>> never be released). >>> >>> So, it appears that performSelectorOnMainThread needs some way to >>> release the lock to let Python code in the main thread be >>> executed. Any suggestions for workarounds? >> >> Update to PyObjC from svn and see if that makes a difference. > > Can't do that - the goal is to provide something that, at worse, > requires the user to install a given binary package (PyOXIDE is > designed to directly call packman if it detects PyObjC not being > installed, to make things as transparent as possible). If I require > the user to download the latest sources and compile it, that becomes > a nightmare. If I compile it myself from "latest beta" and included > it with PyOXIDE, that prevents bug fixed releases (since PyOXIDE > would be hardcoded to run on the older, buggier, pre-release version). > > There's already far too much "well, it will all work great, but first > you need to download this (and then compile that, and install this > third thing)..." in the MacPython world that it makes me cringe (and > certainly the choice of versions of Python included with the OS don't > make the problem less either). Unfortunately, I can't think up a > good way to solve that problem so I just cringe a lot and try to not > make anything worse... Well that's too bad. What you're suggesting will make things much worse. The Python interpreter used by your application should be private anyway, so you can and should include PyObjC (probably even Python itself) inside your application. I've said this a ton of times, but the ONLY time you should EVER run user Python code from an IDE is from separate processes, unless it's simply a plugin for the IDE. That said, PyObjC 1.3.5 is just about ready to release anyway. If PyOXIDE itself needs a bug fix from a newer version of PyObjC (which in this case, I'm almost 100% positive it does), then you should update PyOXIDE with a new version of PyObjC. > After a good burrito for lunch, I'm thinking that adding an > unlockPythonAndPerformSelectorOnMainThread(andRelockAfterwards) > method might be the best way to handle this - at least it's something > easy that I can add as part of PyOXIDE... NO! That is really really horribly bad to do. Working around a bug in PyObjC by writing code that will break in correct versions of PyObjC is absolutely horrible. You should NEVER release the lock unless you own it. -bob From bob at redivi.com Mon May 16 20:28:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 14:28:38 -0400 Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: <05May16.110825pdt."58617"@synergy1.parc.xerox.com> References: <05May16.110825pdt."58617"@synergy1.parc.xerox.com> Message-ID: <1EDD9B6F-2397-4C0A-B237-6C62E21162A3@redivi.com> On May 16, 2005, at 2:08 PM, Bill Janssen wrote: > Pascal data structures?! Have you ever looked at the Carbon/QuickTime APIs? I guess not. Mac OS past was originally written with Pascal calling conventions and pascal strings (unsigned char length prefixed strings), so you see them all over the place. It's ugly, but so are the APIs that use them :) -bob From gandreas at gandreas.com Mon May 16 20:53:21 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Mon, 16 May 2005 13:53:21 -0500 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> Message-ID: <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> On May 16, 2005, at 1:22 PM, Bob Ippolito wrote: > > On May 16, 2005, at 2:01 PM, gandreas at gandreas.com wrote: >>> >> >> The debugged app works like that, but the way that the "remote >> object" interface works is also designed to use sync TCP on the host >> side. Since it's pure python, I didn't want to start adding in >> NSFileHandles, and the obvious solution was "just use threads", and >> the whole "block on reads" model was much cleaner than any sort of >> polling. >> > > This isn't a very good argument since you're already using plenty > of Objective-C code in there. > My goal was to try to not make it worse... (since part of the goal was to be able to provide a debugging stub that could be included in anything that embedded python, regardless if it was PyObjC based or not - or even Mac OS X based). > Anyway, there's Twisted, asyncore/medusa, etc. for non-blocking > Python IO... but NSFileHandle or the like is going to be the > simplest thing that's going to work. > The more I investigate this, the more this seems to be the path of least resistance... > >>> If you need a way to interrupt the debugged app asynchronously >>> (i.e. ctrl-C in gdb), then set up a signal handler in the debugged >>> app that installs a trace hook from the debugging bootstrap code >>> that makes it go into debugging mode and send it a signal from the >>> host app... but that's not something that's ever very clean in >>> Python. >>> >> >> I haven't quite figured out a good way to handle that one either, but >> since the other app is a child, sending a signal should work as good >> as anything. >> > > There's a "you probably shouldn't use this" function in the C API > that lets you write an extension module that sends an exception to > another thread, so in theory you could start a background thread > that sits on this and waits for a "signal" over TCP or the like > from the parent and then uses that to break into the main thread. > Don't do this though, there's a lot of reasons not to. > > Alternatively, you could start up a second socket on another thread > and use it to send a signal to its own pid if it hears from the > host. This would facilitate true remote debugging. > I should be able to directly send the signal from the IDE to the targeted app (since it's a child of the IDE), and the standard "catch a unix signal invokes the debugger" action should work (since the debugger interface on the client talks back to the IDE). >>> >>> Update to PyObjC from svn and see if that makes a difference. >>> >> >> Can't do that - the goal is to provide something that, at worse, >> requires the user to install a given binary package (PyOXIDE is >> designed to directly call packman if it detects PyObjC not being >> installed, to make things as transparent as possible). If I require >> the user to download the latest sources and compile it, that becomes >> a nightmare. If I compile it myself from "latest beta" and included >> it with PyOXIDE, that prevents bug fixed releases (since PyOXIDE >> would be hardcoded to run on the older, buggier, pre-release >> version). >> >> There's already far too much "well, it will all work great, but first >> you need to download this (and then compile that, and install this >> third thing)..." in the MacPython world that it makes me cringe (and >> certainly the choice of versions of Python included with the OS don't >> make the problem less either). Unfortunately, I can't think up a >> good way to solve that problem so I just cringe a lot and try to not >> make anything worse... >> > > Well that's too bad. What you're suggesting will make things much > worse. > > The Python interpreter used by your application should be private > anyway, so you can and should include PyObjC (probably even Python > itself) inside your application. Including an entire "custom" version of Python just seems like a bad solution to me. It may be the only solution, depending on various other circumstances, but it seems kind of sad to say "well, OS X ships with Python.framework, but it can't be used to write a Python IDE". > I've said this a ton of times, but the ONLY time you should EVER > run user Python code from an IDE is from separate processes, unless > it's simply a plugin for the IDE. I personally don't agree with this. There are plenty of times when I just need something to "tinker" with, and the separate process model doesn't work well because I find the ability to have a semi- persistent state extremely useful (run the script, examine the results using an interactive window, manually call some of the routines, fix a routine and run that source file again, etc... - not to mention that examining the state of objects within the application is _much_ faster than having to proxy everything through a socket). Now if there were a "persistent external" mode, that would be another story (but that's more a "future feature"). > That said, PyObjC 1.3.5 is just about ready to release anyway. > Cool! > If PyOXIDE itself needs a bug fix from a newer version of PyObjC > (which in this case, I'm almost 100% positive it does), then you > should update PyOXIDE with a new version of PyObjC. > I'm leaning towards redoing things to avoid the "here be dragons" areas of the map. > >> After a good burrito for lunch, I'm thinking that adding an >> unlockPythonAndPerformSelectorOnMainThread(andRelockAfterwards) >> method might be the best way to handle this - at least it's something >> easy that I can add as part of PyOXIDE... >> > > NO! That is really really horribly bad to do. Working around a > bug in PyObjC by writing code that will break in correct versions > of PyObjC is absolutely horrible. You should NEVER release the > lock unless you own it. > Here, then, is probably the heart of the problem - the interactions between python threads spawned by threading.Thread and the main (objc) thread and performSelectorOnMainThread are "undefined", and the more I look at it, the more it appears that using threading.Thread in a PyObjC app is a bad idea and should probably just be chalked up as "unsupported and probably won't work". It appears that I'd need to build something on top of NSThread (in Objective-C) with explicit thread state handling to get this to work consistently and correctly. Glenn Andreas gandreas at gandreas.com oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From ronaldoussoren at mac.com Mon May 16 21:05:50 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 16 May 2005 21:05:50 +0200 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> Message-ID: <10D82636-0723-42DD-8DB0-FE23EE376F1E@mac.com> On 16-mei-2005, at 20:01, gandreas at gandreas.com wrote: >>> >>> So, it appears that performSelectorOnMainThread needs some way to >>> release the lock to let Python code in the main thread be >>> executed. Any suggestions for workarounds? >>> >>> >> >> Update to PyObjC from svn and see if that makes a difference. >> >> > > Can't do that - the goal is to provide something that, at worse, > requires the user to install a given binary package (PyOXIDE is > designed to directly call packman if it detects PyObjC not being > installed, to make things as transparent as possible). If I require > the user to download the latest sources and compile it, that becomes > a nightmare. Checking the latest PyObjC doesn't mean you must ship it. The bug may be fixed in SVN head, that would save us a lot of time :-) BTW. I don't see why you couldn't ship a version of PyObjC inside your app bundle. If you're running user scripts in a seperate interpreter you should make sure that the stuff in your bundle isn't on the search path, users scripts should only see system-wide stuff. BTW2. Relying on a user-installed version of PyObjC is bad: what if PyObjC 1.7 breaks PyOxide and an unsuspecting user installs that. I'd be very surprised if a standalone application breaks because I install a new library. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050516/d99b1c36/smime.bin From janssen at parc.com Mon May 16 21:07:22 2005 From: janssen at parc.com (Bill Janssen) Date: Mon, 16 May 2005 12:07:22 PDT Subject: [Pythonmac-SIG] convert binary plist to xml string In-Reply-To: Your message of "Mon, 16 May 2005 11:28:38 PDT." <1EDD9B6F-2397-4C0A-B237-6C62E21162A3@redivi.com> Message-ID: <05May16.120730pdt."58617"@synergy1.parc.xerox.com> > > On May 16, 2005, at 2:08 PM, Bill Janssen wrote: > > > Pascal data structures?! > > Have you ever looked at the Carbon/QuickTime APIs? I guess not. Nope. > Mac OS past was originally written with Pascal calling conventions and > pascal strings (unsigned char length prefixed strings), so you see > them all over the place. It's ugly, but so are the APIs that use > them :) > > -bob Isn't that what the "p" code in struct is for? Reading/writing those? Or is the length prefix a short or int? Bill From ronaldoussoren at mac.com Mon May 16 21:12:11 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 16 May 2005 21:12:11 +0200 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> Message-ID: <7E912E18-B126-415C-881F-7DCD224935B2@mac.com> On 16-mei-2005, at 20:53, gandreas at gandreas.com wrote: >> >> NO! That is really really horribly bad to do. Working around a >> bug in PyObjC by writing code that will break in correct versions >> of PyObjC is absolutely horrible. You should NEVER release the >> lock unless you own it. >> >> > > Here, then, is probably the heart of the problem - the interactions > between python threads spawned by threading.Thread and the main > (objc) thread and performSelectorOnMainThread are "undefined", and > the more I look at it, the more it appears that using > threading.Thread in a PyObjC app is a bad idea and should probably > just be chalked up as "unsupported and probably won't work". It > appears that I'd need to build something on top of NSThread (in > Objective-C) with explicit thread state handling to get this to work > consistently and correctly. Threading.Thread should work as long as Cocoa knows that the application is multithreaded or you don't call Cocoa outside of the main thread. (See http://developer.apple.com/documentation/Cocoa/Conceptual/ Multithreading/index.html#//apple_ref/doc/uid/10000057i, threading.Thread uses POSIX threads) Using NSThread is slightly cleaner if you do call Cocoa API's from secondairy threads. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050516/4f431701/smime.bin From bob at redivi.com Mon May 16 21:22:17 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 15:22:17 -0400 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> Message-ID: <1BA143FA-91F4-4C83-815C-B9CC13E61773@redivi.com> On May 16, 2005, at 2:53 PM, gandreas at gandreas.com wrote: > > On May 16, 2005, at 1:22 PM, Bob Ippolito wrote: > > >> >> On May 16, 2005, at 2:01 PM, gandreas at gandreas.com wrote: >> >>> The debugged app works like that, but the way that the "remote >>> object" interface works is also designed to use sync TCP on the host >>> side. Since it's pure python, I didn't want to start adding in >>> NSFileHandles, and the obvious solution was "just use threads", and >>> the whole "block on reads" model was much cleaner than any sort of >>> polling. >> >> This isn't a very good argument since you're already using plenty >> of Objective-C code in there. > > My goal was to try to not make it worse... (since part of the goal > was to be able to provide a debugging stub that could be included > in anything that embedded python, regardless if it was PyObjC based > or not - or even Mac OS X based). The important part is to make what sits inside the running program pure python with no non-stdlib dependencies. The part that lives in the IDE is going to have so much IDE specific code in it that it doesn't really matter whether you're using pure python or not. >>>> If you need a way to interrupt the debugged app asynchronously >>>> (i.e. ctrl-C in gdb), then set up a signal handler in the debugged >>>> app that installs a trace hook from the debugging bootstrap code >>>> that makes it go into debugging mode and send it a signal from the >>>> host app... but that's not something that's ever very clean in >>>> Python. >>>> >>>> >>> >>> I haven't quite figured out a good way to handle that one either, >>> but >>> since the other app is a child, sending a signal should work as good >>> as anything. >>> >>> >> >> There's a "you probably shouldn't use this" function in the C API >> that lets you write an extension module that sends an exception to >> another thread, so in theory you could start a background thread >> that sits on this and waits for a "signal" over TCP or the like >> from the parent and then uses that to break into the main thread. >> Don't do this though, there's a lot of reasons not to. >> >> Alternatively, you could start up a second socket on another >> thread and use it to send a signal to its own pid if it hears from >> the host. This would facilitate true remote debugging. >> >> > > I should be able to directly send the signal from the IDE to the > targeted app (since it's a child of the IDE), and the standard > "catch a unix signal invokes the debugger" action should work > (since the debugger interface on the client talks back to the IDE). Yeah, this will work fine. I'm just saying, that if you wanted something even more decoupled (to implement remote debugging, plugin debugging, objc.inject debugging, etc.), then that's how you could do it. >>>> Update to PyObjC from svn and see if that makes a difference. >>>> >>>> >>> >>> Can't do that - the goal is to provide something that, at worse, >>> requires the user to install a given binary package (PyOXIDE is >>> designed to directly call packman if it detects PyObjC not being >>> installed, to make things as transparent as possible). If I require >>> the user to download the latest sources and compile it, that becomes >>> a nightmare. If I compile it myself from "latest beta" and >>> included >>> it with PyOXIDE, that prevents bug fixed releases (since PyOXIDE >>> would be hardcoded to run on the older, buggier, pre-release >>> version). >>> >>> There's already far too much "well, it will all work great, but >>> first >>> you need to download this (and then compile that, and install this >>> third thing)..." in the MacPython world that it makes me cringe (and >>> certainly the choice of versions of Python included with the OS >>> don't >>> make the problem less either). Unfortunately, I can't think up a >>> good way to solve that problem so I just cringe a lot and try to not >>> make anything worse... >> >> Well that's too bad. What you're suggesting will make things much >> worse. >> >> The Python interpreter used by your application should be private >> anyway, so you can and should include PyObjC (probably even Python >> itself) inside your application. >> > > Including an entire "custom" version of Python just seems like a > bad solution to me. It may be the only solution, depending on > various other circumstances, but it seems kind of sad to say "well, > OS X ships with Python.framework, but it can't be used to write a > Python IDE". Mac OS X 10.3 and 10.4 ship with a Python 2.3 framework. Mac OS X 10.5 (hopefully) will not. Do you want to have to maintain separate versions of your app for 10.3-10.4 and 10.5, so as to use the standard Python? Additionally, do you want to test everything on Python 2.3.0 and Python 2.3.5? What if you run into a bug that can't be monkeypatched for Python 2.3.0? There's so many reasons NOT to use the framework that Apple provides, because they do a really poor job maintaining it, and provide no guarantee of backwards or forward compatibility of any sort... unlike their own frameworks. >> I've said this a ton of times, but the ONLY time you should EVER >> run user Python code from an IDE is from separate processes, >> unless it's simply a plugin for the IDE. > > I personally don't agree with this. There are plenty of times when > I just need something to "tinker" with, and the separate process > model doesn't work well because I find the ability to have a semi- > persistent state extremely useful (run the script, examine the > results using an interactive window, manually call some of the > routines, fix a routine and run that source file again, etc... - > not to mention that examining the state of objects within the > application is _much_ faster than having to proxy everything > through a socket). Now if there were a "persistent external" mode, > that would be another story (but that's more a "future feature"). Semi-persistent state can be had just as easily with an external interpreter using the same methodology you're using for a debugging stub. If the interpreter is already open, then just call execfile in it instead of tearing it down and starting another one. No problem there, and you don't have to worry about forcing the user to use the IDE's version of Python nor do you have to worry about the IDE crashing, hanging, becoming unstable, blowing up, etc. because the user decided to call NSApp().terminate_(None) or something. As far as speed goes. If it's noticeably slower than you're doing something wrong. Safe and correct is better than fast, anyway, ESPECIALLY for an IDE. The last thing you want is the IDE to crash in the middle of doing something. As far as I've seen here, the major complaint with your PyOXIDE is that it is not stable, so perhaps you should change your viewpoint on issues like this. Speed is easy enough to fix anyway, there are plenty of ways you could put more code in the stub or use mmap to transfer memory or whatever else as an *optimization after it already works correctly* without compromising the integrity of the host application. >>> After a good burrito for lunch, I'm thinking that adding an >>> unlockPythonAndPerformSelectorOnMainThread(andRelockAfterwards) >>> method might be the best way to handle this - at least it's >>> something >>> easy that I can add as part of PyOXIDE... >> >> NO! That is really really horribly bad to do. Working around a >> bug in PyObjC by writing code that will break in correct versions >> of PyObjC is absolutely horrible. You should NEVER release the >> lock unless you own it. > > Here, then, is probably the heart of the problem - the interactions > between python threads spawned by threading.Thread and the main > (objc) thread and performSelectorOnMainThread are "undefined", and > the more I look at it, the more it appears that using > threading.Thread in a PyObjC app is a bad idea and should probably > just be chalked up as "unsupported and probably won't work". It > appears that I'd need to build something on top of NSThread (in > Objective-C) with explicit thread state handling to get this to > work consistently and correctly. Well, that's simply not true. PyObjC svn + Python 2.4.1 definitely does not have this problem. There was a thread about this (aptly named "Threading") on pyobjc-dev in March/April. I suggest you subscribe there if you haven't already. The issue you're experiencing is a bug in Python 2.3.0 (another reason not to use Apple's Python framework on Panther). This is in the interpreter of course, so it can't be fixed in-place and Apple sure isn't going to update it. Python 2.4.1 and reportedly Python 2.3.5 do not have this bug. Yet another /really/ good reason not to use the Python framework that ships with Mac OS X 10.3! The only edge case, of course, is that Foundation must be in "threaded" mode before you start calling into objc from the second thread, which generally happens behind the scenes anyway because you're using AppKit which will start a thread or two off the bat. This is a general restriction of using "raw" pthreads from any Foundation app. PyObjC should probably spawn a NSThread during initialization, I'll go ahead and do that before the 1.3.5 release. -bob From gandreas at gandreas.com Mon May 16 21:28:54 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Mon, 16 May 2005 14:28:54 -0500 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <7E912E18-B126-415C-881F-7DCD224935B2@mac.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> <7E912E18-B126-415C-881F-7DCD224935B2@mac.com> Message-ID: <6BC3BC2D-6B82-4968-A384-7A88A0186D79@gandreas.com> On May 16, 2005, at 2:12 PM, Ronald Oussoren wrote: > > On 16-mei-2005, at 20:53, gandreas at gandreas.com wrote: > >>> >>> NO! That is really really horribly bad to do. Working around a >>> bug in PyObjC by writing code that will break in correct versions >>> of PyObjC is absolutely horrible. You should NEVER release the >>> lock unless you own it. >>> >>> >>> >> >> Here, then, is probably the heart of the problem - the interactions >> between python threads spawned by threading.Thread and the main >> (objc) thread and performSelectorOnMainThread are "undefined", and >> the more I look at it, the more it appears that using >> threading.Thread in a PyObjC app is a bad idea and should probably >> just be chalked up as "unsupported and probably won't work". It >> appears that I'd need to build something on top of NSThread (in >> Objective-C) with explicit thread state handling to get this to work >> consistently and correctly. >> > > Threading.Thread should work as long as Cocoa knows that the > application is > multithreaded or you don't call Cocoa outside of the main thread. (See > http://developer.apple.com/documentation/Cocoa/Conceptual/ > Multithreading/index.html#//apple_ref/doc/uid/10000057i, > threading.Thread uses POSIX threads) > The problem isn't the Cocoa threads (Cocoa knows that the application is multithreaded). The problem is that the python code that is executing in a threading.Thread calls performSelectorOnMainThread to do the UI on the main thread (which, since waits for that to complete, blocking the interpreter). The selector called in turn tries to interpret additional Python code, but can't because the lock is held by the blocked threading.Thread and a simple case of deadlock occurs. If something from threading.Thread calls a "pure" Objective-C routine via performSelectorOnMainThread there is no problem (as far as I've seen so far) - it's only when that routine wants to execute additional python code that there is a problem. Glenn Andreas gandreas at gandreas.com oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From ronaldoussoren at mac.com Mon May 16 21:39:07 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 16 May 2005 21:39:07 +0200 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <6BC3BC2D-6B82-4968-A384-7A88A0186D79@gandreas.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> <7E912E18-B126-415C-881F-7DCD224935B2@mac.com> <6BC3BC2D-6B82-4968-A384-7A88A0186D79@gandreas.com> Message-ID: <80F69A4F-FDAE-406F-8DC8-34706F1D0E00@mac.com> On 16-mei-2005, at 21:28, gandreas at gandreas.com wrote: > > On May 16, 2005, at 2:12 PM, Ronald Oussoren wrote: > > >> >> On 16-mei-2005, at 20:53, gandreas at gandreas.com wrote: >> >> >>>> >>>> NO! That is really really horribly bad to do. Working around a >>>> bug in PyObjC by writing code that will break in correct versions >>>> of PyObjC is absolutely horrible. You should NEVER release the >>>> lock unless you own it. >>>> >>>> >>>> >>>> >>> >>> Here, then, is probably the heart of the problem - the interactions >>> between python threads spawned by threading.Thread and the main >>> (objc) thread and performSelectorOnMainThread are "undefined", and >>> the more I look at it, the more it appears that using >>> threading.Thread in a PyObjC app is a bad idea and should probably >>> just be chalked up as "unsupported and probably won't work". It >>> appears that I'd need to build something on top of NSThread (in >>> Objective-C) with explicit thread state handling to get this to work >>> consistently and correctly. >>> >>> >> >> Threading.Thread should work as long as Cocoa knows that the >> application is >> multithreaded or you don't call Cocoa outside of the main thread. >> (See >> http://developer.apple.com/documentation/Cocoa/Conceptual/ >> Multithreading/index.html#//apple_ref/doc/uid/10000057i, >> threading.Thread uses POSIX threads) >> >> > > The problem isn't the Cocoa threads (Cocoa knows that the > application is multithreaded). The problem is that the python code > that is executing in a threading.Thread calls > performSelectorOnMainThread to do the UI on the main thread (which, > since waits for that to complete, blocking the interpreter). The > selector called in turn tries to interpret additional Python code, > but can't because the lock is held by the blocked threading.Thread > and a simple case of deadlock occurs. That should never occur. All calls into ObjC should give up the GIL. That is, during 'performSelectorOnMainThread' the GIL should be free for the taking, and the mail thread should be able to pick it up. If that doesn't work you ran into a bug in PyObjC (or python itself, we have had problems with GIL-related code in the past). You'd run into the same problem using NSThread. It would be really helpful if you could test using PyObjC SVN head both with Python 2.3 and with Python 2.4. > > If something from threading.Thread calls a "pure" Objective-C > routine via performSelectorOnMainThread there is no problem (as far > as I've seen so far) - it's only when that routine wants to execute > additional python code that there is a problem. > > Glenn Andreas gandreas at gandreas.com > oh my! > quadrium | build, mutate, evolve | images, textures, backgrounds, art > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050516/7d5be020/smime.bin From ronaldoussoren at mac.com Mon May 16 21:44:15 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 16 May 2005 21:44:15 +0200 Subject: [Pythonmac-SIG] Python 2.4, test_long failing? Message-ID: <51E18639-D5CF-40E2-A6C9-7B6F4AE29A66@mac.com> I'm building Python 2.4.1 from source (--enable-framework) and noticed that test_long is failing. Is anyone having this problem? $ sw_vers ProductName: Mac OS X ProductVersion: 10.4 BuildVersion: 8A428 $ make test ... test_long test test_long failed -- 9007199254740991.0 9007199254740991L 0 -1 test_long_future ... This occurs without any specials CFLAGS. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050516/74078a44/smime.bin From bob at redivi.com Mon May 16 21:58:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 15:58:20 -0400 Subject: [Pythonmac-SIG] Python 2.4, test_long failing? In-Reply-To: <51E18639-D5CF-40E2-A6C9-7B6F4AE29A66@mac.com> References: <51E18639-D5CF-40E2-A6C9-7B6F4AE29A66@mac.com> Message-ID: On May 16, 2005, at 3:44 PM, Ronald Oussoren wrote: > I'm building Python 2.4.1 from source (--enable-framework) and > noticed that test_long is failing. Is anyone having this problem? > > $ sw_vers > ProductName: Mac OS X > ProductVersion: 10.4 > BuildVersion: 8A428 > > $ make test > ... > test_long > test test_long failed -- 9007199254740991.0 9007199254740991L 0 -1 > test_long_future > ... This is a bug in 8A428. I discovered this before the release (but apparently not soon enough). It's an obvious bug in the implementation of modf, which is one of the things that I would expect to be fixed in Mac OS X 10.4.1 (you might want to check for seeds if you have a key). I publicly documented this a couple weeks ago: http://bob.pythonmac.org/archives/2005/05/01/python-on-mac-os-x-104- tiger/ -bob From gandreas at gandreas.com Mon May 16 22:29:35 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Mon, 16 May 2005 15:29:35 -0500 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <80F69A4F-FDAE-406F-8DC8-34706F1D0E00@mac.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> <7E912E18-B126-415C-881F-7DCD224935B2@mac.com> <6BC3BC2D-6B82-4968-A384-7A88A0186D79@gandreas.com> <80F69A4F-FDAE-406F-8DC8-34706F1D0E00@mac.com> Message-ID: <12133CDF-F7AE-4B7C-A7D5-5BF3210965F6@gandreas.com> On May 16, 2005, at 2:39 PM, Ronald Oussoren wrote: > > On 16-mei-2005, at 21:28, gandreas at gandreas.com wrote: > >> The problem isn't the Cocoa threads (Cocoa knows that the >> application is multithreaded). The problem is that the python >> code that is executing in a threading.Thread calls >> performSelectorOnMainThread to do the UI on the main thread >> (which, since waits for that to complete, blocking the >> interpreter). The selector called in turn tries to interpret >> additional Python code, but can't because the lock is held by the >> blocked threading.Thread and a simple case of deadlock occurs. >> > > That should never occur. All calls into ObjC should give up the > GIL. That is, during 'performSelectorOnMainThread' the GIL should > be free for the taking, and the mail thread should be able to pick > it up. If that doesn't work you ran into a bug in PyObjC (or python > itself, we have had problems with GIL-related code in the past). > You'd run into the same problem using NSThread. > I'm more than willing to admit that there is some other problem here with threading, GIL, etc... and that what I'm seeing is only another symptom of that bigger problem, because I just discovered that if I do the "debug using the local interpreter and absolutely no extra threads ever generated for anything" I get: Fatal Python error: PyThreadState_Get: no current thread so it's probably something bad as a result of updating to Tiger (I know there was a perfectly fine main thread which way up the call chain responded to the menu command to start debugging, executed a boatload of python code, and then loaded a NIB and in that awakeFromNib a call to PyImport_AddModule sent it screaming down to SIGABRT land): #0 0x9004a10c in kill () #1 0x90120934 in abort () #2 0x9879d774 in Py_FatalError () #3 0x9879a884 in PyThreadState_Get () #4 0x98791f48 in PyImport_GetModuleDict () #5 0x98792708 in PyImport_AddModule () #6 0x00008858 in -[PyInteractive awakeFromNib] (self=0x5800fa0, _cmd=0x0) at /Volumes/YWork1/PyOXIDE/Source/PyInteractive.mm:130 #7 0x92886788 in -[NSSet makeObjectsPerformSelector:] () #8 0x93636174 in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] () #9 0x9370cdc4 in old_loadNib () #10 0x93621fd0 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] () #11 0x9367923c in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] () #12 0x9370cb68 in -[NSWindowController loadWindow] () #13 0x9370c88c in -[NSWindowController window] () #14 0x04a008f8 in _ffi_call_DARWIN () at /Users/ronald/Projects/ pyobjc-1.2/pyobjc/libffi-src/src/powerpc/darwin.S:118 #15 0x04a002ec in ffi_call (cif=0x0, fn=0x39, rvalue=0xa00042b0, avalue=0xffffffff) at /Users/ronald/Projects/pyobjc-1.2/pyobjc/libffi- src/src/powerpc/ffi_darwin.c:395 #16 0x049ebeac in PyObjCFFI_Caller (aMeth=0x5754368, self=0x5145d10, args=0x0) at Modules/objc/libffi_support.m:1228 #17 0x049fca24 in objcsel_call (self=0x5754368, args=0x1759030) at Modules/objc/selector.m:502 #18 0x9871e8e0 in PyObject_Call () #19 0x9877e35c in PyEval_GetFuncDesc () #20 0x9877dd4c in PyEval_GetFuncDesc () #21 0x9877b414 in PyEval_EvalCode () #22 0x9877c5e4 in PyEval_EvalCodeEx () #23 0x98733530 in PyFunction_SetClosure () #24 0x9871e8e0 in PyObject_Call () #25 0x049fd1dc in pysel_call (self=0x5130060, args=0x0, kwargs=0x0) at Modules/objc/selector.m:958 #26 0x9871e8e0 in PyObject_Call () #27 0x9877e35c in PyEval_GetFuncDesc () #28 0x9877dd4c in PyEval_GetFuncDesc () #29 0x9877b414 in PyEval_EvalCode () #30 0x9877dedc in PyEval_GetFuncDesc () #31 0x9877dd34 in PyEval_GetFuncDesc () #32 0x9877b414 in PyEval_EvalCode () #33 0x9877c5e4 in PyEval_EvalCodeEx () #34 0x9877df90 in PyEval_GetFuncDesc () #35 0x9877dd34 in PyEval_GetFuncDesc () #36 0x9877b414 in PyEval_EvalCode () #37 0x9877dedc in PyEval_GetFuncDesc () #38 0x9877dd34 in PyEval_GetFuncDesc () #39 0x9877b414 in PyEval_EvalCode () #40 0x9877c5e4 in PyEval_EvalCodeEx () #41 0x98733530 in PyFunction_SetClosure () #42 0x9871e8e0 in PyObject_Call () #43 0x98726af4 in PyMethod_New () #44 0x9871e8e0 in PyObject_Call () #45 0x9871eb8c in PyObject_CallMethod () #46 0x0000b450 in -[NSDocument(NSDocumentPyHandler) pythonOnHandler:] (self=0x512e1c0, _cmd=0x0, sender=0xa00042b0) at /Volumes/YWork1/ PyOXIDE/Source/NSDocumentPyHandler.mm:181 #47 0x936bd274 in -[NSApplication sendAction:to:from:] () #48 0x93717a70 in -[NSMenu performActionForItemAtIndex:] () #49 0x937177f4 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] () #50 0x9371729c in -[NSMenu performKeyEquivalent:] () #51 0x93716e7c in -[NSApplication _handleKeyEquivalent:] () #52 0x93620c70 in -[NSApplication sendEvent:] () #53 0x936185d0 in -[NSApplication run] () #54 0x93708e04 in NSApplicationMain () #55 0x00007944 in _start (argc=1, argv=0xbffff99c, envp=0xbffff9a4) at /SourceCache/Csu/Csu-46/crt.c:267 #56 0x000077b8 in start () > It would be really helpful if you could test using PyObjC SVN head > both with Python 2.3 and with Python 2.4. > It's on the list. Glenn Andreas gandreas at gandreas.com oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From gandreas at gandreas.com Mon May 16 22:32:16 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Mon, 16 May 2005 15:32:16 -0500 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <1BA143FA-91F4-4C83-815C-B9CC13E61773@redivi.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> <1BA143FA-91F4-4C83-815C-B9CC13E61773@redivi.com> Message-ID: <60F28BB1-FA27-4F8B-8FED-47012398ECDC@gandreas.com> On May 16, 2005, at 2:22 PM, Bob Ippolito wrote: > > On May 16, 2005, at 2:53 PM, gandreas at gandreas.com wrote: > >> I should be able to directly send the signal from the IDE to the >> targeted app (since it's a child of the IDE), and the standard >> "catch a unix signal invokes the debugger" action should work >> (since the debugger interface on the client talks back to the IDE). >> > > Yeah, this will work fine. I'm just saying, that if you wanted > something even more decoupled (to implement remote debugging, > plugin debugging, objc.inject debugging, etc.), then that's how you > could do it. > That's an _excellent_ suggestion! The thought of debugging an already running application would be extremely useful.... Of course, I have to get the thing working for the standard case first. Glenn Andreas gandreas at gandreas.com oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From bob at redivi.com Mon May 16 22:40:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 16:40:48 -0400 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <12133CDF-F7AE-4B7C-A7D5-5BF3210965F6@gandreas.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> <7E912E18-B126-415C-881F-7DCD224935B2@mac.com> <6BC3BC2D-6B82-4968-A384-7A88A0186D79@gandreas.com> <80F69A4F-FDAE-406F-8DC8-34706F1D0E00@mac.com> <12133CDF-F7AE-4B7C-A7D5-5BF3210965F6@gandreas.com> Message-ID: <97F1F98A-E2D0-461F-86C4-486CD3937E81@redivi.com> On May 16, 2005, at 4:29 PM, gandreas at gandreas.com wrote: > On May 16, 2005, at 2:39 PM, Ronald Oussoren wrote: > > >> On 16-mei-2005, at 21:28, gandreas at gandreas.com wrote: >> >> >>> The problem isn't the Cocoa threads (Cocoa knows that the >>> application is multithreaded). The problem is that the python >>> code that is executing in a threading.Thread calls >>> performSelectorOnMainThread to do the UI on the main thread >>> (which, since waits for that to complete, blocking the >>> interpreter). The selector called in turn tries to interpret >>> additional Python code, but can't because the lock is held by the >>> blocked threading.Thread and a simple case of deadlock occurs. >> >> That should never occur. All calls into ObjC should give up the >> GIL. That is, during 'performSelectorOnMainThread' the GIL should >> be free for the taking, and the mail thread should be able to pick >> it up. If that doesn't work you ran into a bug in PyObjC (or >> python itself, we have had problems with GIL-related code in the >> past). You'd run into the same problem using NSThread. > > I'm more than willing to admit that there is some other problem > here with threading, GIL, etc... and that what I'm seeing is only > another symptom of that bigger problem, because I just discovered > that if I do the "debug using the local interpreter and absolutely > no extra threads ever generated for anything" I get: > > Fatal Python error: PyThreadState_Get: no current thread > > so it's probably something bad as a result of updating to Tiger (I > know there was a perfectly fine main thread which way up the call > chain responded to the menu command to start debugging, executed a > boatload of python code, and then loaded a NIB and in that > awakeFromNib a call to PyImport_AddModule sent it screaming down to > SIGABRT land): You're probably not embedding Python correctly. You should really be using a Python-based py2app generated plugin, as it saves you the trouble of figuring out how to do it correctly. The procedure is documented in the embedding tutorial: http://svn.red-bean.com/pyobjc/trunk/pyobjc/Doc/tutorial_embed/ extending_objc_with_python.html Using this approach, you shouldn't have to write a SINGLE LINE of Python C API code anywhere in your application. You simply define classes in your plugin and use -[NSBundle classNamed:] or NSClassFromString() to get references to them from the Objective-C shell. PyObjC will take care of doing all the rest, and py2app's plugin bootstrap takes care of initializing Python properly. The added bonus is that py2app will go through the trouble of embedding Python itself and the subset of the standard library (if not using the /System Python) as well as third party extensions you use (always)... so you automatically have a complete and rather isolated (depending on whether you use the system python or not) environment so that users won't break your app accidentally. -bob From bob at redivi.com Mon May 16 22:47:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 16:47:41 -0400 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <60F28BB1-FA27-4F8B-8FED-47012398ECDC@gandreas.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> <1BA143FA-91F4-4C83-815C-B9CC13E61773@redivi.com> <60F28BB1-FA27-4F8B-8FED-47012398ECDC@gandreas.com> Message-ID: <023B0930-BF60-45B6-9E2D-23A27EFAD701@redivi.com> On May 16, 2005, at 4:32 PM, gandreas at gandreas.com wrote: > > On May 16, 2005, at 2:22 PM, Bob Ippolito wrote: > > >> >> On May 16, 2005, at 2:53 PM, gandreas at gandreas.com wrote: >> >> >>> I should be able to directly send the signal from the IDE to the >>> targeted app (since it's a child of the IDE), and the standard >>> "catch a unix signal invokes the debugger" action should work >>> (since the debugger interface on the client talks back to the IDE). >> >> Yeah, this will work fine. I'm just saying, that if you wanted >> something even more decoupled (to implement remote debugging, >> plugin debugging, objc.inject debugging, etc.), then that's how you >> could do it. > > That's an _excellent_ suggestion! The thought of debugging an > already running application would be extremely useful.... This is, more or less, the raison d'?tre for objc.inject. Since it can load into an arbitrary thread, it's possible to even use it to inject a debugging stub into an unknowing Python application (beyond the uses of injecting into an Objective-C application, since PyObjC ostensibly turns Objective-C applications into Python one from the interpreter's perspective). It's tricky, of course, but possible. -bob From jnutting at gmail.com Mon May 16 23:32:46 2005 From: jnutting at gmail.com (Jack Nutting) Date: Mon, 16 May 2005 23:32:46 +0200 Subject: [Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread In-Reply-To: <1BA143FA-91F4-4C83-815C-B9CC13E61773@redivi.com> References: <65FC1DDC-AE1C-4FE1-AFB2-909990156D2E@gandreas.com> <1950CDA6-DDF6-4665-9A20-1F2EF49A0D20@gandreas.com> <1BA143FA-91F4-4C83-815C-B9CC13E61773@redivi.com> Message-ID: > > Including an entire "custom" version of Python just seems like a > > bad solution to me. It may be the only solution, depending on > > various other circumstances, but it seems kind of sad to say "well, > > OS X ships with Python.framework, but it can't be used to write a > > Python IDE". > > Mac OS X 10.3 and 10.4 ship with a Python 2.3 framework. Mac OS X > 10.5 (hopefully) will not. Do you want to have to maintain separate > versions of your app for 10.3-10.4 and 10.5, so as to use the > standard Python? I'd like to heartily second (or third, or fourth) this sentiment. As I've discovered just from releasing my simple pygame games (which don't jump through any of the hoops you need to do with PyOXIDE), relying on Apple-supplied python is probably innappropriate for all but the very simplest python applicaions (e.g. simple utility scripts and the like). Apple dangles that Python.framework carrot there, but if you want to make software that runs on more than one version of Mac OS X, the framework does you no good, and in fact lulls you into a false sense of security, making you think that you're being a good citizen by using a built-in resource that will carry you along to future versions (which it most certainly will NOT). -- // jack From jduhamel at gmail.com Tue May 17 01:56:22 2005 From: jduhamel at gmail.com (Joe Duhamel) Date: Tue, 17 May 2005 08:56:22 +0900 Subject: [Pythonmac-SIG] AddressBook Question. Message-ID: <352b6a9105051616561e6dec50@mail.gmail.com> All, I know this is a novice question but I'm trying to create a new group using the python pyobjc module. I'm ure I've made a juvenile mistake but help would be appreciated. -Joe if undefined is None: undefined = ABGroup.alloc().init() undefined.setValueForProperty_("GroupName") = "UnDefined" ** Causes obvious error. book.addGroup(undefined) From bob at redivi.com Tue May 17 02:06:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 20:06:42 -0400 Subject: [Pythonmac-SIG] AddressBook Question. In-Reply-To: <352b6a9105051616561e6dec50@mail.gmail.com> References: <352b6a9105051616561e6dec50@mail.gmail.com> Message-ID: <48794837-FCF3-4D17-8E53-495038DE9637@redivi.com> On May 16, 2005, at 7:56 PM, Joe Duhamel wrote: > All, > I know this is a novice question but I'm trying to create a new group > using the python pyobjc module. I'm ure I've made a juvenile mistake > but help would be appreciated. > > > -Joe > > if undefined is None: > undefined = ABGroup.alloc().init() > undefined.setValueForProperty_("GroupName") = "UnDefined" ** > Causes > obvious error. > book.addGroup(undefined) That's not even valid Python syntax! undefined.setValue_forProperty_("GroupName", "UnDefined") I suggest you read the PyObjC documentation... -bob From bob at redivi.com Tue May 17 02:16:17 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 20:16:17 -0400 Subject: [Pythonmac-SIG] Python 2.4, test_long failing? In-Reply-To: References: <51E18639-D5CF-40E2-A6C9-7B6F4AE29A66@mac.com> Message-ID: On May 16, 2005, at 3:58 PM, Bob Ippolito wrote: > > On May 16, 2005, at 3:44 PM, Ronald Oussoren wrote: > > >> I'm building Python 2.4.1 from source (--enable-framework) and >> noticed that test_long is failing. Is anyone having this problem? >> >> $ sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.4 >> BuildVersion: 8A428 >> >> $ make test >> ... >> test_long >> test test_long failed -- 9007199254740991.0 9007199254740991L 0 -1 >> test_long_future >> ... >> > > This is a bug in 8A428. I discovered this before the release (but > apparently not soon enough). It's an obvious bug in the > implementation of modf, which is one of the things that I would > expect to be fixed in Mac OS X 10.4.1 (you might want to check for > seeds if you have a key). Let me rephrase that -- check Software Update . This has been fixed, though the 10.4.1 notes don't mention the modf specifically. The seed notes did. -bob From bob at redivi.com Tue May 17 02:49:29 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 May 2005 20:49:29 -0400 Subject: [Pythonmac-SIG] AddressBook Question. In-Reply-To: <352b6a91050516173665b080dd@mail.gmail.com> References: <352b6a9105051616561e6dec50@mail.gmail.com> <48794837-FCF3-4D17-8E53-495038DE9637@redivi.com> <352b6a91050516173665b080dd@mail.gmail.com> Message-ID: Yeah, that is the correct argument order, I wasn't paying attention to the arguments, I copied those in the order you wrote them. The name of the selector and the syntax were what I noticed as being obviously wrong. I highly suggest you read the Introduction to PyObjC document until you understand it. If you have any questions, feel free to ask... -bob On May 16, 2005, at 8:36 PM, Joe Duhamel wrote: > Bob, > I started with the PyObjC doc's. Obviously there was something in > there that I did not understand. I'm trying to figure out how to do a > setValue and failing. I've looked through all of the example code and > have been a bit lost. I'm guessing the properties goes to a key and > that it's actually. > undefined.setValue_forKey_("Undefined","GroupName"). > -Joe > > > > > On 5/17/05, Bob Ippolito wrote: > >> >> On May 16, 2005, at 7:56 PM, Joe Duhamel wrote: >> >> >>> All, >>> I know this is a novice question but I'm trying to create a new >>> group >>> using the python pyobjc module. I'm ure I've made a juvenile mistake >>> but help would be appreciated. >>> >>> >>> -Joe >>> >>> if undefined is None: >>> undefined = ABGroup.alloc().init() >>> undefined.setValueForProperty_("GroupName") = "UnDefined" ** >>> Causes >>> obvious error. >>> book.addGroup(undefined) >>> >> >> That's not even valid Python syntax! >> >> undefined.setValue_forProperty_("GroupName", "UnDefined") >> >> I suggest you read the PyObjC documentation... >> >> -bob >> >> > From lee_cullens at mac.com Tue May 17 06:25:03 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 17 May 2005 00:25:03 -0400 Subject: [Pythonmac-SIG] Python Interest Group Query Message-ID: <4F168B88-40B1-4638-898B-D166E565896A@mac.com> Python Interest Group Query I'm aware of the Boston PIG, a smaller one in Amherst and have been told that there is possibly a PIG in Manchester, NH. Basically I'm trying to find out if there are any, or any interest in (or even any other Python users at all :~)) in a PIG in the northern NE corridor (Vermont, New Hampshire, Maine). I'm a recent Mac and Python convert working at some multimedia software development, and retired from a software engineering career. I live in western NH and back in the late 80's commuted to Boston and NY, so I'm not very keen on such anymore :~) Thank you, Lee C From delza at livingcode.org Tue May 17 20:49:20 2005 From: delza at livingcode.org (Dethe Elza) Date: Tue, 17 May 2005 11:49:20 -0700 Subject: [Pythonmac-SIG] Wrapping a framework Message-ID: <411F09BB-32B5-40AC-92BA-501DCCEF3438@livingcode.org> Hi folks, I've wrapped a couple of frameworks using the following idiom with no problem, but now I'm trying to wrap the framework that comes with Skype and it's refusing to load the bundle. Any ideas what I could be doing wrong? # Contents of Skype/__init__.py in path: import objc, AppKit, Foundation, os if 'site-packages.zip' in __file__: base_path = os.path.join(os.path.dirname(os.getcwd()), 'Frameworks') else: base_path = '/Applications/Skype.app/Contents/Frameworks' # I have also tried moving the framework to /Library/Frameworks and using that path, with the same result bundle_path = os.path.abspath(os.path.join(base_path, 'Skype.framework')) objc.loadBundle('Skype', globals(), bundle_path=bundle_path) del objc, AppKit, Foundation, os, base_path, bundle_path # End of __init__.py >>> import Skype Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/Skype/__init__.py", line 7, in ? objc.loadBundle('Skype', globals(), bundle_path=bundle_path) ImportError: Bundle could not be loaded --Dethe "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. " --Brian Kernighan From sw at wordtech-software.com Wed May 18 05:42:36 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue, 17 May 2005 23:42:36 -0400 Subject: [Pythonmac-SIG] Apple Help Book for Python 2.4.1 Message-ID: <428AB9AC.4000004@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those using Bob's Python 2.4.1 build, I've packaged an Apple Help Book with the official Python docs that can be accessed from PythonIDE: this is the same functionality that Jack provided for Python 2.3 via Package Manager, meaning that you can both load and search the docs from PythonIDE. You can download the package at http://www.wordtech-software.com/python.html --just scroll down the page for the link. It's an Apple installer, which places the files in /Applications/MacPython-2.4/PythonIDE/Contents/Resources/English.lproj. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCirmrJmdQs+6YVcoRArG+AJ9KhYsXterMJbqTN1+W39nhihfa9ACfeawL l9BDilKDg43Rcstp4w2fCwE= =0UTc -----END PGP SIGNATURE----- From sw at wordtech-software.com Wed May 18 05:45:22 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue, 17 May 2005 23:45:22 -0400 Subject: [Pythonmac-SIG] Performance improvement in Python 2.4.1/wxPython 2.6? Message-ID: <428ABA52.7080104@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has anyone using wxPython libraries noticed a performance improvement in Bob's Python 2.4.1 build and wxPython 2.6? I'm working on some new versions of the wxPython apps I maintain, and they seem less crash-prone when linking against the latest and greatest than the Apple-shipped Python/wxPython. If others are noticing this, I may rethink my decision about supporting only the Apple installation. Please let me know your comments. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCirpRJmdQs+6YVcoRAuUeAJ4yx+sCUMYpH+Aon32zycM6lLnjMwCfTrSS xJ+Zy+RBFCE4iHt+ouoaRaI= =eF1K -----END PGP SIGNATURE----- From bob at redivi.com Wed May 18 06:17:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 May 2005 00:17:26 -0400 Subject: [Pythonmac-SIG] Performance improvement in Python 2.4.1/wxPython 2.6? In-Reply-To: <428ABA52.7080104@wordtech-software.com> References: <428ABA52.7080104@wordtech-software.com> Message-ID: <04558DD2-1DE5-4A4B-BB92-799F6A37FB9E@redivi.com> On May 17, 2005, at 11:45 PM, Kevin Walzer wrote: > Has anyone using wxPython libraries noticed a performance > improvement in > Bob's Python 2.4.1 build and wxPython 2.6? I'm working on some new > versions of the wxPython apps I maintain, and they seem less crash- > prone > when linking against the latest and greatest than the Apple-shipped > Python/wxPython. If others are noticing this, I may rethink my > decision > about supporting only the Apple installation. Please let me know your > comments. In general, Python 2.4 is noticeably faster than Python 2.3. I don't know of a single case where it got slower, and I know of many cases where it got a lot faster. I think on average, it's like 30% faster... the usual disclaimers about statistics and benchmarks apply, but it *is* faster in every case I've ever seen. As for stability, there is at least one known threading bug with Python 2.3.0 that may cause certain kinds of deadlocks or crashes when using something like wxPython (we ran across it in PyObjC.. the fix is to not use Python 2.3.0 :). Python 2.3.5 doesn't have this bug in particular, but who knows what others it may have and who knows IF fixes will ever be backported, since it has basically reached its end of life. For wxPython, I certainly would always want to use the latest and greatest on the Mac. They have yet to make a Mac release that I would consider release quality. -bob From delza at livingcode.org Wed May 18 20:05:29 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed, 18 May 2005 11:05:29 -0700 Subject: [Pythonmac-SIG] Frameworks which won't import Message-ID: <5F7CCAEF-577D-4458-9300-4A3554CB89AE@livingcode.org> Let me try to rephrase my question. I have a framework which I can't import into PyObjC in the usual way. Since then I've tried various other frameworks I've found on my system, mostly embedded in application bundles, and some import but others do not. I'm not getting any information on *why* they can't be imported, even when I turn on debugging with the following lines before any attempt to load bundles. from PyObjCTools import Debugging Debugging.installVerboseExceptionHandler() Here are the questions: * What can I do to find out why a bundle wouldn't load? * Are there common, expected reasons for a framework bundle to not load? * Is there anything I can do about it? Now, as far as the Skype framework itself is concerned, I realized I'm using a Beta and downloaded the earlier, stable release, which does not have embedded frameworks. Thanks! --Dethe From bob at redivi.com Wed May 18 20:14:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 May 2005 14:14:35 -0400 Subject: [Pythonmac-SIG] Frameworks which won't import In-Reply-To: <5F7CCAEF-577D-4458-9300-4A3554CB89AE@livingcode.org> References: <5F7CCAEF-577D-4458-9300-4A3554CB89AE@livingcode.org> Message-ID: <216B1BBD-6634-4E9D-8D99-BA9DF08C9D1C@redivi.com> On May 18, 2005, at 2:05 PM, Dethe Elza wrote: > I have a framework which I can't import into PyObjC in the usual > way. Since then I've tried various other frameworks I've found on my > system, mostly embedded in application bundles, and some import but > others do not. I'm not getting any information on *why* they can't > be imported, even when I turn on debugging with the following lines > before any attempt to load bundles. > > from PyObjCTools import Debugging > Debugging.installVerboseExceptionHandler() This logs Objective-C exceptions, not linker errors. It's not going to do anything for you unless the problem is due to a +load or something (which, I have never seen). It's more or less a case of getting what you deserve, trying to load embedded frameworks from applications that were never meant for external use. They probably depend on symbols defined in the executable or something. > Here are the questions: > > * What can I do to find out why a bundle wouldn't load? Not much. > * Are there common, expected reasons for a framework bundle to not > load? Not really. > * Is there anything I can do about it? Probably not. -bob From delza at livingcode.org Wed May 18 20:41:30 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed, 18 May 2005 11:41:30 -0700 Subject: [Pythonmac-SIG] Frameworks which won't import In-Reply-To: <216B1BBD-6634-4E9D-8D99-BA9DF08C9D1C@redivi.com> References: <5F7CCAEF-577D-4458-9300-4A3554CB89AE@livingcode.org> <216B1BBD-6634-4E9D-8D99-BA9DF08C9D1C@redivi.com> Message-ID: <18449480-C54F-4B68-8A50-126F4A9B9B0A@livingcode.org> > It's more or less a case of getting what you deserve, trying to > load embedded frameworks from applications that were never meant > for external use. They probably depend on symbols defined in the > executable or something. OK, thanks. At least I know to give up that route and try another way. --Dethe From ronaldoussoren at mac.com Wed May 18 21:10:24 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 18 May 2005 21:10:24 +0200 Subject: [Pythonmac-SIG] ANN: PyObjC 1.3.5 Message-ID: <38E1EC3A-10B7-41BF-B2EA-32B28460058B@mac.com> PyObjC 1.3.5 is now available for download at http:// pyobjc.sourceforge.net/ PyObjC is a bridge between Python and Objective-C. It allows full featured Cocoa applications to be written in pure Python. It is also easy to use other frameworks containing Objective-C class libraries from Python and to mix in Objective-C, C and C++ source. Python is a highly dynamic programming language with a shallow learning curve. It combines remarkable power with very clear syntax. The installer package includes a number of Xcode templates for easily creating new Cocoa-Python projects, as well as py2app, a suite of tools for building redistributable Python applications and plugins. PyObjC also supports full introspection of Objective-C classes and direct invocation of Objective-C APIs from the interactive interpreter. PyObjC requires Mac OS X 10.2 or later and Python 2.3 or later. PyObjC works with the Apple provided Python installation in Mac OS X 10.3 (and later), MacPython 2.3, and MacPython 2.4. This release features several bugfixes, improved documentation, new Xcode templates, Tiger support and many major enhancements. See the news file at http://pyobjc.sourceforge.net/NEWS-1.3.5.txt for more information. PyObjC is released with an open source license (MIT style). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050518/c62cfba5/smime.bin From bob at redivi.com Wed May 18 21:57:27 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 May 2005 15:57:27 -0400 Subject: [Pythonmac-SIG] ANN: py2app 0.2 Message-ID: `py2app 0.2`_ is a minor bug fix release. You can download it from `pythonmac.org packages`_. `PyObjC`_ 1.3.5 ships with py2app 0.2, so if you have that, you have already upgraded to py2app 0.2! .. _`py2app 0.2`: http://undefined.org/python/#py2app .. _`pythonmac.org packages`: http://pythonmac.org/packages/ .. _`PyObjC 1.3.5`: http://pyobjc.sourceforge.net/ Functional changes: - New datamodels option to support CoreData. Compiles .xcdatamodel files and places them in the Resources dir (as .mom). - New use-pythonpath option. The py2app application bootstrap will no longer use entries from PYTHONPATH unless this option is used. - py2app now persists information about the build environment (python version, executable, build style, etc.) in the Info.plist and will clean the executable before rebuilding if anything at all has changed. - bdist_mpkg now builds packages with the full platform info, so that installing a package for one platform combination will not look like an upgrade to another platform combination. Bug Fixes: - Fixed a bug in standalone building, where a rebuild could cause an unlaunchable executable. - Plugin bootstrap should compile/link correctly with gcc 4. - Plugin bootstrap no longer sets PYTHONHOME and will restore PYTHONPATH after initialization. - Plugin bootstrap swaps out thread state upon plug-in load if it is the first to initialize Python. This fixes threading issues. From kevino at tulane.edu Wed May 18 22:02:30 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed, 18 May 2005 13:02:30 -0700 Subject: [Pythonmac-SIG] Performance improvement in Python 2.4.1/wxPython 2.6? In-Reply-To: <428ABA52.7080104@wordtech-software.com> References: <428ABA52.7080104@wordtech-software.com> Message-ID: Hi Kevin, On May 17, 2005, at 8:45 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Has anyone using wxPython libraries noticed a performance > improvement in > Bob's Python 2.4.1 build and wxPython 2.6? I'm working on some new > versions of the wxPython apps I maintain, and they seem less crash- > prone > when linking against the latest and greatest than the Apple-shipped > Python/wxPython. If others are noticing this, I may rethink my > decision > about supporting only the Apple installation. Please let me know your > comments. It's very likely that improvements to wxWidgets have contributed to this. 2.5.3 is six months old, and considering the rate at which the Mac port has been moving, that's a very long time. Particularly since the last couple months have been focused on bug fixing. Had we known Apple was bundling wx we probably could have pushed a few things off and moved the bug testing up... Unfortunately, we didn't, so the wxPython included with Tiger is missing out on a lot of good bug fixes. ;-/ Thanks, Kevin > - -- > Cheers, > > Kevin Walzer, PhD > WordTech Software--Open Source Applications and Packages for OS X > http://www.wordtech-software.com > http://www.smallbizmac.com > http://www.kevin-walzer.com > mailto:sw at wordtech-software.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFCirpRJmdQs+6YVcoRAuUeAJ4yx+sCUMYpH+Aon32zycM6lLnjMwCfTrSS > xJ+Zy+RBFCE4iHt+ouoaRaI= > =eF1K > -----END PGP SIGNATURE----- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From bob at redivi.com Wed May 18 22:10:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 May 2005 16:10:55 -0400 Subject: [Pythonmac-SIG] [Pyobjc-dev] ANN: PyObjC 1.3.5 In-Reply-To: <38E1EC3A-10B7-41BF-B2EA-32B28460058B@mac.com> References: <38E1EC3A-10B7-41BF-B2EA-32B28460058B@mac.com> Message-ID: <7FAA31BB-7246-43A0-ADF2-1BF36B51CBBD@redivi.com> On May 18, 2005, at 3:10 PM, Ronald Oussoren wrote: > PyObjC 1.3.5 is now available for download at http:// > pyobjc.sourceforge.net/ DO NOT DOWNLOAD THIS YET. There is a mistake in the release, it includes the wrong version of py2app (0.1.9), which means that the Xcode templates are probably broken and it does not implement all of the features it advertises! We need to take this down and fix it. -bob From ronaldoussoren at mac.com Wed May 18 22:42:05 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 18 May 2005 22:42:05 +0200 Subject: [Pythonmac-SIG] [Pyobjc-dev] ANN: PyObjC 1.3.5 In-Reply-To: <7FAA31BB-7246-43A0-ADF2-1BF36B51CBBD@redivi.com> References: <38E1EC3A-10B7-41BF-B2EA-32B28460058B@mac.com> <7FAA31BB-7246-43A0-ADF2-1BF36B51CBBD@redivi.com> Message-ID: On 18-mei-2005, at 22:10, Bob Ippolito wrote: > > On May 18, 2005, at 3:10 PM, Ronald Oussoren wrote: > > >> PyObjC 1.3.5 is now available for download at http:// >> pyobjc.sourceforge.net/ >> > > DO NOT DOWNLOAD THIS YET. There is a mistake in the release, it > includes the wrong version of py2app (0.1.9), which means that the > Xcode templates are probably broken and it does not implement all > of the features it advertises! > > We need to take this down and fix it. I've uploaded new release files that include py2app 0.2.0 instead of 0.1.9 Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050518/50602a10/smime-0001.bin From mstearne at gmail.com Wed May 18 21:29:15 2005 From: mstearne at gmail.com (Michael Stearne) Date: Wed, 18 May 2005 15:29:15 -0400 Subject: [Pythonmac-SIG] [Pyobjc-dev] ANN: PyObjC 1.3.5 In-Reply-To: <38E1EC3A-10B7-41BF-B2EA-32B28460058B@mac.com> References: <38E1EC3A-10B7-41BF-B2EA-32B28460058B@mac.com> Message-ID: <293e03f0050518122926df5ddb@mail.gmail.com> Looks great! Thanks for the work. Michael On 5/18/05, Ronald Oussoren wrote: > PyObjC 1.3.5 is now available for download at http:// > pyobjc.sourceforge.net/ > > PyObjC is a bridge between Python and Objective-C. It allows full > featured Cocoa applications to be written in pure Python. It is also > easy to use other frameworks containing Objective-C class libraries > from Python and to mix in Objective-C, C and C++ source. > > Python is a highly dynamic programming language with a shallow learning > curve. It combines remarkable power with very clear syntax. > > The installer package includes a number of Xcode templates > for easily creating new Cocoa-Python projects, as well as py2app, > a suite of tools for building redistributable Python applications > and plugins. > > PyObjC also supports full introspection of Objective-C classes and > direct invocation of Objective-C APIs from the interactive interpreter. > > PyObjC requires Mac OS X 10.2 or later and Python 2.3 or later. PyObjC > works with the Apple provided Python installation in Mac OS X 10.3 > (and later), > MacPython 2.3, and MacPython 2.4. > > This release features several bugfixes, improved documentation, new > Xcode > templates, Tiger support and many major enhancements. See the news > file at > http://pyobjc.sourceforge.net/NEWS-1.3.5.txt for more information. > > PyObjC is released with an open source license (MIT style). > > > From jwight_lists at toxicsoftware.com Thu May 19 05:32:43 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Wed, 18 May 2005 23:32:43 -0400 Subject: [Pythonmac-SIG] Python Metadata Importer Message-ID: Version 0.9 (everything done exception final documentation tidy-up) is online at: http://svn.toxicsoftware.com/svn/toxic_public/trunk/Freeware/Python% 20Metadata%20Importer/Releases/Python%20Metadata%20Importer.dmg Source is available from: http://svn.toxicsoftware.com/svn/toxic_public/trunk/Freeware/Python% 20Metadata%20Importer Feedback MOST welcome. Jon. From skip at pobox.com Thu May 19 05:45:27 2005 From: skip at pobox.com (Skip Montanaro) Date: Wed, 18 May 2005 22:45:27 -0500 Subject: [Pythonmac-SIG] Silly question perhaps, but how do I use py2app? Message-ID: <17036.3031.525902.859150@montanaro.dyndns.org> I downloaded and installed py2app this evening. I didn't find an app named "py2app", but did find /usr/local/bin/py2applet. Is that py2app? If not, where is it? I tried running py2applet with no args or with --help. Both times it emitted lines like: running py2app creating /private/tmp/tmpN4iyW5/build creating /private/tmp/tmpN4iyW5/build/bdist.darwin-7.9.0-Power_Macintosh creating /private/tmp/tmpN4iyW5/build/bdist.darwin-7.9.0-Power_Macintosh/python2.4-standalone creating /private/tmp/tmpN4iyW5/build/bdist.darwin-7.9.0-Power_Macintosh/python2.4-standalone/app creating /private/tmp/tmpN4iyW5/build/bdist.darwin-7.9.0-Power_Macintosh/python2.4-standalone/app/collect creating /private/tmp/tmpN4iyW5/build/bdist.darwin-7.9.0-Power_Macintosh/python2.4-standalone/app/temp creating /private/tmp/tmpN4iyW5/dist creating build/bdist.darwin-7.9.0-Power_Macintosh/python2.4-standalone/app/lib-dynload creating build/bdist.darwin-7.9.0-Power_Macintosh/python2.4-standalone/app/Frameworks error: You must specify either app or plugin I'd appreciate some tips on how to use it. Thanks, -- Skip Montanaro skip at pobox.com From bob at redivi.com Thu May 19 05:47:11 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 May 2005 23:47:11 -0400 Subject: [Pythonmac-SIG] Silly question perhaps, but how do I use py2app? In-Reply-To: <17036.3031.525902.859150@montanaro.dyndns.org> References: <17036.3031.525902.859150@montanaro.dyndns.org> Message-ID: <23A12695-AD69-4358-BD6D-5E126B7DABDB@redivi.com> On May 18, 2005, at 11:45 PM, Skip Montanaro wrote: > I downloaded and installed py2app this evening. I didn't find an > app named > "py2app", but did find /usr/local/bin/py2applet. Is that py2app? > If not, > where is it? I tried running py2applet with no args or with -- > help. Both > times it emitted lines like: http://undefined.org/python/py2app.html http://pyobjc.sourceforge.net/doc/tutorial.php -bob From arthur at iaaa.nl Thu May 19 12:10:55 2005 From: arthur at iaaa.nl (Arthur Elsenaar) Date: Thu, 19 May 2005 11:10:55 +0100 Subject: [Pythonmac-SIG] On posting long urls In-Reply-To: References: Message-ID: <31CA1AE4-369B-4EDC-9D3D-7FEF52330F70@iaaa.nl> Hi list, to prevent clickable urls to be broken by wrapping, surround the url by <>. Arthur From jnutting at gmail.com Thu May 19 12:35:56 2005 From: jnutting at gmail.com (Jack Nutting) Date: Thu, 19 May 2005 12:35:56 +0200 Subject: [Pythonmac-SIG] On posting long urls In-Reply-To: <31CA1AE4-369B-4EDC-9D3D-7FEF52330F70@iaaa.nl> References: <31CA1AE4-369B-4EDC-9D3D-7FEF52330F70@iaaa.nl> Message-ID: On 5/19/05, Arthur Elsenaar wrote: > > Hi list, > > to prevent clickable urls to be broken by wrapping, surround the url > by <>. > > alongurlthatwillnotbebroken.alongurlthatwillnotbebroken.alongurlthatwill > notbebroken.alongurlthatwillnotbebroken.alongurlthatwillnotbebroken> (Unfortunately, that doesn't actually seem to help in gmail...) Better yet, use a URL-shortening service like tinyurl.com. I've got the following javascript snippet in a bookmark in Safari's bookmark bar: javascript:void(location.href='http://tinyurl.com/create.php?url='+location.href) For whatever page you're looking at, a click on that will take you to a page that gives you a tinyurl equivalent of your big-ass URL. -- // jack From arthur at iaaa.nl Thu May 19 13:00:52 2005 From: arthur at iaaa.nl (Arthur Elsenaar) Date: Thu, 19 May 2005 12:00:52 +0100 Subject: [Pythonmac-SIG] On posting long urls In-Reply-To: <428C66EC.9080805@ucsd.edu> References: <31CA1AE4-369B-4EDC-9D3D-7FEF52330F70@iaaa.nl> <428C66EC.9080805@ucsd.edu> Message-ID: <210131B8-F238-4464-B3DE-C9A99E76D692@iaaa.nl> On May 19, 2005, at 11:14 AM, Robert Kern wrote: > > Nope. Didn't work. Probably I should have added that depending on your mail client YMMV. Arthur From threeve.org at gmail.com Thu May 19 15:12:09 2005 From: threeve.org at gmail.com (Jason Foreman) Date: Thu, 19 May 2005 08:12:09 -0500 Subject: [Pythonmac-SIG] MacPython IDE in 2.4.1 Message-ID: <414e247405051906125553923a@mail.gmail.com> Hey all, In an effort to learn Python, I picked up the 'Official Unofficial' MacPython 2.4.1 from http://undefined.org/python/ and installed it, along with the Tiger fix. It works great. However is there not supposed to be a MacPython folder in /Applications with some goodies like the Python IDE and what not? If so, mine seems to have gone missing... I don't want to start an editor holy war, I just wanted to try it out because I see it mentioned here and there. However I will honor suggestions for other editors to try out (have already tried SPE...) Thanks, Jason From charles.hartman at conncoll.edu Thu May 19 15:51:05 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 19 May 2005 09:51:05 -0400 Subject: [Pythonmac-SIG] wxversion disappeared? Message-ID: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> I must have screwed something up, but I can't retrace where. I'm running 10.4.1. I've installed wxPython 2.6.0. But: 1. when (from Terminal) I run Python (I get the Python 2.4.1 I installed from the framework distributable), and 'import wx' I still get wxPython version 2.5.5.1. 2. if I try 'import wxversion' that module isn't found. Obviously I've confused the paths, but I'm too confused myself to see how. (I also want the Tiger-distributed Python 2.3.5 to be able to call wxPython 2.6 rather than the seriously hobbled 2.5.3.1, and I'm not having much luck with that either.) Charles Hartman From ronaldoussoren at mac.com Thu May 19 15:55:34 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 19 May 2005 15:55:34 +0200 Subject: [Pythonmac-SIG] wxversion disappeared? In-Reply-To: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> References: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> Message-ID: On 19-mei-2005, at 15:51, Charles Hartman wrote: > > (I also want the Tiger-distributed Python 2.3.5 to be able to call > wxPython 2.6 rather than the seriously hobbled 2.5.3.1, and I'm not > having much luck with that either.) "rm /Library/Python/2.3/site-packages/Extras.pth" will remove the version of wxPython that's included with the OS from sys.path. You should then be able to install a new version (or see the new version if you already installed it). Ronald From charles.hartman at conncoll.edu Thu May 19 16:09:35 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 19 May 2005 10:09:35 -0400 Subject: [Pythonmac-SIG] wxversion disappeared? In-Reply-To: References: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> Message-ID: <26DF2434-B927-4B77-99D0-7C3F16B924AE@conncoll.edu> On May 19, 2005, at 9:55 AM, Ronald Oussoren wrote: > On 19-mei-2005, at 15:51, Charles Hartman wrote: >> >> (I also want the Tiger-distributed Python 2.3.5 to be able to call >> wxPython 2.6 rather than the seriously hobbled 2.5.3.1, and I'm not >> having much luck with that either.) > > "rm /Library/Python/2.3/site-packages/Extras.pth" will remove the > version of wxPython that's included with the OS from sys.path. You > should then be able to install a new version (or see the new version > if you already installed it). Though I'm reluctant to *change* what Apple installs (glad to *add* to it of course), I tried what you suggest. But all that does is make wx entirely invisible to Python. Charles Hartman From ronaldoussoren at mac.com Thu May 19 16:19:52 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 19 May 2005 16:19:52 +0200 Subject: [Pythonmac-SIG] wxversion disappeared? In-Reply-To: <26DF2434-B927-4B77-99D0-7C3F16B924AE@conncoll.edu> References: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> <26DF2434-B927-4B77-99D0-7C3F16B924AE@conncoll.edu> Message-ID: On 19-mei-2005, at 16:09, Charles Hartman wrote: > On May 19, 2005, at 9:55 AM, Ronald Oussoren wrote: > > >> On 19-mei-2005, at 15:51, Charles Hartman wrote: >> >>> >>> (I also want the Tiger-distributed Python 2.3.5 to be able to call >>> wxPython 2.6 rather than the seriously hobbled 2.5.3.1, and I'm not >>> having much luck with that either.) >>> >> >> "rm /Library/Python/2.3/site-packages/Extras.pth" will remove the >> version of wxPython that's included with the OS from sys.path. You >> should then be able to install a new version (or see the new version >> if you already installed it). >> > > Though I'm reluctant to *change* what Apple installs (glad to *add* > to it of course), I tried what you suggest. But all that does is > make wx entirely invisible to Python. At least we're making some progress :-) How did you install the new wxPython? Did you install a binairy distribution for Panther? If you did you should also install TigerPython23Compat from http://pythonmac.org/packages. The location of the side-packages directory changed in 10.4. BTW. Removing files in /Library is perfectly valid, changing stuff in /System is a no-no. It is possible to remove Apple's version of wxPython without removing Extras.pth, but I won't tell you how ;-) Ronald From charles.hartman at conncoll.edu Thu May 19 16:28:20 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 19 May 2005 10:28:20 -0400 Subject: [Pythonmac-SIG] wxversion disappeared? In-Reply-To: References: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> <26DF2434-B927-4B77-99D0-7C3F16B924AE@conncoll.edu> Message-ID: <3C1C46F8-4A4E-409E-A73D-D1177B6A1CB2@conncoll.edu> I did install TigerPython23Compat, but I just reinstalled to be sure. Then I moved Extras.pth out of /Library/Python/2.3/site-packages. Now when I run Python (2.4.1), wxversion still can't be found for import; wxPython can be imported, but it's still 2.5.5.1, not 2.6.0. On May 19, 2005, at 10:19 AM, Ronald Oussoren wrote: > On 19-mei-2005, at 16:09, Charles Hartman wrote: > >> On May 19, 2005, at 9:55 AM, Ronald Oussoren wrote: >> >>> On 19-mei-2005, at 15:51, Charles Hartman wrote: >>>> >>>> (I also want the Tiger-distributed Python 2.3.5 to be able to call >>>> wxPython 2.6 rather than the seriously hobbled 2.5.3.1, and I'm not >>>> having much luck with that either.) >>> >>> "rm /Library/Python/2.3/site-packages/Extras.pth" will remove the >>> version of wxPython that's included with the OS from sys.path. You >>> should then be able to install a new version (or see the new version >>> if you already installed it). >>> >> Though I'm reluctant to *change* what Apple installs (glad to >> *add* to it of course), I tried what you suggest. But all that >> does is make wx entirely invisible to Python. >> > > At least we're making some progress :-) > > How did you install the new wxPython? Did you install a binairy > distribution for Panther? If you did you should also install > TigerPython23Compat from http://pythonmac.org/packages. The > location of the side-packages directory changed in 10.4. > > BTW. Removing files in /Library is perfectly valid, changing stuff > in /System is a no-no. It is possible to remove Apple's version of > wxPython without removing Extras.pth, but I won't tell you how ;-) > > Ronald > From ronaldoussoren at mac.com Thu May 19 17:03:40 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 19 May 2005 17:03:40 +0200 Subject: [Pythonmac-SIG] wxversion disappeared? In-Reply-To: <3C1C46F8-4A4E-409E-A73D-D1177B6A1CB2@conncoll.edu> References: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> <26DF2434-B927-4B77-99D0-7C3F16B924AE@conncoll.edu> <3C1C46F8-4A4E-409E-A73D-D1177B6A1CB2@conncoll.edu> Message-ID: <968D4C99-DA52-45DD-88E5-63942F373B1A@mac.com> On 19-mei-2005, at 16:28, Charles Hartman wrote: > > I did install TigerPython23Compat, but I just reinstalled to be > sure. Then I moved Extras.pth out of /Library/Python/2.3/site- > packages. Now when I run Python (2.4.1), wxversion still can't be > found for import; wxPython can be imported, but it's still 2.5.5.1, > not 2.6.0. Python 2.4.1 does not look at /Library/Python/2.3, that's only for Python 2.3.x. I've installed wxPython2.6-osx-unicode-2.6.0.0-macosx10.3-py2.3.dmg and TigerPython23Compat $ ls /Library/Python/2.3 site-packages wx.pth wx-2.6-mac-unicode wxversion.py $ cd /Library/Python/2.3/site-packages $ mv Extras.pth Extra.pth.sv $ python2.3 Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import wx >>> wx.__version__ '2.6.0.0' >>> python2.3 correctly picks up the new version of wxPython. If you want to use wxPython 2.6 in python 2.3 and in python 2.4 you'll have to download two installers, one for every version of python. Ronald > > On May 19, 2005, at 10:19 AM, Ronald Oussoren wrote: > > >> On 19-mei-2005, at 16:09, Charles Hartman wrote: >> >> >>> On May 19, 2005, at 9:55 AM, Ronald Oussoren wrote: >>> >>> >>>> On 19-mei-2005, at 15:51, Charles Hartman wrote: >>>> >>>>> >>>>> (I also want the Tiger-distributed Python 2.3.5 to be able to call >>>>> wxPython 2.6 rather than the seriously hobbled 2.5.3.1, and I'm >>>>> not >>>>> having much luck with that either.) >>>>> >>>> >>>> "rm /Library/Python/2.3/site-packages/Extras.pth" will remove the >>>> version of wxPython that's included with the OS from sys.path. You >>>> should then be able to install a new version (or see the new >>>> version >>>> if you already installed it). >>>> >>>> >>> Though I'm reluctant to *change* what Apple installs (glad to >>> *add* to it of course), I tried what you suggest. But all that >>> does is make wx entirely invisible to Python. >>> >>> >> >> At least we're making some progress :-) >> >> How did you install the new wxPython? Did you install a binairy >> distribution for Panther? If you did you should also install >> TigerPython23Compat from http://pythonmac.org/packages. The >> location of the side-packages directory changed in 10.4. >> >> BTW. Removing files in /Library is perfectly valid, changing stuff >> in /System is a no-no. It is possible to remove Apple's version of >> wxPython without removing Extras.pth, but I won't tell you how ;-) >> >> Ronald >> >> > > From charles.hartman at conncoll.edu Thu May 19 17:21:06 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 19 May 2005 11:21:06 -0400 Subject: [Pythonmac-SIG] wxversion disappeared? In-Reply-To: <968D4C99-DA52-45DD-88E5-63942F373B1A@mac.com> References: <5DF384E4-5D21-4CA3-80A0-81D6A08176EA@conncoll.edu> <26DF2434-B927-4B77-99D0-7C3F16B924AE@conncoll.edu> <3C1C46F8-4A4E-409E-A73D-D1177B6A1CB2@conncoll.edu> <968D4C99-DA52-45DD-88E5-63942F373B1A@mac.com> Message-ID: <415DAAB2-C69F-4AC0-8869-EDD050E40F10@conncoll.edu> I knew I was missing something obvious. Duh! Right, now everything works. Thanks for your patient help! Charles Hartman On May 19, 2005, at 11:03 AM, Ronald Oussoren wrote: > > python2.3 correctly picks up the new version of wxPython. If you > want to use wxPython 2.6 in python 2.3 and in python 2.4 you'll > have to download two installers, one for every version of python. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050519/5e1d0c65/attachment.htm From jwight_lists at toxicsoftware.com Thu May 19 17:49:33 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Thu, 19 May 2005 11:49:33 -0400 Subject: [Pythonmac-SIG] ANN: Python Metadata Importer In-Reply-To: References: Message-ID: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> And again with long URLs fixed ;-) I released the code under the GPL - with minor modifications to the code I think anyone should be able to create Spotlight Importers using python (without depending on PyObjC)... - Version 0.9 (everything done exception final documentation tidy-up) is online at: Source is available from: Feedback MOST welcome. Jon. From skip at pobox.com Thu May 19 17:54:47 2005 From: skip at pobox.com (Skip Montanaro) Date: Thu, 19 May 2005 10:54:47 -0500 Subject: [Pythonmac-SIG] On posting long urls In-Reply-To: References: <31CA1AE4-369B-4EDC-9D3D-7FEF52330F70@iaaa.nl> Message-ID: <17036.46791.111300.761456@montanaro.dyndns.org> Jack> I've got the following javascript snippet in a bookmark in Jack> Safari's bookmark bar: Jack> javascript:void(location.href='http://tinyurl.com/create.php?url='+location.href) Cool. Seems to work with Firefox as well (1.0.3 on Solaris/Intell in my case). Skip From ronaldoussoren at mac.com Thu May 19 19:26:18 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 19 May 2005 19:26:18 +0200 Subject: [Pythonmac-SIG] ANN: PyObjC 1.3.6 Message-ID: <6089FBAD-30BB-4CB1-B94C-5055813A34DA@mac.com> PyObjC 1.3.5 contains a bug that makes most plugins unuseable. PyObjC 1.3.6 fixes this bug. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050519/c92d141b/smime.bin From ronaldoussoren at mac.com Thu May 19 19:32:09 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 19 May 2005 19:32:09 +0200 Subject: [Pythonmac-SIG] ANN: Python Metadata Importer In-Reply-To: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> References: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> Message-ID: On 19-mei-2005, at 17:49, Jonathan Wight wrote: > And again with long URLs fixed ;-) > > I released the code under the GPL Why GPL? > - with minor modifications to the > code I think anyone should be able to create Spotlight Importers > using python (without depending on PyObjC)... Is that a challenge? You cannot create importers using PyObjC at the moment. Ronald P.S. for the humor impaired: :-) :-) :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050519/1169dfc5/smime.bin From jwight_lists at toxicsoftware.com Thu May 19 19:39:30 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Thu, 19 May 2005 13:39:30 -0400 Subject: [Pythonmac-SIG] ANN: Python Metadata Importer In-Reply-To: References: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> Message-ID: <6644A622-F9FD-424D-BB73-CB97A1B0A681@toxicsoftware.com> On May 19, 2005, at 13:32, Ronald Oussoren wrote: > On 19-mei-2005, at 17:49, Jonathan Wight wrote: > > >> And again with long URLs fixed ;-) >> >> I released the code under the GPL >> >> > Why GPL? > Why not? Suggest something different. >> - with minor modifications to the >> code I think anyone should be able to create Spotlight Importers >> using python (without depending on PyObjC)... >> >> > > Is that a challenge? You cannot create importers using PyObjC at > the moment. > Not at all. But feel free to take it as challenge if you wish. Pistols at dawn? ;-) I chose not to use PyObjC because: 1: I started this before the PyObjC guys had officially released PyObjC for 10.4 2: I'm not an expert in PyObjC. 3: I wasn't sure how to bundle PyObjC with the importer without conflicting with PyObjC already on their machine (see #2) 4: It was pretty quick and easy even without PyObjC. 5: It was fun. ;-) Jon. From bob at redivi.com Thu May 19 19:48:11 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 19 May 2005 13:48:11 -0400 Subject: [Pythonmac-SIG] ANN: Python Metadata Importer In-Reply-To: References: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> Message-ID: On May 19, 2005, at 1:32 PM, Ronald Oussoren wrote: > On 19-mei-2005, at 17:49, Jonathan Wight wrote: > > >> And again with long URLs fixed ;-) >> >> I released the code under the GPL >> > Why GPL? Probably because he wants someone else to re-implement it :) >> - with minor modifications to the >> code I think anyone should be able to create Spotlight Importers >> using python (without depending on PyObjC)... >> > > Is that a challenge? You cannot create importers using PyObjC at > the moment. Sure you can, but you would still have to write about three lines of Objective-C code beyond the template.. -bob From jwight_lists at toxicsoftware.com Thu May 19 19:51:06 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Thu, 19 May 2005 13:51:06 -0400 Subject: [Pythonmac-SIG] ANN: Python Metadata Importer In-Reply-To: References: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> Message-ID: On May 19, 2005, at 13:48, Bob Ippolito wrote: > > On May 19, 2005, at 1:32 PM, Ronald Oussoren wrote: > > >> On 19-mei-2005, at 17:49, Jonathan Wight wrote: >> >> >> >>> And again with long URLs fixed ;-) >>> >>> I released the code under the GPL >>> >>> >> Why GPL? >> > > Probably because he wants someone else to re-implement it :) Um no. I wouldn't have gone through the bother or writing it, testing it and then releasing it if I wanted someone else to re-implement it. I'm moving all my free source code i write over to the GPL. >>> - with minor modifications to the >>> code I think anyone should be able to create Spotlight Importers >>> using python (without depending on PyObjC)... >>> >>> >> >> Is that a challenge? You cannot create importers using PyObjC at >> the moment. >> > > Sure you can, but you would still have to write about three lines > of Objective-C code beyond the template.. Go for it then. Jon. From ronaldoussoren at mac.com Thu May 19 19:51:50 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 19 May 2005 19:51:50 +0200 Subject: [Pythonmac-SIG] ANN: Python Metadata Importer In-Reply-To: <6644A622-F9FD-424D-BB73-CB97A1B0A681@toxicsoftware.com> References: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> <6644A622-F9FD-424D-BB73-CB97A1B0A681@toxicsoftware.com> Message-ID: <82B72851-AC01-4597-A0F3-4BE17B80DF2D@mac.com> On 19-mei-2005, at 19:39, Jonathan Wight wrote: > On May 19, 2005, at 13:32, Ronald Oussoren wrote: > > > >> On 19-mei-2005, at 17:49, Jonathan Wight wrote: >> >> >> >>> And again with long URLs fixed ;-) >>> >>> I released the code under the GPL >>> >>> >>> >> Why GPL? >> >> > > Why not? That's as good an answer as any. I was just wondering. One reason to pick a MIT/BSD license (or even the PSF license) is that it is very unlikely that GPL-ed code will ever be included with Python itself. > > Suggest something different. > > > >>> - with minor modifications to the >>> code I think anyone should be able to create Spotlight Importers >>> using python (without depending on PyObjC)... >>> >>> >>> >> >> Is that a challenge? You cannot create importers using PyObjC at >> the moment. >> >> > > Not at all. But feel free to take it as challenge if you wish. > Pistols at dawn? ;-) > > I chose not to use PyObjC because: > > 1: I started this before the PyObjC guys had officially released > PyObjC for 10.4 > > 2: I'm not an expert in PyObjC. > > 3: I wasn't sure how to bundle PyObjC with the importer without > conflicting with PyObjC already on their machine (see #2) > > 4: It was pretty quick and easy even without PyObjC. > > 5: It was fun. ;-) > > Jon. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050519/f28c83f5/smime-0001.bin From bob at redivi.com Thu May 19 19:58:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 19 May 2005 13:58:22 -0400 Subject: [Pythonmac-SIG] ANN: Python Metadata Importer In-Reply-To: References: <315D5AED-57DE-4114-BDDE-532F9389D831@toxicsoftware.com> Message-ID: On May 19, 2005, at 1:51 PM, Jonathan Wight wrote: > > On May 19, 2005, at 13:48, Bob Ippolito wrote: > > >> >> On May 19, 2005, at 1:32 PM, Ronald Oussoren wrote: >> >> >> >>> On 19-mei-2005, at 17:49, Jonathan Wight wrote: >>> >>> >>> >>> >>>> And again with long URLs fixed ;-) >>>> >>>> I released the code under the GPL >>>> >>>> >>>> >>> Why GPL? >>> >>> >> >> Probably because he wants someone else to re-implement it :) >> > > Um no. I wouldn't have gone through the bother or writing it, > testing it and then releasing it if I wanted someone else to re- > implement it. > > I'm moving all my free source code i write over to the GPL. If you open your eyes and look around you'll see that most Python stuff is released under more liberal licenses (MIT, BSD, PSF and the occasional LGPL typically for wrappers over LGPL libraries). GPL is only really appropriate for applications, and even then it's questionable. You're distributing code that would likely be used as a template for other importers, yet you're forcing everyone to adopt the GPL or negotiate an alternate license. In most contexts, that makes the code pretty useless, unless people are writing imports for themselves or for other GPL software. -bob From ml at fgranger.com Thu May 19 21:38:16 2005 From: ml at fgranger.com (Fran=?ISO-8859-1?B?5w==?=ois Granger) Date: Thu, 19 May 2005 21:38:16 +0200 Subject: [Pythonmac-SIG] On posting long urls In-Reply-To: Message-ID: Le 19/05/05 12:35, ??Jack Nutting?? a ?crit?: > Better yet, use a URL-shortening service like tinyurl.com. I've got > the following javascript snippet in a bookmark in Safari's bookmark > bar: > > javascript:void(location.href='http://tinyurl.com/create.php?url='+location.hr > ef) Really good tip ! From bob at redivi.com Thu May 19 22:13:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 19 May 2005 16:13:58 -0400 Subject: [Pythonmac-SIG] On posting long urls In-Reply-To: References: Message-ID: <474AA1E8-ED45-4CFB-92C5-EC90E067831E@redivi.com> On May 19, 2005, at 3:38 PM, Fran?ois Granger wrote: > Le 19/05/05 12:35, ? Jack Nutting ? a ?crit : > > >> Better yet, use a URL-shortening service like tinyurl.com. I've got >> the following javascript snippet in a bookmark in Safari's bookmark >> bar: >> >> javascript:void(location.href='http://tinyurl.com/create.php? >> url='+location.hr >> ef) >> > > Really good tip ! Using tinyurl isn't very search engine friendly and if tinyurl ever goes down then the links are gone... I only really use tinyurl for pathologically long transient URLs, like a mapquest map or something :) -bob From delza at livingcode.org Thu May 19 22:58:07 2005 From: delza at livingcode.org (Dethe Elza) Date: Thu, 19 May 2005 13:58:07 -0700 Subject: [Pythonmac-SIG] On posting long urls In-Reply-To: <474AA1E8-ED45-4CFB-92C5-EC90E067831E@redivi.com> References: <474AA1E8-ED45-4CFB-92C5-EC90E067831E@redivi.com> Message-ID: <3D22FF52-40C3-48B3-B366-E1C14F3FDB39@livingcode.org> > Using tinyurl isn't very search engine friendly and if tinyurl ever > goes down then the links are gone... I only really use tinyurl for > pathologically long transient URLs, like a mapquest map or > something :) > > -bob It's not an either-or proposition. You can include the original URL for searching, or in case tinyurl goes away, but include a tinyurl to the same resource for convenience (and not linebreaking). --Dethe From kenneth.m.mcdonald at gmail.com Fri May 20 02:58:57 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Thu, 19 May 2005 19:58:57 -0500 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: References: Message-ID: I have nothing against the GPL (well, yes I do, I think it makes the free and commercial software sides enemies, but that's a completely different topic), but I do think it would be nice if all free Python software was released under the same license as Python itself. Python is an elegant language, and having all kinds of different Python modules under all sorts of different licenses is, well...inelegant. Thanks for the module though! I will be looking at it once I get Tiger installed, it could be very useful. Does it allow the _creation_ of custom metadata tags on files? Or are we restricted to the ones defined by Apple? Thanks, Ken > >>> I released the code under the GPL > >>> > >>> > >>> > >> Why GPL? > >> > >> > > > > Why not? > > That's as good an answer as any. I was just wondering. One reason to > pick a MIT/BSD license (or even the PSF license) is that it is very > unlikely that GPL-ed code will ever be included with Python itself. From bob at redivi.com Fri May 20 09:00:21 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 20 May 2005 03:00:21 -0400 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: References: Message-ID: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> On May 19, 2005, at 8:58 PM, Kenneth McDonald wrote: > I have nothing against the GPL (well, yes I do, I think it makes the > free and commercial software sides enemies, but that's a completely > different topic), but I do think it would be nice if all free Python > software was released under the same license as Python itself. Python > is an elegant language, and having all kinds of different Python > modules under all sorts of different licenses is, well...inelegant. Well the PSF license has certain issues in that it's only really meant to be used by the PSF for software wholly owned by the PSF. However, using MIT/BSD style license is equivalent to using PSF since they are compatible. I'd rather not have a license flamewar, though :) > Does it allow the _creation_ of custom metadata tags on files? Or are > we restricted to the ones defined by Apple? Metadata importers can define whatever key/value pairs they want to. Only certain keys are used intelligently by Apple's Spotlight UI, but you can define whatever you want and there are APIs to query Spotlight for your own purposes. -bob From mwh at python.net Fri May 20 13:43:57 2005 From: mwh at python.net (Michael Hudson) Date: Fri, 20 May 2005 12:43:57 +0100 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: (Kenneth McDonald's message of "Thu, 19 May 2005 19:58:57 -0500") References: Message-ID: <2m7jhu2kci.fsf@starship.python.net> Kenneth McDonald writes: > I have nothing against the GPL (well, yes I do, I think it makes the > free and commercial software sides enemies, but that's a completely > different topic), but I do think it would be nice if all free Python > software was released under the same license as Python itself. Python > is an elegant language, and having all kinds of different Python > modules under all sorts of different licenses is, well...inelegant. As Bob said, you really don't want use the PSF license for your own code. If you think you do, use MIT/X11. Cheers, mwh (who actually quite likes the LGPL for some things) -- I'm not a PSU agent. -- from Twisted.Quotes From hengist.podd at virgin.net Fri May 20 13:59:00 2005 From: hengist.podd at virgin.net (has) Date: Fri, 20 May 2005 12:59:00 +0100 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> References: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> Message-ID: Bob wrote: >>I have nothing against the GPL (well, yes I do, I think it makes the >>free and commercial software sides enemies, but that's a completely >>different topic), but I do think it would be nice if all free Python >>software was released under the same license as Python itself. > >Well the PSF license has certain issues in that it's only really meant to be used by the PSF for software wholly owned by the PSF. >However, using MIT/BSD style license is equivalent to using PSF since they are compatible. More info here: http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq HTH has -- http://freespace.virgin.net/hamish.sanderson/ From jmutter at uakron.edu Fri May 20 17:36:49 2005 From: jmutter at uakron.edu (Jay Mutter) Date: Fri, 20 May 2005 11:36:49 -0400 Subject: [Pythonmac-SIG] tiger Message-ID: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> I have performed a clean install of Tiger on an ibook and then installed the MacPython-OSX-2.4.1 framework build and the TigerPython24Fix. The MacPython-2.4 folder is in Applications and all included items work. What is a or the correct way to have python 2.4.1 run when I type python in terminal? Prior to installing 2.4.1 I installed one module {SnakeSQL} which worked/works fine under 2.3.5 and is located in /library/Python/2.3/site-packages. What is the proper way to get 2.4.1 to utilize this and to utilize wxPython? thanks Jay Mutter jmutter at uakron.edu From jwight_lists at toxicsoftware.com Fri May 20 18:28:31 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Fri, 20 May 2005 12:28:31 -0400 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> References: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> Message-ID: <18332E71-C12D-4B2A-94E2-8DDB5ABE2AFD@toxicsoftware.com> On May 20, 2005, at 03:00, Bob Ippolito wrote: >> Does it allow the _creation_ of custom metadata tags on files? Or are >> we restricted to the ones defined by Apple? >> >> > > Metadata importers can define whatever key/value pairs they want to. > Only certain keys are used intelligently by Apple's Spotlight UI, but > you can define whatever you want and there are APIs to query > Spotlight for your own purposes. > One problem with defining your own keys is that there are no guarantees that other importers will use the same keys even if they're representing the same thing... For example I'm defining two custom metadata attribute keys: org_python_classes & org_python_functions to represent the list of all classes and functions found within the source file. It would be good if (for example) a PHP importer used the same keys as my importer (perhaps with more generic key names) to represent the same kinds of data found in PHP files. Unfortunately there is no central repository (like Apples type & creator database) for Spotlight metadata keys so it is really hard for importer authors to cooperate. Jon. From bob at redivi.com Fri May 20 18:43:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 20 May 2005 12:43:26 -0400 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: <18332E71-C12D-4B2A-94E2-8DDB5ABE2AFD@toxicsoftware.com> References: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> <18332E71-C12D-4B2A-94E2-8DDB5ABE2AFD@toxicsoftware.com> Message-ID: <787C0E83-647B-4D58-8CA7-8FF5A1714E48@redivi.com> On May 20, 2005, at 12:28 PM, Jonathan Wight wrote: > > On May 20, 2005, at 03:00, Bob Ippolito wrote: > > > >>> Does it allow the _creation_ of custom metadata tags on files? Or >>> are >>> we restricted to the ones defined by Apple? >>> >>> >>> >> >> Metadata importers can define whatever key/value pairs they want to. >> Only certain keys are used intelligently by Apple's Spotlight UI, but >> you can define whatever you want and there are APIs to query >> Spotlight for your own purposes. >> >> > > One problem with defining your own keys is that there are no > guarantees that other importers will use the same keys even if > they're representing the same thing... > > For example I'm defining two custom metadata attribute keys: > org_python_classes & org_python_functions to represent the list of > all classes and functions found within the source file. It would be > good if (for example) a PHP importer used the same keys as my > importer (perhaps with more generic key names) to represent the > same kinds of data found in PHP files. Unfortunately there is no > central repository (like Apples type & creator database) for > Spotlight metadata keys so it is really hard for importer authors > to cooperate. It's not THAT hard, all you need is a central naming authority. You could use wikipedia-based names for things, since each wikipedia URL represents something unambiguous. -bob From kenneth.m.mcdonald at gmail.com Fri May 20 18:49:55 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Fri, 20 May 2005 11:49:55 -0500 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: <787C0E83-647B-4D58-8CA7-8FF5A1714E48@redivi.com> References: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> <18332E71-C12D-4B2A-94E2-8DDB5ABE2AFD@toxicsoftware.com> <787C0E83-647B-4D58-8CA7-8FF5A1714E48@redivi.com> Message-ID: Unfortunately, the hard part is actually getting people to agree on what constitutes a central naming authority. I guarantee that without Apple involvement, twenty different people will come to this same conclusion (it's a good one, after all), and we'll shortly see twenty different 'central' naming standards. Cheers, Ken > It's not THAT hard, all you need is a central naming authority. You > could use wikipedia-based names for things, since each wikipedia URL > represents something unambiguous. > > -bob > > From bob at redivi.com Fri May 20 19:08:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 20 May 2005 13:08:15 -0400 Subject: [Pythonmac-SIG] Free Python code and Licenses In-Reply-To: References: <5BDEE690-CCF2-409A-B908-9A1AD0BA8440@redivi.com> <18332E71-C12D-4B2A-94E2-8DDB5ABE2AFD@toxicsoftware.com> <787C0E83-647B-4D58-8CA7-8FF5A1714E48@redivi.com> Message-ID: <11068CA4-3DEE-40B0-B82E-9C0AC28E952B@redivi.com> On May 20, 2005, at 12:49 PM, Kenneth McDonald wrote: > Unfortunately, the hard part is actually getting people to agree on > what constitutes a central naming authority. I guarantee that without > Apple involvement, twenty different people will come to this same > conclusion (it's a good one, after all), and we'll shortly see twenty > different 'central' naming standards. Well Apple has defined what they want to be defined right now, and they expect most other attributes to be application-specific. The same situation is out there for UTIs. If you felt strongly about the need for an obvious way for everyone to name things then you could pretty easily make it known to the development community. If a couple people pick it up, you'd probably have a de facto standard pretty quickly. -bob From lee_cullens at mac.com Sat May 21 06:12:15 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Sat, 21 May 2005 00:12:15 -0400 Subject: [Pythonmac-SIG] tiger In-Reply-To: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> Message-ID: Sorry to be so slow, but I thought one of the experts would reply and then noticed none had (at least on list). On May 20, 2005, at 11:36 AM, Jay Mutter wrote: > I have performed a clean install of Tiger on an ibook and then > installed the MacPython-OSX-2.4.1 framework build and the > TigerPython24Fix. > The MacPython-2.4 folder is in Applications and all included items > work. > What is a or the correct way to have python 2.4.1 run when I type > python in terminal? Even I can field this question. For the Apple supplied Python one uses the command "python," so for the Bob's MacPython one uses "python2.4" > Prior to installing 2.4.1 I installed one module {SnakeSQL} which > worked/works fine under 2.3.5 and is located in > /library/Python/2.3/site-packages. > What is the proper way to get 2.4.1 to utilize this and to utilize > wxPython? I remember that question being answered just recently (at least in part), so just a little digging in this list will unearth it and you won't be hindered by my faulty memory. > > thanks > > Jay Mutter > jmutter at uakron.edu > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Sat May 21 08:52:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 21 May 2005 02:52:53 -0400 Subject: [Pythonmac-SIG] tiger In-Reply-To: References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> Message-ID: <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> On May 21, 2005, at 12:12 AM, Lee Cullens wrote: > Sorry to be so slow, but I thought one of the experts would reply and > then noticed none had (at least on list). > > > On May 20, 2005, at 11:36 AM, Jay Mutter wrote: > > >> I have performed a clean install of Tiger on an ibook and then >> installed the MacPython-OSX-2.4.1 framework build and the >> TigerPython24Fix. >> The MacPython-2.4 folder is in Applications and all included items >> work. >> What is a or the correct way to have python 2.4.1 run when I type >> python in terminal? >> > > Even I can field this question. For the Apple supplied Python one > uses the command "python," so for the Bob's MacPython one uses > "python2.4" This only works if /usr/local/bin comes after /usr/bin in your PATH, I'm not sure /usr/local/bin is in your PATH at all by default. If / usr/local/bin comes first in PATH, then "python" is sufficient. >> Prior to installing 2.4.1 I installed one module {SnakeSQL} which >> worked/works fine under 2.3.5 and is located in >> /library/Python/2.3/site-packages. >> What is the proper way to get 2.4.1 to utilize this and to utilize >> wxPython? >> > > I remember that question being answered just recently (at least in > part), so just a little digging in this list will unearth it and you > won't be hindered by my faulty memory. What hasn't been answered recently? :) -bob From a.h.jaffe at gmail.com Sat May 21 17:57:28 2005 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Sat, 21 May 2005 16:57:28 +0100 Subject: [Pythonmac-SIG] numarray 1.1.1 w/ vecLib (Apple's optimized implementation of BLAS) Message-ID: <73190ce7b4596a252620baae073a495d@gmail.com> Hi Bob (et al), Any chance of an updated package for numarray 1.3.1? (Or just hints on fixing the installer which doesn't quite pick up veclib correctly, I think!)? Thanks, Andrew From lee_cullens at mac.com Sat May 21 18:48:49 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Sat, 21 May 2005 12:48:49 -0400 Subject: [Pythonmac-SIG] tiger In-Reply-To: <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> Message-ID: On May 21, 2005, at 2:52 AM, Bob Ippolito wrote: > > What hasn't been answered recently? :) > > -bob > > True enough Bob, though not always obvious to the new Mac/Unix user. I understand where you are coming from (I was once an "expert" that others turned to with HP-UX among others) and many questions seemed obvious/trivial to me. I guess what this falls under is "fostering" Python use on Mac OS X to me. Sometimes restating something and maybe being more elaborative helps others less technically proficient on a platform. Please understand that I know the value and need for your level of expertise here, and I do respect and appreciate your efforts. It is obvious to me that Apple has not provided a sufficient and up-to-date enough implementation of Python. Even keeping up to date with Python and evolving third party packages, and deciding just how far to follow, is a bit of a task. Maybe I can get to the point where I can help with more "hand-holding" and between all of us we can unleash the "force" of Python on Mac OS X for the next tier of potential users, and maybe I'm just a dreamy old man. At the moment I have been more involved in (sorting out the methodology of) class design patterns in pure Python. For example, I used a "clean" install for Tiger, wiping out all my previous Python playthings and then installed: MacPython-OSX-2.4.1-1.dmg TigerPython24Fix-r2.zip TigerPython23Compat.pkg Now in the terminal "python2.4" works for me and I had not even looked at your reference about PATH, and with just "python" I can still access the Apple package (assuming I would want to :~). My reference to at least a partial answer to the second part of the OPs question was based on remembering a recent post by Ronald Oussoren. Of course, in WingIDE I do point to /usr/local/bin/pythonw for 2.4 and will soon need to make sure I import more up-to-date packages such as wxPython, Not overly difficult I'm sure, but a bridge I have not crossed yet myself to be able to explain to others. I also have yet to go through the ObjC docs you suggested to better understand native interfaces. It all takes a little time (especially at my age :~), but keeps my head busy in these so-called "golden" years, and again your contributions are greatly appreciated by all involved (unless one is blind to the obvious :<)). Lee C From bob at redivi.com Sat May 21 23:11:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 21 May 2005 14:11:22 -0700 Subject: [Pythonmac-SIG] numarray 1.1.1 w/ vecLib (Apple's optimized implementation of BLAS) In-Reply-To: <73190ce7b4596a252620baae073a495d@gmail.com> References: <73190ce7b4596a252620baae073a495d@gmail.com> Message-ID: <7F261A8C-0B3B-4585-B349-AB2CF0AD5FA8@redivi.com> On May 21, 2005, at 8:57 AM, Andrew Jaffe wrote: > Any chance of an updated package for numarray 1.3.1? (Or just hints on > fixing the installer which doesn't quite pick up veclib correctly, I > think!)? Unfortunately I'm out of town (in SF/Berkeley rather than NYC) for about a month and don't have good access to a Panther machine (I only brought my laptop, which runs Tiger). Looking at setup.py and addons.py (particularly addons.py) it looks like it should pick up vecLib just fine. You just need to say set the USE_LAPACK environment variable prior to running setup.py, or specify --use_lapack on the command line (it's a really really ugly hack that generate.py does circumventing distutils.) -bob From a.h.jaffe at gmail.com Sun May 22 00:44:28 2005 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Sat, 21 May 2005 23:44:28 +0100 Subject: [Pythonmac-SIG] numarray 1.1.1 w/ vecLib (Apple's optimized implementation of BLAS) In-Reply-To: <7F261A8C-0B3B-4585-B349-AB2CF0AD5FA8@redivi.com> References: <73190ce7b4596a252620baae073a495d@gmail.com> <7F261A8C-0B3B-4585-B349-AB2CF0AD5FA8@redivi.com> Message-ID: <00eb6f4d72de2374efcf31f49c144a5f@gmail.com> Hi Bob, Thanks for the quick response. However, it seems that there are some bugs in the script, but you've inspired me to hunt for them. First, the section of addons.py that checks for the existence of the framework (around line 47) needs to set lapack_dirs = [], I think, since it needs to exist later on. Second, the section after that that sets lapack_compile_args, lapack_link_args and lapack_include_dirs for *all* cases (lines 57-60) overwrites lapack_link_args from the if...elif...else above. Finally, cblas.h isn't included correctly, since the framework option is only used for linking, not compiling. I assume this works, since: ~...archive/numarray-1.3.1% otool -L build/lib.darwin-7.9.0-Power_Macintosh-2.3/numarray/linear_algebra/ lapack_lite2.so build/lib.darwin-7.9.0-Power_Macintosh-2.3/numarray/linear_algebra/ lapack_lite2.so: /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 153.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3) The overall solution to this was actually to reorder the sections and make some changes to the part that checks for veclib: # Set to list directories to be searched for BLAS and LAPACK libraries #####?MOVED FROM BELOW lapack_compile_args = [] lapack_link_args = [] lapack_include_dirs = ["Packages/LinearAlgebra2/Src"] if os.path.exists('/System/Library/Frameworks/vecLib.framework'): # use Apple's optimized BLAS implementation lapack_libs = [] lapack_link_args = ['-framework', 'vecLib'] lapack_compile_args = ['-framework', 'vecLib'] ### ADDED lapack_dirs = [] ### ADDED elif USE_ABSOFT: # Absoft Fortran lapack_dirs = ['/usr/local/lib/atlas', '/opt/absoft/lib'] lapack_libs = ['lapack', 'f77blas', 'cblas', 'atlas', 'f90math', 'fio', 'f77math', 'm'] else: lapack_dirs = ['/usr/local/lib/atlas'] lapack_libs = ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c', 'm'] Feel free to use this if you do package it up. Is there any easy way to pass this on to the numarray people? Give my regards to Berkeley (worked there for five years and just visited last month!) Andrew On 21 May 2005, at 22:11, Bob Ippolito wrote: > > On May 21, 2005, at 8:57 AM, Andrew Jaffe wrote: > >> Any chance of an updated package for numarray 1.3.1? (Or just hints on >> fixing the installer which doesn't quite pick up veclib correctly, I >> think!)? > > Unfortunately I'm out of town (in SF/Berkeley rather than NYC) for > about a month and don't have good access to a Panther machine (I only > brought my laptop, which runs Tiger). > > Looking at setup.py and addons.py (particularly addons.py) it looks > like it should pick up vecLib just fine. You just need to say set the > USE_LAPACK environment variable prior to running setup.py, or specify > --use_lapack on the command line (it's a really really ugly hack that > generate.py does circumventing distutils.) > > -bob > > ______________________________________________________________________ Andrew Jaffe Astrophysics Group +44 207 594-7526 Blackett Laboratory, Room 1013 FAX 7541 Imperial College, Prince Consort Road London SW7 2AZ ENGLAND http://astro.imperial.ac.uk/~jaffe From lee_cullens at mac.com Sun May 22 09:15:17 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Sun, 22 May 2005 03:15:17 -0400 Subject: [Pythonmac-SIG] .pth use In-Reply-To: <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> Message-ID: <8F8BC005-C364-4D9A-9AD7-830CF50335EE@mac.com> All my hullabaloo about maybe helping with the simpler questions and I can't even wipe yet :~) I forgot how (where) I set up a .pth file back in the Panther and Bob's new right way of including Python 2.4 in Tiger got me all confused. So I looked back at Bob's notes, got frustrated looking for /usr/bin/local when maybe I should have been looking for /usr/ local/bin - anyway it has been a long day what with college graduation festivities and all the inlaws :~) - another generation hits the streets. I put my little common Python utilities in a separate folder and did not want to fool with Pythonpath to import them while testing so I found a place for a .pth file that worked, but I'm wondering if I am doing what is intended/acceptable? What worked (at least so far) was to put a .pth file (containing / Users/Chinook/PythonProjects/MyUtilities) in /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages So am I violating the proper Mac way scripture? Thanks and to all a good night, Lee C (Trying to solve the riddle of the cosmos and can't add 2 and 2 anymore) From dangoor at gmail.com Sun May 22 15:33:15 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Sun, 22 May 2005 09:33:15 -0400 Subject: [Pythonmac-SIG] .pth use In-Reply-To: <8F8BC005-C364-4D9A-9AD7-830CF50335EE@mac.com> References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> <8F8BC005-C364-4D9A-9AD7-830CF50335EE@mac.com> Message-ID: <3f085ecd050522063329eb7b73@mail.gmail.com> On 5/22/05, Lee Cullens wrote: > What worked (at least so far) was to put a .pth file (containing / > Users/Chinook/PythonProjects/MyUtilities) in /Library/Frameworks/ > Python.framework/Versions/2.4/lib/python2.4/site-packages Since this is a user-specific path, you should put it in ~/Library/Python/2.4/site-packages (/Users/Chinook/Library/Python/2.4/site-packages) You'll likely have to create that directory. Kevin From lee_cullens at mac.com Sun May 22 16:14:24 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Sun, 22 May 2005 10:14:24 -0400 Subject: [Pythonmac-SIG] .pth use In-Reply-To: <3f085ecd050522063329eb7b73@mail.gmail.com> References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> <8F8BC005-C364-4D9A-9AD7-830CF50335EE@mac.com> <3f085ecd050522063329eb7b73@mail.gmail.com> Message-ID: <0430E3FD-AEBD-4E1A-9BCC-CE923F71C5A6@mac.com> Ah-ha, that's what I (didn't quite) remember from before, but I wasn't thinking of the rational late last-night. I didn't notice it in sys.path last-night either, but I moved the .pth file and lo and behold it works great. The world is full of wonders to the simple minded like me :~) Thanks for the assistance Kevin and I hope you're having a great weekend, Lee C On May 22, 2005, at 9:33 AM, Kevin Dangoor wrote: > On 5/22/05, Lee Cullens wrote: > >> What worked (at least so far) was to put a .pth file (containing / >> Users/Chinook/PythonProjects/MyUtilities) in /Library/Frameworks/ >> Python.framework/Versions/2.4/lib/python2.4/site-packages >> > > Since this is a user-specific path, you should put it in > ~/Library/Python/2.4/site-packages > > (/Users/Chinook/Library/Python/2.4/site-packages) > > You'll likely have to create that directory. > > Kevin > From bob at redivi.com Sun May 22 17:04:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 22 May 2005 08:04:12 -0700 Subject: [Pythonmac-SIG] .pth use In-Reply-To: <8F8BC005-C364-4D9A-9AD7-830CF50335EE@mac.com> References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> <8F8BC005-C364-4D9A-9AD7-830CF50335EE@mac.com> Message-ID: On May 22, 2005, at 12:15 AM, Lee Cullens wrote: > All my hullabaloo about maybe helping with the simpler questions and > I can't even wipe yet :~) > > I forgot how (where) I set up a .pth file back in the Panther and > Bob's new right way of including Python 2.4 in Tiger got me all > confused. So I looked back at Bob's notes, got frustrated looking > for /usr/bin/local when maybe I should have been looking for /usr/ > local/bin - anyway it has been a long day what with college > graduation festivities and all the inlaws :~) - another generation > hits the streets. http://www.google.com/search?client=safari&rls=en&q=pth +files&ie=UTF-8&oe=UTF-8 ... or: http://bob.pythonmac.org/archives/2005/02/06/using-pth-files- for-python-development/ -bob From a.h.jaffe at gmail.com Sun May 22 18:34:30 2005 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Sun, 22 May 2005 17:34:30 +0100 Subject: [Pythonmac-SIG] numarray 1.1.1 w/ vecLib (Apple's optimized implementation of BLAS) In-Reply-To: <00eb6f4d72de2374efcf31f49c144a5f@gmail.com> References: <73190ce7b4596a252620baae073a495d@gmail.com> <7F261A8C-0B3B-4585-B349-AB2CF0AD5FA8@redivi.com> <00eb6f4d72de2374efcf31f49c144a5f@gmail.com> Message-ID: Hi Bob (&c)- > >> Any chance of an updated package for numarray 1.3.1? (Or just hints on > >> fixing the installer which doesn't quite pick up veclib correctly, I > >> think!)? > > > > Unfortunately I'm out of town (in SF/Berkeley rather than NYC) for > > about a month and don't have good access to a Panther machine (I only > > brought my laptop, which runs Tiger). Out of curiosity (since I'll upgrade to Tiger soon), why does this matter? > However, it seems that there are some bugs in the script, but you've > inspired me to hunt for them. > > First, the section of addons.py that checks for the existence of the > framework (around line 47) needs to set lapack_dirs = [], I think, > since it needs to exist later on. > > Second, the section after that that sets lapack_compile_args, > lapack_link_args and lapack_include_dirs for *all* cases (lines 57-60) > overwrites lapack_link_args from the if...elif...else above. > > Finally, cblas.h isn't included correctly, since the framework option > is only used for linking, not compiling. > > The overall solution to this was actually to reorder the sections and > make some changes to the part that checks for veclib > Feel free to use this if you do package it up. Is there any easy way to > pass this on to the numarray people? I've hard from Chris Barker that I should post to numpy-discussion, which I will do unless I get any negative feedback here. (I've actually made a patchfile, attached.) Andrew ______________________________________________________________________ Andrew Jaffe Astrophysics Group +44 207 594-7526 Blackett Laboratory, Room 1013 FAX 7541 Imperial College, Prince Consort Road London SW7 2AZ ENGLAND http://astro.imperial.ac.uk/~jaffe -------------- next part -------------- A non-text attachment was scrubbed... Name: numarray131-addons.patch Type: application/octet-stream Size: 1240 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050522/12d51af9/numarray131-addons.obj From bob at redivi.com Sun May 22 18:39:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 22 May 2005 09:39:28 -0700 Subject: [Pythonmac-SIG] numarray 1.1.1 w/ vecLib (Apple's optimized implementation of BLAS) In-Reply-To: References: <73190ce7b4596a252620baae073a495d@gmail.com> <7F261A8C-0B3B-4585-B349-AB2CF0AD5FA8@redivi.com> <00eb6f4d72de2374efcf31f49c144a5f@gmail.com> Message-ID: On May 22, 2005, at 9:34 AM, Andrew Jaffe wrote: >>>> Any chance of an updated package for numarray 1.3.1? (Or just >>>> hints on >>>> fixing the installer which doesn't quite pick up veclib >>>> correctly, I >>>> think!)? >>>> >>> >>> Unfortunately I'm out of town (in SF/Berkeley rather than NYC) for >>> about a month and don't have good access to a Panther machine (I >>> only >>> brought my laptop, which runs Tiger). >>> > > Out of curiosity (since I'll upgrade to Tiger soon), why does this > matter? Software compiled on Tiger doesn't run on Panther, in general. -bob From lee_cullens at mac.com Sun May 22 20:19:17 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Sun, 22 May 2005 14:19:17 -0400 Subject: [Pythonmac-SIG] .pth use In-Reply-To: References: <6DA34536-82C8-416F-8BF0-C7EBC71ACFA9@uakron.edu> <88FDDF38-A817-4795-BD95-B0148F4C9340@redivi.com> <8F8BC005-C364-4D9A-9AD7-830CF50335EE@mac.com> Message-ID: Yes Bob, I had read your notes before posting. I knew what I wanted to do, just got myself in a dither about where it should be placed. With a new day came collected thoughts and all the in-laws gone :~) Thanks Lee C On May 22, 2005, at 11:04 AM, Bob Ippolito wrote: > > On May 22, 2005, at 12:15 AM, Lee Cullens wrote: > > >> All my hullabaloo about maybe helping with the simpler questions and >> I can't even wipe yet :~) >> >> I forgot how (where) I set up a .pth file back in the Panther and >> Bob's new right way of including Python 2.4 in Tiger got me all >> confused. So I looked back at Bob's notes, got frustrated looking >> for /usr/bin/local when maybe I should have been looking for /usr/ >> local/bin - anyway it has been a long day what with college >> graduation festivities and all the inlaws :~) - another generation >> hits the streets. >> > > http://www.google.com/search?client=safari&rls=en&q=pth > +files&ie=UTF-8&oe=UTF-8 > > ... or: http://bob.pythonmac.org/archives/2005/02/06/using-pth- > files-for-python-development/ > > -bob > > From kenneth.m.mcdonald at gmail.com Sun May 22 21:40:25 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Sun, 22 May 2005 14:40:25 -0500 Subject: [Pythonmac-SIG] Is this the correct way to have installed and to use Python 2.4 Message-ID: I just downloaded and installed the Tiger 2.4 Python mpkg (including the fix afterwords), mainly so I could use Bob's great looking xattr module. Bringing up 'python' in a terminal brings up 2.3.whatever, and I assume that's because the version in /System/Library hasn't been disturbed and is first on the default search path--please correct me if I'm wrong. What is the best (a subjective consideration, to be sure) to use python 2.4 while making sure that I don't mess up the Apple-installed version for anything important. Should I put /usr/local/bin on the default path? Should I create a link to python 2.4 in /usr/bin, and if so, should I replace the current 'python', or should I create a new name like 'py' so that 2.3 is still accessible using 'python' on the command line. What do I need to think about in terms of making sure things I install in the future will be compiled against 2.4, and will be available on the python path. Thanks for all the help, Ken From bob at redivi.com Sun May 22 21:43:40 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 22 May 2005 12:43:40 -0700 Subject: [Pythonmac-SIG] Is this the correct way to have installed and to use Python 2.4 In-Reply-To: References: Message-ID: <444F6E2A-E671-4FA4-87B5-C489F373E744@redivi.com> On May 22, 2005, at 12:40 PM, Kenneth McDonald wrote: > I just downloaded and installed the Tiger 2.4 Python mpkg (including > the fix afterwords), mainly so I could use Bob's great looking xattr > module. Bringing up 'python' in a terminal brings up 2.3.whatever, and > I assume that's because the version in /System/Library hasn't been > disturbed and is first on the default search path--please correct me > if I'm wrong. Change your PATH environment variable to put /usr/local/bin before / usr/bin or equivalent. -bob From Chris.Barker at noaa.gov Mon May 23 07:21:19 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Sun, 22 May 2005 22:21:19 -0700 Subject: [Pythonmac-SIG] Is this the correct way to have installed and to use Python 2.4 In-Reply-To: <444F6E2A-E671-4FA4-87B5-C489F373E744@redivi.com> References: <444F6E2A-E671-4FA4-87B5-C489F373E744@redivi.com> Message-ID: <4291684F.70707@noaa.gov> Bob Ippolito wrote: > Change your PATH environment variable to put /usr/local/bin before / > usr/bin or equivalent. That's option A. Option B. is to use "python2.4" when you want 2.4, either at the command line, or in a script's #! line: #!/usr/bin/env python2.4 I'm pretty sure Bob's 2.5 package installs a binary (or a link) called python2.4 If it doesn't work, you may need to put /usr/local/bin on your PATH. I prefer this option because in unequivocally will run ONLY with 2.4, and you've made it clear in your source that that is how it's been tested. It's the ONLY way to go if you want to have multiple versions installed,a nd be able to test against them easily. It also means that when you install 2.5, all the scripts that use 2.4 will still work, and indeed, any of the scripts you now have using 2.3 will still work. I got into this habit when running RedHat Linux, which REQUIRED "python" to be the one they had installed (1.5.6 for a LONG time). I don't' know how Apple has used python, and I think OS-X is less likely to use a PATH you've set for system scripts, but I still like this approach better. -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 at noaa.gov From delza at livingcode.org Mon May 23 08:11:58 2005 From: delza at livingcode.org (Dethe Elza) Date: Sun, 22 May 2005 23:11:58 -0700 Subject: [Pythonmac-SIG] Building Twisted Message-ID: Hi folks, Has anyone installed twisted 2.0 on Tiger? I don't think I've ever had trouble building Twisted before, but now they've made it dependent on Zope Interfaces, which won't build for me. I'm running OS 10.4, Bob's Python 2.4, latest svn of PyObjC and py2app. Here's the traceback I'm getting when I try to build Zope Interfaces 3.0.1: $ python setup.py build running build running build_py running build_ext building 'zope.interface._zope_interface_coptimizations' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - IDependencies/zope.interface-ZopeInterface-3.0.1/zope.interface -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c Dependencies/zope.interface-ZopeInterface-3.0.1/zope.interface/ _zope_interface_coptimizations.c -o build/temp.darwin-8.1.0- Power_Macintosh-2.4/Dependencies/zope.interface-ZopeInterface-3.0.1/ zope.interface/_zope_interface_coptimizations.o Dependencies/zope.interface-ZopeInterface-3.0.1/zope.interface/ _zope_interface_coptimizations.c:339: error: static declaration of 'SpecType' follows non-static declaration Dependencies/zope.interface-ZopeInterface-3.0.1/zope.interface/ _zope_interface_coptimizations.c:73: error: previous declaration of 'SpecType' was here error: command 'gcc' failed with exit status 1 Since when do either Zope or Twisted require binary components anyway? --Dethe From bob at redivi.com Mon May 23 08:35:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun, 22 May 2005 23:35:42 -0700 Subject: [Pythonmac-SIG] Building Twisted In-Reply-To: References: Message-ID: <3CB35038-DF57-4836-8456-15FA9C1F43E7@redivi.com> On May 22, 2005, at 11:11 PM, Dethe Elza wrote: > Has anyone installed twisted 2.0 on Tiger? > > I don't think I've ever had trouble building Twisted before, but now > they've made it dependent on Zope Interfaces, which won't build for > me. > I'm running OS 10.4, Bob's Python 2.4, latest svn of PyObjC and > py2app. Here's the traceback I'm getting when I try to build Zope > Interfaces 3.0.1: Just install the zope.interfaces from http://pythonmac.org/packages/ -- unless you don't trust me, in which case, I don't care :) It's a dumb bug in the z.i sources that gcc4 doesn't like. It probably compiles if you gcc_switch to 3.3. I recall that someone sent the z.i guys a patch, I don't know why they haven't made a 3.0.2 release yet. Lazy, I guess :) > Since when do either Zope or Twisted require binary components anyway? Since Zope 3 and Twisted 2. -bob From delza at livingcode.org Mon May 23 18:59:48 2005 From: delza at livingcode.org (Dethe Elza) Date: Mon, 23 May 2005 09:59:48 -0700 Subject: [Pythonmac-SIG] Building Twisted In-Reply-To: <3CB35038-DF57-4836-8456-15FA9C1F43E7@redivi.com> References: <3CB35038-DF57-4836-8456-15FA9C1F43E7@redivi.com> Message-ID: <3E6A21D5-DFFE-420D-82FA-8438AF33D5CA@livingcode.org> > Just install the zope.interfaces from http://pythonmac.org/ > packages/ -- unless you don't trust me, in which case, I don't care :) > Bob, your packages were the first place I checked, but I checked for twisted and completely missed the fact that you had a package for Zope Interfaces. Thank you! > It's a dumb bug in the z.i sources that gcc4 doesn't like. It > probably compiles if you gcc_switch to 3.3. I recall that someone > sent the z.i guys a patch, I don't know why they haven't made a > 3.0.2 release yet. Lazy, I guess :) > > > >> Since when do either Zope or Twisted require binary components >> anyway? >> >> > > Since Zope 3 and Twisted 2. > Progress. There's no stopping it, more's the pity. Thanks again. --Dethe Windows has detected the mouse has moved. Please restart your system for changes to take effect. From lee_cullens at mac.com Tue May 24 03:04:28 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Mon, 23 May 2005 21:04:28 -0400 Subject: [Pythonmac-SIG] Run Python module directly from Terminal? Message-ID: I wanted to run a python module across a file and tried just double clicking the script, which thanks to Bob's build (I guess) would have worked fine if I had not used a .py file and had not had an arg. Anyway it showed me enough to accomplish what I wanted. I did not want to create a standalone because I edit it for different (usually one time) purposes and thus usually have only a .py file to start. So, after changing the first item to python (instead of pythonw) and including a third item for the arg, this worked: ============================= Welcome to Darwin! Chinook ~ 81 $"/usr/local/bin/python" "/Users/Chinook/PythonProjects/ MyUtilities/ConvertFile.py" "/Users/Chinook/TestFiles/AtoB.txt" && echo Exit status: $? && exit 1 Exit status: 0 logout [Process completed] ================================ So what's my problem? Well I know I could reduce the typing with some aliasing in my .profile file, but I'm wondering if there is not a simpler/direct way of accomplishing a basic task such as this? Thanks, Lee C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050523/bc30f5af/attachment.htm From leshill at gmail.com Tue May 24 04:22:31 2005 From: leshill at gmail.com (Les Hill) Date: Mon, 23 May 2005 22:22:31 -0400 Subject: [Pythonmac-SIG] Run Python module directly from Terminal? In-Reply-To: References: Message-ID: On 5/23/05, Lee Cullens wrote: > So what's my problem? Well I know I could reduce the typing with some > aliasing in my .profile file, but I'm wondering if there is not a > simpler/direct way of accomplishing a basic task such as this? Not sure if this is what you are asking but doing the following as the very first line of the script: #!/usr/bin/env python And then adding the directory where the script is located to your path, for example in your .profile: export PATH=~/Python/scripts:$PATH Finally, make sure the script has the appropriate permissions (execute) by doing the following in a shell where you have moved to the scripts directory: chmod a+x SCRIPTNAME This (admittedly second nature to Unix geeks) straightforward setup should allow you to do the following at the shell command line: wonderland: % your_script_here.py file_to_convert will invoke your script with your_script_here.py as sys.argv[0] and file_to_convert as sys.argv[1]. -- Les Hill leshill at gmail.com From kenneth.m.mcdonald at gmail.com Tue May 24 05:33:31 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Mon, 23 May 2005 22:33:31 -0500 Subject: [Pythonmac-SIG] Note that the 2.4 installer doesn't install pydoc into /usr/local/bin Message-ID: This one caused me a bit of confusion, and I thought I'd mention it so that others would not about it if it bit them. Basically, I installed 2.4 and xattr. However, 'pydoc xattr' couldn't document the xattr module, even though python could load it. I finally figured out that the 2.4 version of pydoc wasn't in /usr/local/bin, meaning the version in /usr/bin was being used, and it wasn't looking at the things installed under 2.4 I like 2.4, though, the the install was very, very easy. Thanks, Ken From kenneth.m.mcdonald at gmail.com Tue May 24 05:42:19 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Mon, 23 May 2005 22:42:19 -0500 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? Message-ID: This is only half a Mac question, I admit, but the Mac aspect will be a big influence... I'd like to pick a crossplatform UI library for which Python has bindings, to start doing some programming in. I've used and liked Tk a lot in the past, but unfortunately it seems to be (1) way out popularity, (2) not moving forward in any significant sense, and (3), in my experience, often quite difficult to use on the Mac with Python and other Tk addons, due to compile issues. The flavors o' the day seem to be either QT or wxWindows. So, questions: 1) Is either of these difficult to install or use with Python on the Mac, using a version of Python newer than that which shipped with Tiger? If one is easier, which one? 2) Similarly, for which is it easier to get third-party widgets and libs up and running, under the conditions stated above. 3) Finally, since I'm asking, a non-Mac question; which do people think is better, both in the context of using with Python, and in the more general context of being a good UI lib. Thanks, Ken From bob at redivi.com Tue May 24 05:42:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 May 2005 20:42:24 -0700 Subject: [Pythonmac-SIG] Note that the 2.4 installer doesn't install pydoc into /usr/local/bin In-Reply-To: References: Message-ID: On May 23, 2005, at 8:33 PM, Kenneth McDonald wrote: > This one caused me a bit of confusion, and I thought I'd mention it so > that others would not about it if it bit them. Basically, I installed > 2.4 and xattr. However, 'pydoc xattr' couldn't document the xattr > module, even though python could load it. I finally figured out that > the 2.4 version of pydoc wasn't in /usr/local/bin, meaning the version > in /usr/bin was being used, and it wasn't looking at the things > installed under 2.4 Yeah, the framework package is a little funny about what and how it installs out-of-framework conveniences. Fortunately python 2.4 has another way to do it: % python -m pydoc xattr """ The -m command line option - python -m modulename will find a module in the standard library, and invoke it. For example, python -m pdb is equivalent to python /usr/lib/python2.4/pdb.py """ -bob From bob at redivi.com Tue May 24 05:58:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 May 2005 20:58:24 -0700 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? In-Reply-To: References: Message-ID: <7904EA58-B432-476A-9F23-92C0F96DE905@redivi.com> On May 23, 2005, at 8:42 PM, Kenneth McDonald wrote: > This is only half a Mac question, I admit, but the Mac aspect will be > a big influence... > > I'd like to pick a crossplatform UI library for which Python has > bindings, to start doing some programming in. I've used and liked Tk a > lot in the past, but unfortunately it seems to be (1) way out > popularity, (2) not moving forward in any significant sense, and (3), > in my experience, often quite difficult to use on the Mac with Python > and other Tk addons, due to compile issues. > > The flavors o' the day seem to be either QT or wxWindows. So, > questions: wxPython is the clear choice for cross-platform GUI for OS X right now. It's more liberally licensed, doesn't have a brain damaged build environment, and it is a whole lot more stable and complete. I would highly recommend ignoring Qt on the Mac right now unless you have a really good reason to bother. > 1) Is either of these difficult to install or use with Python on the > Mac, using a version of Python newer than that which shipped with > Tiger? If one is easier, which one? You ALWAYS want to use the latest wxPython on Mac OS X. Just use Python 2.4.1 and wxPython 2.6, it will work fine (same packages for 10.3 or 10.4). Just make sure to install the TigerPython24Fix package if you plan on compiling any extensions yourself. (With regard to the Python that *does* ship with Mac OS X) It's best to just ignore all Python components that Mac OS X ships with if you're developing redistributable applications. They're already versions behind the rest of the universe and they aren't stable APIs. If you ship an application that depends on a Tiger or Panther Python 2.3, you can be almost certain that it will *not work at all* in Mac OS X 10.5 (where Python 2.4 or newer would be expected to ship, and 2.3 will almost certainly disappear). -bob From lee_cullens at mac.com Tue May 24 06:36:37 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 24 May 2005 00:36:37 -0400 Subject: [Pythonmac-SIG] Run Python module directly from Terminal? In-Reply-To: References: Message-ID: <581E2010-9A8A-4BFB-A234-4957849B84B8@mac.com> It's a little less trouble Les. I added the shbang to my scripts (with Tiger and/or Bob's new right setup the env is dropped) #!/usr/local/bin/python2.4 And changed my shell .profile to export PS1="\u \w \! \$" export PATH=~/PythonProjects/MyUtilities:$PATH #added line without this comment ## # DELUXE-USR-LOCAL-BIN-INSERT # (do not remove this comment) ## echo $PATH | grep -q -s "/usr/local/bin" if [ $? -eq 1 ] ; then PATH=$PATH:/usr/local/bin export PATH fi Then in the Terminal did Chinook ~ 99 $cd ~/PythonProjects/MyUtilities Chinook ~/PythonProjects/MyUtilities 100 $chmod a+x ConvertFile.py Chinook ~/PythonProjects/MyUtilities 101 $ConvertFile.py AtoB.txt which works fine with AtoB.txt in my cd, but otherwise I would need something like Chinook ~/PythonProjects/MyUtilities 102 $cd ~ Chinook ~ 103 $ConvertFile.py ~/TestFiles/AtoB.txt So I still need to set the script file permissions (at least if I save the script to a new name as a variation) and provide an adequate path to the arg file (no magic for that I know of other than a shorthand alias :~) I guess if I would stop looking for magic bullets I'd have time to write a python shell script with which to select a utility script and any arguments (and provide batch processing). I was putting that off until I start playing around with GUIs (after getting a handle on ObjC as Bob suggested). I'm only just two months into this new playground (Mac/Unix(Darwin)/ObjC/Python) and trying to stay on the most productive learning curve :~) At least I'm off on the right foot with my utility scripts written as functions and including the if __name__ == '__main__': block so they can be run either way. Thanks for your help, Lee C On May 23, 2005, at 10:22 PM, Les Hill wrote: > On 5/23/05, Lee Cullens wrote: > >> So what's my problem? Well I know I could reduce the typing with >> some >> aliasing in my .profile file, but I'm wondering if there is not a >> simpler/direct way of accomplishing a basic task such as this? >> > > Not sure if this is what you are asking but doing the following as the > very first line of the script: > > #!/usr/bin/env python > > And then adding the directory where the script is located to your > path, for example in your .profile: > > export PATH=~/Python/scripts:$PATH > > Finally, make sure the script has the appropriate permissions > (execute) by doing the following in a shell where you have moved to > the scripts directory: > > chmod a+x SCRIPTNAME > > This (admittedly second nature to Unix geeks) straightforward setup > should allow you to do the following at the shell command line: > > wonderland: % your_script_here.py file_to_convert > > will invoke your script with your_script_here.py as sys.argv[0] and > file_to_convert as sys.argv[1]. > > -- > Les Hill > leshill at gmail.com > From Chris.Barker at noaa.gov Tue May 24 06:56:45 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon, 23 May 2005 21:56:45 -0700 Subject: [Pythonmac-SIG] Run Python module directly from Terminal? In-Reply-To: <581E2010-9A8A-4BFB-A234-4957849B84B8@mac.com> References: <581E2010-9A8A-4BFB-A234-4957849B84B8@mac.com> Message-ID: <4292B40D.1040608@noaa.gov> Hi Lee, It looks like you've got it pretty well figured out, but the one thing that I'd add is the question of whether there is any need to put these in a special directory. I put all my utilities in /usr/local/bin, which should be on your path for all sorts of reasons anyway. I also tend to remove the ".py" from the end of a script that I'm using in this way. I just find it cleaner to type: ConvertFile AtoB.txt The shell will look at the #! line to figure out what to do, so the .py isn't required. By the way, make sure to practice using the key for command and filename completion at the command prompt...it'll save you a lot of typing. Also there's a little utility: "Open Terminal Here" on the net somewhere that lets you put a button in the finder that will open a terminal window, and cd it to the current folder in the finder--very handy. -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 at noaa.gov From lee_cullens at mac.com Tue May 24 07:34:55 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 24 May 2005 01:34:55 -0400 Subject: [Pythonmac-SIG] Run Python module directly from Terminal? In-Reply-To: <4292B40D.1040608@noaa.gov> References: <581E2010-9A8A-4BFB-A234-4957849B84B8@mac.com> <4292B40D.1040608@noaa.gov> Message-ID: Thanks for the vote of confidence Chris. On May 24, 2005, at 12:56 AM, Chris Barker wrote: > Hi Lee, > > It looks like you've got it pretty well figured out, but the one > thing that I'd add is the question of whether there is any need to > put these in a special directory. > > I put all my utilities in /usr/local/bin, which should be on your > path for all sorts of reasons anyway. Good point - I've been keeping my amateurish utilities separated from the more "professional" stuff and more visible in Finder, but it does lead to more path issues. Maybe when I feel more "professional" I'll keep some stuff there :~) > > I also tend to remove the ".py" from the end of a script that I'm > using in this way. I just find it cleaner to type: > > ConvertFile AtoB.txt > > The shell will look at the #! line to figure out what to do, so > the .py isn't required. > > By the way, make sure to practice using the key for command > and filename completion at the command prompt...it'll save you a > lot of typing. > Have not had much success yet in using tab other than in WingIDE, but with these old fingers I keep trying. > Also there's a little utility: "Open Terminal Here" on the net > somewhere that lets you put a button in the finder that will open a > terminal window, and cd it to the current folder in the finder-- > very handy. > Had that (http://www.entropy.ch/software/applescript/welcome.html) on Panther but have not installed it again yet with Tiger. Are you using it with Tiger? > -Chris > > > > > -- > Christopher Barker, Ph.D. > Oceanographer Ever deal with Woods Hole (MA) - I worked on an engineering project for them many many years ago. > > 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 at noaa.gov > From karl at elemtech.com Tue May 24 16:08:27 2005 From: karl at elemtech.com (Karl Merkley) Date: Tue, 24 May 2005 08:08:27 -0600 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? In-Reply-To: References: Message-ID: <1eae767c5bc815a339b26e0f5fe5ef46@elemtech.com> On May 23, 2005, at 9:42 PM, Kenneth McDonald wrote: > This is only half a Mac question, I admit, but the Mac aspect will be > a big influence... > > I'd like to pick a crossplatform UI library for which Python has > bindings, to start doing some programming in. I've used and liked Tk a > lot in the past, but unfortunately it seems to be (1) way out > popularity, (2) not moving forward in any significant sense, and (3), > in my experience, often quite difficult to use on the Mac with Python > and other Tk addons, due to compile issues. > > The flavors o' the day seem to be either QT or wxWindows. So, > questions: > > 1) Is either of these difficult to install or use with Python on the > Mac, using a version of Python newer than that which shipped with > Tiger? If one is easier, which one? > > 2) Similarly, for which is it easier to get third-party widgets and > libs up and running, under the conditions stated above. > > 3) Finally, since I'm asking, a non-Mac question; which do people > think is better, both in the context of using with Python, and in the > more general context of being a good UI lib. > Just to give the other side of the issue . . . I don't do a lot of PyQt but for the instances that I have it has always worked great. I do a LOT of Qt in a C++ environment across a wide range of platforms (Mac, Windows*, Linux, IRIX, HPUX, Solaris, 32 and 64 bit OS's). I don't have any problems with the build environment. Qmake takes a tiny bit of learning but it's not bad. I am actually using CMake for the cross platform build environment for a very large project (>1M lines with multiple 3rd party libraries) because it was a little more powerful/flexible. Licensing can be a concern but I got my customer to pay for commercial Qt and PyQt licenses. My customer is happy with the work that I do and I give them the tools they ask for more rapidly than I could with other GUI development packages (IMHO of course). I am happy to pay some money to keep a useful tool alive since I am making a living by using the tool. I made my initial decision about three years ago. At that time I felt Qt was by far the stronger library and I have not been disappointed with that decision. Karl From bob at redivi.com Tue May 24 17:21:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 May 2005 08:21:04 -0700 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? In-Reply-To: <1eae767c5bc815a339b26e0f5fe5ef46@elemtech.com> References: <1eae767c5bc815a339b26e0f5fe5ef46@elemtech.com> Message-ID: <19D7E2EE-A6D5-48F1-8373-B932EEEB2E47@redivi.com> On May 24, 2005, at 7:08 AM, Karl Merkley wrote: > > On May 23, 2005, at 9:42 PM, Kenneth McDonald wrote: > > >> This is only half a Mac question, I admit, but the Mac aspect will be >> a big influence... >> >> I'd like to pick a crossplatform UI library for which Python has >> bindings, to start doing some programming in. I've used and liked >> Tk a >> lot in the past, but unfortunately it seems to be (1) way out >> popularity, (2) not moving forward in any significant sense, and (3), >> in my experience, often quite difficult to use on the Mac with Python >> and other Tk addons, due to compile issues. >> >> The flavors o' the day seem to be either QT or wxWindows. So, >> questions: >> >> 1) Is either of these difficult to install or use with Python on the >> Mac, using a version of Python newer than that which shipped with >> Tiger? If one is easier, which one? >> >> 2) Similarly, for which is it easier to get third-party widgets and >> libs up and running, under the conditions stated above. >> >> 3) Finally, since I'm asking, a non-Mac question; which do people >> think is better, both in the context of using with Python, and in the >> more general context of being a good UI lib. >> >> > > Just to give the other side of the issue . . . I don't do a lot of > PyQt > but for the instances that I have it has always worked great. I do a > LOT of Qt in a C++ environment across a wide range of platforms (Mac, > Windows*, Linux, IRIX, HPUX, Solaris, 32 and 64 bit OS's). > > I don't have any problems with the build environment. Qmake takes a > tiny bit of learning but it's not bad. I am actually using CMake for > the cross platform build environment for a very large project (>1M > lines with multiple 3rd party libraries) because it was a little more > powerful/flexible. I was really referring to the fact that Qt has all sorts of screwed up things in their own build process for Mac OS X (Qmake aside), so you end up having to tweak environment variables that you should *NEVER EVER TOUCH* (dyld stuff) and you end up with software that has incorrect dylib paths in it (unless cleaned up with install_name_tool manually or with macho_standalone / py2app). PyQt (SIP really) also does a lot of really bizarre things it shouldn't do, and puts WAY too much code behind the scenes in C (even inter-module dependencies), so it's not possible for py2app, py2exe, etc. to correctly analyze this code. py2app says "oh well, they're using SIP, let's include ALL sip modules" so you end up with huge applications that you have to prune by hand. py2exe doesn't know anything about the issue so you end up with non-working applications and you have to keep adding PyQt bits until it works. cx_Freeze includes even less library-specific code than py2exe does, so I imagine it's much the same there too. Since they can't get their library linked correctly, I don't see how they can be trusted to offer a stable as-native-as-possible cross- platform environment for Mac OS X. Having tried it out -- they can't. wxWidgets doesn't quite deliver on that yet either, but they're much farther along and you don't get hit with license fees or stuck with the GPL if you use it. > Licensing can be a concern but I got my customer to pay for commercial > Qt and PyQt licenses. My customer is happy with the work that I do > and > I give them the tools they ask for more rapidly than I could with > other > GUI development packages (IMHO of course). I am happy to pay some > money to keep a useful tool alive since I am making a living by using > the tool. I'd love to pay license fees for when I need something that works well enough everywhere, but such a product doesn't exist yet (when "everywhere" includes Mac OS X). Except maybe REALbasic -- but then you have a different problem. > I made my initial decision about three years ago. At that time I felt > Qt was by far the stronger library and I have not been disappointed > with that decision. Three years ago it didn't work at all on Mac OS X, unless you could the X11 version, which you shouldn't. I'm not sure I'd say it completely "works" on Mac OS X even today. I did say, specifically, that I highly recommend ignoring Qt *on the Mac*. It works fine, even great in many cases, on other platforms... but this is pythonmac-sig, python-list, so presumably the person asking the question wants to make applications that work well on the Mac (and they did say "the Mac aspect will have a big influence"). -bob From karl at elemtech.com Tue May 24 17:35:56 2005 From: karl at elemtech.com (Karl Merkley) Date: Tue, 24 May 2005 09:35:56 -0600 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? In-Reply-To: <19D7E2EE-A6D5-48F1-8373-B932EEEB2E47@redivi.com> References: <1eae767c5bc815a339b26e0f5fe5ef46@elemtech.com> <19D7E2EE-A6D5-48F1-8373-B932EEEB2E47@redivi.com> Message-ID: On May 24, 2005, at 9:21 AM, Bob Ippolito wrote: > > On May 24, 2005, at 7:08 AM, Karl Merkley wrote: > >> >> On May 23, 2005, at 9:42 PM, Kenneth McDonald wrote: >> >> >>> This is only half a Mac question, I admit, but the Mac aspect will be >>> a big influence... >>> >>> I'd like to pick a crossplatform UI library for which Python has >>> bindings, to start doing some programming in. I've used and liked Tk >>> a >>> lot in the past, but unfortunately it seems to be (1) way out >>> popularity, (2) not moving forward in any significant sense, and (3), >>> in my experience, often quite difficult to use on the Mac with Python >>> and other Tk addons, due to compile issues. >>> >>> The flavors o' the day seem to be either QT or wxWindows. So, >>> questions: >>> >>> 1) Is either of these difficult to install or use with Python on the >>> Mac, using a version of Python newer than that which shipped with >>> Tiger? If one is easier, which one? >>> >>> 2) Similarly, for which is it easier to get third-party widgets and >>> libs up and running, under the conditions stated above. >>> >>> 3) Finally, since I'm asking, a non-Mac question; which do people >>> think is better, both in the context of using with Python, and in the >>> more general context of being a good UI lib. >>> >>> >> >> Just to give the other side of the issue . . . I don't do a lot of >> PyQt >> but for the instances that I have it has always worked great. I do a >> LOT of Qt in a C++ environment across a wide range of platforms (Mac, >> Windows*, Linux, IRIX, HPUX, Solaris, 32 and 64 bit OS's). >> >> I don't have any problems with the build environment. Qmake takes a >> tiny bit of learning but it's not bad. I am actually using CMake for >> the cross platform build environment for a very large project (>1M >> lines with multiple 3rd party libraries) because it was a little more >> powerful/flexible. > > I was really referring to the fact that Qt has all sorts of screwed up > things in their own build process for Mac OS X (Qmake aside), so you > end up having to tweak environment variables that you should *NEVER > EVER TOUCH* (dyld stuff) and you end up with software that has > incorrect dylib paths in it (unless cleaned up with install_name_tool > manually or with macho_standalone / py2app). > > PyQt (SIP really) also does a lot of really bizarre things it > shouldn't do, and puts WAY too much code behind the scenes in C (even > inter-module dependencies), so it's not possible for py2app, py2exe, > etc. to correctly analyze this code. py2app says "oh well, they're > using SIP, let's include ALL sip modules" so you end up with huge > applications that you have to prune by hand. py2exe doesn't know > anything about the issue so you end up with non-working applications > and you have to keep adding PyQt bits until it works. cx_Freeze > includes even less library-specific code than py2exe does, so I > imagine it's much the same there too. > > Since they can't get their library linked correctly, I don't see how > they can be trusted to offer a stable as-native-as-possible > cross-platform environment for Mac OS X. Having tried it out -- they > can't. wxWidgets doesn't quite deliver on that yet either, but > they're much farther along and you don't get hit with license fees or > stuck with the GPL if you use it. > > >> Licensing can be a concern but I got my customer to pay for commercial >> Qt and PyQt licenses. My customer is happy with the work that I do >> and >> I give them the tools they ask for more rapidly than I could with >> other >> GUI development packages (IMHO of course). I am happy to pay some >> money to keep a useful tool alive since I am making a living by using >> the tool. > > I'd love to pay license fees for when I need something that works well > enough everywhere, but such a product doesn't exist yet (when > "everywhere" includes Mac OS X). Except maybe REALbasic -- but then > you have a different problem. > >> I made my initial decision about three years ago. At that time I felt >> Qt was by far the stronger library and I have not been disappointed >> with that decision. > > Three years ago it didn't work at all on Mac OS X, unless you could > the X11 version, which you shouldn't. > > I'm not sure I'd say it completely "works" on Mac OS X even today. I > did say, specifically, that I highly recommend ignoring Qt *on the > Mac*. It works fine, even great in many cases, on other platforms... > but this is pythonmac-sig, python-list, so presumably the person > asking the question wants to make applications that work well on the > Mac (and they did say "the Mac aspect will have a big influence"). > All I can say is that I ported my very large, very complex app to the Mac during the last 6 month release cycle. Qt was the least of my worries. Everything worked great with a single code base on all my platforms. I did run into one problem with custom cursors and I had to disable them on the Mac. A bummer but not a killer. Yes, I did have to do my own packaging using the installl_name_tool. I had to build a script to build the bundle for me. But I have so many component libraries and frameworks that I wanted to make sure that I know exactly what is going on anyway. BTW, I embed python in my app and I do it in the same method on all platforms and I do not use py2app to help me with that process. I have been interested in your comments on that but as I have not had any problems as of yet I haven't worried about it and the method that I am using works regardless of platform. Karl From bob at redivi.com Tue May 24 17:57:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 May 2005 08:57:12 -0700 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? In-Reply-To: References: <1eae767c5bc815a339b26e0f5fe5ef46@elemtech.com> <19D7E2EE-A6D5-48F1-8373-B932EEEB2E47@redivi.com> Message-ID: <7687AA5F-DA59-4FAA-AAD5-2393B915BD41@redivi.com> On May 24, 2005, at 8:35 AM, Karl Merkley wrote: > All I can say is that I ported my very large, very complex app to the > Mac during the last 6 month release cycle. Qt was the least of my > worries. Everything worked great with a single code base on all my > platforms. I did run into one problem with custom cursors and I > had to > disable them on the Mac. A bummer but not a killer. Yes, I did > have > to do my own packaging using the installl_name_tool. I had to build a > script to build the bundle for me. But I have so many component > libraries and frameworks that I wanted to make sure that I know > exactly > what is going on anyway. But does it look and feel like a typical Mac OS X application? Though, it sounds like you have the sort of application where that doesn't really matter -- and maybe it's not even what you're going for (custom cursors!). It's good that you spent the time to figure out how to package such an application on the Mac. Most people don't... or if they do, they don't get far enough into it to do it correctly. You shouldn't have to create such scripts or track components like that. You're already linking to it, why should you have to do anything else? The macho_standalone tool that comes with py2app does all of this automatically, you might want to take a look at it. > BTW, I embed python in my app and I do it in the same method on all > platforms and I do not use py2app to help me with that process. I > have been interested in your comments on that but as I have not had > any > problems as of yet I haven't worried about it and the method that I am > using works regardless of platform. py2app does three things: 1. provides you with an embedded interpreter (either as an application or a plugin) 2. resolves and consolidates Python dependencies as best as it can 3. resolves and consolidates dyld dependencies and rewrites their Mach-O load commands You've done all three of these things, by hand, for your specific application. There's no compelling reason to switch your build process over, especially because it's cross-platform already and it doesn't sound broken. In the general case, these tasks are time consuming and error prone. py2app takes the time out of it, and is pretty good about not introducing errors that weren't already there in the first place. Resolving Python dependencies isn't an exact science, but the embedded interpreter and Mach-O functionality is quite reliable. -bob From karl at elemtech.com Tue May 24 19:19:15 2005 From: karl at elemtech.com (Karl Merkley) Date: Tue, 24 May 2005 11:19:15 -0600 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? In-Reply-To: <7687AA5F-DA59-4FAA-AAD5-2393B915BD41@redivi.com> References: <1eae767c5bc815a339b26e0f5fe5ef46@elemtech.com> <19D7E2EE-A6D5-48F1-8373-B932EEEB2E47@redivi.com> <7687AA5F-DA59-4FAA-AAD5-2393B915BD41@redivi.com> Message-ID: On May 24, 2005, at 9:57 AM, Bob Ippolito wrote: > On May 24, 2005, at 8:35 AM, Karl Merkley wrote: > >> All I can say is that I ported my very large, very complex app to the >> Mac during the last 6 month release cycle. Qt was the least of my >> worries. Everything worked great with a single code base on all my >> platforms. I did run into one problem with custom cursors and I had >> to >> disable them on the Mac. A bummer but not a killer. Yes, I did >> have >> to do my own packaging using the installl_name_tool. I had to build a >> script to build the bundle for me. But I have so many component >> libraries and frameworks that I wanted to make sure that I know >> exactly >> what is going on anyway. > > But does it look and feel like a typical Mac OS X application? > Though, it sounds like you have the sort of application where that > doesn't really matter -- and maybe it's not even what you're going for > (custom cursors!). Actually, it does have a nice Mac look and feel. The application is a CAD-like thing and the custom cursors help the user to know if you are picking a vertex, curve, surface, or volume. All that happens in a custom graphics window. I am currently recommending that Mac users get a 3-button mouse (heresy!) because while there is a capability to switch mouse interactions for the 3-D environment it is not currently very Mac friendly. Next release ;-) > > It's good that you spent the time to figure out how to package such an > application on the Mac. Most people don't... or if they do, they > don't get far enough into it to do it correctly. > > You shouldn't have to create such scripts or track components like > that. You're already linking to it, why should you have to do > anything else? The macho_standalone tool that comes with py2app does > all of this automatically, you might want to take a look at it. Thanks, I'll take a look at macho_standalone. Karl From bob at redivi.com Tue May 24 19:45:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 May 2005 10:45:35 -0700 Subject: [Pythonmac-SIG] Crossplatform UI libraries best supported on the Mac? In-Reply-To: References: <1eae767c5bc815a339b26e0f5fe5ef46@elemtech.com> <19D7E2EE-A6D5-48F1-8373-B932EEEB2E47@redivi.com> <7687AA5F-DA59-4FAA-AAD5-2393B915BD41@redivi.com> Message-ID: On May 24, 2005, at 10:19 AM, Karl Merkley wrote: > > On May 24, 2005, at 9:57 AM, Bob Ippolito wrote: > > >> On May 24, 2005, at 8:35 AM, Karl Merkley wrote: >> >> >>> All I can say is that I ported my very large, very complex app to >>> the >>> Mac during the last 6 month release cycle. Qt was the least of my >>> worries. Everything worked great with a single code base on all my >>> platforms. I did run into one problem with custom cursors and I >>> had to >>> disable them on the Mac. A bummer but not a killer. Yes, I >>> did have >>> to do my own packaging using the installl_name_tool. I had to >>> build a >>> script to build the bundle for me. But I have so many component >>> libraries and frameworks that I wanted to make sure that I know >>> exactly >>> what is going on anyway. >>> >> >> But does it look and feel like a typical Mac OS X application? >> Though, it sounds like you have the sort of application where that >> doesn't really matter -- and maybe it's not even what you're going >> for (custom cursors!). >> > > Actually, it does have a nice Mac look and feel. The application > is a CAD-like thing and the custom cursors help the user to know if > you are picking a vertex, curve, surface, or volume. All that > happens in a custom graphics window. I am currently recommending > that Mac users get a 3-button mouse (heresy!) because while there > is a capability to switch mouse interactions for the 3-D > environment it is not currently very Mac friendly. Next release ;-) Yeah, in the case where your application is a big custom widget, the "look and feel" issue doesn't really exist.. though most applications aren't in that boat. -bob From a.h.jaffe at gmail.com Tue May 24 23:16:37 2005 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Tue, 24 May 2005 22:16:37 +0100 Subject: [Pythonmac-SIG] Run Python module directly from Terminal? Message-ID: > Chinook ~ 81 $"/usr/local/bin/python" "/Users/Chinook/PythonProjects/ > MyUtilities/ConvertFile.py" "/Users/Chinook/TestFiles/AtoB.txt" && > echo Exit status: $? && exit 1 > > > > Exit status: 0 > > So what's my problem? Well I know I could reduce the typing with > some aliasing in my .profile file, but I'm wondering if there is not > a simpler/direct way of accomplishing a basic task such as this? And just to make some of the other bits more explicit, which you've probably already worked out anyway: first, you don't need any of the quotes, since none of the filenames have spaces or other weird characters. Second, /usr/local/bin is likely already in your path. Third, if you are also already in the directory with AtoB.txt, all you need is probably $ python /Users/Chinook/PythonProjects/MyUtilities/ConvertFile.py AtoB.txt (unless you've written the script in such a way that it needs the absolute path) A From kenneth.m.mcdonald at gmail.com Tue May 24 23:41:06 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Tue, 24 May 2005 16:41:06 -0500 Subject: [Pythonmac-SIG] Best way to install pysqlite on 2.4 / Tiger? Message-ID: I know that Apple includes SQLite with Tiger. My question; what is the 'best' way to install pysqlite, with the python 2.4 upgrade, under Tiger. Specifically; - should I install a newer version of SQLite, or use the one Apple provides? - has anyone actually gotten pysqlite to work under Tiger? Thanks, Ken From kenneth.m.mcdonald at gmail.com Tue May 24 23:42:47 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Tue, 24 May 2005 16:42:47 -0500 Subject: [Pythonmac-SIG] donation Message-ID: Bob, I'd like to make a donation to the pythonmac site--I assume the paypal recipient, bob at redivi.com, is you, Bob Ippolito? I thought this might be of interest, so thought I'd ask on the forum; is the percentage that PayPal takes large enough that you would prefer donations by check? Thanks, Ken From mww at opendarwin.org Tue May 24 23:52:23 2005 From: mww at opendarwin.org (Markus Weissmann) Date: Tue, 24 May 2005 23:52:23 +0200 Subject: [Pythonmac-SIG] Best way to install pysqlite on 2.4 / Tiger? In-Reply-To: References: Message-ID: <4F66FA1E-A5D2-47F8-976E-07E76BA63664@opendarwin.org> On 24.05.2005, at 23:41, Kenneth McDonald wrote: > I know that Apple includes SQLite with Tiger. My question; what is the > 'best' way to install pysqlite, with the python 2.4 upgrade, under > Tiger. Specifically; > > - should I install a newer version of SQLite, or use the one Apple > provides? > - has anyone actually gotten pysqlite to work under Tiger? > I've got got sqlite 3.2.1 and pysqlite 1.1.6 running here - both installed via darwinports; yeah, and also python 2.4. don't know if this is "good" enough for you... ;) -Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ From bob at redivi.com Wed May 25 00:42:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 May 2005 15:42:26 -0700 Subject: [Pythonmac-SIG] donation In-Reply-To: References: Message-ID: <5C030724-95CE-461D-B80C-4E3F45DEE780@redivi.com> On May 24, 2005, at 2:42 PM, Kenneth McDonald wrote: > I'd like to make a donation to the pythonmac site--I assume the paypal > recipient, bob at redivi.com, is you, Bob Ippolito? I thought this might > be of interest, so thought I'd ask on the forum; is the percentage > that PayPal takes large enough that you would prefer donations by > check? Yeah, that is me. It looks like paypal takes around 5% (it seems to vary). Unless you're planning on donating a lot, that ~5% works out to less than the hassle of mailing something and depositing a check. It's up to you, I'll surely cash a check if you want to send one -- but paypal is probably more convenient. Note that pythonmac.org donations go to supporting the site and the stuff I work on (py2app, PyObjC, pythonmac.org packages, xattr, etc.) If you're looking to donate to Python in general, the PSF takes donations too . -bob From lee_cullens at mac.com Wed May 25 01:09:26 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 24 May 2005 19:09:26 -0400 Subject: [Pythonmac-SIG] donation In-Reply-To: References: Message-ID: Maybe, for those of us that won't use PayPal, Bob could note a desired payee and address for a check. I made a donation with PayPal sometime last year and when several months ago they sent me something about updating my account, and I ignored it, their emails became more frequent and frantic (now they are saying I have to update my account because it is being misused in Europe ). Their tactics turned me off and they were demoted to junk mail. Lee C On May 24, 2005, at 5:42 PM, Kenneth McDonald wrote: > Bob, > > I'd like to make a donation to the pythonmac site--I assume the paypal > recipient, bob at redivi.com, is you, Bob Ippolito? I thought this might > be of interest, so thought I'd ask on the forum; is the percentage > that PayPal takes large enough that you would prefer donations by > check? > > Thanks, > Ken > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From rkern at ucsd.edu Wed May 25 01:18:37 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 24 May 2005 16:18:37 -0700 Subject: [Pythonmac-SIG] donation In-Reply-To: References: Message-ID: <4293B64D.20201@ucsd.edu> Lee Cullens wrote: > Maybe, for those of us that won't use PayPal, Bob could note a > desired payee and address for a check. > > I made a donation with PayPal sometime last year and when several > months ago they sent me something about updating my account, and I > ignored it, their emails became more frequent and frantic (now they > are saying I have to update my account because it is being misused in > Europe ). Their tactics turned me off and they were demoted to junk > mail. All of those are spam not sent by PayPal. They are phishing attacks designed to get you to give the senders your financial information. Check the URLs of the links; they don't go to www.paypal.com. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From lee_cullens at mac.com Wed May 25 02:19:31 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 24 May 2005 20:19:31 -0400 Subject: [Pythonmac-SIG] donation In-Reply-To: References: Message-ID: <2274CFF8-781C-49CF-A029-A9D971EA2E9C@mac.com> I think this is an important enough point to post back to the list, and Larry's point is general enough that I'm not violating any personal issue. Good point - I never followed any links to see where they led (which can also be misleading). I follow a policy of initiating a contact and checking whatever certificates they have before providing anything. Same as with phone calls - if I get a call from say xxxx I ask for a name only (no phone numbers or extensions) then call back the actual phone number of xxxx to make sure the call is on the up and up, and even then if they need any sensitive info from me I tell them to send their request via mail (and verify the return address from other correspondence with them). Even so, (especially with the volume that is evident) a "good" organization should warn anyone doing business with them that such is occurring. My bank and my brokerage have both sent me such warnings in the past when their was just a hint of phishing scams that I never saw. Better safe than sorry and their spam is enough to turn me off. Lee C On May 24, 2005, at 7:36 PM, Larry Meyn wrote: > Lee, > > PayPal does seem to send out spam about once a week. . > However, the requests for account updates and warnings of account > misuse are probably not from PayPal. They sound like typical > phishing scams which one might receive even if they've never had a > PayPal account. They used to be easy to spot because of bad > spelling and grammar, but they are getting more polished. > > I'm not endorsing PayPal, just pointing out that emails about > account updates are most probably phishing spam. > > Larry > > On May 24, 2005, at 4:09 PM, Lee Cullens wrote: > > >> Maybe, for those of us that won't use PayPal, Bob could note a >> desired payee and address for a check. >> >> I made a donation with PayPal sometime last year and when several >> months ago they sent me something about updating my account, and I >> ignored it, their emails became more frequent and frantic (now they >> are saying I have to update my account because it is being misused in >> Europe ). Their tactics turned me off and they were demoted to junk >> mail. >> >> Lee C >> >> >> On May 24, 2005, at 5:42 PM, Kenneth McDonald wrote: >> >> >>> Bob, >>> >>> I'd like to make a donation to the pythonmac site--I assume the >>> paypal >>> recipient, bob at redivi.com, is you, Bob Ippolito? I thought this >>> might >>> be of interest, so thought I'd ask on the forum; is the percentage >>> that PayPal takes large enough that you would prefer donations by >>> check? >>> >>> Thanks, >>> Ken >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> > > From bob at redivi.com Wed May 25 02:37:01 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 May 2005 17:37:01 -0700 Subject: [Pythonmac-SIG] donation In-Reply-To: <2274CFF8-781C-49CF-A029-A9D971EA2E9C@mac.com> References: <2274CFF8-781C-49CF-A029-A9D971EA2E9C@mac.com> Message-ID: Well, it's not really paypal's fault that they're a target for phishing attacks. Since the majority of the phishing attacks look like warnings of phishing attacks, it's not really useful for them to send real warnings these days. On their site they have plenty of information about fraudulent emails, etc. Anyhow, if you want to mail me a check, then the 10002 address in the WHOIS database for pythonmac.org (which should match undefined.org, redivi.com) is up to date... though I'm not going to be home for a few weeks as I'm out in the bay area for WWDC and other business. -bob On May 24, 2005, at 5:19 PM, Lee Cullens wrote: > I think this is an important enough point to post back to the list, > and Larry's point is general enough that I'm not violating any > personal issue. > > Good point - I never followed any links to see where they led (which > can also be misleading). I follow a policy of initiating a contact > and checking whatever certificates they have before providing > anything. Same as with phone calls - if I get a call from say xxxx I > ask for a name only (no phone numbers or extensions) then call back > the actual phone number of xxxx to make sure the call is on the up > and up, and even then if they need any sensitive info from me I tell > them to send their request via mail (and verify the return address > from other correspondence with them). > > Even so, (especially with the volume that is evident) a "good" > organization should warn anyone doing business with them that such is > occurring. My bank and my brokerage have both sent me such warnings > in the past when their was just a hint of phishing scams that I never > saw. > > Better safe than sorry and their spam is enough to turn me off. > > Lee C > > > On May 24, 2005, at 7:36 PM, Larry Meyn wrote: > > >> Lee, >> >> PayPal does seem to send out spam about once a week. . >> However, the requests for account updates and warnings of account >> misuse are probably not from PayPal. They sound like typical >> phishing scams which one might receive even if they've never had a >> PayPal account. They used to be easy to spot because of bad >> spelling and grammar, but they are getting more polished. >> >> I'm not endorsing PayPal, just pointing out that emails about >> account updates are most probably phishing spam. >> >> Larry >> >> On May 24, 2005, at 4:09 PM, Lee Cullens wrote: >> >> >> >>> Maybe, for those of us that won't use PayPal, Bob could note a >>> desired payee and address for a check. >>> >>> I made a donation with PayPal sometime last year and when several >>> months ago they sent me something about updating my account, and I >>> ignored it, their emails became more frequent and frantic (now they >>> are saying I have to update my account because it is being >>> misused in >>> Europe ). Their tactics turned me off and they were demoted to >>> junk >>> mail. >>> >>> Lee C >>> >>> >>> On May 24, 2005, at 5:42 PM, Kenneth McDonald wrote: >>> >>> >>> >>>> Bob, >>>> >>>> I'd like to make a donation to the pythonmac site--I assume the >>>> paypal >>>> recipient, bob at redivi.com, is you, Bob Ippolito? I thought this >>>> might >>>> be of interest, so thought I'd ask on the forum; is the percentage >>>> that PayPal takes large enough that you would prefer donations by >>>> check? >>>> >>>> Thanks, >>>> Ken >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> >>> >>> >> >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From rkern at ucsd.edu Wed May 25 02:32:37 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 24 May 2005 17:32:37 -0700 Subject: [Pythonmac-SIG] donation In-Reply-To: <2274CFF8-781C-49CF-A029-A9D971EA2E9C@mac.com> References: <2274CFF8-781C-49CF-A029-A9D971EA2E9C@mac.com> Message-ID: <4293C7A5.2000205@ucsd.edu> Lee Cullens wrote: > Even so, (especially with the volume that is evident) a "good" > organization should warn anyone doing business with them that such is > occurring. My bank and my brokerage have both sent me such warnings > in the past when their was just a hint of phishing scams that I never > saw. You mean like https://www.paypal.com/cgi-bin/webscr?cmd=xpt/general/SecuritySpoof-outside linked from the homepage? -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From lee_cullens at mac.com Wed May 25 04:53:26 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue, 24 May 2005 22:53:26 -0400 Subject: [Pythonmac-SIG] donation In-Reply-To: <4293C7A5.2000205@ucsd.edu> References: <2274CFF8-781C-49CF-A029-A9D971EA2E9C@mac.com> <4293C7A5.2000205@ucsd.edu> Message-ID: All well and good Robert (and no disrespect intended) - but to me they seem to be more interested in sending spam than alerting those that do business with them. The warnings I mentioned were heads-up email followed by more detailed snail mail - all in all much more professional and I didn't have to go digging (and their aggressiveness "seemed" to lessen the volume by decreasing the rewards). Not a matter of size either, as one of the "more professional" examples I noted likely has as many doing business with them as the subject. Some places take things more seriously than others. Even so, I'm not trying to discourage others from using PayPal - just noting why I will not. When I was looking for a new Minolta Dimage I found many sites where authentication icons were not even links (which might be considered a giveaway :~). So yes, one is personally responsible for their own business dealings and what ever one personally choses is their business. I personally believe that the only way to even start to "clean" things up is to demand more professional and ethical practices from the businesses that one might do business with (I won't even get into government). My grandmother once said (c1945) "Only a fool pays someone to pick their pocket." That and my attitude in this matter likely denote just how out-of-date I am, but such is my personal choice (and I'll spare you my sermon on the cell-exchanging life forms we are :~) My best to all, Lee C "Criticism may not be agreeable, but it is necessary. It fulfils the same function as pain in the human body. It calls attention to an unhealthy state of things." ?Winston Churchill. On May 24, 2005, at 8:32 PM, Robert Kern wrote: > Lee Cullens wrote: > > >> Even so, (especially with the volume that is evident) a "good" >> organization should warn anyone doing business with them that such is >> occurring. My bank and my brokerage have both sent me such warnings >> in the past when their was just a hint of phishing scams that I never >> saw. >> > > You mean like > > https://www.paypal.com/cgi-bin/webscr?cmd=xpt/general/SecuritySpoof- > outside > > linked from the homepage? > > -- > Robert Kern > rkern at ucsd.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Tim.Cornwell at csiro.au Wed May 25 09:53:28 2005 From: Tim.Cornwell at csiro.au (Tim Cornwell) Date: Wed, 25 May 2005 17:53:28 +1000 Subject: [Pythonmac-SIG] Python 2.4 on Tiger Message-ID: This might be a RTFM question so apologies if so. I've used darwinports to build python2.4 on Tiger. When I run python2.4, I get the following: fuji:~ root# python2.4 sem_init: Function not implemented sem_wait: Bad file descriptor sem_post: Bad file descriptor sem_wait: Bad file descriptor sem_post: Bad file descriptor sem_init: Function not implemented The command prompt eventually appears and seems to work but I continue getting similar messages. Can anyone help? Thanks, Tim Tim Cornwell Tim.Cornwell csiro.au http://www.atnf.csiro.au/people/tim.cornwell From mww at opendarwin.org Wed May 25 13:01:36 2005 From: mww at opendarwin.org (Markus Weissmann) Date: Wed, 25 May 2005 13:01:36 +0200 Subject: [Pythonmac-SIG] Python 2.4 on Tiger In-Reply-To: References: Message-ID: <18038ACA-B405-47A0-8EDE-D10BFD328033@opendarwin.org> hmmm... strange - works like a charm here; what version/revision of python24 do you have installed? (-> port 'installed python24') I just get Zarquon:/ mww$ python2.4 Python 2.4.1 (#1, May 22 2005, 12:40:19) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> as expected. -Markus On 25.05.2005, at 09:53, Tim Cornwell wrote: > > This might be a RTFM question so apologies if so. I've used > darwinports to build python2.4 on Tiger. When I run python2.4, I get > the following: > > fuji:~ root# python2.4 > sem_init: Function not implemented > sem_wait: Bad file descriptor > sem_post: Bad file descriptor > sem_wait: Bad file descriptor > sem_post: Bad file descriptor > sem_init: Function not implemented > > The command prompt eventually appears and seems to work but I > continue getting similar messages. Can anyone help? > > Thanks, > > Tim > > Tim Cornwell > Tim.Cornwell csiro.au > http://www.atnf.csiro.au/people/tim.cornwell > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ From hengist.podd at virgin.net Wed May 25 15:07:24 2005 From: hengist.podd at virgin.net (has) Date: Wed, 25 May 2005 14:07:24 +0100 Subject: [Pythonmac-SIG] donation Message-ID: Lee Cullens wrote: >All well and good Robert (and no disrespect intended) - but to me they seem to be more interested in sending spam than alerting those that do business with them. I've had a PayPal account since last year and have never received unsolicited mail from them. If you really are getting unwanted mails from PayPal (as opposed to scam mails that only pretend to be), check the Profile > Notifications settings for your PayPal account. As for catching the phishing spam, they're dead easy to spot once you know what they are: like Nigerian 409s, they tend to follow pretty predictable patterns. Any mail with a subject line like "Paypal Team identified some unusual activity in your account" is already more or less a dead cert. The "Dear Anonymous Customer" introduction is another giveaway (real PayPal emails always address you by your real name), as is the "click this link to login" bit (something you should NEVER do, as PayPal themselves will tell you). Just forward with full headers to spoof at paypal.com if you're feeling civic minded, and delete. An additional trick might be to set up a separate 'private' email address solely for use with your PayPal account, and put a filter on your inbox that automatically marks as spam any message claiming to be from PayPal that arrives at any other address. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed May 25 15:34:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 25 May 2005 06:34:56 -0700 Subject: [Pythonmac-SIG] Python 2.4 on Tiger In-Reply-To: References: Message-ID: <3C5AB6B8-9F1B-4E39-87B1-E0516AFEA632@redivi.com> On May 25, 2005, at 12:53 AM, Tim Cornwell wrote: > > This might be a RTFM question so apologies if so. I've used > darwinports to build python2.4 on Tiger. When I run python2.4, I get > the following: > > fuji:~ root# python2.4 > sem_init: Function not implemented > sem_wait: Bad file descriptor > sem_post: Bad file descriptor > sem_wait: Bad file descriptor > sem_post: Bad file descriptor > sem_init: Function not implemented > > The command prompt eventually appears and seems to work but I > continue getting similar messages. Can anyone help? Python 2.4.1 shouldn't do that. Maybe your ports tree is old or perhaps you have a panther version of Xcode installed? -bob From dangoor at gmail.com Wed May 25 17:19:50 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Wed, 25 May 2005 11:19:50 -0400 Subject: [Pythonmac-SIG] Best way to install pysqlite on 2.4 / Tiger? In-Reply-To: References: Message-ID: <3f085ecd05052508191d7ad102@mail.gmail.com> On 5/24/05, Kenneth McDonald wrote: > I know that Apple includes SQLite with Tiger. My question; what is the > 'best' way to install pysqlite, with the python 2.4 upgrade, under > Tiger. Specifically; > > - should I install a newer version of SQLite, or use the one Apple provides? > - has anyone actually gotten pysqlite to work under Tiger? I don't know what version of sqlite comes with Tiger (and typing sqlite at the command line doesn't bring up anything). Personally, I'm using the latest sqlite (alter table add column comes in handy now and then ;) I'm also running pysqlite 2.01. I didn't have any real trouble building sqlite or pysqlite using fairly standard means (configure; make and setup.py) Kevin From kquirk at solidworks.com Wed May 25 18:19:49 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Wed, 25 May 2005 12:19:49 -0400 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work Message-ID: We've been building our product using py2app 0.2 on Panther with Apple's Mac python. That has worked for some time, but as has been pointed out here many times, relying on that is not the safest way to ship things to real customers. The app is large with several C++ extensions using boost::python. We need to support customers running Panther as well as Tiger, so we're continuing to build under Panther. So we've upgraded Panther to MacPython 2.4, and grabbed the appropriate py2app (py2app-0.2-py2.4-macosx10.3). The application builds, but when we run it, it dies with "Interpreter not initialized (version mismatch?)". This happens the instant we attempt to import our first extension. We can load our extensions manually by specifying the appropriate DYLD environment variables and they load properly. The DYLD parameters are specified in the setup.py (and it all seems to work with the Apple native python). We have carefully checked all our dependencies in the xcode build - we're building everything with the 2.4 python. The .plist file in the constructed application indicates that we successfully found and built with the 2.4 python. We've tried changing the symlink at /usr/bin/python to point to 2.4 instead of 2.3, but that didn't fix the problem, so we put it back the way it was. We tried installing PantherPythonFix (out of desperation) but we didn't expect it to change anything and it didn't. We build using python2.4 setup.py py2app It looks like the executable built into our app (in the Contents/MacOS folder) is still somehow dependent on the native python, but we can't figure out what the problem is. Help, please? Any ideas? Kent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050525/7856b641/attachment.htm From delza at livingcode.org Wed May 25 18:53:48 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed, 25 May 2005 09:53:48 -0700 Subject: [Pythonmac-SIG] Frameworks which won't import In-Reply-To: <216B1BBD-6634-4E9D-8D99-BA9DF08C9D1C@redivi.com> References: <5F7CCAEF-577D-4458-9300-4A3554CB89AE@livingcode.org> <216B1BBD-6634-4E9D-8D99-BA9DF08C9D1C@redivi.com> Message-ID: On 18-May-05, at 11:14 AM, Bob Ippolito wrote: > On May 18, 2005, at 2:05 PM, Dethe Elza wrote: >> I have a framework which I can't import into PyObjC in the usual >> way. Since then I've tried various other frameworks I've found on my >> system, mostly embedded in application bundles, and some import but >> others do not. I'm not getting any information on *why* they can't >> be imported, even when I turn on debugging with the following lines >> before any attempt to load bundles. > [snip] > It's more or less a case of getting what you deserve, trying to > load embedded frameworks from applications that were never meant > for external use. They probably depend on symbols defined in the > executable or something. So I finally got a response from Skype tech support: Skype.framework is currently a private framework, meaning that you should include it in your application. It should be located in @executable_path/../Frameworks ... Let us know if this solves your problem. And I've embedded the framework in my (PyObjC) application in foo.app/ Contents/Frameworks/ but it still doesn't load. Is this a case where I should build a wrapper in ObjC and then load my wrapper from PyObjC? --Dethe "Isn't 'A guy tried to smuggle plutonium from Tajikistan into Afganistan or Pakistan' just a fancy way of saying 'Live for the moment?'" --Get Your War On From tim.cornwell at csiro.au Thu May 26 00:35:11 2005 From: tim.cornwell at csiro.au (Tim Cornwell) Date: Wed, 25 May 2005 22:35:11 +0000 (UTC) Subject: [Pythonmac-SIG] Python 2.4 on Tiger References: <3C5AB6B8-9F1B-4E39-87B1-E0516AFEA632@redivi.com> Message-ID: Bob Ippolito redivi.com> writes: > > > On May 25, 2005, at 12:53 AM, Tim Cornwell wrote: > > > > > This might be a RTFM question so apologies if so. I've used > > darwinports to build python2.4 on Tiger. When I run python2.4, I get > > the following: > > > > fuji:~ root# python2.4 > > sem_init: Function not implemented > > sem_wait: Bad file descriptor > > sem_post: Bad file descriptor > > sem_wait: Bad file descriptor > > sem_post: Bad file descriptor > > sem_init: Function not implemented > > > > The command prompt eventually appears and seems to work but I > > continue getting similar messages. Can anyone help? > > Python 2.4.1 shouldn't do that. Maybe your ports tree is old or > perhaps you have a panther version of Xcode installed? One (the?) problem is that I'm building against gcc 3.3 instead of 4.0. I'm linking against a library that won't build with 4.0 (yet). I'll probably go back and use 2.3 instead. Thanks, Tim From bob at redivi.com Thu May 26 00:56:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 25 May 2005 15:56:34 -0700 Subject: [Pythonmac-SIG] Python 2.4 on Tiger In-Reply-To: References: <3C5AB6B8-9F1B-4E39-87B1-E0516AFEA632@redivi.com> Message-ID: <41A4E935-E9E1-4658-B9EB-80C1B33E3858@redivi.com> On May 25, 2005, at 3:35 PM, Tim Cornwell wrote: > Bob Ippolito redivi.com> writes: > >> On May 25, 2005, at 12:53 AM, Tim Cornwell wrote: >> >> >>> >>> This might be a RTFM question so apologies if so. I've used >>> darwinports to build python2.4 on Tiger. When I run python2.4, I get >>> the following: >>> >>> fuji:~ root# python2.4 >>> sem_init: Function not implemented >>> sem_wait: Bad file descriptor >>> sem_post: Bad file descriptor >>> sem_wait: Bad file descriptor >>> sem_post: Bad file descriptor >>> sem_init: Function not implemented >>> >>> The command prompt eventually appears and seems to work but I >>> continue getting similar messages. Can anyone help? >>> >> >> Python 2.4.1 shouldn't do that. Maybe your ports tree is old or >> perhaps you have a panther version of Xcode installed? >> > > One (the?) problem is that I'm building against gcc 3.3 instead of > 4.0. I'm > linking against a library that won't build with 4.0 (yet). I'll > probably go back > and use 2.3 instead. Just use the binary distribution of python 2.4.1 and gcc_switch to 3.3 before building your extension. It's not C++ code, the Mach-O calling convention or C ABI haven't changed. -bob From lee_cullens at mac.com Thu May 26 01:14:20 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed, 25 May 2005 19:14:20 -0400 Subject: [Pythonmac-SIG] donation In-Reply-To: References: Message-ID: <15DD7779-6CCA-47BE-B1E7-22A36F192750@mac.com> Just an obvious point. PayPal is a mute point for those with online banking and since bill-paying is usually a free enticement, there is no service charge or fee deducted. If, in addition, Bob's entity had an A/R account, a physical check mailed locally would not even be involved. Lee C From kquirk at solidworks.com Thu May 26 05:18:07 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Wed, 25 May 2005 23:18:07 -0400 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work Message-ID: Just because this is really trouble for me, and I'm hoping to get some ideas, I'm going to update with some of the other things we've tried today: a) I updated py2app from svn and rebuilt it on this machine using python2.4 setup.py bdist-mpkg --open Just to make sure it was compatible with the python2.4 I have here. b) We replaced our app's primary .py file with one that does nothing but import our first extension. It broke (thereby confirming that we're not setting up things funny in our .py file). c) I added some import statements for standard python modules: import os import sys import time print "hello" import util # one of our extensions It got through the first 4 lines and crashed on the last one. d) We dumped sys.environ and sys.executable, then constructed a command line that used those variables to explicitly load our extension. It worked. e) I build using --semi-standalone and the application worked (except that it doesn't include the python framework, which is the point of this exercise). So it appears to be something wrong with the python framework being built into my app. f) I looked into the app/Contents/Frameworks/Python.framework and it contains nothing that looks like python library code. But I'm guessing that's because it's all been stuffed into the site-packages.zip in Resources. Or something. Help? Please? Kent ________________________________________ From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig-bounces at python.org] On Behalf Of Kent Quirk Sent: Wednesday, May 25, 2005 12:20 PM To: pythonmac-sig at python.org Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work We've been building our product using py2app 0.2 on Panther with Apple's Mac python. That has worked for some time, but as has been pointed out here many times, relying on that is not the safest way to ship things to real customers. The app is large with several C++ extensions using boost::python. We need to support customers running Panther as well as Tiger, so we're continuing to build under Panther. So we've upgraded Panther to MacPython 2.4, and grabbed the appropriate py2app (py2app-0.2-py2.4-macosx10.3). The application builds, but when we run it, it dies with "Interpreter not initialized (version mismatch?)".? This happens the instant we attempt to import our first extension. We can load our extensions manually by specifying the appropriate DYLD environment variables and they load properly. The DYLD parameters are specified in the setup.py (and it all seems to work with the Apple native python). We have carefully checked all our dependencies in the xcode build - we're building everything with the 2.4 python. The .plist file in the constructed application indicates that we successfully found and built with the 2.4 python. We've tried changing the symlink at /usr/bin/python to point to 2.4 instead of 2.3, but that didn't fix the problem, so we put it back the way it was. We tried installing PantherPythonFix (out of desperation) but we didn't expect it to change anything and it didn't. We build using python2.4 setup.py py2app It looks like the executable built into our app (in the Contents/MacOS folder) is still somehow dependent on the native python, but we can't figure out what the problem is. Help, please? Any ideas? ???????????? Kent From bob at redivi.com Thu May 26 05:42:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 25 May 2005 20:42:26 -0700 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work In-Reply-To: References: Message-ID: On May 25, 2005, at 8:18 PM, Kent Quirk wrote: > Just because this is really trouble for me, and I'm hoping to get > some ideas, I'm going to update with some of the other things we've > tried today: > > a) I updated py2app from svn and rebuilt it on this machine using > python2.4 setup.py bdist-mpkg --open > Just to make sure it was compatible with the python2.4 I have here. > > b) We replaced our app's primary .py file with one that does > nothing but import our first extension. It broke (thereby > confirming that we're not setting up things funny in our .py file). > > c) I added some import statements for standard python modules: > > import os > import sys > import time > print "hello" > import util # one of our extensions > > It got through the first 4 lines and crashed on the last one. Trash your extension and rebuild it against the new python. -bob From jwight_lists at toxicsoftware.com Thu May 26 06:13:02 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Thu, 26 May 2005 00:13:02 -0400 Subject: [Pythonmac-SIG] Python Metadata Importer Message-ID: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> Just to let everyone know that my Python Metadata Importer plug-in was released the other day. http://toxicsoftware.com/blog/index.php/weblog/ python_metadata_importer_101_released/ I decided to change the license to BSD after Bob and co brought up some good points, so now anyone can use it as a basis for writing Python mdimporters without having to deal the GPLness. The plug-in seems to work fine and unless anyone has some feature suggestions for it I hope I won't post about it any more on this mailing list ;-) Quick screenshot of the Get Info window showing a .py file: http:// toxicsoftware.com/blog/images/uploads/PythonMetaImporterGetInfo.png Jon. From bob at redivi.com Thu May 26 06:38:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 25 May 2005 21:38:32 -0700 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> Message-ID: <5A11F5B8-DCFC-4862-8466-E088F950E196@redivi.com> On May 25, 2005, at 9:13 PM, Jonathan Wight wrote: > Just to let everyone know that my Python Metadata Importer plug-in > was released the other day. > > http://toxicsoftware.com/blog/index.php/weblog/ > python_metadata_importer_101_released/ You could throw away like 95% of that code if you had just used PyObjC to implement CMetadataImporter... I guess I should just write the code and prove it. Also, I have seen that the compiler module is orders of magnitude slower than the parser module and will die various deaths if you give it really large sources, so I would recommend moving away from it (even though it's far easier to use). -bob From kquirk at solidworks.com Thu May 26 06:48:05 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Thu, 26 May 2005 00:48:05 -0400 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work Message-ID: Sadly, that was one of the first things we tried. We've done a full clean build several times and checked the .xcode project files to make sure there were no references to the old python anywhere. And as I said, the extension as stored in the .app loads properly everywhere but from the executable within the app. Any other ideas? Kent -----Original Message----- From: Bob Ippolito [mailto:bob at redivi.com] Sent: Wednesday, May 25, 2005 11:42 PM To: Kent Quirk Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work On May 25, 2005, at 8:18 PM, Kent Quirk wrote: > Just because this is really trouble for me, and I'm hoping to get > some ideas, I'm going to update with some of the other things we've > tried today: > > a) I updated py2app from svn and rebuilt it on this machine using > python2.4 setup.py bdist-mpkg --open > Just to make sure it was compatible with the python2.4 I have here. > > b) We replaced our app's primary .py file with one that does > nothing but import our first extension. It broke (thereby > confirming that we're not setting up things funny in our .py file). > > c) I added some import statements for standard python modules: > > import os > import sys > import time > print "hello" > import util # one of our extensions > > It got through the first 4 lines and crashed on the last one. Trash your extension and rebuild it against the new python. -bob From bob at redivi.com Thu May 26 07:32:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed, 25 May 2005 22:32:32 -0700 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work In-Reply-To: References: Message-ID: You definitely have something that's linking to Python 2.3. Try DYLD_PRINT_LIBRARIES and/or run it under gdb and backtrace to see which init function is failing. % env DYLD_PRINT_LIBRARIES=1 build/ReSTedit.app/Contents/MacOS/ReSTedit dyld: loaded: /Volumes/Crack/src/WWDC2005/ReSTedit-0/build/ ReSTedit.app/Contents/MacOS/ReSTedit dyld: loaded: /System/Library/Frameworks/Foundation.framework/ Versions/C/Foundation dyld: loaded: /System/Library/Frameworks/AppKit.framework/Versions/C/ AppKit dyld: loaded: /usr/lib/libSystem.B.dylib, cpu-sub-type: 0 dyld: loaded: /usr/lib/libxml2.2.dylib ... and so on (eventually you'll start seeing extensions) The callstack under gdb will look like this: #0 0x0026eae0 in init_objc () #1 0x100a8d54 in _PyImport_LoadDynamicModule (name=0xbfffb8e0 "objc._objc", pathname=0xbfffb3e0 "/Users/bob/src/pyobjc/build/ lib.darwin-8.1.0-Power_Macintosh-2.4/objc/_objc.so", fp=0x0) at / Users/bob/src/Python-2.4.1/Python/importdl.c:53 #2 0x100a4e18 in load_module (name=0xbfffb8e0 "objc._objc", fp=0xa000ddf4, buf=0xbfffb3e0 "/Users/bob/src/pyobjc/build/ lib.darwin-8.1.0-Power_Macintosh-2.4/objc/_objc.so", type=0, loader=0x0) at /Users/bob/src/Python-2.4.1/Python/import.c:1665 ..... All the init functions are named simply init with the name of the extension appended (in this case the extension is named _objc).. so you can future-break on them. otool -L on any extension file will tell you what it's linked to.. py2app ships with a tool called macho_find which will find all of the Mach-O files in a folder... uh, here's a script that should help you find the culprit: #!/usr/local/bin/python2.4 """ Usage: linksto.py /System/Library/Frameworks/AppKit.framework/AppKit build """ from macholib.MachOGraph import MachOGraph from macholib.util import iter_platform_files def linksto(target, searchpath): g = MachOGraph() for path in iter_platform_files(searchpath): g.run_file(path) return set( g.graph.edges[edge_ident][0] for edge_ident in g.graph.inc_edges(g.findNode(target).graphident) ) if __name__ == '__main__': import sys, os try: for path in sorted(linksto(*map(os.path.realpath, sys.argv [1:]))): print path except TypeError: raise SystemExit, __doc__.strip() ... % python linksto.py /System/Library/Frameworks/AppKit.framework/ AppKit build /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa /Volumes/Crack/src/WWDC2005/ReSTedit-0/build/ReSTedit.app/Contents/ MacOS/ReSTedit /Volumes/Crack/src/WWDC2005/ReSTedit-0/build/ReSTedit.app/Contents/ Resources/Python/lib-dynload/AppKit/_AppKit.so /Volumes/Crack/src/WWDC2005/ReSTedit-0/build/ReSTedit.app/Contents/ Resources/ReSTeditPlugIn.bundle/Contents/MacOS/ReSTeditPlugIn /Volumes/Crack/src/WWDC2005/ReSTedit-0/build/ReSTeditPlugIn.bundle/ Contents/MacOS/ReSTeditPlugIn You'd use it largely the same way, except with Python.framework/ Python instead of AppKit.framework/AppKit -bob On May 25, 2005, at 9:48 PM, Kent Quirk wrote: > Sadly, that was one of the first things we tried. We've done a full > clean build several times and checked the .xcode project files to make > sure there were no references to the old python anywhere. > > And as I said, the extension as stored in the .app loads properly > everywhere but from the executable within the app. > > Any other ideas? > > Kent > > -----Original Message----- > From: Bob Ippolito [mailto:bob at redivi.com] > Sent: Wednesday, May 25, 2005 11:42 PM > To: Kent Quirk > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work > > > On May 25, 2005, at 8:18 PM, Kent Quirk wrote: > > >> Just because this is really trouble for me, and I'm hoping to get >> some ideas, I'm going to update with some of the other things we've >> tried today: >> >> a) I updated py2app from svn and rebuilt it on this machine using >> python2.4 setup.py bdist-mpkg --open >> Just to make sure it was compatible with the python2.4 I have here. >> >> b) We replaced our app's primary .py file with one that does >> nothing but import our first extension. It broke (thereby >> confirming that we're not setting up things funny in our .py file). >> >> c) I added some import statements for standard python modules: >> >> import os >> import sys >> import time >> print "hello" >> import util # one of our extensions >> >> It got through the first 4 lines and crashed on the last one. >> > > Trash your extension and rebuild it against the new python. > > -bob > > From jwight_lists at toxicsoftware.com Thu May 26 14:44:45 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Thu, 26 May 2005 08:44:45 -0400 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <5A11F5B8-DCFC-4862-8466-E088F950E196@redivi.com> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <5A11F5B8-DCFC-4862-8466-E088F950E196@redivi.com> Message-ID: On May 26, 2005, at 00:38, Bob Ippolito wrote: > On May 25, 2005, at 9:13 PM, Jonathan Wight wrote: > > >> Just to let everyone know that my Python Metadata Importer plug-in >> was released the other day. >> >> http://toxicsoftware.com/blog/index.php/weblog/ >> python_metadata_importer_101_released/ >> > > You could throw away like 95% of that code if you had just used > PyObjC to implement CMetadataImporter... I guess I should just > write the code and prove it. Yes I'm sure you could. I posted why I didn't use PyObjC in a previous post. When I started the project PyObjC wasn't yet officially released for 10.4, also I didn't think either making PyObjC a requirement or bundling a portion of it with my importer was particularly useful. > Also, I have seen that the compiler module is orders of magnitude > slower than the parser module and will die various deaths if you > give it really large sources, so I would recommend moving away from > it (even though it's far easier to use). Indexing all the Python files on my system doesn't seem any slower with the current code over the previous code which just used the parser module (and only used it to find function & class names). It's hard to measure accurately because all the indexing is occurring in the background spotlight daemons - and I don't know what else Spotlight is doing at that time. I'm not overly worried about performance at this point - and so far it hasn't had trouble with any Python file I've thrown at it (including among other things PyObjC). Jon. From hengist.podd at virgin.net Thu May 26 15:28:59 2005 From: hengist.podd at virgin.net (has) Date: Thu, 26 May 2005 14:28:59 +0100 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? Message-ID: Hi all, please forgive my crappy knowledge of C, etc. in advance... ;) In updating my osaterminology package to support Tiger, I've added a new function, OSAGetSdef(), to its OSATerminology.so extension [1]. To allow the extension to build on older OSes, I've inserted an #ifdef as shown: static PyObject * PyOSA_GetSdef(PyObject* self, PyObject* args) { #ifdef AVAILABLE_MAC_OS_X_VERSION_10_4_AND_LATER ... err = OSACopyScriptingDefinition(&fsref, 0, &sdef); ... return res; #else /* Return None when sdef is unobtainable. Client can then call OSAGetTerminology() instead. */ Py_INCREF(Py_None); return Py_None; #endif } But now I realise this doesn't help in making a compiled extension work across different OSes, so I obviously need to do something more/else. Obviously the extension needs to be built on Tiger to provide sdef support, but what should I do to ensure that, say, applications containing that binary extension will still work OK when run on earlier OSes? For example, should I include both extension builds in the osaterminology package and have it import the appropriate one according to OS version, or is there a better/more elegant/official way of doing it? Many thanks, has [1] This is a modified version of OSATerminology.so that's bundled in the osaterminology package, btw; I don't use the original copy in lib-dynload as it's buggy. -- http://freespace.virgin.net/hamish.sanderson/ From njriley at uiuc.edu Thu May 26 15:37:00 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 26 May 2005 08:37:00 -0500 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> Message-ID: <20050526133700.GA30530@uiuc.edu> On Thu, May 26, 2005 at 12:13:02AM -0400, Jonathan Wight wrote: > Just to let everyone know that my Python Metadata Importer plug-in > was released the other day. > > http://toxicsoftware.com/blog/index.php/weblog/ > python_metadata_importer_101_released/ Since I installed this I got a continuous stream of: May 26 08:32:27 byron mdimportserver[29832]: Exception occured: *** -[NSCFArray addObject:]: attempt to insert nil in console.log. I assume this will go away once the import finishes, but it's rather annoying at the moment. -- Nicholas Riley | From njriley at uiuc.edu Thu May 26 15:39:00 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 26 May 2005 08:39:00 -0500 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: Message-ID: <20050526133900.GB30530@uiuc.edu> On Thu, May 26, 2005 at 02:28:59PM +0100, has wrote: > Obviously the extension needs to be built on Tiger to provide sdef > support, but what should I do to ensure that, say, applications > containing that binary extension will still work OK when run on > earlier OSes? For example, should I include both extension builds in > the osaterminology package and have it import the appropriate one > according to OS version, or is there a better/more elegant/official > way of doing it? You can use weak linking if you don't need to support 10.1.x or earlier, otherwise you'll have to load individual bundles, or use CFBundle or some lower-level mechanism to obtain and call through function pointers. -- Nicholas Riley | From jwight_lists at toxicsoftware.com Thu May 26 15:54:22 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Thu, 26 May 2005 09:54:22 -0400 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <20050526133700.GA30530@uiuc.edu> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> Message-ID: <235E5299-AA03-4E0B-B0D8-344FB45D19F6@toxicsoftware.com> Yeah I screwed up with the code that scans functions. There's a new version online now that fixes that. Jon. On May 26, 2005, at 09:37, Nicholas Riley wrote: > On Thu, May 26, 2005 at 12:13:02AM -0400, Jonathan Wight wrote: > > > >> Just to let everyone know that my Python Metadata Importer plug-in >> was released the other day. >> >> http://toxicsoftware.com/blog/index.php/weblog/ >> python_metadata_importer_101_released/ >> >> >> > > Since I installed this I got a continuous stream of: > > May 26 08:32:27 byron mdimportserver[29832]: Exception occured: *** > -[NSCFArray addObject:]: attempt to insert nil > > in console.log. I assume this will go away once the import finishes, > but it's rather annoying at the moment. > > -- Nicholas Riley | njriley> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > From gideon at computer.org Thu May 26 16:07:19 2005 From: gideon at computer.org (Gideon May) Date: Thu, 26 May 2005 16:07:19 +0200 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> Message-ID: <9002978A-C304-4B0C-B29A-885FFD84EB14@computer.org> Jon, I have a number of python files with dos line ending (\r\n), which can't be parsed with the parser module. If you change the open call in importer.py in : theSource = file(inPath,'U').read() the line ending is translated into newline and the script is able to read them :) Cheers, Gideon From jwight_lists at toxicsoftware.com Thu May 26 16:54:59 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Thu, 26 May 2005 10:54:59 -0400 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <20050526133700.GA30530@uiuc.edu> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> Message-ID: <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> After adding Gideon's suggestion for CRLF ending file. My importer is failing on only 8 files out of 3084 files. All the failures are with Python files that try to generate the __version__ attribute with code instead, e.g.: __version__ = string.split('$Revision: 1.8 $')[1] __version__ = '$Revision: 1.6 $'[11:-2] And so on. My options are: #1 Continue to fail and not process the script any further (easiest solution ;-) #2 Just ignore the attribute in question. #3 Convert the attribute into a string even though it might not make much sense. #4 Execute the line and get the computed value of the attribute. I don't really want to execute the line - who the heck knows what it could do. Unless anyone has any better ideas I'm just going to try and gracefully ignore the attribute. Jon. On May 26, 2005, at 09:37, Nicholas Riley wrote: > On Thu, May 26, 2005 at 12:13:02AM -0400, Jonathan Wight wrote: > > >> Just to let everyone know that my Python Metadata Importer plug-in >> was released the other day. >> >> http://toxicsoftware.com/blog/index.php/weblog/ >> python_metadata_importer_101_released/ >> >> > > Since I installed this I got a continuous stream of: > > May 26 08:32:27 byron mdimportserver[29832]: Exception occured: *** > -[NSCFArray addObject:]: attempt to insert nil > > in console.log. I assume this will go away once the import finishes, > but it's rather annoying at the moment. > > -- > Nicholas Riley | njriley> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From kquirk at solidworks.com Thu May 26 17:03:01 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Thu, 26 May 2005 11:03:01 -0400 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work Message-ID: Thanks for the hint. This helped us a lot, but we don't quite have the complete answer. We were never linking to Python 2.3, but otool shows us that we have references to /Library/Frameworks/Python.framework in our extensions (and in the embedded Python executable) rather than to @executable_path/../Frameworks/Python.framework. If we manually change all these references using: install_name_tool -change \ /Library/Frameworks/Python.framework/Versions/2.4/Python \ @executable_path/../Frameworks/Python.framework/Versions/2.4/Python \ myfilename.so the program works. So now the question is how do we convince py2app to do this for us? I'm guessing it may have something to do with the way we build our extensions, but I can't figure out how to convince XCode to brand them properly. Kent -----Original Message----- From: Bob Ippolito [mailto:bob at redivi.com] Sent: Thursday, May 26, 2005 1:33 AM To: Kent Quirk Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work You definitely have something that's linking to Python 2.3. Try DYLD_PRINT_LIBRARIES and/or run it under gdb and backtrace to see which init function is failing. otool -L on any extension file will tell you what it's linked to.. py2app ships with a tool called macho_find which will find all of the Mach-O files in a folder... uh, here's a script that should help you find the culprit: From njriley at uiuc.edu Thu May 26 17:05:04 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 26 May 2005 10:05:04 -0500 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> Message-ID: <20050526150504.GA34507@uiuc.edu> On Thu, May 26, 2005 at 10:54:59AM -0400, Jonathan Wight wrote: > After adding Gideon's suggestion for CRLF ending file. My importer is > failing on only 8 files out of 3084 files. > > All the failures are with Python files that try to generate the > __version__ attribute with code instead, e.g.: > > __version__ = string.split('$Revision: 1.8 $')[1] > __version__ = '$Revision: 1.6 $'[11:-2] > > And so on. > > My options are: > > #1 Continue to fail and not process the script any further (easiest > solution ;-) > #2 Just ignore the attribute in question. > #3 Convert the attribute into a string even though it might not make > much sense. > #4 Execute the line and get the computed value of the attribute. > > I don't really want to execute the line - who the heck knows what it > could do. Unless anyone has any better ideas I'm just going to try > and gracefully ignore the attribute. How about just recognizing versions that have the form "$Revision: foo$" and stripping the tag info, just as the code above does? -- Nicholas Riley | From bob at redivi.com Thu May 26 19:47:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 10:47:41 -0700 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work In-Reply-To: References: Message-ID: On May 26, 2005, at 8:03 AM, Kent Quirk wrote: > Thanks for the hint. This helped us a lot, but we don't quite have the > complete answer. > > We were never linking to Python 2.3, but otool shows us that we have > references to /Library/Frameworks/Python.framework in our extensions > (and in the embedded Python executable) rather than to > @executable_path/../Frameworks/Python.framework. > > If we manually change all these references using: > > install_name_tool -change \ > /Library/Frameworks/Python.framework/Versions/2.4/Python \ > > @executable_path/../Frameworks/Python.framework/Versions/2.4/Python \ > myfilename.so > > the program works. > > So now the question is how do we convince py2app to do this for us? > > I'm guessing it may have something to do with the way we build our > extensions, but I can't figure out how to convince XCode to brand them > properly. As I said before, your extensions shouldn't be linking to Python *at all*. Read that part again, and fix the way your extensions are getting linked. (and this is why people should use distutils to link their extensions, because it knows how to link things right) -bob From bob at redivi.com Thu May 26 19:52:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 10:52:05 -0700 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <20050526150504.GA34507@uiuc.edu> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> <20050526150504.GA34507@uiuc.edu> Message-ID: On May 26, 2005, at 8:05 AM, Nicholas Riley wrote: > On Thu, May 26, 2005 at 10:54:59AM -0400, Jonathan Wight wrote: > >> After adding Gideon's suggestion for CRLF ending file. My importer is >> failing on only 8 files out of 3084 files. >> >> All the failures are with Python files that try to generate the >> __version__ attribute with code instead, e.g.: >> >> __version__ = string.split('$Revision: 1.8 $')[1] >> __version__ = '$Revision: 1.6 $'[11:-2] >> >> And so on. >> >> My options are: >> >> #1 Continue to fail and not process the script any further (easiest >> solution ;-) >> #2 Just ignore the attribute in question. >> #3 Convert the attribute into a string even though it might not make >> much sense. >> #4 Execute the line and get the computed value of the attribute. >> >> I don't really want to execute the line - who the heck knows what it >> could do. Unless anyone has any better ideas I'm just going to try >> and gracefully ignore the attribute. >> > > How about just recognizing versions that have the form "$Revision: > foo$" and stripping the tag info, just as the code above does? There are still other places where you'll have version expressions. PyOpenGL's is the most braindead, it reads the version from *A FILE*. Many extensions bring in the version from some extension (i.e. PyObjC). I'd go ahead and just ignore anything that isn't a string. 99.74% of modules isn't bad. Not many people do the CVS thing these days, and that number is going to get smaller and smaller since people are replacing CVS with Subversion and others. -bob From njriley at uiuc.edu Thu May 26 20:03:34 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 26 May 2005 13:03:34 -0500 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> <20050526150504.GA34507@uiuc.edu> Message-ID: <20050526180334.GA48490@uiuc.edu> On Thu, May 26, 2005 at 10:52:05AM -0700, Bob Ippolito wrote: > There are still other places where you'll have version expressions. > > PyOpenGL's is the most braindead, it reads the version from *A FILE*. > > Many extensions bring in the version from some extension (i.e. PyObjC). > > I'd go ahead and just ignore anything that isn't a string. 99.74% of > modules isn't bad. > > Not many people do the CVS thing these days, and that number is going > to get smaller and smaller since people are replacing CVS with > Subversion and others. Subversion supports keyword substitution, too. Seems reasonable to support if it's common and 1 line of code, otherwise...yeah, whatever. -- Nicholas Riley | From eichin at metacarta.com Thu May 26 20:22:35 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: 26 May 2005 14:22:35 -0400 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> <20050526150504.GA34507@uiuc.edu> Message-ID: > Not many people do the CVS thing these days, and that number is going > to get smaller and smaller since people are replacing CVS with > Subversion and others. svn propset svn:keywords 'id' filename (which is a default, I think, anyway - I don't think switching to subversion will make it *any* less common, though clearly it isn't all that common now.) The only thing to watch out for is when you parse it -- cvs id versions always have a dot in them and mention the ",v" whereas svn id versions are always an integer, and use a different date format: # $Id: FooBarBaz.py,v 1.12 2005/03/15 20:44:09 eichin Exp $ # $Id: FooBarBaz.py 24324 2005-05-13 21:10:53Z eichin $ As long as you're moderately generous in the pattern match, it's likely to work with both (the cvs version can contain multiple dots, as well.) From hengist.podd at virgin.net Thu May 26 20:56:41 2005 From: hengist.podd at virgin.net (has) Date: Thu, 26 May 2005 19:56:41 +0100 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: <20050526133900.GB30530@uiuc.edu> References: <20050526133900.GB30530@uiuc.edu> Message-ID: Nicholas Riley wrote: > > Obviously the extension needs to be built on Tiger to provide sdef >> support, but what should I do to ensure that, say, applications >> containing that binary extension will still work OK when run on > > earlier OSes? > >You can use weak linking if you don't need to support 10.1.x or >earlier, Ah, thanks. nm says OSACopyScriptingDefinition is weak, so I've added the appropriate 'OSACopyScriptingDefinition != NULL' check to OSATerminology.c and recompiled it for Tiger's Apple-installed Python. No problems using it there there, of course, but I do get the following (unrelated) error when trying to import it into user-installed Python 2.3.5 on 10.2.8 (I don't have a copy of Panther so dunno if it works on that): ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python can't open library: /usr/lib/libmx.A.dylib (No such file or directory, errno = 2) Any ideas? (Source and binary are at if it's any help.) Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From gandreas at gandreas.com Thu May 26 21:04:00 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Thu, 26 May 2005 14:04:00 -0500 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> Message-ID: On May 26, 2005, at 1:56 PM, has wrote: > Nicholas Riley wrote: > > >>> Obviously the extension needs to be built on Tiger to provide sdef >>> support, but what should I do to ensure that, say, applications >>> containing that binary extension will still work OK when run on >>> earlier OSes? >>> >> >> You can use weak linking if you don't need to support 10.1.x or >> earlier, >> > > Ah, thanks. nm says OSACopyScriptingDefinition is weak, so I've > added the appropriate 'OSACopyScriptingDefinition != NULL' check to > OSATerminology.c and recompiled it for Tiger's Apple-installed > Python. No problems using it there there, of course, but I do get > the following (unrelated) error when trying to import it into user- > installed Python 2.3.5 on 10.2.8 (I don't have a copy of Panther so > dunno if it works on that): > > ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: > dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/MacOS/Python can't open library: /usr/lib/ > libmx.A.dylib (No such file or directory, errno = 2) gcc 4.0 automatically adds a reference to /usr/lib/libmx.A.dylib for all C++ code (and to make it more annoying, in more than a few cases, it doesn't actually directly reference anything in it - you'd think the linker would skip adding the link record). Switching to gcc 3.3 will make this problem go away. Glenn Andreas gandreas at gandreas.com wicked fun! Widgetarium | the quickest path to widgets From kenneth.m.mcdonald at gmail.com Thu May 26 22:16:11 2005 From: kenneth.m.mcdonald at gmail.com (Kenneth McDonald) Date: Thu, 26 May 2005 15:16:11 -0500 Subject: [Pythonmac-SIG] PYTHONHOME on OS X Message-ID: According to my (slightly dated) Python In a Nutshell book, I can specify python search paths by putting them in a .python.pth file in the PYTHONHOME directory. However, my environment doesn't have a PYTHONHOM variable. Do I need to define it explicitly, or is there another location I can put the path file that will be automatically searched for it. Thanks, Ken From bob at redivi.com Thu May 26 22:42:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 13:42:37 -0700 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> Message-ID: On May 26, 2005, at 11:56 AM, has wrote: > Nicholas Riley wrote: > > >>> Obviously the extension needs to be built on Tiger to provide sdef >>> support, but what should I do to ensure that, say, applications >>> containing that binary extension will still work OK when run on >>> earlier OSes? >>> >> >> You can use weak linking if you don't need to support 10.1.x or >> earlier, >> > > Ah, thanks. nm says OSACopyScriptingDefinition is weak, so I've > added the appropriate 'OSACopyScriptingDefinition != NULL' check to > OSATerminology.c and recompiled it for Tiger's Apple-installed > Python. No problems using it there there, of course, but I do get > the following (unrelated) error when trying to import it into user- > installed Python 2.3.5 on 10.2.8 (I don't have a copy of Panther so > dunno if it works on that): > > ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: > dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/ > Python.app/Contents/MacOS/Python can't open library: /usr/lib/ > libmx.A.dylib (No such file or directory, errno = 2) > > Any ideas? (Source and binary are at hamish.sanderson/osat.dmg.gz> if it's any help.) Well that error is solvable, but Tiger's python links extensions with a linker flag that Jaguar does not understand -- so, it's time to give up. It's possible to compile on 10.2.8 and make it work on 10.4, but you're opening the door to an interpreter mismatch because it's (a) linking directly to Python and (b) linking directly to the WRONG python.. it will work, by accident, unless the user has a user- installed Python 2.3, in which case it will explode. It's possible but very difficult to use a user-installed Python 2.3.5 on Tiger and compile an extension that will work on Jaguar.. I don't have the time to explain the gory details and I don't want to support doing that. In other words, compile everything on the least common denominator, period. Provide separate binaries for 10.2 and 10.3+ (if you still care about 10.2, which you probably shouldn't). -bob From bob at redivi.com Thu May 26 22:43:29 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 13:43:29 -0700 Subject: [Pythonmac-SIG] PYTHONHOME on OS X In-Reply-To: References: Message-ID: <468090E4-ECEF-469C-BC28-63D03A2BF502@redivi.com> On May 26, 2005, at 1:16 PM, Kenneth McDonald wrote: > According to my (slightly dated) Python In a Nutshell book, I can > specify python search paths by putting them in a .python.pth file in > the PYTHONHOME directory. However, my environment doesn't have a > PYTHONHOM variable. Do I need to define it explicitly, or is there > another location I can put the path file that will be automatically > searched for it. -bob From hengist.podd at virgin.net Thu May 26 23:11:31 2005 From: hengist.podd at virgin.net (has) Date: Thu, 26 May 2005 22:11:31 +0100 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> Message-ID: Glenn Andreas wrote: >>ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python can't open library: /usr/lib/libmx.A.dylib (No such file or directory, errno = 2) > >[...] Switching to gcc 3.3 will make this problem go away. Cool, ta. Next dumb question: how do I tell Distutils (Python 2.4.1 on OS 10.4.1) to use gcc 3.3 instead of 4.0? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu May 26 23:17:10 2005 From: hengist.podd at virgin.net (has) Date: Thu, 26 May 2005 22:17:10 +0100 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> Message-ID: Bob wrote: >>ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python can't open library: /usr/lib/libmx.A.dylib (No such file or directory, errno = 2) >> >>Any ideas? (Source and binary are at if it's any help.) > >Well that error is solvable, but Tiger's python links extensions with a linker flag that Jaguar does not understand -- so, it's time to give up. Not a big problem; don't supply Jaguar binaries as it is. More interested in Panther/Tiger portability. (I don't have a copy of Panther to test on myself.) Will extensions built on 10.4 work on 10.3, or will I have to create separate OS-specific binaries for those as well? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu May 26 23:32:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 14:32:12 -0700 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> Message-ID: <3A249795-295A-4B07-A522-6F4F9D4C1B08@redivi.com> On May 26, 2005, at 2:11 PM, has wrote: > Glenn Andreas wrote: > > >>> ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: >>> dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/ >>> Python.app/Contents/MacOS/Python can't open library: /usr/lib/ >>> libmx.A.dylib (No such file or directory, errno = 2) >>> >> >> [...] Switching to gcc 3.3 will make this problem go away. >> > > Cool, ta. Next dumb question: how do I tell Distutils (Python > 2.4.1 on OS 10.4.1) to use gcc 3.3 instead of 4.0? gcc_switch, like I said. Python doesn't tie itself to some specific version of gcc. -bob From bob at redivi.com Thu May 26 23:34:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 14:34:48 -0700 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> Message-ID: <8182BD01-7963-4477-B384-4D06C14F4478@redivi.com> On May 26, 2005, at 2:17 PM, has wrote: > Bob wrote: > > >>> ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: >>> dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/ >>> Python.app/Contents/MacOS/Python can't open library: /usr/lib/ >>> libmx.A.dylib (No such file or directory, errno = 2) >>> >>> Any ideas? (Source and binary are at >> hamish.sanderson/osat.dmg.gz> if it's any help.) >>> >> >> Well that error is solvable, but Tiger's python links extensions >> with a linker flag that Jaguar does not understand -- so, it's >> time to give up. >> > > Not a big problem; don't supply Jaguar binaries as it is. More > interested in Panther/Tiger portability. (I don't have a copy of > Panther to test on myself.) Will extensions built on 10.4 work on > 10.3, or will I have to create separate OS-specific binaries for > those as well? Maybe, it depends. You really should be building packages on the least common denominator, you have to test there anyway. It's hard to do right, Xcode is the only environment that can properly manage SDKs and such, Apple didn't really put that functionality anywhere else, and autoconf REALLY gets in the way (i.e. ./configure). -bob From lee_cullens at mac.com Fri May 27 01:57:02 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu, 26 May 2005 19:57:02 -0400 Subject: [Pythonmac-SIG] PYTHONHOME on OS X In-Reply-To: References: Message-ID: <46A73AB1-F5A8-4659-B162-935C59CE41CC@mac.com> Bob's URL didn't work for me, but I think he meant: http://bob.pythonmac.org/archives/2005/02/06/ On May 26, 2005, at 4:16 PM, Kenneth McDonald wrote: > According to my (slightly dated) Python In a Nutshell book, I can > specify python search paths by putting them in a .python.pth file in > the PYTHONHOME directory. However, my environment doesn't have a > PYTHONHOM variable. Do I need to define it explicitly, or is there > another location I can put the path file that will be automatically > searched for it. > > Thanks, > Ken > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From lee_cullens at mac.com Fri May 27 02:08:03 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu, 26 May 2005 20:08:03 -0400 Subject: [Pythonmac-SIG] PYTHONHOME on OS X In-Reply-To: <46A73AB1-F5A8-4659-B162-935C59CE41CC@mac.com> References: <46A73AB1-F5A8-4659-B162-935C59CE41CC@mac.com> Message-ID: <1AE77CFB-772B-4C0D-BA7D-86720CEF485A@mac.com> Also, for my own projects I place *.pth files in ~/Library/Python/2.4/ site-packages/ (after I woke up with a little help ;') Where they would be placed otherwise, I'll leave to the experts to answer. On May 26, 2005, at 7:57 PM, Lee Cullens wrote: > Bob's URL didn't work for me, but I think he meant: > http://bob.pythonmac.org/archives/2005/02/06/ > > > > > > On May 26, 2005, at 4:16 PM, Kenneth McDonald wrote: > > >> According to my (slightly dated) Python In a Nutshell book, I can >> specify python search paths by putting them in a .python.pth file in >> the PYTHONHOME directory. However, my environment doesn't have a >> PYTHONHOM variable. Do I need to define it explicitly, or is there >> another location I can put the path file that will be automatically >> searched for it. >> >> Thanks, >> Ken >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Fri May 27 02:11:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 May 2005 17:11:31 -0700 Subject: [Pythonmac-SIG] PYTHONHOME on OS X In-Reply-To: <46A73AB1-F5A8-4659-B162-935C59CE41CC@mac.com> References: <46A73AB1-F5A8-4659-B162-935C59CE41CC@mac.com> Message-ID: No, the URL was what I meant, but Mail.app has a tendency to inject extra spaces (show up as %20) into long URLs. Another client may be less stupid about it. -bob On May 26, 2005, at 4:57 PM, Lee Cullens wrote: > Bob's URL didn't work for me, but I think he meant: > http://bob.pythonmac.org/archives/2005/02/06/ > > > > > > On May 26, 2005, at 4:16 PM, Kenneth McDonald wrote: > > >> According to my (slightly dated) Python In a Nutshell book, I can >> specify python search paths by putting them in a .python.pth file in >> the PYTHONHOME directory. However, my environment doesn't have a >> PYTHONHOM variable. Do I need to define it explicitly, or is there >> another location I can put the path file that will be automatically >> searched for it. >> >> Thanks, >> Ken >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From lee_cullens at mac.com Fri May 27 02:25:39 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu, 26 May 2005 20:25:39 -0400 Subject: [Pythonmac-SIG] PYTHONHOME on OS X In-Reply-To: References: <46A73AB1-F5A8-4659-B162-935C59CE41CC@mac.com> Message-ID: <42F3A92B-5373-4365-AAC5-1411C0908735@mac.com> Yep, right at the line break - sorry I didn't notice that (so I guess you could say the client and user in this case :~) Like others, I've been using tinyURLs on another list that has excessively long message URL references, but as you and others have pointed out they have longevity (?) issues. On May 26, 2005, at 8:11 PM, Bob Ippolito wrote: > No, the URL was what I meant, but Mail.app has a tendency to inject > extra spaces (show up as %20) into long URLs. Another client may > be less stupid about it. > > -bob > > On May 26, 2005, at 4:57 PM, Lee Cullens wrote: > > >> Bob's URL didn't work for me, but I think he meant: >> http://bob.pythonmac.org/archives/2005/02/06/ >> >> >> >> >> >> On May 26, 2005, at 4:16 PM, Kenneth McDonald wrote: >> >> >> >>> According to my (slightly dated) Python In a Nutshell book, I can >>> specify python search paths by putting them in a .python.pth file in >>> the PYTHONHOME directory. However, my environment doesn't have a >>> PYTHONHOM variable. Do I need to define it explicitly, or is there >>> another location I can put the path file that will be automatically >>> searched for it. >>> >>> Thanks, >>> Ken >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> >>> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > > From ronaldoussoren at mac.com Fri May 27 07:39:53 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 27 May 2005 07:39:53 +0200 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> Message-ID: <0B19137F-59B3-4BE5-9B53-24E5707007B3@mac.com> On 26-mei-2005, at 16:54, Jonathan Wight wrote: > After adding Gideon's suggestion for CRLF ending file. My importer is > failing on only 8 files out of 3084 files. > > All the failures are with Python files that try to generate the > __version__ attribute with code instead, e.g.: > > __version__ = string.split('$Revision: 1.8 $')[1] > __version__ = '$Revision: 1.6 $'[11:-2] > > And so on. > > My options are: > > #1 Continue to fail and not process the script any further (easiest > solution ;-) > #2 Just ignore the attribute in question. > #3 Convert the attribute into a string even though it might not make > much sense. > #4 Execute the line and get the computed value of the attribute. > > I don't really want to execute the line - who the heck knows what it > could do. Unless anyone has any better ideas I'm just going to try > and gracefully ignore the attribute. You could try to recognize some forms of safe python code and execute those. I'd expect that the lines you mention above would be the majority of computed __version__ attributes. > > Jon. > > > On May 26, 2005, at 09:37, Nicholas Riley wrote: > > > >> On Thu, May 26, 2005 at 12:13:02AM -0400, Jonathan Wight wrote: >> >> >> >>> Just to let everyone know that my Python Metadata Importer plug-in >>> was released the other day. >>> >>> http://toxicsoftware.com/blog/index.php/weblog/ >>> python_metadata_importer_101_released/ >>> >>> >>> >> >> Since I installed this I got a continuous stream of: >> >> May 26 08:32:27 byron mdimportserver[29832]: Exception occured: *** >> -[NSCFArray addObject:]: attempt to insert nil >> >> in console.log. I assume this will go away once the import finishes, >> but it's rather annoying at the moment. >> >> -- >> Nicholas Riley | > njriley> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at 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: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050527/bdaa76a0/smime.bin From jwight_lists at toxicsoftware.com Fri May 27 07:44:51 2005 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Fri, 27 May 2005 01:44:51 -0400 Subject: [Pythonmac-SIG] Python Metadata Importer In-Reply-To: <0B19137F-59B3-4BE5-9B53-24E5707007B3@mac.com> References: <084C934F-8407-40AA-8E5A-DAACE30CDA89@toxicsoftware.com> <20050526133700.GA30530@uiuc.edu> <90B7E9F3-EA99-4B0C-A44C-3C2F0BE75645@toxicsoftware.com> <0B19137F-59B3-4BE5-9B53-24E5707007B3@mac.com> Message-ID: On May 27, 2005, at 01:39, Ronald Oussoren wrote: > On 26-mei-2005, at 16:54, Jonathan Wight wrote: > >> After adding Gideon's suggestion for CRLF ending file. My importer is >> failing on only 8 files out of 3084 files. >> >> All the failures are with Python files that try to generate the >> __version__ attribute with code instead, e.g.: >> >> __version__ = string.split('$Revision: 1.8 $')[1] >> __version__ = '$Revision: 1.6 $'[11:-2] >> >> And so on. >> >> My options are: >> >> #1 Continue to fail and not process the script any further (easiest >> solution ;-) >> #2 Just ignore the attribute in question. >> #3 Convert the attribute into a string even though it might not make >> much sense. >> #4 Execute the line and get the computed value of the attribute. >> >> I don't really want to execute the line - who the heck knows what it >> could do. Unless anyone has any better ideas I'm just going to try >> and gracefully ignore the attribute. >> > > You could try to recognize some forms of safe python code and > execute those. > I'd expect that the lines you mention above would be the majority of > computed __version__ attributes. There's another __version__ format that seems semi-common too (well 3 instances out of 3000 or so files ;-); a tuple of two or three integers: __version__ = (1, 0, 0) There's also an __date__ that someone decided to do some slicing on as well. Right now - I'm just going to silently ignore any non-string metadata. I don't think anyone is going is to lose sleep over the lost metadata ;-) Thanks for the input though. Jon. From mario at ruggier.org Fri May 27 11:11:40 2005 From: mario at ruggier.org (Mario Ruggier) Date: Fri, 27 May 2005 11:11:40 +0200 Subject: [Pythonmac-SIG] @reboot Message-ID: <5677c905bbabbad9d776313c5aa180bd@ruggier.org> Hi, [ apologies about this not really being directly related to python mac... ] I am trying ro use an @reboot cron job to start an svn server (used for python development ;) with each restart (of a Panther G5 powermac). I have edited the file /etc/crontab, adding the line: @reboot svnserve -d -r /var/svn but, after restart, there is no svn server daemon running: $ ps -aux | grep svn xxxxx 449 0.0 0.0 18172 336 std S+ 11:03AM 0:00.01 grep svn $ Cannot tell where the problem is... The system.log contains the following potentially relevant lines: May 27 10:47:15 localhost SystemStarter: Initializing network May 27 10:47:15 localhost cron[176]: (*system*) PARSE (bad username) Any ideas? Thanks, mario From hengist.podd at virgin.net Fri May 27 13:29:09 2005 From: hengist.podd at virgin.net (has) Date: Fri, 27 May 2005 12:29:09 +0100 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: <8182BD01-7963-4477-B384-4D06C14F4478@redivi.com> References: <20050526133900.GB30530@uiuc.edu> <8182BD01-7963-4477-B384-4D06C14F4478@redivi.com> Message-ID: Bob wrote: >>Will extensions built on 10.4 work on 10.3, or will I have to create separate OS-specific binaries for those as well? > >Maybe, it depends. > >You really should be building packages on the least common denominator, you have to test there anyway. It's hard to do right, Xcode is the only environment that can properly manage SDKs and such, Apple didn't really put that functionality anywhere else, and autoconf REALLY gets in the way (i.e. ./configure). Not a problem for other modules where the APIs are the same over multiple OSes. (I've had no problems so far using .so binaries built on Jaguar under Tiger, for example.) Given that OSATerminology needs to use Tiger's weak-lined OSACopyScriptingDefinition function when running under Tiger, is it possible/practical to build it on Panther? It sounds like the easiest thing would be to put the Tiger-only code in a separate file and build that on Tiger, and build the remainder on an older OS as before; then have osaterminology import or ignore the Tiger-only extension at runtime as appropriate. Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From daniel.hartmanstorfer at gmail.com Fri May 27 15:11:46 2005 From: daniel.hartmanstorfer at gmail.com (Daniel S. Hartmanstorfer II) Date: Fri, 27 May 2005 08:11:46 -0500 Subject: [Pythonmac-SIG] PYTHONPATH Message-ID: How do I set my PYTHONPATH in OS X? I am using python2.4 installed via Darwinports in /opt/local/bin/python. Thanks. Daniel S. Hartmanstorfer II "Opportunity is missed by most because it is dressed in overalls and looks like work." -Thomas Edison From kquirk at solidworks.com Fri May 27 15:31:38 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Fri, 27 May 2005 09:31:38 -0400 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work Message-ID: I can't find where you said that extensions shouldn't be linking to Python at all. I also can't understand how this could be the case, at least if we're building the extensions using Boost.Python (which we are). I've tried to build without linking to it, and it compiles but I end up with a bunch of missing symbols from Python. When we started this whole project about a year and a half ago, distutils basically didn't work. We now have several extensions and over 100K lines of complex C++ code distributed in several hundred files in a cross-platform application. We had a difficult enough time getting XCode to handle it. After staring at what passes for distutils documentation for a while, I can't even figure out if it will handle a Boost.Python extension, and trying to get it to do our complete build seems like great way to waste several days. We finally did it manually. After the call to setup(), our setup.py iterates over the constructed modules in the built .app using macholib to find all the occurrences of /Libraries/Frameworks/Python.framework etc and convert them to @executable_path/../Frameworks. What I had hoped for was some hint along the lines of "here's how you can convince py2app to do that for you automatically." OS X documentation is generally of the class that you only know what you need to know after you've already found it (and tried a zillion wrong answers). It's really pretty horrible to figure this stuff out for the first time. We'd like to do things "right", but The One True Way is a hard path to find and follow. Maybe after you've already trod it, you can look back and say "that was obvious", but it sure isn't obvious when you're working your way along it for the first time. Kent -----Original Message----- From: Bob Ippolito [mailto:bob at redivi.com] Sent: Thursday, May 26, 2005 1:48 PM To: Kent Quirk Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work As I said before, your extensions shouldn't be linking to Python *at all*. Read that part again, and fix the way your extensions are getting linked. (and this is why people should use distutils to link their extensions, because it knows how to link things right) -bob From ronaldoussoren at mac.com Fri May 27 16:01:55 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 27 May 2005 16:01:55 +0200 Subject: [Pythonmac-SIG] PYTHONPATH In-Reply-To: References: Message-ID: <11012149.1117202515691.JavaMail.ronaldoussoren@mac.com> On Friday, May 27, 2005, at 03:12PM, Daniel S. Hartmanstorfer II wrote: >How do I set my PYTHONPATH in OS X? I am using python2.4 installed >via Darwinports in /opt/local/bin/python. Thanks. Why do you want to do that? It's often (if not almost always) better to use a pth-file in site-packages. PYTHONPATH can be useful during development (easily switching between various versions of a library), but not in a production environment. Ronald > >Daniel S. Hartmanstorfer II >"Opportunity is missed by most because it is dressed in overalls and >looks like work." > -Thomas Edison > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From ronaldoussoren at mac.com Fri May 27 16:09:53 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 27 May 2005 16:09:53 +0200 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work In-Reply-To: References: Message-ID: <37470.1117202993630.JavaMail.ronaldoussoren@mac.com> On Friday, May 27, 2005, at 03:33PM, Kent Quirk wrote: >I can't find where you said that extensions shouldn't be linking to >Python at all. I also can't understand how this could be the case, at >least if we're building the extensions using Boost.Python (which we >are). The quick summary: if you link against python you're extension will work with just the variant of python that you linked against. If you do not link against python (as distutils does with current version of python) you can use extensions with multiple variants of python (/Library/Frameworks/Python.framework, /System/Library/Frameworks/Python.framework,/opt/local/bin/python, ...) as long as they have the same major relase. This is very important on Panther because /System/Library/Python.framework and /Library/Python.framework (2.3.0 vs. 2.3.5) share the same site-packages directory. This is explained somewhere on the pythonmac mailinglist. Look for 'Why do I need PantherPythonFix'. Ronald From jim at ibang.com Fri May 27 16:25:27 2005 From: jim at ibang.com (Jim Allman) Date: Fri, 27 May 2005 10:25:27 -0400 Subject: [Pythonmac-SIG] @reboot In-Reply-To: <5677c905bbabbad9d776313c5aa180bd@ruggier.org> References: <5677c905bbabbad9d776313c5aa180bd@ruggier.org> Message-ID: On May 27, 2005, at 5:11 AM, Mario Ruggier wrote: > Cannot tell where the problem is... The system.log contains the > following potentially relevant lines: > May 27 10:47:15 localhost SystemStarter: Initializing network > May 27 10:47:15 localhost cron[176]: (*system*) PARSE (bad username) > > Any ideas? Mario, I believe that cron runs as a different effective user (root?), even for tasks in your personal crontab. Also, it doesn't have quite the same environment vars that you'd normally have in the shell. I've had trouble calling Growl (OS X notification) popups from cron for this reason. You might try writing an executable shell script to launch svn, then putting it in the /Library/StartupItems. Yeah, it looks like someone's already doing this: http://svn.haxx.se/users/archive-2004-05/1140.shtml Good luck! =jimA= . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jim Allman Interrobang Digital Media http://www.ibang.com/ (919) 649-5760 From bob at redivi.com Fri May 27 18:19:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 09:19:22 -0700 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> <8182BD01-7963-4477-B384-4D06C14F4478@redivi.com> Message-ID: On May 27, 2005, at 4:29 AM, has wrote: > Bob wrote: > > >>> Will extensions built on 10.4 work on 10.3, or will I have to >>> create separate OS-specific binaries for those as well? >>> >> >> Maybe, it depends. >> >> You really should be building packages on the least common >> denominator, you have to test there anyway. It's hard to do >> right, Xcode is the only environment that can properly manage SDKs >> and such, Apple didn't really put that functionality anywhere >> else, and autoconf REALLY gets in the way (i.e. ./configure). >> > > Not a problem for other modules where the APIs are the same over > multiple OSes. (I've had no problems so far using .so binaries > built on Jaguar under Tiger, for example.) > > Given that OSATerminology needs to use Tiger's weak-lined > OSACopyScriptingDefinition function when running under Tiger, is it > possible/practical to build it on Panther? It sounds like the > easiest thing would be to put the Tiger-only code in a separate > file and build that on Tiger, and build the remainder on an older > OS as before; then have osaterminology import or ignore the Tiger- > only extension at runtime as appropriate. Yeah, the "easiest" thing is basically to do that, or to build an entirely separate version for users with Tiger. -bob From bob at redivi.com Fri May 27 18:27:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 09:27:49 -0700 Subject: [Pythonmac-SIG] Upgraded to 2.4 and can't make it work In-Reply-To: References: Message-ID: On May 27, 2005, at 6:31 AM, Kent Quirk wrote: > I can't find where you said that extensions shouldn't be linking to > Python at all. I also can't understand how this could be the case, at > least if we're building the extensions using Boost.Python (which we > are). When I said it shouldn't be linking to Python, I also said what linker flags should be used: -undefined dynamic_lookup > I've tried to build without linking to it, and it compiles but I > end up > with a bunch of missing symbols from Python. > > When we started this whole project about a year and a half ago, > distutils basically didn't work. We now have several extensions and > over > 100K lines of complex C++ code distributed in several hundred files > in a > cross-platform application. We had a difficult enough time getting > XCode > to handle it. After staring at what passes for distutils documentation > for a while, I can't even figure out if it will handle a Boost.Python > extension, and trying to get it to do our complete build seems like > great way to waste several days. > > We finally did it manually. After the call to setup(), our setup.py > iterates over the constructed modules in the built .app using macholib > to find all the occurrences of /Libraries/Frameworks/Python.framework > etc and convert them to @executable_path/../Frameworks. > > What I had hoped for was some hint along the lines of "here's how you > can convince py2app to do that for you automatically." It should do it automatically, but you shouldn't have those references in the first place. So, there is a problem somewhere, but the obvious solution to that particular problem is to link the extensions correctly. > OS X documentation is generally of the class that you only know > what you > need to know after you've already found it (and tried a zillion wrong > answers). It's really pretty horrible to figure this stuff out for the > first time. Which is why I always recommend to stick to a path where disutils and py2app do all the work... -bob From hengist.podd at virgin.net Fri May 27 18:40:05 2005 From: hengist.podd at virgin.net (has) Date: Fri, 27 May 2005 17:40:05 +0100 Subject: [Pythonmac-SIG] making a C extension compatible across OS versions? In-Reply-To: References: <20050526133900.GB30530@uiuc.edu> <8182BD01-7963-4477-B384-4D06C14F4478@redivi.com> Message-ID: Bob wrote: >> It sounds like the easiest thing would be to put the Tiger-only code in a separate file and build that on Tiger, and build the remainder on an older OS as before; then have osaterminology import or ignore the Tiger-only extension at runtime as appropriate. > >Yeah, the "easiest" thing is basically to do that, or to build an entirely separate version for users with Tiger. Will do. Much thanks for your patient advice. has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Fri May 27 21:26:25 2005 From: hengist.podd at virgin.net (has) Date: Fri, 27 May 2005 20:26:25 +0100 Subject: [Pythonmac-SIG] best way to get os version? Message-ID: Hi all, Apropos to last thread, what's the best way to check Mac OS version from Python at runtime? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri May 27 22:09:17 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 13:09:17 -0700 Subject: [Pythonmac-SIG] best way to get os version? In-Reply-To: References: Message-ID: <352C156D-01D7-4633-918F-2D88B51F8D4B@redivi.com> On May 27, 2005, at 12:26 PM, has wrote: > Apropos to last thread, what's the best way to check Mac OS version > from Python at runtime? platform.mac_ver() is probably the easiest way, but there was a bug in Python 2.3.0 that prevents it from working there (i.e. Apple Python on Mac OS X 10.3) The other way with stock Python is to use gestalt.gestalt('sysv') directly, which returns the version in BCD. See also: -bob From janssen at parc.com Fri May 27 22:57:11 2005 From: janssen at parc.com (Bill Janssen) Date: Fri, 27 May 2005 13:57:11 PDT Subject: [Pythonmac-SIG] best way to get os version? In-Reply-To: Your message of "Fri, 27 May 2005 13:09:17 PDT." <352C156D-01D7-4633-918F-2D88B51F8D4B@redivi.com> Message-ID: <05May27.135717pdt."58617"@synergy1.parc.xerox.com> > platform.mac_ver() is probably the easiest way, but there was a bug > in Python 2.3.0 that prevents it from working there (i.e. Apple > Python on Mac OS X 10.3) That seems to make it essentially useless. Why tell us about it? Bill From bob at redivi.com Fri May 27 23:21:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 14:21:23 -0700 Subject: [Pythonmac-SIG] best way to get os version? In-Reply-To: <05May27.135717pdt."58617"@synergy1.parc.xerox.com> References: <05May27.135717pdt."58617"@synergy1.parc.xerox.com> Message-ID: <33E18F54-45D2-4CED-9463-FC9F61033761@redivi.com> On May 27, 2005, at 1:57 PM, Bill Janssen wrote: >> platform.mac_ver() is probably the easiest way, but there was a bug >> in Python 2.3.0 that prevents it from working there (i.e. Apple >> Python on Mac OS X 10.3) >> > > That seems to make it essentially useless. Why tell us about it? Yet another reason why Python 2.3.0 sucks? If you're not using Python 2.3.0, it's not useless. -bob From jacob at jacobian.org Fri May 27 23:24:52 2005 From: jacob at jacobian.org (Jacob Kaplan-Moss) Date: Fri, 27 May 2005 16:24:52 -0500 Subject: [Pythonmac-SIG] SetSystemUIMode in python? Message-ID: Howdy -- I'm working on a kiosk app, and I'd like to use SetSystemUIMode and friends (defined in MacApplication.h inside HIToolbox.framework). As far as I can tell, the HIToolbox framework isn't exposed in MacPython anywhere, but I might be missing something. Before I start figuring out how to wrap these functions myself, am I right in thinking there's currently no way to get at them from MacPython? Also, if I do end up needing to write an extension to get at them, can anyone suggest the best way to go about this? Specifically, is Pyrex a good tool to use for wrapping Carbon APIs like this? I've not written an extension since I became aware of Pyrex... Thanks, Jacob From bob at redivi.com Fri May 27 23:51:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 14:51:00 -0700 Subject: [Pythonmac-SIG] SetSystemUIMode in python? In-Reply-To: References: Message-ID: <14E2A6C5-7293-4277-95F7-CF1F85211986@redivi.com> On May 27, 2005, at 2:24 PM, Jacob Kaplan-Moss wrote: > I'm working on a kiosk app, and I'd like to use SetSystemUIMode and > friends (defined in MacApplication.h inside HIToolbox.framework). As > far as I can tell, the HIToolbox framework isn't exposed in MacPython > anywhere, but I might be missing something. > > Before I start figuring out how to wrap these functions myself, am I > right in thinking there's currently no way to get at them from > MacPython? With MacPython as-is, there is no way that I'm aware of... but that doesn't mean you should write an extension. > Also, if I do end up needing to write an extension to get at them, > can anyone suggest the best way to go about this? Specifically, is > Pyrex a good tool to use for wrapping Carbon APIs like this? I've not > written an extension since I became aware of Pyrex... While Pyrex is a pretty reasonable way to write extensions, PyObjC or ctypes is generally less painful when wrapping a small number of functions. # cut + paste comments kUIModeNormal = 0 kUIModeContentSuppressed = 1 kUIModeContentHidden = 2 kUIModeAllSuppressed = 4 kUIModeAllHidden = 3 kUIOptionAutoShowMenuBar = 1 << 0 kUIOptionDisableAppleMenu = 1 << 2 kUIOptionDisableProcessSwitch = 1 << 3 kUIOptionDisableForceQuit = 1 << 4 kUIOptionDisableSessionTerminate = 1 << 5 kUIOptionDisableHide = 1 << 6 # wrapped function import objc from Foundation import NSBundle bundle = NSBundle.bundleWithPath_('/System/Library/Frameworks/ Carbon.framework') objc.loadBundleFunctions(bundle, globals(), ( ('SetSystemUIMode', 'III', " Sets the presentation mode for system-provided user interface elements."), )) It does work: -bob From delza at livingcode.org Sat May 28 00:01:57 2005 From: delza at livingcode.org (Dethe Elza) Date: Fri, 27 May 2005 15:01:57 -0700 Subject: [Pythonmac-SIG] SetSystemUIMode in python? In-Reply-To: <14E2A6C5-7293-4277-95F7-CF1F85211986@redivi.com> References: <14E2A6C5-7293-4277-95F7-CF1F85211986@redivi.com> Message-ID: <484F6F0C-0978-451F-9532-27D044FB0773@livingcode.org> > While Pyrex is a pretty reasonable way to write extensions, PyObjC or > ctypes is generally less painful when wrapping a small number of > functions. This is very interesting. I thought the basic choices for wrapping C functions were: * Pyrex * ctypes * Write Obj-C and import with PyObjC I hadn't realized that you could import functions with PyObjC and no (additional) intervening Obj-C code. Very very cool. --Dethe From bob at redivi.com Sat May 28 01:05:47 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 16:05:47 -0700 Subject: [Pythonmac-SIG] SetSystemUIMode in python? In-Reply-To: <484F6F0C-0978-451F-9532-27D044FB0773@livingcode.org> References: <14E2A6C5-7293-4277-95F7-CF1F85211986@redivi.com> <484F6F0C-0978-451F-9532-27D044FB0773@livingcode.org> Message-ID: On May 27, 2005, at 3:01 PM, Dethe Elza wrote: >> While Pyrex is a pretty reasonable way to write extensions, PyObjC or >> ctypes is generally less painful when wrapping a small number of >> functions. >> > > This is very interesting. I thought the basic choices for wrapping C > functions were: > > * Pyrex > * ctypes > * Write Obj-C and import with PyObjC * SWIG (ughh) * Write C++ and use Boost.Python (ugh) * Python C API directly (not really *that* bad) ... > I hadn't realized that you could import functions with PyObjC and no > (additional) intervening Obj-C code. Very very cool. This functionality has been there since 1.2 (2004-12-29). -bob From delza at livingcode.org Sat May 28 01:18:53 2005 From: delza at livingcode.org (Dethe Elza) Date: Fri, 27 May 2005 16:18:53 -0700 Subject: [Pythonmac-SIG] SetSystemUIMode in python? In-Reply-To: References: <14E2A6C5-7293-4277-95F7-CF1F85211986@redivi.com> <484F6F0C-0978-451F-9532-27D044FB0773@livingcode.org> Message-ID: On 27-May-05, at 4:05 PM, Bob Ippolito wrote: >> * Pyrex >> * ctypes >> * Write Obj-C and import with PyObjC >> > > * SWIG (ughh) > * Write C++ and use Boost.Python (ugh) > * Python C API directly (not really *that* bad) Yeah, I know, I was only listing methods that I'd actually consider *using.* And just using PyObjC instead still totally blows them all away. >> I hadn't realized that you could import functions with PyObjC and no >> (additional) intervening Obj-C code. Very very cool. >> > > This functionality has been there since 1.2 (2004-12-29). Yes, I realize I'm late to the party, just discovering this now. It's cool enough to be given more air-time, IMHO. --Dethe From bob at redivi.com Sat May 28 01:22:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 16:22:49 -0700 Subject: [Pythonmac-SIG] SetSystemUIMode in python? In-Reply-To: References: <14E2A6C5-7293-4277-95F7-CF1F85211986@redivi.com> <484F6F0C-0978-451F-9532-27D044FB0773@livingcode.org> Message-ID: <22A2F98E-1680-46CD-8496-15D79C343991@redivi.com> On May 27, 2005, at 4:18 PM, Dethe Elza wrote: > On 27-May-05, at 4:05 PM, Bob Ippolito wrote: > >>> I hadn't realized that you could import functions with PyObjC and no >>> (additional) intervening Obj-C code. Very very cool. >> >> This functionality has been there since 1.2 (2004-12-29). > > Yes, I realize I'm late to the party, just discovering this now. > It's cool enough to be given more air-time, IMHO. It's sort of black magic, and it's not very convenient unless you really know what you're doing (type signatures, etc.). It's also not as complete as ctypes is with regard to pointers to things (i.e. variable length arrays), because PyObjC doesn't offer that abstraction yet. When the new scanner stuff is prime time, it'll get some air-time (indirectly). That said, for simple functions with simple arguments and return values, it's great if you understand the Objective-C type signatures involved :) -bob From nickgsuperstar at gmail.com Sat May 28 03:32:29 2005 From: nickgsuperstar at gmail.com (nickg) Date: Fri, 27 May 2005 21:32:29 -0400 Subject: [Pythonmac-SIG] Apple's python extensions into Quartz2D Message-ID: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> Hi, What's the latest with Apple's python extensions to use Quartz2D? I'd like to use them with the latest python release but I can't figure out where the original source code for the extensions are so I can't do a build. It looks like they used SWIG, but that's about as much as I figured out. Or this is something I might be able to do with PyObjC (which I never have used)? Or is there another alternative? thanks, --nickg From bob at redivi.com Sat May 28 03:39:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 18:39:58 -0700 Subject: [Pythonmac-SIG] Apple's python extensions into Quartz2D In-Reply-To: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> References: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> Message-ID: <5CB8EFD6-1329-46EA-8388-44F92BED1E8B@redivi.com> On May 27, 2005, at 6:32 PM, nickg wrote: > What's the latest with Apple's python extensions to use Quartz2D? > I'd like to use them with the latest python release but I can't > figure out where the original source code for the extensions are so I > can't do a build. It looks like they used SWIG, but that's about as > much as I figured out. They're not open source. You can't use them with anything but the release of Python that ships with Mac OS X. File a bug. I filed mine over a year ago: rdar://3540071 Python CoreGraphics extension can't readily be used by other Python versions 26-Jan-2004 02:10 PM I updated it this april to say "hey, this actually matters now that 2.4.1 is out there", but I still have not received a response. I believe the reason is that the extension does some really horrible nasty SPI hacks in order to lift some of the restrictions that are normally imposed by these APIs (WindowServer connections, etc.) At least, that's what I gathered from reverse engineering it a bit. > Or this is something I might be able to do with PyObjC (which I never > have used)? Or is there another alternative? It depends on what you're trying to do. The Cocoa APIs are higher level than Quartz2D and imposes a few restrictions along the way. -bob From nickgsuperstar at gmail.com Sat May 28 04:00:08 2005 From: nickgsuperstar at gmail.com (nickg) Date: Fri, 27 May 2005 22:00:08 -0400 Subject: [Pythonmac-SIG] Apple's python extensions into Quartz2D In-Reply-To: <5CB8EFD6-1329-46EA-8388-44F92BED1E8B@redivi.com> References: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> <5CB8EFD6-1329-46EA-8388-44F92BED1E8B@redivi.com> Message-ID: thanks for the reply. Odd, the Python API is nearly 1-1 with the CoreGraphics C API so I wouldn't expect any hacks. Oh well. I'm just using it to "draw" into a PDF or buffer to save a file. No UI or Windows needed. Can PyObjC make these calls? I'm new to the all the mac-python trickery. --nickg On May 27, 2005, at 9:39 PM, Bob Ippolito wrote: > > On May 27, 2005, at 6:32 PM, nickg wrote: > > >> What's the latest with Apple's python extensions to use Quartz2D? >> I'd like to use them with the latest python release but I can't >> figure out where the original source code for the extensions are so I >> can't do a build. It looks like they used SWIG, but that's about as >> much as I figured out. >> > > They're not open source. You can't use them with anything but the > release of Python that ships with Mac OS X. File a bug. I filed > mine over a year ago: > > rdar://3540071 > Python CoreGraphics extension can't readily be used by other Python > versions > 26-Jan-2004 02:10 PM > > I updated it this april to say "hey, this actually matters now that > 2.4.1 is out there", but I still have not received a response. > > I believe the reason is that the extension does some really > horrible nasty SPI hacks in order to lift some of the restrictions > that are normally imposed by these APIs (WindowServer connections, > etc.) At least, that's what I gathered from reverse engineering it > a bit. > > >> Or this is something I might be able to do with PyObjC (which I never >> have used)? Or is there another alternative? >> > > It depends on what you're trying to do. The Cocoa APIs are higher > level than Quartz2D and imposes a few restrictions along the way. > > -bob > > From bob at redivi.com Sat May 28 04:17:40 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 19:17:40 -0700 Subject: [Pythonmac-SIG] Apple's python extensions into Quartz2D In-Reply-To: References: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> <5CB8EFD6-1329-46EA-8388-44F92BED1E8B@redivi.com> Message-ID: On May 27, 2005, at 7:00 PM, nickg wrote: > On May 27, 2005, at 9:39 PM, Bob Ippolito wrote: > > >> >> On May 27, 2005, at 6:32 PM, nickg wrote: >> >> >> >>> What's the latest with Apple's python extensions to use Quartz2D? >>> I'd like to use them with the latest python release but I can't >>> figure out where the original source code for the extensions are >>> so I >>> can't do a build. It looks like they used SWIG, but that's about as >>> much as I figured out. >> >> They're not open source. You can't use them with anything but the >> release of Python that ships with Mac OS X. File a bug. I filed >> mine over a year ago: >> >> rdar://3540071 >> Python CoreGraphics extension can't readily be used by other Python >> versions >> 26-Jan-2004 02:10 PM >> >> I updated it this april to say "hey, this actually matters now that >> 2.4.1 is out there", but I still have not received a response. >> >> I believe the reason is that the extension does some really >> horrible nasty SPI hacks in order to lift some of the restrictions >> that are normally imposed by these APIs (WindowServer connections, >> etc.) At least, that's what I gathered from reverse engineering it >> a bit. >> >> >> >>> Or this is something I might be able to do with PyObjC (which I >>> never >>> have used)? Or is there another alternative? >> >> It depends on what you're trying to do. The Cocoa APIs are higher >> level than Quartz2D and imposes a few restrictions along the way. > > Odd, the Python API is nearly 1-1 with the CoreGraphics C API so I > wouldn't expect any hacks. Oh well. Image loading and initialization are whack. It also installs several categories on AppKit classes that probably break stuff if you happen to import CoreGraphics from a GUI app. File a bug. >> I'm just using it to "draw" into a PDF or buffer to save a file. No >> UI or Windows needed. Can PyObjC make these calls? I'm new to the >> all the mac-python trickery. Again, it depends. The API is different, so for some definitions of "draw" it will work just fine, but not all of them. You can probably do something equivalent, but it's going to require a WindowServer connection (i.e. invoked by pythonw as root or by the logged-in user). File a bug. -bob From kquirk at solidworks.com Sat May 28 04:22:22 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Fri, 27 May 2005 22:22:22 -0400 Subject: [Pythonmac-SIG] SetSystemUIMode in python? Message-ID: Bob wrote: >* SWIG (ughh) >* Write C++ and use Boost.Python (ugh) >* Python C API directly (not really *that* bad) Well, I've looked at all of these, and I've gotta disagree with the Ugh on Boost.Python. At least for large projects. If (like me) you have large quantities of existing C++ to deal with, Boost.Python is actually really nice. You can build Python classes that inherit from C++ classes, you can built C++ classes that inherit from Python classes. You can write free functions, you can construct enums, and you basically use it by writing down some simple definitions. Your C++ code is idiomatic AND your Python code is idiomatic. Example: using Boost.Python, we constructed an Event (publish/subscribe) system that allows for arbitrary data to be passed as Python dictionaries. Events, queues and listeners can be constructed on either side of the fence and interoperate cleanly. You can have an arbitrary number of event queues. It's a remarkably easy and clean way to pass messages around between a collection of otherwise-disconnected components, and lets us keep static coupling to a minimum. Boost.Python isn't for everyone, but in our system it was a lifesaver. Kent From bob at redivi.com Sat May 28 04:51:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 May 2005 19:51:58 -0700 Subject: [Pythonmac-SIG] SetSystemUIMode in python? In-Reply-To: References: Message-ID: <7FC15329-D7B3-49AB-AA08-7EC224613C31@redivi.com> On May 27, 2005, at 7:22 PM, Kent Quirk wrote: > Bob wrote: > >> * SWIG (ughh) >> * Write C++ and use Boost.Python (ugh) >> * Python C API directly (not really *that* bad) >> > > Well, I've looked at all of these, and I've gotta disagree with the > Ugh > on Boost.Python. At least for large projects. If (like me) you have > large quantities of existing C++ to deal with, Boost.Python is > actually > really nice. Yes, of course, reusing existing code always wins, but in this case there is exactly 0 lines of existing C++ code. Introducing C++ and Boost.Python to the equation sounds quite masochistic to me. I'm not saying Boost.Python sucks, because it doesn't *if you have C+ + code*. It is a hammer best suited for nails manufactured in another universe. > You can build Python classes that inherit from C++ classes, you can > built C++ classes that inherit from Python classes. You can write free > functions, you can construct enums, and you basically use it by > writing > down some simple definitions. Your C++ code is idiomatic AND your > Python > code is idiomatic. PyObjC (with Objective-C) gives you this too, minus some of the idiomatic on the Python side -- but it requires no glue and happens at runtime, which is well worth the trade. > Example: using Boost.Python, we constructed an Event (publish/ > subscribe) > system that allows for arbitrary data to be passed as Python > dictionaries. Events, queues and listeners can be constructed on > either > side of the fence and interoperate cleanly. You can have an arbitrary > number of event queues. It's a remarkably easy and clean way to pass > messages around between a collection of otherwise-disconnected > components, and lets us keep static coupling to a minimum. > > Boost.Python isn't for everyone, but in our system it was a lifesaver. Except for the fact its build system is *crazy* and is causing you unnecessary headaches on the Mac... Anyway, I was referring to the fact that Boost.Python would be introducing new C++ code where there was none before. On top of that, you'd be adding glue code, another programming language, another compiler, a Python extension, and a funky ABI requirement to the mix. Wrapping with Objective-C takes no more effort than C++ (probably less), doesn't introduce a new compiler, and doesn't even tie you to a particular version of Python (since you just pull in the class from your wrapper at runtime, and you have no Python extension module). Wrapping in Pyrex is even easier than Objective-C, except when dealing with CoreFoundation toll-free bridged types, but can be a PITA to debug since it's a pre-processor for C and it does give you a Python extension. Not wrapping at all is best of course, which is why I suggested PyObjC's loadBundleFunctions or ctypes. -bob From rkern at ucsd.edu Sat May 28 04:56:22 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 27 May 2005 19:56:22 -0700 Subject: [Pythonmac-SIG] Apple's python extensions into Quartz2D In-Reply-To: References: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> <5CB8EFD6-1329-46EA-8388-44F92BED1E8B@redivi.com> Message-ID: <4297DDD6.7090002@ucsd.edu> nickg wrote: > thanks for the reply. > > Odd, the Python API is nearly 1-1 with the CoreGraphics C API so I > wouldn't expect any hacks. Oh well. I disliked the implementation (undocumented, closed source SWIG bindings are largely unusable), so I wrote my own using Pyrex. I call it, unimaginatively, ABCGI, A Better CoreGraphics Interface. It is part of Kiva, Enthought's graphics library, and has served as "ground truth" for the other backends. When I get some time, I'll break it out as a separate package. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From delza at livingcode.org Sat May 28 08:04:05 2005 From: delza at livingcode.org (Dethe Elza) Date: Fri, 27 May 2005 23:04:05 -0700 Subject: [Pythonmac-SIG] Correct way to send info to running program Message-ID: <35C214FB-0738-4004-8AC7-380625A2CF3A@livingcode.org> I want to be able to periodically send data to a running program, from the command-line. I was looking at the various NSPort classes, but just discovered that NSSocketPort is not a raw socket, but only intended to talk to other NSPort instances. Surely I'm not the only one who wants to be able to do this. Is there a "one right way?" Any guidance here would be appreciated. --Dethe There are only two industries that call their customers "users" From bob at redivi.com Sat May 28 11:14:10 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 28 May 2005 02:14:10 -0700 Subject: [Pythonmac-SIG] Correct way to send info to running program In-Reply-To: <35C214FB-0738-4004-8AC7-380625A2CF3A@livingcode.org> References: <35C214FB-0738-4004-8AC7-380625A2CF3A@livingcode.org> Message-ID: <223FF1C4-0661-42DB-990B-0A763B811B39@redivi.com> On May 27, 2005, at 11:04 PM, Dethe Elza wrote: > I want to be able to periodically send data to a running program, > from the command-line. I was looking at the various NSPort classes, > but just discovered that NSSocketPort is not a raw socket, but only > intended to talk to other NSPort instances. Surely I'm not the only > one who wants to be able to do this. Is there a "one right way?" NSDistributedNotificationCenter? You didn't really specify what your requirements are... -bob From meesters at uni-mainz.de Sat May 28 13:13:25 2005 From: meesters at uni-mainz.de (Christian Meesters) Date: Sat, 28 May 2005 13:13:25 +0200 Subject: [Pythonmac-SIG] setting a link to a script using matplolibs WXAgg fails Message-ID: <9eb1a7245f1fae6feb4b8e9111fd8a93@uni-mainz.de> Hi Currently I'm writing a bunch of scripts for batch processing and a few for graphical display of my data. During the process of writing I simply put links in /usr/local/bin to my scripting directory. Invoking the 'non-graphical' scripts this way in any directory is no problem. Calling the 'graphical' scripts via one of the links results in the following error messages: import: unable to open X server `'. import: unable to open X server `'. /usr/local/bin/SPlot: line 14: syntax error near unexpected token `'WXAgg'' /usr/local/bin/SPlot: line 14: `matplotlib.use('WXAgg') Well, as you can see I'm using matplotlib with the WXAgg backend. The code here is simply: import os import matplotlib matplotlib.use('WXAgg') #line 14 This happens regardless of whether I use the WX or WXAgg backend and the program is running just fine if I start it with pythonw directly. (I should mention that I'm still stuck with Panther and - in this case for reasons of backwards compatibility; can't install matplotlib for python 2.4 - with Apple's python 2.3.) Any hints? I don't even know whether this problem is wx related or the reasons are buried in Apple's framework install. So, should I contact a different list? Thanks, Christian From hengist.podd at virgin.net Sat May 28 14:18:47 2005 From: hengist.podd at virgin.net (has) Date: Sat, 28 May 2005 13:18:47 +0100 Subject: [Pythonmac-SIG] binary extension portability Message-ID: Hi folks, One more question: am I right in thinking that extension binaries aren't portable between major Python versions, e.g. an .so file built under Python 2.3 won't work on Python 2.4 and vice-versa? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From enrike at altern.org Sat May 28 14:03:10 2005 From: enrike at altern.org (altern) Date: Sat, 28 May 2005 14:03:10 +0200 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <05May4.170546pdt."58617"@synergy1.parc.xerox.com> References: <05May4.170546pdt."58617"@synergy1.parc.xerox.com> Message-ID: <42985DFE.1010203@altern.org> hi maybe a bit late but there it goes. I have been doing some Ruby recently and i used the 30 days demo of an editor called TextMate. I found nice that when you type ( or [ or { or ' it automaticly gives you the closing simbol ' ] } ) on the right side of you cursor, then you just type the stuff in between and dont have to bother closing it. I am not sure yet if this is useful or might cause some problems, so far it has been very nice, i am not good at typing and all those symbols in spanish keybpard are not that straight forward to get. Maybe this could be switched on or off from preferences? hope this helps, best -- enrike From bob at redivi.com Sat May 28 20:07:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 28 May 2005 11:07:49 -0700 Subject: [Pythonmac-SIG] setting a link to a script using matplolibs WXAgg fails In-Reply-To: <9eb1a7245f1fae6feb4b8e9111fd8a93@uni-mainz.de> References: <9eb1a7245f1fae6feb4b8e9111fd8a93@uni-mainz.de> Message-ID: On May 28, 2005, at 4:13 AM, Christian Meesters wrote: > Hi > > Currently I'm writing a bunch of scripts for batch processing and a > few > for graphical display of my data. During the process of writing I > simply put links in /usr/local/bin to my scripting directory. Invoking > the 'non-graphical' scripts this way in any directory is no problem. > Calling the 'graphical' scripts via one of the links results in the > following error messages: > import: unable to open X server `'. > import: unable to open X server `'. > /usr/local/bin/SPlot: line 14: syntax error near unexpected token > `'WXAgg'' > /usr/local/bin/SPlot: line 14: `matplotlib.use('WXAgg') Use #!/usr/bin/env /usr/bin/pythonw pythonw is a script and can't be invoked directly from an #! -bob From bob at redivi.com Sat May 28 20:08:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 28 May 2005 11:08:16 -0700 Subject: [Pythonmac-SIG] binary extension portability In-Reply-To: References: Message-ID: On May 28, 2005, at 5:18 AM, has wrote: > One more question: am I right in thinking that extension binaries > aren't portable between major Python versions, e.g. an .so file > built under Python 2.3 won't work on Python 2.4 and vice-versa? Correct, binary extensions are not portable between major Python versions on ANY platform. -bob From delza at livingcode.org Sat May 28 20:10:00 2005 From: delza at livingcode.org (Dethe Elza) Date: Sat, 28 May 2005 11:10:00 -0700 Subject: [Pythonmac-SIG] Correct way to send info to running program In-Reply-To: <223FF1C4-0661-42DB-990B-0A763B811B39@redivi.com> References: <35C214FB-0738-4004-8AC7-380625A2CF3A@livingcode.org> <223FF1C4-0661-42DB-990B-0A763B811B39@redivi.com> Message-ID: Bob wrote: > NSDistributedNotificationCenter? > > You didn't really specify what your requirements are... > I'm trying to set up a "simplest thing that could possibly work" for getting events from another application which doesn't really play well with others. I have hacked it enough that it logs the events I want to the console, so I can, for example, put a tail -f console.log | grep [events I'm interested in] | sendMessageToMyApp. I was intending to make "sendMessageToMyApp" be based on datagrams using something along the lines of: import socket host, port = 'localhost', 8081 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.sendto('some data from the command-line', (host, port)) But I was thinking that I could use NSPort to receive these messages, which was totally off base. I can apparently use CFSocket, but realized that I should do a reality check and see if there's a better way than the somewhat convoluted and roundabout path I'd set up. It looks like NSDistributedNotificationCenter might work. I'll try it out. Thanks! --Dethe From hengist.podd at virgin.net Sat May 28 21:11:57 2005 From: hengist.podd at virgin.net (has) Date: Sat, 28 May 2005 20:11:57 +0100 Subject: [Pythonmac-SIG] binary extension portability In-Reply-To: References: Message-ID: Bob wrote: >>One more question: am I right in thinking that extension binaries aren't portable between major Python versions, e.g. an .so file built under Python 2.3 won't work on Python 2.4 and vice-versa? > >Correct, binary extensions are not portable between major Python versions on ANY platform. Thought as much, just couldn't seem to find confirmation in the Python docs. Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From meesters at uni-mainz.de Sun May 29 01:43:30 2005 From: meesters at uni-mainz.de (Christian Meesters) Date: Sun, 29 May 2005 01:43:30 +0200 Subject: [Pythonmac-SIG] setting a link to a script using matplolibs WXAgg fails In-Reply-To: References: <9eb1a7245f1fae6feb4b8e9111fd8a93@uni-mainz.de> Message-ID: <0484052a1248582e7321d6152da1a7e8@uni-mainz.de> On 28 May 2005, at 20:07, Bob Ippolito wrote: > > Use #!/usr/bin/env /usr/bin/pythonw > > pythonw is a script and can't be invoked directly from an #! > > -bob > Oh, yes! I didn't think of it. (The program still crashes, but this is definitively a bug related to converting into a bitmap. I will need to look into this ...) Thanks, Christian From mwh at python.net Sun May 29 19:45:32 2005 From: mwh at python.net (Michael Hudson) Date: Sun, 29 May 2005 18:45:32 +0100 Subject: [Pythonmac-SIG] binary extension portability In-Reply-To: (has's message of "Sat, 28 May 2005 20:11:57 +0100") References: Message-ID: <2my89yvscj.fsf@starship.python.net> has writes: > Bob wrote: > >>>One more question: am I right in thinking that extension binaries >>>aren't portable between major Python versions, e.g. an .so file >>>built under Python 2.3 won't work on Python 2.4 and vice-versa? >> >>Correct, binary extensions are not portable between major Python >>versions on ANY platform. > > Thought as much, just couldn't seem to find confirmation in the > Python docs. Thanks, Well, it's more a matter of practicality; there's no effort to make sure that extensions are binary compatible accross Python versions, and so usually they aren't. That said, you'd probably be able to load an extension for 2.3 into 2.4 if you ignore the warnings, but it certainly isn't supported. Cheers, mwh -- The ability to quote is a serviceable substitute for wit. -- W. Somerset Maugham From lanceboyle at cwazy.co.uk Mon May 30 02:38:36 2005 From: lanceboyle at cwazy.co.uk (Lance Boyle) Date: Sun, 29 May 2005 17:38:36 -0700 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <42985DFE.1010203@altern.org> References: <05May4.170546pdt."58617"@synergy1.parc.xerox.com> <42985DFE.1010203@altern.org> Message-ID: This sounds like a good idea to me. The Mathematica editor does this and I can't remember any problems caused by it. Jerry On May 28, 2005, at 5:03 AM, altern wrote: > hi > > maybe a bit late but there it goes. > I have been doing some Ruby recently and i used the 30 days demo of an > editor called TextMate. I found nice that when you type ( or [ or { or > ' > it automaticly gives you the closing simbol ' ] } ) on the right side > of > you cursor, then you just type the stuff in between and dont have to > bother closing it. > I am not sure yet if this is useful or might cause some problems, so > far > it has been very nice, i am not good at typing and all those symbols in > spanish keybpard are not that straight forward to get. Maybe this could > be switched on or off from preferences? > From y.benita at wanadoo.nl Mon May 30 16:44:14 2005 From: y.benita at wanadoo.nl (Yair Benita) Date: Mon, 30 May 2005 16:44:14 +0200 Subject: [Pythonmac-SIG] Sets and Speed Message-ID: Hi All, My research involves genomic research and the use of sets (recently introduced in version 2.4) makes my life easier in a lot of ways. However, I noticed that working with large set slows the script to unbearable speed. Below I compare two simple scripts, one makes use of a list and the other makes use of a set. The difference of 20 seconds may not be much, but let me tell you that this difference grows exponentially. When my sets reach more that 100,000 elements, a union command is painfully slow. True, a union command of a set may be much more complicated than using a list but the time difference is simply too big for me. Any thoughts/suggestions? I suppose that the obvious solution is to work with lists most of the time and use the sets only when I really need them. But then, what's the point of having those set? Consider the following example just for making my point: (sets were run using MacPython 2.4.1 on a PowerMac G4 dual 1.25) ############################ from time import time x = set([]) prev_time = time() initial_time = time() for i in range(20000): x = x.union(set([i])) if i % 1000 == 0: print i, "done. seconds since last: %.3f" % (time()-prev_time) prev_time = time() print "done in %.3f" %(time() - initial_time) ############################ The output of this script is: 0 done. seconds since last: 0.002 1000 done. seconds since last: 0.103 2000 done. seconds since last: 0.354 3000 done. seconds since last: 0.784 4000 done. seconds since last: 0.861 5000 done. seconds since last: 1.501 6000 done. seconds since last: 1.707 7000 done. seconds since last: 1.751 8000 done. seconds since last: 1.894 9000 done. seconds since last: 2.907 10000 done. seconds since last: 3.155 11000 done. seconds since last: 3.278 12000 done. seconds since last: 3.374 13000 done. seconds since last: 3.559 14000 done. seconds since last: 3.824 15000 done. seconds since last: 3.905 16000 done. seconds since last: 4.040 17000 done. seconds since last: 5.853 18000 done. seconds since last: 6.928 19000 done. seconds since last: 7.038 done in 64.414 Lets run the same script using a list: ############################ from time import time x = [] prev_time = time() initial_time = time() for i in range(20000): if i not in x: x.append(i) if i % 1000 == 0: print i, "done. seconds since last: %.3f" % (time()-prev_time) prev_time = time() print "done in %.3f" %(time() - initial_time) ############################ The output of this script is: 0 done. seconds since last: 0.002 1000 done. seconds since last: 0.102 2000 done. seconds since last: 0.323 3000 done. seconds since last: 0.506 4000 done. seconds since last: 0.676 5000 done. seconds since last: 0.871 6000 done. seconds since last: 1.051 7000 done. seconds since last: 1.242 8000 done. seconds since last: 1.365 9000 done. seconds since last: 1.635 10000 done. seconds since last: 1.760 11000 done. seconds since last: 1.929 12000 done. seconds since last: 2.133 13000 done. seconds since last: 2.294 14000 done. seconds since last: 2.659 15000 done. seconds since last: 3.015 16000 done. seconds since last: 3.182 17000 done. seconds since last: 3.332 18000 done. seconds since last: 3.552 19000 done. seconds since last: 3.690 done in 39.197 From nickgsuperstar at gmail.com Mon May 30 17:35:34 2005 From: nickgsuperstar at gmail.com (nickg) Date: Mon, 30 May 2005 11:35:34 -0400 Subject: [Pythonmac-SIG] Sets and Speed In-Reply-To: References: Message-ID: <8952554E-06E1-4764-A08A-F0D473805646@gmail.com> Hello, x = x.union(set([i]) is the problem. You are creating two new data structures (set[i], and x.union) at every iteration, and I suspect union is a slow operation. Just change this to "x.add(i)" and the script will run 20x faster than your list version! $ ./settest2.py done in 0.026 x = set() for i in range(20000): x.add(i) enjoy! --nickg On May 30, 2005, at 10:44 AM, Yair Benita wrote: > Hi All, > My research involves genomic research and the use of sets (recently > introduced in version 2.4) makes my life easier in a lot of ways. > However, I > noticed that working with large set slows the script to unbearable > speed. > > Below I compare two simple scripts, one makes use of a list and the > other > makes use of a set. The difference of 20 seconds may not be much, > but let me > tell you that this difference grows exponentially. When my sets > reach more > that 100,000 elements, a union command is painfully slow. True, a > union > command of a set may be much more complicated than using a list but > the time > difference is simply too big for me. > > Any thoughts/suggestions? > > I suppose that the obvious solution is to work with lists most of > the time > and use the sets only when I really need them. But then, what's the > point of > having those set? > > > Consider the following example just for making my point: > (sets were run using MacPython 2.4.1 on a PowerMac G4 dual 1.25) > ############################ > from time import time > > x = set([]) > prev_time = time() > initial_time = time() > for i in range(20000): > x = x.union(set([i])) > if i % 1000 == 0: > print i, "done. seconds since last: %.3f" % (time()-prev_time) > prev_time = time() > print "done in %.3f" %(time() - initial_time) > > ############################ > The output of this script is: > 0 done. seconds since last: 0.002 > 1000 done. seconds since last: 0.103 > 2000 done. seconds since last: 0.354 > 3000 done. seconds since last: 0.784 > 4000 done. seconds since last: 0.861 > 5000 done. seconds since last: 1.501 > 6000 done. seconds since last: 1.707 > 7000 done. seconds since last: 1.751 > 8000 done. seconds since last: 1.894 > 9000 done. seconds since last: 2.907 > 10000 done. seconds since last: 3.155 > 11000 done. seconds since last: 3.278 > 12000 done. seconds since last: 3.374 > 13000 done. seconds since last: 3.559 > 14000 done. seconds since last: 3.824 > 15000 done. seconds since last: 3.905 > 16000 done. seconds since last: 4.040 > 17000 done. seconds since last: 5.853 > 18000 done. seconds since last: 6.928 > 19000 done. seconds since last: 7.038 > done in 64.414 > > > Lets run the same script using a list: > ############################ > from time import time > > x = [] > prev_time = time() > initial_time = time() > for i in range(20000): > if i not in x: > x.append(i) > > if i % 1000 == 0: > print i, "done. seconds since last: %.3f" % (time()-prev_time) > prev_time = time() > > print "done in %.3f" %(time() - initial_time) > ############################ > > The output of this script is: > 0 done. seconds since last: 0.002 > 1000 done. seconds since last: 0.102 > 2000 done. seconds since last: 0.323 > 3000 done. seconds since last: 0.506 > 4000 done. seconds since last: 0.676 > 5000 done. seconds since last: 0.871 > 6000 done. seconds since last: 1.051 > 7000 done. seconds since last: 1.242 > 8000 done. seconds since last: 1.365 > 9000 done. seconds since last: 1.635 > 10000 done. seconds since last: 1.760 > 11000 done. seconds since last: 1.929 > 12000 done. seconds since last: 2.133 > 13000 done. seconds since last: 2.294 > 14000 done. seconds since last: 2.659 > 15000 done. seconds since last: 3.015 > 16000 done. seconds since last: 3.182 > 17000 done. seconds since last: 3.332 > 18000 done. seconds since last: 3.552 > 19000 done. seconds since last: 3.690 > done in 39.197 > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Mon May 30 18:03:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 30 May 2005 09:03:30 -0700 Subject: [Pythonmac-SIG] Sets and Speed In-Reply-To: References: Message-ID: <6E073AE8-34AB-48A9-9475-DEB0FC792E84@redivi.com> On May 30, 2005, at 7:44 AM, Yair Benita wrote: > My research involves genomic research and the use of sets (recently > introduced in version 2.4) makes my life easier in a lot of ways. > However, I > noticed that working with large set slows the script to unbearable > speed. Sets were actually introduced in Python 2.3, in the sets module, but were introduced as a built-in in Python 2.4. > Below I compare two simple scripts, one makes use of a list and the > other > makes use of a set. The difference of 20 seconds may not be much, > but let me > tell you that this difference grows exponentially. When my sets > reach more > that 100,000 elements, a union command is painfully slow. True, a > union > command of a set may be much more complicated than using a list but > the time > difference is simply too big for me. > > Any thoughts/suggestions? Yeah, don't write code like that. If you don't want exponential time, don't write algorithms that will take exponential time :) Use the right algorithm. Your two examples aren't equivalent. It has exponential time because union takes two sets to return a third. In your example, you are uselessly creating two new sets (and a single-element list) on every iteration: one set with one item, and one set with N items. What you really want to be using is the add or update method, which mutates the set in-place. The list example is nowhere near equivalent. To compare apples to apples the list example should be: if i not in x: x = x + [i] and that would be much slower than either of your examples! On my 1ghz G4 laptop: Your set example: 87.921s Your list example: 51.542s My set example (using x.add(i)): 0.095s > I suppose that the obvious solution is to work with lists most of > the time > and use the sets only when I really need them. But then, what's the > point of > having those set? What's the point of having Python if you can write faster code in assembly? Where did you learn to use lists as a set anyway? The canonical pre-2.3 example was to use a dict as a set (since the keys are a set). -bob From gandreas at gandreas.com Mon May 30 23:04:09 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Mon, 30 May 2005 16:04:09 -0500 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: References: <05May4.170546pdt."58617"@synergy1.parc.xerox.com> <42985DFE.1010203@altern.org> Message-ID: <5AF5549D-A6A7-4A1D-AD5A-1DDC44D34689@gandreas.com> On May 29, 2005, at 7:38 PM, Lance Boyle wrote: > This sounds like a good idea to me. The Mathematica editor does this > and I can't remember any problems caused by it. > > Jerry > > > On May 28, 2005, at 5:03 AM, altern wrote: > > >> hi >> >> maybe a bit late but there it goes. >> I have been doing some Ruby recently and i used the 30 days demo >> of an >> editor called TextMate. I found nice that when you type ( or [ or >> { or >> ' >> it automaticly gives you the closing simbol ' ] } ) on the right side >> of >> you cursor, then you just type the stuff in between and dont have to >> bother closing it. >> I am not sure yet if this is useful or might cause some problems, so >> far >> it has been very nice, i am not good at typing and all those >> symbols in >> spanish keybpard are not that straight forward to get. Maybe this >> could >> be switched on or off from preferences? It already has it but apparently there isn't a UI for enabling it. You can, however, do: defaults write com.gandreas.PyOXIDE IDEKit_TextAutoCloseKey 1 from the command line to enable it. It only does (), [], and {}, and not any of the quote marks, since, especially for the single quote, it's used for things that don't make it "closable" (like twice in this past sentence). The double quotes, however, probably should... Glenn Andreas gandreas at gandreas.com wicked fun! Widgetarium | the quickest path to widgets From y.benita at wanadoo.nl Mon May 30 23:48:04 2005 From: y.benita at wanadoo.nl (Yair Benita) Date: Mon, 30 May 2005 23:48:04 +0200 Subject: [Pythonmac-SIG] Sets and Speed In-Reply-To: <6E073AE8-34AB-48A9-9475-DEB0FC792E84@redivi.com> References: <6E073AE8-34AB-48A9-9475-DEB0FC792E84@redivi.com> Message-ID: <6CC54C78-3D0B-43C1-802A-02826C312894@wanadoo.nl> Dear Bob, your answer makes me feel very stupid and I think you're even angry at me for appearing stupid, or maybe for hinting that python was not good enough. Don't get me wrong, I love python, and will not switch to assembly any time soon.... Of course, I don't use that kind of code it was only an example to make a point that the union command was very slow when the sets get big. I guess it wasn't such a good example. I usually combine 2 sets using union but one set is much smaller than the other. It is better to do it using "add", as suggested, and that is my solution. I didn't realize that using "add" will not create redundancy, as you said these are like keys in a dictionary so no duplicates can occur. I suppose "union" is worth doing when I have two big sets to be combined. I will be more careful when I post next time. promise. Yair On May 30, 2005, at 6:03 , Bob Ippolito wrote: > > On May 30, 2005, at 7:44 AM, Yair Benita wrote: > > >> My research involves genomic research and the use of sets (recently >> introduced in version 2.4) makes my life easier in a lot of ways. >> However, I >> noticed that working with large set slows the script to unbearable >> speed. >> > > Sets were actually introduced in Python 2.3, in the sets module, > but were introduced as a built-in in Python 2.4. > > >> Below I compare two simple scripts, one makes use of a list and >> the other >> makes use of a set. The difference of 20 seconds may not be much, >> but let me >> tell you that this difference grows exponentially. When my sets >> reach more >> that 100,000 elements, a union command is painfully slow. True, a >> union >> command of a set may be much more complicated than using a list >> but the time >> difference is simply too big for me. >> >> Any thoughts/suggestions? >> > > Yeah, don't write code like that. If you don't want exponential > time, don't write algorithms that will take exponential time :) > Use the right algorithm. > > Your two examples aren't equivalent. It has exponential time > because union takes two sets to return a third. In your example, > you are uselessly creating two new sets (and a single-element list) > on every iteration: one set with one item, and one set with N > items. What you really want to be using is the add or update > method, which mutates the set in-place. The list example is > nowhere near equivalent. To compare apples to apples the list > example should be: > > if i not in x: > x = x + [i] > > and that would be much slower than either of your examples! > > On my 1ghz G4 laptop: > > Your set example: 87.921s > Your list example: 51.542s > My set example (using x.add(i)): 0.095s > > >> I suppose that the obvious solution is to work with lists most of >> the time >> and use the sets only when I really need them. But then, what's >> the point of >> having those set? >> > > What's the point of having Python if you can write faster code in > assembly? > > Where did you learn to use lists as a set anyway? The canonical > pre-2.3 example was to use a dict as a set (since the keys are a set). > > -bob > > From bob at redivi.com Mon May 30 23:51:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 30 May 2005 14:51:09 -0700 Subject: [Pythonmac-SIG] Sets and Speed In-Reply-To: <6CC54C78-3D0B-43C1-802A-02826C312894@wanadoo.nl> References: <6E073AE8-34AB-48A9-9475-DEB0FC792E84@redivi.com> <6CC54C78-3D0B-43C1-802A-02826C312894@wanadoo.nl> Message-ID: On May 30, 2005, at 2:48 PM, Yair Benita wrote: > I usually combine 2 sets using union but one set is much smaller > than the other. It is better to do it using "add", as suggested, > and that is my solution. I didn't realize that using "add" will not > create redundancy, as you said these are like keys in a dictionary > so no duplicates can occur. I suppose "union" is worth doing when I > have two big sets to be combined. Union is for combining two sets and creating a third set -- which involves a lot of copying and reference counting. If you want to combine two sets, simply mutating one, use update. -bob From sw at wordtech-software.com Tue May 31 05:58:32 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon, 30 May 2005 23:58:32 -0400 Subject: [Pythonmac-SIG] Can't register Apple Help book with Carbon.AH module Message-ID: <429BE0E8.5060808@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to format some help docs into Apple Help format for an application I'm working on, but I can't get the help book registered. Here is my code: from Carbon import AH import os path = ?? AH.AHRegisterHelpBook(path) The difficulty I'm having is defining the path to the help documents in the application bundle. I've tried hard-coding the path as /path/to/Contents/Resources/Help Book/index.html, but that yields "file not found." I've looked at the source docs for PythonIDE, but they're a bit cryptic. I don't quite understand how the Carbon module defines this stuff (FSSpec, etc). (I'm working with wxPython, so I need to define this stuff through Carbon.) Is there a way to do this with the os.path module? If so I haven't quite grokked how. Any help is appreciated. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.kevin-walzer.com mailto:sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCm+DoJmdQs+6YVcoRAtM9AJ4zScG7D9CKS4Db2kBSLcc0zXX+TgCggcON rTCeKCthaQAPBCyaC5AblGU= =+1S2 -----END PGP SIGNATURE----- From bob at redivi.com Tue May 31 06:06:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon, 30 May 2005 21:06:15 -0700 Subject: [Pythonmac-SIG] Can't register Apple Help book with Carbon.AH module In-Reply-To: <429BE0E8.5060808@wordtech-software.com> References: <429BE0E8.5060808@wordtech-software.com> Message-ID: <698A167E-7903-485B-92A4-908BD85FD62C@redivi.com> On May 30, 2005, at 8:58 PM, Kevin Walzer wrote: > I'm trying to format some help docs into Apple Help format for an > application I'm working on, but I can't get the help book registered. > Here is my code: Did you try putting it in the Info.plist? It should be automatically registered by LaunchServices on launch. > from Carbon import AH > import os > path = ?? > AH.AHRegisterHelpBook(path) This stuff is probably way deprecated. Look in the Apple docs. > The difficulty I'm having is defining the path to the help > documents in > the application bundle. I've tried hard-coding the path as > /path/to/Contents/Resources/Help Book/index.html, but that yields > "file > not found." I've looked at the source docs for PythonIDE, but > they're a > bit cryptic. I don't quite understand how the Carbon module defines > this > stuff (FSSpec, etc). (I'm working with wxPython, so I need to define > this stuff > through Carbon.) Is there a way to do this with the os.path module? If > so I haven't quite grokked how. Carbon.File.FSRef(someUnixPath) -bob From rogerb at rogerbinns.com Tue May 31 08:19:54 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Mon, 30 May 2005 23:19:54 -0700 Subject: [Pythonmac-SIG] Can't register Apple Help book with Carbon.AHmodule References: <429BE0E8.5060808@wordtech-software.com> <698A167E-7903-485B-92A4-908BD85FD62C@redivi.com> Message-ID: <008001c565a8$c2d7a270$04000100@rogersqyvr14d3> >> from Carbon import AH >> import os >> path = ?? >> AH.AHRegisterHelpBook(path) > > This stuff is probably way deprecated. Look in the Apple docs. That particular function isn't. The Apple docs basically say you can use the plist stuff (without giving sufficient detail for a non-Mac native developer to succeed) or you can use the function above which doesn't seem to work (the index doesn't get used). If anyone does manage to get working help with a wxPython app then please post about it and update the wiki at http://wiki.wxpython.org/ Roger From thorthor at altern.org Tue May 31 13:57:37 2005 From: thorthor at altern.org (thor) Date: Tue, 31 May 2005 12:57:37 +0100 Subject: [Pythonmac-SIG] app on top Message-ID: <8a29ec74f43b0ea5c52d75b4f7271a43@altern.org> Hi list This might be an OS question, rather than a Python one, but I am wondering if there is a way to tell an application to be always on top (or in front) of other applications running. I'd like to create a GUI in python and it should stay on top of other background applications to which the GUI communicates. Any ideas? thor From Henning.Ramm at mediapro-gmbh.de Tue May 31 17:58:20 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Tue, 31 May 2005 17:58:20 +0200 Subject: [Pythonmac-SIG] app on top Message-ID: >This might be an OS question, rather than a Python one, but I am >wondering if there is a way to tell an application to be always on >top (or in front) of other applications running. >I'd like to create a GUI in python and it should stay on top of >other background applications to which the GUI communicates. It's a GUI question - every GUI toolkit has its own "stay on top" method. You didn't specify which toolkit you're planning to use. Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From karl at elemtech.com Tue May 31 18:20:09 2005 From: karl at elemtech.com (Karl Merkley) Date: Tue, 31 May 2005 10:20:09 -0600 Subject: [Pythonmac-SIG] macho_standalone with imported module Message-ID: <3a98ab0dca373d75aee60ce1469d741c@elemtech.com> I am playing with macho_standalone to see how it can help me build a bundle. One of the issues that I've run into is that my C++ application imports modules at run time. Is there anyway to tell macho_standalone that a particular .so file needs to be examined and dependencies need to be included for that as well? Thanks, Karl From bob at redivi.com Tue May 31 18:38:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 31 May 2005 09:38:09 -0700 Subject: [Pythonmac-SIG] macho_standalone with imported module In-Reply-To: <3a98ab0dca373d75aee60ce1469d741c@elemtech.com> References: <3a98ab0dca373d75aee60ce1469d741c@elemtech.com> Message-ID: <41027929-C9BA-479E-94D2-6DE13E00F187@redivi.com> On May 31, 2005, at 9:20 AM, Karl Merkley wrote: > I am playing with macho_standalone to see how it can help me > build a bundle. One of the issues that I've run into is that my C++ > application imports modules at run time. Is there anyway to tell > macho_standalone that a particular .so file needs to be examined and > dependencies need to be included for that as well? It analyzes everything that is in your application bundle, so just make sure the .so files are already in there somewhere and you should be fine. -bob From enrike at altern.org Tue May 31 20:15:09 2005 From: enrike at altern.org (altern) Date: Tue, 31 May 2005 20:15:09 +0200 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <5AF5549D-A6A7-4A1D-AD5A-1DDC44D34689@gandreas.com> References: <05May4.170546pdt."58617"@synergy1.parc.xerox.com> <42985DFE.1010203@altern.org> <5AF5549D-A6A7-4A1D-AD5A-1DDC44D34689@gandreas.com> Message-ID: <429CA9AD.6050600@altern.org> gandreas at gandreas.com wrote: > On May 29, 2005, at 7:38 PM, Lance Boyle wrote: > > >>This sounds like a good idea to me. The Mathematica editor does this >>and I can't remember any problems caused by it. >> >>Jerry >> >> >>On May 28, 2005, at 5:03 AM, altern wrote: >> >> >> >>>hi >>> >>>maybe a bit late but there it goes. >>>I have been doing some Ruby recently and i used the 30 days demo >>>of an >>>editor called TextMate. I found nice that when you type ( or [ or >>>{ or >>>' >>>it automaticly gives you the closing simbol ' ] } ) on the right side >>>of >>>you cursor, then you just type the stuff in between and dont have to >>>bother closing it. >>>I am not sure yet if this is useful or might cause some problems, so >>>far >>>it has been very nice, i am not good at typing and all those >>>symbols in >>>spanish keybpard are not that straight forward to get. Maybe this >>>could >>>be switched on or off from preferences? > > > It already has it but apparently there isn't a UI for enabling it. > You can, however, do: > > defaults write com.gandreas.PyOXIDE IDEKit_TextAutoCloseKey 1 > > from the command line to enable it. > > It only does (), [], and {}, and not any of the quote marks, since, > especially for the single quote, it's used for things that don't make > it "closable" (like twice in this past sentence). The double > quotes, however, probably should... great, many thanks. btw, still i havent been able find out how to type [ or { on Pyoxide with my spanish keyboard. I have to use alt+` and alt+? to get them but those keys dont seem to produce any output on pyoxide. > > Glenn Andreas gandreas at gandreas.com > wicked fun! > Widgetarium | the quickest path to widgets > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- enrike From berkowit at silcom.com Tue May 31 20:24:02 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Tue, 31 May 2005 11:24:02 -0700 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <429CA9AD.6050600@altern.org> Message-ID: On 5/31/05 11:15 AM, "altern" wrote: > btw, still i havent been able find out how to type [ or { on Pyoxide > with my spanish keyboard. I have to use alt+` and alt+? to get them > but those keys dont seem to produce any output on pyoxide. Worst come to worst, add an English language keyboard to the Input menu (System preferences/International/Input menu) and switch to it when you need to. You can add the Keyboard Viewer to the Input menu too, to remind yourself where the keys are. The former built-in keyboard shortcut for switching keyboards - cmd-space - has been taken over by Spotlight in Tiger but you can assign another one in System Prefs/Keyboard & Mouse/Keyboard Shortcuts/Input menu, or right in the International/Input menu prefs. -- Paul Berkowitz From Chris.Barker at noaa.gov Tue May 31 21:15:20 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue, 31 May 2005 12:15:20 -0700 Subject: [Pythonmac-SIG] Apple's python extensions into Quartz2D In-Reply-To: <4297DDD6.7090002@ucsd.edu> References: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> <5CB8EFD6-1329-46EA-8388-44F92BED1E8B@redivi.com> <4297DDD6.7090002@ucsd.edu> Message-ID: <429CB7C8.5000004@noaa.gov> Robert Kern wrote: > I disliked the implementation (undocumented, closed source SWIG bindings > are largely unusable), so I wrote my own using Pyrex. I call it, > unimaginatively, ABCGI, A Better CoreGraphics Interface. It is part of > Kiva, Enthought's graphics library, and has served as "ground truth" for > the other backends. > > When I get some time, I'll break it out as a separate package. While we're on the topic, could Kiva be ripped out and used by itself? It could be a pretty cool lib for things other than Chaco. Also, what's the status of Chaco on Linux and OX-X? It looked so promising, but has kind of disappeared off the radar. -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 at noaa.gov From gandreas at gandreas.com Tue May 31 22:17:40 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Tue, 31 May 2005 15:17:40 -0500 Subject: [Pythonmac-SIG] PyObjC vs "old school" embedding Message-ID: <5282E5B0-18AD-4061-8829-90AA2AB2FD43@gandreas.com> So PyOXIDE is based on the traditional way to embed python in an application (explicitly calling the python APIs to access and call stuff), and this worked reasonably well. For example, it runs various scripts at startup, which register various callbacks to handle things like new documents, new interactives, etc... (and then the underlying Objective C code explicitly calls these callbacks at appropriate points). Unfortunately, things recently have gone downhill (with either the Tiger system framework or the 2.4 unofficial official framework, with PyObjC 1.3.5(*)). I've got an "interactive" window (i.e., the interactive shell) which is loaded via a menu command - in the window's controller awakenFromNib: I've got the following code: - (void) awakeFromNib { NSLog(@"Interactive awakeFromNib"); myMain = PyImport_AddModule("__main__"); if (myMain == NULL || (PyErr_Occurred())) { //NSLog(@"Couldn't add module __main__"); PyErr_Print(); } (... and then the code that calls the python code to hook the interactive window to the text view, etc...) Now, when the interactive window is created by the menu, everything works fine (application main loop calls the Objective C code which loads a nib, nib loading calls above routine, everything fine). If the same thing includes a layer of python on the stack, such as is done as part of the debugger (since I've got interactive windows in the debugger so you can directly access/execute code in your debugged context), it fails - namely, PyImport_AddModule crashes: #0 0x100a68d8 in PyImport_AddModule (name=0x159c8 "__main__") at / Users/bob/src/Python-2.4.1/Python/import.c:308 #1 0x000090bc in -[PyInteractive awakeFromNib] (self=0x54b71a0, _cmd=0x909f36ac) at /Volumes/YWork1/PyOXIDE/Source/PyInteractive.mm:132 #2 0x92886788 in -[NSSet makeObjectsPerformSelector:] () #3 0x93636f94 in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] () #4 0x9370dbdc in old_loadNib () [snip] #8 0x9370d6a4 in -[NSWindowController window] () #9 0x007d7a98 in ffi_call_DARWIN () #10 0x007d74b0 in ffi_call () #11 0x007beb24 in PyObjCFFI_Caller () #12 0x007d1e3c in PyObjCAPI_Register () #13 0x1000c348 in PyObject_Call (func=0x0, arg=0x101158b4, kw=0x101268b8) at /Users/bob/src/Python-2.4.1/Objects/abstract.c:1751 [snip] #39 0x100092cc in PyObject_CallMethod (o=0x0, name=0x10119178 "a more convenient interface.", format=0x713030 "") at /Users/bob/src/ Python-2.4.1/Objects/abstract.c:1751 #40 0x0000d954 in -[NSDocument(NSDocumentPyHandler) pythonOnHandler:] (self=0x4cef190, _cmd=0x1746c, sender=0x387220) at /Volumes/YWork1/ PyOXIDE/Source/NSDocumentPyHandler.mm:181 #41 0x936be08c in -[NSApplication sendAction:to:from:] () [snip] Basically, the app calls my object to handle the menu command ("Debug") which calls PyObject_CallMethod to handle the "bound menu routine". That python code does a bunch of stuff, loads a nib, the nib loading fires off my awakeFromNib code, which tries to get the __main__ module, and boom! Looking at import.c:308: PyObject * PyImport_GetModuleDict(void) { PyInterpreterState *interp = PyThreadState_GET()->interp; // Crash is here, since PyThreadState_GET is NULL if (interp->modules == NULL) Py_FatalError("PyImport_GetModuleDict: no module dictionary!"); return interp->modules; } There are no python threads running, I've not called PyEval_InitThreads() or anything like that. So it _appears_ that any code called from Python through the Objective C bridge can no longer access the interpreter - is this correct? What would be the approach to allow this to work? Should I initialize threads support, and execute all my callbacks on a separate thread? Or would I need to create a new interpreter state for these? Or am I just plain hosed on mixing "traditional" embedding techniques with PyObjC? (* - I've downloaded and installed PyObjC 1.3.6 twice but for some reason it doesn't want to use it: gandreas% /Library/Frameworks/Python.framework/Versions/Current/bin/ python2.4 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import objc >>> objc.__version__ '1.3.5' >>> objc.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/PyObjC/objc/__init__.pyc' ) Glenn Andreas gandreas at gandreas.com wicked fun! Widgetarium | the quickest path to widgets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050531/d1a05a80/attachment-0001.html From rkern at ucsd.edu Tue May 31 22:45:41 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 31 May 2005 13:45:41 -0700 Subject: [Pythonmac-SIG] Apple's python extensions into Quartz2D In-Reply-To: <429CB7C8.5000004@noaa.gov> References: <3021B31A-B087-45A8-A88D-78E2904B80D8@gmail.com> <5CB8EFD6-1329-46EA-8388-44F92BED1E8B@redivi.com> <4297DDD6.7090002@ucsd.edu> <429CB7C8.5000004@noaa.gov> Message-ID: <429CCCF5.4000607@ucsd.edu> Chris Barker wrote: > Robert Kern wrote: > >>I disliked the implementation (undocumented, closed source SWIG bindings >>are largely unusable), so I wrote my own using Pyrex. I call it, >>unimaginatively, ABCGI, A Better CoreGraphics Interface. It is part of >>Kiva, Enthought's graphics library, and has served as "ground truth" for >>the other backends. >> >>When I get some time, I'll break it out as a separate package. > > While we're on the topic, could Kiva be ripped out and used by itself? Certainly. To "rip it out," all you do is not import Chaco. ;-) > It could be a pretty cool lib for things other than Chaco. Also, what's > the status of Chaco on Linux and OX-X? It looked so promising, but has > kind of disappeared off the radar. Neglected. :-) Enthought's primary target has been wxPython 2.4 on Windows. However, there were some recent changes that should improve its outlook on OS X, at least. I haven't had a chance to try them out, yet. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Tue May 31 22:51:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 31 May 2005 13:51:24 -0700 Subject: [Pythonmac-SIG] PyObjC vs "old school" embedding In-Reply-To: <5282E5B0-18AD-4061-8829-90AA2AB2FD43@gandreas.com> References: <5282E5B0-18AD-4061-8829-90AA2AB2FD43@gandreas.com> Message-ID: On May 31, 2005, at 1:17 PM, gandreas at gandreas.com wrote: > So PyOXIDE is based on the traditional way to embed python in an > application (explicitly calling the python APIs to access and call > stuff), and this worked reasonably well. For example, it runs > various scripts at startup, which register various callbacks to > handle things like new documents, new interactives, etc... (and > then the underlying Objective C code explicitly calls these > callbacks at appropriate points). I would just throw this stuff away and take advantage of what PyObjC can (and has always been able to) do for you. Digging at the Python API is hard to get right, and is a LOT more code, as you've shown. Somewhere in PyOXIDE you're not managing interpreter state correctly, probably not in the code you've pasted, I don't have time to look into it... but I HIGHLY RECOMMEND that you throw away all your Python C API code and use a PyObjC-based bundle instead, which will take care of managing interpreter state and such for you at message dispatch boundaries. > (* - I've downloaded and installed PyObjC 1.3.6 twice but for some > reason it doesn't want to use it: > > gandreas% /Library/Frameworks/Python.framework/Versions/Current/bin/ > python2.4 > Python 2.4.1 (#2, Mar 31 2005, 00:05:10) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import objc > >>> objc.__version__ > '1.3.5' > >>> objc.__file__ > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ > site-packages/PyObjC/objc/__init__.pyc' > ) Anyone else have this problem? -bob From dreedmac at columbus.rr.com Tue May 31 23:27:55 2005 From: dreedmac at columbus.rr.com (David Reed) Date: Tue, 31 May 2005 17:27:55 -0400 Subject: [Pythonmac-SIG] PyObjC vs "old school" embedding In-Reply-To: References: <5282E5B0-18AD-4061-8829-90AA2AB2FD43@gandreas.com> Message-ID: On May 31, 2005, at 4:51 PM, Bob Ippolito wrote: > > On May 31, 2005, at 1:17 PM, gandreas at gandreas.com wrote: > >> (* - I've downloaded and installed PyObjC 1.3.6 twice but for some >> reason it doesn't want to use it: >> >> gandreas% /Library/Frameworks/Python.framework/Versions/Current/bin/ >> python2.4 >> Python 2.4.1 (#2, Mar 31 2005, 00:05:10) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin >> Type "help", "copyright", "credits" or "license" for more >> information. >> >>>>> import objc >>>>> objc.__version__ >>>>> >> '1.3.5' >> >>>>> objc.__file__ >>>>> >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> site-packages/PyObjC/objc/__init__.pyc' >> ) >> > > Anyone else have this problem? > > -bob I just downloaded and installed 1.3.6 and also have that problem. $ python2.4 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import objc >>> objc.__version__ '1.3.5' >>> objc.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/PyObjC/objc/__init__.pyc' Dave From gandreas at gandreas.com Tue May 31 23:36:46 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Tue, 31 May 2005 16:36:46 -0500 Subject: [Pythonmac-SIG] PyObjC vs "old school" embedding In-Reply-To: References: <5282E5B0-18AD-4061-8829-90AA2AB2FD43@gandreas.com> Message-ID: <4CECCD45-1384-4C36-9FED-D436219B86EA@gandreas.com> On May 31, 2005, at 3:51 PM, Bob Ippolito wrote: > > On May 31, 2005, at 1:17 PM, gandreas at gandreas.com wrote: > > >> So PyOXIDE is based on the traditional way to embed python in an >> application (explicitly calling the python APIs to access and call >> stuff), and this worked reasonably well. For example, it runs >> various scripts at startup, which register various callbacks to >> handle things like new documents, new interactives, etc... (and >> then the underlying Objective C code explicitly calls these >> callbacks at appropriate points). >> > > I would just throw this stuff away and take advantage of what > PyObjC can (and has always been able to) do for you. Digging at > the Python API is hard to get right, and is a LOT more code, as > you've shown. Yes, it's trickier to get all the details correct on embedding, but yes, I've done it before (more times than I care to admit) so it wasn't that big of a deal. However, the current release of PyObjC appears to change the semantics of that - what the current interpreter state is when getting called back has changed, so it is no longer possible to explicitly call further Python code via the embedding API from native code called over the PyObjC bridge. > > Somewhere in PyOXIDE you're not managing interpreter state > correctly, probably not in the code you've pasted, I don't have > time to look into it... Obviously you've got next week's session to get prepared for, but there is no code for managing the interpreter state to be wrong, since there isn't any (and without any threading, there shouldn't be the need for any - and this case is entirely threading free). > but I HIGHLY RECOMMEND that you throw away all your Python C API > code and use a PyObjC-based bundle instead, which will take care of > managing interpreter state and such for you at message dispatch > boundaries. > It's just not practical at this time to "throw away all my Python C API code" and refactor the application to be a PyObjC based bundle, and frankly, I don't consider this a practical answer anyway. Saying "yes, you can embed python and PyObjC but you really want to throw things around and have your application embedded as a PyObjC based bundle" seems to be a limiting answer. There's lots of scripting languages that can be embedded with various levels of language bridges - Python (PyObjC), Perl (CamelBones), JavaScript (WebKit), Lua (LuaObjective-C), Ruby (RubyCocoa) etc... and as near as I know, PyObjC is the only one that requires this "embed your app" approach. PyObjC and the whole py2app is a _great_ way to take python scripts and turn them into an application - don't get me wrong, I'm not say this isn't really slick and amazing with how well it works, but this doesn't seem like a good approach to embedding Python in an existing application. Compare it with how to use Javascript via WebKit - yes, it's no where near as flexible/automatic as PyObjC, (and you can't mix and match inheritance!) but in the end, if you want to embed a scripting language to extend your application, Javascript via Webkit is probably a better solution than PyObjC (which is a real shame). Glenn Andreas gandreas at gandreas.com wicked fun! quadrium | build, mutate, evolve | images, textures, backgrounds, art From bob at redivi.com Tue May 31 23:54:10 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue, 31 May 2005 14:54:10 -0700 Subject: [Pythonmac-SIG] PyObjC vs "old school" embedding In-Reply-To: <4CECCD45-1384-4C36-9FED-D436219B86EA@gandreas.com> References: <5282E5B0-18AD-4061-8829-90AA2AB2FD43@gandreas.com> <4CECCD45-1384-4C36-9FED-D436219B86EA@gandreas.com> Message-ID: On May 31, 2005, at 2:36 PM, gandreas at gandreas.com wrote: > > On May 31, 2005, at 3:51 PM, Bob Ippolito wrote: > > >> >> On May 31, 2005, at 1:17 PM, gandreas at gandreas.com wrote: >> >> >> >>> So PyOXIDE is based on the traditional way to embed python in an >>> application (explicitly calling the python APIs to access and >>> call stuff), and this worked reasonably well. For example, it >>> runs various scripts at startup, which register various callbacks >>> to handle things like new documents, new interactives, etc... >>> (and then the underlying Objective C code explicitly calls these >>> callbacks at appropriate points). >>> >>> >> >> I would just throw this stuff away and take advantage of what >> PyObjC can (and has always been able to) do for you. Digging at >> the Python API is hard to get right, and is a LOT more code, as >> you've shown. >> > > Yes, it's trickier to get all the details correct on embedding, but > yes, I've done it before (more times than I care to admit) so it > wasn't that big of a deal. However, the current release of PyObjC > appears to change the semantics of that - what the current > interpreter state is when getting called back has changed, so it is > no longer possible to explicitly call further Python code via the > embedding API from native code called over the PyObjC bridge. It hasn't really changed, you just weren't managing the interpreter state correctly. >> Somewhere in PyOXIDE you're not managing interpreter state >> correctly, probably not in the code you've pasted, I don't have >> time to look into it... >> > > Obviously you've got next week's session to get prepared for, but > there is no code for managing the interpreter state to be wrong, > since there isn't any (and without any threading, there shouldn't > be the need for any - and this case is entirely threading free). Actually, there is. Look at: >> but I HIGHLY RECOMMEND that you throw away all your Python C API >> code and use a PyObjC-based bundle instead, which will take care >> of managing interpreter state and such for you at message dispatch >> boundaries. > > It's just not practical at this time to "throw away all my Python C > API code" and refactor the application to be a PyObjC based bundle, > and frankly, I don't consider this a practical answer anyway. > Saying "yes, you can embed python and PyObjC but you really want to > throw things around and have your application embedded as a PyObjC > based bundle" seems to be a limiting answer. There's lots of > scripting languages that can be embedded with various levels of > language bridges - Python (PyObjC), Perl (CamelBones), JavaScript > (WebKit), Lua (LuaObjective-C), Ruby (RubyCocoa) etc... and as near > as I know, PyObjC is the only one that requires this "embed your > app" approach. PyObjC-based bundle meaning -- PyObjC-based *plugin* MH_BUNDLE!! I didn't say rewrite the shell of your app. > PyObjC and the whole py2app is a _great_ way to take python scripts > and turn them into an application - don't get me wrong, I'm not say > this isn't really slick and amazing with how well it works, but > this doesn't seem like a good approach to embedding Python in an > existing application. Compare it with how to use Javascript via > WebKit - yes, it's no where near as flexible/automatic as PyObjC, > (and you can't mix and match inheritance!) but in the end, if you > want to embed a scripting language to extend your application, > Javascript via Webkit is probably a better solution than PyObjC > (which is a real shame). If you say so.. -bob