From delza at livingcode.org Sun Jan 2 03:29:49 2005 From: delza at livingcode.org (Dethe Elza) Date: Sun Jan 2 03:29:48 2005 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 In-Reply-To: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> References: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> Message-ID: <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> Congrats to all the pyobjc developers, this is a great way to start the new year. I have a couple of questions about pyobjc 1.2. First, can Categories extend classes which are defined in Python? Second, what applications can be extended with plugins? I realize a complete list is unfeasible, but which Apple applications would be a good start. As far as I can tell, Safari requires Netscape-style plugins to extend it, is that wrong? TIA, and happy new year! --Dethe There are two ways of constructing a software design. One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. --C.A.R. Hoare -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050101/b0fa3879/smime.bin From bob at redivi.com Sun Jan 2 04:00:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 2 04:01:01 2005 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 In-Reply-To: <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> References: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> Message-ID: <84A9F074-5C6A-11D9-BBAB-000A9567635C@redivi.com> On Jan 1, 2005, at 9:29 PM, Dethe Elza wrote: > I have a couple of questions about pyobjc 1.2. First, can Categories > extend classes which are defined in Python? Only if they are a subclass of an Objective-C class. > Second, what applications can be extended with plugins? I realize a > complete list is unfeasible, but which Apple applications would be a > good start. As far as I can tell, Safari requires Netscape-style > plugins to extend it, is that wrong? Any application that expects its plugins to be written in Objective-C is fair game, anything else (such as Safari's Netscape-style plugins) is unsupported and probably won't work. The reason for this is that applications that expect plugins to be written in C or C++ are probably going to expect that particular symbols are defined in the plugin, and that is basically impossible to do at runtime and would require some custom compiled C/C++ stub. Objective-C is dynamic enough that this may be done at runtime using a dyld bundle loader hook to define the class while the application is trying to look it up. It is theoretically possible to make this work without requiring a custom stub (b/c macholib could rewrite the symbol table), but I'm not going to write such a monstrosity any time soon unless someone is willing to pay me a lot to do it. I simply just don't have a need for it, and if I did, I would likely just write a custom C/C++ stub. -bob From bob at redivi.com Sun Jan 2 04:40:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 2 04:40:42 2005 Subject: [Pythonmac-SIG] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3 In-Reply-To: References: Message-ID: <0FFA1732-5C70-11D9-BBAB-000A9567635C@redivi.com> On Jan 1, 2005, at 5:33 PM, jackjansen@users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Mac/OSX > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14408 > > Modified Files: > fixapplepython23.py > Log Message: > Create the wrapper scripts for gcc/g++ too. > > +SCRIPT="""#!/bin/sh > +export MACOSX_DEPLOYMENT_TARGET=10.3 > +exec %s "${@}" This script should check to see if MACOSX_DEPLOYMENT_TARGET is already set. If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an extension that requires 10.4 features) then I'm going to have some serious problems with this fix. -bob From Meitnik at aol.com Sun Jan 2 06:47:50 2005 From: Meitnik at aol.com (Meitnik@aol.com) Date: Sun Jan 2 06:47:55 2005 Subject: [Pythonmac-SIG] New to phython and need an ide tool help.... Message-ID: <104.57aa1aa2.2f08e506@aol.com> Greetings... :-) I am here due to some good friends to learn Python. :) However, I need some help to really easily learn Python. Due to typing limitations of my fingers, I could really use a code auto-complete feature in the Macphython IDE am currently using to learn Python with. Anyone up to adding this? I am not looking for anything fancy for now. Just enough to rapidly insert code and not be stumbling with syntax and correct spelling. I did find one tool to do it but its an expensive one for my limited fixed income and its far more powerful then I need for now. Thanks for considering my problem. I look forward to learning much! Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050102/56a7fbc7/attachment.html From bob at redivi.com Sun Jan 2 07:02:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 2 07:03:41 2005 Subject: [Pythonmac-SIG] New to phython and need an ide tool help.... In-Reply-To: <104.57aa1aa2.2f08e506@aol.com> References: <104.57aa1aa2.2f08e506@aol.com> Message-ID: On Jan 2, 2005, at 12:47 AM, Meitnik@aol.com wrote: > ???? However, I need some help to really easily learn Python. Due to > typing limitations of my fingers, I could really use a code > auto-complete feature in the Macphython IDE am currently using to > learn Python with. Anyone up to adding this? I am not looking for > anything fancy for now. Just enough to rapidly insert code and not be > stumbling with syntax and correct spelling. I did find one tool to do > it but its an expensive one for my limited fixed income and its far > more powerful then I need for now. The MacPython IDE isn't really maintained, so it's unlikely that this will happen. You may want to try using Xcode, it will do syntax highlighting and completion of Python code. It's not the smartest around, but it doesn't cost anything (assuming you have a copy of Mac OS X 10.3). PyOXIDE might also have code completion, I'm not sure. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1051 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050102/6d575a12/attachment.bin From delza at livingcode.org Sun Jan 2 08:13:00 2005 From: delza at livingcode.org (Dethe Elza) Date: Sun Jan 2 08:13:12 2005 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 In-Reply-To: <84A9F074-5C6A-11D9-BBAB-000A9567635C@redivi.com> References: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> <84A9F074-5C6A-11D9-BBAB-000A9567635C@redivi.com> Message-ID: >> I have a couple of questions about pyobjc 1.2. First, can Categories >> extend classes which are defined in Python? > > Only if they are a subclass of an Objective-C class. OK, that's about what I expected. >> Second, what applications can be extended with plugins? I realize a >> complete list is unfeasible, but which Apple applications would be a >> good start. As far as I can tell, Safari requires Netscape-style >> plugins to extend it, is that wrong? > > Any application that expects its plugins to be written in Objective-C > is fair game, anything else (such as Safari's Netscape-style plugins) > is unsupported and probably won't work. This is also what I expect, but how do I know which applications expect plugins at all? Can I write a plugin for Mail.app? For iCal? What are the rules? If this is in the FAQ somewhere, I haven't seen it, but feel free to tell me to RTFM if it is. I'm also curious how pyject works with this (if its related at all). Can you give an example of how pyject would be used? Thanks again. --Dethe "...our universities, I suggest, are not half-way out of the fifteenth century. [...] The three or four years' course of lectures, the bachelor who knows some, the master who knows most, the doctor who knows all, are ideas that have come down unimpaired from the Middle Ages. Nowadays no one should end his learning while he lives and these university degrees are preposterous. [...] Educationally we are still for all practical purposes in the coach and horse and galley stage." H. G. Wells -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050101/91bc8044/smime.bin From bob at redivi.com Sun Jan 2 08:41:33 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 2 08:41:38 2005 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 In-Reply-To: References: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> <84A9F074-5C6A-11D9-BBAB-000A9567635C@redivi.com> Message-ID: On Jan 2, 2005, at 2:13 AM, Dethe Elza wrote: >>> Second, what applications can be extended with plugins? I realize a >>> complete list is unfeasible, but which Apple applications would be a >>> good start. As far as I can tell, Safari requires Netscape-style >>> plugins to extend it, is that wrong? >> >> Any application that expects its plugins to be written in Objective-C >> is fair game, anything else (such as Safari's Netscape-style plugins) >> is unsupported and probably won't work. > > This is also what I expect, but how do I know which applications > expect plugins at all? Can I write a plugin for Mail.app? For iCal? > What are the rules? If this is in the FAQ somewhere, I haven't seen > it, but feel free to tell me to RTFM if it is. You'll have to RTFM on a per-application basis. This doesn't have much to do with PyObjC. As far as I know, Mail will take plugins if you set a certain plist key, and iCal will not. Certain kinds of plugins will get loaded into ANY Carbon or Cocoa application, but I definitely don't think you should do this with a py2app-built plugin because it will probably break applications that use their own copy of Python... so I'm not going to say any more about that. > I'm also curious how pyject works with this (if its related at all). > Can you give an example of how pyject would be used? pyject works with this by starting a new thread in an arbitrary pid that loads some plugin using mach_inject. The intended use is to load a py2app-built plugin, which will run whatever module level code is in your main script. I wouldn't recommend it for production use, but it could be used for a lot of interesting things from a software developer's perspective. Again, it's mostly only useful if your application is Objective-C, since there isn't too much you can do with Python in a Carbon application that doesn't expect it (without some deep hacking, anyway). Carbon and Cocoa can play nicely together, so you could do something like load a PyInterpreter into iTunes with a UI that works, but you'd have to be really ambitious to make it actually cause iTunes to do anything differently. -bob From jo at johnochiltree.uklinux.net Sun Jan 2 12:33:00 2005 From: jo at johnochiltree.uklinux.net (John Ochiltree) Date: Sun Jan 2 12:33:15 2005 Subject: [Pythonmac-SIG] New to phython and need an ide tool help.... In-Reply-To: References: <104.57aa1aa2.2f08e506@aol.com> Message-ID: <0EEE6CE6-5CB2-11D9-BCE2-000D9352164A@johnochiltree.uklinux.net> On 2 Jan 2005, at 06:02, Bob Ippolito wrote: > On Jan 2, 2005, at 12:47 AM, Meitnik@aol.com wrote: > >> ???? However, I need some help to really easily learn Python. Due to >> typing limitations of my fingers, I could really use a code >> auto-complete feature in the Macphython IDE am currently using to >> learn Python with. Anyone up to adding this? I am not looking for >> anything fancy for now. Just enough to rapidly insert code and not be >> stumbling with syntax and correct spelling. I did find one tool to do >> it but its an expensive one for my limited fixed income and its far >> more powerful then I need for now. > > The MacPython IDE isn't really maintained, so it's unlikely that this > will happen. > > You may want to try using Xcode, it will do syntax highlighting and > completion of Python code. It's not the smartest around, but it > doesn't cost anything (assuming you have a copy of Mac OS X 10.3). > > PyOXIDE might also > have code completion, I'm not sure. > > -bob > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > Is the code available for the MacPython IDE? Is there enough interest to get something like the idlefork project off the ground? Idlefork took the original idle, added loads to it and it was merged back into the main branch. Anyone interested? John Ochiltree -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1539 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050102/117e9aea/attachment.bin From just at letterror.com Sun Jan 2 14:00:23 2005 From: just at letterror.com (Just van Rossum) Date: Sun Jan 2 14:00:40 2005 Subject: [Pythonmac-SIG] New to phython and need an ide tool help.... In-Reply-To: <0EEE6CE6-5CB2-11D9-BCE2-000D9352164A@johnochiltree.uklinux.net> Message-ID: John Ochiltree wrote: > > On 2 Jan 2005, at 06:02, Bob Ippolito wrote: > > > The MacPython IDE isn't really maintained, so it's unlikely that > > this will happen. > > > > You may want to try using Xcode, it will do syntax highlighting and > > completion of Python code. It's not the smartest around, but it > > doesn't cost anything (assuming you have a copy of Mac OS X 10.3). > > > > PyOXIDE might > > also have code completion, I'm not sure. > > > Is the code available for the MacPython IDE? Sure, it's part of the Python CVS tree. > Is there enough interest to get something like the idlefork project > off the ground? Idlefork took the original idle, added loads to it > and it was merged back into the main branch. Anyone interested? Extremely bad idea. The IDE is not so much not maintained because noone is interested (well, that, too :-), but because it is obsolete in many ways. A rewrite from scratch would be best... Fortunately, PyOXIDE seems to be just that. Just From delza at livingcode.org Sun Jan 2 20:50:14 2005 From: delza at livingcode.org (Dethe Elza) Date: Sun Jan 2 20:50:17 2005 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 In-Reply-To: References: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> <84A9F074-5C6A-11D9-BBAB-000A9567635C@redivi.com> Message-ID: <856C06C8-5CF7-11D9-BD26-0003939B59E8@livingcode.org> > You'll have to RTFM on a per-application basis. This doesn't have > much to do with PyObjC. OK, that's what I was afraid of. Thanks! > pyject works with this by > starting a new thread in an arbitrary pid that loads some plugin using > mach_inject. The intended use is to load a py2app-built plugin, which > will run whatever module level code is in your main script. I > wouldn't recommend it for production use, but it could be used for a > lot of interesting things from a software developer's perspective. What would be an example use? --Dethe "Say what you like about C++, but it's uninitialized variables will always hold a special place in my heart. In a world where we define *everything* concretely it is the last refuge of the undefined. It's the programmer's Wild West, the untamed frontier." --Bjorn Stroustrap -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050102/70f56dd8/smime.bin From bob at redivi.com Sun Jan 2 21:10:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 2 21:10:42 2005 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 In-Reply-To: <856C06C8-5CF7-11D9-BD26-0003939B59E8@livingcode.org> References: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> <84A9F074-5C6A-11D9-BBAB-000A9567635C@redivi.com> <856C06C8-5CF7-11D9-BD26-0003939B59E8@livingcode.org> Message-ID: <5D1C6186-5CFA-11D9-8981-000A9567635C@redivi.com> On Jan 2, 2005, at 2:50 PM, Dethe Elza wrote: >> pyject works with this by >> starting a new thread in an arbitrary pid that loads some plugin >> using mach_inject. The intended use is to load a py2app-built >> plugin, which will run whatever module level code is in your main >> script. I wouldn't recommend it for production use, but it could be >> used for a lot of interesting things from a software developer's >> perspective. > > What would be an example use? If you can't immediately think of anything, you probably don't have a use for it :) As it is largely undocumented, has no official release, is quite "evil", and I have no spare time to support it.. I'm not going to encourage its use. If you have a use for it, it's there, but that's about as far as I'm willing to go right now. -bob From delza at livingcode.org Sun Jan 2 21:19:56 2005 From: delza at livingcode.org (Dethe Elza) Date: Sun Jan 2 21:20:06 2005 Subject: [Pythonmac-SIG] ANN: pyobjc-1.2 In-Reply-To: <5D1C6186-5CFA-11D9-8981-000A9567635C@redivi.com> References: <3B7A08B9-5A3F-11D9-85EE-000D93AD379E@mac.com> <2D047026-5C66-11D9-9A2F-0003939B59E8@livingcode.org> <84A9F074-5C6A-11D9-BBAB-000A9567635C@redivi.com> <856C06C8-5CF7-11D9-BD26-0003939B59E8@livingcode.org> <5D1C6186-5CFA-11D9-8981-000A9567635C@redivi.com> Message-ID: > As it is largely undocumented, has no official release, is quite > "evil", and I have no spare time to support it.. I'm not going to > encourage its use. If you have a use for it, it's there, but that's > about as far as I'm willing to go right now. With an intro like that, how can I *not* try it out? %-) --Dethe A miracle, even if it's a lousy miracle, is still a miracle. --Teller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050102/078d73d1/smime.bin From Jack.Jansen at cwi.nl Sun Jan 2 22:28:22 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 2 22:28:12 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3 In-Reply-To: <0FFA1732-5C70-11D9-BBAB-000A9567635C@redivi.com> References: <0FFA1732-5C70-11D9-BBAB-000A9567635C@redivi.com> Message-ID: <3A6CE662-5D05-11D9-81BB-000D934FF6B4@cwi.nl> On 2-jan-05, at 4:40, Bob Ippolito wrote: >> +SCRIPT="""#!/bin/sh >> +export MACOSX_DEPLOYMENT_TARGET=10.3 >> +exec %s "${@}" > > This script should check to see if MACOSX_DEPLOYMENT_TARGET is already > set. If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for > compilation (say I'm compiling an extension that requires 10.4 > features) then I'm going to have some serious problems with this fix. I was going to do that, but then I thought it didn't make any sense, because this script is *only* used in the context of Apple-provided Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other than 10.3 (be it lower or higher) while compiling an extension for Apple's 2.3 is going to produce disappointing results anyway. But, if I've missed a use case, please enlighten me. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Sun Jan 2 22:35:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 2 22:35:25 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3 In-Reply-To: <3A6CE662-5D05-11D9-81BB-000D934FF6B4@cwi.nl> References: <0FFA1732-5C70-11D9-BBAB-000A9567635C@redivi.com> <3A6CE662-5D05-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <3192B720-5D06-11D9-8981-000A9567635C@redivi.com> On Jan 2, 2005, at 4:28 PM, Jack Jansen wrote: > > On 2-jan-05, at 4:40, Bob Ippolito wrote: >>> +SCRIPT="""#!/bin/sh >>> +export MACOSX_DEPLOYMENT_TARGET=10.3 >>> +exec %s "${@}" >> >> This script should check to see if MACOSX_DEPLOYMENT_TARGET is >> already set. If I have some reason to set >> MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an >> extension that requires 10.4 features) then I'm going to have some >> serious problems with this fix. > > I was going to do that, but then I thought it didn't make any sense, > because this script is *only* used in the context of Apple-provided > Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other > than 10.3 (be it lower or higher) while compiling an extension for > Apple's 2.3 is going to produce disappointing results anyway. > > But, if I've missed a use case, please enlighten me. You're right, of course. I had realized that I was commenting on the fixpython script after I had replied, but my concern is still applicable to whatever solution is used for Python 2.4.1. Anything lower than 10.3 is of course an error, in either case. -bob From Jack.Jansen at cwi.nl Mon Jan 3 00:16:07 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jan 3 00:16:02 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3 In-Reply-To: <3192B720-5D06-11D9-8981-000A9567635C@redivi.com> References: <0FFA1732-5C70-11D9-BBAB-000A9567635C@redivi.com> <3A6CE662-5D05-11D9-81BB-000D934FF6B4@cwi.nl> <3192B720-5D06-11D9-8981-000A9567635C@redivi.com> Message-ID: <47FBE1CA-5D14-11D9-81BB-000D934FF6B4@cwi.nl> On 2-jan-05, at 22:35, Bob Ippolito wrote: >> On 2-jan-05, at 4:40, Bob Ippolito wrote: >>>> +SCRIPT="""#!/bin/sh >>>> +export MACOSX_DEPLOYMENT_TARGET=10.3 >>>> +exec %s "${@}" >>> >>> This script should check to see if MACOSX_DEPLOYMENT_TARGET is >>> already set. If I have some reason to set >>> MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an >>> extension that requires 10.4 features) then I'm going to have some >>> serious problems with this fix. >> >> I was going to do that, but then I thought it didn't make any sense, >> because this script is *only* used in the context of Apple-provided >> Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other >> than 10.3 (be it lower or higher) while compiling an extension for >> Apple's 2.3 is going to produce disappointing results anyway. >> >> But, if I've missed a use case, please enlighten me. > > You're right, of course. I had realized that I was commenting on the > fixpython script after I had replied, but my concern is still > applicable to whatever solution is used for Python 2.4.1. Anything > lower than 10.3 is of course an error, in either case. 2.4.1 will install this fix into Apple-installed Python 2.3 (if applicable, i.e. if you're installing 2.4.1 on 10.3), but for its own use it will have the newer distutils, which understands that it needs to pick up MACOSX_DEPLOYMENT_TARGET from the Makefile, so it'll never see these scripts. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Mon Jan 3 03:43:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 3 03:43:44 2005 Subject: [Pythonmac-SIG] Darwin's realloc(...) implementation never shrinks allocations Message-ID: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> Quite a few notable places in the Python sources expect realloc(...) to relinquish some memory if the requested size is smaller than the currently allocated size. This is definitely not true on Darwin, and possibly other platforms. I have tested this on OpenBSD and Linux, and the implementations on these platforms do appear to relinquish memory, but I didn't read the implementation. I haven't been able to find any documentation that states that realloc should make this guarantee, but I figure Darwin does this as an "optimization" and because Darwin probably can't resize mmap'ed memory (at least it can't from Python, but this probably means it doesn't have this capability at all). It is possible to "fix" this for Darwin, because you can ask the default malloc zone how big a particular allocation is, and how big an allocation of a given size will actually be (see: ). The obvious place to put this would be PyObject_Realloc, because this is at least called by _PyString_Resize (which will fix ). Should I write up a patch that "fixes" this? I guess the best thing to do would be to determine whether the fix should be used at runtime, by allocating a meg or so, resizing it to 1 byte, and see if the size of the allocation changes. If the size of the allocation does change, then the system realloc can be trusted to do what Python expects it to do, otherwise realloc should be done "cleanly" by allocating a new block (returning the original on failure, because it's good enough and some places in Python seem to expect that shrink will never fail), memcpy, free, return new block. I wrote up a small hack that does this realloc indirection to CVS trunk, and it doesn't seem to cause any measurable difference in pystone performance. Note that all versions of Darwin that I've looked at (6.x, 7.x, and 8.0b1 corresponding to publicly available WWDC 2004 Tiger code) have this "issue", but it might go away by Mac OS X 10.4 or some later release. This URL points to the sf bug and Darwin 7.7's realloc(...) implementation: http://bob.pythonmac.org/archives/2005/01/01/realloc-doesnt/ -bob From bob at redivi.com Mon Jan 3 07:08:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 3 07:08:38 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <1f7befae05010221134a94eccd@mail.gmail.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> Message-ID: On Jan 3, 2005, at 12:13 AM, Tim Peters wrote: > [Bob Ippolito] >> Quite a few notable places in the Python sources expect realloc(...) >> to >> relinquish some memory if the requested size is smaller than the >> currently allocated size. > > I don't know what "relinquish some memory" means. If it means > something like "returns memory to the OS, so that the reported process > size shrinks", then no, nothing in Python ever assumes that. That's > simply because "returns memory to the OS" and "process size" aren't > concepts in the C standard, and so nothing can be said about them in > general -- not in theory, and neither in practice, because platforms > (OS+libc combos) vary so widely in behavior here. > > As a pragmatic matter, I *expect* that a production-quality realloc() > implementation will at least be able to reuse released memory, > provided that the amount released is at least half the amount > originally malloc()'ed (and, e.g., reasonable buddy systems may not be > able to do better than that). This is what I meant by relinquish (c/o merriam-webster): a : to stop holding physically : RELEASE b : to give over possession or control of : YIELD Your expectation is not correct for Darwin's memory allocation scheme. It seems that Darwin creates allocations of immutable size. The only way ANY part of an allocation will ever be used by ANYTHING else is if free() is called with that allocation. free() can be called either explicitly, or implicitly by calling realloc() with a size larger than the size of the allocation. In that case, it will create a new allocation of at least the requested size, copy the contents of the original allocation into the new allocation (probably with copy-on-write pages if it's large enough, so it might be cheap), and free() the allocation. In the case where realloc() specifies a size that is not greater than the allocation's size, it will simply return the given allocation and cause no side-effects whatsoever. Was this a good decision? Probably not! However, it is our (in the "I know you use Windows but I am not the only one that uses Mac OS X" sense) problem so long as Darwin is a supported platform, because it is highly unlikely that Apple will backport any "fix" to the allocator unless we can prove it has some security implications in software shipped with their OS. I attempted to look for some easy ones by performing a quick audit of Apache, OpenSSH, and OpenSSL. Unfortunately, their developers did not share your expectation. I found one sprintf-like routine in Apache that could be affected by this behavior, and one instance of immutable string creation in Apple's CoreFoundation CFString implementation, but I have yet to find an easy way to exploit this behavior from the outside. I should probably be looking at PHP and Perl instead ;) >> but I figure Darwin does this as an "optimization" and because Darwin >> probably can't resize mmap'ed memory (at least it can't from Python, >> but this probably means it doesn't have this capability at all). >> >> It is possible to "fix" this for Darwin, > > I don't understand what's "broken". Small objects go thru Python's > own allocator, which has its own realloc policies and its own > peculiarities (chiefly that pymalloc never free()s any memory > allocated for small objects). What's broken is that there are several places in Python that seem to assume that you can allocate a large chunk of memory, and make it smaller in some meaningful way with realloc(...). This is not true with Darwin. You are right about small objects. They don't matter because they're small, and because they're handled by Python's allocator. >> because you can ask the default malloc zone how big a particular >> allocation is, and how big an allocation of a given size will actually >> be (see: ). >> The obvious place to put this would be PyObject_Realloc, because this >> is at least called by _PyString_Resize (which will fix >> ). > > The diagnosis in the bug report seems to leave it pointing at > socket.py's _fileobject.read(), although I suspect the real cause is > in socketmodule.c's sock_recv(). We've had other reports of various > problems when people pass absurdly large values to socket recv(). A > better fix here would probably amount to rewriting sock_recv() to > refuse to pass enormous numbers to the platform recv() (it appears > that many platform recv() implementations simply don't expect a recv() > argument to be much bigger than the native network buffer size, and > screw up when that's not so). You are correct. The real cause is in sock_recv(), and/or _PyString_Resize(), depending on how you look at it. >> Note that all versions of Darwin that I've looked at (6.x, 7.x, and >> 8.0b1 corresponding to publicly available WWDC 2004 Tiger code) have >> this "issue", but it might go away by Mac OS X 10.4 or some later >> release. > > It would be good to rewrite sock_recv() more defensively in any case. > Best I can tell, this implementation of realloc() is > standard-conforming but uniquely brain dead in its downsize behavior. Presumably this can happen at other places (including third party extensions), so a better place to do this might be _PyString_Resize(). list_resize() is another reasonable place to put this. I'm sure there are other places that use realloc() too, and the majority of them do this through obmalloc. So maybe instead of trying to track down all the places where this can manifest, we should just "gunk up" Python and patch PyObject_Realloc()? Since we are both pretty confident that other allocators aren't like Darwin, this "gunk" can be #ifdef'ed to the __APPLE__ case. > I don't expect the latter will last (as you say on your page, > "probably plenty of other software" also makes the same pragmatic > assumptions about realloc downsize behavior), so I'm not keen to gunk > up Python to worm around it. As I said above, I haven't yet found any other software that makes the same kind of realloc() assumptions that Python does. I'm sure I'll find something, but what's important to me is that Python works well on Mac OS X, so something should happen. If we can't prove that Apple's allocation strategy is a security flaw in some service that ships with the OS, any improvements to this strategy are very unlikely to be backported to current versions of Mac OS X. -bob From tim.peters at gmail.com Mon Jan 3 06:13:22 2005 From: tim.peters at gmail.com (Tim Peters) Date: Mon Jan 3 16:13:23 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> Message-ID: <1f7befae05010221134a94eccd@mail.gmail.com> [Bob Ippolito] > Quite a few notable places in the Python sources expect realloc(...) to > relinquish some memory if the requested size is smaller than the > currently allocated size. I don't know what "relinquish some memory" means. If it means something like "returns memory to the OS, so that the reported process size shrinks", then no, nothing in Python ever assumes that. That's simply because "returns memory to the OS" and "process size" aren't concepts in the C standard, and so nothing can be said about them in general -- not in theory, and neither in practice, because platforms (OS+libc combos) vary so widely in behavior here. As a pragmatic matter, I *expect* that a production-quality realloc() implementation will at least be able to reuse released memory, provided that the amount released is at least half the amount originally malloc()'ed (and, e.g., reasonable buddy systems may not be able to do better than that). > This is definitely not true on Darwin, and possibly other platforms. I have tested > this on OpenBSD and Linux, and the implementations on these platforms do > appear to relinquish memory, As above, don't know what this means. > but I didn't read the implementation. I haven't been able to find any > documentation that states that realloc should make this guarantee, realloc() guarantees very little; it certainly doesn't guarantee anything, e.g., about OS interactions or process sizes. > but I figure Darwin does this as an "optimization" and because Darwin > probably can't resize mmap'ed memory (at least it can't from Python, > but this probably means it doesn't have this capability at all). > > It is possible to "fix" this for Darwin, I don't understand what's "broken". Small objects go thru Python's own allocator, which has its own realloc policies and its own peculiarities (chiefly that pymalloc never free()s any memory allocated for small objects). > because you can ask the default malloc zone how big a particular > allocation is, and how big an allocation of a given size will actually > be (see: ). > The obvious place to put this would be PyObject_Realloc, because this > is at least called by _PyString_Resize (which will fix > ). The diagnosis in the bug report seems to leave it pointing at socket.py's _fileobject.read(), although I suspect the real cause is in socketmodule.c's sock_recv(). We've had other reports of various problems when people pass absurdly large values to socket recv(). A better fix here would probably amount to rewriting sock_recv() to refuse to pass enormous numbers to the platform recv() (it appears that many platform recv() implementations simply don't expect a recv() argument to be much bigger than the native network buffer size, and screw up when that's not so). > Should I write up a patch that "fixes" this? I guess the best thing to > do would be to determine whether the fix should be used at runtime, by > allocating a meg or so, resizing it to 1 byte, and see if the size of > the allocation changes. If the size of the allocation does change, > then the system realloc can be trusted to do what Python expects it to > do, otherwise realloc should be done "cleanly" by allocating a new > block (returning the original on failure, because it's good enough and > some places in Python seem to expect that shrink will never fail), Yup, that assumption (that a non-growing realloc can't fail) is all over the place. > memcpy, free, return new block. > > I wrote up a small hack that does this realloc indirection to CVS > trunk, and it doesn't seem to cause any measurable difference in > pystone performance. > > Note that all versions of Darwin that I've looked at (6.x, 7.x, and > 8.0b1 corresponding to publicly available WWDC 2004 Tiger code) have > this "issue", but it might go away by Mac OS X 10.4 or some later > release. > > This URL points to the sf bug and Darwin 7.7's realloc(...) > implementation: > http://bob.pythonmac.org/archives/2005/01/01/realloc-doesnt/ It would be good to rewrite sock_recv() more defensively in any case. Best I can tell, this implementation of realloc() is standard-conforming but uniquely brain dead in its downsize behavior. I don't expect the latter will last (as you say on your page, "probably plenty of other software" also makes the same pragmatic assumptions about realloc downsize behavior), so I'm not keen to gunk up Python to worm around it. From tim.peters at gmail.com Mon Jan 3 08:16:34 2005 From: tim.peters at gmail.com (Tim Peters) Date: Mon Jan 3 16:13:24 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> Message-ID: <1f7befae050102231638b0d39d@mail.gmail.com> [Bob Ippolito] > ... > Your expectation is not correct for Darwin's memory allocation scheme. > It seems that Darwin creates allocations of immutable size. The only > way ANY part of an allocation will ever be used by ANYTHING else is if > free() is called with that allocation. Ya, I understood that. My conclusion was that Darwin's realloc() implementation isn't production-quality. So it goes. > free() can be called either explicitly, or implicitly by calling realloc() with > a size larger than the size of the allocation. In that case, it will create a new > allocation of at least the requested size, copy the contents of the > original allocation into the new allocation (probably with > copy-on-write pages if it's large enough, so it might be cheap), and > free() the allocation. Really? Another near-universal "quality of implementation" expectation is that a growing realloc() will strive to extend in-place. Like realloc(malloc(1000000), 1000001). For example, the theoretical guarantee that one-at-a-time list.append() has amortized linear time doesn't depend on that, but pragmatically it's greatly helped by a reasonable growing realloc() implementation. > In the case where realloc() specifies a size that is not greater than the > allocation's size, it will simply return the given allocation and cause no side- > effects whatsoever. > > Was this a good decision? Probably not! Sounds more like a bug (or two) to me than "a decision", but I don't know. > However, it is our (in the "I know you use Windows but I am not the only > one that uses Mac OS X sense) problem so long as Darwin is a supported > platform, because it is highly unlikely that Apple will backport any "fix" to > the allocator unless we can prove it has some security implications in > software shipped with their OS. ... Is there any known case where Python performs poorly on this OS, for this reason, other than the "pass giant numbers to recv() and then shrink the string because we didn't get anywhere near that many bytes" case? Claiming rampant performance problems should require evidence too . ... > Presumably this can happen at other places (including third party > extensions), so a better place to do this might be _PyString_Resize(). > list_resize() is another reasonable place to put this. I'm sure there > are other places that use realloc() too, and the majority of them do > this through obmalloc. So maybe instead of trying to track down all > the places where this can manifest, we should just "gunk up" Python and > patch PyObject_Realloc()? There is no "choke point" for allocations in Python -- some places call the system realloc() directly. Maybe the latter matter on Darwin too, but maybe they don't. The scope of this hack spreads if they do. I have no idea how often realloc() is called directly by 3rd-party extension modules. It's called directly a lot in Zope's C code, but AFAICT only to grow vectors, never to shrink them. ' > Since we are both pretty confident that other allocators aren't like Darwin, > this "gunk" can be #ifdef'ed to the __APPLE__ case. #ifdef's are a last resort: they almost never go away, so they complicate the code forever after, and typically stick around for years even after the platform problems they intended to address have been fixed. For obvious reasons, they're also an endless source of platform-specific bugs. Note that pymalloc already does a memcpy+free when in PyObject_Realloc(p, n) p was obtained from the system malloc or realloc but n is small enough to meet the "small object" threshold (pymalloc "takes over" small blocks that result from a PyObject_Realloc()). That's a reasonable strategy *because* n is always small in such cases. If you're going to extend this strategy to n of arbitrary size, then you may also create new performance problems for some apps on Darwin (copying n bytes can get arbitrarily expensive). > ... > I'm sure I'll find something, but what's important to me is that Python > works well on Mac OS X, so something should happen. I agree the socket-abuse case should be fiddled, and for more reasons than just Darwin's realloc() quirks. I don't know that there are actual problems on Darwin broader than that case (and I'm not challenging you to contrive one, I'm asking whether realloc() quirks are suspected in any other case that's known). Part of what you demonstrated when you said that pystone didn't slow down when you fiddled stuff is that pystone also didn't speed up. I also don't know that the memcpy+free wormaround is actually going to help more than it hurts overall. Yes, in the socket-abuse case, where the program routinely malloc()s strings millions of bytes larger than the socket can deliver, it would obviously help. That's not typically program behavior (however typical it may be of that specific app). More typical is shrinking a long list one element at a time, in which case about half the list remaining would get memcpy'd from time to time where such copies never get made today. IOW, there's no straightforward pure win here. From bob at redivi.com Mon Jan 3 16:48:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 3 16:48:13 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <1f7befae050102231638b0d39d@mail.gmail.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> Message-ID: On Jan 3, 2005, at 2:16 AM, Tim Peters wrote: > [Bob Ippolito] >> ... >> Your expectation is not correct for Darwin's memory allocation scheme. >> It seems that Darwin creates allocations of immutable size. The only >> way ANY part of an allocation will ever be used by ANYTHING else is if >> free() is called with that allocation. > > Ya, I understood that. My conclusion was that Darwin's realloc() > implementation isn't production-quality. So it goes. Whatever that means. >> free() can be called either explicitly, or implicitly by calling >> realloc() with >> a size larger than the size of the allocation. In that case, it will >> create a new >> allocation of at least the requested size, copy the contents of the >> original allocation into the new allocation (probably with >> copy-on-write pages if it's large enough, so it might be cheap), and >> free() the allocation. > > Really? Another near-universal "quality of implementation" > expectation is that a growing realloc() will strive to extend > in-place. Like realloc(malloc(1000000), 1000001). For example, the > theoretical guarantee that one-at-a-time list.append() has amortized > linear time doesn't depend on that, but pragmatically it's greatly > helped by a reasonable growing realloc() implementation. I said that it created allocations of fixed size, not that it created allocations of exactly the size you asked it to. Yes, it will extend in-place for many cases, including the given. >> In the case where realloc() specifies a size that is not greater >> than the >> allocation's size, it will simply return the given allocation and >> cause no side- >> effects whatsoever. >> >> Was this a good decision? Probably not! > > Sounds more like a bug (or two) to me than "a decision", but I don't > know. You said yourself that it is standards compliant ;) I have filed it as a bug, but it is probably unlikely to be backported to current versions of Mac OS X unless a case can be made that it is indeed a security flaw. >> However, it is our (in the "I know you use Windows but I am not the >> only >> one that uses Mac OS X sense) problem so long as Darwin is a supported >> platform, because it is highly unlikely that Apple will backport any >> "fix" to >> the allocator unless we can prove it has some security implications in >> software shipped with their OS. ... > > Is there any known case where Python performs poorly on this OS, for > this reason, other than the "pass giant numbers to recv() and then > shrink the string because we didn't get anywhere near that many bytes" > case? Claiming rampant performance problems should require evidence > too . Known case? No. Do I want to search Python application-space to find one? No. >> Presumably this can happen at other places (including third party >> extensions), so a better place to do this might be _PyString_Resize(). >> list_resize() is another reasonable place to put this. I'm sure there >> are other places that use realloc() too, and the majority of them do >> this through obmalloc. So maybe instead of trying to track down all >> the places where this can manifest, we should just "gunk up" Python >> and >> patch PyObject_Realloc()? > > There is no "choke point" for allocations in Python -- some places > call the system realloc() directly. Maybe the latter matter on Darwin > too, but maybe they don't. The scope of this hack spreads if they do. > I have no idea how often realloc() is called directly by 3rd-party > extension modules. It's called directly a lot in Zope's C code, but > AFAICT only to grow vectors, never to shrink them. In the case of Python, "some places" means "nowhere relevant". Four standard library extension modules relevant to the platform use realloc directly: _sre Uses realloc only to grow buffers. cPickle Uses realloc only to grow buffers. cStringIO Uses realloc only to grow buffers. regexpr: Uses realloc only to grow buffers. If Zope doesn't use the allocator that Python gives it, then it can deal with its own problems. I would expect most extensions to use Python's allocator. >> Since we are both pretty confident that other allocators aren't like >> Darwin, >> this "gunk" can be #ifdef'ed to the __APPLE__ case. > > #ifdef's are a last resort: they almost never go away, so they > complicate the code forever after, and typically stick around for > years even after the platform problems they intended to address have > been fixed. For obvious reasons, they're also an endless source of > platform-specific bugs. They're also the only good way to deal with platform-specific inconsistencies. In this specific case, it's not even possible to determine if a particular allocator implementation is stupid or not without at least using a platform-allocator-specific function to query the size reserved by a given allocation. > Note that pymalloc already does a memcpy+free when in > PyObject_Realloc(p, n) p was obtained from the system malloc or > realloc but n is small enough to meet the "small object" threshold > (pymalloc "takes over" small blocks that result from a > PyObject_Realloc()). That's a reasonable strategy *because* n is > always small in such cases. If you're going to extend this strategy > to n of arbitrary size, then you may also create new performance > problems for some apps on Darwin (copying n bytes can get arbitrarily > expensive). There's obviously a tradeoff between copying lots of bytes and having lots of memory go to waste. That should be taken into consideration when considering how many pages could be returned to the allocator. Note that we can ask the allocator how much memory an allocation has actually reserved (which is usually somewhat larger than the amount you asked it for) and how much memory an allocation will reserve for a given size. An allocation resize wouldn't even show up as smaller unless at least one page would be freed (for sufficiently large allocations anyway, the minimum granularity is 16 bytes because it guarantees that alignment). Obviously if you have a lot of pages anyway, one page isn't a big deal, so we would probably only resort to free()/memcpy() if some fair percentage of the total pages used by the allocation could be rescued. If it does end up causing some real performance problems anyway, there's always deeper hacks like using vm_copy(), a Darwin specific function which will do copy-on-write instead (which only makes sense if the allocation is big enough for this to actually be a performance improvement). >> ... >> I'm sure I'll find something, but what's important to me is that >> Python >> works well on Mac OS X, so something should happen. > > I agree the socket-abuse case should be fiddled, and for more reasons > than just Darwin's realloc() quirks. I don't know that there are > actual problems on Darwin broader than that case (and I'm not > challenging you to contrive one, I'm asking whether realloc() quirks > are suspected in any other case that's known). Part of what you > demonstrated when you said that pystone didn't slow down when you > fiddled stuff is that pystone also didn't speed up. I also don't know > that the memcpy+free wormaround is actually going to help more than it > hurts overall. Yes, in the socket-abuse case, where the program > routinely malloc()s strings millions of bytes larger than the socket > can deliver, it would obviously help. That's not typically program > behavior (however typical it may be of that specific app). More > typical is shrinking a long list one element at a time, in which case > about half the list remaining would get memcpy'd from time to time > where such copies never get made today. I do not yet know of another specific case where Darwin's realloc() implementation causes a problem. The list case would certainly be a loss with current behavior if the list gets extremely large at some point, but then becomes small and stays that way for a long period of time. > IOW, there's no straightforward pure win here. Well at least we have a nice bug to report to Apple, whether or not we do something about it ourselves. -bob From Jack.Jansen at cwi.nl Mon Jan 3 17:08:23 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jan 3 17:07:03 2005 Subject: [Pythonmac-SIG] Live fast, die young: testers wanted for new MacPython additions Message-ID: Folks, I have a first version of the next "MacPython additions for 10.3" available. Please give it a try, including test-driving the Package Manager (which has gone up to version 0.5, and has had all the packages updated to newer versions). Report here with any problems you find, and also if you think there are fixes missing. I'll wait for about a week and unless anyone (including myself) has found problems in that time this'll replace the old additions installer. Download from . -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Mon Jan 3 17:30:14 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 3 17:30:27 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> Message-ID: On Jan 3, 2005, at 11:15 AM, Guido van Rossum wrote: > Coming late to this thread. > > I don't see the point of lying awake at night worrying about potential > memory losses unless you've heard someone complain about it. As Tim > has been trying to explain, here are plenty of other things in Python > that we *could* speed up if there was a need; since every speedup > uglifies the code somewhat, we'd end up with very ugly code if we did > them all. Remember, don't optimize prematurely. We *have* had someone complain about it: http://python.org/sf/1092502 > Here's one theoretical reason why even with socket.recv() it probably > doesn't matter in practice: the overallocated string will usually be > freed as soon as the data has been parsed from it, and this will free > the overallocation as well! That depends on how socket.recv is used. Sometimes, a list of strings is used rather than a cStringIO (or equivalent), which can cause problems (see above referenced bug). -bob From Larry.A.Meyn at nasa.gov Mon Jan 3 22:20:26 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Mon Jan 3 22:21:04 2005 Subject: [Pythonmac-SIG] Problems with matplotlib In-Reply-To: References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> Message-ID: <49966601-5DCD-11D9-951F-000A95A06CF6@nasa.gov> Has anyone had problems with installing and using matplotlib under OS X? I've tried installing the last couple of versions and while installation goes smoothly it crashes when I try to import from pylab, as shown below >>> from pylab import * Traceback (most recent call last): File "", line 1, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pylab.py", line 1, in ? from matplotlib.pylab import * File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/pylab.py", line 194, in ? from axes import Axes, PolarAxes File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/axes.py", line 16, in ? from artist import Artist File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/artist.py", line 3, in ? from transforms import identity_transform File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/transforms.py", line 189, in ? from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY ImportError: cannot import name POLAR I running python 2.3 on OS X 10.3.7 with Numeric 23.6 installed. Any help with this would be greatly appreciated. Larry Larry Meyn Aerospace Operations Modeling Office NASA Ames Research Center From tim.peters at gmail.com Mon Jan 3 22:49:29 2005 From: tim.peters at gmail.com (Tim Peters) Date: Mon Jan 3 22:49:35 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> Message-ID: <1f7befae050103134942ab1696@mail.gmail.com> [Tim Peters] >> Ya, I understood that. My conclusion was that Darwin's realloc() >> implementation isn't production-quality. So it goes. [Bob Ippolito] > Whatever that means. Well, it means what it said. The C standard says nothing about performance metrics of any kind, and a production-quality implementation of C requires very much more than just meeting what the standard requires. The phrase "quality of implementation" is used in the C Rationale (but not in the standard proper) to cover all such issues. realloc() pragmatics are quality-of-implementation issues; the accuracy of fp arithmetic is another (e.g., if you get back -666.0 from the C 1.0 + 2.0, there's nothing in the standard to justify a complaint). >>> free() can be called either explicitly, or implicitly by calling >>> realloc() with a size larger than the size of the allocation. >From later comments feigning outrage , I take it that "the size of the allocation" here does not mean the specific number the user passed to the previous malloc/realloc call, but means whatever amount of address space the implementation decided to use internally. Sorry, but I assumed it meant the former at first. ... >>> Was this a good decision? Probably not! >> Sounds more like a bug (or two) to me than "a decision", but I don't >> know. > You said yourself that it is standards compliant ;) I have filed it as > a bug, but it is probably unlikely to be backported to current versions > of Mac OS X unless a case can be made that it is indeed a security > flaw. That's plausible. If you showed me a case where Python's list.sort() took cubic time, I'd certainly consider that to be "a bug", despite that nothing promises better behavior. If I wrote a malloc subsystem and somebody pointed out "did you know that when I malloc 1024**2+1 bytes, and then realloc(1), I lose the other megabyte forever?", I'd consider that to be "a bug" too (because, docs be damned, I wouldn't intentionally design a malloc subsystem with such behavior; and pymalloc does in fact copy bytes on a shrinking realloc in blocks it controls, whenever at least a quarter of the space is given back -- and it didn't at the start, and I considered that to be "a bug" when it was pointed out). > ... > Known case? No. Do I want to search Python application-space to find > one? No. Serious problems on a platform are usually well-known to users on that platform. For example, it was well-known that Python's list-growing strategy as of a few years ago fragmented address space horribly on Win9X. This was a C quality-of-implementation issue specific to that platform. It was eventually resolved by improving the list-growing strategy on all platforms -- although it's still the case that Win9X does worse on list-growing than other platforms, it's no longer a disaster for most list-growing apps on Win9X. If there's a problem with "overallocate then realloc() to cut back" on Darwin that affects many apps, then I'd expect Darwin users to know about that already -- lots of people have used Python on Macs since Python's beginning, "mysterious slowdowns" and "mysterious bloat" get noticed, and Darwin has been around for a while. .. >> There is no "choke point" for allocations in Python -- some places >> call the system realloc() directly. Maybe the latter matter on Darwin >> too, but maybe they don't. The scope of this hack spreads if they do. ... > In the case of Python, "some places" means "nowhere relevant". Four > standard library extension modules relevant to the platform use realloc > directly: > > _sre > Uses realloc only to grow buffers. > cPickle > Uses realloc only to grow buffers. > cStringIO > Uses realloc only to grow buffers. > regexpr: > Uses realloc only to grow buffers. Good! > If Zope doesn't use the allocator that Python gives it, then it can > deal with its own problems. I would expect most extensions to use > Python's allocator. I don't know. ... > They're [#ifdef's] also the only good way to deal with platform-specific > inconsistencies. In this specific case, it's not even possible to > determine if a particular allocator implementation is stupid or not > without at least using a platform-allocator-specific function to query > the size reserved by a given allocation. We've had bad experience on several platforms when passing large numbers to recv(). If that were addressed, it's unclear that Darwin realloc() behavior would remain a real issue. OTOH, it is clear that *just* worming around Darwin realloc() behavior won't help other platforms with problems in the same *immediate* area of bug 1092502. Gross over-allocation followed by a shrinking realloc() just isn't common in Python. sock_recv() is an exceptionally bad case. More typical is, e.g., fileobject.c's get_line(), where if "a line" exceed 100 characters the buffer keeps growing by 25% until there's enough room, then it's cut back once at the end. That typical use for shrinking realloc() just isn't going to be implicated in a real problem -- the over-allocation is always minor. > ... > There's obviously a tradeoff between copying lots of bytes and having > lots of memory go to waste. That should be taken into consideration > when considering how many pages could be returned to the allocator. > Note that we can ask the allocator how much memory an allocation has > actually reserved (which is usually somewhat larger than the amount you > asked it for) and how much memory an allocation will reserve for a > given size. An allocation resize wouldn't even show up as smaller > unless at least one page would be freed (for sufficiently large > allocations anyway, the minimum granularity is 16 bytes because it > guarantees that alignment). Obviously if you have a lot of pages > anyway, one page isn't a big deal, so we would probably only resort to > free()/memcpy() if some fair percentage of the total pages used by the > allocation could be rescued. > > If it does end up causing some real performance problems anyway, > there's always deeper hacks like using vm_copy(), a Darwin specific > function which will do copy-on-write instead (which only makes sense if > the allocation is big enough for this to actually be a performance > improvement). As above, I'm skeptical that there's a general problem worth addressing here, and am still under the possible illusion that the Mac developers will eventually change their realloc()'s behavior anyway. If you're convinced it's worth the bother, go for it. If you do, I strongly hope that it keys off a new platform-neutral symbol (say, Py_SHRINKING_REALLOC_COPIES) and avoids Darwin-specific implementation code. Then if it turns out that it is a broad problem (across apps or across platforms), everyone can benefit. PyObject_Realloc() seems the best place to put it. Unfortunately, for blocks obtained from the system malloc(), there is no portable way to find out how much excess was allocated in a release-build Python, so "avoids Darwin-specific implementation code" may be impossible to achieve. The more it *can't* be used on any platform other than this flavor of Darwin, the more inclined I am to advise just fixing the immediate problem (sock_recv's potentially unbounded over-allocation). From bob at redivi.com Mon Jan 3 23:40:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 3 23:40:47 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <1f7befae050103134942ab1696@mail.gmail.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> <1f7befae050103134942ab1696@mail.gmail.com> Message-ID: <7D3892F0-5DD8-11D9-ACB4-000A9567635C@redivi.com> On Jan 3, 2005, at 4:49 PM, Tim Peters wrote: > [Tim Peters] >>> Ya, I understood that. My conclusion was that Darwin's realloc() >>> implementation isn't production-quality. So it goes. > > [Bob Ippolito] >> Whatever that means. > > Well, it means what it said. The C standard says nothing about > performance metrics of any kind, and a production-quality > implementation of C requires very much more than just meeting what the > standard requires. The phrase "quality of implementation" is used in > the C Rationale (but not in the standard proper) to cover all such > issues. realloc() pragmatics are quality-of-implementation issues; > the accuracy of fp arithmetic is another (e.g., if you get back -666.0 > from the C 1.0 + 2.0, there's nothing in the standard to justify a > complaint). > >>>> free() can be called either explicitly, or implicitly by calling >>>> realloc() with a size larger than the size of the allocation. > > From later comments feigning outrage , I take it that "the size > of the allocation" here does not mean the specific number the user > passed to the previous malloc/realloc call, but means whatever amount > of address space the implementation decided to use internally. Sorry, > but I assumed it meant the former at first. Sorry for the confusion. >>>> Was this a good decision? Probably not! > >>> Sounds more like a bug (or two) to me than "a decision", but I don't >>> know. > >> You said yourself that it is standards compliant ;) I have filed it >> as >> a bug, but it is probably unlikely to be backported to current >> versions >> of Mac OS X unless a case can be made that it is indeed a security >> flaw. > > That's plausible. If you showed me a case where Python's list.sort() > took cubic time, I'd certainly consider that to be "a bug", despite > that nothing promises better behavior. If I wrote a malloc subsystem > and somebody pointed out "did you know that when I malloc 1024**2+1 > bytes, and then realloc(1), I lose the other megabyte forever?", I'd > consider that to be "a bug" too (because, docs be damned, I wouldn't > intentionally design a malloc subsystem with such behavior; and > pymalloc does in fact copy bytes on a shrinking realloc in blocks it > controls, whenever at least a quarter of the space is given back -- > and it didn't at the start, and I considered that to be "a bug" when > it was pointed out). I wouldn't equate "until free() is called" with "forever". But yes, I consider it a bug just as you do, and have reported it appropriately. Practically, since it exists in Mac OS X 10.2 and Mac OS X 10.3, and may not ever be fixed, we should at least consider it. >> ... >> Known case? No. Do I want to search Python application-space to find >> one? No. > > Serious problems on a platform are usually well-known to users on that > platform. For example, it was well-known that Python's list-growing > strategy as of a few years ago fragmented address space horribly on > Win9X. This was a C quality-of-implementation issue specific to that > platform. It was eventually resolved by improving the list-growing > strategy on all platforms -- although it's still the case that Win9X > does worse on list-growing than other platforms, it's no longer a > disaster for most list-growing apps on Win9X. It does take a long time to figure such weird behavior out though. I would have to guess that most people Python users on Darwin have been at it for less than 3 years. The number of people using Python on Darwin who have have written or used code that exercised this scenario are determined enough to track this sort of thing down is probably very small. > If there's a problem with "overallocate then realloc() to cut back" on > Darwin that affects many apps, then I'd expect Darwin users to know > about that already -- lots of people have used Python on Macs since > Python's beginning, "mysterious slowdowns" and "mysterious bloat" get > noticed, and Darwin has been around for a while. Most people on Mac OS X have a lot of memory, and Mac OS X generally does a good job about swapping in and out without causing much of a problem, so I'm personally not very surprised that it could go unnoticed this long. Google says: Results 1 - 10 of about 1,150 for (darwin OR Mac OR "OS X") AND MemoryError AND Python. Results 1 - 10 of about 942 for malloc vm_allocate failed. (0.73 seconds)? Of course, in both cases, not all of these can be attributed to realloc()'s implementation, but I'm sure some of them can, especially the Python ones! >> They're [#ifdef's] also the only good way to deal with >> platform-specific >> inconsistencies. In this specific case, it's not even possible to >> determine if a particular allocator implementation is stupid or not >> without at least using a platform-allocator-specific function to query >> the size reserved by a given allocation. > > We've had bad experience on several platforms when passing large > numbers to recv(). If that were addressed, it's unclear that Darwin > realloc() behavior would remain a real issue. OTOH, it is clear that > *just* worming around Darwin realloc() behavior won't help other > platforms with problems in the same *immediate* area of bug 1092502. > Gross over-allocation followed by a shrinking realloc() just isn't > common in Python. sock_recv() is an exceptionally bad case. More > typical is, e.g., fileobject.c's get_line(), where if "a line" exceed > 100 characters the buffer keeps growing by 25% until there's enough > room, then it's cut back once at the end. That typical use for > shrinking realloc() just isn't going to be implicated in a real > problem -- the over-allocation is always minor. What about for list objects that are big at some point, then progressively shrink, but happen to stick around for a while? An "event queue" that got clogged for some reason and then became stable? Dictionaries? Of course these potential problems are a lot less likely to happen. >> ... >> There's obviously a tradeoff between copying lots of bytes and having >> lots of memory go to waste. That should be taken into consideration >> when considering how many pages could be returned to the allocator. >> Note that we can ask the allocator how much memory an allocation has >> actually reserved (which is usually somewhat larger than the amount >> you >> asked it for) and how much memory an allocation will reserve for a >> given size. An allocation resize wouldn't even show up as smaller >> unless at least one page would be freed (for sufficiently large >> allocations anyway, the minimum granularity is 16 bytes because it >> guarantees that alignment). Obviously if you have a lot of pages >> anyway, one page isn't a big deal, so we would probably only resort to >> free()/memcpy() if some fair percentage of the total pages used by the >> allocation could be rescued. >> >> If it does end up causing some real performance problems anyway, >> there's always deeper hacks like using vm_copy(), a Darwin specific >> function which will do copy-on-write instead (which only makes sense >> if >> the allocation is big enough for this to actually be a performance >> improvement). > > As above, I'm skeptical that there's a general problem worth > addressing here, and am still under the possible illusion that the Mac > developers will eventually change their realloc()'s behavior anyway. > If you're convinced it's worth the bother, go for it. If you do, I > strongly hope that it keys off a new platform-neutral symbol (say, > Py_SHRINKING_REALLOC_COPIES) and avoids Darwin-specific implementation > code. Then if it turns out that it is a broad problem (across apps or > across platforms), everyone can benefit. PyObject_Realloc() seems the > best place to put it. Unfortunately, for blocks obtained from the > system malloc(), there is no portable way to find out how much excess > was allocated in a release-build Python, so "avoids Darwin-specific > implementation code" may be impossible to achieve. The more it > *can't* be used on any platform other than this flavor of Darwin, the > more inclined I am to advise just fixing the immediate problem > (sock_recv's potentially unbounded over-allocation). I'm pretty sure this kind of malloc functionality is very specific to Darwin and does not carry over to any other BSD. In order for an intelligent implementation, an equivalent of malloc_size() and malloc_good_size() is required. Unfortunately, despite the man page, malloc_good_size() is not declared in , however there is another, declared, way to get at that functionality (by poking into the malloc_introspection_t struct of the malloc_default_zone()). -bob From tim.peters at gmail.com Tue Jan 4 02:38:08 2005 From: tim.peters at gmail.com (Tim Peters) Date: Tue Jan 4 02:38:11 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <7D3892F0-5DD8-11D9-ACB4-000A9567635C@redivi.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> <1f7befae050103134942ab1696@mail.gmail.com> <7D3892F0-5DD8-11D9-ACB4-000A9567635C@redivi.com> Message-ID: <1f7befae05010317387667d8b1@mail.gmail.com> [Bob Ippolito] > ... > What about for list objects that are big at some point, then > progressively shrink, but happen to stick around for a while? An > "event queue" that got clogged for some reason and then became stable? It's less plausible that we''re going to see a lot of these simultaneously alive. It's possible, of course. Note that if we do, fiddling PyObject_Realloc() won't help: list resizing goes thru the PyMem_RESIZE() macro, which calls the platform realloc() directly in a release build (BTW, I suspect that when you were looking for realloc() calls, you were looking for the string "realloc(" -- but that's not the only spelling; we don't even have alphabetical choke points ). The list object itself goes thru Python's small-object allocator, which makes sense because a list object has a small fixed size independent of list length. Space for list elements is allocated seperately from the list object, and talks to the platform malloc/free/realloc directly (in release builds, via how the PyMem_XYZ macros resolve in release builds). > Dictionaries? They're not a potential problem here -- dict resizing (whether growing or shrinking) always proceeds by allocating new space for the dict guts, copying over elements from the original space, then freeing the original space. This is because the hash slot assigned to a key can change when the table size changes, and keeping collision chains straight is a real bitch if you try to do it in-place. IOW, there are implementation reasons for why CPython dicts will probably never use realloc(). > Of course these potential problems are a lot less likely to happen. I think so. Guido's suggestion to look at PyString_Resize (etc) instead could be a good one, since those methods know both the number of thingies (bytes, list elements, tuple elements, ...) currently allocated and the number of thingies being asked for. That could be exploited by a portable heuristic (like malloc+memcpy+free if the new number of thingies is at least a quarter less than the old number of thingies, else let realloc (however spelled) exercise its own judgment). Since list_resize() doesn't go thru pymalloc, that's the only clear way to worm around realloc() quirks for lists. From mahansen at adelphia.net Tue Jan 4 03:40:42 2005 From: mahansen at adelphia.net (Mike Hansen) Date: Tue Jan 4 03:40:48 2005 Subject: [Pythonmac-SIG] pychecker Message-ID: <41DA022A.1010903@adelphia.net> I'm having trouble getting pychecker to work in OS X 10.3.7 I installed it and don't recall seeing any error messages. In the terminal when I type pychecker myprogram.py -bash: pychecker: command not found I noticed in the pythonmac faq, it mentioned that many disutils packages install into /System/Library/Frameworks... and suggests creating a symbolic link in /usr/local/bin to the script. I'm learning unix/linux, so I'm not exactly fluent in unix/linux. I created the link from /usr/local/bin ln -s /System/Library/Frameworks/Python.framework/Versions/2.3/bin/pychecker pychecker Unfortunately, it will won't work. Did I create the link properly? Does anyone have any ideas on how I can get pychecker to work? Thanks, Mike From rkern at ucsd.edu Tue Jan 4 04:25:49 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue Jan 4 04:25:54 2005 Subject: [Pythonmac-SIG] pychecker In-Reply-To: <41DA022A.1010903@adelphia.net> References: <41DA022A.1010903@adelphia.net> Message-ID: <41DA0CBD.503@ucsd.edu> Mike Hansen wrote: > I'm having trouble getting pychecker to work in OS X 10.3.7 > > I installed it and don't recall seeing any error messages. > In the terminal when I type > pychecker myprogram.py > -bash: pychecker: command not found > > I noticed in the pythonmac faq, it mentioned that many disutils packages > install into /System/Library/Frameworks... and suggests creating a > symbolic link in /usr/local/bin to the script. > > I'm learning unix/linux, so I'm not exactly fluent in unix/linux. I > created the link from /usr/local/bin > ln -s > /System/Library/Frameworks/Python.framework/Versions/2.3/bin/pychecker > pychecker > > Unfortunately, it will won't work. Did I create the link properly? Probably. Are you sure /usr/local/bin is in your PATH? > Does anyone have any ideas on how I can get pychecker to work? Create a file in your home directory called .pydistutils.cfg (yes, the first dot is important). Put the following text (between the two #-comment lines) into it: # Begin File [install] install-purelib=/Library/Python/2.3 install-platlib=/Library/Python/2.3 install-scripts=/usr/local/bin install-data=/usr/local/share # End File Now reinstall pychecker. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From gvanrossum at gmail.com Mon Jan 3 17:15:24 2005 From: gvanrossum at gmail.com (Guido van Rossum) Date: Tue Jan 4 05:07:51 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> Message-ID: Coming late to this thread. I don't see the point of lying awake at night worrying about potential memory losses unless you've heard someone complain about it. As Tim has been trying to explain, here are plenty of other things in Python that we *could* speed up if there was a need; since every speedup uglifies the code somewhat, we'd end up with very ugly code if we did them all. Remember, don't optimize prematurely. Here's one theoretical reason why even with socket.recv() it probably doesn't matter in practice: the overallocated string will usually be freed as soon as the data has been parsed from it, and this will free the overallocation as well! OTOH, if you want to do more research, checking the usage patterns for StringRealloc and TupleRealloc would be useful. I could imagine code in either that makes a copy if the new size is less than some fraction of the old size. Most code that I recall writing using these tends to start with a guaranteed-to-fit overallocation, and a single resize at the end. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From bsder at mail.allcaps.org Mon Jan 3 22:26:12 2005 From: bsder at mail.allcaps.org (Andrew P. Lentvorski, Jr.) Date: Tue Jan 4 05:07:52 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <1f7befae050102231638b0d39d@mail.gmail.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> Message-ID: <1776760A-5DCE-11D9-A1A7-000A95C874EE@mail.allcaps.org> On Jan 2, 2005, at 11:16 PM, Tim Peters wrote: > [Bob Ippolito] >> However, it is our (in the "I know you use Windows but I am not the >> only >> one that uses Mac OS X sense) problem so long as Darwin is a supported >> platform, because it is highly unlikely that Apple will backport any >> "fix" to >> the allocator unless we can prove it has some security implications in >> software shipped with their OS. ... > > Is there any known case where Python performs poorly on this OS, for > this reason, other than the "pass giant numbers to recv() and then > shrink the string because we didn't get anywhere near that many bytes" > case? Claiming rampant performance problems should require evidence > too . Possibly. When using the stock btdownloadcurses.py from bitconjurer.org, I occasionally see a memory thrash on OS X. Normally I have to be in a mode where I am aggregating lots of small connections (10Kbps or less uploads) into a large download (10Mbps transfer rate on a >500MB file). When the file completes, Python sends OS X into a long-lasting spinning ball of death. It will emerge after about 10 minutes or so. I do not see this same behavior on Linux or FreeBSD. I never filed a bug because I can't reliably reproduce it (it is dependent upon the upload characteristics of the torrent swarm). However, it seems to fit the bug and diagnosis. -a From bob at redivi.com Tue Jan 4 05:13:21 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 4 05:13:30 2005 Subject: [Pythonmac-SIG] pychecker In-Reply-To: <41DA0CBD.503@ucsd.edu> References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> Message-ID: On Jan 3, 2005, at 10:25 PM, Robert Kern wrote: > Mike Hansen wrote: >> Does anyone have any ideas on how I can get pychecker to work? > > Create a file in your home directory called .pydistutils.cfg (yes, the > first dot is important). > > Put the following text (between the two #-comment lines) into it: > > # Begin File > [install] > install-purelib=/Library/Python/2.3 > install-platlib=/Library/Python/2.3 > install-scripts=/usr/local/bin > install-data=/usr/local/share > # End File > > Now reinstall pychecker. Do this instead: # Begin File [install] install-scripts=/usr/local/bin install-data=/usr/local/share # End File Screwing with purelib and platlib is a terrible idea if you ever have multiple versions of Python installed, because they will all use the same .pydistutils.cfg. The standard Python 2.3.0 already puts its purelib and platlib there anyway (indirectly via symlink, but it still goes there), so it's not ever going to actually do anything helpful. -bob From rkern at ucsd.edu Tue Jan 4 05:58:04 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue Jan 4 05:58:07 2005 Subject: [Pythonmac-SIG] pychecker In-Reply-To: References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> Message-ID: <41DA225C.3020506@ucsd.edu> Bob Ippolito wrote: > Do this instead: > > # Begin File > [install] > install-scripts=/usr/local/bin > install-data=/usr/local/share > # End File > > Screwing with purelib and platlib is a terrible idea if you ever have > multiple versions of Python installed, because they will all use the > same .pydistutils.cfg. The standard Python 2.3.0 already puts its > purelib and platlib there anyway (indirectly via symlink, but it still > goes there), so it's not ever going to actually do anything helpful. Okay. At some point, that symlink got blown away on my machine, so I put in the install-*lib entries. -- Robert Kern rkern@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 Jan 4 06:03:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 4 06:03:37 2005 Subject: [Pythonmac-SIG] pychecker In-Reply-To: <41DA225C.3020506@ucsd.edu> References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> <41DA225C.3020506@ucsd.edu> Message-ID: On Jan 3, 2005, at 11:58 PM, Robert Kern wrote: > Bob Ippolito wrote: > >> Do this instead: >> # Begin File >> [install] >> install-scripts=/usr/local/bin >> install-data=/usr/local/share >> # End File >> Screwing with purelib and platlib is a terrible idea if you ever have >> multiple versions of Python installed, because they will all use the >> same .pydistutils.cfg. The standard Python 2.3.0 already puts its >> purelib and platlib there anyway (indirectly via symlink, but it >> still goes there), so it's not ever going to actually do anything >> helpful. > > Okay. At some point, that symlink got blown away on my machine, so I > put in the install-*lib entries. If that symlink got blown away, /Library/Python/2.3 shouldn't have ended up in sys.path (unless you jigger that in elsewhere). wxPython is the likely culprit. Some of the wxPython installers seem to enjoy breaking Python :) I'm pretty sure this has been fixed since, though. -bob From rkern at ucsd.edu Tue Jan 4 07:11:54 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue Jan 4 07:11:57 2005 Subject: [Pythonmac-SIG] pychecker In-Reply-To: References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> <41DA225C.3020506@ucsd.edu> Message-ID: <41DA33AA.5040000@ucsd.edu> Bob Ippolito wrote: > > On Jan 3, 2005, at 11:58 PM, Robert Kern wrote: >> Okay. At some point, that symlink got blown away on my machine, so I >> put in the install-*lib entries. > > > If that symlink got blown away, /Library/Python/2.3 shouldn't have ended > up in sys.path (unless you jigger that in elsewhere). I don't *think* I did, and I can't think of any places to do so that I haven't already checked. > wxPython is the likely culprit. Some of the wxPython installers seem to > enjoy breaking Python :) I'm pretty sure this has been fixed since, > though. Yeah, I'm pretty sure that was the one, too. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From Jack.Jansen at cwi.nl Tue Jan 4 11:56:09 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 4 11:54:46 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <7D3892F0-5DD8-11D9-ACB4-000A9567635C@redivi.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> <1f7befae050103134942ab1696@mail.gmail.com> <7D3892F0-5DD8-11D9-ACB4-000A9567635C@redivi.com> Message-ID: <3DA96FE4-5E3F-11D9-A0C3-000A958D1666@cwi.nl> On 3 Jan 2005, at 23:40, Bob Ippolito wrote: > Most people on Mac OS X have a lot of memory, and Mac OS X generally > does a good job about swapping in and out without causing much of a > problem, so I'm personally not very surprised that it could go > unnoticed this long. *Except* when you're low on free disk space. 10.2 and before were really bad with this, usually hanging the machine, 10.3 is better but it's still pretty bad when compared to other unixen. It probably has something to do with the way OSX overcommits memory and swapspace, for which it apparently uses a different algorithm than FreeBSD or Linux. I wouldn't be surprised if the bittorrent problem report in this thread was due to being low on diskspace. And that could also be true for the original error report that sparked this discussion. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Tue Jan 4 12:25:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 4 12:25:55 2005 Subject: [Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations In-Reply-To: <3DA96FE4-5E3F-11D9-A0C3-000A958D1666@cwi.nl> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> <1f7befae050103134942ab1696@mail.gmail.com> <7D3892F0-5DD8-11D9-ACB4-000A9567635C@redivi.com> <3DA96FE4-5E3F-11D9-A0C3-000A958D1666@cwi.nl> Message-ID: <60DD4D4B-5E43-11D9-A787-000A9567635C@redivi.com> On Jan 4, 2005, at 5:56 AM, Jack Jansen wrote: > On 3 Jan 2005, at 23:40, Bob Ippolito wrote: >> Most people on Mac OS X have a lot of memory, and Mac OS X generally >> does a good job about swapping in and out without causing much of a >> problem, so I'm personally not very surprised that it could go >> unnoticed this long. > > *Except* when you're low on free disk space. 10.2 and before were > really bad with this, usually hanging the machine, 10.3 is better but > it's still pretty bad when compared to other unixen. It probably has > something to do with the way OSX overcommits memory and swapspace, for > which it apparently uses a different algorithm than FreeBSD or Linux. > > I wouldn't be surprised if the bittorrent problem report in this > thread was due to being low on diskspace. And that could also be true > for the original error report that sparked this discussion. I was able to trigger this bug with a considerable amount of free disk space using a laptop that has 1GB of RAM, although I did have to increase the buffer size from the given example quite a bit to get it to fail. After all, a 32-bit process can't have more than 4 GB of addressable memory. I am pretty sure that OS X is never supposed to overcommit memory. The disk thrashing probably has a lot to do with the fact that Mac OS X will grow and shrink its swap based on demand, rather than having a fixed size swap partition as is common on other unixen. I've never seen the problem myself, though. From what I remember about Linux, its malloc implementation merely increases the address space of a process. The actual allocation will happen when you try and access the memory, and if it's overcommitted things will fail in a bad way. -bob From Jack.Jansen at cwi.nl Tue Jan 4 14:09:29 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 4 14:09:50 2005 Subject: [Pythonmac-SIG] .pydistutils.cfg (was: pychecker) In-Reply-To: References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> Message-ID: Gosh, I'd never even heard of .pydistutils.cfg. I've added a note to the FAQ pointing to it. Then I looked at the distutils code, and noticed that there's also an optional distutils.cfg inside the package. So that made me wonder: we could install a symlink in /System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that points to, say, /Library/Python/2.3/distutils.cfg, and put an (admin-editable) file there that directs scripts tot the right place system wide (/usr/local/bin by default, probably). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Tue Jan 4 14:42:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 4 14:42:26 2005 Subject: [Pythonmac-SIG] .pydistutils.cfg (was: pychecker) In-Reply-To: References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> Message-ID: <6AA9A413-5E56-11D9-A950-000A9567635C@redivi.com> On Jan 4, 2005, at 8:09 AM, Jack Jansen wrote: > I'd never even heard of .pydistutils.cfg. I've added a note to the FAQ > pointing to it. It has some more features in Python 2.4, you can use it to add new build command packages to distutils out-of-tree (like py2app, bdist_mpkg, etc.). Of course, very few distutils extensions are implemented in away that is compatible with this new feature, but it's there and I'll probably end up making py2app and bdist_mpkg compatible. > Then I looked at the distutils code, and noticed that there's also an > optional distutils.cfg inside the package. So that made me wonder: we > could install a symlink in > /System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that > points to, say, /Library/Python/2.3/distutils.cfg, and put an > (admin-editable) file there that directs scripts tot the right place > system wide (/usr/local/bin by default, probably). +1 on the idea +1 for /usr/local/bin as the "right place" Not so sure about install-data pointing to /usr/local/share (earlier on in the thread), because some packages might try and locate their data files using means other than distutils (sys.prefix relative). I have never seen one of these packages, but god knows one has to exist. In my experience, most packages seem to use install-data for documentation and maybe example code if anything. -bob From bob at redivi.com Tue Jan 4 14:51:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 4 14:51:12 2005 Subject: [Pythonmac-SIG] .pydistutils.cfg (was: pychecker) In-Reply-To: <6AA9A413-5E56-11D9-A950-000A9567635C@redivi.com> References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> <6AA9A413-5E56-11D9-A950-000A9567635C@redivi.com> Message-ID: On Jan 4, 2005, at 8:42 AM, Bob Ippolito wrote: > On Jan 4, 2005, at 8:09 AM, Jack Jansen wrote: > >> I'd never even heard of .pydistutils.cfg. I've added a note to the >> FAQ pointing to it. > > It has some more features in Python 2.4, you can use it to add new > build command packages to distutils out-of-tree (like py2app, > bdist_mpkg, etc.). Of course, very few distutils extensions are > implemented in away that is compatible with this new feature, but it's > there and I'll probably end up making py2app and bdist_mpkg > compatible. > >> Then I looked at the distutils code, and noticed that there's also an >> optional distutils.cfg inside the package. So that made me wonder: we >> could install a symlink in >> /System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that >> points to, say, /Library/Python/2.3/distutils.cfg, and put an >> (admin-editable) file there that directs scripts tot the right place >> system wide (/usr/local/bin by default, probably). > > +1 on the idea > +1 for /usr/local/bin as the "right place" > > Not so sure about install-data pointing to /usr/local/share (earlier > on in the thread), because some packages might try and locate their > data files using means other than distutils (sys.prefix relative). I > have never seen one of these packages, but god knows one has to exist. > In my experience, most packages seem to use install-data for > documentation and maybe example code if anything. Another thing that would be nice is to have some admin-writable place to put header files (in addition to Python's own headers) too. But that would require a patch to distutils and might need to happen in the 2.5 tree. -bob From ronaldoussoren at mac.com Tue Jan 4 15:18:54 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue Jan 4 15:18:55 2005 Subject: [Pythonmac-SIG] .pydistutils.cfg (was: pychecker) In-Reply-To: References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> <6AA9A413-5E56-11D9-A950-000A9567635C@redivi.com> Message-ID: <9087DB04-5E5B-11D9-85EE-000D93AD379E@mac.com> On 4-jan-05, at 14:51, Bob Ippolito wrote: > > On Jan 4, 2005, at 8:42 AM, Bob Ippolito wrote: > >> On Jan 4, 2005, at 8:09 AM, Jack Jansen wrote: >> >>> I'd never even heard of .pydistutils.cfg. I've added a note to the >>> FAQ pointing to it. >> >> It has some more features in Python 2.4, you can use it to add new >> build command packages to distutils out-of-tree (like py2app, >> bdist_mpkg, etc.). Of course, very few distutils extensions are >> implemented in away that is compatible with this new feature, but >> it's there and I'll probably end up making py2app and bdist_mpkg >> compatible. >> >>> Then I looked at the distutils code, and noticed that there's also >>> an optional distutils.cfg inside the package. So that made me >>> wonder: we could install a symlink in >>> /System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that >>> points to, say, /Library/Python/2.3/distutils.cfg, and put an >>> (admin-editable) file there that directs scripts tot the right place >>> system wide (/usr/local/bin by default, probably). >> >> +1 on the idea >> +1 for /usr/local/bin as the "right place" same here. >> >> Not so sure about install-data pointing to /usr/local/share (earlier >> on in the thread), because some packages might try and locate their >> data files using means other than distutils (sys.prefix relative). I >> have never seen one of these packages, but god knows one has to >> exist. In my experience, most packages seem to use install-data for >> documentation and maybe example code if anything. > > Another thing that would be nice is to have some admin-writable place > to put header files (in addition to Python's own headers) too. But > that would require a patch to distutils and might need to happen in > the 2.5 tree. install-headers in distutils.cfg + a patch to the Makefile should do it, e.g. set install-headers to /Library/Python/2.3/Headers and add '-I/Library/Python/2.3/Headers' to CPPFLAGS in config/Makefile. Ronald From whamoo at rknet.it Tue Jan 4 19:20:18 2005 From: whamoo at rknet.it (whamoo) Date: Tue Jan 4 19:19:18 2005 Subject: [Pythonmac-SIG] Some question about pyobjc and creating nib based application... Message-ID: <49B825A8-5E7D-11D9-BB00-000A95C62238@rknet.it> Hello, There's somethings i cannot understand about creating nib based application, Ok I start interface builder, build gui, create outlet, create action, saving, create python file starting by the nib, and having a thing like this: ---------------------------------------------- import objc from Foundation import * from AppKit import * from PyObjCTools import NibClassBuilder, AppHelper NibClassBuilder.extractClasses("MainMenu") # class defined in gino.nib class finestra(NibClassBuilder.AutoBaseClass): # the actual base class is NSObject # The following outlets are added to the class: # button # label def change_(self, sender): self.label.setStringValue_("Prova") if __name__ == "__main__": AppHelper.runEventLoop() ---------------------------------------------- Ok, finestra is the base class and all works, but why is the base class? if i create more class?? I've tried xcode template, but if I modify the AppDelegate nib and add the function in python file, it give me this error: Could not connect the action change_: to target of class provaDocument And i don't know why =P I need to know what is the base class, i can chose? There's somethings that I probably miss, someone can help? Thanks a lot. Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From bob at redivi.com Tue Jan 4 19:33:33 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 4 19:33:45 2005 Subject: [Pythonmac-SIG] Some question about pyobjc and creating nib based application... In-Reply-To: <49B825A8-5E7D-11D9-BB00-000A95C62238@rknet.it> References: <49B825A8-5E7D-11D9-BB00-000A95C62238@rknet.it> Message-ID: <238F301C-5E7F-11D9-A950-000A9567635C@redivi.com> On Jan 4, 2005, at 1:20 PM, whamoo wrote: > Hello, > > There's somethings i cannot understand about creating nib based > application, > Ok I start interface builder, build gui, create outlet, create action, > saving, create python file starting by the nib, and having a thing > like this: > > ---------------------------------------------- > > import objc > from Foundation import * > from AppKit import * > from PyObjCTools import NibClassBuilder, AppHelper > > > NibClassBuilder.extractClasses("MainMenu") > > > # class defined in gino.nib > class finestra(NibClassBuilder.AutoBaseClass): > # the actual base class is NSObject > # The following outlets are added to the class: > # button > # label > > def change_(self, sender): > self.label.setStringValue_("Prova") > > > > if __name__ == "__main__": > AppHelper.runEventLoop() > > ---------------------------------------------- > > Ok, finestra is the base class and all works, but why is the base > class? if i create more class?? BTW: You should name your classes LikeThis, it is both Python and Objective-C convention. finestra is not "the base class". When you use NibClassBuilder.AutoBaseClass, you are saying "ask the nib what my base class is". For more information, see > I've tried xcode template, but if I modify the AppDelegate nib and add > the function in python file, it give me this error: > > Could not connect the action change_: to target of class provaDocument Did you actually write "change_:" as the selector? That's not how it works. Underscores are used from Python and colons are used from Objective-C. Maybe you should read . The selector should be named "change:" in this case. Also, your source example does not define any class named "provaDocument". > And i don't know why =P Did you read the documentation? I spent a lot of time on it before the 1.2 release ;) > I need to know what is the base class, i can chose? There's somethings > that I probably miss, someone can help? Hopefully this question will be answered by the referenced documentation... -bob From rswerdlow at transpose.com Tue Jan 4 20:44:15 2005 From: rswerdlow at transpose.com (Bob Swerdlow) Date: Tue Jan 4 20:44:30 2005 Subject: [Pythonmac-SIG] Python 2.3->2.4 "compatibility" package for Mac OS X 10.2 Message-ID: <05ed01c4f295$d2c596f0$046fa8c0@RSWERDLOW800> Is there a Mac OS X 10.2-compatible installer for the Python 2.3->2.4 "compatibility" package? When I double-click on the package from http://undefined.org/python/Python23Compat.zip it tells me that Mac OS X 10.3 is required. Thanks! - Bob Swerdlow From Jack.Jansen at cwi.nl Tue Jan 4 22:17:35 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 4 22:17:22 2005 Subject: [Pythonmac-SIG] .pydistutils.cfg (was: pychecker) In-Reply-To: <6AA9A413-5E56-11D9-A950-000A9567635C@redivi.com> References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> <6AA9A413-5E56-11D9-A950-000A9567635C@redivi.com> Message-ID: <0DFBCC60-5E96-11D9-BB20-000D934FF6B4@cwi.nl> On 4-jan-05, at 14:42, Bob Ippolito wrote: > On Jan 4, 2005, at 8:09 AM, Jack Jansen wrote: > >> I'd never even heard of .pydistutils.cfg. I've added a note to the >> FAQ pointing to it. > > It has some more features in Python 2.4, you can use it to add new > build command packages to distutils out-of-tree (like py2app, > bdist_mpkg, etc.). Of course, very few distutils extensions are > implemented in away that is compatible with this new feature, but it's > there and I'll probably end up making py2app and bdist_mpkg > compatible. Interesting... Although: you only need py2app and bdist_mpkg on the supplier-side (right?), so it doesn't really buy us all that much except a bit of convenience. >> Then I looked at the distutils code, and noticed that there's also an >> optional distutils.cfg inside the package. So that made me wonder: we >> could install a symlink in >> /System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that >> points to, say, /Library/Python/2.3/distutils.cfg, and put an >> (admin-editable) file there that directs scripts tot the right place >> system wide (/usr/local/bin by default, probably). > > +1 on the idea > +1 for /usr/local/bin as the "right place" > > Not so sure about install-data pointing to /usr/local/share (earlier > on in the thread), because some packages might try and locate their > data files using means other than distutils (sys.prefix relative). Yeah, I was wondering about that one too. I'll leave it out, if the end user wants it s/he can edit the file. > Another thing that would be nice is to have some admin-writable place > to put header files (in addition to Python's own headers) too. But > that would require a patch to distutils and might need to happen in > the 2.5 tree. [EVIL GRIN] What happens if we set both "include_dirs" and "headers" to, say, /Library/Python/2.3/python-includes in distutils.cfg? We'd need a bit of extra glue for PackMan binary installs (so it sends include files there too), but if this would cause include files to be installed there *and* that directory added to the -I flags we'd be all set, I think... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Tue Jan 4 22:30:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 4 22:30:35 2005 Subject: [Pythonmac-SIG] .pydistutils.cfg (was: pychecker) In-Reply-To: <0DFBCC60-5E96-11D9-BB20-000D934FF6B4@cwi.nl> References: <41DA022A.1010903@adelphia.net> <41DA0CBD.503@ucsd.edu> <6AA9A413-5E56-11D9-A950-000A9567635C@redivi.com> <0DFBCC60-5E96-11D9-BB20-000D934FF6B4@cwi.nl> Message-ID: On Jan 4, 2005, at 4:17 PM, Jack Jansen wrote: > On 4-jan-05, at 14:42, Bob Ippolito wrote: > >> On Jan 4, 2005, at 8:09 AM, Jack Jansen wrote: >> >>> I'd never even heard of .pydistutils.cfg. I've added a note to the >>> FAQ pointing to it. >> >> It has some more features in Python 2.4, you can use it to add new >> build command packages to distutils out-of-tree (like py2app, >> bdist_mpkg, etc.). Of course, very few distutils extensions are >> implemented in away that is compatible with this new feature, but >> it's there and I'll probably end up making py2app and bdist_mpkg >> compatible. > > Interesting... Although: you only need py2app and bdist_mpkg on the > supplier-side (right?), so it doesn't really buy us all that much > except a bit of convenience. If you want to create redistributable Mac applications, even "applets", then you are a "supplier". So I think it does buy *something* in this case, but not much. It saves you a line or two per setup.py, because right now py2app and bdist_mpkg jigger themselves into distutils by monkeypatch on import like py2exe does. >> Another thing that would be nice is to have some admin-writable place >> to put header files (in addition to Python's own headers) too. But >> that would require a patch to distutils and might need to happen in >> the 2.5 tree. > > [EVIL GRIN] What happens if we set both "include_dirs" and "headers" > to, say, /Library/Python/2.3/python-includes in distutils.cfg? We'd > need a bit of extra glue for PackMan binary installs (so it sends > include files there too), but if this would cause include files to be > installed there *and* that directory added to the -I flags we'd be all > set, I think... If the person who created the package had it set that way, it would already work like that.. since it isn't done by symlink, it should show up in what bdist_dumb will create. -bob From whamoo at rknet.it Wed Jan 5 01:42:18 2005 From: whamoo at rknet.it (whamoo) Date: Wed Jan 5 01:41:18 2005 Subject: [Pythonmac-SIG] Some question about pyobjc and creating nib based application... In-Reply-To: <238F301C-5E7F-11D9-A950-000A9567635C@redivi.com> References: <49B825A8-5E7D-11D9-BB00-000A95C62238@rknet.it> <238F301C-5E7F-11D9-A950-000A9567635C@redivi.com> Message-ID: On 04/gen/05, at 19:33, Bob Ippolito wrote: >> I've tried xcode template, but if I modify the AppDelegate nib and >> add the function in python file, it give me this error: >> >> Could not connect the action change_: to target of class provaDocument > > Did you actually write "change_:" as the selector? That's not how it > works. Underscores are used from Python and colons are used from > Objective-C. Maybe you should read > . The selector should be > named "change:" in this case. Also, your source example does not > define any class named "provaDocument". Sorry, my mail was a little confusing, I'm able to build working program with nib starting by interface builder, in this case all works fine, no problem pyobjc is great, but I'm not able to use xcode template, because I'm so stupid.... Step by step: I create a new cocoa-python application "hello world" open MainMenu.nib click on window put in the windows a button and a label ok, then there is a helloworldAppDelegate class in IB and a helloworldAppDelegate.py in xcode in IB i add two outlet and change: action to helloworldAppDelegate, connect the two outlet to the class and the action to the button. Save the interface Go to helloworldAppDelegate.py, inside it i found: from Foundation import NSLog from PyObjCTools import NibClassBuilder NibClassBuilder.extractClasses("MainMenu") class provaAppDelegate(NibClassBuilder.AutoBaseClass): def applicationDidFinishLaunching_(self, aNotification): NSLog( "Application did finish launching." ) I have added: def change_(self, sender): print "hello" Build all, launch and read this: Could not connect the action change: to target of class helloworldAppDelegate Then I hit the wall with my face a lot of time.... The same thing using only IB work fine =) So, where is my stupid error? I've read the documentation =) Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2552 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050105/06f2cb1a/attachment.bin From bob at redivi.com Wed Jan 5 01:57:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 5 01:57:53 2005 Subject: [Pythonmac-SIG] Some question about pyobjc and creating nib based application... In-Reply-To: References: <49B825A8-5E7D-11D9-BB00-000A95C62238@rknet.it> <238F301C-5E7F-11D9-A950-000A9567635C@redivi.com> Message-ID: On Jan 4, 2005, at 7:42 PM, whamoo wrote: > On 04/gen/05, at 19:33, Bob Ippolito wrote: >>> I've tried xcode template, but if I modify the AppDelegate nib and >>> add the function in python file, it give me this error: >>> >>> Could not connect the action change_: to target of class >>> provaDocument >> >> Did you actually write "change_:" as the selector? That's not how it >> works. Underscores are used from Python and colons are used from >> Objective-C. Maybe you should read >> . The selector should >> be named "change:" in this case. Also, your source example does not >> define any class named "provaDocument". > > Sorry, my mail was a little confusing, I'm able to build working > program with nib starting by interface builder, in this case all works > fine, no problem pyobjc is great, but I'm not able to use xcode > template, because I'm so stupid.... > > Step by step: > > I create a new cocoa-python application "hello world" > open MainMenu.nib > click on window > put in the windows a button and a label > > ok, then there is a helloworldAppDelegate class in IB and a > helloworldAppDelegate.py in xcode > in IB i add two outlet and change: action to helloworldAppDelegate, > connect the two outlet to the class and the action to the button. > Save the interface > Go to helloworldAppDelegate.py, inside it i found: > > from Foundation import NSLog > from PyObjCTools import NibClassBuilder > > NibClassBuilder.extractClasses("MainMenu") > class provaAppDelegate(NibClassBuilder.AutoBaseClass): > def applicationDidFinishLaunching_(self, aNotification): > NSLog( "Application did finish launching." ) > > I have added: > def change_(self, sender): > print "hello" > > Build all, launch and read this: > > Could not connect the action change: to target of class > helloworldAppDelegate Well the class names you are talking about are different from the class name defined in that Python file. Where the heck is this "prova" coming from? I have no idea what you are doing or not doing. I am sorry but I do not know how to help you. Note that there was a bug at some point with Xcode projects that have a space in their name, but I thought that got fixed. I rarely ever use the Xcode template personally, they mostly just get in my way and cause extra maintenance hassle. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2854 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050104/b4a473b9/attachment.bin From mahansen at adelphia.net Wed Jan 5 02:56:45 2005 From: mahansen at adelphia.net (Mike Hansen) Date: Wed Jan 5 02:56:48 2005 Subject: [Pythonmac-SIG] pychecker In-Reply-To: <20050104110143.00FD81E4002@bag.python.org> References: <20050104110143.00FD81E4002@bag.python.org> Message-ID: <41DB495D.4070005@adelphia.net> > > Subject: > Re: [Pythonmac-SIG] pychecker > From: > Bob Ippolito > Date: > Mon, 3 Jan 2005 23:13:21 -0500 > To: > Robert Kern > > To: > Robert Kern > CC: > pythonmac-sig@python.org > > > > On Jan 3, 2005, at 10:25 PM, Robert Kern wrote: > >> Mike Hansen wrote: >> >>> Does anyone have any ideas on how I can get pychecker to work? >> >> >> Create a file in your home directory called .pydistutils.cfg (yes, >> the first dot is important). >> >> Put the following text (between the two #-comment lines) into it: >> >> # Begin File >> [install] >> install-purelib=/Library/Python/2.3 >> install-platlib=/Library/Python/2.3 >> install-scripts=/usr/local/bin >> install-data=/usr/local/share >> # End File >> >> Now reinstall pychecker. > > > Do this instead: > > # Begin File > [install] > install-scripts=/usr/local/bin > install-data=/usr/local/share > # End File > > Screwing with purelib and platlib is a terrible idea if you ever have > multiple versions of Python installed, because they will all use the > same .pydistutils.cfg. The standard Python 2.3.0 already puts its > purelib and platlib there anyway (indirectly via symlink, but it still > goes there), so it's not ever going to actually do anything helpful. > > -bob > > > > ------------------------------------------------------------------------ Argh.../usr/local/bin wasn't in my path. I also did the .pydistutils.cfg. Reinstalled pychecker, and it works now. Thanks for the help. Mike From bob at redivi.com Wed Jan 5 03:55:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 5 03:55:59 2005 Subject: [Pythonmac-SIG] Some question about pyobjc and creating nib based application... In-Reply-To: <30FFD34C-5EB7-11D9-BB00-000A95C62238@rknet.it> References: <49B825A8-5E7D-11D9-BB00-000A95C62238@rknet.it> <238F301C-5E7F-11D9-A950-000A9567635C@redivi.com> <30FFD34C-5EB7-11D9-BB00-000A95C62238@rknet.it> Message-ID: <50591C4C-5EC5-11D9-9DC0-000A9567635C@redivi.com> On Jan 4, 2005, at 8:14 PM, whamoo wrote: > > On 05/gen/05, at 01:57, Bob Ippolito wrote: >>> >>> from Foundation import NSLog >>> from PyObjCTools import NibClassBuilder >>> >>> NibClassBuilder.extractClasses("MainMenu") >>> class provaAppDelegate(NibClassBuilder.AutoBaseClass): >>> def applicationDidFinishLaunching_(self, aNotification): >>> NSLog( "Application did finish launching." ) >>> >>> I have added: >>> def change_(self, sender): >>> print "hello" >>> >>> Build all, launch and read this: >>> >>> Could not connect the action change: to target of class >>> helloworldAppDelegate >> >> Well the class names you are talking about are different from the >> class name defined in that Python file. Where the heck is this >> "prova" coming from? I have no idea what you are doing or not doing. >> I am sorry but I do not know how to help you. >> >> Note that there was a bug at some point with Xcode projects that have >> a space in their name, but I thought that got fixed. I rarely ever >> use the Xcode template personally, they mostly just get in my way and >> cause extra maintenance hassle. > > Ok, i've find the problem, but look very strange, i've deleted this > two line: >>> def applicationDidFinishLaunching_(self, aNotification): >>> NSLog( "Application did finish launching." ) > > And all works fine, but now, i can't add new function to the class > because xcode tell me indentation error (i'm sure there isn't), bof, > maybe template and xcode integration have some bug, thanks a lot for > support. This is not a bug in the integration, and it *is* an indentation error. You are mixing spaces and tabs. Don't do that. Turn tabs off in Xcode. I guess we should document this somewhere. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2364 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050104/545046c4/attachment.bin From delza at livingcode.org Wed Jan 5 07:19:58 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Jan 5 07:20:08 2005 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] missing method? Message-ID: You need to replace colons in the Cocoa method with underscores in Python, so [dictionaryWithContentsOfFile: @"/path"] // My ObjC may be off a bit, but something like this becomes dictionaryWithContentsOfFile_(u"/path") # note underscore --Dethe As for intelligent machines taking over, a machine does not have to be intelligent to conquer the world; it merely has to be desireable. We've already lost a war to a synthetic species--the automobile--that has killed more than 15 million people; occupied all of our cities except Venice, Italy; and continues to exact crushing taxes in resources, wealth, and time from over half the planet--and everybody wants one. --Grant Thompson -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050104/7a62c382/smime-0001.bin From whamoo at rknet.it Wed Jan 5 10:31:39 2005 From: whamoo at rknet.it (whamoo) Date: Wed Jan 5 10:30:38 2005 Subject: [Pythonmac-SIG] Some question about pyobjc and creating nib based application... In-Reply-To: <50591C4C-5EC5-11D9-9DC0-000A9567635C@redivi.com> References: <49B825A8-5E7D-11D9-BB00-000A95C62238@rknet.it> <238F301C-5E7F-11D9-A950-000A9567635C@redivi.com> <30FFD34C-5EB7-11D9-BB00-000A95C62238@rknet.it> <50591C4C-5EC5-11D9-9DC0-000A9567635C@redivi.com> Message-ID: <9A1890BE-5EFC-11D9-BB00-000A95C62238@rknet.it> On 05/gen/05, at 03:55, Bob Ippolito wrote: > This is not a bug in the integration, and it *is* an indentation > error. You are mixing spaces and tabs. Don't do that. Turn tabs off > in Xcode. I guess we should document this somewhere. Oh yeah, turning off tab works =) Thanks a lot, xcode is a great ide, but i doesn't use py2app to create bundle, so i haven't standalone application, back to use IB and the good old vim ;-) Very nice works on pyobjc1.2 thanks for all. Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From whamoo at rknet.it Wed Jan 5 11:33:51 2005 From: whamoo at rknet.it (whamoo) Date: Wed Jan 5 11:32:49 2005 Subject: [Pythonmac-SIG] [May be OT] A question about creating a nib (cocoa specific) Message-ID: <4A923628-5F05-11D9-BB00-000A95C62238@rknet.it> Hello, When I create application with cocoa and python, also using the tutorial on the pyobjc site, when i it cmd-w or click on the reb x button my application disappear but don't quit, the most of macosx application like itunes, ical, ecc... when you click on the dock icon redisplay the graphics interface, my app doesn't... In which way i obtain this? I've looked at the example in the pyobjc documentation, but (es: class browser) have the same problem, the only application that don't do this are NSDocument based application. I must use this class? If i want to create a normal application that on click on red button disappear and then clicking on the dock icon reappear? I'm a totally newbie to cocoa programming and I'm little confused Thanks a lot Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From micktwomey at gmail.com Wed Jan 5 11:33:39 2005 From: micktwomey at gmail.com (Michael Twomey) Date: Wed Jan 5 11:33:42 2005 Subject: [Pythonmac-SIG] Problems with matplotlib In-Reply-To: <49966601-5DCD-11D9-951F-000A95A06CF6@nasa.gov> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> <49966601-5DCD-11D9-951F-000A95A06CF6@nasa.gov> Message-ID: <50a522ca050105023315b52db5@mail.gmail.com> (forgot to reply to list) Hi, I'm guessing that you've wound up with a mix of a newer matplotlib py files and older matplotlib .so extensions, since polar stuff is a relatively new part of matplotlib AFAIK. Try completely removing /Library/Python/matplotlib/ and re-installing. As an alternative to installing it yourself, you can use the fink version (http://fink.sourceforge.net/) which is kept up to date. After installing fink just do "fink install matplotlib-py23" and use /sw/bin/python2.3 to run matplotlib stuff. I prefer using the fink version of python for this kind of stuff, it's easier to manage. Michael On Mon, 3 Jan 2005 13:20:26 -0800, Larry Meyn wrote: > Has anyone had problems with installing and using matplotlib under OS X? > > I've tried installing the last couple of versions and while > installation goes smoothly it crashes when I try to import from pylab, > as shown below > > >>> from pylab import * > Traceback (most recent call last): > File "", line 1, in ? > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/pylab.py", line 1, in ? > from matplotlib.pylab import * > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/matplotlib/pylab.py", line 194, in ? > from axes import Axes, PolarAxes > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/matplotlib/axes.py", line 16, in ? > from artist import Artist > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/matplotlib/artist.py", line 3, in ? > from transforms import identity_transform > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/matplotlib/transforms.py", line 189, in ? > from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY > ImportError: cannot import name POLAR > > I running python 2.3 on OS X 10.3.7 with Numeric 23.6 installed. Any > help with this would be greatly appreciated. > > Larry > > Larry Meyn > Aerospace Operations Modeling Office > NASA Ames Research Center > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Larry.A.Meyn at nasa.gov Wed Jan 5 12:24:44 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Jan 5 12:24:58 2005 Subject: [Pythonmac-SIG] Problems with matplotlib In-Reply-To: <50a522ca0501050227172a03c8@mail.gmail.com> References: <41D823FF-5D31-11D9-8981-000A9567635C@redivi.com> <1f7befae05010221134a94eccd@mail.gmail.com> <1f7befae050102231638b0d39d@mail.gmail.com> <49966601-5DCD-11D9-951F-000A95A06CF6@nasa.gov> <50a522ca0501050227172a03c8@mail.gmail.com> Message-ID: <66407D4E-5F0C-11D9-AC21-000D93680688@nasa.gov> Michael, Thanks for taking the time to reply to my question. You are the second person to suggest completely removing the old libraries and re-installing, which in fact was the needed solution to the problem. As for your suggestion to use fink, it is something that I have been avoiding as it doesn't always seem to play well with standard installations. I was very tempted to use fink in order to get a working matplotlib, as installing freetype2, libpng and zlib from src seemed to be a rather daunting task. Fortunately, the i-Installer (http://ii2.sourceforge.net/) distribution application for TeX on OS X is a viable alternative for installing freetype2, libpng and zlib. Larry On Jan 5, 2005, at 2:27 AM, Michael Twomey wrote: > Hi, > > I'm guessing that you've wound up with a mix of a newer matplotlib py > files and older matplotlib .so extensions, since polar stuff is a > relatively new part of matplotlib AFAIK. Try completely removing > /Library/Python/matplotlib/ and re-installing. > > As an alternative to installing it yourself, you can use the fink > version (http://fink.sourceforge.net/) which is kept up to date. After > installing fink just do "fink install matplotlib-py23" and use > /sw/bin/python2.3 to run matplotlib stuff. I prefer using the fink > version of python for this kind of stuff, it's easier to manage. > > Michael > > On Mon, 3 Jan 2005 13:20:26 -0800, Larry Meyn > wrote: >> Has anyone had problems with installing and using matplotlib under OS >> X? >> >> I've tried installing the last couple of versions and while >> installation goes smoothly it crashes when I try to import from pylab, >> as shown below >> >>>>> from pylab import * >> Traceback (most recent call last): >> File "", line 1, in ? >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/pylab.py", line 1, in ? >> from matplotlib.pylab import * >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/matplotlib/pylab.py", line 194, in ? >> from axes import Axes, PolarAxes >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/matplotlib/axes.py", line 16, in ? >> from artist import Artist >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/matplotlib/artist.py", line 3, in ? >> from transforms import identity_transform >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/matplotlib/transforms.py", line 189, in ? >> from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY >> ImportError: cannot import name POLAR >> >> I running python 2.3 on OS X 10.3.7 with Numeric 23.6 installed. Any >> help with this would be greatly appreciated. >> >> Larry >> >> Larry Meyn >> Aerospace Operations Modeling Office >> NASA Ames Research Center >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > From ronaldoussoren at mac.com Wed Jan 5 12:46:12 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Jan 5 12:46:10 2005 Subject: [Pythonmac-SIG] [May be OT] A question about creating a nib (cocoa specific) In-Reply-To: <4A923628-5F05-11D9-BB00-000A95C62238@rknet.it> References: <4A923628-5F05-11D9-BB00-000A95C62238@rknet.it> Message-ID: <65BC73DC-5F0F-11D9-85EE-000D93AD379E@mac.com> On 5-jan-05, at 11:33, whamoo wrote: > Hello, > > When I create application with cocoa and python, also using the > tutorial on the pyobjc site, when i it cmd-w or click on the reb x > button my application disappear but don't quit, the most of macosx > application like itunes, ical, ecc... when you click on the dock icon > redisplay the graphics interface, my app doesn't... That's a generic Cocoa question. To close the application when your main window is closed you should implement a windowWillClose_ method that exists the application. If you implement a document-based application the application will automaticly open a new window when no windows are open and you click on the dock icon for the application. There is probably a callback that will be called when someone clicks on the document icon (probably a delegate method for NSApplication). Ronald From whamoo at rknet.it Wed Jan 5 12:52:27 2005 From: whamoo at rknet.it (whamoo) Date: Wed Jan 5 12:51:29 2005 Subject: [Pythonmac-SIG] [May be OT] A question about creating a nib (cocoa specific) In-Reply-To: <65BC73DC-5F0F-11D9-85EE-000D93AD379E@mac.com> References: <4A923628-5F05-11D9-BB00-000A95C62238@rknet.it> <65BC73DC-5F0F-11D9-85EE-000D93AD379E@mac.com> Message-ID: <45C29356-5F10-11D9-BB00-000A95C62238@rknet.it> On 05/gen/05, at 12:46, Ronald Oussoren wrote: >> >> When I create application with cocoa and python, also using the >> tutorial on the pyobjc site, when i it cmd-w or click on the reb x >> button my application disappear but don't quit, the most of macosx >> application like itunes, ical, ecc... when you click on the dock icon >> redisplay the graphics interface, my app doesn't... > > That's a generic Cocoa question. > > To close the application when your main window is closed you should > implement a windowWillClose_ method that exists the application. > > If you implement a document-based application the application will > automaticly open a new window when no windows are open and you click > on the dock icon for the application. There is probably a callback > that will be called when someone clicks on the document icon (probably > a delegate method for NSApplication). Ok, but in wich way I can implement a document based application starting by interface builder? Creating a new subclass of NSDocument, instantiate it, add outlet, action, creating code, but the problem don't solve =P Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From whamoo at rknet.it Wed Jan 5 16:49:52 2005 From: whamoo at rknet.it (whamoo) Date: Wed Jan 5 16:48:52 2005 Subject: [Pythonmac-SIG] applicationShouldHandleReopen_ (what i must put into it???) Message-ID: <6FF2B13E-5F31-11D9-BB00-000A95C62238@rknet.it> hello to all, I want use this method for reopen my app if the user close it (it isn't a document based application), the event works, when my app is closed and i click on the dock, i can run the code inside this function: def applicationShouldHandleReopen_hasVisibleWindows_(self, controller, flag): print controller print flag print "Try" return True Ok, but in which way I tell to the cocoa to redisplay my windows? The only main is: AppHelper.runEventLoop(argv=[]) But i cannot relaunch it obviously, so what is the function, event, something, that can tell to reload the nib interface? Thanks folks Here the sample code i use: import objc from Foundation import * from AppKit import * from PyObjCTools import NibClassBuilder, AppHelper NibClassBuilder.extractClasses("MainMenu") # class defined in MainMenu.nib class notes(NibClassBuilder.AutoBaseClass): # the actual base class is NSObject # The following outlets are added to the class: # button # label def applicationDidFinishLaunching_(self, aNotification): NSLog( "asdasd." ) def change_(self, sender): print "Change Action" #def applicationShouldTerminateAfterLastWindowClosed_(self, controller): # return True def applicationShouldHandleReopen_hasVisibleWindows_(self, controller, flag): print controller print flag print "caccamo" return True AppHelper.runEventLoop(argv=[]) Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From sw at wordtech-software.com Wed Jan 5 19:38:46 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Jan 5 19:38:53 2005 Subject: [Pythonmac-SIG] ANN: Spe for OS X available Message-ID: <41DC3436.8010607@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stani's Python Editor (Spe) is a Python IDE built on the wxPython toolkit. It features auto-indentation, auto completion, call tips, syntax coloring, syntax highlighting, class explorer, source index, auto to-do list, sticky notes, integrated Pycrust shell, Python file browser, recent file browser, drag and drop, and context help. Special is its blender support with a Blender 3d object browser and its ability to run interactively inside Blender. Spe ships with wxGlade (gui designer), PyChecker (source code doctor), XRCed (GUI editor) and Kiki (regular expression console). Spe is a particularly powerful environment if you are developing Python applications using the wxPython toolkit. Its integration with other tools make it a complete solution. This version of Spe (0.7.1) is the first one that runs well on Mac OS X. Previous versions had severe bugs that made Spe unusable. Stani Michiels, the developer of Spe, made a concerted effort to get Spe running on OS X, and we thank him for his efforts. We have packaged Spe and its plug-ins into standard double-clickable Mac application bundles. For more information: http://www.wordtech-software.com/spe.html - -- 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@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3DQ1JmdQs+6YVcoRAigvAJ0RJ7f9t7ePaPSsCaiApL1AV0dPngCfTXZI TiWc7zSx8piC3zHMvU2eJGw= =lfxx -----END PGP SIGNATURE----- From rroberts at adobe.com Fri Jan 7 07:03:47 2005 From: rroberts at adobe.com (Read Roberts) Date: Fri Jan 7 07:03:55 2005 Subject: [Pythonmac-SIG] Help in easy way to hide Tk console window Message-ID: I succeeded in fixing a problem with displaying Kanji in my Tkinter-based app under Mac OSX 10.2.8. by building Tcl/Tk 8.4.9. with the patch: http://sourceforge.net/tracker/index.php?func=detail&aid=638966&group_id=12997&atid=312997 Now however, when I run by bundle app made with buildapp.py, the resulting app opens a Tcl interpreter console window. This doesn't happen when I run my Python script directly from a Terminal window using pythonw. Any suggestions? Since I am building my own Tcl/Tk framwork, i can of course disable this in the source, but there must be a simpler way via Tkinter. From rroberts at adobe.com Fri Jan 7 17:10:00 2005 From: rroberts at adobe.com (Read Roberts) Date: Fri Jan 7 17:10:13 2005 Subject: [Pythonmac-SIG] Help in easy way to hide Tk console window In-Reply-To: References: Message-ID: Daniel Steffen answered this from the tcl-mac group: import Tkinter root=Tkinter.Tk() root.tk.call('console','hide') or root.tk.call('after','idle','console','hide') At 10:03 PM -0800 1/6/05, Read Roberts wrote: >I succeeded in fixing a problem with displaying Kanji in my >Tkinter-based app under Mac OSX 10.2.8. by building Tcl/Tk 8.4.9. >with the patch: >http://sourceforge.net/tracker/index.php?func=detail&aid=638966&group_id=12997&atid=312997 > >Now however, when I run by bundle app made with buildapp.py, the >resulting app opens a Tcl interpreter console window. This doesn't >happen when I run my Python script directly from a Terminal window >using pythonw. Any suggestions? > >Since I am building my own Tcl/Tk framwork, i can of course disable >this in the source, but there must be a simpler way via Tkinter. From dgram001 at yahoo.com Fri Jan 7 17:48:29 2005 From: dgram001 at yahoo.com (Daniel Gram) Date: Fri Jan 7 17:52:07 2005 Subject: [Pythonmac-SIG] problem installing 2.4 Message-ID: <20050107164829.89593.qmail@web90007.mail.scd.yahoo.com> Hi Think I made something stupid: In order to install Python 2.4 on my iBook (10.3.7) I read some recent threads here on the mailing list and then tried it myself. Everything was working fine until I tried: make frameworkinstall, which resulted in this error message: BuildPhase PythonLauncher.app echo Completed phase "" for "PythonLauncher.app" Completed phase for PythonLauncher.app StandaloneExecutable ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLauncher StandaloneExecutable.LinkUsingFileList ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLauncher /usr/bin/gcc-3.3 -o ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLauncher "-L/Users/meesters/Documents/Downloads/Python-2.4/Mac/OSX/PythonLauncher/build" "-L/Users/meesters/Documents/Downloads/Python-2.4/Mac/OSX/PythonLauncher/build" "-F/Users/meesters/Documents/Downloads/Python-2.4/Mac/OSX/PythonLauncher/build" "-F/Users/meesters/Documents/Downloads/Python-2.4/Mac/OSX/PythonLauncher/build" -filelist /Users/meesters/Documents/Downloads/Python-2.4/Mac/OSX/PythonLauncher/build/PythonLauncher.build/PythonLauncher.build/Objects-normal/LinkFileList "-arch" "ppc" "-s" "-prebind" "-Wl,-no_arch_warnings" "-framework" "Cocoa" "-framework" "Carbon" ld: can't open: /Users/meesters/Desktop/Python-2.4/Mac/OSX/PythonLauncher/build/PythonLauncher.build/PythonLauncher.build/Objects-normal/ppc/MyDocument.o (No such file or directory, errno = 2) ld: can't open: /Users/meesters/Desktop/Python-2.4/Mac/OSX/PythonLauncher/build/PythonLauncher.build/PythonLauncher.build/Objects-normal/ppc/main.o (No such file or directory, errno = 2) ld: can't open: /Users/meesters/Desktop/Python-2.4/Mac/OSX/PythonLauncher/build/PythonLauncher.build/PythonLauncher.build/Objects-normal/ppc/FileSettings.o (No such file or directory, errno = 2) ld: can't open: /Users/meesters/Desktop/Python-2.4/Mac/OSX/PythonLauncher/build/PythonLauncher.build/PythonLauncher.build/Objects-normal/ppc/PreferencesWindowController.o (No such file or directory, errno = 2) ld: can't open: /Users/meesters/Desktop/Python-2.4/Mac/OSX/PythonLauncher/build/PythonLauncher.build/PythonLauncher.build/Objects-normal/ppc/MyAppDelegate.o (No such file or directory, errno = 2) ld: can't open: /Users/meesters/Desktop/Python-2.4/Mac/OSX/PythonLauncher/build/PythonLauncher.build/PythonLauncher.build/Objects-normal/ppc/doscript.o (No such file or directory, errno = 2) ld: warning prebinding disabled because dependent library: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit can't be searched ...failed StandaloneExecutable.LinkUsingFileList ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLauncher ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 All I did before is this: $ MACOSX_DEPLOYMENT_TARGET=10.3; export MACOSX_DEPLOYMENT_TA RGET $ env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enabl e-framework $ make and then $ make frameworkinstall A few days before I re-installed wx on version 2.3, but this shouldn't cause this problem, right? Any idea what I might have done and how to solve this? Thanks a lot in advance, Daniel __________________________________ Do you Yahoo!? All your favorites on one personal page – Try My Yahoo! http://my.yahoo.com From rroberts at adobe.com Fri Jan 7 19:54:54 2005 From: rroberts at adobe.com (Read Roberts) Date: Fri Jan 7 19:55:02 2005 Subject: [Pythonmac-SIG] Help in easy way to hide Tk console window Message-ID: Addendum: If the Tcl/Tk framework decides that it does not need to open a Tcl console window, then the commands below fail with an exception "TclError". In my case, the console window is not put up when I run my script from the Mac OSX Terminal window with "pythonw GMT.py", but it is put up when I run the script as a bundle app made by 'bundelbuilder.py". Hence I needed to day: from Tkinter import all root=Tk() try: root.tk.call('console','hide') except TclError: pass At 10:50 AM -0800 1/7/05, Read Roberts wrote: >Daniel Steffen answered this from the tcl-mac group: > import Tkinter > root=Tkinter.Tk() > root.tk.call('console','hide') >or > root.tk.call('after','idle','console','hide') > > >At 10:03 PM -0800 1/6/05, Read Roberts wrote: >>I succeeded in fixing a problem with displaying Kanji in my >>Tkinter-based app under Mac OSX 10.2.8. by building Tcl/Tk 8.4.9. >>with the patch: >>http://sourceforge.net/tracker/index.php?func=detail&aid=638966&group_id=12997&atid=312997 >> >>Now however, when I run by bundle app made with buildapp.py, the >>resulting app opens a Tcl interpreter console window. This doesn't >>happen when I run my Python script directly from a Terminal window >>using pythonw. Any suggestions? >> >>Since I am building my own Tcl/Tk framwork, i can of course disable >>this in the source, but there must be a simpler way via Tkinter. > From matsakis at mit.edu Fri Jan 7 21:02:04 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Fri Jan 7 21:02:07 2005 Subject: [Pythonmac-SIG] Python 2.4 Framework build? Message-ID: It appears to me that there is not a python 2.4 framework build in fink. Is this actually the case? It is my impression that a framework build is necessary to use appscript and other Mac goodies. Is this still the case with 2.4? Finally, what is the easiest way to get a framework build of 2.4? Is there a binary installer somewhere? Nick Matsakis From bob at redivi.com Fri Jan 7 22:29:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 7 22:29:43 2005 Subject: [Pythonmac-SIG] Python 2.4 Framework build? In-Reply-To: References: Message-ID: <3B01DAC0-60F3-11D9-B917-000A95BA5446@redivi.com> On Jan 7, 2005, at 15:02, Nick Matsakis wrote: > It appears to me that there is not a python 2.4 framework build in > fink. > Is this actually the case? It is my impression that a framework build > is > necessary to use appscript and other Mac goodies. Is this still the > case > with 2.4? Finally, what is the easiest way to get a framework build of > 2.4? Is there a binary installer somewhere? Neither darwinports nor fink provide a framework build. appscript and other mac goodies *may* work with a non-framework build, but may not work in some circumstances since there is no fake application bundle installed with this style of build. appscript and friends would certainly work with a py2app packaged bundle created using a non-framework build, however, since a real application bundle is present in this case. The easiest way to get a framework build of 2.4 is to wait until 2.4.1 comes out, for which there will probably be a binary installer. 2.4.1 will have a bunch of bugfixes that make it easier to compile+build, fix destroot'ed builds so that fink/darwinports *could* support framework builds, and it will also have better compatibility with Mac OS X 10.2 (though, as always, if you compile on 10.X it will need 10.X or later). -bob From marshall at labow.com Fri Jan 7 18:23:04 2005 From: marshall at labow.com (Marshall Labow) Date: Sat Jan 8 16:28:03 2005 Subject: [Pythonmac-SIG] Help - MacPython stopped running Message-ID: Can anyone help me? I am running Panther (10.3.7) and installed the upgrade to Python 2.3 (MacPython IDE) and it worked for a few days. Now when I attempt to load the program, the splash screen appears for a few seconds and then disappears without the finder ever showing Python IDE as being active. I have tried (1) rebooting the computer; (2) re-installing MacPython; and (3) deleting the existing MacPython files and re-installing them. Nothing so far helps. Anyone have any suggestions? Marshall Labow marshall@labow.com From brendansimons at yahoo.ca Fri Jan 7 22:55:02 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sat Jan 8 16:28:03 2005 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X Message-ID: <20050107215502.76489.qmail@web12407.mail.yahoo.com> This is an old thread, (and an old topic) but my question is about the state of the "new tools" described in Bob's presentation at last year's pyCon. Scanning the archives, I see Jack and Just have talked about a PyObjC-based python ide since 2002. I've really anxious to see how they are coming along. I've used PyOXIDE, and am suitably impressed, but it is still way too crashy for daily use. There are some promising wx-based IDEs which run fine (PyPE, PythonCard Editor, SPE), but none include a debugger, and most look just a little "off" . So, what news? - Brendan Simons Stern Laboratories Hamilton, ON, Canada ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From charles.hartman at conncoll.edu Sat Jan 8 17:26:03 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat Jan 8 17:26:13 2005 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <20050107215502.76489.qmail@web12407.mail.yahoo.com> References: <20050107215502.76489.qmail@web12407.mail.yahoo.com> Message-ID: FWIW: After going through everything I could find for OS X (PyOxide, SPE, IDLE, etc) and giving up on all of it, I finally sprang for $35 for the Personal Edition of WingIDE. It's very good, and very well supported. The Personal Edition is missing a bunch of stuff I don't care about and one thing I do, debug Watch values. The debugger is well integrated; you can debug by the project or by the module, which is very handy. Though the editor is slightly clunky (I prefer TextWrangler) it's perfectly workable. The integration with wxPython is excellent. The only thing I don't like about Wing -- aside from having to pay actual money -- is that it runs under X11, the only app I have (so far) that requires it. The different (anti-Mac) key-bindings are annoying, but I believe I could change that if I took the time to build a "personality" in Wing. The performance hit from X11 doesn't seem to be severe, and it plays well with Virtual Desktop Pro (which I'm also going to have to pay for because after five days I can't live without it). Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Jan 7, 2005, at 4:55 PM, Brendan Simons wrote: > This is an old thread, (and an old topic) but my > question is about the state of the "new tools" > described in Bob's presentation at last year's pyCon. > > Scanning the archives, I see Jack and Just have talked > about a PyObjC-based python ide since 2002. I've > really anxious to see how they are coming along. > > I've used PyOXIDE, and am suitably impressed, but it > is still way too crashy for daily use. There are some > promising wx-based IDEs which run fine (PyPE, > PythonCard Editor, SPE), but none include a debugger, > and most look just a little "off" . > > So, what news? > > - > Brendan Simons > Stern Laboratories > Hamilton, ON, Canada > > > > > ______________________________________________________________________ > Post your free ad now! http://personals.yahoo.ca > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Jack.Jansen at cwi.nl Sat Jan 8 23:18:54 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Jan 8 23:18:34 2005 Subject: [Pythonmac-SIG] Python 2.4 Framework build? In-Reply-To: References: Message-ID: <4898DF36-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> On 7-jan-05, at 21:02, Nick Matsakis wrote: > It appears to me that there is not a python 2.4 framework build in > fink. > Is this actually the case? It is my impression that a framework build > is > necessary to use appscript and other Mac goodies. Is this still the > case > with 2.4? Finally, what is the easiest way to get a framework build of > 2.4? Is there a binary installer somewhere? I'm working on a lot of distributions right now, including a 2.4.1 framework build. It can't really be finished until 2.4.1 comes out, but if people want to give a 2.4.1a0 build a try: let me know and I'll make it available. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Sat Jan 8 23:20:10 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Jan 8 23:19:51 2005 Subject: [Pythonmac-SIG] Help - MacPython stopped running In-Reply-To: References: Message-ID: <756F5992-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> On 7-jan-05, at 18:23, Marshall Labow wrote: > Can anyone help me? > > I am running Panther (10.3.7) and installed the upgrade to Python 2.3 > (MacPython IDE) and it worked for a few days. Now when I attempt to > load the program, the splash screen appears for a few seconds and then > disappears without the finder ever showing Python IDE as being active. > I have tried (1) rebooting the computer; (2) re-installing MacPython; > and (3) deleting the existing MacPython files and re-installing them. > Nothing so far helps. Anyone have any suggestions? You've probably run into the "Scripts menu" problem. See the FAQ for a fix (in short: remove your IDE preferences file). If that doesn't help please report back, -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Sat Jan 8 23:41:36 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Jan 8 23:41:13 2005 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <20050107215502.76489.qmail@web12407.mail.yahoo.com> References: <20050107215502.76489.qmail@web12407.mail.yahoo.com> Message-ID: <746E3C14-61C6-11D9-B0FB-000D934FF6B4@cwi.nl> On 7-jan-05, at 22:55, Brendan Simons wrote: > This is an old thread, (and an old topic) but my > question is about the state of the "new tools" > described in Bob's presentation at last year's pyCon. > > Scanning the archives, I see Jack and Just have talked > about a PyObjC-based python ide since 2002. I've > really anxious to see how they are coming along. Aren't we all:-( The problem is one of time: I've spent all of my working hours the last year on a completely un-pythonic project (www.ambulantplayer.org, but I do plan to do Python bindings some time this year), and now that I finally have some time to do Python work I'm concentrating on the important infrastructural problems (mainly the "multiple-python-problem" and getting Package Manager to be more maintainable). I assume Just is similarly occupied by other priorities (hmm, that doesn't look like english:-). I haven't even had the time to seriously look at PyOXIDE, let alone the other contenders. But I'm still very interested in getting a good replacement for the IDE, it's just that I don't have the time to invest in it. Is there some way we could turn this "next generation IDE" thing into a group effort? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Sun Jan 9 00:15:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 9 00:15:24 2005 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <746E3C14-61C6-11D9-B0FB-000D934FF6B4@cwi.nl> References: <20050107215502.76489.qmail@web12407.mail.yahoo.com> <746E3C14-61C6-11D9-B0FB-000D934FF6B4@cwi.nl> Message-ID: <296B2C7C-61CB-11D9-9C18-000A95BA5446@redivi.com> On Jan 8, 2005, at 17:41, Jack Jansen wrote: > > On 7-jan-05, at 22:55, Brendan Simons wrote: > >> This is an old thread, (and an old topic) but my >> question is about the state of the "new tools" >> described in Bob's presentation at last year's pyCon. >> >> Scanning the archives, I see Jack and Just have talked >> about a PyObjC-based python ide since 2002. I've >> really anxious to see how they are coming along. > > Aren't we all:-( > > The problem is one of time: I've spent all of my working hours the > last year on a completely un-pythonic project (www.ambulantplayer.org, > but I do plan to do Python bindings some time this year), and now that > I finally have some time to do Python work I'm concentrating on the > important infrastructural problems (mainly the > "multiple-python-problem" and getting Package Manager to be more > maintainable). I assume Just is similarly occupied by other priorities > (hmm, that doesn't look like english:-). I've also been working on infrastructure problems (py2app, PyObjC, helping however I can with Python), and commercial projects. > I haven't even had the time to seriously look at PyOXIDE, let alone > the other contenders. But I'm still very interested in getting a good > replacement for the IDE, it's just that I don't have the time to > invest in it. I haven't taken a serious look at it (or anything else) either. I'm quite interested in helping to replace the IDE, but I also don't have the time for at least a few months. I would like to make some major changes to PyObjC, some minor changes to py2app, and work on the packman problem before I start on any IDE work. > Is there some way we could turn this "next generation IDE" thing into > a group effort? I think that two of the most important and difficult things to tackle are an out-of-process interpreter and debugger that work well. At least, those are the two things I would work on first, because they would be most useful to me. I already have sufficient tools for editing text :) The py lib project would be a good place to start I think (py.execnet, specifically, would be a reasonable to to implement an out-of-process interpreter and debugger). -bob From gandreas at gandreas.com Sun Jan 9 05:00:38 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Sun Jan 9 05:00:41 2005 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: <20050107215502.76489.qmail@web12407.mail.yahoo.com> References: <20050107215502.76489.qmail@web12407.mail.yahoo.com> Message-ID: <05829BFB-61F3-11D9-8AD6-000D9346E10A@gandreas.com> On Jan 7, 2005, at 3:55 PM, Brendan Simons wrote: > This is an old thread, (and an old topic) but my > question is about the state of the "new tools" > described in Bob's presentation at last year's pyCon. > > Scanning the archives, I see Jack and Just have talked > about a PyObjC-based python ide since 2002. I've > really anxious to see how they are coming along. > > I've used PyOXIDE, and am suitably impressed, but it > is still way too crashy for daily use. There are some > promising wx-based IDEs which run fine (PyPE, > PythonCard Editor, SPE), but none include a debugger, > and most look just a little "off" . > > So, what news? > While PyOXIDE has been pretty quiet recently, I just reached a _major_ milestone (which will hopefully be released this week). I created a new project, added the example CurrencyConverter.py and nib & string files to it, and told it to run - and it build a nice little stand-alone app, and ran like expected (yes, this is all new, but this isn't the interesting part). And then I turned on debugging. Hit run again, and there was the debugger with source to CurrencyConverter.py staring me in the face. Set a breakpoint in convert_, hit run, switched to the app, pressed the "Convert" button, and popped back to PyOXIDE, and there we were, in convert_, just like expected. Stepped a few times (to get the total value), changed it to 99, and then continued - and sure enough, back in CurrencyConverter we get a result of 2 * 3 = 99. (And yes, the console works so you can execute arbitrary code within the client environment while stopped between steps or at a break point) So "proof of example" source code debugging of bundled PyObjC app projects has been reached! Glenn Andreas????????????????????? gandreas@gandreas.com? oh my! Mad, Bad, and Dangerous to Know From n8gray at gmail.com Sun Jan 9 07:38:05 2005 From: n8gray at gmail.com (Nathaniel Gray) Date: Sun Jan 9 07:38:09 2005 Subject: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X In-Reply-To: References: <20050107215502.76489.qmail@web12407.mail.yahoo.com> Message-ID: On Sat, 8 Jan 2005 11:26:03 -0500, Charles Hartman wrote: > > The performance hit from X11 doesn't seem to be > severe, and it plays well with Virtual Desktop Pro (which I'm also > going to have to pay for because after five days I can't live without > it). Check out these projects: http://virtuedesktops.sourceforge.net/ http://wsmanager.sourceforge.net/ I'm using wsmanager for now but I'll probably switch to virtue once they implement the pager-in-menubar feature. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> From kim at anechoicmedia.com Mon Jan 10 05:25:25 2005 From: kim at anechoicmedia.com (Kim Cascone) Date: Mon Jan 10 05:25:31 2005 Subject: [Pythonmac-SIG] SOAPpy Message-ID: I'm trying to install SOAPpy I first DL'd and installed fpconst and pyXML (but I don't think they are in the right place) I then DL'd the SOAPpy from the web site (not darwinports) and tried to do an install it couldn't find fpconst I went to darwinports and DL'd SOAPpy from there and it seemed to load in the dependencies for me this time but somehow I also got Python2.4 installed as well... so now when I try to build SOAPpy I get the following error: Bourbaki:/SOAPpy-0.11.6 root# python /SOAPpy-0.11.6/setup.py build Traceback (most recent call last): File "/SOAPpy-0.11.6/setup.py", line 8, in ? from SOAPpy.version import __version__ File "/SOAPpy-0.11.6/SOAPpy/__init__.py", line 5, in ? from Client import * File "/SOAPpy-0.11.6/SOAPpy/Client.py", line 57, in ? from Parser import parseSOAPRPC File "/SOAPpy-0.11.6/SOAPpy/Parser.py", line 8, in ? import fpconst ImportError: No module named fpconst I think there are some differences in the two different SOAPpy packages I DL'd, the first one was done via CVS and the second via a .tar.gz package which was DL'd and extracted...so the various parts were placed in odd places like the python2.4/ is in my /opt/local/lib (I added a $PATH for this in my ~/.bash_profile) for some reason and not in the Library/Frameworks/Python.framework/Versions/ dir can anyone tell me where fpconst should be located? as well as whether python2.4 should be in the Library/Frameworks... dir? thanks in advance! KIM From Jack.Jansen at cwi.nl Mon Jan 10 10:14:44 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jan 10 10:14:49 2005 Subject: [Pythonmac-SIG] SOAPpy In-Reply-To: References: Message-ID: <110E29CD-62E8-11D9-B171-000A958D1666@cwi.nl> At best, your various Python installations (in your case, at least Apple's Python 2.3 and darwinports Python 2.4) will be completely independent. At worst they'll break each other, but that's a different story for now:-) What seems to have happened in your case is that you installed fpconst and pyXML into Apple's Python 2.3, then got SOAPpy from darwinports (which installed its own separate Python 2.4). You can check this be seeing whether there' s fpconst and pyXML stuff in /Library/Python/2.3, which is where Apple's Python keeps its extension modules. Apparently darwinports' dependencies aren't complete, otherwise it would have loaded copies of fpconst and pyXML for it's Python 2.4 too. Why SOAPpy didn't work for Apple Python I don't know. But your best course of action is probably to get the missing fpconst module into darwinports' Python 2.4, by running its setup.py again with the right python. On 10 Jan 2005, at 05:25, Kim Cascone wrote: > I'm trying to install SOAPpy > I first DL'd and installed fpconst and pyXML (but I don't think they > are in the right place) > I then DL'd the SOAPpy from the web site (not darwinports) and tried > to do an install > it couldn't find fpconst > I went to darwinports and DL'd SOAPpy from there and it seemed to load > in the dependencies for me this time but somehow I also got Python2.4 > installed as well... > so now when I try to build SOAPpy I get the following error: > > Bourbaki:/SOAPpy-0.11.6 root# python /SOAPpy-0.11.6/setup.py build > Traceback (most recent call last): > File "/SOAPpy-0.11.6/setup.py", line 8, in ? > from SOAPpy.version import __version__ > File "/SOAPpy-0.11.6/SOAPpy/__init__.py", line 5, in ? > from Client import * > File "/SOAPpy-0.11.6/SOAPpy/Client.py", line 57, in ? > from Parser import parseSOAPRPC > File "/SOAPpy-0.11.6/SOAPpy/Parser.py", line 8, in ? > import fpconst > ImportError: No module named fpconst > > I think there are some differences in the two different SOAPpy > packages I DL'd, the first one was done via CVS and the second via a > .tar.gz package which was DL'd and extracted...so the various parts > were placed in odd places like the python2.4/ is in my /opt/local/lib > (I added a $PATH for this in my ~/.bash_profile) for some reason and > not in the Library/Frameworks/Python.framework/Versions/ dir > > can anyone tell me where fpconst should be located? as well as whether > python2.4 should be in the Library/Frameworks... dir? > > thanks in advance! > KIM > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Mon Jan 10 10:31:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 10 10:31:25 2005 Subject: [Pythonmac-SIG] SOAPpy In-Reply-To: <110E29CD-62E8-11D9-B171-000A958D1666@cwi.nl> References: <110E29CD-62E8-11D9-B171-000A958D1666@cwi.nl> Message-ID: <5E75A3F6-62EA-11D9-B9E0-000A95BA5446@redivi.com> From the description, it sounds like the following happened: - Installation of SOAPpy without fpconst failed, because setup.py imports SOAPpy to fetch the version. - Installation of SOAPpy without fpconst using DarwinPorts succeeded, but didn't actually work because fpconst is still missing. A whole lot of other crap (Python 2.4, etc.) was installed in the process. ... so, it sounds like you need fpconst to use SOAPpy. Google and PEP 754 agree that fpconst is here: http://research.warnes.net/projects/rzope/fpconst/ -bob On Jan 10, 2005, at 4:14, Jack Jansen wrote: > At best, your various Python installations (in your case, at least > Apple's Python 2.3 and darwinports Python 2.4) will be completely > independent. At worst they'll break each other, but that's a different > story for now:-) > > What seems to have happened in your case is that you installed fpconst > and pyXML into Apple's Python 2.3, then got SOAPpy from darwinports > (which installed its own separate Python 2.4). You can check this be > seeing whether there' s fpconst and pyXML stuff in > /Library/Python/2.3, which is where Apple's Python keeps its extension > modules. > > Apparently darwinports' dependencies aren't complete, otherwise it > would have loaded copies of fpconst and pyXML for it's Python 2.4 too. > > Why SOAPpy didn't work for Apple Python I don't know. But your best > course of action is probably to get the missing fpconst module into > darwinports' Python 2.4, by running its setup.py again with the right > python. > > On 10 Jan 2005, at 05:25, Kim Cascone wrote: > >> I'm trying to install SOAPpy >> I first DL'd and installed fpconst and pyXML (but I don't think they >> are in the right place) >> I then DL'd the SOAPpy from the web site (not darwinports) and tried >> to do an install >> it couldn't find fpconst >> I went to darwinports and DL'd SOAPpy from there and it seemed to >> load in the dependencies for me this time but somehow I also got >> Python2.4 installed as well... >> so now when I try to build SOAPpy I get the following error: >> >> Bourbaki:/SOAPpy-0.11.6 root# python /SOAPpy-0.11.6/setup.py build >> Traceback (most recent call last): >> File "/SOAPpy-0.11.6/setup.py", line 8, in ? >> from SOAPpy.version import __version__ >> File "/SOAPpy-0.11.6/SOAPpy/__init__.py", line 5, in ? >> from Client import * >> File "/SOAPpy-0.11.6/SOAPpy/Client.py", line 57, in ? >> from Parser import parseSOAPRPC >> File "/SOAPpy-0.11.6/SOAPpy/Parser.py", line 8, in ? >> import fpconst >> ImportError: No module named fpconst >> >> I think there are some differences in the two different SOAPpy >> packages I DL'd, the first one was done via CVS and the second via a >> .tar.gz package which was DL'd and extracted...so the various parts >> were placed in odd places like the python2.4/ is in my /opt/local/lib >> (I added a $PATH for this in my ~/.bash_profile) for some reason and >> not in the Library/Frameworks/Python.framework/Versions/ dir >> >> can anyone tell me where fpconst should be located? as well as >> whether python2.4 should be in the Library/Frameworks... dir? >> >> thanks in advance! >> KIM >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From mike at maibaum.org Mon Jan 10 11:06:09 2005 From: mike at maibaum.org (Michael Maibaum) Date: Mon Jan 10 11:06:13 2005 Subject: [Pythonmac-SIG] SOAPpy In-Reply-To: <5E75A3F6-62EA-11D9-B9E0-000A95BA5446@redivi.com> References: <110E29CD-62E8-11D9-B171-000A958D1666@cwi.nl> <5E75A3F6-62EA-11D9-B9E0-000A95BA5446@redivi.com> Message-ID: <20050110100609.GA87271@remote.gene-hacker.net> On Mon, Jan 10, 2005 at 04:31:13AM -0500, Bob Ippolito wrote: >From the description, it sounds like the following happened: > >- Installation of SOAPpy without fpconst failed, because setup.py >imports SOAPpy to fetch the version. >- Installation of SOAPpy without fpconst using DarwinPorts succeeded, >but didn't actually work because fpconst is still missing. A whole lot >of other crap (Python 2.4, etc.) was installed in the process. Actually, here is hypothesis number 3: Instalation of python 2.4, fpconst, py-xml and py-soappy with darwinports suceeded, but the OP is still invoking python2.3 because either /opt/local/bin/python is not in the $PATH or is not before /usr/bin/python And Suggestion number 3: Try invoking darwinports python explicitly with /opt/local/bin/python if you want to use darwinports modules. I'm certain (looking at the portfile in front of me) that py-soappy doesn't miss either py-fpconst or py-xml as deps. cheers Michael -- Dr Michael A. Maibaum internet: mike@maibaum.org http://mike.maibaum.org/ voice: [m] 07813 713 952 [w] (020) 7679 3890 From hengist.podd at virgin.net Tue Jan 11 01:27:21 2005 From: hengist.podd at virgin.net (has) Date: Tue Jan 11 01:27:27 2005 Subject: [Pythonmac-SIG] [ann] appscript 0.10.0 Message-ID: Hi all, Quick update to appscript package posted that fixes a couple dumb bugs and further enhances built-in help: http://freespace.virgin.net/hamish.sanderson/appscript.html BTW, I'd like to start aiming for the 1.0 release, so if anyone has some time on their hands and would like to look over the todo list, source code and documentation and let me know what they think works/doesn't work/still needs to be done then it'd be much appreciated. (I've been staring at this crap so long I'm probably snow-blind by now.) If someone who's familiar with using Apple events at lower levels could review the aem package that'd also be a big help: there's still a little bit of coding work to do there, some decisions to make about how much more to develop aem.receive, and the API could do with a quick once-over to see if it could be improved any further. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From Layne.Bilyeu at robbstucky.net Mon Jan 10 23:13:29 2005 From: Layne.Bilyeu at robbstucky.net (AdvertisingDept) Date: Tue Jan 11 01:54:44 2005 Subject: [Pythonmac-SIG] MacPython OSX beginner concepts ~/Desktop Message-ID: In apple's terminal app I can type: touch ~/Desktop/foobar and create an empty file. How do I go about doing this in Apple's Python2.3 Panther? From neal at metaslash.com Tue Jan 11 01:33:35 2005 From: neal at metaslash.com (Neal Norwitz) Date: Tue Jan 11 01:54:44 2005 Subject: [Pythonmac-SIG] [visexnotifier1@mindvision.com: MindVision Releases VISE X 1.5 for Mac OS X] Message-ID: <20050111003335.GD14363@janus.swcomplete.com> I thought this might be of interest here. The PSF owns a license to VISE. Jack knows the details. Neal ----- Forwarded message from VISE X Notification ----- From: VISE X Notification Subject: MindVision Releases VISE X 1.5 for Mac OS X Date: 06 Jan 2005 14:21:05 -0600 ------------------------------------------------------------------------ MINDVISION RELEASES VISE X 1.5 FOR MAC OS X ------------------------------------------------------------------------ LINCOLN, NEB. - Jan. 6, 2005: MindVision Software today announced VISE X 1.5, an upgrade to its Mac OS X installer product. Developers can use VISE X 1.5 to create single-file updaters--compact installers that contain just enough information to update Mac OS X applications quickly and safely based on the differences between the old and new versions. Other new features in version 1.5 include: * Make changes to the Dock or Startup Items * Check the user's install permissions * Use shadows of folders to reduce installer size * Share forms between archives The VISE X 1.5 installer is available for downloading now at http://www.mindvision.com/downloads.asp. For a detailed list of changes in this release, see the Read Me in the VISE X installer, or visit http://www.mindvision.com/visexwhatsnew. ------------------------------------------------------------------------ AVAILABILITY ------------------------------------------------------------------------ Fully functional evaluation copies of VISE X 1.5 are available for downloading at http://www.mindvision.com/downloads.asp. Customers with current annual licenses are eligible to receive this upgrade for free. Others can find licensing information through the MindVision web site at http://www.mindvision.com/pricing.asp, or by contacting us at (402) 323-6600 or sales@mindvision.com. ------------------------------------------------------------------------ ABOUT MINDVISION ------------------------------------------------------------------------ Founded in 1987, MindVision Software is a recognized industry leader specializing in software delivery systems for Macintosh and Windows. Installer VISE has long been the industry standard installer for the Macintosh, and is recognized as an excellent choice for Windows. VISE X was introduced in November 2003 to meet the needs of software developers who build installers exclusively for Mac OS X. Thousands of software companies, including Apple, Adobe, Microsoft, Netscape, Macromedia, AOL, Connectix and FileMaker have come to rely on our software to deliver professional, easy-to-use installers to their customers. Fully functional evaluation copies of MindVision products can be obtained directly from the MindVision web site, by calling (402) 323-6600, or by sending e-mail to sales@mindvision.com. MindVision, VISE X and Installer VISE are trademarks of MindVision, Inc. All other brand names mentioned are trademarks or registered trademarks of their respective holders and are hereby acknowledged. *********************************************************************** If you no longer wish to receive VISE X product announcements from MindVision Software, please reply to this e-mail with the word Remove in the subject. *********************************************************************** ----- End forwarded message ----- From bob at redivi.com Tue Jan 11 02:00:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 11 02:00:39 2005 Subject: [Pythonmac-SIG] MacPython OSX beginner concepts ~/Desktop In-Reply-To: References: Message-ID: <30F9DCC6-636C-11D9-9F71-000A95BA5446@redivi.com> On Jan 10, 2005, at 17:13, AdvertisingDept wrote: > In apple's terminal app I can type: > > touch ~/Desktop/foobar > > and create an empty file. > > > How do I go about doing this in Apple's Python2.3 Panther? import os foobarPath = os.path.expanduser('~/Desktop/foobar') foobarFile = open(foobarPath, 'w') # ... write something to foobarFile foobarFile.close() -bob From bob at redivi.com Tue Jan 11 02:01:29 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 11 02:01:34 2005 Subject: [Pythonmac-SIG] [visexnotifier1@mindvision.com: MindVision Releases VISE X 1.5 for Mac OS X] In-Reply-To: <20050111003335.GD14363@janus.swcomplete.com> References: <20050111003335.GD14363@janus.swcomplete.com> Message-ID: <53C55AC0-636C-11D9-9F71-000A95BA5446@redivi.com> On Jan 10, 2005, at 19:33, Neal Norwitz wrote: > I thought this might be of interest here. The PSF owns a license to > VISE. Jack knows the details. I think that this is only really relevant to Mac OS9. I'm not sure if Jack plans to make another release for OS9? -bob From micktwomey at gmail.com Tue Jan 11 11:09:39 2005 From: micktwomey at gmail.com (Michael Twomey) Date: Tue Jan 11 11:09:41 2005 Subject: [Pythonmac-SIG] Testers needed again: Fix installer 1.2 In-Reply-To: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> References: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> Message-ID: <50a522ca0501110209b2e1c8d@mail.gmail.com> Hi, I just tried out the installer and it works fine, but it appears to have littered my disk with CVS directories, was that intentional? (I'm guessing not) Otherwise it appears to work fine. A listing of the archive contents: hamtoro:/Volumes/PantherPythonFix/PantherPythonFix.pkg/Contents/Resources mtt$ gunzip -c PantherPythonFix.pax.gz |pax . ./CVS ./CVS/Entries ./CVS/Repository ./CVS/Root ./System ./System/CVS ./System/CVS/Entries ./System/CVS/Repository ./System/CVS/Root ./System/Library ./System/Library/CVS ./System/Library/CVS/Entries ./System/Library/CVS/Repository ./System/Library/CVS/Root ./System/Library/Frameworks ./System/Library/Frameworks/CVS ./System/Library/Frameworks/CVS/Entries ./System/Library/Frameworks/CVS/Repository ./System/Library/Frameworks/CVS/Root ./System/Library/Frameworks/Python.framework ./System/Library/Frameworks/Python.framework/CVS ./System/Library/Frameworks/Python.framework/CVS/Entries ./System/Library/Frameworks/Python.framework/CVS/Repository ./System/Library/Frameworks/Python.framework/CVS/Root ./System/Library/Frameworks/Python.framework/Versions ./System/Library/Frameworks/Python.framework/Versions/2.3 ./System/Library/Frameworks/Python.framework/Versions/2.3/CVS ./System/Library/Frameworks/Python.framework/Versions/2.3/CVS/Entries ./System/Library/Frameworks/Python.framework/Versions/2.3/CVS/Repository ./System/Library/Frameworks/Python.framework/Versions/2.3/CVS/Root ./System/Library/Frameworks/Python.framework/Versions/2.3/lib ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/CVS ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/CVS/Entries ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/CVS/Repository ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/CVS/Root ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3 ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/CVS ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/CVS/Entries ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/CVS/Repository ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/CVS/Root ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/Makefile ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/PantherPythonFix ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/PantherPythonFix/run-g++ ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config/PantherPythonFix/run-gcc ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/CVS ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/CVS/Entries ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/CVS/Repository ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/CVS/Root ./System/Library/Frameworks/Python.framework/Versions/CVS ./System/Library/Frameworks/Python.framework/Versions/CVS/Entries ./System/Library/Frameworks/Python.framework/Versions/CVS/Repository ./System/Library/Frameworks/Python.framework/Versions/CVS/Root Thanks, Michael On Fri, 31 Dec 2004 13:07:36 +0100, Jack Jansen wrote: > There's yet another new version of the Python 2.3 fix installer > available: . > > This one should also make C++ extensions build correctly again with > apple-installed Python 2.3 on 10.3, after installing a later framework > build. > > Please let me know whether it works, especially with real C++ > extensions (I only tried a toy extension). > > And, for the record, I used Ronalds solution of using driver scripts > for gcc and g++ that set the MACOSX_DEPLOYMENT_TARGET environment > variable before running the compiler. > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Benjamin.Schollnick at xerox.com Tue Jan 11 14:34:12 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Tue Jan 11 14:34:21 2005 Subject: [Pythonmac-SIG] MacPython OSX beginner concepts ~/Desktop Message-ID: <266589E1B9392B4C9195CC25A07C73B9AA4DB3@usa0300ms04.na.xerox.net> > In apple's terminal app I can type: > > touch ~/Desktop/foobar > > and create an empty file. Keep in mind Touch is not just used to create a empty file... To create a empty file... def file_to_create ( filepathname ): empty = open ( filepathname, "w" ) empty.close () But touch can be used to update a existing file's time/date stamp. Here's a limited tested Touch clone: def touch ( filepathname, atime = None, mtime = None ): """An attempt to recreate in python Unix's Touch command... Set the access and modified times of the file specified by path. If atime and mtime are set to None (Default), then the file's access and modified times are set to the current time. Otherwise, atime (Last Accessed) time, and mtime (Last Modified) will be used to set the Last Accessed and Last Modified timedate stamp on the file. inputs - filepathname - The full filename and pathname of the file to be modified or created. The file will be created if it does not exist. atime - The last Accessed time to set the file to. mtime - The last modified time to set the file to. Outputs - External ; filepathname is either created, or the time/date stamp is updated to reflect the current time, or the times passed in by atime and mtime. """ import os, os.path, time if os.path.exists (filepathname): # # File Exists # if atime == None and mtime == None: # # Update to current time # os.utime( filepathname, None) else: # # Update to user definied times # if atime == None: # # Only one of the variables is None, set it to NOW # atime = time.time() if mtime == None: # # Only one of the variables is None, set it to NOW # mtime = time.time() os.utime (filepathname, (atime, mtime) ) else: empty = open ( filepathname, "w" ) empty.close () if atime <> None and mtime <> None: # # The user wants the newly created file to be # time/date stamped differently then "Now". # Run the newly created file through touch again # to define the atime and mtime. # touch ( filepathname, atime, mtime) From Benjamin.Schollnick at xerox.com Tue Jan 11 14:28:51 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Tue Jan 11 15:48:47 2005 Subject: [Pythonmac-SIG] MacPython OSX beginner concepts ~/Desktop Message-ID: <266589E1B9392B4C9195CC25A07C73B9124B9C@usa0300ms04.na.xerox.net> > In apple's terminal app I can type: > > touch ~/Desktop/foobar > > and create an empty file. Keep in mind Touch is not just used to create a empty file... To create a empty file... def file_to_create ( filepathname ): empty = open ( filepathname, "w" ) empty.close () But touch can be used to update a existing file's time/date stamp. Here's a limited tested Touch clone: def touch ( filepathname, atime = None, mtime = None ): """An attempt to recreate in python Unix's Touch command... Set the access and modified times of the file specified by path. If atime and mtime are set to None (Default), then the file's access and modified times are set to the current time. Otherwise, atime (Last Accessed) time, and mtime (Last Modified) will be used to set the Last Accessed and Last Modified timedate stamp on the file. inputs - filepathname - The full filename and pathname of the file to be modified or created. The file will be created if it does not exist. atime - The last Accessed time to set the file to. mtime - The last modified time to set the file to. Outputs - External ; filepathname is either created, or the time/date stamp is updated to reflect the current time, or the times passed in by atime and mtime. """ import os, os.path, time if os.path.exists (filepathname): # # File Exists # if atime == None and mtime == None: # # Update to current time # os.utime( filepathname, None) else: # # Update to user definied times # if atime == None: # # Only one of the variables is None, set it to NOW # atime = time.time() if mtime == None: # # Only one of the variables is None, set it to NOW # mtime = time.time() os.utime (filepathname, (atime, mtime) ) else: empty = open ( filepathname, "w" ) empty.close () if atime <> None and mtime <> None: # # The user wants the newly created file to be # time/date stamped differently then "Now". # Run the newly created file through touch again # to define the atime and mtime. # touch ( filepathname, atime, mtime) From bob at redivi.com Tue Jan 11 16:37:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 11 16:37:24 2005 Subject: [Pythonmac-SIG] Testers needed again: Fix installer 1.2 In-Reply-To: <50a522ca0501110209b2e1c8d@mail.gmail.com> References: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> <50a522ca0501110209b2e1c8d@mail.gmail.com> Message-ID: On Jan 11, 2005, at 5:09, Michael Twomey wrote: > I just tried out the installer and it works fine, but it appears to > have littered my disk with CVS directories, was that intentional? (I'm > guessing not) > > Otherwise it appears to work fine. > > A listing of the archive contents: > > hamtoro:/Volumes/PantherPythonFix/PantherPythonFix.pkg/Contents/ > Resources > mtt$ gunzip -c PantherPythonFix.pax.gz |pax The pkg also has CVS directories in it. Since all of the files in the pkg are in that one folder, I would simply lay out the archive like: . ./Makefile ./PantherPythonFix ./PantherPythonFix/run-g++ ./PantherPythonFix/run-gcc and set the IFPkgFlagDefaultLocation Info.plist key to /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ config At worst case, this would net you two CVS directories instead of 11 :) -bob From whamoo at rknet.it Wed Jan 12 17:05:03 2005 From: whamoo at rknet.it (whamoo) Date: Wed Jan 12 17:04:04 2005 Subject: [Pythonmac-SIG] [py2app help] Argv emulation and lost of focus Message-ID: Hi to all, I've bundled an application with argv emulation (-a) , but when i start the app this doesn't focus, and the "applicationDidFinishLaunching_" only start when i clik on the icon on the dock...... all works fine but i want the focus on my app when i open it =) Someone can tell me something? =) Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk From rayme at pobox.com Wed Jan 12 18:52:54 2005 From: rayme at pobox.com (Rayme Jernigan) Date: Wed Jan 12 18:53:00 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton In-Reply-To: <4898DF36-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> References: <4898DF36-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> Message-ID: Hi, I'm looking for a language to abuse for a project I'm working on. I know a little Python, but I do not know if it can do this: I'd like to define some class "N" that instantiates objects that can instantiate fresh new objects of that same class... without external controller code. You could use this capability, for example, to generate a red-black tree-type data structure that implicitly instantiates a new node for each new input d1, d2, d3... so on. The algorithm for each node could be: -- Toggle downstream L/R pointer -- If no node there, instantiate one and link to it -- if a node is there, pass the datum to it The execution sequence as the tree builds itself out might look something like this: 1. n0 = N(d0) # new instance of N # (downstream pointer default = "Left") # (the first input data, d0, is instantiated in node n0) # nodes: n0 2. n0.send(d1) # toggle n0's downstream pointer to "Right" # on n0 there is no downstream node right so instantiate a new linked node right n1 with d1 # nodes: n0,n1 3. n0. send(d2) # toggle n0's downstream pointer "Left" # in n0 there is no downstream node left so instantiate n2 with d2 # nodes: n0,n1,n2 4. n0. send(d3) # toggle n0's downstream pointer "Right" # there exists a downstream node right, n1, so send d3 there # toggle n1's downstream pointer "Right" # in n1 there is no downstream node right so instantiate n3 with d3 # nodes: n0,n1,n2,n3 5. n0. send(d4) # toggle n0's downstream pointer "Left" # there exists a downstream node left, n2, so send d4 there # toggle n2's downstream pointer "Right" # in n2 there is no downstream node right so instantiate n4 with d4 # nodes: n0,n1,n2,n3,n4 6. n0.send(d5) # toggle n0's downstream pointer "Right" # there exists a downstream node right, n1, so send d5 there # toggle n1's downstream pointer "Left" # in n1 there is no downstream node left so instantiate n5 with d5 # nodes: n0,n1,n2,n3,n4,n5 7. n0.send(d6) # So on... # ... Any thoughts about how to do this in Python appreciated. Possible at all? Thanks in advance, -Rayme. From Benjamin.Schollnick at xerox.com Wed Jan 12 19:03:04 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Wed Jan 12 19:05:39 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton Message-ID: <266589E1B9392B4C9195CC25A07C73B9AA4DCB@usa0300ms04.na.xerox.net> Rayme, This sounds like a Linked List system... I was not able to find quickly a linked list module, but searching by "trees" at the Vaults produced a R/B tree... http://newcenturycomputers.net/projects/rbtree.html I've been out of touch, I have not heard about the Red/Black balanced tree algorithm... Hmm... But take a look and see if it meets your requirements... But take a look at your implementation, if your just trying to make a linked list, you could just use a standard python list.... - Benjamin > -----Original Message----- > From: pythonmac-sig-bounces@python.org > [mailto:pythonmac-sig-bounces@python.org] On Behalf Of Rayme Jernigan > Sent: Wednesday, January 12, 2005 12:53 PM > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] self-instantiating instances in pyhton > > > Hi, > > I'm looking for a language to abuse for a project I'm working on. I > know a little Python, but I do not know if it can do this: > I'd like to > define some class "N" that instantiates objects that can instantiate > fresh new objects of that same class... without external controller > code. > > You could use this capability, for example, to generate a red-black > tree-type data structure that implicitly instantiates a new node for > each new input d1, d2, d3... so on. The algorithm for each node could > be: > > -- Toggle downstream L/R pointer > -- If no node there, instantiate one and link to it > -- if a node is there, pass the datum to it > > The execution sequence as the tree builds itself out might look > something like this: > > 1. n0 = N(d0) # new instance of N > # (downstream pointer default = "Left") > # (the first input data, d0, is > instantiated in node n0) > # nodes: n0 > > 2. n0.send(d1) # toggle n0's downstream pointer to "Right" > # on n0 there is no downstream node > right so instantiate a new > linked node right n1 with d1 > # nodes: n0,n1 > > 3. n0. send(d2) # toggle n0's downstream pointer "Left" > # in n0 there is no downstream node > left so instantiate n2 with d2 > # nodes: n0,n1,n2 > > 4. n0. send(d3) # toggle n0's downstream pointer "Right" > # there exists a downstream node right, > n1, so send d3 there > # toggle n1's downstream pointer "Right" > # in n1 there is no downstream node > right so instantiate n3 with d3 > # nodes: n0,n1,n2,n3 > > 5. n0. send(d4) # toggle n0's downstream pointer "Left" > # there exists a downstream node left, > n2, so send d4 there > # toggle n2's downstream pointer "Right" > # in n2 there is no downstream node > right so instantiate n4 with d4 > # nodes: n0,n1,n2,n3,n4 > > 6. n0.send(d5) # toggle n0's downstream pointer "Right" > # there exists a downstream node right, > n1, so send d5 there > # toggle n1's downstream pointer "Left" > # in n1 there is no downstream node > left so instantiate n5 with d5 > # nodes: n0,n1,n2,n3,n4,n5 > > 7. n0.send(d6) # So on... > # ... > > > Any thoughts about how to do this in Python appreciated. Possible at > all? Thanks in advance, > > -Rayme. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From rayme at pobox.com Wed Jan 12 19:32:26 2005 From: rayme at pobox.com (Rayme Jernigan) Date: Wed Jan 12 19:32:33 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton In-Reply-To: <266589E1B9392B4C9195CC25A07C73B9AA4DCB@usa0300ms04.na.xerox.net> References: <266589E1B9392B4C9195CC25A07C73B9AA4DCB@usa0300ms04.na.xerox.net> Message-ID: <4F39AA13-64C8-11D9-9580-000A95AF4302@pobox.com> Hi Benjamin, I've done this sort of thing with linked lists in Python... by putting all the nodes in a (Python) list, each with a unique ID, and using that ID to link the nodes to each other, etc. But the important thing for me to learn about here... "the goal"... is the self-instantiation aspect of the problem. The R/B tree is just an example I chose to show why you might want to so such a silly thing. ;) Thanks for checking around, though... On Jan 12, 2005, at 1:03 PM, Schollnick, Benjamin wrote: > Rayme, > > This sounds like a Linked List system... > > I was not able to find quickly a linked list module, but > searching by "trees" at the Vaults produced a R/B tree... > > http://newcenturycomputers.net/projects/rbtree.html > > I've been out of touch, I have not heard about the Red/Black > balanced tree algorithm... > > Hmm... But take a look and see if it meets your > requirements... > > But take a look at your implementation, if your just > trying to make a linked list, you could just use a > standard python list.... > > - Benjamin > >> -----Original Message----- >> From: pythonmac-sig-bounces@python.org >> [mailto:pythonmac-sig-bounces@python.org] On Behalf Of Rayme Jernigan >> Sent: Wednesday, January 12, 2005 12:53 PM >> To: pythonmac-sig@python.org >> Subject: [Pythonmac-SIG] self-instantiating instances in pyhton >> >> >> Hi, >> >> I'm looking for a language to abuse for a project I'm working on. I >> know a little Python, but I do not know if it can do this: >> I'd like to >> define some class "N" that instantiates objects that can instantiate >> fresh new objects of that same class... without external controller >> code. >> >> You could use this capability, for example, to generate a red-black >> tree-type data structure that implicitly instantiates a new node for >> each new input d1, d2, d3... so on. The algorithm for each node could >> be: >> >> -- Toggle downstream L/R pointer >> -- If no node there, instantiate one and link to it >> -- if a node is there, pass the datum to it >> >> The execution sequence as the tree builds itself out might look >> something like this: >> >> 1. n0 = N(d0) # new instance of N >> # (downstream pointer default = "Left") >> # (the first input data, d0, is >> instantiated in node n0) >> # nodes: n0 >> >> 2. n0.send(d1) # toggle n0's downstream pointer to "Right" >> # on n0 there is no downstream node >> right so instantiate a new >> linked node right n1 with d1 >> # nodes: n0,n1 >> >> 3. n0. send(d2) # toggle n0's downstream pointer "Left" >> # in n0 there is no downstream node >> left so instantiate n2 with d2 >> # nodes: n0,n1,n2 >> >> 4. n0. send(d3) # toggle n0's downstream pointer "Right" >> # there exists a downstream node right, >> n1, so send d3 there >> # toggle n1's downstream pointer "Right" >> # in n1 there is no downstream node >> right so instantiate n3 with d3 >> # nodes: n0,n1,n2,n3 >> >> 5. n0. send(d4) # toggle n0's downstream pointer "Left" >> # there exists a downstream node left, >> n2, so send d4 there >> # toggle n2's downstream pointer "Right" >> # in n2 there is no downstream node >> right so instantiate n4 with d4 >> # nodes: n0,n1,n2,n3,n4 >> >> 6. n0.send(d5) # toggle n0's downstream pointer "Right" >> # there exists a downstream node right, >> n1, so send d5 there >> # toggle n1's downstream pointer "Left" >> # in n1 there is no downstream node >> left so instantiate n5 with d5 >> # nodes: n0,n1,n2,n3,n4,n5 >> >> 7. n0.send(d6) # So on... >> # ... >> >> >> Any thoughts about how to do this in Python appreciated. Possible at >> all? Thanks in advance, >> >> -Rayme. >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > From Jack.Jansen at cwi.nl Wed Jan 12 23:13:40 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Jan 12 23:13:10 2005 Subject: [Pythonmac-SIG] [visexnotifier1@mindvision.com: MindVision Releases VISE X 1.5 for Mac OS X] In-Reply-To: <53C55AC0-636C-11D9-9F71-000A95BA5446@redivi.com> References: <20050111003335.GD14363@janus.swcomplete.com> <53C55AC0-636C-11D9-9F71-000A95BA5446@redivi.com> Message-ID: <36B6A900-64E7-11D9-B7C6-000D934FF6B4@cwi.nl> On 11-jan-05, at 2:01, Bob Ippolito wrote: > > On Jan 10, 2005, at 19:33, Neal Norwitz wrote: > >> I thought this might be of interest here. The PSF owns a license to >> VISE. Jack knows the details. > > I think that this is only really relevant to Mac OS9. I'm not sure if > Jack plans to make another release for OS9? I plan to do a final 2.3.5 release. But that does depend on my OS9 partition still starting up (I've reshuffled things), I'm not going to install OS9 and CodeWarrior and all that from scratch. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From hengist.podd at virgin.net Thu Jan 13 00:49:00 2005 From: hengist.podd at virgin.net (has) Date: Thu Jan 13 00:49:20 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton Message-ID: Rayme Jernigan wrote: >I'm looking for a language to abuse for a project I'm working on. I >know a little Python, but I do not know if it can do this: I'd like to >define some class "N" that instantiates objects that can instantiate >fresh new objects of that same class... without external controller >code. This the sort of thing you mean? class _Base: def __call__(self, *args, **kargs): return self.__class__(*args, **kargs) class Foo(_Base): pass class Bar(_Base): pass f = Foo() b = Bar() print f, f() print b, b() HTH has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Jan 13 01:14:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 13 01:14:26 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton In-Reply-To: References: <4898DF36-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> Message-ID: <12370A0E-64F8-11D9-B569-000A95BA5446@redivi.com> On Jan 12, 2005, at 12:52, Rayme Jernigan wrote: > Hi, > > I'm looking for a language to abuse for a project I'm working on. I > know a little Python, but I do not know if it can do this: I'd like to > define some class "N" that instantiates objects that can instantiate > fresh new objects of that same class... without external controller > code. > > You could use this capability, for example, to generate a red-black > tree-type data structure that implicitly instantiates a new node for > each new input d1, d2, d3... so on. The algorithm for each node could > be: > > -- Toggle downstream L/R pointer > -- If no node there, instantiate one and link to it > -- if a node is there, pass the datum to it > > The execution sequence as the tree builds itself out might look > something like this: > > 1. n0 = N(d0) # new instance of N > # (downstream pointer default = "Left") > # (the first input data, d0, is instantiated in node n0) > # nodes: n0 > > 2. n0.send(d1) # toggle n0's downstream pointer to "Right" > # on n0 there is no downstream node right so instantiate a new > linked node right n1 with d1 > # nodes: n0,n1 > > 3. n0. send(d2) # toggle n0's downstream pointer "Left" > # in n0 there is no downstream node left so instantiate n2 with d2 > # nodes: n0,n1,n2 > > 4. n0. send(d3) # toggle n0's downstream pointer "Right" > # there exists a downstream node right, n1, so send d3 there > # toggle n1's downstream pointer "Right" > # in n1 there is no downstream node right so instantiate n3 with d3 > # nodes: n0,n1,n2,n3 > > 5. n0. send(d4) # toggle n0's downstream pointer "Left" > # there exists a downstream node left, n2, so send d4 there > # toggle n2's downstream pointer "Right" > # in n2 there is no downstream node right so instantiate n4 with d4 > # nodes: n0,n1,n2,n3,n4 > > 6. n0.send(d5) # toggle n0's downstream pointer "Right" > # there exists a downstream node right, n1, so send d5 there > # toggle n1's downstream pointer "Left" > # in n1 there is no downstream node left so instantiate n5 with d5 > # nodes: n0,n1,n2,n3,n4,n5 > > 7. n0.send(d6) # So on... > # ... > > > Any thoughts about how to do this in Python appreciated. Possible at > all? Thanks in advance, I would guess that you'd want an implementation that looks kinda like this: class RBNode(object): def __init__(self, value): self.index = 0 self.nodes = [None, None] self.value = value def send(self, value): node = self.nodes[self.index] if node is None: # use type(self) so that if this is a subclass, # then the subclass would be used rather than # RBNode self.nodes[self.index] = type(self)(value) else: node.send(value) self.index = (self.index + 1) % len(self.nodes) -bob From piet at cs.uu.nl Thu Jan 13 10:19:36 2005 From: piet at cs.uu.nl (Piet van Oostrum) Date: Thu Jan 13 10:19:40 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton In-Reply-To: (Rayme Jernigan's message of "Wed, 12 Jan 2005 12:52:54 -0500") References: <4898DF36-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> Message-ID: >>>>> Rayme Jernigan (RJ) wrote: RJ> Hi, RJ> I'm looking for a language to abuse for a project I'm working on. I know a RJ> little Python, but I do not know if it can do this: I'd like to define some RJ> class "N" that instantiates objects that can instantiate fresh new objects RJ> of that same class... without external controller code. Every instance of a class can instantiate new objects of that class. I don't know a programming language where that is not possible. But what do you mean with external controller code? -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: piet@vanoostrum.net From charles.hartman at conncoll.edu Thu Jan 13 13:55:45 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Jan 13 13:55:55 2005 Subject: [Pythonmac-SIG] RegEx 101 (or 102?) Message-ID: <70DC6CE3-6562-11D9-9698-000D933C27EA@conncoll.edu> Not quite Python, not quite Mac -- but I'm stalled on something about REs that I ought to know but can't seem to find. I want to search a string like '/xx/x/x/xx' for the *longest* match of 'x[x/]' -- that is, the longest sequence of pairs whose first member is 'x' and whose second member is either 'x' or '/'. The obvious solution is for grp in sre.finditer( '(x[x/])+' , str): if But this doesn't work, and every approach I've thought of seems to have the same problem: Searching / x x / x / x / x x the pattern first finds the 'xx' beginning at position 1, and then the 'x/x/xx' beginning in position 4. But it doesn't find the 'x/x/x/xx' beginning at position 2. I guess it starts looking for the next group after, not in the middle of, the group it's already found. The solutions that occur to me are pretty Rube Goldberg (run the search multiple times, cutting one character off the beginning of the string each time . . .) I know there's a better solution. Charles Hartman From charles.hartman at conncoll.edu Thu Jan 13 14:20:04 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Jan 13 14:20:09 2005 Subject: [Pythonmac-SIG] RegEx oops Message-ID: Sorry, that was a dumb question. I forgot about for i in range(len(str) - 3): fnd = pattern.search(str, i) if fnd (Why do I think of these things one [1] minute after posting a question in desperation? Law of nature?) Charles Hartman From rayme at pobox.com Thu Jan 13 15:41:30 2005 From: rayme at pobox.com (Rayme Jernigan) Date: Thu Jan 13 15:41:39 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton In-Reply-To: References: <4898DF36-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> Message-ID: <3653CB5E-6571-11D9-AFE5-000A95AF4302@pobox.com> Hi Piet, Thanks to you, and everyone for your thoughts on this. By "external controller code" I mean code that would instantiate, keep track of and manipulate these objects. So the second part of the problem is transfer of control to the new node object. Put another way, in the purest implementation the only code in the tree program would "node code." Cooperative multitasking where each node could instantiate; and signal, save state and transfer control it's children and vice versa would be one way to do this, but I don't think that's supported in Python... Thx, -Rayme. On Jan 13, 2005, at 4:19 AM, Piet van Oostrum wrote: >>>>>> Rayme Jernigan (RJ) wrote: > > RJ> Hi, > RJ> I'm looking for a language to abuse for a project I'm working on. > I know a > RJ> little Python, but I do not know if it can do this: I'd like to > define some > RJ> class "N" that instantiates objects that can instantiate fresh new > objects > RJ> of that same class... without external controller code. > > Every instance of a class can instantiate new objects of that class. I > don't know a programming language where that is not possible. But what > do > you mean with external controller code? > -- > Piet van Oostrum > URL: http://www.cs.uu.nl/~piet [PGP] > Private email: piet@vanoostrum.net > From matsakis at mit.edu Thu Jan 13 17:46:49 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Thu Jan 13 17:46:53 2005 Subject: [Pythonmac-SIG] Appscript Binary Installer Feedback Message-ID: Greetings. I'm putting together a binary installer for Appscript and friends --- instead of installing seven different components, it will be able to be done in a single install without any dependencies on the developers tools being installed. The components being installed include: appscript, aem, carbonAE, HTMLTemplate, LaunchServices, osaterminology, and osax. The basics of the install are simple, but there are a few subtleties that have come up, and I would like to solicit some feedback from you all on the following issues. ** Permissions ** Are there any special permissions that need to be respected? Specifically, do .so files need to be executable to work properly? Is there a reason that any of the .py files should need to be executed as a shell script? ** Licenses ** The installed components are licensed under the LGPL and Python licenses. My reading of these is that we just need to have links to the source versions on the same server that the binary is distributed from and we'll be ok. I wasn't going to have the user click-through a license agreement when installing the software (I find these annoying myself). ** Documentation and Support Apps ** Unlike the Python software components, which must be installed in /Library/Python/2.3, the helper apps (RenderTerminology and AppscriptTerminologyServer) and documentation for Appscript can be installed anywhere, or not at all. In particular, I could envision a user who wants to download and tweak/run an appscript but not actually write appscripts himself. There are basically two courses of action here, either install this stuff automatically or have the user do a drag install. In the first case, a default location for these should be specified. I would suggest /Application/Applescript/Python (/Applications/Applescript/Appscript is another option, but I find the similarity between Applescript and Appscript confusing). My preference, though, is to _not_ install these components, but provide them on the installer disk image. Anyone who is going to write appscripts should be comfortable with a drag install, and I generally prefer that installers only install things that are required to go in a particular place in the filesystem to work. Comments? Nick Matsakis From bob at redivi.com Thu Jan 13 17:54:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 13 17:55:04 2005 Subject: [Pythonmac-SIG] Appscript Binary Installer Feedback In-Reply-To: References: Message-ID: On Jan 13, 2005, at 11:46, Nick Matsakis wrote: > > Greetings. I'm putting together a binary installer for Appscript and > friends --- instead of installing seven different components, it will > be > able to be done in a single install without any dependencies on the > developers tools being installed. The components being installed > include: > appscript, aem, carbonAE, HTMLTemplate, LaunchServices, osaterminology, > and osax. > > The basics of the install are simple, but there are a few subtleties > that > have come up, and I would like to solicit some feedback from you all on > the following issues. > > ** Permissions ** > Are there any special permissions that need to be respected? > Specifically, do .so files need to be executable to work properly? Is > there a reason that any of the .py files should need to be executed as > a > shell script? No, none of the .so files need any special permissions. > ** Licenses ** > The installed components are licensed under the LGPL and Python > licenses. > My reading of these is that we just need to have links to the source > versions on the same server that the binary is distributed from and > we'll > be ok. I wasn't going to have the user click-through a license > agreement > when installing the software (I find these annoying myself). No, you do not need links to the source for either of these licenses. Click-through is pretty standard with an installer package, I'd go ahead and do it. > ** Documentation and Support Apps ** > Unlike the Python software components, which must be installed in > /Library/Python/2.3, the helper apps (RenderTerminology and > AppscriptTerminologyServer) and documentation for Appscript can be > installed anywhere, or not at all. In particular, I could envision a > user > who wants to download and tweak/run an appscript but not actually write > appscripts himself. > > There are basically two courses of action here, either install this > stuff > automatically or have the user do a drag install. In the first case, a > default location for these should be specified. I would suggest > /Application/Applescript/Python (/Applications/Applescript/Appscript > is > another option, but I find the similarity between Applescript and > Appscript confusing). > > My preference, though, is to _not_ install these components, but > provide > them on the installer disk image. Anyone who is going to write > appscripts > should be comfortable with a drag install, and I generally prefer that > installers only install things that are required to go in a particular > place in the filesystem to work. I would install them automatically. If they are on the disk image, people will run them before installing, and they will not work due to missing dependencies. If they're built with bundlebuilder, they'll probably just bounce and disappear with no error. Are you using py2app's bdist_mpkg to build this package or are you doing it by hand? -bob From matsakis at mit.edu Thu Jan 13 18:00:07 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Thu Jan 13 18:00:09 2005 Subject: [Pythonmac-SIG] Appscript Binary Installer Feedback In-Reply-To: References: Message-ID: On Thu, 13 Jan 2005, Bob Ippolito wrote: > Click-through is pretty standard with an installer package, I'd go > ahead and do it. Why? Does it indemnify anyone if someone uses appscript to run a nuclear sub? No one reads that stuff anyway. > I would install them automatically. If they are on the disk image, > people will run them before installing, and they will not work due to > missing dependencies. These apps are faceless background apps that help speed appscript but are not required for it to run properly. > Are you using py2app's bdist_mpkg to build this package or are you > doing it by hand? I'm using Apple's PackageMaker tool. Nick From bob at redivi.com Thu Jan 13 18:06:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 13 18:06:43 2005 Subject: [Pythonmac-SIG] Appscript Binary Installer Feedback In-Reply-To: References: Message-ID: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> On Jan 13, 2005, at 12:00, Nick Matsakis wrote: > On Thu, 13 Jan 2005, Bob Ippolito wrote: > >> Click-through is pretty standard with an installer package, I'd go >> ahead and do it. > > Why? Does it indemnify anyone if someone uses appscript to run a > nuclear > sub? No one reads that stuff anyway. I'll usually glimpse at the top to see which license it is. If I want a hassle-free install, I use installer from the command line. >> I would install them automatically. If they are on the disk image, >> people will run them before installing, and they will not work due to >> missing dependencies. > > These apps are faceless background apps that help speed appscript but > are > not required for it to run properly. Even more reason to have them installed behind the scenes. The point is that if you put applications on the disk image, people will click on them and expect them to do something. They won't, so there is no reason to have them out there. >> Are you using py2app's bdist_mpkg to build this package or are you >> doing it by hand? > > I'm using Apple's PackageMaker tool. Why? bdist_mpkg a lot of this correctly and automatically. You should at least use bdist_mpkg to make easy packages out of the installable-by-distutils stuff. Since you are not the author, it might make sense to do the documentation and examples by hand rather than putting in the effort to subclass the bdist_mpkg command and add those schemes (see py2app or PyObjC's setup.py for examples). If you do use bdist_mpkg, use it from trunk, I made some enhancements. -bob From matsakis at mit.edu Thu Jan 13 18:54:14 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Thu Jan 13 18:54:16 2005 Subject: [Pythonmac-SIG] Re: Appscript Binary Installer Feedback In-Reply-To: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> References: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> Message-ID: On Thu, 13 Jan 2005, Bob Ippolito wrote: > Even more reason to have them installed behind the scenes. Where should they be installed, then? I think the appscript folder in /Library/Python/2.3 is the best place for them. Nick From bob at redivi.com Thu Jan 13 19:02:27 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 13 19:02:33 2005 Subject: [Pythonmac-SIG] Re: Appscript Binary Installer Feedback In-Reply-To: References: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> Message-ID: <48ECCB4B-658D-11D9-94F0-000A95BA5446@redivi.com> On Jan 13, 2005, at 12:54, Nick Matsakis wrote: > On Thu, 13 Jan 2005, Bob Ippolito wrote: > >> Even more reason to have them installed behind the scenes. > > Where should they be installed, then? I think the appscript folder in > /Library/Python/2.3 is the best place for them. What I meant by "behind the scenes" was that they should be installed by the installer, not drag+drop installed by the user. If you put these applications in the user's face they *will* click on them, and be disappointed/confused when they don't do anything (because appscript isn't installed *and* because they have no UI). Their installation destination depends on what kind of interaction the user will have with them, if any. If appscript will start them on its own, then the same location as the Python package makes some sense, but I would put them in a directory that is clearly not a subpackage (i.e. a directory with-a-hyphen-in-it). -bob From wolfgang.keller.nospam at gmx.de Thu Jan 13 21:03:28 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Thu Jan 13 21:03:34 2005 Subject: [Pythonmac-SIG] Folder Actions in Python? Message-ID: Hello, this may potentially be a dumb FAQ, but: Is there a way to write "folder actions" for MacOS X in Python? I would guess to enable this the corresponding script would at least have to be applescript-able itself...? Related question: I read somewhere that FreeBSD has a similar notification mechanism built-in - is this feature available in MacOS X as well or does it depend on the "native" BSD filesystem? If it is available, is there a way (preferably without havong to learn C) to use it from Python on MacOS X? Any other way to implement such a function in Python without having to poll the corresponding folder all the time (ouch)? TIA, Best regards Wolfgang Keller From rayme at pobox.com Thu Jan 13 21:31:09 2005 From: rayme at pobox.com (Rayme Jernigan) Date: Thu Jan 13 21:31:16 2005 Subject: [Pythonmac-SIG] self-instantiating instances in pyhton In-Reply-To: <12370A0E-64F8-11D9-B569-000A95BA5446@redivi.com> References: <4898DF36-61C3-11D9-B0FB-000D934FF6B4@cwi.nl> <12370A0E-64F8-11D9-B569-000A95BA5446@redivi.com> Message-ID: <0EEBF986-65A2-11D9-AFE5-000A95AF4302@pobox.com> You guess right... this is the type of approach I was looking for. Thanks!! On Jan 12, 2005, at 7:14 PM, Bob Ippolito wrote: > > On Jan 12, 2005, at 12:52, Rayme Jernigan wrote: > >> Hi, >> >> I'm looking for a language to abuse for a project I'm working on. I >> know a little Python, but I do not know if it can do this: I'd like >> to define some class "N" that instantiates objects that can >> instantiate fresh new objects of that same class... without external >> controller code. >> >> You could use this capability, for example, to generate a red-black >> tree-type data structure that implicitly instantiates a new node for >> each new input d1, d2, d3... so on. The algorithm for each node could >> be: >> >> -- Toggle downstream L/R pointer >> -- If no node there, instantiate one and link to it >> -- if a node is there, pass the datum to it >> >> The execution sequence as the tree builds itself out might look >> something like this: >> >> 1. n0 = N(d0) # new instance of N >> # (downstream pointer default = "Left") >> # (the first input data, d0, is instantiated in node n0) >> # nodes: n0 >> >> 2. n0.send(d1) # toggle n0's downstream pointer to "Right" >> # on n0 there is no downstream node right so instantiate a new >> linked node right n1 with d1 >> # nodes: n0,n1 >> >> 3. n0. send(d2) # toggle n0's downstream pointer "Left" >> # in n0 there is no downstream node left so instantiate n2 with d2 >> # nodes: n0,n1,n2 >> >> 4. n0. send(d3) # toggle n0's downstream pointer "Right" >> # there exists a downstream node right, n1, so send d3 there >> # toggle n1's downstream pointer "Right" >> # in n1 there is no downstream node right so instantiate n3 with d3 >> # nodes: n0,n1,n2,n3 >> >> 5. n0. send(d4) # toggle n0's downstream pointer "Left" >> # there exists a downstream node left, n2, so send d4 there >> # toggle n2's downstream pointer "Right" >> # in n2 there is no downstream node right so instantiate n4 with d4 >> # nodes: n0,n1,n2,n3,n4 >> >> 6. n0.send(d5) # toggle n0's downstream pointer "Right" >> # there exists a downstream node right, n1, so send d5 there >> # toggle n1's downstream pointer "Left" >> # in n1 there is no downstream node left so instantiate n5 with d5 >> # nodes: n0,n1,n2,n3,n4,n5 >> >> 7. n0.send(d6) # So on... >> # ... >> >> >> Any thoughts about how to do this in Python appreciated. Possible at >> all? Thanks in advance, > > I would guess that you'd want an implementation that looks kinda like > this: > > class RBNode(object): > def __init__(self, value): > self.index = 0 > self.nodes = [None, None] > self.value = value > > def send(self, value): > node = self.nodes[self.index] > if node is None: > # use type(self) so that if this is a subclass, > # then the subclass would be used rather than > # RBNode > self.nodes[self.index] = type(self)(value) > else: > node.send(value) > self.index = (self.index + 1) % len(self.nodes) > > -bob > From bob at redivi.com Thu Jan 13 22:21:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 13 22:21:36 2005 Subject: [Pythonmac-SIG] Re: Appscript Binary Installer Feedback In-Reply-To: References: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> <48ECCB4B-658D-11D9-94F0-000A95BA5446@redivi.com> Message-ID: <17E94382-65A9-11D9-9A68-000A95BA5446@redivi.com> On Jan 13, 2005, at 15:43, has wrote: > Nick wrote: > >> These apps are faceless background apps that help speed appscript but >> are >> not required for it to run properly. > > AppscriptTerminologyServer is a scriptable FBA that enhances > appscript's performance and remote scripting support. > RenderTerminology is a convenient drag-n-drop end-user app for > rendering application terminologies to HTML files. Both need to be > launched by the user, though ASTS can optionally be added to Login > Items to launch automatically at startup. So then they shouldn't be in site-packages, because they should be accessible to the user. Either /Developer/Somewhere or /Applications/Somewhere. I use /Developer/Applications/Python Tools/packagename/ when I build packages (similar to Java Tools, but using a package namespace). -bob From bob at redivi.com Thu Jan 13 22:30:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 13 22:30:57 2005 Subject: [Pythonmac-SIG] Folder Actions in Python? In-Reply-To: References: Message-ID: <655B2D00-65AA-11D9-9A68-000A95BA5446@redivi.com> On Jan 13, 2005, at 15:03, Wolfgang Keller wrote: > Is there a way to write "folder actions" for MacOS X in Python? I would > guess to enable this the corresponding script would at least have to be > applescript-able itself...? You'd need to write an applescript that spawns a Python process (or talks to a Python application via some means like XML-RPC or apple events). > Related question: I read somewhere that FreeBSD has a similar > notification > mechanism built-in - is this feature available in MacOS X as well or > does > it depend on the "native" BSD filesystem? If it is available, is there > a > way (preferably without havong to learn C) to use it from Python on > MacOS > X? This feature is available in Mac OS X 10.3 and later. Using it from Python on Mac OS X requires either patching some ancient C extension for kqueue and calling it from Python, writing your own extension, using ctypes or PyObjC 1.2 to call directly into it, or using PyObjC to talk to an Objective-C wrapper (ReSTedit does this). There are no examples that I'm aware of beyond ReSTedit, and it does not monitor directories, only files. I believe that there is a limitation in kqueue that will only tell you that something in the directory has changed, but not what is changed, so I think some sort of "polling" needs to be done to figure out what actually did change. At least that's what I remember from hearing about the FreeBSD implementation, I'm not aware if Darwin has implemented any enhancements to kqueue. > Any other way to implement such a function in Python without having to > poll > the corresponding folder all the time (ouch)? Not really, unless you install FAM (may need to find a patch for kqueue, don't know if they support it yet) or dnotify and talk to that. I believe that Finder uses a combination of polling and notifications. Properly written Mac OS X applications will send out a notification when they modify a file (this can be done with either Cocoa or Carbon), and Finder uses this to immediately update its views. It also polls to pick up changes done by lower level APIs, but I'm not sure at what frequency (it might be when the user acts on a Finder view, or something). -bob From hengist.podd at virgin.net Thu Jan 13 22:54:04 2005 From: hengist.podd at virgin.net (has) Date: Thu Jan 13 22:54:09 2005 Subject: [Pythonmac-SIG] Re: Appscript Binary Installer Feedback In-Reply-To: <48ECCB4B-658D-11D9-94F0-000A95BA5446@redivi.com> References: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> <48ECCB4B-658D-11D9-94F0-000A95BA5446@redivi.com> Message-ID: Nick wrote: >These apps are faceless background apps that help speed appscript but are >not required for it to run properly. AppscriptTerminologyServer is a scriptable FBA that enhances appscript's performance and remote scripting support. RenderTerminology is a convenient drag-n-drop end-user app for rendering application terminologies to HTML files. Both need to be launched by the user, though ASTS can optionally be added to Login Items to launch automatically at startup. Hope that clarifies, has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Thu Jan 13 23:14:40 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Jan 13 23:14:07 2005 Subject: [Pythonmac-SIG] Testers needed again: Fix installer 1.2 In-Reply-To: <50a522ca0501110209b2e1c8d@mail.gmail.com> References: <8F295280-5B24-11D9-81BB-000D934FF6B4@cwi.nl> <50a522ca0501110209b2e1c8d@mail.gmail.com> Message-ID: <84E4FE05-65B0-11D9-A3F8-000D934FF6B4@cwi.nl> On 11-jan-05, at 11:09, Michael Twomey wrote: > Hi, > > I just tried out the installer and it works fine, but it appears to > have littered my disk with CVS directories, was that intentional? (I'm > guessing not) Good catch! I've created a new installer that doesn't have this problem. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From hengist.podd at virgin.net Thu Jan 13 23:23:18 2005 From: hengist.podd at virgin.net (has) Date: Thu Jan 13 23:24:27 2005 Subject: [Pythonmac-SIG] Re: Appscript Binary Installer Feedback In-Reply-To: <17E94382-65A9-11D9-9A68-000A95BA5446@redivi.com> References: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> <48ECCB4B-658D-11D9-94F0-000A95BA5446@redivi.com> <17E94382-65A9-11D9-9A68-000A95BA5446@redivi.com> Message-ID: Bob wrote: [AppscriptTerminologyServer & RenderTerminology] >So then they shouldn't be in site-packages, because they should be >accessible to the user. Either /Developer/Somewhere or >/Applications/Somewhere. I use /Developer/Applications/Python >Tools/packagename/ when I build packages (similar to Java Tools, but >using a package namespace). /Applications/Somewhere might seem a bit more friendly and familiar to novices and newcomers. What would be the advantages of /Developer/Somewhere? Sticking them in with other MacPython-related apps in /Applications/MacPython-2.x may be option option, though may be better from a marketing PoV to use a more high-profile, visible location like /Applications/Appscript (could maybe stick the appscript docs in there too). HTH has p.s. Incidentally, if we could think of some way to make the appscript documentation show up in Help Center like MacPython's does, that'd be an additional plus. -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Thu Jan 13 23:38:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 13 23:38:47 2005 Subject: [Pythonmac-SIG] Re: Appscript Binary Installer Feedback In-Reply-To: References: <7AB9CD55-6585-11D9-94F0-000A95BA5446@redivi.com> <48ECCB4B-658D-11D9-94F0-000A95BA5446@redivi.com> <17E94382-65A9-11D9-9A68-000A95BA5446@redivi.com> Message-ID: On Jan 13, 2005, at 17:23, has wrote: > Bob wrote: > > [AppscriptTerminologyServer & RenderTerminology] > >> So then they shouldn't be in site-packages, because they should be >> accessible to the user. Either /Developer/Somewhere or >> /Applications/Somewhere. I use /Developer/Applications/Python >> Tools/packagename/ when I build packages (similar to Java Tools, but >> using a package namespace). > > /Applications/Somewhere might seem a bit more friendly and familiar to > novices and newcomers. What would be the advantages of > /Developer/Somewhere? Sticking them in with other MacPython-related > apps in /Applications/MacPython-2.x may be option option, though may > be better from a marketing PoV to use a more high-profile, visible > location like /Applications/Appscript (could maybe stick the appscript > docs in there too). /Developer/Somewhere is where all of the other developer applications are (Xcode, etc.). > p.s. Incidentally, if we could think of some way to make the appscript > documentation show up in Help Center like MacPython's does, that'd be > an additional plus. That's certainly possible, especially if it's HTML. I don't have time right now to explain how, but Apple has documentation on this. You'd need to put the documentation inside of an application (possibly the terminology server), though. It also doesn't get into the index until first launch, I think. -bob From gandreas at gandreas.com Fri Jan 14 02:56:28 2005 From: gandreas at gandreas.com (Glenn Andreas) Date: Fri Jan 14 02:56:31 2005 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.7.1 - Cocoa based Python IDE Message-ID: <813B5120-65CF-11D9-8AD6-000D9346E10A@gandreas.com> PyOXIDE 0.7.1 is now available for abuse. It now allows for creating PyObjC applications from a project (it still uses bundlebuilder - support for py2app is forthcoming). This includes setting destinations within the bundle for project components, as well as an InfoPList editor and even supports debugging your PyObjC application. PyOXIDE 0.7.1 has only been tested with 10.3.6, but should work with 10.2 (assuming it can find the python framework). The sources are built using XCode 1.5 on 10.3.6 PyOXIDE 0.7.1 is now available on my idisk (as PyOXIDE_0.7.1.dmg): from the pather finder, "connect to other public folder" and type in "gandreas" or http://projects.gandreas.com/pyoxide/ or hopefully you should just be able to "check for update" from within PyOXIDE itself. If you want to build from source, you'll need to get PyOXIDE_Src_0.7.1.dmg, and IDEKit_0.3.1.dmg (also built XCode 1.5 on 10.3.6). IDEKit_0.3.1.dmg is found either on the idisk above or PyOXIDE source is covered under a BSD-style license. The IDEKit framework is covered under LGPL, so you can freely link it in other projects. Glenn Andreas????????????????????? gandreas@gandreas.com? oh my! Mad, Bad, and Dangerous to Know From lanceboyle at cwazy.co.uk Fri Jan 14 03:10:51 2005 From: lanceboyle at cwazy.co.uk (Lance Boyle) Date: Fri Jan 14 03:10:59 2005 Subject: [Pythonmac-SIG] Python access to RS-232, USB, MIDI? In-Reply-To: <813B5120-65CF-11D9-8AD6-000D9346E10A@gandreas.com> References: <813B5120-65CF-11D9-8AD6-000D9346E10A@gandreas.com> Message-ID: <83CABDC2-65D1-11D9-AFBD-003065F93FF0@cwazy.co.uk> I'm brainstorming on a project that involves communicating with a head tracker (I need only azimuth). I haven't decided on an actual head tracker, but am looking at a Polhemus. (Comments on head trackers are also welcomed--gaming devices or 3D mice?) It looks like that I might need to communicate via RS-232 or USB (is there a MIDI tracker?). I want to keep this simple and clobber the problem with minimum fuss, so naturally I think of Python, AppleScript, etc. I'm pretty much a neophyte with such things (although I wrote a 3D plotting program for a Tektronix pen plotter a _long_ time ago). So--can Python help me? AppScript? Thanks, Jerry From bob at redivi.com Fri Jan 14 03:51:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 14 03:51:16 2005 Subject: [Pythonmac-SIG] Python access to RS-232, USB, MIDI? In-Reply-To: <83CABDC2-65D1-11D9-AFBD-003065F93FF0@cwazy.co.uk> References: <813B5120-65CF-11D9-8AD6-000D9346E10A@gandreas.com> <83CABDC2-65D1-11D9-AFBD-003065F93FF0@cwazy.co.uk> Message-ID: <24AB2F06-65D7-11D9-8F98-000A95BA5446@redivi.com> On Jan 13, 2005, at 21:10, Lance Boyle wrote: > I'm brainstorming on a project that involves communicating with a head > tracker (I need only azimuth). I haven't decided on an actual head > tracker, but am looking at a Polhemus. (Comments on head trackers are > also welcomed--gaming devices or 3D mice?) > > It looks like that I might need to communicate via RS-232 or USB (is > there a MIDI tracker?). I want to keep this simple and clobber the > problem with minimum fuss, so naturally I think of Python, > AppleScript, etc. I'm pretty much a neophyte with such things > (although I wrote a 3D plotting program for a Tektronix pen plotter a > _long_ time ago). > > So--can Python help me? AppScript? appscript / AppleScript isn't really going to do anything for you. Python can talk to serial devices just fine using pySerial. I'd recommend against using something other than serial because it will be more work. USB<->Serial converters work just fine, of course. I've done it with pySerial + Twisted for GPS devices and proprietary packet data modems, but it works fine with just pySerial if you don't mind blocking. Alternatively you can buy a serial<->TCP/IP box and just write it like any other network app with a line-based TCP protocol. -bob From jack at uitdesloot.nl Fri Jan 14 00:09:23 2005 From: jack at uitdesloot.nl (Jack Jansen) Date: Fri Jan 14 10:39:15 2005 Subject: [Pythonmac-SIG] Any suggestions for a questionnaire site? Message-ID: <29A2CD8C-65B8-11D9-A3F8-000D934FF6B4@uitdesloot.nl> Folks, I want to do a questionnaire shortly, on the subject of which installers people want most (2.{3,4}.X for 10.{2,3}, mainly). That'll help me spend my time most efficiently (my MacPython time, that is:-) Does anyone know of a decent site that hosts such questionnaires that is both easy to use and cheap (preferably free:-)? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From mjb at uma.pt Fri Jan 14 12:19:28 2005 From: mjb at uma.pt (Michael J. Barber) Date: Fri Jan 14 12:18:48 2005 Subject: [Pythonmac-SIG] Folder Actions in Python? In-Reply-To: References: Message-ID: <27E6FDA2-661E-11D9-9042-0050E4794D0F@uma.pt> You could write a folder action in AppleScript that uses "do shell script" in the Standard Additions to call out to a python script. The amount of AppleScript needed should be pretty minimal. On Jan 13, 2005, at 8:03 PM, Wolfgang Keller wrote: > Is there a way to write "folder actions" for MacOS X in Python? I would > guess to enable this the corresponding script would at least have to be > applescript-able itself...? From arthur at iaaa.nl Fri Jan 14 14:25:59 2005 From: arthur at iaaa.nl (Arthur Elsenaar) Date: Fri Jan 14 14:26:04 2005 Subject: [Pythonmac-SIG] Python access to RS-232, USB, MIDI? In-Reply-To: <83CABDC2-65D1-11D9-AFBD-003065F93FF0@cwazy.co.uk> References: <813B5120-65CF-11D9-8AD6-000D9346E10A@gandreas.com> <83CABDC2-65D1-11D9-AFBD-003065F93FF0@cwazy.co.uk> Message-ID: On Jan 14, 2005, at 02:10, Lance Boyle wrote: > I'm brainstorming on a project that involves communicating with a head > tracker (I need only azimuth). I haven't decided on an actual head > tracker, but am looking at a Polhemus. (Comments on head trackers are > also welcomed--gaming devices or 3D mice?) > > It looks like that I might need to communicate via RS-232 or USB (is > there a MIDI tracker?). I want to keep this simple and clobber the > problem with minimum fuss, so naturally I think of Python, > AppleScript, etc. I'm pretty much a neophyte with such things > (although I wrote a 3D plotting program for a Tektronix pen plotter a > _long_ time ago). Have a look at what http://www.makingthings.com has to offer. They built really nice IO modules (USB, serial, etc.) for mere mortals (read artists) that hook up to almost anything from Flash to Max/MSP, Java, C, etc. I haven't checked recently if there's a python binding already, but it shouldn't be hard for an experienced programmer to create. We've had great success with our art students working with these modules. Arthur From delza at livingcode.org Fri Jan 14 15:58:38 2005 From: delza at livingcode.org (Dethe Elza) Date: Fri Jan 14 15:58:46 2005 Subject: [Pythonmac-SIG] Any suggestions for a questionnaire site? In-Reply-To: <29A2CD8C-65B8-11D9-A3F8-000D934FF6B4@uitdesloot.nl> References: <29A2CD8C-65B8-11D9-A3F8-000D934FF6B4@uitdesloot.nl> Message-ID: Jack, No personal experience with these, but a quick google shows: http://free-online-surveys.co.uk/ http://freesurveysonline.com/ http://freeonlinesurveys.com/ No idea how reputable any of these are... If all you want is a simple poll, my livingcode.org site is running on DreamHost, which offers a polling component. I haven't tried it, but I'd be willing to figure it out and host the poll. I seem to remember Sourceforge-hosted sites with polls, but I can't find any info on Sourceforge about their support for it. HTH --Dethe There are only two industries that call their customers "users" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050114/632f490f/smime.bin From fbartlet at optonline.net Fri Jan 14 17:17:19 2005 From: fbartlet at optonline.net (fbartlet@optonline.net) Date: Fri Jan 14 17:17:21 2005 Subject: [Pythonmac-SIG] Anyone script ChemDraw w/ Python? Message-ID: <14ce8014f2ae.14f2ae14ce80@optonline.net> Gentlefolk, I have a mess of VBA and AppleScript scripts I wrote to automate Word & ChemDraw tasks. Now that everyone who needs this stuff has access to OS X, I thought I might try Python to make some improvements I've been asked for and which VBA and AppleScript don't seem to be able to deliver. While I've used Python to script Word under Windows, I'm not terribly knowledgeable about Macs; so any and all clues will be received gratefully. Thanks, Fred From bob at redivi.com Fri Jan 14 18:00:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 14 18:00:29 2005 Subject: [Pythonmac-SIG] Any suggestions for a questionnaire site? In-Reply-To: References: <29A2CD8C-65B8-11D9-A3F8-000D934FF6B4@uitdesloot.nl> Message-ID: On Jan 14, 2005, at 9:58, Dethe Elza wrote: > No personal experience with these, but a quick google shows: > > http://free-online-surveys.co.uk/ > http://freesurveysonline.com/ > http://freeonlinesurveys.com/ > > No idea how reputable any of these are... > > If all you want is a simple poll, my livingcode.org site is running on > DreamHost, which offers a polling component. I haven't tried it, but > I'd be willing to figure it out and host the poll. pythonmac.org is also on DreamHost, and I'd do the same. -bob > From kranki at mac.com Fri Jan 14 19:29:56 2005 From: kranki at mac.com (Robert White) Date: Fri Jan 14 19:26:50 2005 Subject: [Pythonmac-SIG] Using .pth to adjust Python on startup Message-ID: <4A7D28AE-665A-11D9-A7F8-000A95A94FC8@mac.com> Last night, while researching a different problem, I ran across the usage of 'import' within ".pth" to run arbitrary code as the Python environment is being initialized. I believe that this provides an alternative to using PYTHONPATH and possibly some of the other environment variables via "~/.MacOSX/environment.plist". Is this correct? If so, I will document it as such in the wiki. Thanks for your help. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 462 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050114/6a363a0e/attachment.bin From hengist.podd at virgin.net Fri Jan 14 19:31:59 2005 From: hengist.podd at virgin.net (has) Date: Fri Jan 14 19:32:06 2005 Subject: [Pythonmac-SIG] Folder Actions in Python? In-Reply-To: References: Message-ID: Wolfgang Keller wrote: >Is there a way to write "folder actions" for MacOS X in Python? Ideally, you'd use PythonOSA , but it doesn't yet support handling of arbitrary Apple events. For now, your options are: 1. Use an AppleScript to run your Python scripts via 'do shell script' when it receives Folder Action events. 2. Use an AppleScript to forward Folder Action events to a faceless background application (FBA). Scriptable FBAs are easy enough to write in Python using aem.receive (see ). BTW, the second option could be extended to create a general-purpose system for forwarding Folder Actions to user-installed shell scripts of any kind. If anyone is interested in writing such a thing, email me and I'll be happy to discuss further. has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Fri Jan 14 19:47:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 14 19:47:27 2005 Subject: [Pythonmac-SIG] Using .pth to adjust Python on startup In-Reply-To: <4A7D28AE-665A-11D9-A7F8-000A95A94FC8@mac.com> References: <4A7D28AE-665A-11D9-A7F8-000A95A94FC8@mac.com> Message-ID: On Jan 14, 2005, at 13:29, Robert White wrote: > Last night, while researching a different problem, I ran across the > usage of 'import' within ".pth" to run arbitrary code as the Python > environment is being initialized. I believe that this provides an > alternative to using PYTHONPATH and possibly some of the other > environment variables via "~/.MacOSX/environment.plist". Is this > correct? If so, I will document it as such in the wiki. Thanks for > your help. .pth files *without* using the import statement are a replacement for PYTHONPATH. These .pth files get processed every time that site.py runs, which happens for more cases than just the interactive prompt (i.e. it is not a replacement for .pythonrc). The fact that they can use import statements is a cute trick, but shouldn't be used very often -- I only use it to make "deep" sys.path modifications when necessary, such as to override parts of the standard library. -bob From hengist.podd at virgin.net Fri Jan 14 20:00:46 2005 From: hengist.podd at virgin.net (has) Date: Fri Jan 14 20:01:06 2005 Subject: [Pythonmac-SIG] Anyone script ChemDraw w/ Python? Message-ID: fbartlet wrote: >I have a mess of VBA and AppleScript scripts I wrote to automate >Word & ChemDraw tasks. Now that everyone who needs this stuff has >access to OS X, I thought I might try Python to make some >improvements I've been asked for and which VBA and AppleScript don't >seem to be able to deliver. Depends on the reason _why_ they can't deliver. If the limitation is in the application APIs, there's not much you can do about that except file a feature request with the application developer. But if it's just the language that's being lame and obnoxious then you can probably do something about that by switching to Python. Here's a link to Python's new application scripting support package (c/o yours truly): http://freespace.virgin.net/hamish.sanderson/appscript.html >While I've used Python to script Word under Windows, I'm not >terribly knowledgeable about Macs; so any and all clues will be >received gratefully. Word 2004 has a much expanded Apple event interface compared to previous versions. I think it's basically just a thin wrapper around the API used by VBA, so not very Mac-like but pretty comprehensive. The MacScrpt mailing list has various crusty old application scripters who can advise on application-specific issues. Paul Berkowitz might be a particularly good person to answer Word scripting questions as he does a lot of scripting of Office apps (he sometimes posts on this list as well, so say his name three times and maybe he'll appear;). I've yet to write up a proper introduction to Mac application scripting and appscript, but if you dig around the PythonMac SIG archives there's been a few threads discussing application scripting theory and principles. And if you're familiar with AppleScript then you shouldn't have any problems with appscript - the syntactic sugar is slightly different, but it behaves just about the same - see the appscript documentation for caveats and instructions. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From kid at kendermedia.com Fri Jan 14 20:11:34 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Fri Jan 14 20:11:28 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? Message-ID: <41E81966.2080204@kendermedia.com> I'm trying to mix Twisted and a Mac interface. I'm using PyObjC 1.2 and Twisted's trunk as of a few days back. All of this with Python 2.3. The combo appeared to be working until this morning. Intriguingly, the problem appeared when I added Cheetah (the template engine) to the mix. If I remove Cheetah *or* I remove PyObjC, everything appears to be happy. The basic order in which I'm doing things is: 1) install cfreactor, 2) load up my nib-based controller class, 3) tell the reactor to start listening on a TCP port, 4) (reactor.run) -- I had this line in there but then removed it without a difference in behavior 5) AppHelper.runEventLoop I'm not exactly sure how or why introducing Cheetah could have this effect. I even moved Cheetah's one C module out of the way (falling back to straight Python code), but that didn't seem to have an effect. I figured it was time to double check that I'm doing the right things in getting things running. Is there anything glaringly obvious in that list of steps that should be different or in a different order? Thanks, Kevin From kid at kendermedia.com Fri Jan 14 21:32:42 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Fri Jan 14 21:32:37 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? In-Reply-To: <41E81966.2080204@kendermedia.com> References: <41E81966.2080204@kendermedia.com> Message-ID: <41E82C6A.2080607@kendermedia.com> Replying to myself is always fun. I decided to try a more minimal test, eliminating everything but PyObjC and Cheetah. It does indeed appear to be the case that I get a Bus Error if I render a Cheetah template from within an action called by a menu item. This happens even when Cheetah is 100% python. The bus error occurs after my action returns. This leads me to believe that either there's something else I need to do in my class to handle that action properly, or there is a bug in Cheetah or PyObjC. Even though Twisted is not at all at issue here, I'd still be curious to hear if I'm setting up event handling properly... Kevin Kevin Dangoor wrote: > I'm trying to mix Twisted and a Mac interface. I'm using PyObjC 1.2 > and Twisted's trunk as of a few days back. All of this with Python > 2.3. The combo appeared to be working until this morning. > Intriguingly, the problem appeared when I added Cheetah (the template > engine) to the mix. If I remove Cheetah *or* I remove PyObjC, > everything appears to be happy. > > The basic order in which I'm doing things is: > 1) install cfreactor, > 2) load up my nib-based controller class, > 3) tell the reactor to start listening on a TCP port, > 4) (reactor.run) -- I had this line in there but then removed it > without a difference in behavior > 5) AppHelper.runEventLoop > > I'm not exactly sure how or why introducing Cheetah could have this > effect. I even moved Cheetah's one C module out of the way (falling > back to straight Python code), but that didn't seem to have an effect. > I figured it was time to double check that I'm doing the right things > in getting things running. > > Is there anything glaringly obvious in that list of steps that should > be different or in a different order? From kid at kendermedia.com Fri Jan 14 21:48:10 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Fri Jan 14 21:48:05 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? In-Reply-To: <41E81966.2080204@kendermedia.com> References: <41E81966.2080204@kendermedia.com> Message-ID: <41E8300A.1000207@kendermedia.com> Replying to myself is always fun. I decided to try a more minimal test, eliminating everything but PyObjC and Cheetah. It does indeed appear to be the case that I get a Bus Error if I render a Cheetah template from within an action called by a menu item. This happens even when Cheetah is 100% python. The bus error occurs after my action returns. This leads me to believe that either there's something else I need to do in my class to handle that action properly, or there is a bug in Cheetah or PyObjC. Even though Twisted is not at all at issue here, I'd still be curious to hear if I'm setting up event handling properly... Kevin Kevin Dangoor wrote: > I'm trying to mix Twisted and a Mac interface. I'm using PyObjC 1.2 > and Twisted's trunk as of a few days back. All of this with Python > 2.3. The combo appeared to be working until this morning. > Intriguingly, the problem appeared when I added Cheetah (the template > engine) to the mix. If I remove Cheetah *or* I remove PyObjC, > everything appears to be happy. > > The basic order in which I'm doing things is: > 1) install cfreactor, > 2) load up my nib-based controller class, > 3) tell the reactor to start listening on a TCP port, > 4) (reactor.run) -- I had this line in there but then removed it > without a difference in behavior > 5) AppHelper.runEventLoop > > I'm not exactly sure how or why introducing Cheetah could have this > effect. I even moved Cheetah's one C module out of the way (falling > back to straight Python code), but that didn't seem to have an effect. > I figured it was time to double check that I'm doing the right things > in getting things running. > > Is there anything glaringly obvious in that list of steps that should > be different or in a different order? From bob at redivi.com Fri Jan 14 21:53:17 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 14 21:53:24 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? In-Reply-To: <41E82C6A.2080607@kendermedia.com> References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> Message-ID: <50BADC7D-666E-11D9-A02F-000A95BA5446@redivi.com> The issue you're having sounds like it's either something really easy or really hard to fix. If you post code I'll track it down, but I don't have the time this weekend to debug-by-mail. Your crash aside, it should be done in this order: 1) Install cfreactor 2) Load up all the classes 3) AppHelper.runEventLoop 4) From 'applicationDidFinishLaunching:' do any Twisted stuff. You *should* call reactor.run() at the end. It doesn't actually block because it integrates into the NSRunLoop, but it should still be called. -bob On Jan 14, 2005, at 15:32, Kevin Dangoor wrote: > Replying to myself is always fun. > > I decided to try a more minimal test, eliminating everything but > PyObjC and Cheetah. It does indeed appear to be the case that I get a > Bus Error if I render a Cheetah template from within an action called > by a menu item. This happens even when Cheetah is 100% python. > > The bus error occurs after my action returns. This leads me to believe > that either there's something else I need to do in my class to handle > that action properly, or there is a bug in Cheetah or PyObjC. > > Even though Twisted is not at all at issue here, I'd still be curious > to hear if I'm setting up event handling properly... > > Kevin > > Kevin Dangoor wrote: > >> I'm trying to mix Twisted and a Mac interface. I'm using PyObjC >> 1.2 and Twisted's trunk as of a few days back. All of this with >> Python 2.3. The combo appeared to be working until this morning. >> Intriguingly, the problem appeared when I added Cheetah (the template >> engine) to the mix. If I remove Cheetah *or* I remove PyObjC, >> everything appears to be happy. >> >> The basic order in which I'm doing things is: >> 1) install cfreactor, >> 2) load up my nib-based controller class, >> 3) tell the reactor to start listening on a TCP port, >> 4) (reactor.run) -- I had this line in there but then removed it >> without a difference in behavior >> 5) AppHelper.runEventLoop >> >> I'm not exactly sure how or why introducing Cheetah could have this >> effect. I even moved Cheetah's one C module out of the way (falling >> back to straight Python code), but that didn't seem to have an >> effect. I figured it was time to double check that I'm doing the >> right things in getting things running. >> >> Is there anything glaringly obvious in that list of steps that should >> be different or in a different order? From bob at redivi.com Fri Jan 14 22:40:43 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 14 22:40:49 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? In-Reply-To: <41E82C6A.2080607@kendermedia.com> References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> Message-ID: (Kevin sent me the test off-list, and I took a look at it). I'm not sure exactly why your example crashes (somehow a retain message gets sent to a dead or non-object), however, the problem is that you are using an import statement from inside the implementation of the action. Don't do that. Do your imports in module level code. -bob On Jan 14, 2005, at 15:32, Kevin Dangoor wrote: > Replying to myself is always fun. > > I decided to try a more minimal test, eliminating everything but > PyObjC and Cheetah. It does indeed appear to be the case that I get a > Bus Error if I render a Cheetah template from within an action called > by a menu item. This happens even when Cheetah is 100% python. > > The bus error occurs after my action returns. This leads me to believe > that either there's something else I need to do in my class to handle > that action properly, or there is a bug in Cheetah or PyObjC. > > Even though Twisted is not at all at issue here, I'd still be curious > to hear if I'm setting up event handling properly... > > Kevin > > Kevin Dangoor wrote: > >> I'm trying to mix Twisted and a Mac interface. I'm using PyObjC >> 1.2 and Twisted's trunk as of a few days back. All of this with >> Python 2.3. The combo appeared to be working until this morning. >> Intriguingly, the problem appeared when I added Cheetah (the template >> engine) to the mix. If I remove Cheetah *or* I remove PyObjC, >> everything appears to be happy. >> >> The basic order in which I'm doing things is: >> 1) install cfreactor, >> 2) load up my nib-based controller class, >> 3) tell the reactor to start listening on a TCP port, >> 4) (reactor.run) -- I had this line in there but then removed it >> without a difference in behavior >> 5) AppHelper.runEventLoop >> >> I'm not exactly sure how or why introducing Cheetah could have this >> effect. I even moved Cheetah's one C module out of the way (falling >> back to straight Python code), but that didn't seem to have an >> effect. I figured it was time to double check that I'm doing the >> right things in getting things running. >> >> Is there anything glaringly obvious in that list of steps that should >> be different or in a different order? > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kid at kendermedia.com Fri Jan 14 22:56:52 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Fri Jan 14 22:56:48 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? In-Reply-To: References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> Message-ID: <41E84024.8070707@kendermedia.com> Wow. That was quick! I didn't realize that there was a gotcha with the imports. That was just a premature optimization, so I can easily avoid that :) Thanks for your help... that's certainly not the kind of thing I would have just guessed... Kevin Bob Ippolito wrote: > (Kevin sent me the test off-list, and I took a look at it). > > I'm not sure exactly why your example crashes (somehow a retain > message gets sent to a dead or non-object), however, the problem is > that you are using an import statement from inside the implementation > of the action. Don't do that. Do your imports in module level code. > > -bob From bob at redivi.com Fri Jan 14 23:14:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 14 23:14:40 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? In-Reply-To: <41E84024.8070707@kendermedia.com> References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> Message-ID: I don't think there is typically a gotcha with imports, I've certainly never seen this happen before, and I have done imports from applicationDidFinishLaunching: (pygame, in particular) before. I have no idea if I should be blaming Cheetah, PyObjC or Python 2.3.0 (haven't tested with 2.4 or CVS), but I will try and remember to dig in later. -bob On Jan 14, 2005, at 16:56, Kevin Dangoor wrote: > Wow. That was quick! > > I didn't realize that there was a gotcha with the imports. That was > just a premature optimization, so I can easily avoid that :) > > Thanks for your help... that's certainly not the kind of thing I would > have just guessed... > > Kevin > > Bob Ippolito wrote: > >> (Kevin sent me the test off-list, and I took a look at it). >> >> I'm not sure exactly why your example crashes (somehow a retain >> message gets sent to a dead or non-object), however, the problem is >> that you are using an import statement from inside the implementation >> of the action. Don't do that. Do your imports in module level code. >> >> -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Fri Jan 14 23:57:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 14 23:57:36 2005 Subject: [Pythonmac-SIG] Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?) In-Reply-To: References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> Message-ID: On Jan 14, 2005, at 17:14, Bob Ippolito wrote: > On Jan 14, 2005, at 16:56, Kevin Dangoor wrote: > >> Bob Ippolito wrote: >> >>> (Kevin sent me the test off-list, and I took a look at it). >>> >>> I'm not sure exactly why your example crashes (somehow a retain >>> message gets sent to a dead or non-object), however, the problem is >>> that you are using an import statement from inside the >>> implementation of the action. Don't do that. Do your imports in >>> module level code. >> >> Wow. That was quick! >> >> I didn't realize that there was a gotcha with the imports. That was >> just a premature optimization, so I can easily avoid that :) >> >> Thanks for your help... that's certainly not the kind of thing I >> would have just guessed... > > I don't think there is typically a gotcha with imports, I've certainly > never seen this happen before, and I have done imports from > applicationDidFinishLaunching: (pygame, in particular) before. I have > no idea if I should be blaming Cheetah, PyObjC or Python 2.3.0 > (haven't tested with 2.4 or CVS), but I will try and remember to dig > in later. I have traced the problem. It is a two-parter: (1) There is a module namespace conflict: WebWare has a package named WebKit PyObjC has a package named WebKit (2) Cheetah.Servlet checks to see if WebWare's WebKit is available, and ends up importing PyObjC's WebKit. (3) For whatever reason, it is not safe to import the WebKit wrapper from inside of an action (unless it's already imported, of course). Now this issue I will have to look further into. --- So apparently it's more or less undefined behavior if you have both WebWare and PyObjC installed! Fun :) -bob From kid at kendermedia.com Sat Jan 15 03:28:37 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Sat Jan 15 03:28:31 2005 Subject: [Pythonmac-SIG] how do I use twisted cfreactor? In-Reply-To: References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> Message-ID: <41E87FD5.1020106@kendermedia.com> That's good to hear. The more I thought about it, the more it seems like there are other cases where "non-standard" imports are more than a little useful. I'm actually running into another Cheetah-related problem when I use py2app (though this one is very clearly in Cheetah land), and it's also import related. If I spot anything wacky as I look at that problem, I'll let you know. Kevin Bob Ippolito wrote: > I don't think there is typically a gotcha with imports, I've certainly > never seen this happen before, and I have done imports from > applicationDidFinishLaunching: (pygame, in particular) before. I have > no idea if I should be blaming Cheetah, PyObjC or Python 2.3.0 > (haven't tested with 2.4 or CVS), but I will try and remember to dig > in later. > > -bob > > On Jan 14, 2005, at 16:56, Kevin Dangoor wrote: > >> Wow. That was quick! >> >> I didn't realize that there was a gotcha with the imports. That was >> just a premature optimization, so I can easily avoid that :) >> >> Thanks for your help... that's certainly not the kind of thing I >> would have just guessed... >> >> Kevin >> >> Bob Ippolito wrote: >> >>> (Kevin sent me the test off-list, and I took a look at it). >>> >>> I'm not sure exactly why your example crashes (somehow a retain >>> message gets sent to a dead or non-object), however, the problem is >>> that you are using an import statement from inside the >>> implementation of the action. Don't do that. Do your imports in >>> module level code. >>> >>> -bob >> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > From bob at redivi.com Sat Jan 15 03:38:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 15 03:38:25 2005 Subject: [Pythonmac-SIG] Cheetah Templates and py2app (Was: how do I use twisted cfreactor?) In-Reply-To: <41E87FD5.1020106@kendermedia.com> References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> <41E87FD5.1020106@kendermedia.com> Message-ID: <84BBDE64-669E-11D9-A02F-000A95BA5446@redivi.com> Somebody else had a Cheetah and template issue with py2app. The custom import hook is not recognized by py2app and I have no interest in writing that kind of Cheetah-specific stuff at this time (I don't use it, and I actually really don't like anything about it). The person who had that problem managed to precompile the tempates into .pyc or something with some facility that comes with Cheetah or WebWare, which py2app could handle just fine. I have no idea if this discussion was had on pythonmac-sig, pyobjc-dev, or #macpython, but that's what I remember of it. -bob On Jan 14, 2005, at 21:28, Kevin Dangoor wrote: > That's good to hear. The more I thought about it, the more it seems > like there are other cases where "non-standard" imports are more than > a little useful. I'm actually running into another Cheetah-related > problem when I use py2app (though this one is very clearly in Cheetah > land), and it's also import related. If I spot anything wacky as I > look at that problem, I'll let you know. > > Kevin > > Bob Ippolito wrote: > >> I don't think there is typically a gotcha with imports, I've >> certainly never seen this happen before, and I have done imports from >> applicationDidFinishLaunching: (pygame, in particular) before. I >> have no idea if I should be blaming Cheetah, PyObjC or Python 2.3.0 >> (haven't tested with 2.4 or CVS), but I will try and remember to dig >> in later. >> >> -bob >> >> On Jan 14, 2005, at 16:56, Kevin Dangoor wrote: >> >>> Wow. That was quick! >>> >>> I didn't realize that there was a gotcha with the imports. That was >>> just a premature optimization, so I can easily avoid that :) >>> >>> Thanks for your help... that's certainly not the kind of thing I >>> would have just guessed... >>> >>> Kevin >>> >>> Bob Ippolito wrote: >>> >>>> (Kevin sent me the test off-list, and I took a look at it). >>>> >>>> I'm not sure exactly why your example crashes (somehow a retain >>>> message gets sent to a dead or non-object), however, the problem is >>>> that you are using an import statement from inside the >>>> implementation of the action. Don't do that. Do your imports in >>>> module level code. >>>> >>>> -bob >>> >>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> >> >> > From kid at kendermedia.com Sat Jan 15 04:33:51 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Sat Jan 15 04:33:45 2005 Subject: [Pythonmac-SIG] Re: Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?) In-Reply-To: References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> Message-ID: <41E88F1F.9000707@kendermedia.com> Fun indeed. Given that I'm not using WebWare, it would most definitely be picking up PyObjC's WebKit. Maybe there's something to be said for Java's package naming conventions :) The py2app issue I was having was far less exciting. Cheetah seems to like dumping templates into /tmp and it drops in an __init__.py to pretend that /tmp is a package, and then imports from that package. It seems like there's gotta be a better way. Something to investigate tomorrow... I wouldn't expect you to add Cheetah-specific stuff to py2app. It shouldn't need to do anything *that* magical. What I like about Cheetah is that it's concise (unlike TAL), is pleasant to work with (subjective to be sure, but I don't like ClearSilver's syntax), is reasonably performant, and strikes a nice balance between functionality and separation of concerns. With the sleuthing you've done, I should be able to come up with something that works well for my needs. Kevin Bob Ippolito wrote: > > I have traced the problem. It is a two-parter: > > (1) There is a module namespace conflict: > WebWare has a package named WebKit > PyObjC has a package named WebKit > > (2) Cheetah.Servlet checks to see if WebWare's WebKit is available, > and ends up importing PyObjC's WebKit. > > (3) For whatever reason, it is not safe to import the WebKit wrapper > from inside of an action (unless it's already imported, of course). > Now this issue I will have to look further into. > > --- > So apparently it's more or less undefined behavior if you have both > WebWare and PyObjC installed! Fun :) > > -bob > > > > From bob at redivi.com Sat Jan 15 12:15:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 15 12:15:55 2005 Subject: [Pythonmac-SIG] Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?) In-Reply-To: References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> Message-ID: On Jan 14, 2005, at 17:57, Bob Ippolito wrote: > On Jan 14, 2005, at 17:14, Bob Ippolito wrote: > >> On Jan 14, 2005, at 16:56, Kevin Dangoor wrote: >> >>> Bob Ippolito wrote: >>> >>>> (Kevin sent me the test off-list, and I took a look at it). >>>> >>>> I'm not sure exactly why your example crashes (somehow a retain >>>> message gets sent to a dead or non-object), however, the problem is >>>> that you are using an import statement from inside the >>>> implementation of the action. Don't do that. Do your imports in >>>> module level code. >>> >>> Wow. That was quick! >>> >>> I didn't realize that there was a gotcha with the imports. That was >>> just a premature optimization, so I can easily avoid that :) >>> >>> Thanks for your help... that's certainly not the kind of thing I >>> would have just guessed... >> >> I don't think there is typically a gotcha with imports, I've >> certainly never seen this happen before, and I have done imports from >> applicationDidFinishLaunching: (pygame, in particular) before. I >> have no idea if I should be blaming Cheetah, PyObjC or Python 2.3.0 >> (haven't tested with 2.4 or CVS), but I will try and remember to dig >> in later. > > I have traced the problem. It is a two-parter: > > (1) There is a module namespace conflict: > WebWare has a package named WebKit > PyObjC has a package named WebKit > > (2) Cheetah.Servlet checks to see if WebWare's WebKit is available, > and ends up importing PyObjC's WebKit. > > (3) For whatever reason, it is not safe to import the WebKit wrapper > from inside of an action (unless it's already imported, of course). > Now this issue I will have to look further into. > > --- > So apparently it's more or less undefined behavior if you have both > WebWare and PyObjC installed! Fun :) I've filed a bug against WebWare , hopefully they'll change the name of WebKit, I don't think we will do it in PyObjC -- because then we'd have to change the names of every wrapped framework for consistency. The actual crash is due to the fact that WebKit/__init__.py recycles the PyObjC global autorelease pool. God knows why. I've reverted this behavior in svn trunk r1337. -bob From hengist.podd at virgin.net Sat Jan 15 18:54:18 2005 From: hengist.podd at virgin.net (has) Date: Sat Jan 15 18:54:26 2005 Subject: [Pythonmac-SIG] Re: Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?) Message-ID: Kevin Dangoor wrote: >What I like about Cheetah >is that it's concise (unlike TAL), is pleasant to work with (subjective >to be sure, but I don't like ClearSilver's syntax), is reasonably >performant, and strikes a nice balance between functionality and >separation of concerns. Utterly shameless self-plug here, but HTMLTemplate is a mature, powerful and flexible DOM-like HTML templating system that's also refreshingly simple and unintrusive in both implementation and use. I've also just posted an update to its plain text-oriented sibling, texttemplate (the documentation isn't quite done yet, but the module itself should be quite usable). Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From Jack.Jansen at cwi.nl Sun Jan 16 00:26:28 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 16 00:25:58 2005 Subject: [Pythonmac-SIG] Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?) In-Reply-To: References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> Message-ID: On 14-jan-05, at 23:57, Bob Ippolito wrote: > I have traced the problem. It is a two-parter: > > (1) There is a module namespace conflict: > WebWare has a package named WebKit > PyObjC has a package named WebKit As far as I know this is the first time this potential problem with python's naming convention is seen in the wild. Maybe it's worth it to report it to python-dev? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Sun Jan 16 00:56:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 16 00:56:23 2005 Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?) In-Reply-To: References: <41E81966.2080204@kendermedia.com> <41E82C6A.2080607@kendermedia.com> <41E84024.8070707@kendermedia.com> Message-ID: <0B10E87D-6751-11D9-BFCD-000A95BA5446@redivi.com> On Jan 15, 2005, at 18:26, Jack Jansen wrote: > > On 14-jan-05, at 23:57, Bob Ippolito wrote: >> I have traced the problem. It is a two-parter: >> >> (1) There is a module namespace conflict: >> WebWare has a package named WebKit >> PyObjC has a package named WebKit > > As far as I know this is the first time this potential problem with > python's naming convention is seen in the wild. Maybe it's worth it to > report it to python-dev? Well I filed a bug with Webware, let's wait a couple days and see if they say anything. -bob From m93k2y8 at acncanada.net Sun Jan 16 03:43:18 2005 From: m93k2y8 at acncanada.net (Kirk Durston) Date: Sun Jan 16 03:42:55 2005 Subject: [Pythonmac-SIG] accessing my modules from within Python Message-ID: I'm just starting to learn Python. When I write a module in one of my text programs (MSWord, or Textedit) and save it as a text file in on my harddrive, and then go to the terminal window to import it, I get a message saying it either can't find the file or can't open it. I do put the .py suffix on when I save the module, but no success. I have been saving my modules in different places, the last of which was in library/python/2.3/sitepackages ... no success. The test module I?ve written is called bogus.py If I start python in the terminal window and then type 'import bogus' I get a message saying 'Import error: No module named bogus' If I try and launch the python module by typing 'python bogus.py' I get a message "python: can't open file 'bogus.py' " Question: Can I use TextEdit or MS Word to write modules just so long as I put a .py suffix on the file? Question: How can I save a module such that Python can find and open it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050115/b9fed2f3/attachment.html From bob at redivi.com Sun Jan 16 04:08:01 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 16 04:08:08 2005 Subject: [Pythonmac-SIG] accessing my modules from within Python In-Reply-To: References: Message-ID: On Jan 15, 2005, at 21:43, Kirk Durston wrote: > I'm just starting to learn Python. When I write a module in one of my > text programs (MSWord, or Textedit) and save it as a text file in on > my harddrive, and then go to the terminal window to import it, I get a > message saying it either can't find the file or can't open it. I do > put the .py suffix on when I save the module, but no success. I have > been saving my modules in different places, the last of which was in > library/python/2.3/sitepackages ... no success. The test module I?ve > written is called bogus.py > > If I start python in the terminal window and then type 'import bogus' > I get a message saying 'Import error: No module named bogus' > > If I try and launch the python module by typing 'python bogus.py' I > get a message "python: can't open file 'bogus.py' " > > Question: Can I use TextEdit or MS Word to write modules just so long > as I put a .py suffix on the file? If and only if the file is saved as plain text. I wouldn't recommend using either of these editors as they don't have any built-in support for programming (syntax highlighting, completion, indentation, etc.) and you will probably have the tabs vs. spaces problem. You should ideally use a text editor more suitable for programming, such as Xcode. If you use Xcode, make sure to uncheck "Editor uses tabs" in the Text Editing preference pane before writing any code. > Question: How can I save a module such that Python can find and open > it? There is some useful information about how Python modules are located in the Python tutorial . The global location where add-on modules should be placed is dependent on which Python you are using. If you are using the Python 2.3.0 that comes with Mac OS X 10.3.x, then this location is . Otherwise, it depends on which distribution of Python you installed and how you installed it. If you would like to place your modules somewhere else, you can create a plain-text pth file that points to this other desired location. Documentation for this feature is described in the site module documentation . Running Python files from the command line is like running anything else from the command line. When you say "python bogus.py", bogus.py MUST be in the current directory, or else it won't work. Either you need to change to the directory that bogus.py is in, or pass in the complete path to bogus.py. A quick way to do this is to just type "python ", drag bogus.py to your Terminal window to paste the file's full path, and press return. -bob From Larry.A.Meyn at nasa.gov Sun Jan 16 17:49:39 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Sun Jan 16 17:49:51 2005 Subject: [Pythonmac-SIG] accessing my modules from within Python In-Reply-To: References: Message-ID: <9CC6CEE2-67DE-11D9-89E5-000D93680688@nasa.gov> On Jan 15, 2005, at 6:43 PM, Kirk Durston wrote: > I'm just starting to learn Python. When I write a module in one of my > text programs (MSWord, or Textedit) and save it as a text file in on > my harddrive, and then go to the terminal window to import it, I get a > message Just a quick note, there are much better editor alternatives to TextEdit and Word. The free TextWrangler 2.0 from BareBones is a very good programming editor does syntax highlighting. There is also the MacPython IDE and PyOxide IDE . > saying it either can't find the file or can't open it. I do put the > .py suffix on when I save the module, but no success. I have been > saving my modules in different places, the last of which was in > library/python/2.3/sitepackages ... no success. The test module I?ve > written is called bogus.py > Larry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1169 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050116/a1ba7c37/attachment.bin From wesley.fraser at nrc.ca Sun Jan 16 21:09:55 2005 From: wesley.fraser at nrc.ca (Wes Fraser) Date: Sun Jan 16 21:10:10 2005 Subject: [Pythonmac-SIG] problems installing PIL on 10.3 Message-ID: <96C0ADCE-67FA-11D9-B30A-000A95E96858@nrc.ca> Hey Everyone. I am having a few issues trying to install PIL for the standard max os x 10.3 installation of python. Sadly, the only package that won't build _imagingtk, is the only one I actually need. So if anyone can help out, that would be great. So here's how I am trying to build this. I have exactly followed the instructions given at http://plone.sourceforge.net/archetypes/known_issues.html I get the same warning that they mention I would when I do a make. When I go to do the $ python setup.py build , I get the following error: building '_imagingtk' extension gcc -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/_imagingtk.o bu ild/temp.darwin-7.7.0-Power_Macintosh-2.3/Tk/tkImaging.o -LlibImaging -lImaging -o build/lib.darw in-7.7.0-Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 I have tried to do this build form both the manual build and fink builds of libjpeg, so I don't think that is my isssue. I would guess that it has something to do with my tk install, but don't have any ideas as to what I should do. Can anyone shine some light on my issue? Thanks much! Wes From peter at jorjun.org.uk Sun Jan 16 11:00:21 2005 From: peter at jorjun.org.uk (Pete) Date: Mon Jan 17 00:16:08 2005 Subject: [Pythonmac-SIG] coding preference Message-ID: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> I have been wondering what to use for my next project which involves a simple static window with graphical image background and drop down lists with dynamic content. Can somebody with experience of both comment on using PyGame and PyObjc to help me decide which developer framework to choose? The main advantage with PyObjc may be that I can use interface builder...but I prefer the portability of PyGame. Cheers Peter From bob at redivi.com Mon Jan 17 03:33:29 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 17 03:33:36 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> Message-ID: <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> On Jan 16, 2005, at 5:00, Pete wrote: > I have been wondering what to use for my next project which involves a > simple static window with graphical image background and drop down > lists with dynamic content. > > Can somebody with experience of both comment on using PyGame and > PyObjc to help me decide which developer framework to choose? The > main advantage with PyObjc may be that I can use interface > builder...but I prefer the portability of PyGame. If you use pygame, you will have to code drop-down widgets yourself. From scratch. It does not have any GUI elements you can use. If you use PyObjC, all of the widgets you need are already part of Cocoa, so you probably only really have to write code that populates the lists... which might be really trivial if you can require Mac OS X 10.3+ and use Cocoa Bindings. Using PyObjC will build a smaller application too. The implementation of pygame on Mac OS X depends on PyObjC, SDL, SDL_image, SDL_mixer, SDL_ttf, smpeg (and probably another library or two), so naturally is is going to create considerably larger application bundles than just PyObjC, which has no dependencies (that are not part of the system). -bob From wolfgang.keller.nospam at gmx.de Mon Jan 17 15:22:11 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Mon Jan 17 15:22:16 2005 Subject: [Pythonmac-SIG] Folder Actions in Python? In-Reply-To: References: Message-ID: <1qe3u77952nlt$.eyttpel1yxe4.dlg@40tude.net> > Is there a way to write "folder actions" for MacOS X in Python? In fact it seems there is more than one way to use kqueue from Python, which is more efficient than Finder Folder Actions. First, there is effectively a Python module PyKQueue. The current version is 1.4, available from http://ox.eicat.ca/~dgilbert/files/PyKQueue.html. The version available at http://fink.sourceforge.net/pdb/package.php/pykqueue-py23 is the old 1.3. Second, there is Stakeout, an ObjC program, available from http://michael-mccracken.net/blog/blosxom.pl/computers/mac/programming/meetWatch.html And finally, the development of a kqueuereactor is now foreseen for twisted. :-) There are also kernel modules available for Linux which provide similar functionality. BTW: It seems that the MacOS X Finder still polls the filesystem instead of using kqueue - Ouch. Best regards, Wolfgang Keller From robster at videotron.ca Mon Jan 17 20:01:44 2005 From: robster at videotron.ca (Robert Costain) Date: Mon Jan 17 20:03:05 2005 Subject: [Pythonmac-SIG] a question about paths Message-ID: <3B19BC2C-68BA-11D9-B850-000A95BC732A@videotron.ca> Hi there, I apologise in advance for a somewhat "newbie" question. I am not a Python developer. I run a web server using Jaguar Server (10.2.8). I have an installation of Mailman running on this server. It's been working really well for me for over 2 years. Last week I upgraded my Mailman install from 2.1.4 to 2.1.5. I started to notice some interface oddities (messages that should have bounced simply disappeared). On the Mailman project page, I noticed that Python 2.3 is recommended for Mailman. I downloaded the source for Python 2.3.4 and ran configure, make and make install - I have some experience doing installations like this and am quite comfortable doing it. It appears to have been installed correctly, but when I run "python -V" in Terminal to check the version number, it still shows the Apple-installed version 2.2. How do I get the system to default to the new installation of Python? Thanks in advance, Rob --- Robert Costain T?l.: 819.684.8542 Cell.: 613.889.1552 From Jack.Jansen at cwi.nl Tue Jan 18 14:58:47 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Jan 18 14:58:11 2005 Subject: [Pythonmac-SIG] a question about paths In-Reply-To: <3B19BC2C-68BA-11D9-B850-000A95BC732A@videotron.ca> References: <3B19BC2C-68BA-11D9-B850-000A95BC732A@videotron.ca> Message-ID: <12F1D9E5-6959-11D9-8EC3-000A958D1666@cwi.nl> On 17 Jan 2005, at 20:01, Robert Costain wrote: > I downloaded the source for Python 2.3.4 and ran configure, make and > make install - I have some experience doing installations like this > and am quite comfortable doing it. > > It appears to have been installed correctly, but when I run "python > -V" in Terminal to check the version number, it still shows the > Apple-installed version 2.2. > > How do I get the system to default to the new installation of Python? The new Python will be in /usr/local/bin/python, you have to make sure it is used in stead of Apple's Python 2.2 (which is in /usr/bin/python). It's been a long time since I installed mailman, but I wouldn't be surprised if the easiest way to get mailman to use your new Python is to re-install mailman, making sure you use /usr/local/bin/python. Do this by putting /usr/local/bin in your $PATH before /usr/bin and then running configure. [checking...] Yes, that's easiest. Or you can use the --with-python option to configure. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Chris.Barker at noaa.gov Tue Jan 18 18:29:01 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Jan 18 18:34:08 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> Message-ID: <41ED475D.3030604@noaa.gov> Bob Ippolito wrote: > On Jan 16, 2005, at 5:00, Pete wrote: >> I have been wondering what to use for my next project which involves a >> simple static window with graphical image background and drop down >> lists with dynamic content. > If you use PyObjC, all of the widgets you need are already part of > Cocoa, so you probably only really have to write code that populates the > lists... which might be really trivial if you can require Mac OS X 10.3+ > and use Cocoa Bindings. Another option is wxPython. If you want portability, that's the best way to go. > Using PyObjC will build a smaller application too. wxPython is large as well, so if you need small, probably PyObjC, if you need portable, probably wxPython is your best bet. If you need both, your out of luck. Consider PyGame if you need fast raster graphics. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From charles.hartman at conncoll.edu Tue Jan 18 22:40:54 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Jan 18 22:43:05 2005 Subject: [Pythonmac-SIG] a RegEx question Message-ID: Sorry, I know this isn't CompSci 101, but if any can help I'll appreciate it. My question about regular expressions (any language, I suppose) has to do with finding *overlapping* and (relatedly) *longest* matches. Two examples: find 'abca' in string 'abcabca' find longest '(a[ab])+' in string 'baabaaabba' Every *single* RE I can think of misses the second instance (beginning in position 3) in the first example, because it's eaten the beginning of it in finding the first instance. And the same problem means that in the second example, while an RE finds matches at positions 1 and 4 ('aa' and 'aaab' respectively), it can't find the longest, at position 2 ('abaaab'), because the find at position 1 steps on it. I know I can solve this by compiling the expression and using the argument that becomes available then. It's just awkward. And I keep thinking I must be missing something about RE syntax that would let me do these searches in a single step, not a loop (or, often, two nested loops). Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com From njriley at uiuc.edu Tue Jan 18 23:08:02 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue Jan 18 23:08:07 2005 Subject: [Pythonmac-SIG] a RegEx question In-Reply-To: References: Message-ID: <20050118220802.GA39150@uiuc.edu> On Tue, Jan 18, 2005 at 04:40:54PM -0500, Charles Hartman wrote: > find 'abca' in string 'abcabca' > > Every *single* RE I can think of misses the second instance (beginning > in position 3) in the first example, because it's eaten the beginning > of it in finding the first instance. Lookahead will do this one, e.g.: In [39]: [m.span() for m in re.finditer(r'(?=abca)', 'abcabca')] Out[39]: [(0, 0), (3, 3)] > find longest '(a[ab])+' in string 'baabaaabba' I don't think even Perl regexps can do the second one, but I might be wrong. Neither greedy or non-greedy quantifiers will compare match length. You could get a list of all matches and pick the longest one yourself. -- Nicholas Riley | From wolfgang.keller.nospam at gmx.de Tue Jan 18 23:20:20 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Tue Jan 18 23:20:24 2005 Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.7.1 - Cocoa based Python IDE In-Reply-To: <813B5120-65CF-11D9-8AD6-000D9346E10A@gandreas.com> References: <813B5120-65CF-11D9-8AD6-000D9346E10A@gandreas.com> Message-ID: > PyOXIDE 0.7.1 is now available on my idisk (as PyOXIDE_0.7.1.dmg): Hey, no screenshots on the WWW site? ;-) Regards, Wolfgang Keller From bob at redivi.com Wed Jan 19 00:09:47 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 19 00:09:55 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <41ED475D.3030604@noaa.gov> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> Message-ID: <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> On Jan 18, 2005, at 12:29, Chris Barker wrote: > Bob Ippolito wrote: >> On Jan 16, 2005, at 5:00, Pete wrote: >>> I have been wondering what to use for my next project which involves >>> a simple static window with graphical image background and drop down >>> lists with dynamic content. >> If you use PyObjC, all of the widgets you need are already part of >> Cocoa, so you probably only really have to write code that populates >> the lists... which might be really trivial if you can require Mac OS >> X 10.3+ and use Cocoa Bindings. > > Another option is wxPython. If you want portability, that's the best > way to go. > >> Using PyObjC will build a smaller application too. > > wxPython is large as well, so if you need small, probably PyObjC, if > you need portable, probably wxPython is your best bet. If you need > both, your out of luck. > > Consider PyGame if you need fast raster graphics. I don't think fast is the right word for it :) pygame is actually rather slow in comparison to Apple's stuff, because it's not optimized for the PPC (though someone is working on altivec support for SDL, so that may change). If you want fast raster graphics, you should be using OpenGL, which you can do with PyOpenGL and PyObjC just fine, without bothering with pygame. One of the benefits of Mac OS X is that every machine capable of running it is capable of OpenGL. -bob From delza at livingcode.org Wed Jan 19 06:14:02 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Jan 19 06:14:11 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> Message-ID: I'm glad I'm not the only one who feels that PyGame isn't worth the trouble for what you get. I'm not real crazy about wxWindows either. Right now I'm not concerned with cross-platform issues, but if I were I'd rather see time spent on making a strong, Pythonic UI library on top of pyobjc (mac), pywin32 (win), and pygtk (linux), instead of spending all their time making very unpythonic wrappers for gigantic C/C++ libararies which don't capture all of the platform capabilities and much of which are better done in Python anyways (most UI libraries contain a lot besides UI classes: timing, threading, strings manipulation, etc.) I'm not trying to knock how difficult it is to write cross-platform C++ libraries, but what is needed for C++ isn't what's needed for Python. On the other hand, I'd rather spend my own time writing applications and utilities, not a UI framework, so I guess I'll just shut up now. --Dethe p.s. I have been ignoring the confusion of Linux UIs for some time. I just pulled pygtk out of a hat from all the various incompatible ways which are the One True Right Way to write UI code for Linux. If I really had to worry about cross-platform, I'd probably use PyXPCOM and the Mozilla libraries. "Why is Virtual Reality always posited in terms of space, when time is the only real commodity left?" --Rich Gold -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050118/f9c5ad9d/smime.bin From charles.hartman at conncoll.edu Wed Jan 19 14:20:18 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Jan 19 14:20:36 2005 Subject: [Pythonmac-SIG] a RegEx question In-Reply-To: <20050118220802.GA39150@uiuc.edu> References: <20050118220802.GA39150@uiuc.edu> Message-ID: Ah! Of course! Thank you. But no, you're right, it doesn't work on the find-the-longest problem. (Result is a recursion overrun; hm.) "We are working on some minor configuration/security issues which may result in odd behavior over the next 24-48 hours." -- notice on a BBS On Jan 18, 2005, at 5:08 PM, Nicholas Riley wrote: > On Tue, Jan 18, 2005 at 04:40:54PM -0500, Charles Hartman wrote: >> find 'abca' in string 'abcabca' >> >> Every *single* RE I can think of misses the second instance (beginning >> in position 3) in the first example, because it's eaten the beginning >> of it in finding the first instance. > > Lookahead will do this one, e.g.: > > In [39]: [m.span() for m in re.finditer(r'(?=abca)', 'abcabca')] > Out[39]: [(0, 0), (3, 3)] > >> find longest '(a[ab])+' in string 'baabaaabba' > > I don't think even Perl regexps can do the second one, but I might be > wrong. Neither greedy or non-greedy quantifiers will compare match > length. You could get a list of all matches and pick the longest one > yourself. > > -- > Nicholas Riley | > > From Chris.Barker at noaa.gov Wed Jan 19 18:24:45 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Jan 19 18:29:54 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> Message-ID: <41EE97DD.6000401@noaa.gov> Dethe Elza wrote: > Right now I'm not concerned with cross-platform issues, but if I were > I'd rather see time spent on making a strong, Pythonic UI library on top > of pyobjc (mac), pywin32 (win), and pygtk (linux), Like PyGUI? (http://nz.cosc.canterbury.ac.nz/~greg/python_gui/) > On the other hand, I'd rather spend my own time writing applications and > utilities, not a UI framework, so I guess I'll just shut up now. Exactly. The Python GUI situation is a direct result of the fact that Python is an open source project: people write code because they need it, and it's a heck of a lot less work to wrap a library than write one from scratch. That being said, I am hopeful about PyGUI, but it's a going to be at least another few years before it's as useful as wxPython (there isn't even a real Windows version yet!). After all, it took quite a few years for wxPython to become really usable. In the meantime, wxPython (and probably PyQT, if the license works for you) is a pretty good option for cross platform code, and it's slowly becoming more Pythonic. There are also a couple of pythonic wrappers for wxPython: WAX and PythonCard. I'm not fond of the wrappers around wrappers around wrappers approach, but if they work for you, who cares how many layers there are? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From charles.hartman at conncoll.edu Wed Jan 19 18:52:57 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Jan 19 18:53:01 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <41EE97DD.6000401@noaa.gov> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> Message-ID: > > In the meantime, wxPython (and probably PyQT, if the license works for > you) is a pretty good option for cross platform code, and it's slowly > becoming more Pythonic. Would you (or anyone) care to comment on the relative merits of the two? I've been using wxPython, but since I have no intention of writing commercial software I guess I could as easily (that is, cheaply) use QT. (I do need my (academic) programs to run on both Mac and Windows.) Worth switching? Charles Hartman From pymac at jorjun.org.uk Wed Jan 19 18:57:23 2005 From: pymac at jorjun.org.uk (Pete) Date: Wed Jan 19 18:57:28 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <41EE97DD.6000401@noaa.gov> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> Message-ID: <92870548-6A43-11D9-AB85-0003936CD80C@jorjun.org.uk> > There are also a couple of pythonic wrappers for wxPython: WAX and > PythonCard. I'm not fond of the wrappers around wrappers around > wrappers approach, but if they work for you, who cares how many layers > there are? > > -Chris Talking of PythonCard do you know if it has settled down, bugz and stability wise? It looked like a very promising project to me I meant to check back to it. Thanks for the reminder. -Pete From Chris.Barker at noaa.gov Wed Jan 19 18:54:32 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Jan 19 18:59:41 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> Message-ID: <41EE9ED8.3000506@noaa.gov> Charles Hartman wrote: > Would you (or anyone) care to comment on the relative merits of the two? > I've been using wxPython, but since I have no intention of writing > commercial software I guess I could as easily (that is, cheaply) use QT. > (I do need my (academic) programs to run on both Mac and Windows.) Worth > switching? I'm pretty sure you need a license to distribute even free QT software for Windows. I understand that buying Black Adder is the cheapest way to get a license for Python, rather than C++ development. I've never used QT, so I can't speak to the advantages. One reason I would consider switching, however, is that there are more Scientific Widgets for QT (like http://qwt.sourceforge.net/). If you don't have a need for those, then wx should be fine. Others on this list can probably speak better as the advantages/disadvantages of wx vs QT. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Wed Jan 19 19:06:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 19 19:06:16 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> Message-ID: On Jan 19, 2005, at 12:52, Charles Hartman wrote: >> >> In the meantime, wxPython (and probably PyQT, if the license works >> for you) is a pretty good option for cross platform code, and it's >> slowly becoming more Pythonic. > > Would you (or anyone) care to comment on the relative merits of the > two? I've been using wxPython, but since I have no intention of > writing commercial software I guess I could as easily (that is, > cheaply) use QT. (I do need my (academic) programs to run on both Mac > and Windows.) Worth switching? I would not recommend PyQT. Their Mac port does some pretty gnarly things and I don't trust it (yet). There is also no free edition available for Windows, IIRC. -bob From delza at livingcode.org Wed Jan 19 22:59:18 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Jan 19 22:59:22 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <41EE97DD.6000401@noaa.gov> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> Message-ID: <5E2C63B8-6A65-11D9-A0C0-0003939B59E8@livingcode.org> > That being said, I am hopeful about PyGUI, but it's a going to be at > least another few years before it's as useful as wxPython (there isn't > even a real Windows version yet!). After all, it took quite a few > years for wxPython to become really usable. My mistake. I was under the impression that PyGUI had been abandoned. I will take another look. Maybe I was thinking of PIDDLE/Sping, which does appear to be abandoned. If PyGUI is still viable, I'll look into it and see if I can help out. > In the meantime, wxPython (and probably PyQT, if the license works for > you) is a pretty good option for cross platform code, and it's slowly > becoming more Pythonic. I keep trying to like wxPython, I really do. It's just that its freaking huge, many of its widgets look like they were designed by children, and I find it really cumbersome to work with. The wx demo looks moderately OK on Windows, but pretty bad on OS X. I don't have any experience with PyQT, but prefer open systems to closed, given a choice. > There are also a couple of pythonic wrappers for wxPython: WAX and > PythonCard. I'm not fond of the wrappers around wrappers around > wrappers approach, but if they work for you, who cares how many layers > there are? I've looked at PythonCard, but you can't next objects, which rules it out for me (plus it's built on wx). I've been meaning to take a look at Wax to see if the API is worth porting to live on top of Cocoa, but I'll take another look at PyGUI first. --Dethe Choosing software is not a neutral act. It must be done consciously; the debate over free and proprietary software can?t be limited to the differences in the applications? features and ergonomics. To choose an operating system, or software, or network architecture is to choose a kind of society. --Lemaire and Decroocq (trans. by Tim Bray) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050119/7e93d6a1/smime.bin From matsakis at mit.edu Thu Jan 20 06:13:37 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Thu Jan 20 06:13:39 2005 Subject: [Pythonmac-SIG] NOHUPing a python process? Message-ID: I was wondering if anyone knew if it was possible to programmatically nohup a python process on Mac OS X. That is, is there a way for the script, as it is running, to ensure that it will keep running even if the user that started it logged out or shut his or her terminal? Nick Matsakis From bob at redivi.com Thu Jan 20 09:25:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 20 09:26:21 2005 Subject: [Pythonmac-SIG] NOHUPing a python process? In-Reply-To: References: Message-ID: <55534FEA-620A-42AA-A0F8-DC3FC49A5CDA@redivi.com> On Jan 20, 2005, at 12:13 AM, Nick Matsakis wrote: > I was wondering if anyone knew if it was possible to programmatically > nohup a python process on Mac OS X. That is, is there a way for the > script, as it is running, to ensure that it will keep running even if > the > user that started it logged out or shut his or her terminal? Use the signal module . -bob From whamoo at rknet.it Thu Jan 20 15:50:29 2005 From: whamoo at rknet.it (whamoo) Date: Thu Jan 20 15:49:26 2005 Subject: [Pythonmac-SIG] @selector(mymethod:) with pyobjc? Message-ID: Hi to all, I'm writing an application with dinamic menu (NSMenu - NSMenuItem), but i've some problem with this function: [[NSMenuItem alloc] initWithTitle:action:keyEquivalent:] I want to pass to "action:" a function of my class, in objc i must use this code @selector(mioMetodo:) In Python how to translate this? menuitem = NSMenuItem.alloc().initWithTitle_action_keyEquivalent_(str(a), "Here the code" , "") Thanks a lot =) Whamoo www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 710 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050120/2f4d1b42/attachment.bin From just at letterror.com Thu Jan 20 16:43:15 2005 From: just at letterror.com (Just van Rossum) Date: Thu Jan 20 16:43:35 2005 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] @selector(mymethod:) with pyobjc? In-Reply-To: Message-ID: whamoo wrote: > I'm writing an application with dinamic menu (NSMenu - NSMenuItem), > but i've some problem with this function: > [[NSMenuItem alloc] initWithTitle:action:keyEquivalent:] > > I want to pass to "action:" a function of my class, in objc i must use > this code @selector(mioMetodo:) > In Python how to translate this? > > menuitem = > NSMenuItem.alloc().initWithTitle_action_keyEquivalent_(str(a), "Here > the code" , "") menuitem = NSMenuItem.alloc().initWithTitle_action_keyEquivalent_( str(a), "mioMetodo:" , "") Just From bob at redivi.com Thu Jan 20 19:56:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 20 19:56:12 2005 Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] @selector(mymethod:) with pyobjc? In-Reply-To: References: Message-ID: On Jan 20, 2005, at 10:43, Just van Rossum wrote: > whamoo wrote: > >> I'm writing an application with dinamic menu (NSMenu - NSMenuItem), >> but i've some problem with this function: >> [[NSMenuItem alloc] initWithTitle:action:keyEquivalent:] >> >> I want to pass to "action:" a function of my class, in objc i must use >> this code @selector(mioMetodo:) >> In Python how to translate this? >> >> menuitem = >> NSMenuItem.alloc().initWithTitle_action_keyEquivalent_(str(a), "Here >> the code" , "") > > menuitem = NSMenuItem.alloc().initWithTitle_action_keyEquivalent_( > str(a), "mioMetodo:" , "") menuitem = NSMenuItem.alloc().initWithTitle_action_keyEquivalent_( unicode(a), "mioMetodo:", "") Note that you need to name your method mioMetodo_ -- it needs to match that selector (replacing colons by underscores). This should be documented in the PyObjC introduction. -bob From Jack.Jansen at cwi.nl Fri Jan 21 00:33:30 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 21 00:32:45 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <41EE9ED8.3000506@noaa.gov> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> <41EE9ED8.3000506@noaa.gov> Message-ID: On 19-jan-05, at 18:54, Chris Barker wrote: > I've never used QT, so I can't speak to the advantages. One reason I > would consider switching, however, is that there are more Scientific > Widgets for QT (like http://qwt.sourceforge.net/). If you don't have a > need for those, then wx should be fine. I've only used it from C++, and only on Linux (the multimedia projects I do tend to grow platform-dependent UI solutions), but I was favorably impressed. Functionality tends to be in the place where you expect it, which is where most GUI packages break down (including Cocoa), and the documentation is pretty good. For Linux standards things look absolutely great on-screen. Which brings me to my real point: I don't think a good cross-platform GUI toolkit is possible. Period. There are some things that simply cannot be matched programmatically, specifically when paradigms are different. So while a really good x-platform GUI toolkit may get the "look" right, I don't think it'll ever manage getting the "feel" right. Which means your stuck with the worst of both worlds: something that looks like a (say) Mac application but doesn't behave like it. My solution: for throwaway applications consider a cross-platform toolkit, for anything serious use MVC and code the view and controller in a platform-native toolkit. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From kevino at tulane.edu Sat Jan 22 02:21:46 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Sat Jan 22 02:21:57 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> <41EE9ED8.3000506@noaa.gov> Message-ID: Hi Jack, On Jan 20, 2005, at 3:33 PM, Jack Jansen wrote: > > On 19-jan-05, at 18:54, Chris Barker wrote: > >> I've never used QT, so I can't speak to the advantages. One reason I >> would consider switching, however, is that there are more Scientific >> Widgets for QT (like http://qwt.sourceforge.net/). If you don't have >> a need for those, then wx should be fine. > > I've only used it from C++, and only on Linux (the multimedia projects > I do tend to grow platform-dependent UI solutions), but I was > favorably impressed. Functionality tends to be in the place where you > expect it, which is where most GUI packages break down (including > Cocoa), and the documentation is pretty good. For Linux standards > things look absolutely great on-screen. > > Which brings me to my real point: I don't think a good cross-platform > GUI toolkit is possible. Period. There are some things that simply > cannot be matched programmatically, specifically when paradigms are > different. I think you're getting bogged down by the differences between platforms rather than abstracting them. ;-) Which is what any cross-platform developer will need to do if they wish to succeed, regardless of what GUI toolkit(s) they use. For the most part, it isn't 'what' the native toolkits (or platforms) do that differ, it's 'how' they do it. So if you program 'what' you want to do, and design the toolkit to figure out 'how' to do it correctly on each platform, a lot of times you can get the right look *and* feel without much extra effort. Granted, there are some technical challenges (look at Apple's Carbon text control technologies, like MLTE for example, where sometimes you need to manually implement even basic, standard functionality), but I have a hard time understanding how these difficulties are insurmountable. > So while a really good x-platform GUI toolkit may get the "look" > right, I don't think it'll ever manage getting the "feel" right. Which > means your stuck with the worst of both worlds: something that looks > like a (say) Mac application but doesn't behave like it. Well, that depends on the programmer. Even a Mac developer can create an application that doesn't "feel" like a Mac application; it really isn't very hard if you try. (And for people coming from Windows, that will be their natural inclination anyways.) It's arguable that the problem is the toolkit at all - it's the developer simply not taking Mac design considerations into effect. Yes, toolkit affects their ability to do this, but in the end a tool is just a tool. I see no fundamentally technical reason a cross-platform GUI toolkit *cannot* provide a user with the ability to create a well-designed Mac application. Heck, if wxPython had some more resources in its corner, I firmly believe it would already be doing so. That's the downside of open source. We've got the technical expertise to fix most of the issues that people have brought up with wxWidgets/wxPython, it's just that most of these experts have to handle bread and butter problems first. Again, not a technical problem. (As an aside, wxPython will in its next release have a tool that automatically creates standard button layouts that match the platform's HIG and even provides "Save" "Don't Save" on Mac. We're also working on a way to get and utilize standard "borders/spacing" for various native controls, so that you can properly space items in a non-platform-specific manner. And IIRC the scrollbars issue is *finally* resolved.) I do agree that it is probably next to impossible for some cross-platform GUI toolkit to match the elegance of Apple's libraries (or possibly QT), but sometimes the need/desire for elegance is superseded by real world constraints like time and money, and if you need cross-platform w/ native look and feel, something like wxPython is about the best option that's out there. > My solution: for throwaway applications consider a cross-platform > toolkit, for anything serious use MVC and code the view and controller > in a platform-native toolkit. Just be aware that for all but 'throwaway' apps, this means that some developer is going to have to learn and master three different GUI toolkits, and create, test, debug, document, and package three totally different interfaces. Maybe you have time to put in the extra effort when writing your apps, but I think a lot of people don't. And when a PHB is told that the only way to support a minority platform is to do that work, s/he's going to say - sorry, just build the Windows version. For my app, I can tell you without doubt - if I had to do what you suggest, Mac support would not be an option. Bye bye Mac port. I performed some training last summer, and to be honest, the Mac users at the training were quite glad that a Mac version of my app existed and that they weren't marginalized users (as they often end up being in the real world) who would need to "pick up a PC" to undergo the training. It certainly wasn't as 'slick' as an Apple app, but it worked and some people quite liked it. And in the end, that's how I personally measure whether a technology is "good" or not. Whether or not it has a positive impact. So my point is, you may very well be advocating an approach which will marginalize the Mac platform even further. I know that's not your intent, your intent is to see excellent Mac apps get created, but by eschewing and not helping approaches like the one wxWidgets takes, and in fact by making the toolkit sound useless for any practical purpose, you're actually reducing the options that people have, and in doing so making Mac support a less attractive option or possibly a simply unfeasible one. Does the Mac platform really win in the end if you do that? And the shame of it all is that aside from the ambiguous, off-hand comments ("widgets designed by children", "a really good cross platform GUI toolkit is not possible") that do little except poke fun at projects such as wxPython, we get very little constructive feedback about exactly what needs fixing. But I guess if you blindly assume it's all "hopeless", then there's little point in that, is there? Kevin From hengist.podd at virgin.net Sun Jan 23 11:35:15 2005 From: hengist.podd at virgin.net (has) Date: Sun Jan 23 11:35:22 2005 Subject: [Pythonmac-SIG] portability problem with py2app-built app Message-ID: Hi, Having a problem with a semi-standalone app built using py2app 0.1.7. Building it OMM (OS10.2.8, MacPython 2.3.3) and the app works fine here, but on the user's machine (OS10.3, standard Apple-installed MacPython) it shows a dialog saying that it requires Python 2.3. What's wrong? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From pymac at jorjun.org.uk Sun Jan 23 14:19:43 2005 From: pymac at jorjun.org.uk (Pete) Date: Sun Jan 23 14:19:46 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> <41EE9ED8.3000506@noaa.gov> Message-ID: <7222EA1D-6D41-11D9-8A2E-0003936CD80C@jorjun.org.uk> > So my point is, you may very well be advocating an approach which will > marginalize the Mac platform even further. I know that's not your > intent, your intent is to see excellent Mac apps get created, but by > eschewing and not helping approaches like the one wxWidgets takes, and > in fact by making the toolkit sound useless for any practical purpose, > you're actually reducing the options that people have, and in doing so > making Mac support a less attractive option or possibly a simply > unfeasible one. Does the Mac platform really win in the end if you do > that? > > And the shame of it all is that aside from the ambiguous, off-hand > comments ("widgets designed by children", "a really good cross > platform GUI toolkit is not possible") that do little except poke fun > at projects such as wxPython, we get very little constructive feedback > about exactly what needs fixing. But I guess if you blindly assume > it's all "hopeless", then there's little point in that, is there? > > Kevin Personally I have a great application and I don't care about the 'market' - I don't owe them anything, especially the sheepish ones. My app' is currently very simple and I am going to continue developing it on the greatest client platform available using the very best tools. I have now decided that portability in the context of evolving a piece of work is just a distraction. When a better (more productive and elegant) OS than OS X shows up I will jump ship. I prefer diversity to homogeneity, any-day. Something like Pythoncard which is now cross-platform was inspired by HyperCard (Mac only) as was the common hypertext browser, I believe. I wish there were more developer-oriented operating systems out there. There is far too much code that needs writing and precious little time. A rich platform can stimulate rich new applications. Pete From hengist.podd at virgin.net Sun Jan 23 15:29:25 2005 From: hengist.podd at virgin.net (has) Date: Sun Jan 23 15:29:42 2005 Subject: [Pythonmac-SIG] Python+Automator? Message-ID: Hey all, Just reading up on Automator development and wondering if the MacPython community (or anyone in it) has any plans to 0wnz0r it yet? Like providing a 'Python Automator Action' template for Xcode, flogging a nice introductory 'Developing Automator Actions with Python' article to online tech sites like O'Reilly, making themselves a presence on Automator mailing lists and forums when they arrive, etc. With Tiger arriving soon, seems like a grand opportunity for someone with a pre-release build and a hankering for MacPython evangelism to get in at the head of the rush and mop the floor with the competition. :) Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Sun Jan 23 15:42:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 23 15:43:01 2005 Subject: [Pythonmac-SIG] portability problem with py2app-built app In-Reply-To: References: Message-ID: <6B9A0EB4-D19D-4ABF-B125-D457F33C6305@redivi.com> On Jan 23, 2005, at 5:35 AM, has wrote: > Having a problem with a semi-standalone app built using py2app 0.1.7. > Building it OMM (OS10.2.8, MacPython 2.3.3) and the app works fine > here, but on the user's machine (OS10.3, standard Apple-installed > MacPython) it shows a dialog saying that it requires Python 2.3. > What's wrong? > Nothing. The semi-standalone option depends on an equivalent Python installation and it didn't find one. An equivalent Python installation means that there is either one in the bundle, or on the filesystem in an identical location. If you look at the Info.plist in a py2app application, is lists the equivalent Python installations: PyRuntimeLocations @executable_path/../Frameworks/Python.framework/Versions/2.3/ Python /System/Library/Frameworks/Python.framework/Versions/2.3/ Python When using --semi-standalone, your Python extensions can't have their Mach-O headers rewritten. If they are linked on a version of Python or platform that doesn't use -undefined dynamic_lookup, your application is susceptible to the Multiple Python Problem. I chose to display an error dialog and quit rather than run with no possibility to display an error message if something goes wrong. You can override the contents of PyRuntimeLocations with the plist option, but the recommended solution to building a Python application that runs on multiple versions of OS X is to use a standalone bundle built on[1] the earliest supported version of Mac OS X. In the future, py2app may audit your application to determine if it is safe to use "any" version of Python (no extensions, or extensions with only -undefined dynamic_lookup).. however, that still won't support your use case. In theory, it could use macholib to rewrite the headers at runtime into a temp dir if it determines that this is necessary, but I'm not going to implement that. [1] I have successfully been able to build an OS X 10.2 compatible application on a later version of OS X, but all of the components that go into the bundle (extensions and Python) were compiled on OS X 10.2 and copied over. -bob From bob at redivi.com Sun Jan 23 15:55:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 23 15:55:08 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: On Jan 23, 2005, at 9:29, has wrote: > Just reading up on Automator development > and wondering > if the MacPython community (or anyone in it) has any plans to 0wnz0r > it yet? Like providing a 'Python Automator Action' template for Xcode, > flogging a nice introductory 'Developing Automator Actions with > Python' article to online tech sites like O'Reilly, making themselves > a presence on Automator mailing lists and forums when they arrive, > etc. > > With Tiger arriving soon, seems like a grand opportunity for someone > with a pre-release build and a hankering for MacPython evangelism to > get in at the head of the rush and mop the floor with the competition. > :) Given the description, it would be trivial to write an Automator Action in PyObjC 1.2+ using the py2app plug-in bundle support. I doubt I'll be using Automator often enough to become a PyObjC Automator evangelist though. -bob From hengist.podd at virgin.net Sun Jan 23 16:32:23 2005 From: hengist.podd at virgin.net (has) Date: Sun Jan 23 16:40:08 2005 Subject: [Pythonmac-SIG] portability problem with py2app-built app In-Reply-To: <6B9A0EB4-D19D-4ABF-B125-D457F33C6305@redivi.com> References: <6B9A0EB4-D19D-4ABF-B125-D457F33C6305@redivi.com> Message-ID: Bob wrote: >>Having a problem with a semi-standalone app built using py2app >>0.1.7. Building it OMM (OS10.2.8, MacPython 2.3.3) and the app >>works fine here, but on the user's machine (OS10.3, standard >>Apple-installed MacPython) it shows a dialog saying that it >>requires Python 2.3. What's wrong? >> >Nothing. The semi-standalone option depends on an equivalent Python >installation and it didn't find one. An equivalent Python >installation means that there is either one in the bundle, or on the >filesystem in an identical location. Ahh, right. This wasn't obvious. >When using --semi-standalone, your Python extensions can't have >their Mach-O headers rewritten. If they are linked on a version of >Python or platform that doesn't use -undefined dynamic_lookup, You mean installations like (e.g.) Apple's MacPython on 10.3? Sorry my C/ObjC is extremely limited - probably best if it's explained in dummy talk. Is there a definitive document I can go read that describes the scope, scale and implications of this problem? >You can override the contents of PyRuntimeLocations with the plist >option, but the recommended solution to building a Python >application that runs on multiple versions of OS X is to use a >standalone bundle built on[1] the earliest supported version of Mac >OS X. Only problem with that is it bumps each app's size by about 7MB, which is a bit of a hog for any user on dialup... especially if I'm shifting serveral 'small' apps at a time. >In the future, py2app may audit your application to determine if it >is safe to use "any" version of Python (no extensions, or extensions >with only -undefined dynamic_lookup).. however, that still won't >support your use case. My immediate problem is making ASTS portable, but I've got other apps in development that are going to have the same problem. And I can't afford a copy of 10.3 to do a parallel build on, so building cross-platform on 10.2 is currently my only option. What if I exclude appscript from the app (it can be provided as a separate one-off installation via a third-party binary installer) and munge its Info.plist to pick up Apple's MacPython? >In theory, it could use macholib to rewrite the headers at runtime >into a temp dir if it determines that this is necessary, but I'm not >going to implement that. Would this solve the problem (and at what cost)? Any other options open to me? I can solve the ASTS problem by having a 10.3 build included in the 10.3 binary installer, but it does put a bit of a damper on me other ambitions until I can raise the cost of an upgrade or two. Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Sun Jan 23 16:52:44 2005 From: hengist.podd at virgin.net (has) Date: Sun Jan 23 16:52:56 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: Bob wrote: >Given the description, it would be trivial to write an Automator >Action in PyObjC 1.2+ using the py2app plug-in bundle support. Cool. How hard would it be to provide casual users a more Pythonic, easy-to-use API over part or all of that, you think? Or would it be more sensible to wait for Python's OSA support to get to the level where it could use the Studio API? An Xcode template would be nice as well; even if only for marketing's sake. Would that be a big job? >I doubt I'll be using Automator often enough to become a PyObjC >Automator evangelist though. I'm sure if someone provides a nice, easy-to-use infrastructure then other folks will be able to evangelise it. (Python as the de-facto OS X Scripting Language... Mmmm....) has -- http://freespace.virgin.net/hamish.sanderson/ From charles.hartman at conncoll.edu Sun Jan 23 16:57:40 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sun Jan 23 16:57:45 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <7222EA1D-6D41-11D9-8A2E-0003936CD80C@jorjun.org.uk> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> <41EE9ED8.3000506@noaa.gov> <7222EA1D-6D41-11D9-8A2E-0003936CD80C@jorjun.org.uk> Message-ID: <82DE40EA-6D57-11D9-8D0C-000D933C27EA@conncoll.edu> I have to say I fall between the two positions. Writing applications that have some pedagogical component, as I often do, and finding that 90% of students can't run it because it runs only on Mac, gets really, really tiresome in the long run. (An old tutorial Hypercard stack is still waiting for me to find some way to port it, which PythonCard is *certainly* not ready to do.) That's what brought me to Python in the first place (and to wx in the second). At the same time, the idea of doing separately tuned developments for the GUIs of different platforms is simply out of the question. I don't even *have* different platforms (I sneak onto a colleague's machine to see if my Windows builds work). Certainly this distinguishes what I write from commercial apps; but when you ask me to describe the result as "throwaway," I balk. Charles Hartman On Jan 23, 2005, at 8:19 AM, Pete wrote: >> So my point is, you may very well be advocating an approach which >> will marginalize the Mac platform even further. I know that's not >> your intent, your intent is to see excellent Mac apps get created, >> but by eschewing and not helping approaches like the one wxWidgets >> takes, and in fact by making the toolkit sound useless for any >> practical purpose, you're actually reducing the options that people >> have, and in doing so making Mac support a less attractive option or >> possibly a simply unfeasible one. Does the Mac platform really win in >> the end if you do that? >> >> And the shame of it all is that aside from the ambiguous, off-hand >> comments ("widgets designed by children", "a really good cross >> platform GUI toolkit is not possible") that do little except poke fun >> at projects such as wxPython, we get very little constructive >> feedback about exactly what needs fixing. But I guess if you blindly >> assume it's all "hopeless", then there's little point in that, is >> there? >> >> Kevin > > Personally I have a great application and I don't care about the > 'market' - I don't owe them anything, especially the sheepish ones. > My app' is currently very simple and I am going to continue developing > it on the greatest client platform available using the very best > tools. I have now decided that portability in the context of evolving > a piece of work is just a distraction. When a better (more productive > and elegant) OS than OS X shows up I will jump ship. > I prefer diversity to homogeneity, any-day. Something like Pythoncard > which is now cross-platform was inspired by HyperCard (Mac only) as > was the common hypertext browser, I believe. I wish there were more > developer-oriented operating systems out there. There is far too much > code that needs writing and precious little time. A rich platform can > stimulate rich new applications. > > Pete > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com From bob at redivi.com Sun Jan 23 19:10:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 23 19:11:02 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> On Jan 23, 2005, at 10:52, has wrote: > Bob wrote: > >> Given the description, it would be trivial to write an Automator >> Action in PyObjC 1.2+ using the py2app plug-in bundle support. > > Cool. How hard would it be to provide casual users a more Pythonic, > easy-to-use API over part or all of that, you think? Or would it be > more sensible to wait for Python's OSA support to get to the level > where it could use the Studio API? Well, you need to write one class and implement one particular function that returns a list. I don't really see what you could do to make it significantly easier to use beyond creating a template for the 5 or 6 lines of boilerplate. The Objective-C API is going to be faster and richer anyway, I don't see a reason to care about the OSA interface for Automator in this context. > An Xcode template would be nice as well; even if only for marketing's > sake. Would that be a big job? Not particularly. -bob From bob at redivi.com Sun Jan 23 19:28:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 23 19:28:41 2005 Subject: [Pythonmac-SIG] portability problem with py2app-built app In-Reply-To: References: <6B9A0EB4-D19D-4ABF-B125-D457F33C6305@redivi.com> Message-ID: <97F4E84A-6D6C-11D9-90F7-000A95BA5446@redivi.com> On Jan 23, 2005, at 10:32, has wrote: > Bob wrote: > >>> Having a problem with a semi-standalone app built using py2app >>> 0.1.7. Building it OMM (OS10.2.8, MacPython 2.3.3) and the app works >>> fine here, but on the user's machine (OS10.3, standard >>> Apple-installed MacPython) it shows a dialog saying that it requires >>> Python 2.3. What's wrong? >>> >> Nothing. The semi-standalone option depends on an equivalent Python >> installation and it didn't find one. An equivalent Python >> installation means that there is either one in the bundle, or on the >> filesystem in an identical location. > > Ahh, right. This wasn't obvious. > > >> When using --semi-standalone, your Python extensions can't have their >> Mach-O headers rewritten. If they are linked on a version of Python >> or platform that doesn't use -undefined dynamic_lookup, > > You mean installations like (e.g.) Apple's MacPython on 10.3? Sorry my > C/ObjC is extremely limited - probably best if it's explained in dummy > talk. Is there a definitive document I can go read that describes the > scope, scale and implications of this problem? I've posted summaries of the multiple python problem to this list before, you'll have to search the archives.. I don't have a link handy, and it's not really documented elsewhere. >> You can override the contents of PyRuntimeLocations with the plist >> option, but the recommended solution to building a Python application >> that runs on multiple versions of OS X is to use a standalone bundle >> built on[1] the earliest supported version of Mac OS X. > > Only problem with that is it bumps each app's size by about 7MB, which > is a bit of a hog for any user on dialup... especially if I'm shifting > serveral 'small' apps at a time. In my 10.2 compatible application, zipped with -r9 (minus non-Python resources), it is less than 2 megs. 2 megs is a lot less than 7 :) >> In the future, py2app may audit your application to determine if it >> is safe to use "any" version of Python (no extensions, or extensions >> with only -undefined dynamic_lookup).. however, that still won't >> support your use case. > > My immediate problem is making ASTS portable, but I've got other apps > in development that are going to have the same problem. And I can't > afford a copy of 10.3 to do a parallel build on, so building > cross-platform on 10.2 is currently my only option. What if I exclude > appscript from the app (it can be provided as a separate one-off > installation via a third-party binary installer) and munge its > Info.plist to pick up Apple's MacPython? That creates the same problem all in a different context. If you can't build 10.3 extensions, then you can't build 10.3 extensions, and you will ALWAYS have the multiple python problem UNLESS you are using standalone builds. >> In theory, it could use macholib to rewrite the headers at runtime >> into a temp dir if it determines that this is necessary, but I'm not >> going to implement that. > > Would this solve the problem (and at what cost)? Quite a bit of development for very little return. It's only relevant to OS X 10.2 compatible --semi-standalone builds, which I don't care about at all. When I do 10.2 compatible applications, I need to make them standalone because they are for consumers. I'd rather buy you a copy of 10.3 than write this code, but I'm not going to do either :) > Any other options open to me? I can solve the ASTS problem by having a > 10.3 build included in the 10.3 binary installer, but it does put a > bit of a damper on me other ambitions until I can raise the cost of an > upgrade or two. Not really. -bob From kevino at tulane.edu Sun Jan 23 22:39:39 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Sun Jan 23 22:39:49 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: <7222EA1D-6D41-11D9-8A2E-0003936CD80C@jorjun.org.uk> References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> <41EE9ED8.3000506@noaa.gov> <7222EA1D-6D41-11D9-8A2E-0003936CD80C@jorjun.org.uk> Message-ID: <48F25A18-6D87-11D9-B3CE-000393CB1C86@tulane.edu> Hi Pete, On Jan 23, 2005, at 5:19 AM, Pete wrote: [snip] > Personally I have a great application and I don't care about the > 'market' - I don't owe them anything, especially the sheepish ones. > My app' is currently very simple and I am going to continue developing > it on the greatest client platform available using the very best > tools. I have now decided that portability in the context of evolving > a piece of work is just a distraction. When a better (more productive > and elegant) OS than OS X shows up I will jump ship. I understand your position, but I think you're lucky if the above factors are the biggest concerns you have when developing an app. You get to develop the app you want, targeting your OS and target audience based largely on what you yourself prefer. However, many, many people don't have that flexibility. (Myself included.) They need to target other OSes in order to be successful. I wasn't arguing that you should use wxPython; instead, I was arguing that particularly the Python maintainers shouldn't be talking down the product as only for 'throwaway' software and the like, because while it may not meet your, or their, needs/criteria, that doesn't mean the software is useless to everybody. It's one thing to say "I don't need it" or "this isn't for me", and another entirely to say "this can only be used to write throwaway apps/code". After all, I've seen several people argue that Python, being a scripting language, is useless for writing 'real' code. But it seems to work very, very well for me, so either those people are wrong, or everything I write isn't 'real' code. Thanks, Kevin From Jack.Jansen at cwi.nl Sun Jan 23 23:28:29 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Jan 23 23:28:07 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: <1B1F81E4-6D8E-11D9-82B4-000D934FF6B4@cwi.nl> On 23-jan-05, at 15:55, Bob Ippolito wrote: > > On Jan 23, 2005, at 9:29, has wrote: > >> Just reading up on Automator development >> and >> wondering if the MacPython community (or anyone in it) has any plans >> to 0wnz0r it yet? Like providing a 'Python Automator Action' template >> for Xcode, flogging a nice introductory 'Developing Automator Actions >> with Python' article to online tech sites like O'Reilly, making >> themselves a presence on Automator mailing lists and forums when they >> arrive, etc. >> >> With Tiger arriving soon, seems like a grand opportunity for someone >> with a pre-release build and a hankering for MacPython evangelism to >> get in at the head of the rush and mop the floor with the >> competition. :) > > Given the description, it would be trivial to write an Automator > Action in PyObjC 1.2+ using the py2app plug-in bundle support. I > doubt I'll be using Automator often enough to become a PyObjC > Automator evangelist though. What's the advantage of PyObjC here? Just because it makes it easier to write the plugin, or does it help with writing the Python code too? Because I wouldn't mind having automator support in a future "MacPython for Tiger additions"... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Mon Jan 24 00:16:49 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Jan 24 00:15:56 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> <41EE9ED8.3000506@noaa.gov> Message-ID: On 22-jan-05, at 2:21, Kevin Ollivier wrote: > Hi Jack, Hi Kevin! First: sorry for my bad choice of words. "throwaway apps" especially is not what I should have said, and some of the other words were badly chosen too. I definitely don't want to belittle the work you're doing with wxPython (and other people with other toolkits), far from it! > I think you're getting bogged down by the differences between > platforms rather than abstracting them. ;-) Which is what any > cross-platform developer will need to do if they wish to succeed, > regardless of what GUI toolkit(s) they use. For the most part, it > isn't 'what' the native toolkits (or platforms) do that differ, it's > 'how' they do it. So if you program 'what' you want to do, and design > the toolkit to figure out 'how' to do it correctly on each platform, a > lot of times you can get the right look *and* feel without much extra > effort. Granted, there are some technical challenges (look at Apple's > Carbon text control technologies, like MLTE for example, where > sometimes you need to manually implement even basic, standard > functionality), but I have a hard time understanding how these > difficulties are insurmountable. I guess my real point is that once you abstract that far enough you're at the MVC level. To name just a few paradigms that differ between Mac and Windows: - Standard menu structure and shortcuts, i.e. where the Preferences command is, whether it's called Preferences or Settings and its shortcut, the Windows menu, Help, etc. are completely different. - Treatment of toolbars. Windows users like oodles of them, Mac users are used to one. Windows programs often have them filled with dropdown menus, etc. - Mac preferences tend to be direct manipulation, windows preferences tend to be cancel/ok/apply style. - Mac programs tend to require every command to be available somewhere in the menu bar, with toolbar/contextual menu entries used as shortcuts only. No such rules on Windows. - Two-paned browsers are ubiquitous on Windows. On the Mac they look otherworldly. - The Mac floating palette style is cumbersome on Windows (cf. all Adobe software), and the Windows MDI architecture translates very badly to the Mac: window-in-a-window is abysmal, but multiple toplevel windows is bad too because there often tend to be really many of them. Tabbed windows for, say, editing multiple source files is the norm on Windows (probably because of MDI or the Visual Studio example) but makes Mac users scream. By the time you've special-cased all of these there's not all that much machine-independent code left:-( > Well, that depends on the programmer. Even a Mac developer can create > an application that doesn't "feel" like a Mac application; it really > isn't very hard if you try. (And for people coming from Windows, that > will be their natural inclination anyways.) It's arguable that the > problem is the toolkit at all - it's the developer simply not taking > Mac design considerations into effect. Yes, toolkit affects their > ability to do this, but in the end a tool is just a tool. I see no > fundamentally technical reason a cross-platform GUI toolkit *cannot* > provide a user with the ability to create a well-designed Mac > application. Right, but where a local toolkit will get a lot of things right automatically (or because the skeleton programs already do a lot of the right things) with a cross-platform toolkit you'll have to be aware of the issues... > Just be aware that for all but 'throwaway' apps, this means that some > developer is going to have to learn and master three different GUI > toolkits, and create, test, debug, document, and package three totally > different interfaces. Maybe you have time to put in the extra effort > when writing your apps, but I think a lot of people don't. And when a > PHB is told that the only way to support a minority platform is to do > that work, s/he's going to say - sorry, just build the Windows > version. For my app, I can tell you without doubt - if I had to do > what you suggest, Mac support would not be an option. Bye bye Mac > port. Well... for a commercial app you'll have to do the testing, debugging and packaging anyway. So you'll save on creating and documenting. With only a little on the latter: Adobe and Macromedia (and my previous company, Oratrix) did the multiplatform documentation by putting in one section on the mac (installation and first run) and using a mac screenshot once in every 5 or so. And then one proofread adding a couple of paragraphs. > I performed some training last summer, and to be honest, the Mac users > at the training were quite glad that a Mac version of my app existed > and that they weren't marginalized users (as they often end up being > in the real world) who would need to "pick up a PC" to undergo the > training. It certainly wasn't as 'slick' as an Apple app, but it > worked and some people quite liked it. And in the end, that's how I > personally measure whether a technology is "good" or not. Whether or > not it has a positive impact. Fully agreed. I guess that where I said "throwaway app" I should have said "applications that provide a unique service that isn't available anywhere else". Whether that unique service is for you yourself only (as in a throwaway app) or for a larger community isn't the point. But if your app is competing with other products (an IDE, an image editing program, a database or spreadsheet, whatever) it will really have to stand out in functionality to offset the disadvantages of a cross-platform toolkit. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Mon Jan 24 04:53:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 24 04:53:55 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <1B1F81E4-6D8E-11D9-82B4-000D934FF6B4@cwi.nl> References: <1B1F81E4-6D8E-11D9-82B4-000D934FF6B4@cwi.nl> Message-ID: <8E5B64F9-6DBB-11D9-90F7-000A95BA5446@redivi.com> On Jan 23, 2005, at 17:28, Jack Jansen wrote: > On 23-jan-05, at 15:55, Bob Ippolito wrote: > >> >> On Jan 23, 2005, at 9:29, has wrote: >> >>> Just reading up on Automator development >>> and >>> wondering if the MacPython community (or anyone in it) has any plans >>> to 0wnz0r it yet? Like providing a 'Python Automator Action' >>> template for Xcode, flogging a nice introductory 'Developing >>> Automator Actions with Python' article to online tech sites like >>> O'Reilly, making themselves a presence on Automator mailing lists >>> and forums when they arrive, etc. >>> >>> With Tiger arriving soon, seems like a grand opportunity for someone >>> with a pre-release build and a hankering for MacPython evangelism to >>> get in at the head of the rush and mop the floor with the >>> competition. :) >> >> Given the description, it would be trivial to write an Automator >> Action in PyObjC 1.2+ using the py2app plug-in bundle support. I >> doubt I'll be using Automator often enough to become a PyObjC >> Automator evangelist though. > > What's the advantage of PyObjC here? Just because it makes it easier > to write the plugin, or does it help with writing the Python code too? > > Because I wouldn't mind having automator support in a future > "MacPython for Tiger additions"... The advantage of PyObjC here is that there are two interfaces for creating plugins: Objective-C plugins that implement a certain method, and applescripts that implement a certain handler. Since the latter isn't really possible to do with Python, that leaves PyObjC as the ONLY option, and it happens to be trivial to do. -bob From berkowit at silcom.com Mon Jan 24 06:10:59 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Mon Jan 24 06:11:03 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <8E5B64F9-6DBB-11D9-90F7-000A95BA5446@redivi.com> Message-ID: On 1/23/05 7:53 PM, "Bob Ippolito" wrote: >>> Given the description, it would be trivial to write an Automator >>> Action in PyObjC 1.2+ using the py2app plug-in bundle support. I >>> doubt I'll be using Automator often enough to become a PyObjC >>> Automator evangelist though. >> >> What's the advantage of PyObjC here? Just because it makes it easier >> to write the plugin, or does it help with writing the Python code too? >> >> Because I wouldn't mind having automator support in a future >> "MacPython for Tiger additions"... > > The advantage of PyObjC here is that there are two interfaces for > creating plugins: Objective-C plugins that implement a certain method, > and applescripts that implement a certain handler. Since the latter > isn't really possible to do with Python, that leaves PyObjC as the ONLY > option, and it happens to be trivial to do. Except that you can only write Objective-C Automator actions for Cocoa apps which expose their entire APIs publicly. Only a few Apple apps do that. Nobody else will do it - their developers might write their own Obj-C actions but they won't open source their apps for others to do it. On the other hand, all applescriptable apps are immediately accessible to AppleScript Automator actions. You can cut out a lot of the "internal" scripting by using Cocoa Bindings (as for Obj-C actions) but need AppleScript to talk to the apps. Probably has's appscript will be able to do the same in Python. I can't see how far anyone is going to get with PyObjC except for their own apps, and Apple's Address Book, which Apple is already providing many actions for. -- Paul Berkowitz From bob at redivi.com Mon Jan 24 06:40:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 24 06:41:00 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: <81399216-6DCA-11D9-80C4-000A95BA5446@redivi.com> On Jan 24, 2005, at 0:10, Paul Berkowitz wrote: > On 1/23/05 7:53 PM, "Bob Ippolito" wrote: > >>>> Given the description, it would be trivial to write an Automator >>>> Action in PyObjC 1.2+ using the py2app plug-in bundle support. I >>>> doubt I'll be using Automator often enough to become a PyObjC >>>> Automator evangelist though. >>> >>> What's the advantage of PyObjC here? Just because it makes it easier >>> to write the plugin, or does it help with writing the Python code >>> too? >>> >>> Because I wouldn't mind having automator support in a future >>> "MacPython for Tiger additions"... >> >> The advantage of PyObjC here is that there are two interfaces for >> creating plugins: Objective-C plugins that implement a certain method, >> and applescripts that implement a certain handler. Since the latter >> isn't really possible to do with Python, that leaves PyObjC as the >> ONLY >> option, and it happens to be trivial to do. > > Except that you can only write Objective-C Automator actions for Cocoa > apps > which expose their entire APIs publicly. Only a few Apple apps do that. > Nobody else will do it - their developers might write their own Obj-C > actions but they won't open source their apps for others to do it. On > the > other hand, all applescriptable apps are immediately accessible to > AppleScript Automator actions. You can cut out a lot of the "internal" > scripting by using Cocoa Bindings (as for Obj-C actions) but need > AppleScript to talk to the apps. Probably has's appscript will be able > to do > the same in Python. I can't see how far anyone is going to get with > PyObjC > except for their own apps, and Apple's Address Book, which Apple is > already > providing many actions for. You're totally wrong here. Automator actions *entirely separate* from applications! Apple applications will not and can not support Automator actions directly, but they may ship with Automator actions. Whether these actions communicate with their application via Apple Events, Distributed Objects, or simply link with the same code and do things directly is beside the point entirely. Objective-C actions can perform a superset of what AppleScript actions can do, including sending apple events to other applications, so your rant makes no sense. Yes, you could use appscript from a PyObjC plugin. I would expect that the majority of actions that people will write in Python will do very little inter-application communication anyway and instead will do things that Python is significantly better than AppleScript at (doing stuff on a network, mangling files, calling into Objective-C frameworks, etc.). -bob From kevino at tulane.edu Mon Jan 24 07:42:55 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Mon Jan 24 07:43:31 2005 Subject: [Pythonmac-SIG] coding preference In-Reply-To: References: <6EFDD0F2-67A5-11D9-A56D-0003936CD80C@jorjun.org.uk> <2C581AB4-6830-11D9-A001-000A95BA5446@redivi.com> <41ED475D.3030604@noaa.gov> <0C1AF7B8-69A6-11D9-B0C4-000A95BA5446@redivi.com> <41EE97DD.6000401@noaa.gov> <41EE9ED8.3000506@noaa.gov> Message-ID: <2DC91E3C-6DD3-11D9-B716-000393CB1C86@tulane.edu> Hi Jack, On Jan 23, 2005, at 3:16 PM, Jack Jansen wrote: > > On 22-jan-05, at 2:21, Kevin Ollivier wrote: > >> Hi Jack, > > Hi Kevin! > First: sorry for my bad choice of words. "throwaway apps" especially > is not what I should have said, and some of the other words were badly > chosen too. I definitely don't want to belittle the work you're doing > with wxPython (and other people with other toolkits), far from it! Apology accepted. :) >> I think you're getting bogged down by the differences between >> platforms rather than abstracting them. ;-) Which is what any >> cross-platform developer will need to do if they wish to succeed, >> regardless of what GUI toolkit(s) they use. For the most part, it >> isn't 'what' the native toolkits (or platforms) do that differ, it's >> 'how' they do it. So if you program 'what' you want to do, and design >> the toolkit to figure out 'how' to do it correctly on each platform, >> a lot of times you can get the right look *and* feel without much >> extra effort. Granted, there are some technical challenges (look at >> Apple's Carbon text control technologies, like MLTE for example, >> where sometimes you need to manually implement even basic, standard >> functionality), but I have a hard time understanding how these >> difficulties are insurmountable. > > I guess my real point is that once you abstract that far enough you're > at the MVC level. Sure, but there's a big difference between learning and programming against three toolkits (which all have their own paradigms, APIs, and bugs) and learning and programming against one toolkit that handles much of the differences for you. After all, there's no reason that MVC requires that you use three toolkits instead of one for your GUI. ;-) > To name just a few paradigms that differ between Mac and Windows: > - Standard menu structure and shortcuts, i.e. where the Preferences > command is, whether it's called Preferences or Settings and its > shortcut, the Windows menu, Help, etc. are completely different. Most of these are easy to deal with, and wxPython does deal with Help, About, Preferences, etc. > - Treatment of toolbars. Windows users like oodles of them, Mac users > are used to one. Windows programs often have them filled with dropdown > menus, etc. > - Mac preferences tend to be direct manipulation, windows preferences > tend to be cancel/ok/apply style. But are both of these Windows/Mac differences, or just differences in application design? In other words, is it because Windows users prefer oodles of toolbars, or instead, is it because most developers have never experienced a Mac program and Mac design philosophies? (Many of which aren't specific to the platform.) In any case, customizable toolbars seem to be the solution that Mac-specific and cross-platform apps are headed towards, something wxWidgets or any other toolkit is capable of. > - Mac programs tend to require every command to be available somewhere > in the menu bar, with toolbar/contextual menu entries used as > shortcuts only. No such rules on Windows. Another case that I would argue has little to do with the toolkit itself. And IMHO this is also a case where this isn't Mac-specific design - it's good design. ;-) > - Two-paned browsers are ubiquitous on Windows. On the Mac they look > otherworldly. Using a Drawer or Sidebar (ala Tiger's Mail.app) achieves the same functionality in a way that works on all platforms. (If I understand what you're referring to correctly.) And in fact, Windows Explorer now uses the sidebar approach. (And, BTW, we now have Drawer support in wxWidgets CVS too. It uses a sidebar on other OSes.) > - The Mac floating palette style is cumbersome on Windows (cf. all > Adobe software), and the Windows MDI architecture translates very > badly to the Mac: window-in-a-window is abysmal, but multiple toplevel > windows is bad too because there often tend to be really many of them. > Tabbed windows for, say, editing multiple source files is the norm on > Windows (probably because of MDI or the Visual Studio example) but > makes Mac users scream. Really, MDI has mostly been abandoned on Windows too. MS Office and Macromedia tools now use top level windows for each document, which is actually pretty close to the Mac approach. And Adobe uses floating palettes AND MDI, so the two aren't at all mutually exclusive. I've personally found that dockable palettes work well on Windows, and have seen more and more apps adopting them. IMHO, a good cross-platform solution would be to either use top level windows and palettes (dockable on Windows) on every platform, or have tabbed windows on Windows/Linux and top level windows on Mac. Again, the toolkit can abstract much of this. (wxWidgets I know is coming up with a more cross-platform friendly way of handling multiple document windows, but I admittedly haven't played with it myself.) > By the time you've special-cased all of these there's not all that > much machine-independent code left:-( Sure there is. Dialogs, menus, notebooks/tabs, windows, controls, sliders, process gauges, etc., etc., etc. Going with 3 different native toolkits means learning how to create and manipulate each of these controls 3 separate ways. Not to mention learning three event handling systems, three application frameworks, etc. In the end, people deal more with the GUI "building blocks" than the special cases. (But the special cases are what people remember, because they're a lot more interesting and challenging. ;-) Also, most of the problems you outlined (in fact, all but the first and last, I'd argue) are at their core issues with developers not knowing how to target the Mac platform. The way to resolve that is to tell developers what they should and should not do if they wish to target the Mac platform. In other words, a "Mac development tips for Windows developers" type of guide. (Or actually, a "wxWidgets HIG" which explains how to create solid cross-platform interfaces.) The idea is that, by using this guide, programmers can avoid the most serious pitfalls without even having access to all the platforms they develop for. >> Well, that depends on the programmer. Even a Mac developer can create >> an application that doesn't "feel" like a Mac application; it really >> isn't very hard if you try. (And for people coming from Windows, that >> will be their natural inclination anyways.) It's arguable that the >> problem is the toolkit at all - it's the developer simply not taking >> Mac design considerations into effect. Yes, toolkit affects their >> ability to do this, but in the end a tool is just a tool. I see no >> fundamentally technical reason a cross-platform GUI toolkit *cannot* >> provide a user with the ability to create a well-designed Mac >> application. > > Right, but where a local toolkit will get a lot of things right > automatically (or because the skeleton programs already do a lot of > the right things) with a cross-platform toolkit you'll have to be > aware of the issues... Taking an approach that deals with three different toolkits, you have to be aware of many more issues and you have to be competent in programming against three toolkits that sometimes have very different levels of abstraction (i.e. some are more low-level than others) and very different programming philosophies. You'll have to keep all that straight, and learn how to do everything three different ways. That is pretty darn difficult, and costly. In fact, some developers use wxWidgets for Windows only apps simply because the wxWidgets framework is easier to deal with than using the Microsoft APIs. ;-) >> Just be aware that for all but 'throwaway' apps, this means that some >> developer is going to have to learn and master three different GUI >> toolkits, and create, test, debug, document, and package three >> totally different interfaces. Maybe you have time to put in the extra >> effort when writing your apps, but I think a lot of people don't. And >> when a PHB is told that the only way to support a minority platform >> is to do that work, s/he's going to say - sorry, just build the >> Windows version. For my app, I can tell you without doubt - if I had >> to do what you suggest, Mac support would not be an option. Bye bye >> Mac port. > > Well... for a commercial app you'll have to do the testing, debugging > and packaging anyway. So you'll save on creating and documenting. > > With only a little on the latter: Adobe and Macromedia (and my > previous company, Oratrix) did the multiplatform documentation by > putting in one section on the mac (installation and first run) and > using a mac screenshot once in every 5 or so. And then one proofread > adding a couple of paragraphs. But you will save a LOT on the former. ;-) And, theoretically at least, the debugging and testing phases should also be cheaper because the developer will spend less time working out platform/toolkit-specific bugs and more time on app-specific bugs. The wxWidgets APIs will handle most of that for him/her. For the packaging part, I guess I should have mentioned I'm writing a wxWidgets-style installer which will create NSIS/Inno/RPM/DEB/.app/.pkg/etc. installers based off a master installation file. So eventually, you will save on that too, but to be fair you wouldn't need to use wxWidgets as your toolkit to get that benefit. ;-) >> I performed some training last summer, and to be honest, the Mac >> users at the training were quite glad that a Mac version of my app >> existed and that they weren't marginalized users (as they often end >> up being in the real world) who would need to "pick up a PC" to >> undergo the training. It certainly wasn't as 'slick' as an Apple app, >> but it worked and some people quite liked it. And in the end, that's >> how I personally measure whether a technology is "good" or not. >> Whether or not it has a positive impact. > > Fully agreed. I guess that where I said "throwaway app" I should have > said "applications that provide a unique service that isn't available > anywhere else". Whether that unique service is for you yourself only > (as in a throwaway app) or for a larger community isn't the point. > > But if your app is competing with other products (an IDE, an image > editing program, a database or spreadsheet, whatever) it will really > have to stand out in functionality to offset the disadvantages of a > cross-platform toolkit. I think the main difference here is that you see said disadvantages as inherently built into all cross-platform toolkits, while I see those disadvantages as things that more or less can be addressed/removed, if makers of the toolkit wish to do so. By improving the software, and improving the documentation, I think we can make it so that you can create high-quality Mac apps with wxWidgets, that are native in every sense of the word. I'll agree that wxWidgets isn't totally "there yet" for Mac, but it's a *lot* better than it was even a year ago. Well, in any case, I'm one of those people who thinks actions count more than words. I'm not the fastest guy out there, but when I set my sights on it, I do keep working at it. I'm nothing if not stubborn. So I'll continue along with the other wx devs to try to be able to show you how good a cross-platform toolkit actually can be. If we can make something that Mac users can grudgingly accept as capable of making good Mac interfaces, I'll feel we've accomplished our goal. :-) Thanks, Kevin From brendansimons at yahoo.ca Mon Jan 24 16:03:09 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Mon Jan 24 16:03:13 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 21, Issue 35 In-Reply-To: <20050124110004.52D7A1E4002@bag.python.org> Message-ID: <20050124150309.46065.qmail@web30205.mail.mud.yahoo.com> > If we can make > something that Mac users can grudgingly accept as > capable of making > good Mac interfaces, I'll feel we've accomplished our > goal. :-) Kevin, I would like to thank you for your work towards that end. wxPython allows me to develop my apps both on my home mac, and on my work PC. Not only do my apps look -and feel- native on each platform (after some tweaking, the default border size for most wxWidgets is way too small for os x), but they're future-proof (which is VERY valuable to my company, who's still porting programs from an out-of-business mainframe OS). The result is close enough that I might be able to convince my office to switch to Apple. You can't beat that! Brendan -- Brendan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From brendansimons at yahoo.ca Mon Jan 24 16:03:25 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Mon Jan 24 16:03:29 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 21, Issue 35 In-Reply-To: <20050124110004.52D7A1E4002@bag.python.org> Message-ID: <20050124150325.75132.qmail@web30204.mail.mud.yahoo.com> > If we can make > something that Mac users can grudgingly accept as > capable of making > good Mac interfaces, I'll feel we've accomplished our > goal. :-) Kevin, I would like to thank you for your work towards that end. wxPython allows me to develop my apps both on my home mac, and on my work PC. Not only do my apps look -and feel- native on each platform (after some tweaking, the default border size for most wxWidgets is way too small for os x), but they're future-proof (which is VERY valuable to my company, who's still porting programs from an out-of-business mainframe OS). The result is close enough that I might be able to convince my office to switch to Apple. You can't beat that! Brendan -- Brendan Simons Stern Laboratories ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From bobsavage at mac.com Mon Jan 24 16:21:00 2005 From: bobsavage at mac.com (Bob Savage) Date: Mon Jan 24 16:21:09 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <81399216-6DCA-11D9-80C4-000A95BA5446@redivi.com> References: <81399216-6DCA-11D9-80C4-000A95BA5446@redivi.com> Message-ID: <8DFA1F10-6E1B-11D9-A630-000393083D64@mac.com> On Jan 23, 2005, at 11:40 PM, Bob Ippolito wrote: > I would expect that the majority of actions that people will write in > Python will do very little inter-application communication anyway and > instead will do things that Python is significantly better than > AppleScript at (doing stuff on a network, mangling files, calling into > Objective-C frameworks, etc.). This is consistent with my first reading of the Automator website. It seemed to me that one could write little Python scripts perhaps similar to the "Services" menu, which could be strung together with other "services" inside of Automator as part of a workflow. I once built a whole graphics processing workflow in AppleScript (and a what is now a VERY old version of PhotoShop); there were some things that I might have been able to do in pure AppleScript, but took only two or three lines of Python code to do, so I invoked little Python scripts in a couple of places -- I'm sure many people have similar needs. The website says that you can invoke shell scripts from Automator, however, so from this angle the main thing missing is a little tutorial. best to all, Bob From bob at redivi.com Mon Jan 24 16:32:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 24 16:32:15 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <8DFA1F10-6E1B-11D9-A630-000393083D64@mac.com> References: <81399216-6DCA-11D9-80C4-000A95BA5446@redivi.com> <8DFA1F10-6E1B-11D9-A630-000393083D64@mac.com> Message-ID: <1A292528-6E1D-11D9-8A29-000A95BA5446@redivi.com> On Jan 24, 2005, at 10:21, Bob Savage wrote: > > On Jan 23, 2005, at 11:40 PM, Bob Ippolito wrote: > >> I would expect that the majority of actions that people will write in >> Python will do very little inter-application communication anyway and >> instead will do things that Python is significantly better than >> AppleScript at (doing stuff on a network, mangling files, calling >> into Objective-C frameworks, etc.). > > This is consistent with my first reading of the Automator website. It > seemed to me that one could write little Python scripts perhaps > similar to the "Services" menu, which could be strung together with > other "services" inside of Automator as part of a workflow. I once > built a whole graphics processing workflow in AppleScript (and a what > is now a VERY old version of PhotoShop); there were some things that I > might have been able to do in pure AppleScript, but took only two or > three lines of Python code to do, so I invoked little Python scripts > in a couple of places -- I'm sure many people have similar needs. > > The website says that you can invoke shell scripts from Automator, > however, so from this angle the main thing missing is a little > tutorial. It does say you can invoke shell scripts, but it does not say how. It may be that they simply expect you to use AppleScript's functionality to do it, or perhaps they have a "do shell script" action. It's not possible to say either way with the given information. However, since it is not hard to do it from PyObjC as a plugin, and the interface preserves more information and should be easier to use, there is little reason to even consider the shell script option. -bob From pymac at jorjun.org.uk Mon Jan 24 17:45:50 2005 From: pymac at jorjun.org.uk (Pete) Date: Mon Jan 24 17:45:55 2005 Subject: [Pythonmac-SIG] Re: Office Macs, shudder... In-Reply-To: <20050124150309.46065.qmail@web30205.mail.mud.yahoo.com> References: <20050124150309.46065.qmail@web30205.mail.mud.yahoo.com> Message-ID: <67D14D8E-6E27-11D9-9A89-0003936CD80C@jorjun.org.uk> > The result is close enough that I might be able to > convince my office to switch to Apple. You can't beat > that! > > Brendan I hope the wxPython devotees don't assume that Mac users want to see Macs in the office to replace Windows?? Not me. I used to get cheap remarks every time I bought my powerbook in to the office in the old days (before VB made programmers out of anybody). Some places were even superstitious to the point of preventing access to the intranet. I now think that a cheap, defacto OS suits organ grinding, Java programming, VB-like database forms and other general grist that keeps stock market investors in new cars. And a creative OS refuge for work and projects about which you are genuinely concerned and that relate to personal fulfillment. An informal word of advice, based on painful experience (if you ever work in the UK, at least) : Don't get the two mixed up. Having said all this, the day that OS X becomes widespread in the office will be the day that a New Knuckle OS will appear as viable, edgy alternative! ;-) Peter From berkowit at silcom.com Mon Jan 24 17:45:54 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Mon Jan 24 17:45:59 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <81399216-6DCA-11D9-80C4-000A95BA5446@redivi.com> Message-ID: On 1/23/05 9:40 PM, "Bob Ippolito" wrote: > > You're totally wrong here. Automator actions *entirely separate* from > applications! Apple applications will not and can not support > Automator actions directly, but they may ship with Automator actions. > Whether these actions communicate with their application via Apple > Events, Distributed Objects, or simply link with the same code and do > things directly is beside the point entirely. > > Objective-C actions can perform a superset of what AppleScript actions > can do, including sending apple events to other applications, so your > rant makes no sense. Yes, you could use appscript from a PyObjC > plugin. I would expect that the majority of actions that people will > write in Python will do very little inter-application communication > anyway and instead will do things that Python is significantly better > than AppleScript at (doing stuff on a network, mangling files, calling > into Objective-C frameworks, etc.). > I don't know why you call it a rant - you appear to be a bit deficient in the politeness department. Is it really necessary to turn a conversation into trading insults? I've already made some AppleScript Automator actions, so I know how they work, thanks. My Objective-C is more limited so I haven't tried one of those yet. My reading of the docs, and what I was told by some Apple engineers, implied pretty strongly that you'd have to have access to an application's Cocoa APIs to be able to write an action controlling that application, which I was saying was going to be unlikely unless it was your own application. Also there are two Apple applications which expose their API's: one is Address Book, and I think the other is iChat, so those are available. Of course Objective-C and thus PyObjC are perfect for getting into frameworks and the other stuff you mention. No dispute there. Perhaps we were talking at cross-purposes. The docs mention that you can write "mixed mode" actions that use both AppleScript and ObjC to do both. It hadn't occurred to me that you might want to send raw AppleEvents from ObjC when AppleScript was available, but OK. I suppose that's because I do a lot of AppleScript and find it easier. If you'd really rather send AppleEvents between applications then I'm glad you can do it. I did say that has's appscript would surely be useful here. I think getting into any more detail might be breaking NDA - most of this so far is in the publicly available documents. -- Paul Berkowitz From hengist.podd at virgin.net Mon Jan 24 18:06:01 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 24 18:06:15 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> References: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> Message-ID: Bob wrote: >>>Given the description, it would be trivial to write an Automator >>>Action in PyObjC 1.2+ using the py2app plug-in bundle support. >> >>Cool. How hard would it be to provide casual users a more Pythonic, >>easy-to-use API over part or all of that, you think? > >The Objective-C API is going to be faster and richer anyway, I don't >see a reason to care about the OSA interface for Automator in this >context. PyObjC is a great piece of kit and definitely the way for professional developers to go, but not every Python user is a technical whizz and I can see the PyObjC route being somewhat overwhelming for newbies and casual scripters. Not every user wants, needs or can immediately handle a professional Word/Photoshop/Cumulus/Quark publishing workflow, for example. Some will be much better catered for by something like Pages, which offers less functionality and control but presents it in a way that makes it much easier for non-professionals to use. Less is More, in other words. Same sort of idea here: after all, Automator itself is just a GUI version of Unix pipes and commands, repackaged to suit a different audience. Apple's obviously planning to market AppleScript as the amateur's route into the underpinnings, and ObjC for the professionals. Python easily nails the latter group thanks to PyObjC; what I'm wondering here is how well it's going to cater to the former? Sure as guns, there's going to lots of be Automator users who sooner or later need a custom action, and often that'll mean they'll be going under the hood themselves. A simple, cut-down, newbie-friendly API might make all the difference in bringing these folks to Python, giving them an easy way to get their foot in the door. The alternative is losing that potential audience to AppleScript - a far inferior platform in technical terms, but one which knows a thing or two about presenting itself in a newbie-friendly form. It's a question of marketing really: what type(s) of audience do you wish to promote Python to, and what needs to be done to guarantee each's capture? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Jan 24 18:08:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 24 18:08:52 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: <9A864328-6E2A-11D9-8A29-000A95BA5446@redivi.com> On Jan 24, 2005, at 11:45, Paul Berkowitz wrote: > On 1/23/05 9:40 PM, "Bob Ippolito" wrote: > >> >> You're totally wrong here. Automator actions *entirely separate* from >> applications! Apple applications will not and can not support >> Automator actions directly, but they may ship with Automator actions. >> Whether these actions communicate with their application via Apple >> Events, Distributed Objects, or simply link with the same code and do >> things directly is beside the point entirely. >> >> Objective-C actions can perform a superset of what AppleScript actions >> can do, including sending apple events to other applications, so your >> rant makes no sense. Yes, you could use appscript from a PyObjC >> plugin. I would expect that the majority of actions that people will >> write in Python will do very little inter-application communication >> anyway and instead will do things that Python is significantly better >> than AppleScript at (doing stuff on a network, mangling files, calling >> into Objective-C frameworks, etc.). >> > > I don't know why you call it a rant - you appear to be a bit deficient > in > the politeness department. Is it really necessary to turn a > conversation > into trading insults? I called it a rant because the rest of the thread was about how Python can be used to write Automator Actions, and you were talking about something else entirely. I could've used a better word for it. > I've already made some AppleScript Automator actions, so I know how > they > work, thanks. My Objective-C is more limited so I haven't tried one of > those > yet. My reading of the docs, and what I was told by some Apple > engineers, > implied pretty strongly that you'd have to have access to an > application's > Cocoa APIs to be able to write an action controlling that application, > which > I was saying was going to be unlikely unless it was your own > application. Controlling applications is something you can do with an Automator Action, but it is not what Actions do in the general sense. The way you worded your original response made it sound like controlling other applications is the only reason to use Automator. While it is a good reason, it is not the only reason, and certainly not the most compelling reason to use Python. > Also there are two Apple applications which expose their API's: one is > Address Book, and I think the other is iChat, so those are available. > Of > course Objective-C and thus PyObjC are perfect for getting into > frameworks > and the other stuff you mention. No dispute there. Perhaps we were > talking > at cross-purposes. The docs mention that you can write "mixed mode" > actions > that use both AppleScript and ObjC to do both. It hadn't occurred to > me that > you might want to send raw AppleEvents from ObjC when AppleScript was > available, but OK. I suppose that's because I do a lot of AppleScript > and > find it easier. If you'd really rather send AppleEvents between > applications > then I'm glad you can do it. I did say that has's appscript would > surely be > useful here. While you can send raw AppleEvents from Objective-C, and it is often useful to do so, you certainly don't have to. NSAppleScript has been around since Mac OS X 10.2, and allows you to run AppleScript code from a file (by way of NSURL) or from a NSString. This may or may not be what they meant by "mixed mode" (though "mixed mode" is not mentioned in the public information, so I can't comment further). -bob From hengist.podd at virgin.net Mon Jan 24 18:15:19 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 24 18:15:32 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <81399216-6DCA-11D9-80C4-000A95BA5446@redivi.com> References: <81399216-6DCA-11D9-80C4-000A95BA5446@redivi.com> Message-ID: Bob wrote: >>>>What's the advantage of PyObjC here? Just because it makes it easier >>>>to write the plugin, or does it help with writing the Python code too? >>> >>>The advantage of PyObjC here is that there are two interfaces for >>>creating plugins: Objective-C plugins that implement a certain method, >>>and applescripts that implement a certain handler. Since the latter >>>isn't really possible to do with Python, Not yet, but Philip Aker is planning Apple event handling for PythonOSA. Whether Apple will make it easy or not to use OSA languages other than AS is another question, but at least the potential for writing Python Actions to Automator's OSA API will be there at some point. >>>that leaves PyObjC as the ONLY option, and it happens to be trivial to do. Even for dummies like me, you think? >>Except that you can only write Objective-C Automator actions for Cocoa apps >>which expose their entire APIs publicly. > >You're totally wrong here. Automator actions *entirely separate* >from applications! Paul might've meant you can't write ObjC-based Actions to control apps that provide Apple event interfaces, only apps that expose ObjC APIs. I dunno, what is the state of play re. using Cocoa/ObjC to send AEs to other applications? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Jan 24 18:15:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 24 18:16:03 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> Message-ID: <9CC45C8A-6E2B-11D9-8A29-000A95BA5446@redivi.com> On Jan 24, 2005, at 12:06, has wrote: > Bob wrote: > >>>> Given the description, it would be trivial to write an Automator >>>> Action in PyObjC 1.2+ using the py2app plug-in bundle support. >>> >>> Cool. How hard would it be to provide casual users a more Pythonic, >>> easy-to-use API over part or all of that, you think? >> >> The Objective-C API is going to be faster and richer anyway, I don't >> see a reason to care about the OSA interface for Automator in this >> context. > > PyObjC is a great piece of kit and definitely the way for professional > developers to go, but not every Python user is a technical whizz and I > can see the PyObjC route being somewhat overwhelming for newbies and > casual scripters. > > Not every user wants, needs or can immediately handle a professional > Word/Photoshop/Cumulus/Quark publishing workflow, for example. Some > will be much better catered for by something like Pages, which offers > less functionality and control but presents it in a way that makes it > much easier for non-professionals to use. Less is More, in other > words. > > Same sort of idea here: after all, Automator itself is just a GUI > version of Unix pipes and commands, repackaged to suit a different > audience. Apple's obviously planning to market AppleScript as the > amateur's route into the underpinnings, and ObjC for the > professionals. Python easily nails the latter group thanks to PyObjC; > what I'm wondering here is how well it's going to cater to the former? > > Sure as guns, there's going to lots of be Automator users who sooner > or later need a custom action, and often that'll mean they'll be going > under the hood themselves. A simple, cut-down, newbie-friendly API > might make all the difference in bringing these folks to Python, > giving them an easy way to get their foot in the door. The alternative > is losing that potential audience to AppleScript - a far inferior > platform in technical terms, but one which knows a thing or two about > presenting itself in a newbie-friendly form. > > It's a question of marketing really: what type(s) of audience do you > wish to promote Python to, and what needs to be done to guarantee > each's capture? From the public documentation, you would trivially construct an Action in PyObjC with the following boilerplate: # MyAction.py from Foundation import * class MyAction(NSObject): def runWithInput_fromAction_error_(self, theInput, anAction): if somethingBadHappens: result = None error = someNSError else: result = [some output] error = None return result, error Is that so overwhelming? Do you think that given an Xcode template (that has this code, plus the Info.plist boilerplate), people won't be able to fill some code in and hit the build button? -bob From kevino at tulane.edu Mon Jan 24 19:18:06 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Mon Jan 24 19:18:17 2005 Subject: [Pythonmac-SIG] Re: Office Macs, shudder... In-Reply-To: <67D14D8E-6E27-11D9-9A89-0003936CD80C@jorjun.org.uk> References: <20050124150309.46065.qmail@web30205.mail.mud.yahoo.com> <67D14D8E-6E27-11D9-9A89-0003936CD80C@jorjun.org.uk> Message-ID: <4B3845CC-6E34-11D9-B716-000393CB1C86@tulane.edu> Hi Pete, On Jan 24, 2005, at 8:45 AM, Pete wrote: >> The result is close enough that I might be able to >> convince my office to switch to Apple. You can't beat >> that! >> >> Brendan > I hope the wxPython devotees don't assume that Mac users want to see > Macs in the office to replace Windows?? I don't think wxPython devotees are all of one mind about anything, except possibly that they like wxPython. ;-) Similarly, I don't think Mac users are all of one mind about anything, either. Some of them may actually *want* to see Macs in the office. I think it's even arguable to say that Apple isn't targeting the office. (Who uses the XServe at home?) But this is getting quite a bit off-topic. Thanks, Kevin From hengist.podd at virgin.net Mon Jan 24 20:52:35 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 24 20:55:54 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <9CC45C8A-6E2B-11D9-8A29-000A95BA5446@redivi.com> References: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> <9CC45C8A-6E2B-11D9-8A29-000A95BA5446@redivi.com> Message-ID: Bob wrote: >>It's a question of marketing really: what type(s) of audience do >>you wish to promote Python to, and what needs to be done to >>guarantee each's capture? > >From the public documentation, you would trivially construct an >Action in PyObjC with the following boilerplate: > ># MyAction.py >from Foundation import * >class MyAction(NSObject): > def runWithInput_fromAction_error_(self, theInput, anAction): > if somethingBadHappens: > result = None > error = someNSError > else: > result = [some output] > error = None > return result, error > >Is that so overwhelming? For you, not in the slightest. For me, well I've been doing this Python thing a year now so think I can probably cope. So that's the professional and hack markets covered. Now, what about the newbies, the new blood? The folks who are complete newcomers to Python and/or to programming in general? Try to see it from their point of view: "What's 'Foundation'? What's a 'class'? Why do I return both a result _and_ an error? How do I hook up my super l33t GUI that I built myself by drag-and-drop? That language looks a bit geeky to me. Ho-hum, on run {input, parameters, ignoresInput} set output to {} -- process input items into output items return output end run looks much simpler; think I'll use that instead." And there went your sale. Ouch. i.e. It's not that this particular group _couldn't_ use it if they wanted/had to: vast armies of completely self-taught amateur JavaScripters, ActionScripters and PHPers all achieving remarkable results from a total standing start should prove ordinary folk's fantastic ability to adapt and learn when they really need to. But as a general rule, most folk are busy, lazy, disinterested, and/or have much more important things to do with their time than waste it learning some complex new framework and language. So the chances are they don't. They just want to solve their problem in the least amount of time and work so they can get on with the much more important stuff they were doing before, so it won't much matter if Python is the technically superior option because from where they're standing if it looks like they can solve their problem quicker and easier by going to the competition, then that's what they'll do. Yes, they're a hacktacular bunch and the code that they'll write will make a mature professional man like yourself howl tears of absolute despair at the merest glimpse of it. But just do the math before you write them off, because there's an awful lot more non-programmers out there using Macs than there are programmers. It's the folks like you and me too who are the exception - they're the rule. So if you can bring even a percentage of them into the Python fold then you've just up its marketshare, and getting bums on seats - as any marketing man or Alan Kay will tell you - is the bit that counts most. Build your userbase now, and you can always worry about setting them on the One Path to True Enlightenment later. So again, the question is: do we want 'em; and if we do, how do we ensure Python will be more attractive to them than the competition? Hey, if nothing else p'rhaps some of them newcomers'll be Babes... Rotten job, I know; but gotta do it for the babes, man. ;) has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Jan 24 21:42:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 24 21:42:45 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> <9CC45C8A-6E2B-11D9-8A29-000A95BA5446@redivi.com> Message-ID: <46F38E14-69F9-43BB-A9C2-BF0C58B00A4F@redivi.com> On Jan 24, 2005, at 2:52 PM, has wrote: > Bob wrote: > >>> It's a question of marketing really: what type(s) of audience do you >>> wish to promote Python to, and what needs to be done to guarantee >>> each's capture? >> >> From the public documentation, you would trivially construct an >> Action in PyObjC with the following boilerplate: >> >> # MyAction.py >> from Foundation import * >> class MyAction(NSObject): >> def runWithInput_fromAction_error_(self, theInput, anAction): >> if somethingBadHappens: >> result = None >> error = someNSError >> else: >> result = [some output] >> error = None >> return result, error >> >> Is that so overwhelming? > > For you, not in the slightest. For me, well I've been doing this > Python thing a year now so think I can probably cope. So that's the > professional and hack markets covered. That is the raw boilerplate for using the documented interface as-is. You could of course wrap that six ways to sunday if you wanted it to catch exceptions and throw an error automatically, or whatever. I didn't present such a cleaned up interface because there isn't enough public information available to present an Automator interface that makes sense in that regard. This is simply a good approximation of what the boilerplate will look like that *directly* interfaces with the documented Objective-C interface for Actions. This means no middle-man whatsoever beyond the runtime bridge, no code written by anyone else, nothing but PyObjC 1.2 installed. > Now, what about the newbies, the new blood? The folks who are complete > newcomers to Python and/or to programming in general? Try to see it > from their point of view: Personally, I'd rather not be bothered catering to that class of users. I'm more interested in making the things work correctly for the people who DO know what they're doing. There are lots of people with more interest in making possible things easier, such as yourself, but I'm more inclined to expand what is possible in the first place (in my spare time anyway)... with occasional bouts of cleaning things up and hand-holding (writing documentation, speaking at PyCon, doing a tutorial now and then, answering the mailing lists, setting up websites, releasing software, etc.). -bob From berkowit at silcom.com Mon Jan 24 22:07:22 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Mon Jan 24 22:07:26 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <46F38E14-69F9-43BB-A9C2-BF0C58B00A4F@redivi.com> Message-ID: On 1/24/05 12:42 PM, "Bob Ippolito" wrote: > >> Now, what about the newbies, the new blood? The folks who are complete >> newcomers to Python and/or to programming in general? Try to see it >> from their point of view: > > Personally, I'd rather not be bothered catering to that class of users. > I'm more interested in making the things work correctly for the people > who DO know what they're doing. There are lots of people with more > interest in making possible things easier, such as yourself, but I'm > more inclined to expand what is possible in the first place (in my > spare time anyway)... with occasional bouts of cleaning things up and > hand-holding (writing documentation, speaking at PyCon, doing a > tutorial now and then, answering the mailing lists, setting up > websites, releasing software, etc.). Actually, writing Automator actions is probably always going to be too difficult for that class of "users" (scripters). Even the AppleScript variety is rather complex for such users - lots of different apps and techniques. It's probably on a par with AppleScript Studio unless you want to take advantage of yet another technology that's available - which makes things quicker once you know how but has a steep learning curve. And most applescripters won't even go near Studio because it's "too difficult". The idea here is to develop Automator actions so that _end users_ can automate with complete ease and simplicity, not to make the writing of actions simple. I would agree with Bob that you'd do better to concentrate on doing things right. The applescript code is simpler than ObjC for anyone who's done AppleScript, but not for those who haven't. -- Paul Berkowitz From hengist.podd at virgin.net Mon Jan 24 22:18:48 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 24 22:19:05 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: <46F38E14-69F9-43BB-A9C2-BF0C58B00A4F@redivi.com> References: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> <9CC45C8A-6E2B-11D9-8A29-000A95BA5446@redivi.com> <46F38E14-69F9-43BB-A9C2-BF0C58B00A4F@redivi.com> Message-ID: Bob wrote: >>Now, what about the newbies, the new blood? The folks who are >>complete newcomers to Python and/or to programming in general? > >Personally, I'd rather not be bothered catering to that class of users. Well, I know _you're_ not - that's why the Universe inflicted me upon you, as a form of karmic balance. ;) Still, it's a general question, open to all, and I'm curious to see what perspectives other folks can bring. > I'm more inclined to expand what is possible in the first place (in >my spare time anyway)... with occasional bouts of cleaning things up >and hand-holding (writing documentation, speaking at PyCon, doing a >tutorial now and then, answering the mailing lists, setting up >websites, releasing software, etc.). All of which is hugely appreciated, of course. While I might not doff my cap at every encounter, I'd be the first to acknowledge that you're one of major backbones to MacPython; and without folk like you and Jack and Ronald to support it, it probably wouldn't exist. All the same, I would suggest one small caveat: when developing material intended specifically for the standard library, one should deal with the users one gets, rather than the users one might ideally like. One of Python's great features many other languages, for example, is that it doesn't by design exclude those who _don't_ know what they're doing; and IMO anyone contributing to the language or standard library should feel a certain, shall we say, 'moral obligation' to respect and uphold that position, even if it's not something they have an ideological interest in themselves. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Jan 24 23:00:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 24 23:00:31 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: <214E2B66-6D6A-11D9-90F7-000A95BA5446@redivi.com> <9CC45C8A-6E2B-11D9-8A29-000A95BA5446@redivi.com> <46F38E14-69F9-43BB-A9C2-BF0C58B00A4F@redivi.com> Message-ID: <580D1E68-6E53-11D9-8863-000A95BA5446@redivi.com> On Jan 24, 2005, at 16:18, has wrote: > Bob wrote: > >>> Now, what about the newbies, the new blood? The folks who are >>> complete newcomers to Python and/or to programming in general? >> >> Personally, I'd rather not be bothered catering to that class of >> users. > > Well, I know _you're_ not - that's why the Universe inflicted me upon > you, as a form of karmic balance. ;) > > Still, it's a general question, open to all, and I'm curious to see > what perspectives other folks can bring. > > >> I'm more inclined to expand what is possible in the first place (in >> my spare time anyway)... with occasional bouts of cleaning things up >> and hand-holding (writing documentation, speaking at PyCon, doing a >> tutorial now and then, answering the mailing lists, setting up >> websites, releasing software, etc.). > > All of which is hugely appreciated, of course. While I might not doff > my cap at every encounter, I'd be the first to acknowledge that you're > one of major backbones to MacPython; and without folk like you and > Jack and Ronald to support it, it probably wouldn't exist. > > All the same, I would suggest one small caveat: when developing > material intended specifically for the standard library, one should > deal with the users one gets, rather than the users one might ideally > like. One of Python's great features many other languages, for > example, is that it doesn't by design exclude those who _don't_ know > what they're doing; and IMO anyone contributing to the language or > standard library should feel a certain, shall we say, 'moral > obligation' to respect and uphold that position, even if it's not > something they have an ideological interest in themselves. Other than small patches (plistlib is the biggest of these I guess), filing bugs, and bugging the right people, I have contributed NOTHING to the Python standard library and if I did I would be catering to the general community. I personally don't use much stuff in the Python standard library, and when I do end up using it I usually have to rewrite it in some way ;) For example, bundlebuilder wasn't adequate, so I wrote py2app. py2app originally used modulefinder, but it proved inadequate so I wrote modulegraph. I regularly use Twisted (or Objective-C stuff) for networking because the built-in stuff is not scalable and threading in Python sucks. I fixed plistlib because it handled a few datatypes incorrectly... This is of course not a definitive list :) I do use a lot of the low-level stuff without complaining too much (the data types, itertools, os, sys, datetime, time). Sure, PyObjC and (at least components of) py2app might be slated for inclusion in Python itself, as standard MacPython batteries, or components of some future Mac OS X, but the reality is that they are not yet and there is nobody (that I know of) actively petitioning for this kind of inclusion right now (especially me). It's a tradeoff, once something goes in the standard library or Mac OS X, deprecation takes a long time. In py2app, I still have the freedom to make or break any feature on a whim ;) PyObjC less so, but Ronald and I have a bunch of ideas for PyObjC 1.3 that may cause some minor breakage in the name of functionality and correctness. For example, making the class hierarchy identical to that of the Objective-C runtime, including metaclasses, which fixes the class/instance selector problem but breaks the old-style-class idiom that SomeClass.someSelector(self) is the same as self.someSelector(). Hopefully people aren't doing that, but it's possible they are in some cases at least with NSMutableString because our support for that was kinda stupid in 1.1 and earlier. -bob From hengist.podd at virgin.net Tue Jan 25 02:04:03 2005 From: hengist.podd at virgin.net (has) Date: Tue Jan 25 02:04:15 2005 Subject: [Pythonmac-SIG] Python+Automator? Message-ID: Paul Berkowitz wrote: > >> Now, what about the folks who are complete > >> newcomers to Python and/or to programming in general? > >Actually, writing Automator actions is probably always going to be too >difficult for that class of "users" (scripters). Even the AppleScript >variety is rather complex for such users - lots of different apps and >techniques. Forget about application scripting here: it's totally tangental to the main topic, which is can/should MacPython provide a newbie-friendly system for writing Actions using Python? There's a huge range of tasks Automator Actions could be written to perform that have absolutely nothing to do with application scripting, and for just about any of those Python is far better than AppleScript. Python's hardly the ideal end-user language either, regardless of what its more enthusiastic envangelists might like to claim, but in many respects it's 'good enough'. Like I say, if complete n00bs can pick up enough ActionScript or JavaScript to be a danger to the web, they can grok enough Python to knock some holes in their desktops if they want to too. >It's probably on a par with AppleScript Studio [...] And most >applescripters won't even go near Studio because it's "too difficult". Y'know what this says to me? "Opportunity." Indeed, Studio IS "too difficult" for many novice scripters: that's because it's a quick-n-dirty low-budget lash-up between Cocoa, Xcode and AppleScript, and miles away from a proper end-user oriented environment such as Hypercard. Yet people use it anyway because while it's fairly sucky at ease-of-use, it's still less sucky than anything else available at the same price point (free). Meanwhile, Studio alternatives such as Revolution and RB prove that significanlty lower suckiness _is_ achievable: RunRev & RB users ain't paying that premium price for nothing. So all you gotta do to beat Studio is provide something that's a decent bit less sucky than it is (which may or may not be easy, but it's certainly not impossible) while still holding the same price point (something OSS is reknowned for). Whether or not it's an opportunity worth taking - e.g. could the rewards justify the investment? - is another question. But on the technical side at least it seems likely that Apple's left a noticeable window of opportunity for anyone brave and/or foolish to try claiming it. >The idea here is to develop Automator actions so that _end users_ can >automate with complete ease and simplicity, not to make the writing of >actions simple. False dichotomy. While I absolutely agree with the first, I see absolutely no reason why writing actions should not also be made as simple as possible. Otherwise you might as well argue that there's no point in creating languages like Python because you can already program anything in C. >I would agree with Bob that you'd do better to concentrate >on doing things right. The applescript code is simpler than ObjC for anyone >who's done AppleScript, but not for those who haven't. Well, Action entry and exit points are pretty easy to nail: the AppleScript Action API already does that. Obviously, any folks with Tiger seeds can't discuss NDA'd details with those who don't, so for now a public analysis of the existing UI interaction model and brainstorming of possible better alternatives isn't yet an option. So this thread's really just to get the creative juices woken up; prehaps someone with a seed copy'll decide to pursue it a bit further in private just now, or we can take it to the next stage on-list as Apple releases more technical info into public. Just never say never. (Hey, was a time when you and me didn't know squat about AppleScript 'n Python 'n programming and stuff either - and just look where we are now! End-user's just another potential developer in-waiting, s'all...;) Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Jan 25 02:42:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 25 02:42:10 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: <50B6E61E-6E72-11D9-8863-000A95BA5446@redivi.com> On Jan 24, 2005, at 20:04, has wrote: > Paul Berkowitz wrote: > >> It's probably on a par with AppleScript Studio [...] And most >> applescripters won't even go near Studio because it's "too difficult". > > Y'know what this says to me? "Opportunity." > > Indeed, Studio IS "too difficult" for many novice scripters: that's > because it's a quick-n-dirty low-budget lash-up between Cocoa, Xcode > and AppleScript, and miles away from a proper end-user oriented > environment such as Hypercard. Yet people use it anyway because while > it's fairly sucky at ease-of-use, it's still less sucky than anything > else available at the same price point (free). Meanwhile, Studio > alternatives such as Revolution and RB prove that significanlty lower > suckiness _is_ achievable: RunRev & RB users ain't paying that premium > price for nothing. > > So all you gotta do to beat Studio is provide something that's a > decent bit less sucky than it is (which may or may not be easy, but > it's certainly not impossible) while still holding the same price > point (something OSS is reknowned for). Whether or not it's an > opportunity worth taking - e.g. could the rewards justify the > investment? - is another question. But on the technical side at least > it seems likely that Apple's left a noticeable window of opportunity > for anyone brave and/or foolish to try claiming it. Well, from the documentation, it looks like you need to use Interface Builder in order to write actions... so if Studio is too difficult, just about anything would be. I suppose a few useful templates including cookie cutter UIs could be included, maybe with some kind of declarative way to add widgets (Renaissance?), would be useful to that kind of users you're talking about. You'd really need to develop a bunch of Actions before you'd know... >> The idea here is to develop Automator actions so that _end users_ can >> automate with complete ease and simplicity, not to make the writing of >> actions simple. > > False dichotomy. While I absolutely agree with the first, I see > absolutely no reason why writing actions should not also be made as > simple as possible. Otherwise you might as well argue that there's no > point in creating languages like Python because you can already > program anything in C. Well, in order to have a language like Python, you need people who can already program anything in C. Actions follow similarly, especially out of the box. They're always going to be easier to use than write, though. >> I would agree with Bob that you'd do better to concentrate >> on doing things right. The applescript code is simpler than ObjC for >> anyone >> who's done AppleScript, but not for those who haven't. > > Well, Action entry and exit points are pretty easy to nail: the > AppleScript Action API already does that. Obviously, any folks with > Tiger seeds can't discuss NDA'd details with those who don't, so for > now a public analysis of the existing UI interaction model and > brainstorming of possible better alternatives isn't yet an option. So > this thread's really just to get the creative juices woken up; prehaps > someone with a seed copy'll decide to pursue it a bit further in > private just now, or we can take it to the next stage on-list as Apple > releases more technical info into public. I'm not even sure that NDA'd people are supposed to talk about Tiger amongst themselves. The first rule of ADC is - you do NOT talk about ADC.... :) -bob From clarkson at csl.sony.co.jp Tue Jan 25 03:31:36 2005 From: clarkson at csl.sony.co.jp (Brian Clarkson) Date: Tue Jan 25 03:27:18 2005 Subject: [Pythonmac-SIG] python.h and veclib.h incompatible? Message-ID: <3C04325C-6E79-11D9-8AEE-000D934470FC@csl.sony.co.jp> Hello. I was swig'ing an extension that made use of veclib in its internals and discovered that if python.h is included before veclib.h that compilation will not succeed. It seems they are interacting so that parts of fp.h are being left out when they shouldn't be. I have distilled the problem down to the following simple test case: ****begin test.cpp**** #include #include #include using namespace std; int main(){ cerr << scalb(3,4) << endl; return 0; } ****end test.cpp**** Which when compiled as follows: gcc -I/sw/include/python2.3 -c test.cpp gives the following errors: In file included from /sw/include/python2.3/python.h:70, from test.cpp:1: /sw/include/python2.3/objimpl.h:255: warning: use of `long double' type; its size may change in a future release /sw/include/python2.3/objimpl.h:255: warning: (Long double usage is reported only once for each file. /sw/include/python2.3/objimpl.h:255: warning: To disable this warning, use -Wno-long-double.) In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/CarbonCore.h:165, from /System/Library/Frameworks/CoreServices.framework/Headers/ CoreServices.h:21, from /System/Library/Frameworks/veclib.framework/Headers/veclib.h:20, from test.cpp:2: /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function `long double scalbl(long double, long int)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:1896: error: ` scalb' undeclared (first use this function) /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:1896: error: (Each undeclared identifier is reported only once for each function it appears in.) Other than refactoring in order to hide veclib.h from python.h, does anyone have any fixes for this? Thanks in advance! Brian From brian_l at mac.com Tue Jan 25 07:15:05 2005 From: brian_l at mac.com (Brian Lenihan) Date: Tue Jan 25 07:15:18 2005 Subject: [Pythonmac-SIG] ANN: PySol for OS X Message-ID: <74C0E30C-6E98-11D9-80E6-000A95841920@mac.com> I re-factored Markus F.X.J Oberhumer's excellent PySol solitaire so it could be built as an OS X app bundle using Bob Ippolito's brilliant py2app. In addition, I fixed a few bugs, fixed the OS X key-bindings (in the places that really matter), happied up some icons (thanks to everaldo) and added 172 or so games, including Mahjongg and the Flowersol hanafuda variants. Please download the small version, unless you, or someone close to you, is either a solitaire or mahjongg freak. I am especially interested in finding out if the py2app bundle really works with a stock 10.3 system (being the geek that I am, neither my or my wife's system can be considered stock, although hers does not have mag wheels, yet). http://homepage.mac.com/brian_l/FileSharing.html Yes, I will keep paying Steve until I've made up for all the money MS has squeezed out of my wallet over the years. I'm hoping that I won't burn quite as fiercely when I go. From bob at redivi.com Tue Jan 25 07:39:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 25 07:39:30 2005 Subject: [Pythonmac-SIG] ANN: PySol for OS X In-Reply-To: <74C0E30C-6E98-11D9-80E6-000A95841920@mac.com> References: <74C0E30C-6E98-11D9-80E6-000A95841920@mac.com> Message-ID: On Jan 25, 2005, at 1:15, Brian Lenihan wrote: > I re-factored Markus F.X.J Oberhumer's excellent PySol solitaire so it > could be built as an OS X app bundle using Bob Ippolito's brilliant > py2app. ... > I am especially interested in finding out if the py2app bundle really > works with a stock 10.3 system (being the geek that I am, neither my > or my wife's system can be considered stock, although hers does not > have mag wheels, yet). py2app is designed such that if an application that it builds works at all, it should work everywhere (on a given base platform). It's not really possible to trip it up such that it works on your machine, but not elsewhere unless you're actively trying to do it. Things that could cause this would be: - installing anything other than Mac OS X itself to /System or /usr outside of /usr/local (don't do this! ever!) - specifying --site-packages (will run locally, may not run elsewhere. packages on a user's machine might interfere in some way with yours) - including binary code as a resource explicitly or implicitly via a framework (resources may depend on some other external framework, which won't be found + included.. for example, if you're embedding Tcl and some Tcl extensions that link against non-standard components) - using code that can alternatively use files from some preinstalled location rather than bundle-relative (it could look in your homedir or some absolute path and find stuff it needs) Otherwise, you can be relatively certain that if it runs on your machine, it runs everywhere. (it runs here, btw). -bob From brian_l at mac.com Tue Jan 25 08:09:59 2005 From: brian_l at mac.com (Brian Lenihan) Date: Tue Jan 25 08:10:18 2005 Subject: [Pythonmac-SIG] ANN: PySol for OS X In-Reply-To: References: <74C0E30C-6E98-11D9-80E6-000A95841920@mac.com> Message-ID: <1FD23492-6EA0-11D9-A03B-000A95841920@mac.com> On Jan 24, 2005, at 10:39 PM, Bob Ippolito wrote: > On Jan 25, 2005, at 1:15, Brian Lenihan wrote: > >> I re-factored Markus F.X.J Oberhumer's excellent PySol solitaire so >> it could be built as an OS X app bundle using Bob Ippolito's >> brilliant py2app. > ... >> I am especially interested in finding out if the py2app bundle really >> works with a stock 10.3 system (being the geek that I am, neither my >> or my wife's system can be considered stock, although hers does not >> have mag wheels, yet). > > py2app is designed such that if an application that it builds works at > all, it should work everywhere (on a given base platform). It's not > really possible to trip it up such that it works on your machine, but > not elsewhere unless you're actively trying to do it. Things that > could cause this would be: > - installing anything other than Mac OS X itself to /System or /usr > outside of /usr/local (don't do this! ever!) > - specifying --site-packages (will run locally, may not run elsewhere. > packages on a user's machine might interfere in some way with yours) > - including binary code as a resource explicitly or implicitly via a > framework (resources may depend on some other external framework, > which won't be found + included.. for example, if you're embedding Tcl > and some Tcl extensions that link against non-standard components) > - using code that can alternatively use files from some preinstalled > location rather than bundle-relative (it could look in your homedir or > some absolute path and find stuff it needs) > > Otherwise, you can be relatively certain that if it runs on your > machine, it runs everywhere. (it runs here, btw). Thanks, Bob. I know all that, but I wanted to be sure. Especially with the Tck/Tk and SDL stuff. We get daily reminders that "relatively certain" != "I know". You have done a fine job with py2app and I, for one, am grateful. > > -bob > From skip at pobox.com Tue Jan 25 16:53:38 2005 From: skip at pobox.com (Skip Montanaro) Date: Tue Jan 25 17:00:13 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? Message-ID: <16886.27522.588493.5828@montanaro.dyndns.org> This is probably a bit off-topic for this list, but is the only Mac-specific mailing list I subscribe to, and Mac OSX versioning seems to affect MacPython and many apps built with it. I was prompted to write after seeing Brian Lenihan's post about PySol for Mac OSX. Visiting the page I saw "10.3 only". *sigh* Yet another app I can't run on my laptop. Here's the rub. Apple seems to rather quickly drop support for what appear (numerically) to be minor releases. 10.1 is long gone. I have 10.3 on my G5 and 10.2 on my laptop. I'm loathe to buy 10.3 at this point for my laptop because 10.4 is in beta (right? Apple offered a preview version of 10.4 to me for $500 recently). I figure as soon as I buy 10.3, 10.4 final will be released. 10.3 will start to corrode and I'll be stuck again with "old" software once again. Only now I have two Macs, so the costs are double. It seems that Apple's upgrade policy almost forces me to buy new versions as soon as they are released. If I snooze when new releases come out I quickly get left in the dust and wind up either skipping a version or upgrading right before the next release. (This has happened to me in the past.) I really hate to say this, but in this respect backward compatibility in Windows seems to be much better. Am I missing something? Thx, -- Skip Montanaro skip@mojam.com http://www.mojam.com/ From charles.hartman at conncoll.edu Tue Jan 25 17:09:07 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Jan 25 17:09:11 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16886.27522.588493.5828@montanaro.dyndns.org> References: <16886.27522.588493.5828@montanaro.dyndns.org> Message-ID: <70AFC878-6EEB-11D9-8D0C-000D933C27EA@conncoll.edu> On Jan 25, 2005, at 10:53 AM, Skip Montanaro wrote: > It seems that Apple's upgrade policy almost forces me to buy new > versions as > soon as they are released. If I snooze when new releases come out I > quickly > get left in the dust and wind up either skipping a version or upgrading > right before the next release. (This has happened to me in the past.) > I > really hate to say this, but in this respect backward compatibility in > Windows seems to be much better. Am I missing something? Umm . . . Software Update? Charles Hartman http://cherry.conncoll.edu/cohar http://villex.blogspot.com From bob at redivi.com Tue Jan 25 17:28:51 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Jan 25 17:28:58 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16886.27522.588493.5828@montanaro.dyndns.org> References: <16886.27522.588493.5828@montanaro.dyndns.org> Message-ID: <3289B70E-6EEE-11D9-A261-000A95BA5446@redivi.com> On Jan 25, 2005, at 10:53, Skip Montanaro wrote: > This is probably a bit off-topic for this list, but is the only > Mac-specific > mailing list I subscribe to, and Mac OSX versioning seems to affect > MacPython and many apps built with it. I was prompted to write after > seeing > Brian Lenihan's post about PySol for Mac OSX. Visiting the page I saw > "10.3 > only". *sigh* Yet another app I can't run on my laptop. > > Here's the rub. Apple seems to rather quickly drop support for what > appear > (numerically) to be minor releases. 10.1 is long gone. I have 10.3 > on my > G5 and 10.2 on my laptop. I'm loathe to buy 10.3 at this point for my > laptop because 10.4 is in beta (right? Apple offered a preview > version of > 10.4 to me for $500 recently). I figure as soon as I buy 10.3, 10.4 > final > will be released. 10.3 will start to corrode and I'll be stuck again > with > "old" software once again. Only now I have two Macs, so the costs are > double. For Apple's own software (iTunes, Safari, etc.), they often support the current release version minus one. Apple supports older operating systems by providing security updates, etc. 10.4 is indeed in beta, slated to release sometime the "first half" of this year. Apple offered you an ADC select subscription for $500/yr which includes a seed key which will get you betas on DVD by mail (but also available for download). The ADC subscription also includes access and license to use the release operating systems too, so it's not a bad deal if you're going to (profitably) develop software for the platform. > It seems that Apple's upgrade policy almost forces me to buy new > versions as > soon as they are released. If I snooze when new releases come out I > quickly > get left in the dust and wind up either skipping a version or upgrading > right before the next release. (This has happened to me in the past.) > I > really hate to say this, but in this respect backward compatibility in > Windows seems to be much better. Am I missing something? What you're missing is that this has nothing to do with Apple, it is the third party software developers that are dropping support for 10.2. For Python, the grass is a lot greener when using OS X 10.3. Building 10.2 compatible Python-based applications requires direct access to 10.2 or a significant effort (which few people know how to do, and those that do aren't likely to go through the trouble for free software). In the case of PySol, Use The Source Luke. It should build just fine. There should not be as much of a Python disconnect between 10.3 and 10.4 though. Unlike the difference between 10.2 and 10.3, there are no expected at-the-unix-level changes between Mac OS X 10.3 and 10.4 that will force incompatibility. However, for applications, you're still at the mercy of third party developers. If they choose to use 10.4 specific features (CoreData, etc.) then you're out of luck with 10.3. Apple does not back-port OS features. -bob From njriley at uiuc.edu Tue Jan 25 17:38:18 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue Jan 25 17:39:07 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16886.27522.588493.5828@montanaro.dyndns.org> References: <16886.27522.588493.5828@montanaro.dyndns.org> Message-ID: <20050125163818.GA4417@uiuc.edu> On Tue, Jan 25, 2005 at 09:53:38AM -0600, Skip Montanaro wrote: > Here's the rub. Apple seems to rather quickly drop support for what appear > (numerically) to be minor releases. 10.1 is long gone. I have 10.3 on my > G5 and 10.2 on my laptop. I'm loathe to buy 10.3 at this point for my > laptop because 10.4 is in beta (right? Apple offered a preview version of > 10.4 to me for $500 recently). I figure as soon as I buy 10.3, 10.4 final > will be released. 10.3 will start to corrode and I'll be stuck again with > "old" software once again. 10.3's popularity was a lot greater than 10.2's; also, the time between 10.3 and 10.4 was considerably greater. I imagine it'll last you longer than 10.2 did, but you may find yourself wishing for 10.4 in a few months. > Only now I have two Macs, so the costs are double. Not quite; you can get a "family pack" good for up to 5 machines owned by an individual or family for less than twice the price. > It seems that Apple's upgrade policy almost forces me to buy new versions as > soon as they are released. If I snooze when new releases come out I quickly > get left in the dust and wind up either skipping a version or upgrading > right before the next release. (This has happened to me in the past.) I > really hate to say this, but in this respect backward compatibility in > Windows seems to be much better. Am I missing something? Only that Mac OS X started out a lot less mature than recent versions of Windows, and is evolving a lot faster than Windows, so often the reason why a new Mac OS X version is required is that the functionality simply didn't exist in the prior version. Yes, backwards compatibility in Windows is better than Mac OS X, with most products I see still supporting back to Windows 98, and some requiring Windows 2000 (released December 1999, to use one definition). Mac OS X 10.0 wasn't even released until March 2001. I used 10.0, but had to reboot into Mac OS 9 a lot. 10.1 (September 2001) was a marginal improvement, but not a paid upgrade; still I couldn't use OS X full-time. 10.2 (August 2002) was the first version I voluntarily gave other people to use, and 10.3 (October 2003) the version I gave my mother. 10.4 is unlikely to be released before April 2005. Note that the time between releases continues to increase. I doubt Mac OS X is ever going to see Windows' multi-year release cycles, but you can expect better backwards compatibility in future. -- Nicholas Riley | From skip at pobox.com Tue Jan 25 17:13:23 2005 From: skip at pobox.com (Skip Montanaro) Date: Tue Jan 25 18:00:03 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <70AFC878-6EEB-11D9-8D0C-000D933C27EA@conncoll.edu> References: <16886.27522.588493.5828@montanaro.dyndns.org> <70AFC878-6EEB-11D9-8D0C-000D933C27EA@conncoll.edu> Message-ID: <16886.28707.695775.818171@montanaro.dyndns.org> >> Am I missing something? Charles> Umm . . . Software Update? Software Update won't take me from 10.2 to 10.3. I'm as Software Updated as I can be on my laptop, but it's still 10.2. Skip From berkowit at silcom.com Tue Jan 25 18:24:37 2005 From: berkowit at silcom.com (Paul Berkowitz) Date: Tue Jan 25 18:24:42 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16886.28707.695775.818171@montanaro.dyndns.org> Message-ID: On 1/25/05 8:13 AM, "Skip Montanaro" wrote: > >>> Am I missing something? > > Charles> Umm . . . Software Update? > > Software Update won't take me from 10.2 to 10.3. I'm as Software Updated as > I can be on my laptop, but it's still 10.2. You made it sound as if this was something happening to you on a weekly or monthly basis: > It seems that Apple's upgrade policy almost forces me to buy new versions as > soon as they are released. If I snooze when new releases come out I quickly > get left in the dust and wind up either skipping a version or upgrading > right before the next release. So it's understandable that Charles thought you meant ..x releases. You're talking about major upgrades that are now coming every 18 months or slower. It's hard to snooze through those, especially with all the hoopla that accompanies one. It also seems you're being misled by the 10.x numerology or pretending to be, into imagining the major OS steps are " what appear (numerically) to be minor releases". The cost alone should tell you otherwise. Of course you're just joking. The differences between each of 10.1 to 10.2, 10.2 to 10.3, and form the sound of it, 10.3 to 10.4 are bigger than OS 8 to OS 9 was, by quite a long way. The reason for the small points is surely just that Apple is still "branding" OS X as an entirely separate operating system form what came before. I imagine they'll stick in the 10.x region for a while yet. -- Paul Berkowitz From bobsavage at mac.com Wed Jan 26 00:28:08 2005 From: bobsavage at mac.com (Bob Savage) Date: Wed Jan 26 00:29:02 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: On Jan 24, 2005, at 7:04 PM, has wrote: >> The idea here is to develop Automator actions so that _end users_ can >> automate with complete ease and simplicity, not to make the writing of >> actions simple. > > False dichotomy. While I absolutely agree with the first, I see > absolutely no reason why writing actions should not also be made as > simple as possible. Otherwise you might as well argue that there's no > point in creating languages like Python because you can already > program anything in C. > It's a floor wax *and* a desert topping! Yes, ultimately end users will be assembling pre-built pieces in an easy, visually obvious, snap it together way. And yes, some people will be happy to pay someone else to build a custom piece for them, so that they can snap it into their existing set. And yes, there will be some clever folks in between who might hire someone to do C programming, or perhaps have some legacy code, and figure they can use Python to glue it into their or their customers' workflow. Etc. and Etc. I like has' idea that instead of a VB-like systems integrator group on the Mac platform, these people might stumble across an article on the O'Reilly site or something describing how to do something interesting by writing Python code that is reusable as a component inside of Automator. I would recommend that someone interested in writing said article look specifically at a solution for the publishing industry. That industry has bought into the idea of using Macs, but more importantly, they have bought into the idea of assembling workflows (using AppleScript, traditionally) in order to automate repetitive actions. Perhaps processing of an XML file prior to feeding it into Adobe's InDesign, but really anything cool that's a good read would serve the purpose. Thanks to has for starting this thread, and thanks to Bob Ippolito for contributing code, since at least someone checking the archive can look here: http://mail.python.org/pipermail/pythonmac-sig/2005-January/012696.html From bob at redivi.com Wed Jan 26 00:45:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 26 00:46:00 2005 Subject: [Pythonmac-SIG] Python+Automator? In-Reply-To: References: Message-ID: <2862F99A-6F2B-11D9-8EA4-000A95BA5446@redivi.com> On Jan 25, 2005, at 18:28, Bob Savage wrote: > > On Jan 24, 2005, at 7:04 PM, has wrote: > >>> The idea here is to develop Automator actions so that _end users_ can >>> automate with complete ease and simplicity, not to make the writing >>> of >>> actions simple. >> >> False dichotomy. While I absolutely agree with the first, I see >> absolutely no reason why writing actions should not also be made as >> simple as possible. Otherwise you might as well argue that there's no >> point in creating languages like Python because you can already >> program anything in C. >> > > It's a floor wax *and* a desert topping! Yes, ultimately end users > will be assembling pre-built pieces in an easy, visually obvious, snap > it together way. And yes, some people will be happy to pay someone > else to build a custom piece for them, so that they can snap it into > their existing set. And yes, there will be some clever folks in > between who might hire someone to do C programming, or perhaps have > some legacy code, and figure they can use Python to glue it into their > or their customers' workflow. Etc. and Etc. > > I like has' idea that instead of a VB-like systems integrator group on > the Mac platform, these people might stumble across an article on the > O'Reilly site or something describing how to do something interesting > by writing Python code that is reusable as a component inside of > Automator. I would recommend that someone interested in writing said > article look specifically at a solution for the publishing industry. > That industry has bought into the idea of using Macs, but more > importantly, they have bought into the idea of assembling workflows > (using AppleScript, traditionally) in order to automate repetitive > actions. Perhaps processing of an XML file prior to feeding it into > Adobe's InDesign, but really anything cool that's a good read would > serve the purpose. > > Thanks to has for starting this thread, and thanks to Bob Ippolito for > contributing code, since at least someone checking the archive can > look here: > > http://mail.python.org/pipermail/pythonmac-sig/2005-January/012696.html It's "probably" not correct code, but it is correct enough given the public documentation. I "imagine" that it's close to what you would actually write, though :) -bob From Chris.Barker at noaa.gov Wed Jan 26 06:18:34 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Jan 26 06:18:38 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? Message-ID: ----- Original Message ----- From: Skip Montanaro > This is probably a bit off-topic for this list, That's OK. This list is the only one I'm on where folks that seem to really understand OS-X reside as well. > It seems that Apple's upgrade policy almost forces me to buy new > versions as soon as they are released. It's not so much their policy, as the fact that they have been making major changes, very frequently. This is a good thing, as 10.1 had, at best the quality of a beta version. > I > really hate to say this, but in this respect backward compatibility in > Windows seems to be much better. I'm no fan of windows, but you are absolutely right. Backward compatibility is much better than it has been for OS-X. Of course, it took Windows to get to NT 5 (Win 2000) to be worth using at all. Apple did somethuing similar, but got to 10.3 MUCH faster, once they got started! > Am I missing something? You're missing the fact that OS-X is a propriatary product, and they therefore have you by the b**ls. If you want to run software like that, you need to accept that fact. Apple has a long history of great products, with occasional losers, a dedicated user base, and jerking that user base around once in a while. >From how I read your post, your only real objection is that Apple is making you pay for all these upgrades. That's one thing I like about Linux. Change is rapid, and backward compatibility is no better, but at least I don't have to pay a bunch of money each time I upgrade. As others have pointed out, the number of changes between the 10.1, 10.2, and 10.3 upgrades have been enough to justify calling it a "new" version, and charging for it. However, they have been rapidly released. I think free upgrades for say, three years would be reasonable. On the other hand, some folks like to license software more as a lease. Perhaps $100/yr isn't too much for the use of OS-X. -Chris From brian_l at mac.com Wed Jan 26 07:14:17 2005 From: brian_l at mac.com (Brian Lenihan) Date: Wed Jan 26 07:14:33 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16886.27522.588493.5828@montanaro.dyndns.org> References: <16886.27522.588493.5828@montanaro.dyndns.org> Message-ID: <37f0d64818df1cb3170d152eb3fdc308@mac.com> On Jan 25, 2005, at 7:53 AM, Skip Montanaro wrote: > > This is probably a bit off-topic for this list, but is the only > Mac-specific > mailing list I subscribe to, and Mac OSX versioning seems to affect > MacPython and many apps built with it. I was prompted to write after > seeing > Brian Lenihan's post about PySol for Mac OSX. Visiting the page I saw > "10.3 > only". *sigh* Yet another app I can't run on my laptop. I might be misremembering, but I thought Python on 10.2 was an optional install. I know 10.3 has Python 2.3.0 installed by default, so that is what I built PySol with. I have a stand-alone version which uses Python 2.5, so it should work with whatever you installed on 10.2, but I believe you need a framework build of Python. Bob will correct me if I am wrong. Bob is right: I know how to cross-compile using Apple's tool chain, but I have no idea how to make a 10.2 compatible app bundle using py2app and I have no interest in investing the time to find out how. Markus got annoyed by some people's rather loose behavior with his source code (and their even looser interpretation of what "forking" and GPL compatibility mean) and jerked everything but the code to PySol and the pysolsoundserver from his site. If you take my modified tarball of his code and get the data files from one of my disk images, you can build a version compatible with your system. The pysolsoundserver uses SDL, SDL_mixer, and smpeg. Markus has provided a configure file and a setup.py.in for the sound server which will work with a little minor tweaking (fix the paths, if necessary). There was a bug which prevented PySol from starting if the sound server could not be imported, but I fixed it so the sound server is now optional, but recommended. From pymac at jorjun.org.uk Wed Jan 26 12:52:18 2005 From: pymac at jorjun.org.uk (Pete) Date: Wed Jan 26 12:52:23 2005 Subject: [Pythonmac-SIG] Collaborative pyObjC development Message-ID: Hi Mac fellows Has anyone set up a Plone based site for collaborating on PyObjC software development? If anyone is interested I could set up a site pretty quickly for the purpose. Or if there are Plone experts who would prefer to do this, let me know. I am still a beginner, currently learning how to make portlets and Archetype-based applications, obviously some stuff is better as an interactive OS X App'. Cheers Peter From bob at redivi.com Wed Jan 26 13:01:27 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 26 13:01:36 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <37f0d64818df1cb3170d152eb3fdc308@mac.com> References: <16886.27522.588493.5828@montanaro.dyndns.org> <37f0d64818df1cb3170d152eb3fdc308@mac.com> Message-ID: <9858F908-9DF8-45F1-AFB1-1768B3326416@redivi.com> On Jan 26, 2005, at 1:14 AM, Brian Lenihan wrote: > > On Jan 25, 2005, at 7:53 AM, Skip Montanaro wrote: > >> >> This is probably a bit off-topic for this list, but is the only >> Mac-specific >> mailing list I subscribe to, and Mac OSX versioning seems to affect >> MacPython and many apps built with it. I was prompted to write after >> seeing >> Brian Lenihan's post about PySol for Mac OSX. Visiting the page I >> saw "10.3 >> only". *sigh* Yet another app I can't run on my laptop. > > I might be misremembering, but I thought Python on 10.2 was an > optional install. I know 10.3 has Python 2.3.0 installed by default, > so that is what I built PySol with. I have a stand-alone version > which uses Python 2.5, so it should work with whatever you installed > on 10.2, but I believe you need a framework build of Python. Bob will > correct me if I am wrong. A practically unusable version of Python 2.2.0 shipped with Mac OS X 10.2. If you built Python 2.5 on Mac OS X 10.3, it and anything you build for it (extensions, etc.) are not going to be compatible with Mac OS X 10.2. If you build the Python and all of its extensions on 10.2, then it will. If you build a --semi-standalone PySol it will still bring in the third party extensions, so it's still nothing suitable for 10.2 use. > Bob is right: I know how to cross-compile using Apple's tool chain, > but I have no idea how to make a 10.2 compatible app bundle using > py2app and I have no interest in investing the time to find out how. Well, it's hard enough to where I couldn't figure out how to actually build a Python on Mac OS X 10.3 that was compatible with 10.2, and I tried for the better part of a day, so take that as you will. I gave up and used a Mac OS X 10.2 machine (which I needed for testing anyway) and built Python and all the extensions and transferred it to my 10.3 box. I have a deploy script that sets up the environment properly and runs the py2app setup.py from that 10.2 compatible interpreter and everything just works. > Markus got annoyed by some people's rather loose behavior with his > source code (and their even looser interpretation of what "forking" > and GPL compatibility mean) and jerked everything but the code to > PySol and the pysolsoundserver from his site. If you take my modified > tarball of his code and get the data files from one of my disk images, > you can build a version compatible with your system. The > pysolsoundserver uses SDL, SDL_mixer, and smpeg. Markus has provided > a configure file and a setup.py.in for the sound server which will > work with a little minor tweaking (fix the paths, if necessary). > > There was a bug which prevented PySol from starting if the sound > server could not be imported, but I fixed it so the sound server is > now optional, but recommended. Offering source code is the only feasible option to support Python software on versions of Mac OS X older than your build environment. That's just how it is. It might be somewhat different between 10.3 and 10.4, but I'm not going to make any promises. -bob From pymac at jorjun.org.uk Wed Jan 26 13:24:04 2005 From: pymac at jorjun.org.uk (Pete) Date: Wed Jan 26 13:24:11 2005 Subject: [Pythonmac-SIG] Collaborative pyObjC development In-Reply-To: <7CCD0197-1CAA-4CE0-BA6B-8CE036C33E52@mac.com> References: <7CCD0197-1CAA-4CE0-BA6B-8CE036C33E52@mac.com> Message-ID: <2AA45024-6F95-11D9-9B5C-0003936CD80C@jorjun.org.uk> > > What's wrong with using http://pythonmac.org/wiki ? I think a Plone > site is a bit much. > > -bob Well you have the possibility of developing and sharing Plone Archetypes as well man. My feeling right now for new development : start with a new web-based app that suits all clients-platforms, then build it 'properly' using pyObjc clients and decent native widgets. Diversity is to be encouraged and code sharing with others is very good here too. You never know, somebody might make a Plone App. that will perform the py2App function as a web service. Pete From bob at redivi.com Wed Jan 26 13:56:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 26 13:56:43 2005 Subject: [Pythonmac-SIG] Collaborative pyObjC development In-Reply-To: <2AA45024-6F95-11D9-9B5C-0003936CD80C@jorjun.org.uk> References: <7CCD0197-1CAA-4CE0-BA6B-8CE036C33E52@mac.com> <2AA45024-6F95-11D9-9B5C-0003936CD80C@jorjun.org.uk> Message-ID: On Jan 26, 2005, at 7:24 AM, Pete wrote: >> >> What's wrong with using http://pythonmac.org/wiki ? I think a Plone >> site is a bit much. >> > Well you have the possibility of developing and sharing Plone > Archetypes as well man. > My feeling right now for new development : start with a new web-based > app that suits all clients-platforms, then build it 'properly' using > pyObjc clients and decent native widgets. Diversity is to be > encouraged and code sharing with others is very good here too. You > never know, somebody might make a Plone App. that will perform the > py2App function as a web service. Sounds like a lot more than "setting up a Plone site". If you build it, it might get used, but I wouldn't hold your breath. The wiki is used mostly in a read-only context as-is. Do you have any examples of projects that actually work like that to develop non-web applications? I'm not aware of any projects that use such a development strategy. -bob From pymac at jorjun.org.uk Wed Jan 26 15:36:45 2005 From: pymac at jorjun.org.uk (Pete) Date: Wed Jan 26 15:36:49 2005 Subject: Fwd: [Pythonmac-SIG] Collaborative pyObjC development Message-ID: Begin forwarded message: > From: Pete > Date: 26 January 2005 14:36:16 GMT > To: Bob Ippolito > Subject: Re: [Pythonmac-SIG] Collaborative pyObjC development > > > On 26 Jan 2005, at 12:56, Bob Ippolito wrote: > >> >> On Jan 26, 2005, at 7:24 AM, Pete wrote: >> >>>> >>>> What's wrong with using http://pythonmac.org/wiki ? I think a >>>> Plone site is a bit much. >>>> >>> Well you have the possibility of developing and sharing Plone >>> Archetypes as well man. >>> My feeling right now for new development : start with a new >>> web-based app that suits all clients-platforms, then build it >>> 'properly' using pyObjc clients and decent native widgets. Diversity >>> is to be encouraged and code sharing with others is very good here >>> too. You never know, somebody might make a Plone App. that will >>> perform the py2App function as a web service. >> >> Sounds like a lot more than "setting up a Plone site". If you build >> it, it might get used, but I wouldn't hold your breath. The wiki is >> used mostly in a read-only context as-is. >> >> Do you have any examples of projects that actually work like that to >> develop non-web applications? I'm not aware of any projects that use >> such a development strategy. >> >> -bob > > No Bob > > It think (hope) it is a new and therefore untried and untested > strategy. The thing is the start-up cost is pretty low, my Plone site > has two instances - so at least one for long-running tasks. It costs > me less than $30 per month, how many users that can support I don't > know. Probably only a smallish team. > > -Pete > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1837 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050126/89e7163a/attachment.bin From hengist.podd at virgin.net Wed Jan 26 20:48:51 2005 From: hengist.podd at virgin.net (has) Date: Wed Jan 26 20:48:58 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? Message-ID: Hey, Saw this via Boing Boing: http://carlo.typepad.com/clo/2005/01/the_milliondoll.html Got me wondering if there might be potential for cooking up, say, a Python-based web UI for iTunes that could operate across a LAN? With appscript maturing and more webapp frameworks than you can shake a stick at, it might make a nice opportunity for (Mac)Python to promote itself if somebody with a bit of spare time and some prior webapp experience were interested. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed Jan 26 21:24:25 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Jan 26 21:24:32 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? In-Reply-To: References: Message-ID: <4b16d696bf77cd7c0365c76f080f2126@redivi.com> On Jan 26, 2005, at 14:48, has wrote: > Saw this via Boing Boing: > > http://carlo.typepad.com/clo/2005/01/the_milliondoll.html > > Got me wondering if there might be potential for cooking up, say, a > Python-based web UI for iTunes that could operate across a LAN? With > appscript maturing and more webapp frameworks than you can shake a > stick at, it might make a nice opportunity for (Mac)Python to promote > itself if somebody with a bit of spare time and some prior webapp > experience were interested. It doesn't sound like that's what he wants. There are plenty of ways to remotely control iTunes already, anyway. What I read is that he wants a solution that will keep multiple iTunes libraries in sync, without replicating files to every machine. What's necessary is: (a) an easy way to have multiple drive(s) shared (AFP, SMB, or WebDAV), so that iTunes can point to the files (b) a seamless way to propagate changes between iTunes libraries (appscript could be used in the implementation of this) WebDAV is an interesting possibility because the application could take care of serving it without dealing with admin permissions. I haven't seen a great implementation of it for Python yet, though. I've written a minimal one myself, and there's akaDAV , but it would be quite a bit of effort. Even if you took care of (a) manually, (b) is a hard problem (detecting changes, conflict resolution, rewriting mount points, etc.). -bob From hengist.podd at virgin.net Wed Jan 26 21:50:40 2005 From: hengist.podd at virgin.net (has) Date: Wed Jan 26 21:51:47 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? In-Reply-To: <8D55BDB8-6A13-4DFA-B582-B1A3036D1DC7@mac.com> References: <8D55BDB8-6A13-4DFA-B582-B1A3036D1DC7@mac.com> Message-ID: Bob wrote: >It doesn't sound like that's what he wants. Yeah I know, I was thinking laterally; throwing random ideas into the ring 'n that. iTunes... Mac Mini... media centers... cross-platform... LANs... etc... seems a very wide field; perhaps there's opportunities there for MacPython to do interesting things. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From pymac at jorjun.org.uk Thu Jan 27 02:02:21 2005 From: pymac at jorjun.org.uk (Pete) Date: Thu Jan 27 02:02:26 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? In-Reply-To: References: Message-ID: <196A5B86-6FFF-11D9-AD60-0003936CD80C@jorjun.org.uk> > Got me wondering if there might be potential for cooking up, say, a > Python-based web UI for iTunes that could operate across a LAN? With > appscript maturing and more webapp frameworks than you can shake a > stick at, it might make a nice opportunity for (Mac)Python to promote > itself if somebody with a bit of spare time and some prior webapp > experience were interested. (has) Definitely Has, plenty of multi-user aware stuff to write, that is what i used to do for business, but i have lost a lot of motivation to code these days. Finally I seem to have decided on which clients and server(s) I want, though. It has taken two years of searching about. Kind of pleased that XXX will get a kick up the arse for outsourcing my prospects - if it was them, since so many midrange tasks seem just one free Webkit away, these days. But w.r.t. the Mac : even a simple, practically useful application takes a lot of concentrated effort - true for all GUIs, probably. pyObjc is a blessing here. But I hope that Apple will get the Python bug, big and let us have a Pythonic way in, because there still seems to be too many artifacts in the way of coding a program on an unfamiliar OS. I know what I want to do, I just hate running my eyes up and down the long list of APIs - feels too much like accountancy or something, trying to spot the one I want. I hate to say it, but I wrote VB code when it first came out, and it was pretty awesomely easy to do off the bat. Apple need to make this stuff slightly less eclectic, only slightly :-) Or may I really should invest in a training course of some kind. Cheers -Pete From eric at erickson.on.net Tue Jan 25 18:13:26 2005 From: eric at erickson.on.net (Eric) Date: Thu Jan 27 03:02:25 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? References: <16886.27522.588493.5828@montanaro.dyndns.org> Message-ID: <41F67DAF.FEE895F1@erickson.on.net> Skip Montanaro wrote: > > I really hate to say this, but in this respect backward compatibility in > Windows seems to be much better. Am I missing something? > I think you will find that Windows will quickly catch up in this regard when they (finally) release LONGHORN and they, too, discover the joys of settling in a totally new operating system. At least there was much better backward compatibility over a longer period with Mac as compared to Windows before OSX - and I believe this is what they are aiming at again into the future. This is really small pain we are seeing for the massive gains that OSX brought. I think if we persist for a bit and things settle down in this Brave New MacWorld swetness and light will return (it ain't so bad now). Eric From etrepum at mac.com Wed Jan 26 13:06:42 2005 From: etrepum at mac.com (Bob Ippolito) Date: Thu Jan 27 03:02:27 2005 Subject: [Pythonmac-SIG] Collaborative pyObjC development In-Reply-To: References: Message-ID: <7CCD0197-1CAA-4CE0-BA6B-8CE036C33E52@mac.com> On Jan 26, 2005, at 6:52 AM, Pete wrote: > Has anyone set up a Plone based site for collaborating on PyObjC > software development? No > If anyone is interested I could set up a site pretty quickly for the > purpose. Or if there are Plone experts who would prefer to do this, > let me know. > I am still a beginner, currently learning how to make portlets and > Archetype-based applications, obviously some stuff is better as an > interactive OS X App'. What's wrong with using http://pythonmac.org/wiki ? I think a Plone site is a bit much. -bob From etrepum at mac.com Wed Jan 26 13:06:42 2005 From: etrepum at mac.com (Bob Ippolito) Date: Thu Jan 27 03:02:28 2005 Subject: [Pythonmac-SIG] Collaborative pyObjC development Message-ID: <76A65236-1513-4916-AFFE-5FD61CBB28C2@mac.com> On Jan 26, 2005, at 6:52 AM, Pete wrote: > Has anyone set up a Plone based site for collaborating on PyObjC > software development? No > If anyone is interested I could set up a site pretty quickly for the > purpose. Or if there are Plone experts who would prefer to do this, > let me know. > I am still a beginner, currently learning how to make portlets and > Archetype-based applications, obviously some stuff is better as an > interactive OS X App'. What's wrong with using http://pythonmac.org/wiki ? I think a Plone site is a bit much. -bob From etrepum at mac.com Wed Jan 26 21:03:16 2005 From: etrepum at mac.com (Bob Ippolito) Date: Thu Jan 27 03:02:29 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? In-Reply-To: References: Message-ID: <8D55BDB8-6A13-4DFA-B582-B1A3036D1DC7@mac.com> On Jan 26, 2005, at 2:48 PM, has wrote: > Saw this via Boing Boing: > > http://carlo.typepad.com/clo/2005/01/the_milliondoll.html > > Got me wondering if there might be potential for cooking up, say, a > Python-based web UI for iTunes that could operate across a LAN? With > appscript maturing and more webapp frameworks than you can shake a > stick at, it might make a nice opportunity for (Mac)Python to promote > itself if somebody with a bit of spare time and some prior webapp > experience were interested. It doesn't sound like that's what he wants. There are plenty of ways to remotely control iTunes already, anyway. What I read is that he wants a solution that will keep multiple iTunes libraries in sync, without replicating files to every machine. What's necessary is: (a) an easy way to have multiple drive(s) shared (AFP, SMB, or WebDAV), so that iTunes can point to the files (b) a seamless way to propagate changes between iTunes libraries (appscript could be used in the implementation of this) WebDAV is an interesting possibility because the application could take care of serving it without dealing with admin permissions. I haven't seen a great implementation of it for Python yet, though. I've written a minimal one myself, and there's akaDAV , but it would be quite a bit of effort. Even if you took care of (a) manually, (b) is a hard problem (detecting changes, conflict resolution, rewriting mount points, etc.). -bob From etrepum at mac.com Wed Jan 26 21:03:16 2005 From: etrepum at mac.com (Bob Ippolito) Date: Thu Jan 27 03:02:30 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? Message-ID: On Jan 26, 2005, at 2:48 PM, has wrote: > Saw this via Boing Boing: > > http://carlo.typepad.com/clo/2005/01/the_milliondoll.html > > Got me wondering if there might be potential for cooking up, say, a > Python-based web UI for iTunes that could operate across a LAN? With > appscript maturing and more webapp frameworks than you can shake a > stick at, it might make a nice opportunity for (Mac)Python to promote > itself if somebody with a bit of spare time and some prior webapp > experience were interested. It doesn't sound like that's what he wants. There are plenty of ways to remotely control iTunes already, anyway. What I read is that he wants a solution that will keep multiple iTunes libraries in sync, without replicating files to every machine. What's necessary is: (a) an easy way to have multiple drive(s) shared (AFP, SMB, or WebDAV), so that iTunes can point to the files (b) a seamless way to propagate changes between iTunes libraries (appscript could be used in the implementation of this) WebDAV is an interesting possibility because the application could take care of serving it without dealing with admin permissions. I haven't seen a great implementation of it for Python yet, though. I've written a minimal one myself, and there's akaDAV , but it would be quite a bit of effort. Even if you took care of (a) manually, (b) is a hard problem (detecting changes, conflict resolution, rewriting mount points, etc.). -bob From etrepum at mac.com Wed Jan 26 21:03:16 2005 From: etrepum at mac.com (Bob Ippolito) Date: Thu Jan 27 03:02:31 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? Message-ID: On Jan 26, 2005, at 2:48 PM, has wrote: > Saw this via Boing Boing: > > http://carlo.typepad.com/clo/2005/01/the_milliondoll.html > > Got me wondering if there might be potential for cooking up, say, a > Python-based web UI for iTunes that could operate across a LAN? With > appscript maturing and more webapp frameworks than you can shake a > stick at, it might make a nice opportunity for (Mac)Python to promote > itself if somebody with a bit of spare time and some prior webapp > experience were interested. It doesn't sound like that's what he wants. There are plenty of ways to remotely control iTunes already, anyway. What I read is that he wants a solution that will keep multiple iTunes libraries in sync, without replicating files to every machine. What's necessary is: (a) an easy way to have multiple drive(s) shared (AFP, SMB, or WebDAV), so that iTunes can point to the files (b) a seamless way to propagate changes between iTunes libraries (appscript could be used in the implementation of this) WebDAV is an interesting possibility because the application could take care of serving it without dealing with admin permissions. I haven't seen a great implementation of it for Python yet, though. I've written a minimal one myself, and there's akaDAV , but it would be quite a bit of effort. Even if you took care of (a) manually, (b) is a hard problem (detecting changes, conflict resolution, rewriting mount points, etc.). -bob From bob at redivi.com Thu Jan 27 03:17:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 03:17:26 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? In-Reply-To: References: Message-ID: <982127a34f2e192ce094b38b86cee853@redivi.com> On Jan 26, 2005, at 15:03, Bob Ippolito wrote: > On Jan 26, 2005, at 2:48 PM, has wrote: > > >> Saw this via Boing Boing: >> >> http://carlo.typepad.com/clo/2005/01/the_milliondoll.html >> >> Got me wondering if there might be potential for cooking up, say, a >> Python-based web UI for iTunes that could operate across a LAN? With >> appscript maturing and more webapp frameworks than you can shake a >> stick at, it might make a nice opportunity for (Mac)Python to promote >> itself if somebody with a bit of spare time and some prior webapp >> experience were interested. > > It doesn't sound like that's what he wants. There are plenty of ways > to remotely control iTunes already, anyway. > > What I read is that he wants a solution that will keep multiple iTunes > libraries in sync, without replicating files to every machine. > > What's necessary is: > (a) an easy way to have multiple drive(s) shared (AFP, SMB, or > WebDAV), so that iTunes can point to the files > (b) a seamless way to propagate changes between iTunes libraries > (appscript could be used in the implementation of this) > > WebDAV is an interesting possibility because the application could > take care of serving it without dealing with admin permissions. I > haven't seen a great implementation of it for Python yet, though. > I've written a minimal one myself, and there's akaDAV > , but it would be quite a bit of > effort. Even if you took care of (a) manually, (b) is a hard problem > (detecting changes, conflict resolution, rewriting mount points, > etc.). I just want to apologize for these multiple posts... I was fighting with an email client that apparently has bugs. Won't be sending mail from that machine any time soon :) -bob From skip at pobox.com Thu Jan 27 03:43:05 2005 From: skip at pobox.com (Skip Montanaro) Date: Thu Jan 27 03:43:11 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <41F67DAF.FEE895F1@erickson.on.net> References: <16886.27522.588493.5828@montanaro.dyndns.org> <41F67DAF.FEE895F1@erickson.on.net> Message-ID: <16888.21817.962464.313549@montanaro.dyndns.org> Thanks for all the responses w.r.t. upgrading Mac OSX. My bad experience was when migrating from 9->X on an older iMac. It couldn't have been more than a few weeks after buying 10.1 that 10.2 came out. It just never dawned on me at the time to do any sort of investigation of OSX release schedules. It is heartening to know that the release interval is lengthening as the system stabilizes and that there should be better 10.3->10.4 compatibility. I haven't paid any attention to the temporal timing of OSX releases and wouldn't have any idea how to find info if I was so inclined to do so. Someone suggested I was complaining about having to pay for upgrades. That's not really it at all. I'm happy to pay Apple their due. They have an excellent product. I was miffed that I paid my $99 (or whatever it was) literally weeks before 10.2 came out. I think it would have been wise for Apple to include a coupon for a free or discounted upgrade to 10.2. They clearly knew its release was imminent. Bob mentioned: For Apple's own software (iTunes, Safari, etc.), they often support the current release version minus one. Apple supports older operating systems by providing security updates, etc. In fact I just upgraded to iTunes 4.7.1 on my 10.2 system this evening, so I know it's possible for Apple to continue support of applications on "old" versions of the OS. I haven't seen a functional upgrade of Safari on that OS in quite awhile though. I suspect it has something to do with the fact that iTunes represents a very lucrative revenue stream for Apple, while Safari doesn't. Skip From bob at redivi.com Thu Jan 27 04:16:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 04:16:10 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16888.21817.962464.313549@montanaro.dyndns.org> References: <16886.27522.588493.5828@montanaro.dyndns.org> <41F67DAF.FEE895F1@erickson.on.net> <16888.21817.962464.313549@montanaro.dyndns.org> Message-ID: <56f7db98927e12b92502141af19a9bfd@redivi.com> On Jan 26, 2005, at 21:43, Skip Montanaro wrote: > Thanks for all the responses w.r.t. upgrading Mac OSX. My bad > experience > was when migrating from 9->X on an older iMac. It couldn't have been > more > than a few weeks after buying 10.1 that 10.2 came out. It just never > dawned > on me at the time to do any sort of investigation of OSX release > schedules. The general rule is that as soon as you buy an Apple product, something better will come out before you'd like it to and you'll wish you had waited a few weeks.. unless of course you buy something as soon as its available for order, in which case you'll have to wait more than you'd like to receive it. > It is heartening to know that the release interval is lengthening as > the > system stabilizes and that there should be better 10.3->10.4 > compatibility. > I haven't paid any attention to the temporal timing of OSX releases and > wouldn't have any idea how to find info if I was so inclined to do so. Compatibility -> In -> This -> Direction -> Was -> Never -> A -> Problem! > Someone suggested I was complaining about having to pay for upgrades. > That's not really it at all. I'm happy to pay Apple their due. They > have > an excellent product. I was miffed that I paid my $99 (or whatever it > was) > literally weeks before 10.2 came out. I think it would have been wise > for > Apple to include a coupon for a free or discounted upgrade to 10.2. > They > clearly knew its release was imminent. Obviously they're not going to repackage boxes when they're about to clear them off the shelves. I think Apple *did* have a contingency for users that had very recently purchased the prior release. Did you ask them at the time? > Bob mentioned: > > For Apple's own software (iTunes, Safari, etc.), they often > support the > current release version minus one. Apple supports older operating > systems by providing security updates, etc. > > In fact I just upgraded to iTunes 4.7.1 on my 10.2 system this > evening, so I > know it's possible for Apple to continue support of applications on > "old" > versions of the OS. I haven't seen a functional upgrade of Safari on > that > OS in quite awhile though. I suspect it has something to do with the > fact > that iTunes represents a very lucrative revenue stream for Apple, while > Safari doesn't. Safari was a bad example, but I wouldn't expect any functional updates to 10.2 from here on out. It's very close to missing the mark for "current release version minus one", given that 10.4 is promised for the first half of this year. It wouldn't be the worst thing in the world to buy 10.3 now, because 10.4 is definitely more than a few weeks away, but you certainly wouldn't be getting "full value" from it because it's 15 months old (Oct 24 2003) already. -bob From skip at pobox.com Thu Jan 27 04:37:49 2005 From: skip at pobox.com (Skip Montanaro) Date: Thu Jan 27 04:37:57 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <56f7db98927e12b92502141af19a9bfd@redivi.com> References: <16886.27522.588493.5828@montanaro.dyndns.org> <41F67DAF.FEE895F1@erickson.on.net> <16888.21817.962464.313549@montanaro.dyndns.org> <56f7db98927e12b92502141af19a9bfd@redivi.com> Message-ID: <16888.25101.340579.859752@montanaro.dyndns.org> Bob> It wouldn't be the worst thing in the world to buy 10.3 now, Bob> because 10.4 is definitely more than a few weeks away, but you Bob> certainly wouldn't be getting "full value" from it because it's 15 Bob> months old (Oct 24 2003) already. Where would an interested person find a log of release dates? Skip From richard at commonground.com.au Thu Jan 27 05:49:44 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Jan 27 05:49:53 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? Message-ID: I'm starting on the path to PyObjC, and have made some progress. I'm developing a very simple GUI control panel to allow starting, stopping and status display of a Zope server running on the machine. I've hit a nasty roadblock though - Zope (2.7.4) *requires* Python 2.3.3. Unfortunately, because I want to use all the incredibly useful Zope Daemon management functions (zdaemon), the process that imports PyObjC must import Zope. Is there a way to either: 1. install a newer Python over the Apple one, or 2. install the PyObjC stuff alongside a manually compiled Python? Richard From delza at livingcode.org Thu Jan 27 05:58:43 2005 From: delza at livingcode.org (Dethe Elza) Date: Thu Jan 27 05:58:52 2005 Subject: [Pythonmac-SIG] Categories for class methods Message-ID: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> Hi folks, Is it possible to add class methods to a class using Categories? when I try what appears to me to be the naive way to do it: from objc import Category from AppKit import NSImage class NSImage(Category(NSImage)): def read_(cls, filepath): return NSImage.alloc().initWithhContentsOfFile_(filepath) read_ = classmethod(read_) when I try to call NSImage.read_('/path/to/my/file'), I get: TypeError: Expecting instance of NSImage as self, got one of str Incidentally, is classmethod the proper way to make class methods for PyObjC classes? --Dethe "...our universities, I suggest, are not half-way out of the fifteenth century. [...] The three or four years' course of lectures, the bachelor who knows some, the master who knows most, the doctor who knows all, are ideas that have come down unimpaired from the Middle Ages. Nowadays no one should end his learning while he lives and these university degrees are preposterous. [...] Educationally we are still for all practical purposes in the coach and horse and galley stage." H. G. Wells -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050126/844fdf28/smime.bin From njriley at uiuc.edu Thu Jan 27 06:09:45 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu Jan 27 06:09:49 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <16888.25101.340579.859752@montanaro.dyndns.org> References: <16886.27522.588493.5828@montanaro.dyndns.org> <41F67DAF.FEE895F1@erickson.on.net> <16888.21817.962464.313549@montanaro.dyndns.org> <56f7db98927e12b92502141af19a9bfd@redivi.com> <16888.25101.340579.859752@montanaro.dyndns.org> Message-ID: <20050127050944.GA83197@uiuc.edu> On Wed, Jan 26, 2005 at 09:37:49PM -0600, Skip Montanaro wrote: > > Bob> It wouldn't be the worst thing in the world to buy 10.3 now, > Bob> because 10.4 is definitely more than a few weeks away, but you > Bob> certainly wouldn't be getting "full value" from it because it's 15 > Bob> months old (Oct 24 2003) already. > > Where would an interested person find a log of release dates? I happened to use Ars Technica's reviews, but another good source is Apple's press releases. -- Nicholas Riley | From delza at livingcode.org Thu Jan 27 06:34:25 2005 From: delza at livingcode.org (Dethe Elza) Date: Thu Jan 27 06:34:35 2005 Subject: [Pythonmac-SIG] Categories for class methods In-Reply-To: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> References: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> Message-ID: <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> On 26-Jan-05, at 8:58 PM, Dethe Elza wrote: > class NSImage(Category(NSImage)): > > def read_(cls, filepath): > return NSImage.alloc().initWithhContentsOfFile_(filepath) > read_ = classmethod(read_) er, that should be initWithContentsOfFile_, but still gets the same error even without the typo. --Dethe Excel is the Awk of Windows --Joel Spolsky -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050126/d3df2a73/smime.bin From jkrushen at gmail.com Thu Jan 27 06:59:39 2005 From: jkrushen at gmail.com (Jordan Krushen) Date: Thu Jan 27 06:59:42 2005 Subject: [Pythonmac-SIG] [OT] To upgrade Mac OSX or not? In-Reply-To: <56f7db98927e12b92502141af19a9bfd@redivi.com> References: <16886.27522.588493.5828@montanaro.dyndns.org> <41F67DAF.FEE895F1@erickson.on.net> <16888.21817.962464.313549@montanaro.dyndns.org> <56f7db98927e12b92502141af19a9bfd@redivi.com> Message-ID: On Wed, 26 Jan 2005 22:16:05 -0500, Bob Ippolito wrote: > Obviously they're not going to repackage boxes when they're about to > clear them off the shelves. I think Apple *did* have a contingency for > users that had very recently purchased the prior release. Did you ask > them at the time? FWIW, I bought an iMac (with Jaguar pre-installed) a week after Panther came out, and was eligible for a $30 upgrade. The same was true for iLife recently -- I bought an iBook a few days after iLife '05 came out and qualified for a cheaper upgrade, but only machines that were bought after the release date qualify. I can't state for certain if there's anything to account for purchases a few days before a release, but surely a local Apple shop should be able to confirm our speculation. When I bought the iBook, they simply handed me the form to send in. J. From p.thibault at bigfoot.com Thu Jan 27 07:50:54 2005 From: p.thibault at bigfoot.com (Pierre Thibault) Date: Thu Jan 27 07:50:50 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? Message-ID: Hello, I just made an install of Python 2.4 on my machine. The 'README' is saying that the install is going to take place on /usr/bin but in reality things were installed in /usr/local/bin'. Why is it like that? Regards. --------------------- Pierre From richard at commonground.com.au Thu Jan 27 09:21:51 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Jan 27 09:22:40 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? In-Reply-To: References: Message-ID: <75fe416cd0007da732f0ea34472fc2b6@commonground.com.au> On 27/01/2005, at 5:50 PM, Pierre Thibault wrote: > I just made an install of Python 2.4 on my machine. The 'README' is > saying that the install is going to take place on /usr/bin but in > reality things were installed in /usr/local/bin'. If you built it from scratch, it'll configure to go in /usr/local/bin by default, so the README lies. I'd highly recommend you *don't* install to /usr/bin over the top of the Apple Python (or if you do, when you're done reinstate the symlink to make python2.3 the default). Richard From ronaldoussoren at mac.com Thu Jan 27 12:06:30 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu Jan 27 12:07:14 2005 Subject: [Pythonmac-SIG] Categories for class methods In-Reply-To: <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> References: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> Message-ID: On 27-jan-05, at 6:34, Dethe Elza wrote: > > On 26-Jan-05, at 8:58 PM, Dethe Elza wrote: >> class NSImage(Category(NSImage)): >> >> def read_(cls, filepath): >> return NSImage.alloc().initWithhContentsOfFile_(filepath) >> read_ = classmethod(read_) > > er, that should be initWithContentsOfFile_, but still gets the same > error even without the typo. It's a bug in PyObjC. objc.classAddMethod (which is used by the implementation of Category) doesn't handle classmethods correctly. Ronald From ronaldoussoren at mac.com Thu Jan 27 12:32:28 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu Jan 27 12:32:35 2005 Subject: [Pythonmac-SIG] Categories for class methods In-Reply-To: References: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> Message-ID: <2f6de48b9625bdee429aa080f8b65936@mac.com> On 27-jan-05, at 12:06, Ronald Oussoren wrote: > > On 27-jan-05, at 6:34, Dethe Elza wrote: > >> >> On 26-Jan-05, at 8:58 PM, Dethe Elza wrote: >>> class NSImage(Category(NSImage)): >>> >>> def read_(cls, filepath): >>> return NSImage.alloc().initWithhContentsOfFile_(filepath) >>> read_ = classmethod(read_) >> >> er, that should be initWithContentsOfFile_, but still gets the same >> error even without the typo. > > It's a bug in PyObjC. Which is fixed in SVN (as of 5 minutes ago, revision 1413). Ronald From pymac at jorjun.org.uk Thu Jan 27 13:03:34 2005 From: pymac at jorjun.org.uk (Pete) Date: Thu Jan 27 13:03:39 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? In-Reply-To: References: Message-ID: <780747A2-705B-11D9-B234-0003936CD80C@jorjun.org.uk> > I'm starting on the path to PyObjC, and have made some progress. I'm > developing a very simple GUI control panel to allow starting, stopping > and status display of a Zope server running on the machine. I've hit a > nasty roadblock though - Zope (2.7.4) *requires* Python 2.3.3. > Unfortunately, because I want to use all the incredibly useful Zope > Daemon management functions (zdaemon), the process that imports PyObjC > must import Zope. > > Is there a way to either: > > 1. install a newer Python over the Apple one, or > 2. install the PyObjC stuff alongside a manually compiled Python? > > Richard Installing a new Python over the Apple one is straightforward. A mechanism to keep the client and server process separate could be a good plan though, others on the list would be more qualified to say what that should be? From bob at redivi.com Thu Jan 27 14:14:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 14:14:11 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? In-Reply-To: References: Message-ID: <0b3b57b25c207f26795eb572615aa42b@redivi.com> On Jan 27, 2005, at 1:50, Pierre Thibault wrote: > I just made an install of Python 2.4 on my machine. The 'README' is > saying that the install is going to take place on /usr/bin but in > reality things were installed in /usr/local/bin'. The README is wrong. The installation prefix always defaults to /usr/local. -bob From bob at redivi.com Thu Jan 27 14:14:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 14:14:46 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? In-Reply-To: References: Message-ID: On Jan 26, 2005, at 23:49, Richard Jones wrote: > I'm starting on the path to PyObjC, and have made some progress. I'm > developing a very simple GUI control panel to allow starting, stopping > and status display of a Zope server running on the machine. I've hit a > nasty roadblock though - Zope (2.7.4) *requires* Python 2.3.3. > Unfortunately, because I want to use all the incredibly useful Zope > Daemon management functions (zdaemon), the process that imports PyObjC > must import Zope. > > Is there a way to either: > > 1. install a newer Python over the Apple one, or Never ever do that. > 2. install the PyObjC stuff alongside a manually compiled Python? That works fine. -bob From bob at redivi.com Thu Jan 27 14:31:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 14:31:18 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? In-Reply-To: <75fe416cd0007da732f0ea34472fc2b6@commonground.com.au> References: <75fe416cd0007da732f0ea34472fc2b6@commonground.com.au> Message-ID: <5060c2298929cf95e7d83c3819d7d888@redivi.com> On Jan 27, 2005, at 3:21, Richard Jones wrote: > On 27/01/2005, at 5:50 PM, Pierre Thibault wrote: >> I just made an install of Python 2.4 on my machine. The 'README' is >> saying that the install is going to take place on /usr/bin but in >> reality things were installed in /usr/local/bin'. > > If you built it from scratch, it'll configure to go in /usr/local/bin > by default, so the README lies. I'd highly recommend you *don't* > install to /usr/bin over the top of the Apple Python (or if you do, > when you're done reinstate the symlink to make python2.3 the default). Don't make any attempt to replace Apple's Python in the first place. You *will* break things. py2app, for example, will not correctly bundle applications if you install a non-standard Python to /usr (not local). -bob From darran.edmundson at anu.edu.au Thu Jan 27 14:34:24 2005 From: darran.edmundson at anu.edu.au (Darran Edmundson) Date: Thu Jan 27 14:34:31 2005 Subject: [Pythonmac-SIG] GDAL python bindings? Message-ID: <41F8EDE0.3050601@anu.edu.au> Can anyone explain how to get GDAL http://www.remotesensing.org/gdal/index.html to compile with python bindings. I've downloaded from http://gdal.org/dl/, tried the standard "configure; make" but get the following: g++ -Wl,-bind_at_load -o .libs/_gdalmodule.so -bundle .libs/gdal_wrap.o .libs/numpydataset.o .libs/gdalnumeric.o ../.libs/libgdal.dylib ld: Undefined symbols: _PyArg_Parse _PyArg_ParseTuple _PyDict_New _PyDict_Next _PyDict_SetItem _PyDict_Type _PyErr_Clear _PyErr_SetString [...] Someone brought this issue up on the list back in Nov 2003 but there was no response to this same problem. Cheers, Darran. P.S. Is there an easier way to search the list archives than going month by month through http://mail.python.org/pipermail/pythonmac-sig/ -- Darran Edmundson (darran.edmundson@anu.edu.au) ANU Supercomputer Facility Vizlab Australian National University, Canberra, ACT 2600 tel: +61 2 6125-0517 fax: +61 2 6125-5088 From jwt at onjapan.net Thu Jan 27 14:46:48 2005 From: jwt at onjapan.net (Jim Tittsler) Date: Thu Jan 27 14:46:52 2005 Subject: [Pythonmac-SIG] GDAL python bindings? In-Reply-To: <41F8EDE0.3050601@anu.edu.au> References: <41F8EDE0.3050601@anu.edu.au> Message-ID: On Jan 27, 2005, at 22:34, Darran Edmundson wrote: > P.S. Is there an easier way to search the list archives than > going month by month through > http://mail.python.org/pipermail/pythonmac-sig/ You can use Google and restrict your search with site:mail.python.org > Someone brought this issue up on the list back in Nov 2003 but > there was no response to this same problem. It looks like there was a response at the beginning of Dec 2003... but I don't see a response from the original poster saying adding -framework Python to PYTHON_LIBS actually solved his problem. From bob at redivi.com Thu Jan 27 14:50:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 14:50:55 2005 Subject: [Pythonmac-SIG] GDAL python bindings? In-Reply-To: <41F8EDE0.3050601@anu.edu.au> References: <41F8EDE0.3050601@anu.edu.au> Message-ID: On Jan 27, 2005, at 8:34, Darran Edmundson wrote: > > Can anyone explain how to get GDAL > http://www.remotesensing.org/gdal/index.html > to compile with python bindings. I've downloaded from > http://gdal.org/dl/, tried the standard "configure; make" but > get the following: > > g++ -Wl,-bind_at_load -o .libs/_gdalmodule.so -bundle > .libs/gdal_wrap.o .libs/numpydataset.o .libs/gdalnumeric.o > ../.libs/libgdal.dylib > ld: Undefined symbols: > _PyArg_Parse > _PyArg_ParseTuple > _PyDict_New > _PyDict_Next > _PyDict_SetItem > _PyDict_Type > _PyErr_Clear > _PyErr_SetString > [...] > > Someone brought this issue up on the list back in Nov 2003 but > there was no response to this same problem. GDAL is broken-ish because it doesn't use distutils to link modules. Try this: env MACOSX_DEPLOYMENT_TARGET=10.3 g++ -Wl,-bind_at_load -o .libs/_gdalmodule.so -bundle .libs/gdal_wrap.o .libs/numpydataset.o .libs/gdalnumeric.o ../.libs/libgdal.dylib -bundle -undefined dynamic_lookup ( this is largely from the LDSHARED setting in Python's Makefile that gets installed to %(sys.prefix)s/lib/python%(sys.version[:3])s/config/Makefile ) -bob From darran.edmundson at anu.edu.au Thu Jan 27 15:17:14 2005 From: darran.edmundson at anu.edu.au (Darran Edmundson) Date: Thu Jan 27 15:17:21 2005 Subject: [Pythonmac-SIG] GDAL python bindings? In-Reply-To: References: <41F8EDE0.3050601@anu.edu.au> Message-ID: <41F8F7EA.10606@anu.edu.au> Bob Ippolito wrote: > GDAL is broken-ish because it doesn't use distutils to link modules. > > Try this: > > env MACOSX_DEPLOYMENT_TARGET=10.3 g++ -Wl,-bind_at_load -o > .libs/_gdalmodule.so -bundle .libs/gdal_wrap.o .libs/numpydataset.o > .libs/gdalnumeric.o ../.libs/libgdal.dylib -bundle -undefined > dynamic_lookup Thanks so much Bob. I can't say I understand it but it was enough to get the job done. A few tweaks, listed here for the benefit of others running into this problem in future: 1) To recap, a 'configure; make' of gdal-1.2.5 from source almost works, compiling all the gdal core but failing a link step with lots of undefined Python symbols. 2) In the same dir, $ env MACOSX_DEPLOYMENT_TARGET=10.3 g++ -Wl,-bind_at_load -o .libs/_gdalmodule.so -bundle ./pymod/.libs/gdal_wrap.o ./pymod/.libs/numpydataset.o ./pymod/.libs/gdalnumeric.o .libs/libgdal.dylib -bundle -undefined dynamic_lookup 3) 'make' will still fail, so I hand-copied the following as root gdal-1.2.5 root# cp .libs/libgdal.1.6.0.dylib /usr/local/lib/ gdal-1.2.5 root# cp .libs/libgdal.1.dylib /usr/local/lib/ gdal-1.2.5 root# cp .libs/libgdal.a /usr/local/lib/ gdal-1.2.5 root# cp .libs/libgdal.dylib /usr/local/lib/ gdal-1.2.5 root# cp .libs/libgdal.la /usr/local/lib/ 4) "python setup.py install" 5) Start python and "import gdal" gdal-1.2.5 root# python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import gdal >>> dir(gdal) ['AllRegister', 'AutoCreateWarpedVRT', 'Band', 'CE_Debug', 'CE_Failure', 'CE_Fatal', 'CE_None', 'CE_Warning', 'CPLES_BackslashQuotable', 'CPLES_CSV', 'CPLES_SQL', 'CPLES_URL', 'CPLES_XML', 'CPLE_AppDefined', 'CPLE_AssertionFailed', 'CP ... Works for me, though I haven't yet tried to use the code. Bob might want to comment on the (lack of?) wisdom of step 3. Thanks again, Darran. -- Darran Edmundson (darran.edmundson@anu.edu.au) ANU Supercomputer Facility Vizlab Australian National University, Canberra, ACT 2600 tel: +61 2 6125-0517 fax: +61 2 6125-5088 From delza at livingcode.org Thu Jan 27 15:45:02 2005 From: delza at livingcode.org (Dethe Elza) Date: Thu Jan 27 15:45:10 2005 Subject: [Pythonmac-SIG] Categories for class methods In-Reply-To: <2f6de48b9625bdee429aa080f8b65936@mac.com> References: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> <2f6de48b9625bdee429aa080f8b65936@mac.com> Message-ID: <0694A7B5-7072-11D9-A0C0-0003939B59E8@livingcode.org> You totally rock, heading to svn now. Thanks! --Dethe On 27-Jan-05, at 3:32 AM, Ronald Oussoren wrote: > > On 27-jan-05, at 12:06, Ronald Oussoren wrote: > >> >> On 27-jan-05, at 6:34, Dethe Elza wrote: >> >>> >>> On 26-Jan-05, at 8:58 PM, Dethe Elza wrote: >>>> class NSImage(Category(NSImage)): >>>> >>>> def read_(cls, filepath): >>>> return NSImage.alloc().initWithhContentsOfFile_(filepath) >>>> read_ = classmethod(read_) >>> >>> er, that should be initWithContentsOfFile_, but still gets the same >>> error even without the typo. >> >> It's a bug in PyObjC. > > Which is fixed in SVN (as of 5 minutes ago, revision 1413). > > Ronald > > A good engineer is a person who makes a design that works with as few original ideas as possible. --Freeman Dyson -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050127/380b3109/smime-0001.bin From p.thibault at bigfoot.com Thu Jan 27 15:53:06 2005 From: p.thibault at bigfoot.com (Pierre Thibault) Date: Thu Jan 27 15:53:01 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? In-Reply-To: <75fe416cd0007da732f0ea34472fc2b6@commonground.com.au> References: <75fe416cd0007da732f0ea34472fc2b6@commonground.com.au> Message-ID: <26EADA76-7073-11D9-8966-000A95B2409A@bigfoot.com> Ok, I've reported this to the Python team so I'll hope they'll make the correction. Thank you. Le 27 janv. 2005, ? 03:21, Richard Jones a ?crit : > If you built it from scratch, it'll configure to go in /usr/local/bin > by default, so the README lies. I'd highly recommend you *don't* > install to /usr/bin over the top of the Apple Python (or if you do, > when you're done reinstate the symlink to make python2.3 the default). > Regards. --------------------- Pierre From joaoleao at gmx.net Thu Jan 27 16:11:29 2005 From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=) Date: Thu Jan 27 16:11:22 2005 Subject: [Pythonmac-SIG] py2app and argv_emulation Message-ID: Hi list Before I begin: thank you Bob for py2app. Py2applet is great for simple projects, even for newbies, and I can't see how could it be easier to use. That said, I wanted to ask you how can I get argv_emulation with py2app. Using py2applet I get it "for free" and I suspect that it has something to do with "__boot__.py" inside the application package. However I don't have a clue about if argv_emulation is an option defined in "setup.py" or somewhere else. Thanks for any help. _ jo?o From M.Laloux at mrw.wallonie.be Thu Jan 27 16:20:51 2005 From: M.Laloux at mrw.wallonie.be (LALOUX Martin) Date: Thu Jan 27 16:54:18 2005 Subject: [Pythonmac-SIG] thuban on Mac Message-ID: <6.1.2.0.0.20050127160651.02ceb5e0@pop.promibra.intra.mrw.wallonie.be> Lorenzo Moretti has compiled Thuban ( Interactive Geographic Data Viewer in Python : http://thuban.intevation.org/) for Mac os X (10.3) as a single application with : - wxPython 2.4.2.4 - Python 2.3.0 - PySQLite 0.5.1 - SQLite 2.8.15 - GDAL 1.2.5.0 - psycopg 1.1.14 - proj 4.4.9 download at http://wwwamb.bologna.enea.it/forthuban/ Martin Laloux Dr Sc. Geologue Universit? Catholique de Louvain D?tach? au M.R.W. - DGRNE Cellule g?ologie Division de la Pr?vention et des Autorisations 15, avenue Prince de Li?ge B-5100 Namur t?l. : 081 / 33 61 24 fax : 081 / 33 61 22 mailto:M.Laloux@mrw.wallonie.be http://environnement.wallonie.be/cartosig/cartegeologique ________________________________________________________________ Ce message n'engage aucunement la DGRNE et reste informel. Tout courrier officiel doit toujours actuellement ?tre confirm? par lettre et rev?tu de la signature d'un agent d?ment mandat?. ________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050127/5910c622/attachment.html From bob at redivi.com Thu Jan 27 16:59:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 16:59:25 2005 Subject: [Pythonmac-SIG] py2app and argv_emulation In-Reply-To: References: Message-ID: <9eafd919bfd3c729fee93398765a33b5@redivi.com> On Jan 27, 2005, at 10:11, Jo?o Le?o wrote: > Before I begin: thank you Bob for py2app. Py2applet is great for > simple projects, even for newbies, and I can't see how could it be > easier to use. > > That said, I wanted to ask you how can I get argv_emulation with > py2app. > Using py2applet I get it "for free" and I suspect that it has > something to do with "__boot__.py" inside the application package. > However I don't have a clue about if argv_emulation is an option > defined in "setup.py" or somewhere else. % python setup.py py2app --help For an example of an application that uses argv_emulation from a setup.py, look no further than py2applet ! -bob From pythonmac at navidado.se Thu Jan 27 17:27:26 2005 From: pythonmac at navidado.se (Thomas Wiroth) Date: Thu Jan 27 17:27:37 2005 Subject: [Pythonmac-SIG] advancededitor Message-ID: <41F9166E.3060906@navidado.se> Could someone help me get the advanced editor patch working in pythonIDE 2.3? The files at "http://www.strout.net/python/mac/" seems to need some work ... I changed the path (/Mac/Tools/IDE/) in AdvancedEditorPatch.py. I put "from Carbon" in front of the imports (Qd, Fm, Evt, Events) in PyAdvancedEditor.py. When running BuildIDE.py I get this message: " File "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/IDE/BuildIDE.py", line 9, in ? import py_resource ImportError: No module named py_resource " /Thomas From bob at redivi.com Thu Jan 27 17:39:29 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 17:39:36 2005 Subject: [Pythonmac-SIG] advancededitor In-Reply-To: <41F9166E.3060906@navidado.se> References: <41F9166E.3060906@navidado.se> Message-ID: <859266643a5ab66a8724ed8f375fc3d9@redivi.com> On Jan 27, 2005, at 11:27, Thomas Wiroth wrote: > Could someone help me get the advanced editor patch working in > pythonIDE 2.3? The files at "http://www.strout.net/python/mac/" seems > to need some work ... > > I changed the path (/Mac/Tools/IDE/) in AdvancedEditorPatch.py. > I put "from Carbon" in front of the imports (Qd, Fm, Evt, Events) in > PyAdvancedEditor.py. > > When running BuildIDE.py I get this message: > > " > File > "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ > IDE/BuildIDE.py", line 9, in ? > import py_resource > ImportError: No module named py_resource > " The files there are over 5 years old and were for a practically ancient version of Python (1.5.2 vs. 2.3.0).. it's not surprising it doesn't work :) -bob From doug at sonosphere.com Thu Jan 27 17:51:37 2005 From: doug at sonosphere.com (Doug Wyatt) Date: Thu Jan 27 17:51:43 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? In-Reply-To: <5060c2298929cf95e7d83c3819d7d888@redivi.com> References: <75fe416cd0007da732f0ea34472fc2b6@commonground.com.au> <5060c2298929cf95e7d83c3819d7d888@redivi.com> Message-ID: <1943E0B6-2570-4DFB-B399-B6FF474F452B@sonosphere.com> On Jan 27, 2005, at 5:31, Bob Ippolito wrote: > Don't make any attempt to replace Apple's Python in the first place. > You *will* break things. py2app, for example, will not correctly > bundle applications if you install a non-standard Python to /usr (not > local). Would it make sense to have the main Python distribution build on MacOS X the same way Apple builds it, so that, for example, if one wants to update it to 2.3.4, it's easy? Sorry if this has been asked before ... Doug From bob at redivi.com Thu Jan 27 18:04:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 18:04:43 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? In-Reply-To: <1943E0B6-2570-4DFB-B399-B6FF474F452B@sonosphere.com> References: <75fe416cd0007da732f0ea34472fc2b6@commonground.com.au> <5060c2298929cf95e7d83c3819d7d888@redivi.com> <1943E0B6-2570-4DFB-B399-B6FF474F452B@sonosphere.com> Message-ID: On Jan 27, 2005, at 11:51, Doug Wyatt wrote: > On Jan 27, 2005, at 5:31, Bob Ippolito wrote: >> Don't make any attempt to replace Apple's Python in the first place. >> You *will* break things. py2app, for example, will not correctly >> bundle applications if you install a non-standard Python to /usr (not >> local). > > Would it make sense to have the main Python distribution build on > MacOS X the same way Apple builds it, so that, for example, if one > wants to update it to 2.3.4, it's easy? > > Sorry if this has been asked before ... For some unix-based software, it is useful to build it in the normal unix way, so framework building is an option but not the default. To build it as a framework: ./configure --enable-framework make sudo make frameworkinstall This will still create a /usr/local/bin/python, but Python itself will be installed to /Library/Frameworks/Python.framework -bob From p.thibault at bigfoot.com Thu Jan 27 19:50:15 2005 From: p.thibault at bigfoot.com (Pierre Thibault) Date: Thu Jan 27 19:50:35 2005 Subject: [Pythonmac-SIG] Python 2.4 in /usr/local/bin? In-Reply-To: References: Message-ID: Sorry but I was wrong about the README file. It said that is going to install in /usr/local/ and it did. Maybe I was reading too fast. But they were others errors in it and I made a report so my comments are going to be helpful anyway. Sorry. Le 27 janv. 2005, ? 01:50, Pierre Thibault a ?crit : > I just made an install of Python 2.4 on my machine. The 'README' is > saying that the install is going to take place on /usr/bin but in > reality things were installed in /usr/local/bin'. > Regards. --------------------- Pierre From delza at livingcode.org Thu Jan 27 21:24:13 2005 From: delza at livingcode.org (Dethe Elza) Date: Thu Jan 27 21:24:19 2005 Subject: [Pythonmac-SIG] Categories for class methods In-Reply-To: <0694A7B5-7072-11D9-A0C0-0003939B59E8@livingcode.org> References: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> <2f6de48b9625bdee429aa080f8b65936@mac.com> <0694A7B5-7072-11D9-A0C0-0003939B59E8@livingcode.org> Message-ID: <68AFB8CA-70A1-11D9-A0C0-0003939B59E8@livingcode.org> FYI, once I updated PyObjC from svn, my example code worked, thanks again Ronald. from objc import Category from AppKit import * from os.path import splitext _fileRepresentationMapping = { '.png': NSPNGFileType, '.gif': NSGIFFileType, '.jpg': NSJPEGFileType, '.jpeg': NSJPEGFileType, '.bmp': NSBMPFileType, '.tif': NSTIFFFileType, '.tiff': NSTIFFFileType, } def _getFileRepresentationType(filepath): base, ext = splitext(filepath) return _fileRepresentationMapping[ext.lower()] class NSImage(Category(NSImage)): def rect(self): return (0,0),self.size() @classmethod # for Python2.3 replace with read_ = classmethod(read_) def read_(cls, filepath): return NSImage.alloc().initWithContentsOfFile_(filepath) def write_(self, filepath): self.lockFocus() image_rep = NSBitmapImageRep.alloc().initWithFocusedViewRect_(self.rect()) self.unlockFocus() representation = _getFileRepresentationType(filepath) data = image_rep.representationUsingType_properties_(representation, None) data.writeToFile_atomically_(filepath, False) def fill_(self, color): self.lockFocus() color.set() NSBezierPath.fillRect_(self.rect()) self.unlockFocus() And an example for building images from the command-line from AppKit import NSApplication, NSBezierPath, NSColor, NSImage from Foundation import NSInsetRect, NSMakeRect import image app = NSApplication.sharedApplication() def newImage(width, height): image = NSImage.alloc().initWithSize_((width, height)) image.fill_(NSColor.whiteColor()) return image def drawRedCircleOnImage(image): image.lockFocus() NSColor.redColor().set() rect = NSInsetRect(image.rect() 8, 8) circle = NSBezierPath.bezierPathWithOvalInRect_(rect) circle.setLineWidth_(4) circle.stroke() image.unlockFocus() return image def drawBlackRectOnImage(image): image.lockFocus() rect = NSInsetRect(image.rect(), 16, 16) NSBezierPath.setDefaultLineWidth_(4) NSColor.blackColor().set() NSBezierPath.strokeRect_(rect) image.unlockFocus() return image def test_read_and_write(): image1 = newImage(64,64) drawBlackRectOnImage(image1) image1.write_('square.gif') image2 = NSImage.read_('square.gif') drawRedCircleOnImage(image2) image2.write_('circle.png') if __name__ == '__main__': test_read_and_write() --Dethe "...coding isn't the poor handmaiden of design or analysis. Coding is where your fuzzy, comfortable ideas awaken in the harsh dawn of reality. It is where you learn what your computer can do. If you stop coding, you stop learning." Kent Beck, Smalltalk Best Practice Patterns -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050127/838155b9/smime-0001.bin From bob at redivi.com Thu Jan 27 21:57:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Jan 27 21:57:12 2005 Subject: [Pythonmac-SIG] Categories for class methods In-Reply-To: <68AFB8CA-70A1-11D9-A0C0-0003939B59E8@livingcode.org> References: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> <2f6de48b9625bdee429aa080f8b65936@mac.com> <0694A7B5-7072-11D9-A0C0-0003939B59E8@livingcode.org> <68AFB8CA-70A1-11D9-A0C0-0003939B59E8@livingcode.org> Message-ID: On Jan 27, 2005, at 15:24, Dethe Elza wrote: > FYI, once I updated PyObjC from svn, my example code worked, thanks > again Ronald. ... > class NSImage(Category(NSImage)): > > def rect(self): > return (0,0),self.size() > > @classmethod # for Python2.3 replace with read_ = > classmethod(read_) > def read_(cls, filepath): > return NSImage.alloc().initWithContentsOfFile_(filepath) Just a nit here, you should probably call this imageWithFilePath_ to follow convention. "read:" is a really confusing name for an initializer. -bob From hengist.podd at virgin.net Thu Jan 27 22:07:02 2005 From: hengist.podd at virgin.net (has) Date: Thu Jan 27 22:17:32 2005 Subject: [Pythonmac-SIG] [ann] appscript 0.11.0 Message-ID: Hi all, Updates to appscript, aem and osaterminology posted: http://freespace.virgin.net/hamish.sanderson/appscript.html Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From pythonmac at navidado.se Thu Jan 27 22:26:53 2005 From: pythonmac at navidado.se (Thomas Wiroth) Date: Thu Jan 27 22:27:09 2005 Subject: [Pythonmac-SIG] advancededitor In-Reply-To: <859266643a5ab66a8724ed8f375fc3d9@redivi.com> References: <41F9166E.3060906@navidado.se> <859266643a5ab66a8724ed8f375fc3d9@redivi.com> Message-ID: <41F95C9D.7000902@navidado.se> Bob Ippolito wrote: >> Could someone help me get the advanced editor patch working in >> pythonIDE 2.3? The files at "http://www.strout.net/python/mac/" seems >> to need some work ... >> > > The files there are over 5 years old and were for a practically ancient > version of Python (1.5.2 vs. 2.3.0).. it's not surprising it doesn't > work :) > So what does people use to develop python then, Macpython is nice but I would really like the features in the advanced editor patch. /Thomas From delza at livingcode.org Fri Jan 28 01:19:15 2005 From: delza at livingcode.org (Dethe Elza) Date: Fri Jan 28 01:19:26 2005 Subject: [Pythonmac-SIG] Categories for class methods In-Reply-To: References: <1EB95A42-7020-11D9-A0C0-0003939B59E8@livingcode.org> <1B02835B-7025-11D9-A0C0-0003939B59E8@livingcode.org> <2f6de48b9625bdee429aa080f8b65936@mac.com> <0694A7B5-7072-11D9-A0C0-0003939B59E8@livingcode.org> <68AFB8CA-70A1-11D9-A0C0-0003939B59E8@livingcode.org> Message-ID: <3E8CE700-70C2-11D9-A0C0-0003939B59E8@livingcode.org> That's a good tip, I haven't gotten the hang of Cocoa's verbosity yet. The choice of read: was to balance write:. The whole thing started because I found it odd that writing an image to a file was such a convoluted process. In a lot of ways, Cocoa makes things really easy, but when it isn't easy, sometimes it becomes really, really hard (at least hard to figure out, if not to implement). Some of that is just getting to know the libraries, of course, and a lack of howtos for the things I'm trying to do. --Dethe On 27-Jan-05, at 12:57 PM, Bob Ippolito wrote: > > On Jan 27, 2005, at 15:24, Dethe Elza wrote: > >> FYI, once I updated PyObjC from svn, my example code worked, thanks >> again Ronald. > ... >> class NSImage(Category(NSImage)): >> >> def rect(self): >> return (0,0),self.size() >> >> @classmethod # for Python2.3 replace with read_ = >> classmethod(read_) >> def read_(cls, filepath): >> return NSImage.alloc().initWithContentsOfFile_(filepath) > > Just a nit here, you should probably call this imageWithFilePath_ to > follow convention. "read:" is a really confusing name for an > initializer. > > -bob > > "...coding isn't the poor handmaiden of design or analysis. Coding is where your fuzzy, comfortable ideas awaken in the harsh dawn of reality. It is where you learn what your computer can do. If you stop coding, you stop learning." Kent Beck, Smalltalk Best Practice Patterns -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050127/6d7b76d5/smime.bin From richard at commonground.com.au Fri Jan 28 01:31:37 2005 From: richard at commonground.com.au (Richard Jones) Date: Fri Jan 28 01:31:43 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? In-Reply-To: References: Message-ID: <3abe15deb1a9e17d1579d96dc5631389@commonground.com.au> On 28/01/2005, at 12:14 AM, Bob Ippolito wrote: > On Jan 26, 2005, at 23:49, Richard Jones wrote: >> 2. install the PyObjC stuff alongside a manually compiled Python? > > That works fine. Two hitches here: 1. I can't find source for PyObjC (though I think it might come with Python?) 2. I can't install a --enable-framework in a place other than /usr/local - the --prefix and INSTALLDIR arguments to --enable-framework appear to be ignored. I need the resulting Python to be relocatable (ie. bundled inside a drag-installed app like other OS X apps) ... and I've now got a niggling feeling that this isn't possible... Richard From bob at redivi.com Fri Jan 28 04:45:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 28 04:46:03 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? In-Reply-To: <3abe15deb1a9e17d1579d96dc5631389@commonground.com.au> References: <3abe15deb1a9e17d1579d96dc5631389@commonground.com.au> Message-ID: On Jan 27, 2005, at 7:31 PM, Richard Jones wrote: > On 28/01/2005, at 12:14 AM, Bob Ippolito wrote: >> On Jan 26, 2005, at 23:49, Richard Jones wrote: >>> 2. install the PyObjC stuff alongside a manually compiled Python? >> >> That works fine. > > Two hitches here: > > 1. I can't find source for PyObjC (though I think it might come with > Python?) Ever tried google? Even clicking "I'm feeling lucky" will take you to the right place.. which happens to be . > 2. I can't install a --enable-framework in a place other than > /usr/local - > the --prefix and INSTALLDIR arguments to --enable-framework appear > to be > ignored. > > I need the resulting Python to be relocatable (ie. bundled inside a > drag-installed app like other OS X apps) ... and I've now got a > niggling feeling that this isn't possible... The /usr/local crap just symlinks inside the framework, so your feeling is not correct. You will want to use py2app when bundling your application though, as the Mach-O headers need some rewriting in order to avoid conflict. If you start it up with a non-System Python, it will automatically decide that you want to include a stripped down version of the Python runtime inside your application. .. note that py2app can even do this for a non-framework regular 'old unix-style build. However, those builds don't have the machinery to run GUI applications outside of the context of an application bundle. If you're using PyObjC, you basically need to be using a per-application bundle anyway, so it's really not a problem. py2app's alias bundle mode is great for this, I suggest reading the PyObjC tutorial. -bob From richard at commonground.com.au Fri Jan 28 05:26:54 2005 From: richard at commonground.com.au (Richard Jones) Date: Fri Jan 28 05:26:59 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? In-Reply-To: References: <3abe15deb1a9e17d1579d96dc5631389@commonground.com.au> Message-ID: <2b0617cafc4b79ed4e033f15c5eb1231@commonground.com.au> On 28/01/2005, at 2:45 PM, Bob Ippolito wrote: > On Jan 27, 2005, at 7:31 PM, Richard Jones wrote: >> 1. I can't find source for PyObjC (though I think it might come with >> Python?) > > Ever tried google? Even clicking "I'm feeling lucky" will take you to > the right place.. which happens to be . OK, a fair cop. I just assumed it would be hard to find given it's not linked from pythonmac.org. >> 2. I can't install a --enable-framework in a place other than >> /usr/local - >> the --prefix and INSTALLDIR arguments to --enable-framework appear >> to be >> ignored. >> >> I need the resulting Python to be relocatable (ie. bundled inside a >> drag-installed app like other OS X apps) ... and I've now got a >> niggling feeling that this isn't possible... > > The /usr/local crap just symlinks inside the framework, so your > feeling is not correct. Hrm. Still doesn't quite address point #2 though. I guess the answer, reading between the next lines, is "it doesn't - just use /usr/local" :) > You will want to use py2app when bundling your application though, as > the Mach-O headers need some rewriting in order to avoid conflict. If > you start it up with a non-System Python, it will automatically decide > that you want to include a stripped down version of the Python runtime > inside your application. > > .. note that py2app can even do this for a non-framework regular 'old > unix-style build. However, those builds don't have the machinery to > run GUI applications outside of the context of an application bundle. > If you're using PyObjC, you basically need to be using a > per-application bundle anyway, so it's really not a problem. py2app's > alias bundle mode is great for this, I suggest reading the PyObjC > tutorial. Yeah, I guess I have a whole lotta reading to do. I've opened a can of worms, and they're looking scary :( Having said that, last time* I did this, PyObjC didn't exist and I'm *pretty* sure it's making my life easier this time, if I can only crack this minor issue of getting Zope up and running in a PyObjC-enabled Python, and then have it bundled, and ... :) Richard *: http://www.zope.org/Members/richard/zope_controller/mac From bob at redivi.com Fri Jan 28 05:42:45 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Jan 28 05:42:52 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? In-Reply-To: <2b0617cafc4b79ed4e033f15c5eb1231@commonground.com.au> References: <3abe15deb1a9e17d1579d96dc5631389@commonground.com.au> <2b0617cafc4b79ed4e033f15c5eb1231@commonground.com.au> Message-ID: <51C11D4E-5AAF-4F96-AB29-C0335E72A08F@redivi.com> On Jan 27, 2005, at 11:26 PM, Richard Jones wrote: > On 28/01/2005, at 2:45 PM, Bob Ippolito wrote: >> On Jan 27, 2005, at 7:31 PM, Richard Jones wrote: >>> 1. I can't find source for PyObjC (though I think it might come with >>> Python?) >> >> Ever tried google? Even clicking "I'm feeling lucky" will take you >> to the right place.. which happens to be . > > OK, a fair cop. I just assumed it would be hard to find given it's not > linked from pythonmac.org. It is actually, at the bottom of the front page of http://pythonmac.org/ >>> 2. I can't install a --enable-framework in a place other than >>> /usr/local - >>> the --prefix and INSTALLDIR arguments to --enable-framework >>> appear to be >>> ignored. >>> >>> I need the resulting Python to be relocatable (ie. bundled inside a >>> drag-installed app like other OS X apps) ... and I've now got a >>> niggling feeling that this isn't possible... >> >> The /usr/local crap just symlinks inside the framework, so your >> feeling is not correct. > > Hrm. Still doesn't quite address point #2 though. I guess the answer, > reading between the next lines, is "it doesn't - just use /usr/local" > :) I don't think you understood me. When you build as --enable-framework, the files installed to /usr/local are simply for convenience of use. The fact that they are in /usr/local is of no consequence and they are not at all used by the framework itself. If you ask what the os.path.realpath(sys.executable) is, it won't say /usr/local. What you don't realize is that even though it is a framework, it is not really relocatable (in a deterministic fashion at runtime) without jumping through a significant amount of hoops. py2app jumps through these hoops for you, so this isn't a problem. Also, py2app doesn't need nor care about framework vs. non-framework builds.... so, use whatever works best for your application, and py2app will do the rest to make it redistributable. >> You will want to use py2app when bundling your application though, as >> the Mach-O headers need some rewriting in order to avoid conflict. >> If you start it up with a non-System Python, it will automatically >> decide that you want to include a stripped down version of the Python >> runtime inside your application. >> >> .. note that py2app can even do this for a non-framework regular 'old >> unix-style build. However, those builds don't have the machinery to >> run GUI applications outside of the context of an application bundle. >> If you're using PyObjC, you basically need to be using a >> per-application bundle anyway, so it's really not a problem. >> py2app's alias bundle mode is great for this, I suggest reading the >> PyObjC tutorial. > > Yeah, I guess I have a whole lotta reading to do. I've opened a can of > worms, and they're looking scary :( > > Having said that, last time* I did this, PyObjC didn't exist and I'm > *pretty* sure it's making my life easier this time, if I can only > crack this minor issue of getting Zope up and running in a > PyObjC-enabled Python, and then have it bundled, and ... :) This "can of worms" is simply that the issues with bundling applications for the Mac are all well specified now and have been discussed quite a bit because they are difficult to understand, somewhat non-intuitive, and come up on a regular basis. Well, PyObjC is a lot older than OS X... so, that's not really correct. Whether a usable port of PyObjC to Mac OS X existed at the time you wrote that app, I'm not sure. I certainly wasn't using it at that time. py2app does all the things that need to be done in order to make it work. It is far easier than it used to be. Using py2app also happens to be easier than using py2exe, because it has a better understanding of modules and dependencies, so at least it's not any worse than doing the same thing for other platforms. -bob From richard at commonground.com.au Fri Jan 28 05:49:21 2005 From: richard at commonground.com.au (Richard Jones) Date: Fri Jan 28 05:49:26 2005 Subject: [Pythonmac-SIG] Just starting out - Python 2.3.3? In-Reply-To: <51C11D4E-5AAF-4F96-AB29-C0335E72A08F@redivi.com> References: <3abe15deb1a9e17d1579d96dc5631389@commonground.com.au> <2b0617cafc4b79ed4e033f15c5eb1231@commonground.com.au> <51C11D4E-5AAF-4F96-AB29-C0335E72A08F@redivi.com> Message-ID: <8af94335087a4cd4bc37abbdf0cee7d2@commonground.com.au> On 28/01/2005, at 3:42 PM, Bob Ippolito wrote: > On Jan 27, 2005, at 11:26 PM, Richard Jones wrote: >> On 28/01/2005, at 2:45 PM, Bob Ippolito wrote: >>> On Jan 27, 2005, at 7:31 PM, Richard Jones wrote: >>>> 1. I can't find source for PyObjC (though I think it might come >>>> with Python?) >>> >>> Ever tried google? Even clicking "I'm feeling lucky" will take you >>> to the right place.. which happens to be . >> >> OK, a fair cop. I just assumed it would be hard to find given it's >> not linked from pythonmac.org. > > It is actually, at the bottom of the front page of > http://pythonmac.org/ ARGH! I feel stupid :) >>>> 2. I can't install a --enable-framework in a place other than >>>> /usr/local - >>>> the --prefix and INSTALLDIR arguments to --enable-framework >>>> appear to be >>>> ignored. >>>> >>>> I need the resulting Python to be relocatable (ie. bundled inside a >>>> drag-installed app like other OS X apps) ... and I've now got a >>>> niggling feeling that this isn't possible... >>> >>> The /usr/local crap just symlinks inside the framework, so your >>> feeling is not correct. >> >> Hrm. Still doesn't quite address point #2 though. I guess the answer, >> reading between the next lines, is "it doesn't - just use /usr/local" >> :) > > I don't think you understood me. When you build as > --enable-framework, the files installed to /usr/local are simply for > convenience of use. The fact that they are in /usr/local is of no > consequence and they are not at all used by the framework itself. If > you ask what the os.path.realpath(sys.executable) is, it won't say > /usr/local. Ah, OK. Thanks for the hand-holding, I really appreciate it! Richard From Jack.Jansen at cwi.nl Fri Jan 28 15:08:29 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Jan 28 15:09:17 2005 Subject: [Pythonmac-SIG] python.h and veclib.h incompatible? In-Reply-To: <3C04325C-6E79-11D9-8AEE-000D934470FC@csl.sony.co.jp> References: <3C04325C-6E79-11D9-8AEE-000D934470FC@csl.sony.co.jp> Message-ID: <162C51E6-7136-11D9-B298-000A958D1666@cwi.nl> Google found one possibly interesting reference, and the rest of that thread. The trick seems to be to include before "python.h". On 25 Jan 2005, at 03:31, Brian Clarkson wrote: > Hello. > > I was swig'ing an extension that made use of veclib in its internals > and discovered that if python.h is included before veclib.h that > compilation will not succeed. It seems they are interacting so that > parts of fp.h are being left out when they shouldn't be. > > I have distilled the problem down to the following simple test case: > > ****begin test.cpp**** > > #include > #include > #include > > using namespace std; > > int main(){ > cerr << scalb(3,4) << endl; > return 0; > } > > ****end test.cpp**** > > Which when compiled as follows: > > gcc -I/sw/include/python2.3 -c test.cpp > > gives the following errors: > > In file included from /sw/include/python2.3/python.h:70, > from test.cpp:1: > /sw/include/python2.3/objimpl.h:255: warning: use of `long double' > type; its > size may change in a future release > /sw/include/python2.3/objimpl.h:255: warning: (Long double usage is > reported > only once for each file. > /sw/include/python2.3/objimpl.h:255: warning: To disable this warning, > use > -Wno-long-double.) > In file included from > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/CarbonCore.h:165, > from > /System/Library/Frameworks/CoreServices.framework/Headers/ > CoreServices.h:21, > from > /System/Library/Frameworks/veclib.framework/Headers/veclib.h:20, > from test.cpp:2: > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h: In > function `long double scalbl(long double, long int)': > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h:1896: error: ` > scalb' undeclared (first use this function) > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h:1896: error: (Each > undeclared identifier is reported only once for each function it > appears > in.) > > Other than refactoring in order to hide veclib.h from python.h, does > anyone have any fixes for this? > > Thanks in advance! > > Brian > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From darran.edmundson at anu.edu.au Fri Jan 28 23:21:48 2005 From: darran.edmundson at anu.edu.au (Darran Edmundson) Date: Fri Jan 28 23:21:55 2005 Subject: [Pythonmac-SIG] arghh, wxBitmapButton problem ... Message-ID: <41FABAFC.6090301@anu.edu.au> I'm having problems with wxBitmapButton as discussed in this post to the wxPython-users list yesterday. Robin indicates that this is a known problem on the Mac. I wonder if someone here can confirm this and possibly point out a workaround? What confuses me is that the wxBitmapButton example in the wxPython Demo works fine (PNG image encoded with img2py). Any help is much appreciated. Cheers, Darran. -------- Original Message -------- Subject: Re: [wxPython-users] arghh, colour wxBitmapButton problem ... Date: Fri, 28 Jan 2005 11:31:03 -0800 From: Robin Dunn Reply-To: wxPython-users@lists.wxwidgets.org To: wxPython-users@lists.wxwidgets.org References: <41FA4740.2030000@anu.edu.au> Darran Edmundson wrote: > > I've been trying desperately for the last few hours to get > a colour wxBitmapButton working. It seems so simple: > but my buttons thus created don't appear properly. I've put a > screen capture of a test app on: > > http://anusf.anu.edu.au/~dee900/Projects/wxPython/ > > along with two of the source images. I've tried converting > the source images in Photoshop to 8-bit PNG, index-colour, > etc., all to no avail. > > Looking at the wxPython wxBitmapButton demo, the > authors use hardcoded XPM images rather than loading from Actually they are PNG images that have been encoded into a Python source file using the img2py tool included with wxPython. > a file via one of the wx image loaders. Surely one can load from > a file though, no? Yes. The problem you are running into is a known problem with BitmapButtons on wxMac. I don't know the details but it is something to do with which native format that is being used to give the image to the native control. If you put the same image in wx.StaticBitmap then you'll see that it is being loaded okay. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! --------------------------------------------------------------------- To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org -- Darran Edmundson (darran.edmundson@anu.edu.au) ANU Supercomputer Facility Vizlab Australian National University, Canberra, ACT 2600 tel: +61 2 6125-0517 fax: +61 2 6125-5088 From Jack.Jansen at cwi.nl Sat Jan 29 00:24:37 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Jan 29 00:23:34 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? In-Reply-To: References: <8D55BDB8-6A13-4DFA-B582-B1A3036D1DC7@mac.com> Message-ID: On 26-jan-05, at 21:50, has wrote: > Bob wrote: > >> It doesn't sound like that's what he wants. > > Yeah I know, I was thinking laterally; throwing random ideas into the > ring 'n that. > > iTunes... Mac Mini... media centers... cross-platform... LANs... > etc... seems a very wide field; perhaps there's opportunities there > for MacPython to do interesting things. Definitely, but someone has to do them:-) When I came across the Mac mini media center stuff a couple of days ago I realised that this would be an area where Python/MacPython/PyObjC/appscript could really shine. They have very few ObjC developers right now, and a rather large agenda. Think of it: the end user will want to use the remote control to browse a selection of songs (or radio stations) on-screen and have the result play through itunes. So we're talking a combination of unix programming/bit manipulation (reading /dev/ttyXX and getting the IR commands), a reasonable user interface in 640x480 (or 575xtheotherone) and talking to iTunes. Python is the only language I can think of that I would consider doing something like this in. But, of course, I don't have the time:-( But it would really make me happy if people looking for pet projects could have a look at this... -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From hengist.podd at virgin.net Sat Jan 29 00:52:01 2005 From: hengist.podd at virgin.net (has) Date: Sat Jan 29 00:52:16 2005 Subject: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity? In-Reply-To: References: <8D55BDB8-6A13-4DFA-B582-B1A3036D1DC7@mac.com> Message-ID: Jack wrote: >>iTunes... Mac Mini... media centers... cross-platform... LANs... >>etc... seems a very wide field; perhaps there's opportunities there >>for MacPython to do interesting things. > >Definitely, [...] But, of course, I don't have the time:-( But it >would really make me happy if people looking for pet projects could >have a look at this... Same here... too many other pots already on the stove, plus I don't have all the skills needed anyway.:/ (Tho' I'd be happy to provide any help or advice needed on the iTunes scripting part, of course.:) S'why I threw the idea into the wild here. And even if nobody here picks it up themselves, I'm sure some folks subscribe to other OS X dev lists as well, and might like to promote Python/PyObjC/appscript as a solution if/when the topic arises there. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From kranki at mac.com Sat Jan 29 04:05:17 2005 From: kranki at mac.com (Robert White) Date: Sat Jan 29 04:05:26 2005 Subject: [Pythonmac-SIG] History of Python in MacOSX Message-ID: <5e9985a2d912239938e7fa229cc1bf3d@mac.com> I started with Jaguar, MacOSX 10.2, where Python was built as a framework. I am just curious. Was Python included with 10.1 or 10.0? If so, were they framework builds as well? Thank you for your time. From just at letterror.com Sat Jan 29 10:28:04 2005 From: just at letterror.com (Just van Rossum) Date: Sat Jan 29 10:28:07 2005 Subject: [Pythonmac-SIG] History of Python in MacOSX In-Reply-To: <5e9985a2d912239938e7fa229cc1bf3d@mac.com> Message-ID: Robert White wrote: > I started with Jaguar, MacOSX 10.2, where Python was built as a > framework. The Python that shipped with 10.2 was not a framework build, but an "ordinary" static unix build, or whatever the correct term for that is. > I am just curious. Was Python included with 10.1 or 10.0? > If so, were they framework builds as well? It was not. Just From bob at redivi.com Sat Jan 29 15:21:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Jan 29 15:21:19 2005 Subject: [Pythonmac-SIG] History of Python in MacOSX In-Reply-To: References: Message-ID: <5bdba15b4cc00a1858ce17d5e183559f@redivi.com> On Jan 29, 2005, at 4:28, Just van Rossum wrote: > Robert White wrote: > >> I started with Jaguar, MacOSX 10.2, where Python was built as a >> framework. > > The Python that shipped with 10.2 was not a framework build, but an > "ordinary" static unix build, or whatever the correct term for that is. Mac OS X 10.2 shipped with Python 2.2.0, which was rife with bugs (both cross-platform and Mac specific bugs). A shared library was not available, so this Python could not be embedded in other software. Thus, application bundles that bootstrapped with this Python needed to use a shell script or equivalent that did an execve(...) call to /usr/bin/python. Additionally, the config/Makefile for this Python had some compiler flags related to x86 cross-compilation that Apple neglected to remove from their production build, thus it was necessary to sudo vi this file or mangle distutils a bit at runtime from setup.py in order to build extensions at all. Not terribly long after Mac OS X 10.3 and Python 2.3.0 came out, people stopped supporting this Python 2.2.0, because it was horrible. -bob From moatgoat at hotmail.com Sat Jan 29 18:13:15 2005 From: moatgoat at hotmail.com (Dave Kanter) Date: Sat Jan 29 18:14:03 2005 Subject: [Pythonmac-SIG] Trouble getting TK to work Message-ID: Forgive me if this question has been asked 100 times. I tried reading through past archives, honest I did. I'm having some trouble with Python and TK, but I'm not sure how to proceed. This is what I did: I'm using the version of Python that came with OSX -- version 2.3. I also downloaded TclTkAquaBl - 8.4.9.0 and ran the installer. Then I fired up Python, and typed: from Tkinter import * and then root = Tk() Which were commands I got from the Python book I'm working out of. This is what happened: >>>from Tkinter import * Traceback (most recent call last): File "", line 1, in ? File "/sw/lib/python2.3/lib-tk/Tkinter.py", line 3, in ? Tkinter provides classes which allow the display, positioning and NameError: name 'Tk' is not defined >>>root = Tk() Traceback (most recent call last): File "", line 1, in ? NameError: name 'Tk' is not defined >>> It seems to me it's an improper path configuration, but for the life of me I can't figure out how to get it straight. Any help would be much appreciated. Dave. From m93k2y8 at acncanada.net Sat Jan 29 19:29:26 2005 From: m93k2y8 at acncanada.net (Kirk Durston) Date: Sat Jan 29 19:29:40 2005 Subject: [Pythonmac-SIG] Mutating Row in a matrix Message-ID: It will be obvious that I am a newbie here when you see my question, but here goes. I am writing my first program, and have encountered a problem which I?ve been able to reproduce in the short program below. Basically, I select a row (B) from a matrix and I want to keep B constant. Then I create a new matrix by copying the old, and mutate the new matrix. I then want to substitute the unmutated row B into the mutated new matrix. Problem: B changes, as you can see when you run the short program below. So does the original matrix, although I don?t care about that. Question: Why does the list B change when I don?t work on it? I want to understand this. Question #2: A solution would be to convert the list B into a tuple and then reconvert the tuple back into a list after the new matrix has been mutated and insert it, but I still want to understand why a list would change when I?m haven?t done anything to it. Here?s a small program that reproduces the problem. When B changes depends upon the value you set for ?e? import random A = [[1,1,1,1,1], [2,2,2,2,2],[3,3,3,3,3],[4,4,4,4,4]] e = 2 B = A[e] Columns = 4 Rows = 4 NewMatrix = A MutationRate = .9999 #Mutation of NewMatrix s = 0 while s References: Message-ID: <63885A5B-79FC-4799-BC26-443B4109CBD1@redivi.com> On Jan 29, 2005, at 1:29 PM, Kirk Durston wrote: > It will be obvious that I am a newbie here when you see my question, > but here goes. I am writing my first program, and have encountered a > problem which I?ve been able to reproduce in the short program below. > Basically, I select a row (B) from a matrix and I want to keep B > constant. Then I create a new matrix by copying the old, and mutate > the new matrix. I then want to substitute the unmutated row B into > the mutated new matrix. > > Problem: B changes, as you can see when you run the short program > below. So does the original matrix, although I don?t care about that. > > Question: Why does the list B change when I don?t work on it? I want > to understand this. > > Question #2: A solution would be to convert the list B into a tuple > and then reconvert the tuple back into a list after the new matrix has > been mutated and insert it, but I still want to understand why a list > would change when I?m haven?t done anything to it. What you're missing here is that everything in Python is an object, and variables are just *references* to objects. When you say ``a = b[0]``, ``a`` is a reference to ``b[0]``. If ``b[0]`` is some mutable object, like a list or a dict, you're simply referencing it. In this case, changing ``a`` would "also change" ``b[0]`` because they ``a`` and ``b[0]`` are references to the *same object*. You should read this: http://starship.python.net/crew/mwh/hacks/objectthink.html There is no need to convert a list to a tuple and back again. Two simple ways to make a shallow copy of a list are ``list(anotherList)`` or ``anotherList[:]``. You should also read the documentation for the ``copy`` module, whether or not you end up using it in your implementation. -bob From joachimm at mac.se Sun Jan 30 01:40:55 2005 From: joachimm at mac.se (=?ISO-8859-1?Q?Joachim_M=E5rtensson?=) Date: Sun Jan 30 01:40:58 2005 Subject: [Pythonmac-SIG] How do I send appleevents to an external program Message-ID: <41FC2D17.4070007@mac.se> Hello everyone. I am trying to figure out how to send appleevents to an external program. What I want to accomplish is to open a text document in a editor that supports the external editor protocol as described here http://www.codingmonkeys.de/techpubs/externaleditor/pbxexternaleditor.html. Here is my code so far, What am I doing wrong? _filePath is the path to the file and _lnnum is the line number where I want to place the caret. I am using PyObjc but no api in cocoa seems to exist so I use various other modules. def openInExternalEditor(self, _filePath, _lnnum): import aetools, struct editor = aetools.TalkTo('TxMt', 0) # TxMt = textmate a texteditor keyDirectObject = '----' keyAEPosition = 'sopk' _code = 'aeve' # kCoreEventClass _subcode = 'odoc' # kAEOpenDocuments SelectionRange=struct.pack('hhllll', 0, int(_lnnum), 0,0,0,0) _arguments = {} _arguments[keyDirectObject] = _filePath _arguments[keyAEPosition] = SelectionRange _attributes = {} editor.send(_code, _subcode, _arguments, _attributes) Thanks in advance Joachim M?rtensson From bob at redivi.com Sun Jan 30 02:08:33 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Jan 30 02:08:39 2005 Subject: [Pythonmac-SIG] How do I send appleevents to an external program In-Reply-To: <41FC2D17.4070007@mac.se> References: <41FC2D17.4070007@mac.se> Message-ID: <05e4253bce628adf2b3fa8ea2090f6dc@redivi.com> On Jan 29, 2005, at 19:40, Joachim M?rtensson wrote: > Hello everyone. > I am trying to figure out how to send appleevents to an external > program. What I want to accomplish is to open a text document in a > editor that supports the external editor protocol as described here > http://www.codingmonkeys.de/techpubs/externaleditor/ > pbxexternaleditor.html. > Here is my code so far, What am I doing wrong? _filePath is the path > to the file and _lnnum is the line number where I want to place the > caret. I am using PyObjc but no api in cocoa seems to exist so I use > various other modules. PyObjC can use AppleScript with the NSAppleScript class . However, the best way to send Apple Events from Python is probably appscript . The standard library support for Apple Events is very... raw, so I wouldn't recommend that approach to anyone :) -bob From joachimm at mac.se Sun Jan 30 03:51:05 2005 From: joachimm at mac.se (=?ISO-8859-1?Q?Joachim_M=E5rtensson?=) Date: Sun Jan 30 03:51:07 2005 Subject: [Pythonmac-SIG] How do I send appleevents to an external program In-Reply-To: <05e4253bce628adf2b3fa8ea2090f6dc@redivi.com> References: <41FC2D17.4070007@mac.se> <05e4253bce628adf2b3fa8ea2090f6dc@redivi.com> Message-ID: <41FC4B99.9000806@mac.se> Bob Ippolito wrote: > > On Jan 29, 2005, at 19:40, Joachim M?rtensson wrote: > >> Hello everyone. >> I am trying to figure out how to send appleevents to an external >> program. What I want to accomplish is to open a text document in a >> editor that supports the external editor protocol as described here >> http://www.codingmonkeys.de/techpubs/externaleditor/ >> pbxexternaleditor.html. >> Here is my code so far, What am I doing wrong? _filePath is the path >> to the file and _lnnum is the line number where I want to place the >> caret. I am using PyObjc but no api in cocoa seems to exist so I use >> various other modules. > > > PyObjC can use AppleScript with the NSAppleScript class > ObjC_classic/Classes/NSAppleScript.html>. However, the best way to > send Apple Events from Python is probably appscript > . The > standard library support for Apple Events is very... raw, so I > wouldn't recommend that approach to anyone :) > > -bob Ok thanks, I downloaded the aem module from the page you linked. Everything works fine except for the placing of the caret. I have tried various ways to get this c-structure to work. struct SelectionRange { short unused1; // 0 (not used) short lineNum; // line to select (<0 to specify range) long startRange; // start of selection range (if line < 0) long endRange; // end of selection range (if line < 0) long unused2; // 0 (not used) long theDate; // modification date/time }; This is what I have come up with so far. What is the proper way of passing the struct? def openInExternalEditor(self, _filePath, _lnnum): from aem.send import Application import struct from Carbon.File import FSSpec SelectionRange=struct.pack('hhllll', 0, int(_lnnum), 0,0,0,0) Application('/Applications/TextMate.app').event('aevt','odoc',{'----':FSSpec(_filePath),'sopk':`SelectionRange`}).send() From eichin at metacarta.com Sun Jan 30 04:03:46 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: Sun Jan 30 04:10:08 2005 Subject: [Pythonmac-SIG] Trouble getting TK to work In-Reply-To: References: Message-ID: <7g651fhb3h.fsf@pikespeak.metacarta.com> > File "/sw/lib/python2.3/lib-tk/Tkinter.py", line 3, in ? /sw means you're getting something out of Fink, which may be your problem -- the fink install hacks a path set into your account's dotfiles somewhere, so you may only *think* you're getting the one that comes with osx... Note the difference: $ python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> $ /sw/bin/python Python 2.3.3 (#1, Aug 23 2004, 20:06:57) [GCC 3.3 20030304 (Apple Computer, Inc. build 1640)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> Also if you import sys and print sys.path in either case you'll find *very* different sets of places that they look for installed things... (It also looks from the traceback that you're missing a first line of /sw/lib/python2.3/lib-tk/Tkinter.py, but that's locally strange...) From joachimm at mac.se Sun Jan 30 16:24:47 2005 From: joachimm at mac.se (=?ISO-8859-1?Q?Joachim_M=E5rtensson?=) Date: Sun Jan 30 16:24:51 2005 Subject: [Pythonmac-SIG] Solved! How do I send appleevents to an external program In-Reply-To: <41FC4B99.9000806@mac.se> References: <41FC2D17.4070007@mac.se> <05e4253bce628adf2b3fa8ea2090f6dc@redivi.com> <41FC4B99.9000806@mac.se> Message-ID: <41FCFC3F.9040201@mac.se> This code will open a texteditor with the caret positon on a specific line. Beware of the datefield (last field in the struct) so that you dont let different editors interfer with your changes to the document. def openInExternalEditor(self, _filePath, _lnnum, _editor = '/Applications/TextMate.app'): from aem.send import Application import struct from Carbon.File import FSSpec SelectionRange=struct.pack('hhllll', 0, int(_lnnum)-1, 1,1,0,0) Application(_editor).event('aevt', 'odoc',{'----':FSSpec(_filePath),'kpos':SelectionRange}).send() Thanks for the help, especially Hamish Sanderson who helped me out (off-list). Joachim M?rtensson From rogerb at rogerbinns.com Sun Jan 30 20:28:50 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Sun Jan 30 20:29:16 2005 Subject: [Pythonmac-SIG] Implementing help Message-ID: <328067e6c878a2ce710ff28a2bb94f1a@rogerbinns.com> For the BitPim project I currently use the wxWidgets way of doing help, authored using HelpBlocks. Behind the scenes it amounts to various HTML files dumped into a zip file and given a .htb extension. HelpBlocks also makes a Windows format help file (CHM) and I use the native Windows help api to load and display that help on Windows. I want to produce a tool that can take any wxWidgets format help file and transform it into a directory that can be used by the Apple help APIs (AHRegisterHelpBook and AHGotoPage). These are the steps I took in compliance with Apple's doc: http://developer.apple.com/documentation/Carbon/Conceptual/ ProvidingUserAssitAppleHelp/index.html - Make a directory somewhere - Extract resources/bitpim.htb using unzip into that directory (you can find this file if you peek inside the standard download of BitPim for Mac) - Edit welcome.htm to add a tag in the head section: - Drag and drop the folder onto the help indexing tool. It is in /Developer/Applications/Utilities. (For some reason Apple go out of their way to ensure you can't run this tool from the command line). If I call AHGotoPage (which is the only API I want to call), the page displays correctly but the search widget does nothing and claims to be in a book (null). I couldn't figure out what to do to get AHRegisterHelpBook to accept the directory since Apple's doc helpfully leaves that information out. I assume some sort of directory structure is needed as well as a property list somewhere (the doc is vague). Note that I am not trying to put something within my application bundle. I just want a standalone directory with non-localised help content that I can use from an application if I happen to know where the directory ended up. And I want to be able to do this transformation from pure Python code (ie no dragging and dropping or using an interactive property list editor). As an alternative I would settle for an extra option to py2app where I can give the path of the .htb file and have it do the right thing. BTW I have found the Mac support in Python quite a bit harder to work with than the corresponding stuff for Windows (win32all). In particular most of the documentation is empty and there are no examples. Most of the APIs like to return MacOS.Error: (-50, 'error in user parameter list'). Things are more complicated by the corresponding C API documentation going on about types like FSRef and CFStringRef so I couldn't be sure if I was supposed to call some constructor in Carbon.CF or if it was fine just passing in Python strings. I am still not sure if AhRegisterHelpBook isn't working because I have the wrong types or because the underlying API doesn't like whatever directory structure and contents I am supposed to have but Apple didn't document. Roger From charles.hartman at conncoll.edu Mon Jan 31 01:31:01 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon Jan 31 01:31:08 2005 Subject: [Pythonmac-SIG] Did I bust py2app? Message-ID: I haven't used it for a while. Now when I try to make an app of the thing I've been working on -- OR of a separate package (part of appscript)! -- I get "ObjectGraph not found." ObjectGraph.py(c) *is* in /Library/Python/2.3/py2app/altgraph. So what did I do?? Charles Hartman From rroberts at adobe.com Mon Jan 31 07:50:00 2005 From: rroberts at adobe.com (Read Roberts) Date: Mon Jan 31 11:06:53 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type Message-ID: Now that mcfs.py is deprecated, what is an alternative for the now unsupported FindApplication? From bob at redivi.com Mon Jan 31 13:50:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 31 13:50:59 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: References: Message-ID: <6b20e913b45276d1e262c4be3086ed81@redivi.com> On Jan 31, 2005, at 1:50, Read Roberts wrote: > Now that mcfs.py is deprecated, what is an alternative for the now > unsupported FindApplication? The LaunchServices package. Python 2.4 ships with it (Carbon.LaunchServices I think?) or you can use this package for 2.3 to get it. Alternatively, you can use PyObjC 1.2 or later to just wrap the C function directly like this: . -bob From hengist.podd at virgin.net Mon Jan 31 14:17:40 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 31 14:18:28 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: References: Message-ID: Read Roberts wrote: >Now that mcfs.py is deprecated, what is an alternative for the now >unsupported FindApplication? from LaunchServices import LSFindApplicationForInfo from Carbon.CoreFoundation import kCFURLPOSIXPathStyle creator = 'ttxt' path = LSFindApplicationForInfo(creator, None, None)[1] \ .CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() print path LaunchServices is due for inclusion in MacPython 2.4. Meantime, you can find it on SourceForge CVS or just use the pre-packaged copy from my site: http://freespace.virgin.net/hamish.sanderson/appscript.html HTH has -- http://freespace.virgin.net/hamish.sanderson/ From rroberts at adobe.com Mon Jan 31 19:00:25 2005 From: rroberts at adobe.com (Read Roberts) Date: Mon Jan 31 19:00:36 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: <6b20e913b45276d1e262c4be3086ed81@redivi.com> References: <6b20e913b45276d1e262c4be3086ed81@redivi.com> Message-ID: Thank you both very much for your responses. This was very helpful - I now have working code. Using the package pointed to by Bob Ippolito, I find I cannot use the import statement suggested by has? hengist, although it may work with the package that he points to. My code now looks like: from LaunchServices.Launch import LSFindApplicationForInfo from Carbon.CoreFoundation import kCFURLPOSIXPathStyle import MacOS creatorID = 'KONA' try: adobeHelpFSRef, adobeHelpURL = \ LSFindApplicationForInfo(creatorID, None, None) adobeHelpPath = \ adobeHelpURL.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() except MacOS.Error : adobeHelpPath = None adobeHelpPath is now a Unicode string, and needs to be encoded as 'utf-8' to work with some file operatons. At 7:50 AM -0500 1/31/05, Bob Ippolito wrote: >On Jan 31, 2005, at 1:50, Read Roberts wrote: > >>Now that mcfs.py is deprecated, what is an >>alternative for the now unsupported >>FindApplication? > >The LaunchServices package. Python 2.4 ships >with it (Carbon.LaunchServices I think?) or you >can use this package for 2.3 > >to get it. > >Alternatively, you can use PyObjC 1.2 or later >to just wrap the C function directly like this: >. > >-bob From hengist.podd at virgin.net Mon Jan 31 21:06:50 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 31 21:07:02 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type Message-ID: Read Roberts wrote: >Using the package pointed to by Bob Ippolito, I >find I cannot use the import statement suggested >by has hengist, although it may work with the >package that he points to. My version exported everything from package's main namespace, allowing one to write: import LaunchServices # imports LaunchServices' functions and constants but it looks like the official LaunchServices package requires one to import its sub-modules directly: import LaunchServices.Launch # imports LaunchServices' functions import LaunchServices.LaunchServices # imports LaunchServices' constants Not sure what the logic behind this is: it's less convenient for the user, but OTOH there may be a good reason for it. Maybe Jack or Bob can enlighten? has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Jan 31 21:24:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 31 21:25:09 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: References: Message-ID: On Jan 31, 2005, at 15:06, has wrote: > Read Roberts wrote: > >> Using the package pointed to by Bob Ippolito, I >> find I cannot use the import statement suggested >> by has hengist, although it may work with the >> package that he points to. > > My version exported everything from package's main namespace, allowing > one to write: > > import LaunchServices # imports LaunchServices' functions and > constants > > but it looks like the official LaunchServices package requires one to > import its sub-modules directly: > > import LaunchServices.Launch # imports LaunchServices' functions > import LaunchServices.LaunchServices # imports LaunchServices' > constants > > Not sure what the logic behind this is: it's less convenient for the > user, but OTOH there may be a good reason for it. Maybe Jack or Bob > can enlighten? It's how gensuitemodule does things... My package uses the sources from Python 2.4 unmodified. -bob From hengist.podd at virgin.net Mon Jan 31 21:40:21 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 31 21:41:05 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: References: Message-ID: Bob wrote: >> it looks like the official LaunchServices package requires one to >>import its sub-modules directly: >>[...] >>Not sure what the logic behind this is: [...] Maybe Jack or Bob can >>enlighten? > >It's how gensuitemodule does things... Not that one could ever describe gensuitemodule as an arbiter of good taste... :p Well, for better or worse, I'll assume now it's Just The Way Things Are. Off to do a bunch of quick updates on all my own stuff... has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Jan 31 21:46:33 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 31 21:46:39 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: References: Message-ID: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> On Jan 31, 2005, at 15:40, has wrote: > Bob wrote: > >>> it looks like the official LaunchServices package requires one to >>> import its sub-modules directly: >>> [...] >>> Not sure what the logic behind this is: [...] Maybe Jack or Bob can >>> enlighten? >> >> It's how gensuitemodule does things... > > Not that one could ever describe gensuitemodule as an arbiter of good > taste... :p > > Well, for better or worse, I'll assume now it's Just The Way Things > Are. Off to do a bunch of quick updates on all my own stuff... You should probably use my packages or source for bringing Python 2.4 features (OSA, LaunchServices) into Python 2.3. When building packages, it will build decimal, subprocess, OSA, QuickTime, etc. into separate packages (so you can cherry-pick if you really want to) but it also builds a metapackage that references them all so you can install in one fell swoop (which I would recommend, as the other additions are nice to have). -bob From Dave.Opstad at monotypeimaging.com Mon Jan 31 21:53:40 2005 From: Dave.Opstad at monotypeimaging.com (Opstad, Dave) Date: Mon Jan 31 21:53:48 2005 Subject: [Pythonmac-SIG] What are "METH_CLASS" and "METH_STATIC"? Message-ID: I've had good luck building C-language extensions for my Python work, at least up until now. I've got a C file which #includes Carbon.h as well as the canonical Python.h. Attempting to use distutils to build it fails with the error message: ld: build/temp.darwin-7.7.0-Power_Macintosh-2.3/MacUtils/macutilsmodule.o illegal reference to symbol: _FSPathMakeRef defined in indirectly referenced dynamic library /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Carb onCore.framework/Versions/A/CarbonCore when executing this line: gcc -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/MacUtils/macutilsmodule.o -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/macutilsbackend.so So I tried recompiling/linking by using the same line but adding "-framework Carbon" and the .so built with no complaints. However, once I installed it and tried to import it, I got this from Python: ValueError: module functions cannot set METH_CLASS or METH_STATIC What does this mean? I searched the mail.python.org list and saw a post back in April, 2004 from someone else who saw this exact same line, but nobody every replied to that message. More generally, I'd like to know the answer to this: How do I specify changes to the gcc lines that distutils runs when it builds? Is there a way (short of modifying distutils themselves) to specify optional and/or additional arguments to these commands? Thanks for any help or pointers! Dave Opstad From bob at redivi.com Mon Jan 31 22:15:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 31 22:15:54 2005 Subject: [Pythonmac-SIG] What are "METH_CLASS" and "METH_STATIC"? In-Reply-To: References: Message-ID: On Jan 31, 2005, at 15:53, Opstad, Dave wrote: > I've had good luck building C-language extensions for my Python work, > at > least up until now. I've got a C file which #includes Carbon.h as well > as > the canonical Python.h. Attempting to use distutils to build it fails > with > the error message: > > ld: > build/temp.darwin-7.7.0-Power_Macintosh-2.3/MacUtils/macutilsmodule.o > illegal reference to symbol: _FSPathMakeRef defined in indirectly > referenced > dynamic library > /System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/Carb > onCore.framework/Versions/A/CarbonCore > > when executing this line: > > gcc -Wl,-F. -bundle -framework Python > build/temp.darwin-7.7.0-Power_Macintosh-2.3/MacUtils/macutilsmodule.o > -o > build/lib.darwin-7.7.0-Power_Macintosh-2.3/macutilsbackend.so > > So I tried recompiling/linking by using the same line but adding > "-framework > Carbon" and the .so built with no complaints. However, once I > installed it > and tried to import it, I got this from Python: Yeah, but you should probably -framework CoreServices instead, as that will link in only what it needs, rather than all of Carbon. > ValueError: module functions cannot set METH_CLASS or METH_STATIC > > What does this mean? I searched the mail.python.org list and saw a > post back > in April, 2004 from someone else who saw this exact same line, but > nobody > every replied to that message. It think that it means that you're adding a method to a module dictionary and you shouldn't do that.. functions should be on the module dictionary. Without some source, I wouldn't really be able to say. > More generally, I'd like to know the answer to this: How do I specify > changes to the gcc lines that distutils runs when it builds? Is there > a way > (short of modifying distutils themselves) to specify optional and/or > additional arguments to these commands? from distutils.core import Extension, setup setup(name="LaunchServices", version="0.2", ext_modules=[ Extension('_Launch', ['_Launchmodule.c'], extra_link_args=['-framework', 'ApplicationServices']) ], py_modules=['LaunchServices.Launch', 'LaunchServices.LaunchServices'], package_dir={'LaunchServices':'../../../Lib/plat-mac/Carbon'} ) -bob From Dave.Opstad at monotypeimaging.com Mon Jan 31 22:35:59 2005 From: Dave.Opstad at monotypeimaging.com (Opstad, Dave) Date: Mon Jan 31 22:36:06 2005 Subject: [Pythonmac-SIG] What are "METH_CLASS" and "METH_STATIC"? In-Reply-To: Message-ID: Bob, I fixed setup.py to use the extra link args and switched to CoreServices, as you suggested. That fixed the build issues. I also discovered the main problem I was having: I had forgotten the {NULL, NULL, 0, NULL} entry at the end of my array of PyMethodDefs. I hate copy-and-paste errors... Thanks again for the help! Dave Opstad From hengist.podd at virgin.net Mon Jan 31 22:37:52 2005 From: hengist.podd at virgin.net (has) Date: Mon Jan 31 22:38:30 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> Message-ID: Bob wrote: >You should probably use my packages or source for bringing Python >2.4 features (OSA, LaunchServices) into Python 2.3. Will do. Must've missed the original announcement - didn't know of 'em till today. One thing: the binary installer only works for 10.3. I'd be happy to build a 10.2 version though if you can tell me how (given I'm not familiar with the CVS or making installers). has p.s. I've submitted patches for Carbon.AE [1090958] and OSATerminology [1113328]; don't suppose you know if/when they'll make it into 2.4, and from there into your 2.3 retro-package? -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Jan 31 22:51:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Jan 31 22:51:26 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> Message-ID: <11784ef9dee718e4216b74f0213f1151@redivi.com> On Jan 31, 2005, at 16:37, has wrote: > Bob wrote: > >> You should probably use my packages or source for bringing Python 2.4 >> features (OSA, LaunchServices) into Python 2.3. > > Will do. Must've missed the original announcement - didn't know of 'em > till today. One thing: the binary installer only works for 10.3. I'd > be happy to build a 10.2 version though if you can tell me how (given > I'm not familiar with the CVS or making installers). After checking out the repository with subversion (or just doing a recursive web get, I guess), and having recent version of py2app installed (I suggest also using svn, as it builds python source a bit nicer): % python setup.py bdist_mpkg > p.s. I've submitted patches for Carbon.AE [1090958] and OSATerminology > [1113328]; don't suppose you know if/when they'll make it into 2.4, > and from there into your 2.3 retro-package? Unfortunately these patches need to be rewritten such that they change the gensuitemodule scripts that generate them.. and Jack is really the only one good at doing that :) I've done it before, but that was a long time ago. -bob From etrepum at mac.com Mon Jan 31 01:37:36 2005 From: etrepum at mac.com (Bob Ippolito) Date: Tue Feb 1 14:24:39 2005 Subject: [Pythonmac-SIG] Did I bust py2app? In-Reply-To: References: Message-ID: <227DB5E5-AE94-4C9B-AADC-DFF6E6C7A486@mac.com> On Jan 30, 2005, at 7:31 PM, Charles Hartman wrote: > I haven't used it for a while. Now when I try to make an app of the > thing I've been working on -- OR of a separate package (part of > appscript)! -- I get "ObjectGraph not found." ObjectGraph.py(c) *is* > in /Library/Python/2.3/py2app/altgraph. So what did I do?? You'll need to remove the following directories from /Library/Python/2.3 if they exist, then install the latest py2app (to be safe) -- you have junk from an early version of py2app. modulegraph bdist_mpkg altgraph macholib py2app -bob