From a.h.jaffe at gmail.com Wed Feb 1 17:29:54 2006 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Wed, 01 Feb 2006 16:29:54 +0000 Subject: [Pythonmac-SIG] Mac Python and eggs and bdist_mpkg and ... In-Reply-To: <67D16263-8D42-499B-9B29-63A01F61B2B1@redivi.com> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> <43D6719D.6050607@noaa.gov> <5DF15570-4A6C-4ECD-9398-0E0F510C3FC9@redivi.com> <43D67B29.8080705@noaa.gov> <67D16263-8D42-499B-9B29-63A01F61B2B1@redivi.com> Message-ID: Hi All, On a related note, is there a 'best' way to install python packages on a mac nowadays? It seems that there at least three possibilities: - plain old setup.py install - bdist_mpkg - eggs I've been using bdist_mpkg a lot recently, but this discussion is making me think it may not the preferred way. Any opinions? -Andrew From ronaldoussoren at mac.com Wed Feb 1 19:53:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 1 Feb 2006 19:53:13 +0100 Subject: [Pythonmac-SIG] Mac Python and eggs and bdist_mpkg and ... In-Reply-To: References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> <43D6719D.6050607@noaa.gov> <5DF15570-4A6C-4ECD-9398-0E0F510C3FC9@redivi.com> <43D67B29.8080705@noaa.gov> <67D16263-8D42-499B-9B29-63A01F61B2B1@redivi.com> Message-ID: On 1-feb-2006, at 17:29, Andrew Jaffe wrote: > Hi All, > > On a related note, is there a 'best' way to install python packages > on a > mac nowadays? It seems that there at least three possibilities: > - plain old setup.py install > - bdist_mpkg > - eggs > > I've been using bdist_mpkg a lot recently, but this discussion is > making > me think it may not the preferred way. Any opinions? I've been using setup.py install until now (with adding an extra_path argument to setup.py to make it easier to uninstall). bdist_mpkg is a nice way to distribute binary packages, but doesn't have enough advantages if you don't distribute the resulting packages, mostly because there is no uninstaller. I'll probably switch to setuptools/eggs sometime soon because it is better than anything we have now on OSX and PJE has an (IMHO) good vision of a complete package management solution. Ronald > > -Andrew > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060201/1bd2a05c/attachment.bin From bob at redivi.com Thu Feb 2 02:16:25 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 1 Feb 2006 17:16:25 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> Message-ID: <8B3322BF-F37D-4153-A9A4-646D8AE92869@redivi.com> On Jan 27, 2006, at 8:31 AM, Ronald Oussoren wrote: > > On 27-jan-2006, at 16:38, bear wrote: > >> Ronald Oussoren wrote: >>> >>> On 27-jan-2006, at 4:22, bear wrote: >>> >>>> Ronald Oussoren wrote: >>>>> That part is easy enough. If you want a framework build you'll >>>>> have to patch Makefile.pre.in because it contains a hardcoded '- >>>>> arch ppc' in the section that builds that actual framework. >>>>> Otherwise it should just build (assuming you have an intel mac >>>>> of course, cross-building from PPC to Intel will be hard >>>>> because the build process assumes you'll do a native build). >>>> ok, I found the relevant part in configure (and cofigure.in) >>>> that was putting -arch_only ppc into the Makefile and I've re- >>>> run configure and it seems happy - heck, even the compiling ran >>>> error free. >>>> >>>> But when it got to the link part - I get the following error: >>> >>> You must replace the -arch ppc part by -arch i386. If you want to >>> build a universal binary you'll have to replace the call to >>> libtool by something more complex. I'll see if I can produce a >>> patch later today. >> Coolness - I was able to get a clean build of python for the i386 >> arch just now. I did have to apply a patch to Lib/plat-mac/ >> applesingle.py so that it would run without errors. I got the >> required patch from http://www.opensource.apple.com/darwinsource/ >> tarballs/other/python-16.tar.gz that Kevin mentioned in an earlier >> post to this thread. >> >> Now to build the rest of our app and see how it fairs ;) >> > > From my Makefile.pre.in: -- > This is very ugly. As you have noted you can't just drop -arch ppc > because libtool than assumes that you want to do a 3-way universal > build. Probably because libSystem contains a ppc64 binary. > > I hope to have a script for building a "batteries included" > universal build of python by the end of this weekend. Speaking of "batteries included"... the WASTE 2.1 library used by the ancient PythonIDE (and maybe other old junk?) is not x86 compatible and isn't open source. It would need its Info.plist modified so that it runs under Rosetta if it's distributed at all. -bob From ronaldoussoren at mac.com Thu Feb 2 08:48:22 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 2 Feb 2006 08:48:22 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <8B3322BF-F37D-4153-A9A4-646D8AE92869@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <8B3322BF-F37D-4153-A9A4-646D8AE92869@redivi.com> Message-ID: On 2-feb-2006, at 2:16, Bob Ippolito wrote: >> >> From my Makefile.pre.in: > -- >> This is very ugly. As you have noted you can't just drop -arch ppc >> because libtool than assumes that you want to do a 3-way universal >> build. Probably because libSystem contains a ppc64 binary. >> >> I hope to have a script for building a "batteries included" >> universal build of python by the end of this weekend. > > Speaking of "batteries included"... the WASTE 2.1 library used by > the ancient PythonIDE (and maybe other old junk?) is not x86 > compatible and isn't open source. It would need its Info.plist > modified so that it runs under Rosetta if it's distributed at all. I don't want to include waste, PythonIDE and PackMan it is time for them to die. Ronald > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060202/d1daf73b/attachment.bin From bob at redivi.com Thu Feb 2 09:02:43 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 2 Feb 2006 00:02:43 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <8B3322BF-F37D-4153-A9A4-646D8AE92869@redivi.com> Message-ID: On Feb 1, 2006, at 11:48 PM, Ronald Oussoren wrote: > > On 2-feb-2006, at 2:16, Bob Ippolito wrote: > >>> >>> From my Makefile.pre.in: >> -- >>> This is very ugly. As you have noted you can't just drop -arch >>> ppc because libtool than assumes that you want to do a 3-way >>> universal build. Probably because libSystem contains a ppc64 binary. >>> >>> I hope to have a script for building a "batteries included" >>> universal build of python by the end of this weekend. >> >> Speaking of "batteries included"... the WASTE 2.1 library used by >> the ancient PythonIDE (and maybe other old junk?) is not x86 >> compatible and isn't open source. It would need its Info.plist >> modified so that it runs under Rosetta if it's distributed at all. > > I don't want to include waste, PythonIDE and PackMan it is time for > them to die. +1 -bob From w.northcott at unsw.edu.au Fri Feb 3 02:34:43 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Fri, 3 Feb 2006 12:34:43 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: Message-ID: I have been trying to build wxPython on Tiger (10.4.4 gcc--3.3/g77) with some difficulty, which may just be me being dense. I have the latest ActivePython and have built and installed wxMac-2.6.2 widgets without problems. However when I attempt to build wxPython it breaks here: building '_core_' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict- prototypes -DSWIG_TYPE_TABLE=_wxPython_table -DHAVE_CONFIG_H - DWXP_USE_THREAD=1 -UNDEBUG -D__WXMAC__ -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -DNO_GCC_PRAGMA -Iinclude -Isrc -I/usr/local/lib/wx/ include/mac-ansi-release-2.6 -I/usr/local/include/wx-2.6 -I/Library/ Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/ helpers.cpp -o build/temp.darwin-8.4.0-Power_Macintosh-2.4/src/ helpers.o -O3 In file included from /usr/local/include/wx-2.6/wx/memory.h:20, from /usr/local/include/wx-2.6/wx/object.h:25, from /usr/local/include/wx-2.6/wx/wx.h:16, from include/wx/wxPython/wxPython_int.h:19, from src/helpers.cpp:16 /usr/local/include/wx-2.6/wx/string.h: In function `int Stricmp(const char*, const char*)': /usr/local/include/wx-2.6/wx/string.h:135: error: `strcasecmp' undeclared (first use this function) I can't say I have much understanding of the wxWidgets/wxPython build process but the error seems to go back to code in configure.in from wxWidgets. On lines 1632 to 1680 of configure.in there is code which appears to attempt to identify whether strcasecmp() is declared in or . It is erroneously concluding that is appropriate, and HAVE_STRCASECMP_IN_STRING.H is defined. However in the declaration of strcasecmp() is conditional on #ifndef POSIX_C_SOURCE. So the wxPython compile breaks. Apple's man page is quite clear that to use strcasecmp(), is required. Indeed it says, "Their prototypes existed previously in before they were moved to for IEEE Std 1003.1-2001 (``POSIX.1'') compliance." This would also seem to be compliant with OpenGroup standards as at: http://www.opengroup.org/ onlinepubs/007908799/xsh/strcasecmp.html. While Googling I came across some messages from Bob on what seemed to be a closely related issue Is there something that I am doing wrong or does this need fixing? If someone could give me some pointers about exactly how the wxWidgets configuration propagates down to wxPython, then I might be able to cook up some sort of fix. Also does anyone understand when and where POSIX_C_SOURCE gets defined? Bill Northcott From w.northcott at unsw.edu.au Fri Feb 3 02:48:14 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Fri, 3 Feb 2006 12:48:14 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: Message-ID: One more observation on my last posting: The #ifndef POSIX_C_SOURCE condition on strcasecmp() in seems to have been introduced between Panther and Tiger. Looking in the 10.3.9 SDK, strcasecmp() is only conditional on #ifndef _ANSI_SOURCE. So presumably the build works on Panther, but the new seems to me to be correct, as in standards compliant. I have seen similar on Tru64 and Solaris, and seen similar problems arise. Bill Northcott From w.northcott at unsw.edu.au Fri Feb 3 04:56:59 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Fri, 3 Feb 2006 14:56:59 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: Message-ID: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> The more I look, the more the problem spreads. I found that _POSIX_C_SOURCES is defined in pyconfig.h in Python 2.4 but not 2.3. So this problem will only arise using Python 2.4 on Tiger. Python 2.4 on Panther, or 2.3 on Tiger would be OK. It seems both Apple and the Python people decided to be IEEE Stds 1003.1-2001 compliant, but it has caused a problem in wxWidgets/wxPython. Bill From bob at redivi.com Fri Feb 3 05:23:29 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 2 Feb 2006 20:23:29 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> Message-ID: <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> On Jan 27, 2006, at 8:31 AM, Ronald Oussoren wrote: > > On 27-jan-2006, at 16:38, bear wrote: > >> Ronald Oussoren wrote: >>> >>> On 27-jan-2006, at 4:22, bear wrote: >>> >>>> Ronald Oussoren wrote: >>>>> That part is easy enough. If you want a framework build you'll >>>>> have to patch Makefile.pre.in because it contains a hardcoded '- >>>>> arch ppc' in the section that builds that actual framework. >>>>> Otherwise it should just build (assuming you have an intel mac >>>>> of course, cross-building from PPC to Intel will be hard >>>>> because the build process assumes you'll do a native build). >>>> ok, I found the relevant part in configure (and cofigure.in) >>>> that was putting -arch_only ppc into the Makefile and I've re- >>>> run configure and it seems happy - heck, even the compiling ran >>>> error free. >>>> >>>> But when it got to the link part - I get the following error: >>> >>> You must replace the -arch ppc part by -arch i386. If you want to >>> build a universal binary you'll have to replace the call to >>> libtool by something more complex. I'll see if I can produce a >>> patch later today. >> Coolness - I was able to get a clean build of python for the i386 >> arch just now. I did have to apply a patch to Lib/plat-mac/ >> applesingle.py so that it would run without errors. I got the >> required patch from http://www.opensource.apple.com/darwinsource/ >> tarballs/other/python-16.tar.gz that Kevin mentioned in an earlier >> post to this thread. >> >> Now to build the rest of our app and see how it fairs ;) >> > > From my Makefile.pre.in: --- > This is very ugly. As you have noted you can't just drop -arch ppc > because libtool than assumes that you want to do a 3-way universal > build. Probably because libSystem contains a ppc64 binary. > > I hope to have a script for building a "batteries included" > universal build of python by the end of this weekend. I've made a private branch of python24-maint via SVK that's probably most of the way there. It fixes a couple of the endian issues in the Mac modules (platform.mac_ver, applesingle, gestalt, and the OSType converter functions) and fixes enough of the configure/make/autoconf crap so that it cleanly builds on either ppc or i386 (with just one compiler, and not yet universal): http://svn.red-bean.com/bob/python24-fat I think removed all the -arch flags from everywhere, and it does intelligently build a fat library at the end (with one arch), so assuming you can stuff the CCFLAGS/LDFLAGS in it'll probably build universal properly (using CCFLAGS/LDFLAGS environment variables are apparently not useful for Python as-is... I'll probably try and fix that). Rather than work around libtool, I went the Xcode approach and dropped it from the build process altogether in exchange for just cc and lipo. It uses lipo to determine which architectures are in the static library that was built. The Makefile.pre.in in my branch looks like this: if test -x /usr/bin/lipo; then \ Z="" ;\ for X in `lipo -info $(LIBRARY) | cut -f 3 -s -d :`; do \ Z="$$Z $(LDLIBRARY).libtool.$$X" ;\ $(CC) -o $(LDLIBRARY).libtool.$$X -arch $$X -dynamiclib \ -all_load $(LIBRARY) -Wl,-single_module \ -install_name $(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$ (VERSION)/Python \ -compatibility_version $(VERSION) \ -current_version $(VERSION) ;\ LIPO_FILES="$(LIPO_FILES) $(LDLIBRARY).libtool.$(ARCH)" ;\ done ;\ lipo -create$$Z -output $(LDLIBRARY) ;\ rm -f$$Z ;\ else\ libtool -o $(LDLIBRARY) -dynamic $(OTHER_LIBTOOL_OPT) $(LIBRARY) - arch_only ppc \ @LIBTOOL_CRUFT@ ;\ fi -bob From daniel at brightfire.com Fri Feb 3 06:31:16 2006 From: daniel at brightfire.com (Daniel Lord) Date: Thu, 2 Feb 2006 21:31:16 -0800 Subject: [Pythonmac-SIG] Non-obvious Question about PyObjC and Xcode In-Reply-To: References: Message-ID: I am a neophyte when it comes to Cocoa and ObjC so forgive me if his question is nonsensical and the answer is obvious to you seasoned professionals. I decided to tackle a formidable task: learning Cocoa and Objective-C by approaching them through Python and Perl which I know and find better 'RAD' tools (though I do know C and C++ and have written some small Carbon applications using XCode and Code Warrior in the past). So I face a steep and formidable learning curve akin to soloing the Eiger in Winter perhaps. But here goes... I have to say I am a bit confused on the two very different sets of directions for using PyObjC and I want to use the tools a formal way to avoid as much obsolescence of my projects as possible: 1. The Tutorials on the SourceForge site present a somewhat traditional way of creating outlets and actions and linking them to an instantiated class in Interface Builder before executing py2app. However, unlike using the Camel Bones Perl ObjC Bridge, I have to run the external build tool outside of Xcode to make a build. I find the Camel Bones method much easier and it almost tempts me to go back to using Perl over Python (I said _almost_ ;-) $$$$$This means that once py2app is run though, I cannot change my nib files because the outlets and actions won't be 'bridged' or will they? 2. The Apple documentation describes an entirely different process which involves the Bindings tab of the Inspector in Interface Builder and I don't really understand it very well. What confuses me is this: 1) are they two different methods of achieving the same end and eventually will coalesce into some standard that fits Xcode better or 2) are they instead stark differences in philosophy and underlying architecture in accessing the PyObjC Bridge which will stay diverged with one eventually obviating the other? The advantage of the Apple-documented way is that I can use Xcode for building the application which is very convenient and consistent but I don't really 'get' the Binding tab just yet since I would think that it would show the bindings I make the traditional way with the Control-click graphic connections if the underlying architecture is consistent--and it doesn't. So they seem mutually exclusive and not consistent in Xcode. That worries me frankly--it makes them both seem more like hacks. It seems to be one way or another. I find this 'schizophenic' approach to development tools unsettling and it concerns me that I risk very fast obsolescence of my work if I pick the wrong build approach. Or worse: that both methods are just temporary and will disappear capriciously one OS revision without warning.So it begs the question: which method will be the 'main- stream' recommendation going forward? The SourceForge team is clearly a standard-setter but then again Apple has 'vendor power' when it comes to Cocoa and Objective-C. The Apple way is far better integrated with Xcode but seems strained and awkward when creating the outlets and actions because it doesn't use the 'standard' that Objective-C/Cocoa projects use and all the Cocoa tutorials use.. Or am I just confused because Cocoa and the Apple Tools is fairly opaque to me at this point? From bob at redivi.com Fri Feb 3 07:09:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 2 Feb 2006 22:09:34 -0800 Subject: [Pythonmac-SIG] Non-obvious Question about PyObjC and Xcode In-Reply-To: References: Message-ID: On Feb 2, 2006, at 9:31 PM, Daniel Lord wrote: > I have to say I am a bit confused on the two very different sets of > directions for using PyObjC and I want to use the tools a formal way > to avoid as much obsolescence of my projects as possible: There are two supported ways to use PyObjC in combination -- with and without Xcode. Using Xcode is somewhat better for prototyping, not using Xcode is better for compatibility and version control (since the Xcode version needs to muck about reading the Xcode project file in order to get the information it needs). > 1. The Tutorials on the SourceForge site present a somewhat > traditional way of creating outlets and actions and linking them to > an instantiated class in Interface Builder before executing py2app. > However, unlike using the Camel Bones Perl ObjC Bridge, I have to run > the external build tool outside of Xcode to make a build. I find the > Camel Bones method much easier and it almost tempts me to go back to > using Perl over Python (I said _almost_ ;-) $$$$$This means that once > py2app is run though, I cannot change my nib files because the > outlets and actions won't be 'bridged' or will they? PyObjC ships with an Xcode template which will run py2app for you, so there is effectively no "external build tool" you need to worry about if you take that approach. Nib files and py2app are totally unrelated. With py2app's alias mode, you don't even need to run py2app again when you *change the source code*! > 2. The Apple documentation describes an entirely different process > which involves the Bindings tab of the Inspector in Interface Builder > and I don't really understand it very well. What confuses me is this: > 1) are they two different methods of achieving the same end and > eventually will coalesce into some standard that fits Xcode better or > 2) are they instead stark differences in philosophy and underlying > architecture in accessing the PyObjC Bridge which will stay diverged > with one eventually obviating the other? > > The advantage of the Apple-documented way is that I can use Xcode for > building the application which is very convenient and consistent but > I don't really 'get' the Binding tab just yet since I would think > that it would show the bindings I make the traditional way with the > Control-click graphic connections if the underlying architecture is > consistent--and it doesn't. So they seem mutually exclusive and not > consistent in Xcode. That worries me frankly--it makes them both seem > more like hacks. It seems to be one way or another. Bindings and Outlets/Actions are two different things, but there's a lot of overlap in what they can do. Bindings are new in Mac OS X 10.3, and PyObjC is a lot older than that. > I find this 'schizophenic' approach to development tools unsettling > and it concerns me that I risk very fast obsolescence of my work if I > pick the wrong build approach. Or worse: that both methods are just > temporary and will disappear capriciously one OS revision without > warning.So it begs the question: which method will be the 'main- > stream' recommendation going forward? The SourceForge team is clearly > a standard-setter but then again Apple has 'vendor power' when it > comes to Cocoa and Objective-C. The Apple way is far better > integrated with Xcode but seems strained and awkward when creating > the outlets and actions because it doesn't use the 'standard' that > Objective-C/Cocoa projects use and all the Cocoa tutorials use.. > > Or am I just confused because Cocoa and the Apple Tools is fairly > opaque to me at this point? You're confused for a lot of reasons... Whichever APIs you use, you don't have to worry about forwards compatibility. Nothing that Apple does with regard to their APIs are temporary. They almost never break any API that used to work, but they will shove deprecation warnings down your throat at compile time (and sometimes runtime in the console log). For example, lots of code from the early 90s from an entirely different flavor of Mac OS still compiles if you prod it a little (change the header files to Carbon, etc.). Nothing that Xcode does is special (except ZeroLink, I guess, which isn't relevant). All the functionality in Xcode lives somewhere in a unix tool or in a Cocoa API. It's "just" a pretty face on stuff you can do by other means. Interface Builder is a separate application from Xcode. Bindings and Outlets/Actions aren't mutually exclusive. Every technique that can be used with Cocoa is applicable to PyObjC, so basically any Apple tutorial for Cocoa/Objective-C is going to work with PyObjC given that you know how to translate the syntax and build instructions appropriately. -bob From w.northcott at unsw.edu.au Fri Feb 3 07:59:50 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Fri, 3 Feb 2006 17:59:50 +1100 Subject: [Pythonmac-SIG] wxPython building process on Mac Os X 10.4.x Message-ID: Hi Adriano Back in September you wrote to pythonmac about build errors with Python 2.4 and wxPython 2.6.1. Did you ever find the answer to these? /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long double gammal (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2027: error: 'gamma' was not declared in this scope /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long int rinttoll (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2141: error: 'rinttol' was not declared in this scope /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long int roundtoll (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2179: error: 'roundtol' was not declared in this scope error: command 'gcc' failed with exit status 1 I am trying to build wxPython 2.6.2 with Python 2.4 on MacOS X 10.4.4 and have similar problems. Cheers Bill Northcott From kevino at theolliviers.com Fri Feb 3 08:32:04 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 2 Feb 2006 23:32:04 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> Message-ID: Hi Bill, On Feb 2, 2006, at 7:56 PM, Bill Northcott wrote: > The more I look, the more the problem spreads. > > I found that _POSIX_C_SOURCES is defined in pyconfig.h in Python 2.4 > but not 2.3. So this problem will only arise using Python 2.4 on > Tiger. Python 2.4 on Panther, or 2.3 on Tiger would be OK. It seems > both Apple and the Python people decided to be IEEE Stds 1003.1-2001 > compliant, but it has caused a problem in wxWidgets/wxPython. Thanks for all your help tracking this down! I'm seeing the problem and have made some changes to the wx configure script that fix it on OS X. But I need to check if the fix doesn't break anything on other platforms first. We should have this in the 2.6.3 release (due in a couple weeks), and fixed in HEAD hopefully in the next couple days. (I had been doing my 2.4 builds on Panther, which is why I had not noticed this before!) Kevin > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From w.northcott at unsw.edu.au Fri Feb 3 08:53:11 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Fri, 3 Feb 2006 18:53:11 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> Message-ID: <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> On 03/02/2006, at 6:32 PM, Kevin Ollivier wrote: >> I found that _POSIX_C_SOURCES is defined in pyconfig.h in Python 2.4 >> but not 2.3. So this problem will only arise using Python 2.4 on >> Tiger. Python 2.4 on Panther, or 2.3 on Tiger would be OK. It seems >> both Apple and the Python people decided to be IEEE Stds 1003.1-2001 >> compliant, but it has caused a problem in wxWidgets/wxPython. > > Thanks for all your help tracking this down! I'm seeing the problem > and have made some changes to the wx configure script that fix it > on OS X. But I need to check if the fix doesn't break anything on > other platforms first. We should have this in the 2.6.3 release > (due in a couple weeks), and fixed in HEAD hopefully in the next > couple days. (I had been doing my 2.4 builds on Panther, which is > why I had not noticed this before!) Hi Kevin I thought about this some more and concluded that messing with the autoconf stuff might break other extensions that worked now. After reading more, particularly http://www.opengroup.org/onlinepubs/ 009695399/functions/xsh_chap02_02.html , I settled on a change in wx/ string.h. It seems to me that if the host is IEEE Std 1003.1-2001 compliant then the HAVE_STRCASECMP..... macros should be ignored and strings.h included. So I added more alternative conditions to wx/string.h:46 thus: #if defined(HAVE_STRCASECMP_IN_STRINGS_H) || _POSIX_C_SOURCE == 200112L || _XOPEN_SOURCE == 600 This definitely works on MacOS X 10.4 and I don't see how it can break on other systems. Cheers Bill Northcott PS I still have the issue from my other posting which Adriano posted in September. From bob at redivi.com Fri Feb 3 13:00:06 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 04:00:06 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> Message-ID: <50F3BB9B-14FE-4B54-83F2-CE86CB8EB415@redivi.com> On Feb 2, 2006, at 8:23 PM, Bob Ippolito wrote: > > On Jan 27, 2006, at 8:31 AM, Ronald Oussoren wrote: > >> >> On 27-jan-2006, at 16:38, bear wrote: >> >>> Ronald Oussoren wrote: >>>> >>>> On 27-jan-2006, at 4:22, bear wrote: >>>> >>>>> Ronald Oussoren wrote: >>>>>> That part is easy enough. If you want a framework build you'll >>>>>> have to patch Makefile.pre.in because it contains a hardcoded '- >>>>>> arch ppc' in the section that builds that actual framework. >>>>>> Otherwise it should just build (assuming you have an intel mac >>>>>> of course, cross-building from PPC to Intel will be hard >>>>>> because the build process assumes you'll do a native build). >>>>> ok, I found the relevant part in configure (and cofigure.in) >>>>> that was putting -arch_only ppc into the Makefile and I've re- >>>>> run configure and it seems happy - heck, even the compiling ran >>>>> error free. >>>>> >>>>> But when it got to the link part - I get the following error: >>>> >>>> You must replace the -arch ppc part by -arch i386. If you want to >>>> build a universal binary you'll have to replace the call to >>>> libtool by something more complex. I'll see if I can produce a >>>> patch later today. >>> Coolness - I was able to get a clean build of python for the i386 >>> arch just now. I did have to apply a patch to Lib/plat-mac/ >>> applesingle.py so that it would run without errors. I got the >>> required patch from http://www.opensource.apple.com/darwinsource/ >>> tarballs/other/python-16.tar.gz that Kevin mentioned in an earlier >>> post to this thread. >>> >>> Now to build the rest of our app and see how it fairs ;) >>> >> >> From my Makefile.pre.in: > --- >> This is very ugly. As you have noted you can't just drop -arch ppc >> because libtool than assumes that you want to do a 3-way universal >> build. Probably because libSystem contains a ppc64 binary. >> >> I hope to have a script for building a "batteries included" >> universal build of python by the end of this weekend. > > I've made a private branch of python24-maint via SVK that's probably > most of the way there. It fixes a couple of the endian issues in the > Mac modules (platform.mac_ver, applesingle, gestalt, and the OSType > converter functions) and fixes enough of the configure/make/autoconf > crap so that it cleanly builds on either ppc or i386 (with just one > compiler, and not yet universal): > > http://svn.red-bean.com/bob/python24-fat I've got universal working against the 10.4u SDK at the same svn URL, even building from a PPC host. $ arch; sw_vers ppc ProductName: Mac OS X ProductVersion: 10.4.4 BuildVersion: 8G32 $ svn co http://svn.red-bean.com/bob/python24-fat ... $ cd python24-fat $ mkdir _build; cd _build $ ../configure --enable-universalsdk --enable-framework && make ... $ lipo -info python.exe Python.framework/Versions/2.4/Python libpython2.4.a build/lib.macosx-10.4.4-fat-2.4/gestalt.so Architectures in the fat file: python.exe are: ppc i386 Architectures in the fat file: Python.framework/Versions/2.4/Python are: ppc i386 Architectures in the fat file: libpython2.4.a are: ppc i386 Architectures in the fat file: build/lib.macosx-10.4.3-fat-2.4/ gestalt.so are: ppc i386 $ DYLD_FRAMEWORK_PATH=. ./python.exe -c "from distutils.util import get_platform as p; print p()" $ DYLD_FRAMEWORK_PATH=. ./python.exe -c "import platform; print platform.mac_ver()" .. and on an i386 box: $ arch; sw_vers i386 ProductName: Mac OS X ProductVersion: 10.4.3 BuildVersion: 8F1099 $ DYLD_FRAMEWORK_PATH=. ./python.exe -c "from distutils.util import get_platform as p; print p()" macosx-10.4.3-fat $ DYLD_FRAMEWORK_PATH=. ./python.exe -c "import platform; print platform.mac_ver()" ('10.4.3', ('', '', ''), 'i386') $ DYLD_FRAMEWORK_PATH=. /usr/libexec/oah/oah750 ./python.exe -c "import platform; print platform.mac_ver()" ('10.4.3', ('', '', ''), 'PowerPC') The only thing "wrong" with this build, as far as I can tell, is that it very likely isn't going to work on Mac OS X 10.3. I'm not very interested in fixing this myself, especially because I don't have a 10.3 machine around. Clearly I had to make a bunch of changes to configure.in, Makefile.pre.in, some of the Mac modules, and distutils (so it gets the platform_name correct. The resultant is really fat, not the host arch.. especially important for setuptools). There is some more work that needs to be done with regard to distribution, but I think it's pretty close. -bob From ronaldoussoren at mac.com Fri Feb 3 13:53:24 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 03 Feb 2006 13:53:24 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <50F3BB9B-14FE-4B54-83F2-CE86CB8EB415@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <50F3BB9B-14FE-4B54-83F2-CE86CB8EB415@redivi.com> Message-ID: <460857.1138971204880.JavaMail.ronaldoussoren@mac.com> On Friday, February 03, 2006, at 01:00PM, Bob Ippolito wrote: >> >> I've made a private branch of python24-maint via SVK that's probably >> most of the way there. It fixes a couple of the endian issues in the >> Mac modules (platform.mac_ver, applesingle, gestalt, and the OSType >> converter functions) and fixes enough of the configure/make/autoconf >> crap so that it cleanly builds on either ppc or i386 (with just one >> compiler, and not yet universal): >> >> http://svn.red-bean.com/bob/python24-fat > >I've got universal working against the 10.4u SDK at the same svn URL, >even building from a PPC host. Oh bummer, you beat me too it. I'll post my build scripts tonight. My version requires an intel box to build and works on 10.3 or later. Running on 10.3 while still having os.statvfs on 10.4 requires some gross hacks to extension modules. Ronald From kevino at theolliviers.com Fri Feb 3 17:52:39 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 3 Feb 2006 08:52:39 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> Message-ID: <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> Hi Bill, On Feb 2, 2006, at 11:53 PM, Bill Northcott wrote: > On 03/02/2006, at 6:32 PM, Kevin Ollivier wrote: >>> I found that _POSIX_C_SOURCES is defined in pyconfig.h in Python 2.4 >>> but not 2.3. So this problem will only arise using Python 2.4 on >>> Tiger. Python 2.4 on Panther, or 2.3 on Tiger would be OK. It >>> seems >>> both Apple and the Python people decided to be IEEE Stds 1003.1-2001 >>> compliant, but it has caused a problem in wxWidgets/wxPython. >> >> Thanks for all your help tracking this down! I'm seeing the >> problem and have made some changes to the wx configure script that >> fix it on OS X. But I need to check if the fix doesn't break >> anything on other platforms first. We should have this in the >> 2.6.3 release (due in a couple weeks), and fixed in HEAD hopefully >> in the next couple days. (I had been doing my 2.4 builds on >> Panther, which is why I had not noticed this before!) > > Hi Kevin > > I thought about this some more and concluded that messing with the > autoconf stuff might break other extensions that worked now. > > After reading more, particularly http://www.opengroup.org/ > onlinepubs/009695399/functions/xsh_chap02_02.html , I settled on a > change in wx/string.h. It seems to me that if the host is IEEE Std > 1003.1-2001 compliant then the HAVE_STRCASECMP..... macros should > be ignored and strings.h included. > > So I added more alternative conditions to wx/string.h:46 thus: > #if defined(HAVE_STRCASECMP_IN_STRINGS_H) || _POSIX_C_SOURCE == > 200112L || _XOPEN_SOURCE == 600 > > This definitely works on MacOS X 10.4 and I don't see how it can > break on other systems. Out of curiosity, was there a problem with just doing defined (_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE) tests? Are these always guaranteed to be set to those values? > Cheers > Bill Northcott > > PS I still have the issue from my other posting which Adriano > posted in September. Could you give me a thread to look up so that I can follow up? Thanks, Kevin From a.h.jaffe at gmail.com Fri Feb 3 17:57:44 2006 From: a.h.jaffe at gmail.com (Andrew Jaffe) Date: Fri, 03 Feb 2006 16:57:44 +0000 Subject: [Pythonmac-SIG] best way to install packages? Message-ID: Hi All, I originally posted this in a different thread, but I realize that the first post was about 10 levels deep, so possibly ignored by people who might care or be able to help (or possibly just ignored as a dumb question). Anyway, is there a 'best' way to install python packages on a mac nowadays? It seems that there at least three possibilities: - plain old setup.py install - bdist_mpkg - eggs (in which case I realize I'm not sure I know exactly *how* to do this) I've been using bdist_mpkg a lot recently, but this discussion is making me think it may not the preferred way. Any opinions? (There was one answer in favor of plain-old setup.py install.) -Andrew From bob at redivi.com Fri Feb 3 18:09:27 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 09:09:27 -0800 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: References: Message-ID: <42BCEBF4-6EF5-4128-AD5F-84EC65174085@redivi.com> On Feb 3, 2006, at 8:57 AM, Andrew Jaffe wrote: > I originally posted this in a different thread, but I realize that the > first post was about 10 levels deep, so possibly ignored by people who > might care or be able to help (or possibly just ignored as a dumb > question). Anyway, is there a 'best' way to install python packages > on a > mac nowadays? It seems that there at least three possibilities: > > - plain old setup.py install > - bdist_mpkg > - eggs (in which case I realize I'm not sure I know exactly > *how* to > do this) > > I've been using bdist_mpkg a lot recently, but this discussion is > making > me think it may not the preferred way. Any opinions? (There was one > answer in favor of plain-old setup.py install.) Whichever one works. setup.py install works for everything, but you might need to specify --install-scripts in order to make the scripts get installed to a useful location. bdist_mpkg does that for you. Some packages are dumb and don't really use distutils, like Twisted, so bdist_mpkg doesn't work everywhere. setuptools is a bit more sensitive to distutils abuse and definitely doesn't like Twisted, but also doesn't like some other packages like Zope.Interface (IIRC). If you want to learn more about setuptools from a user's perspective, read the EasyInstall documentation. If you want to learn about it from a developer's perspective, read the setuptools and PkgResources documentation. http://peak.telecommunity.com/DevCenter/EasyInstall http://peak.telecommunity.com/DevCenter/setuptools http://peak.telecommunity.com/DevCenter/PkgResources Personally, I've been using setuptools for everything lately because it deals with a few issues like dependencies and development builds. It's not yet ready for everyone all the time, but it's clearly the future. -bob From bob at redivi.com Fri Feb 3 18:28:07 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 09:28:07 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> <1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com> Message-ID: <21675E32-8217-41F1-B5BC-0B54EC54D6D3@redivi.com> On Jan 27, 2006, at 12:19 AM, Ronald Oussoren wrote: > > On 27-jan-2006, at 8:46, Kevin Ollivier wrote: > >> On Jan 26, 2006, at 10:55 PM, Bob Ippolito wrote: >> >>> Some extensions aren't going to build cleanly universal, and most >>> users probably aren't going to have all the SDKs installed so if >>> it shipped with universal flags then it wouldn't be able to build >>> extensions. >> >> Unless we had distutils check for the existence of the Universal >> SDK before setting the flags, or probably more accurately, remove >> them if the SDK isn't available. Then perhaps add a distutils >> 'flag' to manually turn off Universal building for extensions that >> can't be fixed. This might be a bit of a hack, but I don't imagine >> it would be too painful. The question is how many extensions would >> have troubles... But I guess the only way we'll know is to test >> the waters. In any case, even if it wouldn't be reasonable to make >> a Universal build the "official" build, it would be very useful to >> people packaging apps, even if it were Tiger+ only. > > I know of one popular extension (cElementTree) that won't build > with '-arch i386 -arch ppc' because it calcutes a #define based on > the current byte-order. There might be others, I haven't done a > thorough search yet. In my python24-fat branch, I made the following change to pyconfig.h.in which I believe will resolve that issue in any extension that doesn't do something dumb like trying to grep the endianness out of pyconfig.h: http://svn.red-bean.com/bob/python24-fat/pyconfig.h.in /* Define to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ #ifdef __BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #else #ifndef __LITTLE_ENDIAN__ #undef WORDS_BIGENDIAN #endif #endif GCC defines __BIG_ENDIAN__ to 1 when it's compiling a big endian arch... and __LITTLE_ENDIAN__ to 1 when it's compiling on a little endian arch. Configured on i386, this turns into: #ifdef __BIG_ENDIAN__ #define WORD_BIGENDIAN 1 #else #ifndef __LITTLE_ENDIAN__ /* #undef WORDS_BIGENDIAN */ #endif #endif When configured on PPC, it turns into: #ifdef __BIG_ENDIAN__ #define WORD_BIGENDIAN 1 #else #ifndef __LITTLE_ENDIAN__ #define WORDS_BIGENDIAN 1 #endif #endif Since this is GCC, the #ifndef __LITTLE_ENDIAN__ branch is always false... so I'm making this a compile-time not configure-time value, but I left in the configure-time stuff for other platforms. -bob From Chris.Barker at noaa.gov Fri Feb 3 18:59:07 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 03 Feb 2006 09:59:07 -0800 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: References: Message-ID: <43E399EB.9060806@noaa.gov> Andrew Jaffe wrote: > Anyway, is there a 'best' way to install python packages on a > mac nowadays? It seems that there at least three possibilities: > > - plain old setup.py install > - bdist_mpkg > - eggs (in which case I realize I'm not sure I know exactly *how* to > do this) The "Best" way to install packages is to use whatever form you get. If you get an egg, use easy-install, if you get a mpkg, point and click it, if you the source, use setup.py. I'm not just being glib here. I wonder if you, in fact, are asking a larger question, which it would be nice to discuss here: What is the best way to distribute packages? Now you have to consider the three options above: 1) Just distribute the source with a setup.py 2) Use bdist_mpkg to build a mpkg 3) Build and egg. The reason I make this distinction is that if you are getting just the source from a package maintainer, there is little reason to go though the trouble of making mpkgs or eggs, if you only want to install it on your own machine. slight modification to that: The is no reason to make a mpkg. You might want to make an egg, so that you can get the versioning control eggs give you (and some other features, but versioning control is the big one) However, if it's just for your purposes, and the package maintainer hasn't set up setup.py to build and egg, it's probably not worth it. That being said, I would love it if EVERYONE that downloads and builds a source package on their Mac would contribute a binary package to the community. Mac users like binary packages! I suggest the following for making a package that can be distributed: - Make an egg. - If you can't figure out how to make an ebb, use bdist_mpkg - I think Bob is working on making py2app support eggs with bdist_mpkg, so that may get easy. However, keep in mind that when you make a binary package, it will only work (reliably) with the version of Python that you build it with. I think the versions we should support are: Bob's "official unofficial" 2.4.1 framework build for 10.3 (this will run on 10.4 also) 2.4.1 framework build for 10.4 There's something to be said for supporting Apple's pythons but I think that's lower priority. And these packages should be put up on pythonmac.org One other note: The Framework builds put the "bin" directory inside the Framework. That's where scripts get installed by default. What that means is that in order to use them, the user needs to add that directory to their PATH. This isn't a big deal, but it reminds me too much of the old DOS days, where you needed to add something to your PATH for every darn piece of software you installed. I much prefer the *nix standard of having a few locations where executables get installed, and I's like to see the default scripts directory be /use/local/bin. Should this be the standard? How could we accomplish that? Or should we just tell people to add the Framework bin directory to their PATH. Mostly I feel strongly that, as a community, we need to establish standard ways of doing Python on OS-X, and publish them somewhere. I'm not picky about what those standards are, as long as they exist. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Fri Feb 3 19:33:22 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 3 Feb 2006 19:33:22 +0100 Subject: [Pythonmac-SIG] Non-obvious Question about PyObjC and Xcode In-Reply-To: References: Message-ID: <5A5212DC-AFC8-4C02-8535-B28BD58F2027@mac.com> On 3-feb-2006, at 6:31, Daniel Lord wrote: > I am a neophyte when it comes to Cocoa and ObjC so forgive me if his > question is nonsensical and the answer is obvious to you seasoned > professionals. I decided to tackle a formidable task: learning Cocoa > and Objective-C by approaching them through Python and Perl which I > know and find better 'RAD' tools (though I do know C and C++ and have > written some small Carbon applications using XCode and Code Warrior > in the past). So I face a steep and formidable learning curve akin to > soloing the Eiger in Winter perhaps. But here goes... I learned Cocoa while rewriting PyObjC :-). Cocoa isn't very hard, the hard part is deducing how the framework designers want you to write code. Cocoa is one of those "if it is hard you're doing it the wrong way" frameworks. > > I have to say I am a bit confused on the two very different sets of > directions for using PyObjC and I want to use the tools a formal way > to avoid as much obsolescence of my projects as possible: > > 1. The Tutorials on the SourceForge site present a somewhat > traditional way of creating outlets and actions and linking them to > an instantiated class in Interface Builder before executing py2app. > However, unlike using the Camel Bones Perl ObjC Bridge, I have to run > the external build tool outside of Xcode to make a build. I find the > Camel Bones method much easier and it almost tempts me to go back to > using Perl over Python (I said _almost_ ;-) $$$$$This means that once > py2app is run though, I cannot change my nib files because the > outlets and actions won't be 'bridged' or will they? No, the tutorial presents an easy way to generate the initial implemention of the classes you defined in the nib file. If you change the nib you'll have to change your sources by hand, no need to rerun tools again. > > 2. The Apple documentation describes an entirely different process > which involves the Bindings tab of the Inspector in Interface Builder > and I don't really understand it very well. What confuses me is this: > 1) are they two different methods of achieving the same end and > eventually will coalesce into some standard that fits Xcode better or > 2) are they instead stark differences in philosophy and underlying > architecture in accessing the PyObjC Bridge which will stay diverged > with one eventually obviating the other? Cocoa bindings are a method for reducing the amount of code you have to write in your controller layer in a MVC design. PyObjC fully supports this, and there are even examples that show you how. The major disadvantage of bindings is that this makes it harder to how a program works, you can't just print out source code and find a quiet space to digest it but part of you logic will be in the nib file. But the big advantage of bindings is that you'll have to write less code, and hence have less change to make bugs. I'd say the advantage is larger than the disadvantage. However, if I were new to Cocoa I'd start by ignoring bindings because that makes it easier to get a feel of framework. > > The advantage of the Apple-documented way is that I can use Xcode for > building the application which is very convenient and consistent but > I don't really 'get' the Binding tab just yet since I would think > that it would show the bindings I make the traditional way with the > Control-click graphic connections if the underlying architecture is > consistent--and it doesn't. So they seem mutually exclusive and not > consistent in Xcode. That worries me frankly--it makes them both seem > more like hacks. It seems to be one way or another. > > I find this 'schizophenic' approach to development tools unsettling > and it concerns me that I risk very fast obsolescence of my work if I > pick the wrong build approach. Or worse: that both methods are just > temporary and will disappear capriciously one OS revision without > warning.So it begs the question: which method will be the 'main- > stream' recommendation going forward? The SourceForge team is clearly > a standard-setter but then again Apple has 'vendor power' when it > comes to Cocoa and Objective-C. The Apple way is far better > integrated with Xcode but seems strained and awkward when creating > the outlets and actions because it doesn't use the 'standard' that > Objective-C/Cocoa projects use and all the Cocoa tutorials use.. Bindings are the way forward, but build on the older behaviour. There is little change that the older behaviour will go away. > > Or am I just confused because Cocoa and the Apple Tools is fairly > opaque to me at this point? Ronald > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/79a05bd5/attachment.bin From ronaldoussoren at mac.com Fri Feb 3 19:37:29 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 3 Feb 2006 19:37:29 +0100 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <42BCEBF4-6EF5-4128-AD5F-84EC65174085@redivi.com> References: <42BCEBF4-6EF5-4128-AD5F-84EC65174085@redivi.com> Message-ID: On 3-feb-2006, at 18:09, Bob Ippolito wrote: > > On Feb 3, 2006, at 8:57 AM, Andrew Jaffe wrote: > >> I originally posted this in a different thread, but I realize that >> the >> first post was about 10 levels deep, so possibly ignored by people >> who >> might care or be able to help (or possibly just ignored as a dumb >> question). Anyway, is there a 'best' way to install python packages >> on a >> mac nowadays? It seems that there at least three possibilities: >> >> - plain old setup.py install >> - bdist_mpkg >> - eggs (in which case I realize I'm not sure I know exactly >> *how* to >> do this) >> >> I've been using bdist_mpkg a lot recently, but this discussion is >> making >> me think it may not the preferred way. Any opinions? (There was one >> answer in favor of plain-old setup.py install.) > > Whichever one works. > > setup.py install works for everything, but you might need to specify > --install-scripts in order to make the scripts get installed to a > useful location. bdist_mpkg does that for you. Depends on what you find a useful location :-). I've used my unix-fu to add the bin directory inside the python framework to my PATH. That way my python stuf is nicely in one place and I don't have to worry about 'python2.3 setup.py install' replacing files I had earlier installed using python2.4. > > Some packages are dumb and don't really use distutils, like Twisted, > so bdist_mpkg doesn't work everywhere. > > setuptools is a bit more sensitive to distutils abuse and definitely > doesn't like Twisted, but also doesn't like some other packages like > Zope.Interface (IIRC). If you want to learn more about setuptools > from a user's perspective, read the EasyInstall documentation. If > you want to learn about it from a developer's perspective, read the > setuptools and PkgResources documentation. > > http://peak.telecommunity.com/DevCenter/EasyInstall > http://peak.telecommunity.com/DevCenter/setuptools > http://peak.telecommunity.com/DevCenter/PkgResources > > Personally, I've been using setuptools for everything lately because > it deals with a few issues like dependencies and development > builds. It's not yet ready for everyone all the time, but it's > clearly the future. +1 Ronald > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/086e1844/attachment.bin From bob at redivi.com Fri Feb 3 19:43:48 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 10:43:48 -0800 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <43E399EB.9060806@noaa.gov> References: <43E399EB.9060806@noaa.gov> Message-ID: <3FFA3B76-A03C-48CA-B9AE-54BCD523744D@redivi.com> On Feb 3, 2006, at 9:59 AM, Christopher Barker wrote: > Andrew Jaffe wrote: >> Anyway, is there a 'best' way to install python packages on a >> mac nowadays? It seems that there at least three possibilities: >> >> - plain old setup.py install >> - bdist_mpkg >> - eggs (in which case I realize I'm not sure I know exactly >> *how* to >> do this) > > The "Best" way to install packages is to use whatever form you get. If > you get an egg, use easy-install, if you get a mpkg, point and > click it, > if you the source, use setup.py. easy_install will also download, compile, and install (as an egg) many source distributions for you, whether or not it's an egg. If the package happens to use setuptools, it'll also find download, compile, and install any dependencies it needs. This of course isn't so easy for a very select few packages (Twisted and Zope.Interface in my experience so far), and it's not as useful for packages that are not yet registered on Cheese Shop (PyPI) > I'm not just being glib here. I wonder if you, in fact, are asking a > larger question, which it would be nice to discuss here: > > What is the best way to distribute packages? Now you have to consider > the three options above: > > 1) Just distribute the source with a setup.py You're always doing this anyway, whether or not you use setuptools or if you provide binary packages of some kind (egg, mpkg, etc.). > 2) Use bdist_mpkg to build a mpkg This makes sense if you have to install other junk that doesn't live in site-packages (other than scripts), like examples, documentation, etc. For packages that have big dependency graphs, bdist_mpkg can be a chore because you have to instruct your users to install a bunch of other junk first (e.g. pygame users should also be downloading and installing four or five other packages). > 3) Build an egg. > > The reason I make this distinction is that if you are getting just the > source from a package maintainer, there is little reason to go though > the trouble of making mpkgs or eggs, if you only want to install it on > your own machine. slight modification to that: Building eggs and uploading them to Cheese Shop is absolutely trivial. Do it. > The is no reason to make a mpkg. > > You might want to make an egg, so that you can get the versioning > control eggs give you (and some other features, but versioning control > is the big one) However, if it's just for your purposes, and the > package > maintainer hasn't set up setup.py to build and egg, it's probably not > worth it. Is this hard? python -c "import setuptools; execfile('setup.py')" bdist_egg > That being said, I would love it if EVERYONE that downloads and > builds a > source package on their Mac would contribute a binary package to the > community. Mac users like binary packages! > > I suggest the following for making a package that can be distributed: > > - Make an egg. > - If you can't figure out how to make an egg, use bdist_mpkg > - I think Bob is working on making py2app support eggs with > bdist_mpkg, > so that may get easy. The next version(s) of py2app, bdist_mpkg, etc. are going to be separate software packages. setuptools makes this reasonable to do. I'm not going to release any updates to any of that suite until they are usable with eggs. > However, keep in mind that when you make a binary package, it will > only > work (reliably) with the version of Python that you build it with. I > think the versions we should support are: > > Bob's "official unofficial" 2.4.1 framework build for 10.3 (this will > run on 10.4 also) > > 2.4.1 framework build for 10.4 Note that ActivePython 2.4.2 is equivalent to the 2.4.1 framework build for 10.3. The only difference is that ActivePython doesn't ship with a working bsddb or readline (bzip2 and curses may also be broken with older builds of ActivePython 2.4.2). There will soon be a Python 2.4.2 (really more like 2.4.3, since it has many significant patches) build for Mac OS X that is fat (i386 ppc). Ronald and I are working out the issues with that. It is very difficult to have two different Python 2.4 installations at the same time though, but Ronald says he has some patches that allow the 10.4 build to run on 10.3.9, so maybe that's Good Enough to be the one and only distro to support. > There's something to be said for supporting Apple's pythons but I > think > that's lower priority. Don't bother, especially not if you care about i386. Python 2.3 is on its way out, and Mac OS X 10.5 is on its way in.. I'd expect that Mac OS X 10.5 will include Python 2.4.3 (or 2.4.2+all of our universal build patches) anyway. Supporting Apple's Python is a losing battle because you lose both backwards and forwards compatibility. Backwards compatibility is gone or at least prohibitively difficult because they're always going to build with the latest MACOSX_DEPLOYMENT_TARGET and forwards compatibility is fragile at best because they can change the Python minor (minor as in 2.X) version at any major OS upgrade and break anything that you have done. They also have a habit of doing a crummy job of testing it and they never upgrade except during major OS upgrades. > And these packages should be put up on pythonmac.org > > One other note: > > The Framework builds put the "bin" directory inside the Framework. > That's where scripts get installed by default. What that means is that > in order to use them, the user needs to add that directory to their > PATH. This isn't a big deal, but it reminds me too much of the old DOS > days, where you needed to add something to your PATH for every darn > piece of software you installed. I much prefer the *nix standard of > having a few locations where executables get installed, and I's > like to > see the default scripts directory be /use/local/bin. > > Should this be the standard? How could we accomplish that? Or > should we > just tell people to add the Framework bin directory to their PATH. Personally I have a ~/.pydistutils.cfg that looks like this: [install] install_lib = ~/Library/Python/$py_version_short/site-packages install_scripts = ~/bin/py$py_version_short and of course ~/bin/py2.4 is in my PATH. Some people might prefer an install_scripts = /usr/local/bin -- but then they'll need sudo to install stuff. bdist_mpkg chooses /usr/ local/bin as the default, since the "sudo" is provided easily by Installer.app's authorization facility. -bob From ronaldoussoren at mac.com Fri Feb 3 19:50:03 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 3 Feb 2006 19:50:03 +0100 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <43E399EB.9060806@noaa.gov> References: <43E399EB.9060806@noaa.gov> Message-ID: On 3-feb-2006, at 18:59, Christopher Barker wrote: > Andrew Jaffe wrote: >> Anyway, is there a 'best' way to install python packages on a >> mac nowadays? It seems that there at least three possibilities: >> >> - plain old setup.py install >> - bdist_mpkg >> - eggs (in which case I realize I'm not sure I know exactly >> *how* to >> do this) > > The "Best" way to install packages is to use whatever form you get. If > you get an egg, use easy-install, if you get a mpkg, point and > click it, > if you the source, use setup.py. > > I'm not just being glib here. I wonder if you, in fact, are asking a > larger question, which it would be nice to discuss here: > > What is the best way to distribute packages? Now you have to consider > the three options above: > > 1) Just distribute the source with a setup.py > 2) Use bdist_mpkg to build a mpkg > 3) Build and egg. > > The reason I make this distinction is that if you are getting just the > source from a package maintainer, there is little reason to go though > the trouble of making mpkgs or eggs, if you only want to install it on > your own machine. slight modification to that: > > The is no reason to make a mpkg. > > You might want to make an egg, so that you can get the versioning > control eggs give you (and some other features, but versioning control > is the big one) However, if it's just for your purposes, and the > package > maintainer hasn't set up setup.py to build and egg, it's probably not > worth it. Even more important that versioning is that eggs give you an easy way to uninstall software (although I'm not quite sure about scripts). The normal distutils makes it very hard to uninstall some packages because they install multiple toplevel packages and it is not always immediately obvious which files they install. > > That being said, I would love it if EVERYONE that downloads and > builds a > source package on their Mac would contribute a binary package to the > community. Mac users like binary packages! > > I suggest the following for making a package that can be distributed: > > - Make an egg. > - If you can't figure out how to make an ebb, use bdist_mpkg > - I think Bob is working on making py2app support eggs with > bdist_mpkg, > so that may get easy. > > However, keep in mind that when you make a binary package, it will > only > work (reliably) with the version of Python that you build it with. I > think the versions we should support are: > > Bob's "official unofficial" 2.4.1 framework build for 10.3 (this will > run on 10.4 also) > > 2.4.1 framework build for 10.4 Don't. There should be only one binary installation of Python 2.4.x for every x and than one should work on 10.3 and 10.4. This makes live a lot easier for causual users. > > There's something to be said for supporting Apple's pythons but I > think > that's lower priority. > > And these packages should be put up on pythonmac.org > > One other note: > > The Framework builds put the "bin" directory inside the Framework. > That's where scripts get installed by default. What that means is that > in order to use them, the user needs to add that directory to their > PATH. This isn't a big deal, but it reminds me too much of the old DOS > days, where you needed to add something to your PATH for every darn > piece of software you installed. I much prefer the *nix standard of > having a few locations where executables get installed, and I's > like to > see the default scripts directory be /use/local/bin. BTW. modern unix systems assume that additional software will bin installed in directories below /opt, such as /opt/python2.4, /opt/gnome, .... I'd prefer /Library/Python/2.x/bin as the directory where scripts get placed because that directory is easily visible in the Finder and allows you to install software for both python2.3 and python2.4. I regularly do that to make it easier to install software using older versions of python. > > Should this be the standard? How could we accomplish that? Or > should we > just tell people to add the Framework bin directory to their PATH. The bin directory inside the framework is a bit to hidden for most users and hard to get to using the Finder. > > Mostly I feel strongly that, as a community, we need to establish > standard ways of doing Python on OS-X, and publish them somewhere. I'm > not picky about what those standards are, as long as they exist. I'll defer to any standard once it is here :-). Feel free to write a proposal about a standard, including what needs to be done to get there ;-) Off to hack on another universal python build, Ronald > > -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/69a3709c/attachment-0001.bin From ronaldoussoren at mac.com Fri Feb 3 19:52:36 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 3 Feb 2006 19:52:36 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> Message-ID: <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> On 3-feb-2006, at 5:23, Bob Ippolito wrote: > It fixes a couple of the endian issues in the Mac modules > (platform.mac_ver, applesingle, gestalt, and the OSType converter > functions) How do you convert four character codes? Is 'abcd' big endian or platform-native? Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/c3137637/attachment.bin From ronaldoussoren at mac.com Fri Feb 3 19:59:16 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 3 Feb 2006 19:59:16 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <21675E32-8217-41F1-B5BC-0B54EC54D6D3@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> <1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com> <21675E32-8217-41F1-B5BC-0B54EC54D6D3@redivi.com> Message-ID: <689F3805-E73A-405F-89F9-6C1318090335@mac.com> On 3-feb-2006, at 18:28, Bob Ippolito wrote: > On Jan 27, 2006, at 12:19 AM, Ronald Oussoren wrote: > >> >> On 27-jan-2006, at 8:46, Kevin Ollivier wrote: >> >>> On Jan 26, 2006, at 10:55 PM, Bob Ippolito wrote: >>> >>>> Some extensions aren't going to build cleanly universal, and >>>> most users probably aren't going to have all the SDKs installed >>>> so if it shipped with universal flags then it wouldn't be able >>>> to build extensions. >>> >>> Unless we had distutils check for the existence of the Universal >>> SDK before setting the flags, or probably more accurately, remove >>> them if the SDK isn't available. Then perhaps add a distutils >>> 'flag' to manually turn off Universal building for extensions >>> that can't be fixed. This might be a bit of a hack, but I don't >>> imagine it would be too painful. The question is how many >>> extensions would have troubles... But I guess the only way we'll >>> know is to test the waters. In any case, even if it wouldn't be >>> reasonable to make a Universal build the "official" build, it >>> would be very useful to people packaging apps, even if it were >>> Tiger+ only. >> >> I know of one popular extension (cElementTree) that won't build >> with '-arch i386 -arch ppc' because it calcutes a #define based on >> the current byte-order. There might be others, I haven't done a >> thorough search yet. > > In my python24-fat branch, I made the following change to > pyconfig.h.in which I believe will resolve that issue in any > extension that doesn't do something dumb like trying to grep the > endianness out of pyconfig.h: > > http://svn.red-bean.com/bob/python24-fat/pyconfig.h.in > > /* Define to 1 if your processor stores words with the most > significant byte > first (like Motorola and SPARC, unlike Intel and VAX). */ > #ifdef __BIG_ENDIAN__ > #define WORDS_BIGENDIAN 1 > #else > #ifndef __LITTLE_ENDIAN__ > #undef WORDS_BIGENDIAN > #endif > #endif > > GCC defines __BIG_ENDIAN__ to 1 when it's compiling a big endian > arch... and __LITTLE_ENDIAN__ to 1 when it's compiling on a little > endian arch. Configured on i386, this turns into: > > #ifdef __BIG_ENDIAN__ > #define WORD_BIGENDIAN 1 > #else > #ifndef __LITTLE_ENDIAN__ > /* #undef WORDS_BIGENDIAN */ > #endif > #endif > > When configured on PPC, it turns into: > > #ifdef __BIG_ENDIAN__ > #define WORD_BIGENDIAN 1 > #else > #ifndef __LITTLE_ENDIAN__ > #define WORDS_BIGENDIAN 1 > #endif > #endif > > Since this is GCC, the #ifndef __LITTLE_ENDIAN__ branch is always > false... so I'm making this a compile-time not configure-time > value, but I left in the configure-time stuff for other platforms. Did you test this? I'd be surprised if distutils honours the ifdef statement. Luckily the easiest way to find the byteorder is sys.byteorder. I have a patched version of pyconfig.h that #includes "macosx- config.h" at the end. This file redefines a number of values based on the cpu-type. Anyone that grabs CPU information from pyconfig.h will get the values from the platform that was used to generate pyconfig.h (an intel system in my case). I like your trick better, mine is a bit too elaborate and not needed until someone wants to do a ppc64 build. Ronald > > -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/0b18bf30/attachment.bin From bob at redivi.com Fri Feb 3 20:00:52 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 11:00:52 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> Message-ID: <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> On Feb 3, 2006, at 10:52 AM, Ronald Oussoren wrote: > > On 3-feb-2006, at 5:23, Bob Ippolito wrote: > >> It fixes a couple of the endian issues in the Mac modules >> (platform.mac_ver, applesingle, gestalt, and the OSType converter >> functions) > > How do you convert four character codes? Is 'abcd' big endian or > platform-native? 'abcd' is platform endian. See http://svn.red-bean.com/bob/python24-fat/Python/mactoolboxglue.c /* Convert a 4-char string object argument to an OSType value */ int PyMac_GetOSType(PyObject *v, OSType *pr) { uint32_t tmp; if (!PyString_Check(v) || PyString_Size(v) != 4) { PyErr_SetString(PyExc_TypeError, "OSType arg must be string of 4 chars"); return 0; } memcpy((char *)&tmp, PyString_AsString(v), 4); *pr = (OSType)ntohl(tmp); return 1; } /* Convert an OSType value to a 4-char string object */ PyObject * PyMac_BuildOSType(OSType t) { uint32_t tmp = htonl((uint32_t)t); return PyString_FromStringAndSize((char *)&tmp, 4); } -bob From ronaldoussoren at mac.com Fri Feb 3 20:01:25 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 3 Feb 2006 20:01:25 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> Message-ID: On 3-feb-2006, at 20:00, Bob Ippolito wrote: > > On Feb 3, 2006, at 10:52 AM, Ronald Oussoren wrote: > >> >> On 3-feb-2006, at 5:23, Bob Ippolito wrote: >> >>> It fixes a couple of the endian issues in the Mac modules >>> (platform.mac_ver, applesingle, gestalt, and the OSType converter >>> functions) >> >> How do you convert four character codes? Is 'abcd' big endian or >> platform-native? > > 'abcd' is platform endian. Fine by me. Either choice seems to be defendable that why I asked. BTW. I know next to nothing about SVK, can I use an ordinary subversion client to fetch files from your repository? Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/840ad6c2/attachment.bin From bob at redivi.com Fri Feb 3 20:41:10 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 11:41:10 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> Message-ID: <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> On Feb 3, 2006, at 11:01 AM, Ronald Oussoren wrote: > > On 3-feb-2006, at 20:00, Bob Ippolito wrote: > >> >> On Feb 3, 2006, at 10:52 AM, Ronald Oussoren wrote: >> >>> >>> On 3-feb-2006, at 5:23, Bob Ippolito wrote: >>> >>>> It fixes a couple of the endian issues in the Mac modules >>>> (platform.mac_ver, applesingle, gestalt, and the OSType >>>> converter functions) >>> >>> How do you convert four character codes? Is 'abcd' big endian or >>> platform-native? >> >> 'abcd' is platform endian. > > Fine by me. Either choice seems to be defendable that why I asked. > > BTW. I know next to nothing about SVK, can I use an ordinary > subversion client to fetch files from your repository? Yes, it works fine, the repo is just a subversion repo. svk does all its magic in a few svn properties (keeping track of merge history basically). The advantage that SVK has in cases like this is that I can create a branch of python24-maint without using the svn.python.org repo directly and then have the capability to merge changes one way or another, while still using svn repositories. -bob From bob at redivi.com Fri Feb 3 20:51:52 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 11:51:52 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <689F3805-E73A-405F-89F9-6C1318090335@mac.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> <1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com> <21675E32-8217-41F1-B5BC-0B54EC54D6D3@redivi.com> <689F3805-E73A-405F-89F9-6C1318090335@mac.com> Message-ID: On Feb 3, 2006, at 10:59 AM, Ronald Oussoren wrote: > > On 3-feb-2006, at 18:28, Bob Ippolito wrote: > >> On Jan 27, 2006, at 12:19 AM, Ronald Oussoren wrote: >> >>> >>> On 27-jan-2006, at 8:46, Kevin Ollivier wrote: >>> >>>> On Jan 26, 2006, at 10:55 PM, Bob Ippolito wrote: >>>> >>>>> Some extensions aren't going to build cleanly universal, and >>>>> most users probably aren't going to have all the SDKs installed >>>>> so if it shipped with universal flags then it wouldn't be able >>>>> to build extensions. >>>> >>>> Unless we had distutils check for the existence of the Universal >>>> SDK before setting the flags, or probably more accurately, >>>> remove them if the SDK isn't available. Then perhaps add a >>>> distutils 'flag' to manually turn off Universal building for >>>> extensions that can't be fixed. This might be a bit of a hack, >>>> but I don't imagine it would be too painful. The question is how >>>> many extensions would have troubles... But I guess the only way >>>> we'll know is to test the waters. In any case, even if it >>>> wouldn't be reasonable to make a Universal build the "official" >>>> build, it would be very useful to people packaging apps, even if >>>> it were Tiger+ only. >>> >>> I know of one popular extension (cElementTree) that won't build >>> with '-arch i386 -arch ppc' because it calcutes a #define based >>> on the current byte-order. There might be others, I haven't done >>> a thorough search yet. >> >> In my python24-fat branch, I made the following change to >> pyconfig.h.in which I believe will resolve that issue in any >> extension that doesn't do something dumb like trying to grep the >> endianness out of pyconfig.h: >> >> http://svn.red-bean.com/bob/python24-fat/pyconfig.h.in >> >> /* Define to 1 if your processor stores words with the most >> significant byte >> first (like Motorola and SPARC, unlike Intel and VAX). */ >> #ifdef __BIG_ENDIAN__ >> #define WORDS_BIGENDIAN 1 >> #else >> #ifndef __LITTLE_ENDIAN__ >> #undef WORDS_BIGENDIAN >> #endif >> #endif >> >> GCC defines __BIG_ENDIAN__ to 1 when it's compiling a big endian >> arch... and __LITTLE_ENDIAN__ to 1 when it's compiling on a little >> endian arch. Configured on i386, this turns into: >> >> #ifdef __BIG_ENDIAN__ >> #define WORD_BIGENDIAN 1 >> #else >> #ifndef __LITTLE_ENDIAN__ >> /* #undef WORDS_BIGENDIAN */ >> #endif >> #endif >> >> When configured on PPC, it turns into: >> >> #ifdef __BIG_ENDIAN__ >> #define WORD_BIGENDIAN 1 >> #else >> #ifndef __LITTLE_ENDIAN__ >> #define WORDS_BIGENDIAN 1 >> #endif >> #endif >> >> Since this is GCC, the #ifndef __LITTLE_ENDIAN__ branch is always >> false... so I'm making this a compile-time not configure-time >> value, but I left in the configure-time stuff for other platforms. > > Did you test this? I'd be surprised if distutils honours the ifdef > statement. Luckily the easiest way to find the byteorder is > sys.byteorder. Yes, I ran the test suite on PPC with a PPC-built build and on i386 with and without Rosetta on a i386 build... I didn't test the PPC- built version on an i386, but I'm going to assume it works for now since the two possible outputs above are logically equivalent. distutils does know how to parse and find pyconfig.h (sysconfig.parse_config_h, get_config_h_filename), but Python itself only uses that functionality in the main setup.py. Surprisingly, the main setup.py parses pyconfig.h twice (once with distutils, once without -- good job there), but it of course doesn't go anywhere near WORDS_BIGENDIAN. Packages that use WORDS_BIGENDIAN from distutils are broken. There's nothing we can do to fix that short of patching the package. Fortunately I don't think any package is dumb enough to do that. Packages that do something with sys.byteorder at setup.py time are probably going to be broken also... but I've never seen that either. > I have a patched version of pyconfig.h that #includes "macosx- > config.h" at the end. This file redefines a number of values based > on the cpu-type. Anyone that grabs CPU information from pyconfig.h > will get the values from the platform that was used to generate > pyconfig.h (an intel system in my case). I like your trick better, > mine is a bit too elaborate and not needed until someone wants to > do a ppc64 build. sys.byteorder is actually determined at runtime: unsigned long number = 1; char *value; s = (char *) &number; if (s[0] == 0) value = "big"; else value = "little"; PyDict_SetItemString(sysdict, "byteorder", v = PyString_FromString(value)); Py_XDECREF(v); -bob From bob at redivi.com Fri Feb 3 21:10:57 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 12:10:57 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> Message-ID: <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> On Feb 3, 2006, at 11:41 AM, Bob Ippolito wrote: > > On Feb 3, 2006, at 11:01 AM, Ronald Oussoren wrote: > >> >> On 3-feb-2006, at 20:00, Bob Ippolito wrote: >> >>> >>> On Feb 3, 2006, at 10:52 AM, Ronald Oussoren wrote: >>> >>>> >>>> On 3-feb-2006, at 5:23, Bob Ippolito wrote: >>>> >>>>> It fixes a couple of the endian issues in the Mac modules >>>>> (platform.mac_ver, applesingle, gestalt, and the OSType >>>>> converter functions) >>>> >>>> How do you convert four character codes? Is 'abcd' big endian or >>>> platform-native? >>> >>> 'abcd' is platform endian. >> >> Fine by me. Either choice seems to be defendable that why I asked. >> >> BTW. I know next to nothing about SVK, can I use an ordinary >> subversion client to fetch files from your repository? > > Yes, it works fine, the repo is just a subversion repo. svk does all > its magic in a few svn properties (keeping track of merge history > basically). > > The advantage that SVK has in cases like this is that I can create a > branch of python24-maint without using the svn.python.org repo > directly and then have the capability to merge changes one way or > another, while still using svn repositories. I think the only things missing from my branch currently are: 1) 10.3.9 support 2) Universal PythonLauncher 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that in Python and not hardcode everything) I'll probably take the pbproj out of PythonLauncher and just build it with the Makefile since it can inherit the right build flags and such that way. In other words, this seems to work correctly universally: $ mkdir _build $ cd _build $ ../configure --enable-framework --enable-universalsdk && make $ sudo make frameworkinstall The only backwards incompatible change (beyond missing WASTE, PythonIDE, PackageManager) that I'm aware of is the distutils.util.get_platform string: it no longer says darwin, it says macosx-{ver}-{arch} where ver is the major.minor version of Mac OS X (not the damned kernel) and arch is either fat (universal is too long), ppc, i386, or whatever falls through from the uname. And of course, if you're using the universal build, you'll need the 10.4u SDK installed to compile any extensions. This backwards incompatible change is mostly just a backport from setuptools' pkg_resources module. $ python -c "from distutils.util import get_platform as p; print p()" macosx-10.4.3-fat First and foremost this change fixes running-Python-in-the-build- directory-with-Rosetta, but the secondary benefit is that this metadata will show up in Cheese Shop if you build an egg with a universal Python. Thus, this universal python will create fat eggs and will have a proclivity for fat eggs. The potential issue here is that it might refuse to use single-arch eggs, which I don't see as much of a problem really. If it didn't change the arch name to "fat" then you wouldn't be able to tell universal and single-arch eggs apart. -bob From w.northcott at unsw.edu.au Fri Feb 3 21:13:07 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Sat, 4 Feb 2006 07:13:07 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> Message-ID: On 04/02/2006, at 3:52 AM, Kevin Ollivier wrote: >> So I added more alternative conditions to wx/string.h:46 thus: >> #if defined(HAVE_STRCASECMP_IN_STRINGS_H) || _POSIX_C_SOURCE == >> 200112L || _XOPEN_SOURCE == 600 >> >> This definitely works on MacOS X 10.4 and I don't see how it can >> break on other systems. > > Out of curiosity, was there a problem with just doing defined > (_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE) tests? Are these always > guaranteed to be set to those values? As I read the Opengroup document, Posix 200112L and Xopen 600 have been converged. Older standards would not be the same and certainly older versions of Xopen might have strcasecmp and friends in string.h. OTOH higher versions are undefined. So it would not be right to assume the code should work under them. That was my take but it may be quite wrong. >> >> PS I still have the issue from my other posting which Adriano >> posted in September. > > Could you give me a thread to look up so that I can follow up? There never was a thread because nobody replied to the original message. The extract listed the errors other than those due to the strings.h/string.h issue. Let me poke about on this some more. The missing declarations in fp.h are conditional on #if (!defined(__MWERKS__) || !defined(__cmath__)) && (! TARGET_RT_MAC_MACHO || !defined(__MATH__)) So maybe cmath has been included but failed to provide all the required symbols. Cheers Bill From jeremy.kloth at fourthought.com Fri Feb 3 21:05:32 2006 From: jeremy.kloth at fourthought.com (Jeremy Kloth) Date: Fri, 3 Feb 2006 13:05:32 -0700 Subject: [Pythonmac-SIG] building universal binaries References: <20060125004922.GF10062@activestate.com><43D712E7.4080601@code-bear.com><50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com><43D7CB4D.1010903@code-bear.com><5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com><43D802D5.10709@code-bear.com><43D80DF9.7000707@code-bear.com><09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com><5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com><1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com><21675E32-8217-41F1-B5BC-0B54EC54D6D3@redivi.com><689F3805-E73A-405F-89F9-6C1318090335@mac.com> Message-ID: <02ae01c628fd$300e2c70$f301a8c0@hades> On Friday, February 03, 2006 12:51 PM, Bob Ippolito wrote: > Packages that do something with sys.byteorder at setup.py time are > probably going to be broken also... but I've never seen that either. Any package that wraps Expat will probably be using sys.byteorder as Expat needs to know the byte order at compile time for its UTF-16 functionality. Packages that I know about are PyXML, cElementTree and 4Suite. -- Jeremy Kloth http://fourthought.com/ http://4suite.org/ From bob at redivi.com Fri Feb 3 22:29:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 13:29:34 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <02ae01c628fd$300e2c70$f301a8c0@hades> References: <20060125004922.GF10062@activestate.com><43D712E7.4080601@code-bear.com><50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com><43D7CB4D.1010903@code-bear.com><5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com><43D802D5.10709@code-bear.com><43D80DF9.7000707@code-bear.com><09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com><5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com><1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com><21675E32-8217-41F1-B5BC-0B54EC54D6D3@redivi.com><689F3805-E73A-405F-89F9-6C1318090335@mac.com> <02ae01c628fd$300e2c70$f301a8c0@hades> Message-ID: <6733DB39-C710-4AB8-840C-927A480F94E5@redivi.com> On Feb 3, 2006, at 12:05 PM, Jeremy Kloth wrote: > On Friday, February 03, 2006 12:51 PM, Bob Ippolito wrote: >> Packages that do something with sys.byteorder at setup.py time are >> probably going to be broken also... but I've never seen that either. > > Any package that wraps Expat will probably be using sys.byteorder > as Expat > needs to know the byte order at compile time for its UTF-16 > functionality. > Packages that I know about are PyXML, cElementTree and 4Suite. Ok, then they're all broken. They need to use the C preprocessor, not setup.py, to determine byteorder. Something like this (not yet tested) should work for cElementTree, for example: === cElementTree.c ================================================================== --- cElementTree.c (revision 54) +++ cElementTree.c (local) @@ -33,6 +33,7 @@ * 2005-08-11 fl added runtime test for copy workaround (1.0.3) * 2005-12-13 fl added expat_capi support (for xml.etree) (1.0.4) * 2005-12-16 fl added support for non-standard encodings + * 2006-02-03 bi determine endian from Python.h, not sys.byteorder * * Copyright (c) 1999-2005 by Secret Labs AB. All rights reserved. * Copyright (c) 1999-2005 by Fredrik Lundh. === setup.py ================================================================== --- setup.py (revision 54) +++ setup.py (local) @@ -49,10 +49,7 @@ defines.append((feature_macro, "1")) defines.append(("XML_NS", "1")) defines.append(("XML_DTD", "1")) - if sys.byteorder == "little": - defines.append(("BYTEORDER", "1234")) - else: - defines.append(("BYTEORDER", "4321")) + defines.append(("HAVE_EXPAT_CONFIG_H", "1")) defines.append(("XML_CONTEXT_BYTES", "1024")) === expat_config.h ================================================================== --- expat_config.h (revision 54) +++ expat_config.h (local) @@ -0,0 +1,9 @@ +#include "Python.h" +#ifdef BYTEORDER +#undef BYTEORDER +#endif +#ifdef WORDS_BIGENDIAN +#define BYTEORDER 4321 +#else +#define BYTEORDER 1234 +#endif -bob From bob at redivi.com Fri Feb 3 23:04:16 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 14:04:16 -0800 Subject: [Pythonmac-SIG] cElementTree 1.0.5 and expat byte order Message-ID: <0E137788-C282-4BC0-B3DE-5C4DFC9F22E1@redivi.com> The method that cElementTree uses to determine byte order is not reliable on some platforms such as Mac OS X or Darwin where you may be compiling for multiple architectures at the same time (in my particular case, i386 and ppc). The best way to determine byte order is either at runtime or from the C preprocessor. Attached is a patch for cElementTree that determines expat's byteorder from Python.h on platforms other than Windows and Mac OS Classic. It also adds a test that should exercise expat's capability to read UTF-16 streams. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: cElementTree-1.0.5-byteorder.patch Type: application/octet-stream Size: 1953 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/dd07ec37/attachment-0001.obj From bob at redivi.com Fri Feb 3 23:30:23 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 14:30:23 -0800 Subject: [Pythonmac-SIG] PyXML 0.8.4 and expat byteorder Message-ID: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> Here's the PyXML patch that gets expat byteorder from pyconfig.h. I don't know who the maintainer is nor do I have any interest in subscribing to xml-sig (this CC will probably bounce, or get stuck in mod queue for days/weeks/forever). If you give a damn about PyXML please make sure to get the patch to the right person. I've never even installed the 4Suite stuff, so I'm not going to put together a patch for that. Such a patch should be roughly the same as this one. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: PyXML-0.8.4-byteorder.patch Type: application/octet-stream Size: 1002 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/ac81574d/attachment.obj -------------- next part -------------- From bear42 at code-bear.com Sat Feb 4 00:01:28 2006 From: bear42 at code-bear.com (bear) Date: Fri, 03 Feb 2006 18:01:28 -0500 Subject: [Pythonmac-SIG] PyXML 0.8.4 and expat byteorder In-Reply-To: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> References: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> Message-ID: <43E3E0C8.7080509@code-bear.com> I've taken the patch and submitted it to the PyXML sourceforge project and included a link to your mailing list archive entry for reference. http://sourceforge.net/tracker/index.php?func=detail&aid=1423775&group_id=6473&atid=306473 Bob Ippolito wrote: > Here's the PyXML patch that gets expat byteorder from pyconfig.h. I > don't know who the maintainer is nor do I have any interest in > subscribing to xml-sig (this CC will probably bounce, or get stuck in > mod queue for days/weeks/forever). If you give a damn about PyXML > please make sure to get the patch to the right person. From w.northcott at unsw.edu.au Sat Feb 4 00:57:43 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Sat, 4 Feb 2006 10:57:43 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> Message-ID: >> PS I still have the issue from my other posting which Adriano >> posted in September. > > Could you give me a thread to look up so that I can follow up? I spent a bit more time on this, but I have to quit now. The problem here is that if is included with _POSIX_C_SOURCE defined, the gamma(), rinttol() and roundtol() functions among others are not declared. wx/mac/private.h, which is included from helpers.cpp, includes . The carbon header eventually includes fp.h. The #ifdef on line 124 of fp.h prevents the declarations of gamma() etc being used from fp.h. Hence the errors: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict- prototypes -DSWIG_TYPE_TABLE=_wxPython_table -DHAVE_CONFIG_H - DWXP_USE_THREAD=1 -UNDEBUG -D__WXMAC__ -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -DNO_GCC_PRAGMA -Iinclude -Isrc -I/usr/local/lib/wx/ include/mac-ansi-release-2.6 -I/usr/local/include/wx-2.6 -I/Library/ Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/ helpers.cpp -o build/temp.darwin-8.4.0-Power_Macintosh-2.4/src/ helpers.o -O3 cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long double gammal (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2031: error: 'gamma' was not declared in this scope /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long int rinttoll (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2145: error: 'rinttol' was not declared in this scope /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long int roundtoll (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2183: error: 'roundtol' was not declared in this scope This leaves me with questions: Is the Carbon framework POSIX C compliant? I suspect that it is not. So how and where should _POSIX_C_SOURCE be undefined? If _POSIX_C_SOURCE is undefed does that bring back the strcasecmp issue? Cheers Bill From kevino at theolliviers.com Sat Feb 4 01:08:17 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 3 Feb 2006 16:08:17 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> Message-ID: <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> Hi Bill, On Feb 3, 2006, at 12:13 PM, Bill Northcott wrote: > On 04/02/2006, at 3:52 AM, Kevin Ollivier wrote: >>> So I added more alternative conditions to wx/string.h:46 thus: >>> #if defined(HAVE_STRCASECMP_IN_STRINGS_H) || _POSIX_C_SOURCE == >>> 200112L || _XOPEN_SOURCE == 600 >>> >>> This definitely works on MacOS X 10.4 and I don't see how it can >>> break on other systems. >> >> Out of curiosity, was there a problem with just doing defined >> (_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE) tests? Are these >> always guaranteed to be set to those values? > > As I read the Opengroup document, Posix 200112L and Xopen 600 have > been converged. Older standards would not be the same and > certainly older versions of Xopen might have strcasecmp and friends > in string.h. OTOH higher versions are undefined. So it would not > be right to assume the code should work under them. That was my > take but it may be quite wrong. My concern is that while you're right that we can't assume that the code should work for new versions, neither can we assume it won't, so I'd prefer a solution that is guaranteed to work even if these values change. IMHO, even if we need to write a OS X-only configure test to properly set HAVE_STRCASECMP_IN_STRING_H, I'd rather go that route, because strings.h handles both scenarios (with or without the define) correctly and likely will continue to do so in the future. Thanks, Kevin From Chris.Barker at noaa.gov Sat Feb 4 01:21:08 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 03 Feb 2006 16:21:08 -0800 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: References: <43E399EB.9060806@noaa.gov> Message-ID: <43E3F374.7050508@noaa.gov> Ronald Oussoren wrote: > Even more important that versioning is that eggs give you an easy way > to uninstall software (although I'm not quite sure about scripts). It really does look like eggs are the way of the future. >> Bob's "official unofficial" 2.4.1 framework build for 10.3 (this will >> run on 10.4 also) >> >> 2.4.1 framework build for 10.4 > > Don't. There should be only one binary installation of Python 2.4.x for > every x and than one should work on 10.3 and 10.4. OK. However, if I understand it, if I am running 10.4, I can run a python and extensions that were built on and for 10.3. However, if I build an extension on 10.4, it may well not work on 10.3. What that means is that anyone building extensions on 10.4 can't contribute to the repository of packages for 10.3. However, you also can't run extensions built for a 10.3 python on a 10.4 python, which is why this is such a headache! For that matter, can I build extensions to a python built for 10.3 on 10.4 at all without trickery? I, and all my colleagues, are switching to 10.4 now (I just upgraded to day). I was just thinking I'd go 10.4 across the board, but now I think I may want to stick with a python built for 10.3, if for no other reason that to get wxPython working as easily as possible. > This makes life a lot easier for casual users. Good point. The "standard" approach is for casual users, those doing things like trying to build a universal binary python can do whatever they want! > I'd prefer /Library/Python/2.x/bin as the directory where scripts get > placed > because that directory is easily visible in the Finder and allows you to > install > software for both python2.3 and python2.4. So we need to tell people to add that to their PATH. > The bin directory inside the framework is a bit to hidden for most users > and hard to get to using the Finder. Maybe we could put a link from /Library/Python/2.x/bin to the bin directory in the Framework. That way, you wouldn't need to change the standard script dir. > I'll defer to any standard once it is here :-). Feel free to write a > proposal about a standard, including what needs to be done to get there ;-) OK, I'll get working on that, once I'm clear about all this 10.3 vs. 10.4 stuff. By the way, is there any advantage of the 10.4 build? One other thought: having all these different pythons and what not to support is a pain, but really, once you have the setup.py hacked so that it works right, it's no big deal to build a new package. What that means is that the real goal is to make sure that the patches required to build for OS-X get applied by the package maintainers. Then things will "just work" -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From kevino at theolliviers.com Sat Feb 4 01:22:58 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 3 Feb 2006 16:22:58 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> Message-ID: <6D0A4E85-EFBA-4F8C-83BE-000C111D7418@theolliviers.com> Hi Bill, On Feb 3, 2006, at 3:57 PM, Bill Northcott wrote: >>> PS I still have the issue from my other posting which Adriano >>> posted in September. >> >> Could you give me a thread to look up so that I can follow up? > > I spent a bit more time on this, but I have to quit now. > > The problem here is that if is included with > _POSIX_C_SOURCE defined, the gamma(), rinttol() and roundtol() > functions among others are not declared. wx/mac/private.h, which > is included from helpers.cpp, includes . The > carbon header eventually includes fp.h. The #ifdef on line 124 of > fp.h prevents the declarations of gamma() etc being used from > fp.h. Hence the errors: > > gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno- > fused-madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wall - > Wstrict-prototypes -DSWIG_TYPE_TABLE=_wxPython_table - > DHAVE_CONFIG_H -DWXP_USE_THREAD=1 -UNDEBUG -D__WXMAC__ - > D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA -Iinclude - > Isrc -I/usr/local/lib/wx/include/mac-ansi-release-2.6 -I/usr/local/ > include/wx-2.6 -I/Library/Frameworks/Python.framework/Versions/2.4/ > include/python2.4 -c src/helpers.cpp -o build/temp.darwin-8.4.0- > Power_Macintosh-2.4/src/helpers.o -O3 > cc1plus: warning: command line option "-Wstrict-prototypes" is > valid for C/ObjC but not for C++ > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h: In function 'long double gammal > (long double)': > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h:2031: error: 'gamma' was not > declared in this scope > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h: In function 'long int rinttoll > (long double)': > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h:2145: error: 'rinttol' was not > declared in this scope > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h: In function 'long int roundtoll > (long double)': > /System/Library/Frameworks/CoreServices.framework/Frameworks/ > CarbonCore.framework/Headers/fp.h:2183: error: 'roundtol' was not > declared in this scope > > This leaves me with questions: > Is the Carbon framework POSIX C compliant? > I suspect that it is not. So how and where should _POSIX_C_SOURCE > be undefined? I would suspect the right place is in the wx headers, probably in somewhere like setup.h. For the moment, could you write a hard-coded #undef _POSIX_C_SOURCE in your setup.h (or setup.h.in) and see if it resolves the matter? If so, it'll just be a matter of writing a proper test before undefining it, either in configure.in or setup.h.in. > If _POSIX_C_SOURCE is undefed does that bring back the strcasecmp > issue? So long as the undefine is done before string.h gets included in wx, this should actually be a very simple solution to the problem. Thanks, Kevin > Cheers > Bill > From Chris.Barker at noaa.gov Sat Feb 4 01:28:10 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 03 Feb 2006 16:28:10 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> Message-ID: <43E3F51A.9060206@noaa.gov> Guys, I'm a bit confused where the problem is here. I've just installed OS-X 10.4, and I'm trying to decide where to go with my python version. I was planning on going all 10.4, rather than using a python framework built for 10.3. However, I need wxPython, so I'm interested in this thread. Bill Northcott wrote: > I have been trying to build wxPython on Tiger (10.4.4 gcc--3.3/g77) > with some difficulty, which may just be me being dense. Is this only a problem with gcc 3.3? What about gcc 4.0? Why are you building with 3.3 on OS-X 10.4? Or should I just stick with the older python build and use Robin's binaries? thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From w.northcott at unsw.edu.au Sat Feb 4 01:33:11 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Sat, 4 Feb 2006 11:33:11 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> Message-ID: Hi Kevin On 04/02/2006, at 11:08 AM, Kevin Ollivier wrote: >> As I read the Opengroup document, Posix 200112L and Xopen 600 have >> been converged. Older standards would not be the same and >> certainly older versions of Xopen might have strcasecmp and >> friends in string.h. OTOH higher versions are undefined. So it >> would not be right to assume the code should work under them. >> That was my take but it may be quite wrong. > > My concern is that while you're right that we can't assume that the > code should work for new versions, neither can we assume it won't, > so I'd prefer a solution that is guaranteed to work even if these > values change. IMHO, even if we need to write a OS X-only configure > test to properly set HAVE_STRCASECMP_IN_STRING_H, I'd rather go > that route, because strings.h handles both scenarios (with or > without the define) correctly and likely will continue to do so in > the future. I quite agree that it would be best to have a solution guaranteed to work in the future. However, the standard makes it very clear that these sort of behaviours may change in the future. So it not possible to use something like _XOPEN_SOURCE >= 600 with any confidence. In any event, these standard revisions are not like program versions, because they change very infrequently. when you get a new standard the conditionals need to be checked. As for the autoconf test, IMO it is fundamentally flawed. I have checked out MacOS X, Tru64 and Solaris and in all cases the operative declaration of strcasecmp() is inside multiple #ifdefs. So it depends on what headers have been included first and in what order. Autoconf test programs need to be really simple and reliable, which means not having a long list of included headers. Unfortunately without such a list the test, as we see, is not discovering what was intended. I am at a loss to see how a simple valid test might be constructed, but that may be me being thick. My two penny worth Bill From w.northcott at unsw.edu.au Sat Feb 4 01:39:00 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Sat, 4 Feb 2006 11:39:00 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <43E3F51A.9060206@noaa.gov> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> Message-ID: <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> On 04/02/2006, at 11:28 AM, Christopher Barker wrote: > I'm a bit confused where the problem is here. I've just installed > OS-X 10.4, and I'm trying to decide where to go with my python > version. I was planning on going all 10.4, rather than using a > python framework built for 10.3. However, I need wxPython, so I'm > interested in this thread. > > Bill Northcott wrote: > > I have been trying to build wxPython on Tiger (10.4.4 gcc--3.3/g77) > > with some difficulty, which may just be me being dense. > > Is this only a problem with gcc 3.3? What about gcc 4.0? Why are > you building with 3.3 on OS-X 10.4? > > Or should I just stick with the older python build and use Robin's > binaries? MacOS X 10.4 Tiger includes Python 2.3.5 and wxPython. The issue only arises using Python 2.4.x on Tiger. It does not arise with Python 2.3.x on Tiger or Python 2.4.x on Panther (MacOS 10.3.x) As for using gcc-3.3 this is mainly because of the need for Fortran. gfortran while improving fast is still not production and g77 is not compatible with gcc-4. Bill From bob at redivi.com Sat Feb 4 01:54:13 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 16:54:13 -0800 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <43E3F374.7050508@noaa.gov> References: <43E399EB.9060806@noaa.gov> <43E3F374.7050508@noaa.gov> Message-ID: <54309EAF-F553-4718-8580-4E65A7EF4100@redivi.com> On Feb 3, 2006, at 4:21 PM, Christopher Barker wrote: > Ronald Oussoren wrote: >> Even more important that versioning is that eggs give you an easy way >> to uninstall software (although I'm not quite sure about scripts). > > It really does look like eggs are the way of the future. > >>> Bob's "official unofficial" 2.4.1 framework build for 10.3 (this >>> will >>> run on 10.4 also) >>> >>> 2.4.1 framework build for 10.4 >> >> Don't. There should be only one binary installation of Python >> 2.4.x for >> every x and than one should work on 10.3 and 10.4. > > OK. However, if I understand it, if I am running 10.4, I can run a > python and extensions that were built on and for 10.3. However, if I > build an extension on 10.4, it may well not work on 10.3. What that > means is that anyone building extensions on 10.4 can't contribute > to the > repository of packages for 10.3. However, you also can't run > extensions > built for a 10.3 python on a 10.4 python, which is why this is such a > headache! For that matter, can I build extensions to a python built > for > 10.3 on 10.4 at all without trickery? You're really confused here. > I, and all my colleagues, are switching to 10.4 now (I just > upgraded to > day). I was just thinking I'd go 10.4 across the board, but now I > think > I may want to stick with a python built for 10.3, if for no other > reason > that to get wxPython working as easily as possible. That's totally backwards... Chances are, for any given package, it will work best on the newest version of Python and OS X, because that's what the core developers almost definitely use in their regular workflow. The exception of course is going to be during and shortly after an OS beta, where there haven't been enough eyes on things in order to shake out all the bugs. >> I'd prefer /Library/Python/2.x/bin as the directory where scripts get >> placed >> because that directory is easily visible in the Finder and allows >> you to >> install >> software for both python2.3 and python2.4. > > So we need to tell people to add that to their PATH. The problem with that is that the /Library/Python/2.x/bin is likely to clash with whatever Apple has installed, since they also use those locations. For various reasons, anything we do needs to stay the hell out of their way because the vendor distribution is undesirable for anyone building redistributable software (or anyone that needs a recent build of Python for that matter). >> The bin directory inside the framework is a bit to hidden for most >> users >> and hard to get to using the Finder. > > Maybe we could put a link from /Library/Python/2.x/bin to the bin > directory in the Framework. That way, you wouldn't need to change the > standard script dir. We could do what darwinports does and twiddle their .profile on install to include the framework build dir. It's nasty, but practicality may beat purity in this case. I don't think Finder-visibility means a damn thing for usability of UNIX applications. You can't double-click them and have anything useful happen, and seeing them in Finder doesn't put them on your PATH. It seems futile to install the scripts to yet another non- standard place especially when there are cons to this particular location. >> I'll defer to any standard once it is here :-). Feel free to write a >> proposal about a standard, including what needs to be done to get >> there ;-) > > OK, I'll get working on that, once I'm clear about all this 10.3 vs. > 10.4 stuff. > > By the way, is there any advantage of the 10.4 build? There will only be one supported build. That build will probably support 10.3.9 and later (since that's all gcc4 can do). Earlier versions of OS X will be ignored. I definitely don't have the patience/time/resources/hardware to come up with something that runs gcc-3.3 and gcc4 via distutils to build ultra-compatible extensions. It's not easy. They take different flags, are compatible with different code, etc. As Ronald said, such a build would have different bugs on i386 and ppc, where the current gcc4 only approach is going to have the same set of bugs unless it's an endian thing. Dropping support for < 10.3.9 (from the official binaries) is probably inevitable, because supporting new i386 machines is more important than supporting aging PPC machines to the people doing this work, and this is the best compromise. We'll probably need some more tweaks to setuptools to allow it to relax the platform version requirement (e.g. 10.3 users should probably be allowed to try 10.4 eggs and vice versa if exact matches aren't available). > One other thought: having all these different pythons and what not to > support is a pain, but really, once you have the setup.py hacked so > that > it works right, it's no big deal to build a new package. What that > means > is that the real goal is to make sure that the patches required to > build > for OS-X get applied by the package maintainers. > > Then things will "just work" Assuming the user has developer tools installed, it's not a big deal. But yes, pushing patches upstream is generally more important than providing binary packages. -bob From bob at redivi.com Sat Feb 4 02:00:57 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 17:00:57 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> Message-ID: On Feb 3, 2006, at 4:39 PM, Bill Northcott wrote: > On 04/02/2006, at 11:28 AM, Christopher Barker wrote: >> I'm a bit confused where the problem is here. I've just installed >> OS-X 10.4, and I'm trying to decide where to go with my python >> version. I was planning on going all 10.4, rather than using a >> python framework built for 10.3. However, I need wxPython, so I'm >> interested in this thread. >> >> Bill Northcott wrote: >>> I have been trying to build wxPython on Tiger (10.4.4 gcc--3.3/g77) >>> with some difficulty, which may just be me being dense. >> >> Is this only a problem with gcc 3.3? What about gcc 4.0? Why are >> you building with 3.3 on OS-X 10.4? >> >> Or should I just stick with the older python build and use Robin's >> binaries? > > MacOS X 10.4 Tiger includes Python 2.3.5 and wxPython. > > The issue only arises using Python 2.4.x on Tiger. It does not arise > with Python 2.3.x on Tiger or Python 2.4.x on Panther (MacOS 10.3.x) On top of that, it should only happen if you're using a Python 2.4.x build on Tiger that was compiled on Panther. This is exactly what TigerPython24Fix is for: http://undefined.org/python/#TigerPython24Fix -bob From Chris.Barker at noaa.gov Sat Feb 4 02:18:51 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 03 Feb 2006 17:18:51 -0800 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <54309EAF-F553-4718-8580-4E65A7EF4100@redivi.com> References: <43E399EB.9060806@noaa.gov> <43E3F374.7050508@noaa.gov> <54309EAF-F553-4718-8580-4E65A7EF4100@redivi.com> Message-ID: <43E400FB.3050102@noaa.gov> Bob Ippolito wrote: > You're really confused here. Yes, I know. I was hoping for some clarification. Let me try it this way: I am running OS-X 10.4 I need Python >= 2.4.1 I *need* to build packages that will run on my machine, and I can give binaries to others running 10.4. I can also give them whatever pre-requisites they need, as long as there is )or I can make) and easy installer for it (like a python2.4.1 mpkg, for instance) I also need to build stand-alone apps with Py2app that will run on 10.4 While I'm at it I'd *like* to build binaries that I can contribute to the community and put up on pythonmac.org. Which python should I use? Which gcc should I use when I build stuff? >> I may want to stick with a python built for 10.3, if for no other >> reason that to get wxPython working as easily as possible. > > That's totally backwards... How is that? Robin provided binaries built for both 2.3 and 2.4 for OS-X 10.3, but not for 10.4, so I think that means I need to use the python built for 10.3. In addition, there is a thread in this group right now about trouble building wxPython on 10.4 -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From w.northcott at unsw.edu.au Sat Feb 4 02:29:58 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Sat, 4 Feb 2006 12:29:58 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> Message-ID: On 04/02/2006, at 12:00 PM, Bob Ippolito wrote: >> The issue only arises using Python 2.4.x on Tiger. It does not arise >> with Python 2.3.x on Tiger or Python 2.4.x on Panther (MacOS 10.3.x) > > On top of that, it should only happen if you're using a Python > 2.4.x build on Tiger that was compiled on Panther. Why would it not happen if Python 2.4 was built on Tiger? > > This is exactly what TigerPython24Fix is for: > http://undefined.org/python/#TigerPython24Fix As far as I can see this patch is a work around for the binary package on Bob's web site. Kevin and I are trying to fix the source code. so things build correctly without user level patching. Cheers Bill From bob at redivi.com Sat Feb 4 02:39:24 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 17:39:24 -0800 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <43E400FB.3050102@noaa.gov> References: <43E399EB.9060806@noaa.gov> <43E3F374.7050508@noaa.gov> <54309EAF-F553-4718-8580-4E65A7EF4100@redivi.com> <43E400FB.3050102@noaa.gov> Message-ID: On Feb 3, 2006, at 5:18 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> You're really confused here. > > Yes, I know. I was hoping for some clarification. Let me try it > this way: > > I am running OS-X 10.4 > > I need Python >= 2.4.1 > > I *need* to build packages that will run on my machine, and I can give > binaries to others running 10.4. I can also give them whatever > pre-requisites they need, as long as there is )or I can make) and easy > installer for it (like a python2.4.1 mpkg, for instance) > > I also need to build stand-alone apps with Py2app that will run on > 10.4 > > While I'm at it I'd *like* to build binaries that I can contribute to > the community and put up on pythonmac.org. > > Which python should I use? Which gcc should I use when I build stuff? There are only two Python distributions to choose from today: Python 2.4.1(for PPC) ActivePython 2.4.2 (for PPC) For all intents and purposes, they're the same and will cover all your purposes. Python 2.4.1 ships readline, but you will want to install TigerPython24Fix. ActivePython 2.4.2 does not ship readline, but I believe it already has a patched header. In the near future, there will be a Python 2.4.2 (with a LOT of patching) that is built fat, which will build extensions that work natively on i386 or ppc. Such a distribution is not available today. That distribution will only be compatible with GCC4 (so maybe Fortran users will have to do some major tweaking.. not sure if it's relevant to anything else). Unless you manually did something, GCC4 will be the default compiler for everything. This is fine. The only downside to GCC4 that I'm aware of is that some code might not be compatible with it (VERY unlikely) and that the binaries it produces have no chance at all on working on versions of Mac OS X prior to 10.3.9 (where gcc-3.3 produces binaries that "might" work on older versions of the OS). >>> I may want to stick with a python built for 10.3, if for no other >>> reason that to get wxPython working as easily as possible. >> >> That's totally backwards... > > How is that? Robin provided binaries built for both 2.3 and 2.4 for > OS-X > 10.3, but not for 10.4, so I think that means I need to use the python > built for 10.3. No, it doesn't... And that's not surprising because there isn't a readily available binary distribution of Python that was built on 10.4! > In addition, there is a thread in this group right now about trouble > building wxPython on 10.4 And I'm pretty sure I answered that with the reason and the fix, which has been available since the day 10.4.0 was released, if not a day or two earlier.... -bob From bob at redivi.com Sat Feb 4 02:51:27 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 17:51:27 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> Message-ID: <5D93C394-3203-45EB-806A-2DC25E91F7B6@redivi.com> On Feb 3, 2006, at 5:29 PM, Bill Northcott wrote: > On 04/02/2006, at 12:00 PM, Bob Ippolito wrote: >>> The issue only arises using Python 2.4.x on Tiger. It does not >>> arise >>> with Python 2.3.x on Tiger or Python 2.4.x on Panther (MacOS 10.3.x) >> >> On top of that, it should only happen if you're using a Python >> 2.4.x build on Tiger that was compiled on Panther. > > Why would it not happen if Python 2.4 was built on Tiger? The configure script detects Mac OS X 10.4 and changes its behavior accordingly. All this POSIX compliance stuff was broken on Mac OS X 10.2, then Apple 'fixed' it in 10.3, but it regressed in 10.4 When 10.3 came out, a Python developer decided to turn on the POSIX compliance junk. When 10.4 came out, Guido's time machine was apparently unavailable. In my current branch for universal binaries, the configure script will once again assume Mac OS X is not POSIX compliant until proven otherwise... even if compiled on 10.3. >> This is exactly what TigerPython24Fix is for: >> http://undefined.org/python/#TigerPython24Fix > > As far as I can see this patch is a work around for the binary > package on Bob's web site. Kevin and I are trying to fix the > source code. so things build correctly without user level patching. The fix needs to happen in Python, not in wxPython. You MUST apply TigerPython24Fix if you expect to build ANY extensions with this Python 2.4.1 build on OS X 10.4. That's just how it is. -bob From kevino at theolliviers.com Sat Feb 4 03:02:18 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 3 Feb 2006 18:02:18 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> Message-ID: <08C7D48A-1215-429C-A960-5D0AF225C04C@theolliviers.com> Hi Bill, On Feb 3, 2006, at 5:29 PM, Bill Northcott wrote: > On 04/02/2006, at 12:00 PM, Bob Ippolito wrote: >>> The issue only arises using Python 2.4.x on Tiger. It does not >>> arise >>> with Python 2.3.x on Tiger or Python 2.4.x on Panther (MacOS 10.3.x) >> >> On top of that, it should only happen if you're using a Python >> 2.4.x build on Tiger that was compiled on Panther. > > Why would it not happen if Python 2.4 was built on Tiger? Quoting a message Ronald wrote a few days back, when we were discussing universal builds: "Python's configure has hardcoded that OSX 10.2 and 10.4 must not have _POSIX_SOURCE and friends defined. Annoyingly this means that if you build Python on Panther you'll have to patch the build if you want to build extensions on Tiger." In other words, on Tiger and Jaguar, Python does not define _POSIX_C_SOURCE, in which case everything goes smoothly. I didn't remember this point until Bob mentioned the patch... >> This is exactly what TigerPython24Fix is for: >> http://undefined.org/python/#TigerPython24Fix > > As far as I can see this patch is a work around for the binary > package on Bob's web site. Kevin and I are trying to fix the source > code. so things build correctly without user level patching. Actually, if Python can get along without having _POSIX_C_SOURCE defined, then removing that define from Python itself is a very good idea. However, you're right that it only solves the immediate problem, still leaving the problem that wx cannot be built when _POSIX_C_SOURCE is defined. Thanks, Kevin > Cheers > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Sat Feb 4 03:07:37 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 3 Feb 2006 18:07:37 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <08C7D48A-1215-429C-A960-5D0AF225C04C@theolliviers.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> <08C7D48A-1215-429C-A960-5D0AF225C04C@theolliviers.com> Message-ID: <41AC0338-C63C-4499-8FF5-67AA6D5D5979@redivi.com> On Feb 3, 2006, at 6:02 PM, Kevin Ollivier wrote: > On Feb 3, 2006, at 5:29 PM, Bill Northcott wrote: > >> On 04/02/2006, at 12:00 PM, Bob Ippolito wrote: >>> This is exactly what TigerPython24Fix is for: >>> http://undefined.org/python/#TigerPython24Fix >> >> As far as I can see this patch is a work around for the binary >> package on Bob's web site. Kevin and I are trying to fix the source >> code. so things build correctly without user level patching. > > Actually, if Python can get along without having _POSIX_C_SOURCE > defined, then removing that define from Python itself is a very > good idea. However, you're right that it only solves the immediate > problem, still leaving the problem that wx cannot be built when > _POSIX_C_SOURCE is defined. Mac OS X applications can not be built with _POSIX_C_SOURCE is defined, period (pure Darwin stuff doesn't count, obviously). This is an Apple bug, not a wxPython bug... unless wxPython goes out of its way to make that #define like Python does in this particular case. -bob From kevino at theolliviers.com Sat Feb 4 04:14:18 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 3 Feb 2006 19:14:18 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> Message-ID: <48E82FA4-D582-4EF2-8E1B-FFC0212AD7BD@theolliviers.com> Hi Bill, On Feb 3, 2006, at 4:33 PM, Bill Northcott wrote: > Hi Kevin > > On 04/02/2006, at 11:08 AM, Kevin Ollivier wrote: >>> As I read the Opengroup document, Posix 200112L and Xopen 600 >>> have been converged. Older standards would not be the same and >>> certainly older versions of Xopen might have strcasecmp and >>> friends in string.h. OTOH higher versions are undefined. So it >>> would not be right to assume the code should work under them. >>> That was my take but it may be quite wrong. >> >> My concern is that while you're right that we can't assume that >> the code should work for new versions, neither can we assume it >> won't, so I'd prefer a solution that is guaranteed to work even if >> these values change. IMHO, even if we need to write a OS X-only >> configure test to properly set HAVE_STRCASECMP_IN_STRING_H, I'd >> rather go that route, because strings.h handles both scenarios >> (with or without the define) correctly and likely will continue to >> do so in the future. > > I quite agree that it would be best to have a solution guaranteed > to work in the future. However, the standard makes it very clear > that these sort of behaviours may change in the future. So it not > possible to use something like _XOPEN_SOURCE >= 600 with any > confidence. While that argument may be theoretically true, on OS X Tiger, in practical terms, the value of _XOPEN_SOURCE, or even it's definition, doesn't matter for our purposes; the tests we need to concern ourselves with are all for _POSIX_C_SOURCE, and in addition, the tests for that in string.h and math.h simply check to see if it is defined. Thus, your test will do the wrong thing in cases where _POSIX_C_SOURCE is defined to 1, or any other value, but _XOPEN_SOURCE is not defined, or _XOPEN_SOURCE is defined to any other value than 600 (because _POSIX_C_SOURCE will be defined anyways). Not only in the future, but also in the present, we could very possibly run into cases that will break your proposed header fix. > As for the autoconf test, IMO it is fundamentally flawed. I have > checked out MacOS X, Tru64 and Solaris and in all cases the > operative declaration of strcasecmp() is inside multiple #ifdefs. > So it depends on what headers have been included first and in what > order. Autoconf test programs need to be really simple and > reliable, which means not having a long list of included headers. > Unfortunately without such a list the test, as we see, is not > discovering what was intended. > > I am at a loss to see how a simple valid test might be constructed, > but that may be me being thick. Well, in most cases, we don't run into problems with this approach, meaning that the configure test is 'good enough' in most environments in which it is used. So I rather think the best thing to do is to fix it when it breaks. In this case, thanks to the Carbon fp.h problem, there's really no debate as to what the fix must be - we simply can't have _POSIX_C_SOURCE defined for wx on Tiger, so making sure it is undefined at the appropriate place should fix the problem. Otherwise, if we get rid of the configure test, we need to construct a completely fool-proof runtime test in the headers, and to do that, we'd have to look at every possible combination of #ifdef's for the inclusion of these functions on every supported platform, and then construct our own runtime test that passes in every one of those conditions, and fails in any other. Considering we'll probably never get it totally right this way either, and in the meantime we may break cases where the code does already work (in which case the patch won't be accepted anyways), I'd rather live with the configure test for now. :-) Thanks, Kevin > My two penny worth > Bill From kevino at theolliviers.com Sat Feb 4 04:25:32 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 3 Feb 2006 19:25:32 -0800 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <41AC0338-C63C-4499-8FF5-67AA6D5D5979@redivi.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> <08C7D48A-1215-429C-A960-5D0AF225C04C@theolliviers.com> <41AC0338-C63C-4499-8FF5-67AA6D5D5979@redivi.com> Message-ID: <1434BFD3-67D9-4780-B03F-67B7C2E648E4@theolliviers.com> Hi Bob, On Feb 3, 2006, at 6:07 PM, Bob Ippolito wrote: > > On Feb 3, 2006, at 6:02 PM, Kevin Ollivier wrote: > >> On Feb 3, 2006, at 5:29 PM, Bill Northcott wrote: >> >>> On 04/02/2006, at 12:00 PM, Bob Ippolito wrote: >>>> This is exactly what TigerPython24Fix is for: >>>> http://undefined.org/python/#TigerPython24Fix >>> >>> As far as I can see this patch is a work around for the binary >>> package on Bob's web site. Kevin and I are trying to fix the source >>> code. so things build correctly without user level patching. >> >> Actually, if Python can get along without having _POSIX_C_SOURCE >> defined, then removing that define from Python itself is a very >> good idea. However, you're right that it only solves the immediate >> problem, still leaving the problem that wx cannot be built when >> _POSIX_C_SOURCE is defined. > > Mac OS X applications can not be built with _POSIX_C_SOURCE is > defined, period (pure Darwin stuff doesn't count, obviously). > > This is an Apple bug, not a wxPython bug... unless wxPython goes > out of its way to make that #define like Python does in this > particular case. No, it doesn't, but it does determine which header file to get strcasecmp from at configure time, which is a bug because it may choose string.h at configure time, but later needs to get these functions from strings.h because the define of _POSIX_C_SOURCE changed. The fix for that bug would be to always use strings.h, at least on Tiger and up. Of course, since we'll still have the Apple bug with Carbon even if we use strings.h, we're better off just making sure _POSIX_C_SOURCE is undefined for wx, and thus string.h now always works with wx, solving both problems at once. :-) Thanks, Kevin > -bob > From evdo.hsdpa at gmail.com Sat Feb 4 01:38:04 2006 From: evdo.hsdpa at gmail.com (Robert Kim Wireless Internet Advisor) Date: Fri, 3 Feb 2006 16:38:04 -0800 Subject: [Pythonmac-SIG] [XML-SIG] PyXML 0.8.4 and expat byteorder In-Reply-To: <43E3E0C8.7080509@code-bear.com> References: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> <43E3E0C8.7080509@code-bear.com> Message-ID: <1ec620e90602031638u643d37f6wc3dec8b325cdcc33@mail.gmail.com> verrrrry cool! thanks! - bk On 2/3/06, bear wrote: > I've taken the patch and submitted it to the PyXML sourceforge project > and included a link to your mailing list archive entry for reference. -- Robert Q Kim, Wireless Internet Advisor http://hsdpa-coverage.com http://www.antennacoverage.com/cell-repeater.html 2611 S. Pacific Coast Highway 101 Suite 102 Cardiff by the Sea, CA 92007 206 984 0880 From w.northcott at unsw.edu.au Sat Feb 4 05:47:01 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Sat, 4 Feb 2006 15:47:01 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <5D93C394-3203-45EB-806A-2DC25E91F7B6@redivi.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> <5D93C394-3203-45EB-806A-2DC25E91F7B6@redivi.com> Message-ID: <61D3A891-D917-4E58-89A3-D0D12F2E5B24@unsw.edu.au> On 04/02/2006, at 12:51 PM, Bob Ippolito wrote: > All this POSIX compliance stuff was broken on Mac OS X 10.2, then > Apple 'fixed' it in 10.3, but it regressed in 10.4 From what I have seen on the particular issue of strcasecmp(), that is backwards. The headers were non-compliant in 10.3 and fixed in 10.4. Possibly it is different in respect of other issues. > When 10.3 came out, a Python developer decided to turn on the POSIX > compliance junk. When 10.4 came out, Guido's time machine was > apparently unavailable. Of course whether or not POSIX compliance is useful or not is a subject for a long discussion which is better avoided right now. I would just observe that in the case of strcasecmp() there is no doubt which header file provides it in a POSIX environment. Whereas the autoconf macro currently used gives no useful information. > > In my current branch for universal binaries, the configure script > will once again assume Mac OS X is not POSIX compliant until proven > otherwise... even if compiled on 10.3. It is certainly not POSIX compliant if you don't define _POSIX_C_SOURCE. > > Mac OS X applications can not be built with _POSIX_C_SOURCE is > defined, period (pure Darwin stuff doesn't count, obviously). I will take your word for that, but I might try to do it anyway. > > This is an Apple bug, not a wxPython bug... unless wxPython goes > out of its way to make that #define like Python does in this > particular case. > There certainly seems to be a bug in fp.h. The comments in fp.h regarding rinttoll() etc. say they are not available in MacOS X but they are getting declared which is the problem I have left. Cheers Bill From w.northcott at unsw.edu.au Sat Feb 4 06:23:39 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Sat, 4 Feb 2006 16:23:39 +1100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <48E82FA4-D582-4EF2-8E1B-FFC0212AD7BD@theolliviers.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <48E82FA4-D582-4EF2-8E1B-FFC0212AD7BD@theolliviers.com> Message-ID: <1BC05656-FCA8-498A-9EE2-61A9366FB5EC@unsw.edu.au> >> I quite agree that it would be best to have a solution guaranteed >> to work in the future. However, the standard makes it very clear >> that these sort of behaviours may change in the future. So it not >> possible to use something like _XOPEN_SOURCE >= 600 with any >> confidence. > > While that argument may be theoretically true, on OS X Tiger, in > practical terms, the value of _XOPEN_SOURCE, or even it's > definition, doesn't matter for our purposes; the tests we need to > concern ourselves with are all for _POSIX_C_SOURCE, and in > addition, the tests for that in string.h and math.h simply check to > see if it is defined. Thus, your test will do the wrong thing in > cases where _POSIX_C_SOURCE is defined to 1, or any other value, > but _XOPEN_SOURCE is not defined, or _XOPEN_SOURCE is defined to > any other value than 600 (because _POSIX_C_SOURCE will be defined > anyways). Not only in the future, but also in the present, we could > very possibly run into cases that will break your proposed header fix. These Macros should not be defined to any old values. Any sources doing that sort of thing are clearly wrong, and they should not accommodated except as specific exceptions. Only certain values are valid. The fix I put up only changes the existing code if _POSIX_C_SOURCES is 200112L. In that case strcasecmp() and friends are most definitely in . and the fix must still work in all the old cases. I don't see how the fix can break anything. > Well, in most cases, we don't run into problems with this approach, > meaning that the configure test is 'good enough' in most > environments in which it is used. So I rather think the best thing > to do is to fix it when it breaks. In this case, thanks to the > Carbon fp.h problem, there's really no debate as to what the fix > must be - we simply can't have _POSIX_C_SOURCE defined for wx on > Tiger, so making sure it is undefined at the appropriate place > should fix the problem. But my suggested fix ensures that code will not break whether or not _POSIX_C_SOURCES is defined. The code without the fix only works if it is not defined. > > Otherwise, if we get rid of the configure test, we need to > construct a completely fool-proof runtime test in the headers, and > to do that, we'd have to look at every possible combination of > #ifdef's for the inclusion of these functions on every supported > platform, and then construct our own runtime test that passes in > every one of those conditions, and fails in any other. Considering > we'll probably never get it totally right this way either, and in > the meantime we may break cases where the code does already work > (in which case the patch won't be accepted anyways), I'd rather > live with the configure test for now. :-) If you really want to stick with the configure test, it seems to me that it should at least be reversed. That is test for first and if that works, don't bother with . It seems to me that would be more robust. I guess it is the other way around for historical reasons. In BSD 4.3 the extensions were in . In BSD 4.4 and subsequent they are moved to . So if works it should be right, and the systems for which it does not work are all going to be fairly geriatric by now. That way the code would be POSIX compliant even without the other fix :-)! Cheers Bill From ronaldoussoren at mac.com Sat Feb 4 09:32:35 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 09:32:35 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> <1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com> <21675E32-8217-41F1-B5BC-0B54EC54D6D3@redivi.com> <689F3805-E73A-405F-89F9-6C1318090335@mac.com> Message-ID: <432AD8FE-0D74-45E0-80E6-C5A01319381C@mac.com> On 3-feb-2006, at 20:51, Bob Ippolito wrote: >>> >>> Since this is GCC, the #ifndef __LITTLE_ENDIAN__ branch is always >>> false... so I'm making this a compile-time not configure-time >>> value, but I left in the configure-time stuff for other platforms. >> >> Did you test this? I'd be surprised if distutils honours the ifdef >> statement. Luckily the easiest way to find the byteorder is >> sys.byteorder. > > Yes, I ran the test suite on PPC with a PPC-built build and on i386 > with and without Rosetta on a i386 build... I didn't test the PPC- > built version on an i386, but I'm going to assume it works for now > since the two possible outputs above are logically equivalent. I meant fetching WORDS_BIGENDIAN using distutils :-). Not that I think anyone actually does this. I had no doubt about your trick w.r.t. building python or extensions. > > distutils does know how to parse and find pyconfig.h > (sysconfig.parse_config_h, get_config_h_filename), but Python > itself only uses that functionality in the main setup.py. > Surprisingly, the main setup.py parses pyconfig.h twice (once with > distutils, once without -- good job there), but it of course > doesn't go anywhere near WORDS_BIGENDIAN. > > Packages that use WORDS_BIGENDIAN from distutils are broken. > There's nothing we can do to fix that short of patching the > package. Fortunately I don't think any package is dumb enough to > do that. We could patch distutils to derive WORDS_BIGENDIAN from sys.byteorder. > > Packages that do something with sys.byteorder at setup.py time are > probably going to be broken also... but I've never seen that either. These are not broken, its just harder to create universal binaries for them. I know that cElementTree uses sys.byteorder to calculate the right flags for compiling expat and wouldn't be surprised if other packages that wrap expat use the same mechanism. > >> I have a patched version of pyconfig.h that #includes "macosx- >> config.h" at the end. This file redefines a number of values based >> on the cpu-type. Anyone that grabs CPU information from pyconfig.h >> will get the values from the platform that was used to generate >> pyconfig.h (an intel system in my case). I like your trick better, >> mine is a bit too elaborate and not needed until someone wants to >> do a ppc64 build. > > sys.byteorder is actually determined at runtime: > > unsigned long number = 1; > char *value; > > s = (char *) &number; > if (s[0] == 0) > value = "big"; > else > value = "little"; > PyDict_SetItemString(sysdict, "byteorder", > v = PyString_FromString(value)); > Py_XDECREF(v); I know that. I've looked into eliminating WORDS_BIGENDIAN and the SIZEOF_* defines and decided this was a bit too much work for now. Odly enough WORDS_BIGENDIAN is used elsewhere in the sourcecode, not using that define here just complicates the code. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/13d042b7/attachment.bin From ronaldoussoren at mac.com Sat Feb 4 09:41:32 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 09:41:32 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> Message-ID: <0C84506D-EB2C-4FE7-B280-00F63FD86D20@mac.com> On 3-feb-2006, at 21:10, Bob Ippolito wrote: > > On Feb 3, 2006, at 11:41 AM, Bob Ippolito wrote: > >> >> On Feb 3, 2006, at 11:01 AM, Ronald Oussoren wrote: >> >>> >>> On 3-feb-2006, at 20:00, Bob Ippolito wrote: >>> >>>> >>>> On Feb 3, 2006, at 10:52 AM, Ronald Oussoren wrote: >>>> >>>>> >>>>> On 3-feb-2006, at 5:23, Bob Ippolito wrote: >>>>> >>>>>> It fixes a couple of the endian issues in the Mac modules >>>>>> (platform.mac_ver, applesingle, gestalt, and the OSType >>>>>> converter functions) >>>>> >>>>> How do you convert four character codes? Is 'abcd' big endian or >>>>> platform-native? >>>> >>>> 'abcd' is platform endian. >>> >>> Fine by me. Either choice seems to be defendable that why I asked. >>> >>> BTW. I know next to nothing about SVK, can I use an ordinary >>> subversion client to fetch files from your repository? >> >> Yes, it works fine, the repo is just a subversion repo. svk does all >> its magic in a few svn properties (keeping track of merge history >> basically). >> >> The advantage that SVK has in cases like this is that I can create a >> branch of python24-maint without using the svn.python.org repo >> directly and then have the capability to merge changes one way or >> another, while still using svn repositories. > > I think the only things missing from my branch currently are: > > 1) 10.3.9 support I have that, although the patches are gross. > 2) Universal PythonLauncher > 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that > in Python and not hardcode everything) I have started on this as well, including code to download a build universal binaries for readline and sleepycat db. > > I'll probably take the pbproj out of PythonLauncher and just build > it with the Makefile since it can inherit the right build flags and > such that way. That seems to be the correct way forward, the project file isn't helpful here. > > In other words, this seems to work correctly universally: > > $ mkdir _build > $ cd _build > $ ../configure --enable-framework --enable-universalsdk && make > $ sudo make frameworkinstall > > The only backwards incompatible change (beyond missing WASTE, > PythonIDE, PackageManager) that I'm aware of is the > distutils.util.get_platform string: it no longer says darwin, it > says macosx-{ver}-{arch} where ver is the major.minor version of > Mac OS X (not the damned kernel) and arch is either fat (universal > is too long), ppc, i386, or whatever falls through from the uname. > And of course, if you're using the universal build, you'll need the > 10.4u SDK installed to compile any extensions. The first one seems unacceptable, there's no change that this will get merged into python 2.4.3. It would be nice to get this into python 2.5 though. This will not stop me from using your build though. The requirement on the 10.4u SDK means you won't be able to build extensions on 10.3. > > This backwards incompatible change is mostly just a backport from > setuptools' pkg_resources module. > > $ python -c "from distutils.util import get_platform as p; print p()" > macosx-10.4.3-fat > > First and foremost this change fixes running-Python-in-the-build- > directory-with-Rosetta, but the secondary benefit is that this > metadata will show up in Cheese Shop if you build an egg with a > universal Python. Thus, this universal python will create fat eggs > and will have a proclivity for fat eggs. The potential issue here > is that it might refuse to use single-arch eggs, which I don't see > as much of a problem really. If it didn't change the arch name to > "fat" then you wouldn't be able to tell universal and single-arch > eggs apart. An alternative to fat might be 'ppc,i386'. That is longer, but is clearer about which architectures are supported (just in case someone decides to donate support for a threeway universal build). Patching setuptools to know that an architecture string that contains a comma is actually a list of architectures shouldn't be too hard. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/4dd36aa0/attachment.bin From ronaldoussoren at mac.com Sat Feb 4 09:55:34 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 09:55:34 +0100 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <43E3F374.7050508@noaa.gov> References: <43E399EB.9060806@noaa.gov> <43E3F374.7050508@noaa.gov> Message-ID: On 4-feb-2006, at 1:21, Christopher Barker wrote: > Ronald Oussoren wrote: >> Even more important that versioning is that eggs give you an easy way >> to uninstall software (although I'm not quite sure about scripts). > > It really does look like eggs are the way of the future. > >>> Bob's "official unofficial" 2.4.1 framework build for 10.3 (this >>> will >>> run on 10.4 also) >>> >>> 2.4.1 framework build for 10.4 >> Don't. There should be only one binary installation of Python >> 2.4.x for every x and than one should work on 10.3 and 10.4. > > OK. However, if I understand it, if I am running 10.4, I can run a > python and extensions that were built on and for 10.3. However, if > I build an extension on 10.4, it may well not work on 10.3. What > that means is that anyone building extensions on 10.4 can't > contribute to the repository of packages for 10.3. Most packages should work just fine when build on 10.4, it is important to test this especially for packages that use autoconf. > However, you also can't run extensions built for a 10.3 python on a > 10.4 python, which is why this is such a headache! For that matter, > can I build extensions to a python built for 10.3 on 10.4 at all > without trickery? That's only a problem for Apple's build of python, they changed the location of site-packages in 10.4. A clean build of python2.4 will alway have site-packages somewhere inside the framework. > > I, and all my colleagues, are switching to 10.4 now (I just > upgraded to day). I was just thinking I'd go 10.4 across the board, > but now I think I may want to stick with a python built for 10.3, > if for no other reason that to get wxPython working as easily as > possible. > > > This makes life a lot easier for casual users. > > Good point. The "standard" approach is for casual users, those > doing things like trying to build a universal binary python can do > whatever they want! There should be a good univeral binary build of Python 2.4 soon, Bob has already published a patched python tree that's almost there and I have another set of patches that seem to fix most of the remaining gaps. > >> I'd prefer /Library/Python/2.x/bin as the directory where scripts >> get placed >> because that directory is easily visible in the Finder and allows >> you to install >> software for both python2.3 and python2.4. > > So we need to tell people to add that to their PATH. Or write a simple (GUI) script to do that for them. Adding to a .bash_profile or .cshrc isn't very hard (for .bash_profile you can just append 'PATH="/Library/Frameworks/Python.framework/Versions/ Current/bin:${PATH}"' to the end of the file, for .cshrc it is something simular) and anyone that has made extensive changes to their profile should be smart enough to do it themselves. > >> The bin directory inside the framework is a bit to hidden for most >> users >> and hard to get to using the Finder. > > Maybe we could put a link from /Library/Python/2.x/bin to the bin > directory in the Framework. That way, you wouldn't need to change > the standard script dir. That's what I have on my system. The major problem with my setup is that Apple might decide to upgrade to python 2.4 in OSX 10.5 and replace /Library/Python/2.5 with their stuff. > >> I'll defer to any standard once it is here :-). Feel free to >> write a proposal about a standard, including what needs to be done >> to get there ;-) > > OK, I'll get working on that, once I'm clear about all this 10.3 > vs. 10.4 stuff. > > By the way, is there any advantage of the 10.4 build? As it is now a 10.4 build supports os.statvfs, os.fstatvfs and os.lchown while the 10.3 build doesn't. The 10.4 build also uses a better API to implement time.time and part of the socket module. I haven't looked at differences in the Carbon namespace yet. > > One other thought: having all these different pythons and what not > to support is a pain, but really, once you have the setup.py hacked > so that it works right, it's no big deal to build a new package. > What that means is that the real goal is to make sure that the > patches required to build for OS-X get applied by the package > maintainers. > > Then things will "just work" That's the idea, local patches should be the last resort (e.g. a patch is really needed but the upstream maintainer doesn't want to apply it). Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/82672c73/attachment.bin From ronaldoussoren at mac.com Sat Feb 4 10:06:50 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 10:06:50 +0100 Subject: [Pythonmac-SIG] best way to install packages? In-Reply-To: <54309EAF-F553-4718-8580-4E65A7EF4100@redivi.com> References: <43E399EB.9060806@noaa.gov> <43E3F374.7050508@noaa.gov> <54309EAF-F553-4718-8580-4E65A7EF4100@redivi.com> Message-ID: On 4-feb-2006, at 1:54, Bob Ippolito wrote: > >>> The bin directory inside the framework is a bit to hidden for >>> most users >>> and hard to get to using the Finder. >> >> Maybe we could put a link from /Library/Python/2.x/bin to the bin >> directory in the Framework. That way, you wouldn't need to change the >> standard script dir. > > We could do what darwinports does and twiddle their .profile on > install to include the framework build dir. It's nasty, but > practicality may beat purity in this case. Just make sure it is optional, I thoroughly dislike installers that modify my profile. I use the same profile on several machines (including some that are not running osx). > > I don't think Finder-visibility means a damn thing for usability of > UNIX applications. You can't double-click them and have anything > useful happen, and seeing them in Finder doesn't put them on your > PATH. It seems futile to install the scripts to yet another non- > standard place especially when there are cons to this particular > location. It might help in the discoverability department. But I shouldn't comment here, I'm in the "large screens are nice because it allows me to open more command-line windows" camp. > >>> I'll defer to any standard once it is here :-). Feel free to >>> write a >>> proposal about a standard, including what needs to be done to get >>> there ;-) >> >> OK, I'll get working on that, once I'm clear about all this 10.3 vs. >> 10.4 stuff. >> >> By the way, is there any advantage of the 10.4 build? > > There will only be one supported build. That build will probably > support 10.3.9 and later (since that's all gcc4 can do). Earlier > versions of OS X will be ignored. I definitely don't have the > patience/time/resources/hardware to come up with something that > runs gcc-3.3 and gcc4 via distutils to build ultra-compatible > extensions. It's not easy. They take different flags, are > compatible with different code, etc > > As Ronald said, such a build would have different bugs on i386 and > ppc, where the current gcc4 only approach is going to have the same > set of bugs unless it's an endian thing. Dropping support for < > 10.3.9 (from the official binaries) is probably inevitable, because > supporting new i386 machines is more important than supporting > aging PPC machines to the people doing this work, and this is the > best compromise. I have (ugly) patches that make it possible to run on 10.3.9 using weak linking. My current universal build uses gcc 3.3 to build binaries and uses lipo to merge the i386 and ppc builds. I'm going to port my patches to Bob's tree because that's a much nicer way to build and I cannot test on anything before 10.3.9 anyway. > > We'll probably need some more tweaks to setuptools to allow it to > relax the platform version requirement (e.g. 10.3 users should > probably be allowed to try 10.4 eggs and vice versa if exact > matches aren't available). 10.4 users should be allowed to use 10.3 eggs, but not the other way around. If you (the packager) have binaries that work on 10.3 you should provide the right flags to setuptools and create 10.3 eggs. Just using 10.4 eggs when available might cause hard crashes, which wouldn't help the setuptools cause :-) > >> One other thought: having all these different pythons and what not to >> support is a pain, but really, once you have the setup.py hacked >> so that >> it works right, it's no big deal to build a new package. What that >> means >> is that the real goal is to make sure that the patches required to >> build >> for OS-X get applied by the package maintainers. >> >> Then things will "just work" > > Assuming the user has developer tools installed, it's not a big > deal. But yes, pushing patches upstream is generally more > important than providing binary packages. > > -bob > Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/90f9089e/attachment-0001.bin From ronaldoussoren at mac.com Sat Feb 4 10:11:37 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 10:11:37 +0100 Subject: [Pythonmac-SIG] wxPython build issue In-Reply-To: <08C7D48A-1215-429C-A960-5D0AF225C04C@theolliviers.com> References: <7139F8A1-853C-468C-A378-9081B4B95846@unsw.edu.au> <11973ADD-7D45-4230-9149-EE2E20B80662@unsw.edu.au> <971EA839-63F7-4FD4-8513-78B4FF094F3D@theolliviers.com> <6664E678-ED08-4375-A43D-3381E532F4C7@theolliviers.com> <43E3F51A.9060206@noaa.gov> <020B5023-F13D-4121-874D-ABE92F6F99BB@unsw.edu.au> <08C7D48A-1215-429C-A960-5D0AF225C04C@theolliviers.com> Message-ID: On 4-feb-2006, at 3:02, Kevin Ollivier wrote: > Hi Bill, > > On Feb 3, 2006, at 5:29 PM, Bill Northcott wrote: > >> On 04/02/2006, at 12:00 PM, Bob Ippolito wrote: >>>> The issue only arises using Python 2.4.x on Tiger. It does not >>>> arise >>>> with Python 2.3.x on Tiger or Python 2.4.x on Panther (MacOS >>>> 10.3.x) >>> >>> On top of that, it should only happen if you're using a Python >>> 2.4.x build on Tiger that was compiled on Panther. >> >> Why would it not happen if Python 2.4 was built on Tiger? > > Quoting a message Ronald wrote a few days back, when we were > discussing universal builds: > > "Python's configure has hardcoded that OSX 10.2 and 10.4 must not > have _POSIX_SOURCE and friends defined. Annoyingly this means that if > you build Python on Panther you'll have to patch the build if you > want to build extensions on Tiger." > > In other words, on Tiger and Jaguar, Python does not define > _POSIX_C_SOURCE, in which case everything goes smoothly. I didn't > remember this point until Bob mentioned the patch... My patch for this is here: http://www.python.org/sf/1416559 This turns of _POSIX_C_SOURCE for 10.2, 10.3 and 10.4. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/4bb34f03/attachment.bin From njriley at uiuc.edu Sat Feb 4 10:29:08 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat, 4 Feb 2006 03:29:08 -0600 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <0C84506D-EB2C-4FE7-B280-00F63FD86D20@mac.com> References: <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <0C84506D-EB2C-4FE7-B280-00F63FD86D20@mac.com> Message-ID: <20060204092908.GA11291@uiuc.edu> On Sat, Feb 04, 2006 at 09:41:32AM +0100, Ronald Oussoren wrote: > An alternative to fat might be 'ppc,i386'. That is longer, but is > clearer about which architectures are supported (just in case someone > decides to donate support for a threeway universal build). Patching > setuptools to know that an architecture string that contains a comma > is actually a list of architectures shouldn't be too hard. This sounds like a good idea, and this is not just a legacy issue with ppc64 - we'll likely have a 64-bit x86 Mac variant to handle within the year. -- Nicholas Riley | From bob at redivi.com Sat Feb 4 11:16:05 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 4 Feb 2006 02:16:05 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <20060204092908.GA11291@uiuc.edu> References: <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <0C84506D-EB2C-4FE7-B280-00F63FD86D20@mac.com> <20060204092908.GA11291@uiuc.edu> Message-ID: <5335B50A-C9F2-4C1F-81ED-DF7BC9B5B000@redivi.com> On Feb 4, 2006, at 1:29 AM, Nicholas Riley wrote: > On Sat, Feb 04, 2006 at 09:41:32AM +0100, Ronald Oussoren wrote: >> An alternative to fat might be 'ppc,i386'. That is longer, but is >> clearer about which architectures are supported (just in case someone >> decides to donate support for a threeway universal build). Patching >> setuptools to know that an architecture string that contains a comma >> is actually a list of architectures shouldn't be too hard. > > This sounds like a good idea, and this is not just a legacy issue with > ppc64 - we'll likely have a 64-bit x86 Mac variant to handle within > the year. Even more reason to leave fat as ppc,i386 -- which are all 32 bit builds... Currently, I'm pretty sure ppc64 won't even build at all. -bob From ronaldoussoren at mac.com Sat Feb 4 11:57:48 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 11:57:48 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <5335B50A-C9F2-4C1F-81ED-DF7BC9B5B000@redivi.com> References: <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <0C84506D-EB2C-4FE7-B280-00F63FD86D20@mac.com> <20060204092908.GA11291@uiuc.edu> <5335B50A-C9F2-4C1F-81ED-DF7BC9B5B000@redivi.com> Message-ID: <6F3AEFB8-1F45-4CA2-8FE4-52C3DBC5C2B2@mac.com> On 4-feb-2006, at 11:16, Bob Ippolito wrote: > > On Feb 4, 2006, at 1:29 AM, Nicholas Riley wrote: > >> On Sat, Feb 04, 2006 at 09:41:32AM +0100, Ronald Oussoren wrote: >>> An alternative to fat might be 'ppc,i386'. That is longer, but is >>> clearer about which architectures are supported (just in case >>> someone >>> decides to donate support for a threeway universal build). Patching >>> setuptools to know that an architecture string that contains a comma >>> is actually a list of architectures shouldn't be too hard. >> >> This sounds like a good idea, and this is not just a legacy issue >> with >> ppc64 - we'll likely have a 64-bit x86 Mac variant to handle within >> the year. > > Even more reason to leave fat as ppc,i386 -- which are all 32 bit > builds... Currently, I'm pretty sure ppc64 won't even build at all. So what? "fat" or "universal" is ambigious, "i386,ppc" is not. That seems a good reason to adapt the more verbose label to me, especially in the context of setuptools. If someone were to donate a patch for a ppc64 universal build[*] it will also require an architecture label, if it were to reuse 'fat' you'd get two types of universal eggs: ones that support ppc64 and ones that don't. That's no good if you want to support automatic installation, as setuptools does. An explicit list of supported architectures is forward compatible and doesn't require more work right now: just do a global substitute that replaces 'fat' by 'i386,ppc' and you're done. Inserting logic that treats 'i386,ppc' can be done when adding the hypothetical ppc64 build I mentioned earlier. Ronald [*] which won't be me, it seems that I'll be skipping the entire G5 generation > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/dff14425/attachment.bin From ronaldoussoren at mac.com Sat Feb 4 21:02:06 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 21:02:06 +0100 Subject: [Pythonmac-SIG] First experiences with the python24-fat tree. Message-ID: test_email is failing, this is due to a bad checkin: the files in Lib/ test/data should be checked in as binary files and are not The attached python2.4-readline-searchpath.patch makes sure we pick up libreadline.a from LDFLAGS in preference of the system libreadline.dylib The attached patches python2.4-weaklinking.patch makes it possible to run 'regrtest -uall' on OSX 10.3 systems. IMO this patch needs work, I'd be surprised if it were accepted into the python repository as is. What I don't quite understand is that the latter patch doesn't quite work: the i386 contains weak links to fstatvfs and other 10.4-only symbols, but the ppc version does not. A small test program does work correctly. testfile.c: #pragma weak fstatvfs #include #include int main (void) { printf("%p\n", fstatvfs); return 0; } // EOF Compile this with 'MACOSX_DEPLOYMENT_TARGET=10.3 gcc -arch i386 -arch ppc -o testfile testfile.c -isysroot /Developer/SDKs/ MacOSX10.4u.sdk'. 'nm -arch ppc -pm testfile.c | grep statvfs' clearly shows that statvfs is weakly linked. Yet 'nm -arch ppc -pm Modules/posixmodule.o' shows a hard link and 'nm -arch i386 -pm Modules/posixmodule.o' shows a weak link again. What's even stranger is that weaklinking works properly again if I create a PPC only build by first configure-ing for a universal build and then removing '-arch i386' from the toplevel Makefile. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: python2.4-readline-searchpath.patch Type: application/octet-stream Size: 1077 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/f10569cf/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: python2.4-weaklinking.patch Type: application/octet-stream Size: 4737 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/f10569cf/attachment-0001.obj -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/f10569cf/attachment.bin From ronaldoussoren at mac.com Sat Feb 4 21:26:36 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 21:26:36 +0100 Subject: [Pythonmac-SIG] First experiences with the python24-fat tree. In-Reply-To: References: Message-ID: <761024FC-0133-4819-AB25-4DF7131A18A6@mac.com> On 4-feb-2006, at 21:02, Ronald Oussoren wrote: > > What I don't quite understand is that the latter patch doesn't > quite work: the i386 contains weak links to fstatvfs and other 10.4- > only symbols, but the ppc version does not. A small test program > does work correctly. I hope nobody noticed this e-mail :-(. You have to set MACOSX_DEPLOYMENT_TARGET=10.4 (or any value except 10.1) before building, else gcc ignores weak linking instructions for ppc builds. I've solved this more permantently by adding these lines to Makefile.pre.in (just after settings CONFIGURE_MACOSX_DEPLOYMENT): # # Ensure that the deployment target doesn't change between configure and # build time. MACOSX_DEPLOYMENT_TARGET=@CONFIGURE_MACOSX_DEPLOYMENT_TARGET@ This ensures that make and distutils will use the same setting of MACOSX_DEPLOYMENT_TARGET. A better fix might be to drop CONFIGURE_MACOSX_DEPLOYMENT_TARGET entirely, I'll do that later. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/c016a106/attachment.bin From ronaldoussoren at mac.com Sat Feb 4 22:16:39 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 4 Feb 2006 22:16:39 +0100 Subject: [Pythonmac-SIG] First experiences with the python24-fat tree. In-Reply-To: <761024FC-0133-4819-AB25-4DF7131A18A6@mac.com> References: <761024FC-0133-4819-AB25-4DF7131A18A6@mac.com> Message-ID: <456A7F97-37DE-40E6-8622-111AB1E78D68@mac.com> On 4-feb-2006, at 21:26, Ronald Oussoren wrote: > > On 4-feb-2006, at 21:02, Ronald Oussoren wrote: >> >> What I don't quite understand is that the latter patch doesn't >> quite work: the i386 contains weak links to fstatvfs and other >> 10.4-only symbols, but the ppc version does not. A small test >> program does work correctly. > > I hope nobody noticed this e-mail :-(. You have to set > MACOSX_DEPLOYMENT_TARGET=10.4 (or any value except 10.1) before > building, else gcc ignores weak linking instructions for ppc > builds. I've solved this more permantently by adding these lines to > Makefile.pre.in (just after settings CONFIGURE_MACOSX_DEPLOYMENT): > > # > # Ensure that the deployment target doesn't change between > configure and > # build time. > MACOSX_DEPLOYMENT_TARGET=@CONFIGURE_MACOSX_DEPLOYMENT_TARGET@ Arghh, this doesn't help. Modules/posixmodule.o gets build with weak linking enabled, but the creation of $(BUILDPYTHON) ignores the MACOSX_DEPLOYMENT_TARGET setting in the Makefile and you must once again set it while running make. It must be an off night for me, it's quite obvious why this doesn't work: make variables are not the same as environment variables. GNU make has a feature to export variables to the environment, but the toplevel makefile should only contain portable code. Oh well, you win some an you loose some. > > This ensures that make and distutils will use the same setting of > MACOSX_DEPLOYMENT_TARGET. A better fix might be to drop > CONFIGURE_MACOSX_DEPLOYMENT_TARGET entirely, I'll do that later. But not unless I find a way to use the value that configure calculated in the makefile. Ronald > > Ronald_______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/f597c6e6/attachment.bin From bob at redivi.com Sun Feb 5 02:35:06 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 4 Feb 2006 17:35:06 -0800 Subject: [Pythonmac-SIG] First experiences with the python24-fat tree. In-Reply-To: <761024FC-0133-4819-AB25-4DF7131A18A6@mac.com> References: <761024FC-0133-4819-AB25-4DF7131A18A6@mac.com> Message-ID: On Feb 4, 2006, at 12:26 PM, Ronald Oussoren wrote: > > On 4-feb-2006, at 21:02, Ronald Oussoren wrote: >> >> What I don't quite understand is that the latter patch doesn't >> quite work: the i386 contains weak links to fstatvfs and other >> 10.4-only symbols, but the ppc version does not. A small test >> program does work correctly. > > I hope nobody noticed this e-mail :-(. You have to set > MACOSX_DEPLOYMENT_TARGET=10.4 (or any value except 10.1) before > building, else gcc ignores weak linking instructions for ppc > builds. I've solved this more permantently by adding these lines to > Makefile.pre.in (just after settings CONFIGURE_MACOSX_DEPLOYMENT): > > # > # Ensure that the deployment target doesn't change between > configure and > # build time. > MACOSX_DEPLOYMENT_TARGET=@CONFIGURE_MACOSX_DEPLOYMENT_TARGET@ > > This ensures that make and distutils will use the same setting of > MACOSX_DEPLOYMENT_TARGET. A better fix might be to drop > CONFIGURE_MACOSX_DEPLOYMENT_TARGET entirely, I'll do that later. Maybe what we should do is assume MACOSX_DEPLOYMENT_TARGET=10.3 unless it's set manually, and make sure to use it in the makefiles any time a compiler is invoked. distutils already ensures MACOSX_DEPLOYMENT_TARGET is set for anything it does. I'm also thinking about having distutils.util.get_platform() return macosx-$MACOSX_DEPLOYMENT_TARGET-arch rather than the actual current version, since for all intents and purposes that's what distutils is going to be producing binaries for. -bob From bob at redivi.com Sun Feb 5 04:57:25 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 4 Feb 2006 19:57:25 -0800 Subject: [Pythonmac-SIG] First experiences with the python24-fat tree. In-Reply-To: <456A7F97-37DE-40E6-8622-111AB1E78D68@mac.com> References: <761024FC-0133-4819-AB25-4DF7131A18A6@mac.com> <456A7F97-37DE-40E6-8622-111AB1E78D68@mac.com> Message-ID: <9DCC99C7-8A8E-42E4-99A6-1F35EC92D885@redivi.com> On Feb 4, 2006, at 1:16 PM, Ronald Oussoren wrote: > > On 4-feb-2006, at 21:26, Ronald Oussoren wrote: > >> >> On 4-feb-2006, at 21:02, Ronald Oussoren wrote: >>> >>> What I don't quite understand is that the latter patch doesn't >>> quite work: the i386 contains weak links to fstatvfs and other >>> 10.4-only symbols, but the ppc version does not. A small test >>> program does work correctly. >> >> I hope nobody noticed this e-mail :-(. You have to set >> MACOSX_DEPLOYMENT_TARGET=10.4 (or any value except 10.1) before >> building, else gcc ignores weak linking instructions for ppc >> builds. I've solved this more permantently by adding these lines >> to Makefile.pre.in (just after settings CONFIGURE_MACOSX_DEPLOYMENT): >> >> # >> # Ensure that the deployment target doesn't change between >> configure and >> # build time. >> MACOSX_DEPLOYMENT_TARGET=@CONFIGURE_MACOSX_DEPLOYMENT_TARGET@ > > Arghh, this doesn't help. Modules/posixmodule.o gets build with > weak linking enabled, but the creation of $(BUILDPYTHON) ignores > the MACOSX_DEPLOYMENT_TARGET setting in the Makefile and you must > once again set it while running make. > > It must be an off night for me, it's quite obvious why this doesn't > work: make variables are not the same as environment variables. > GNU make has a feature to export variables to the environment, but > the toplevel makefile should only contain portable code. Oh well, > you win some an you loose some. > >> >> This ensures that make and distutils will use the same setting of >> MACOSX_DEPLOYMENT_TARGET. A better fix might be to drop >> CONFIGURE_MACOSX_DEPLOYMENT_TARGET entirely, I'll do that later. > > But not unless I find a way to use the value that configure > calculated in the makefile. CONFIGURE_MACOSX_DEPLOYMENT_TARGET=@CONFIGURE_MACOSX_DEPLOYMENT_TARGET@ ifneq ($(CONFIGURE_MACOSX_DEPLOYMENT_TARGET),"") SHELL=/usr/bin/env MACOSX_DEPLOYMENT_TARGET=$ (CONFIGURE_MACOSX_DEPLOYMENT_TARGET) /bin/sh endif Your patches and this fix are in the branch. -bob From bob at redivi.com Sun Feb 5 07:39:47 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 4 Feb 2006 22:39:47 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <6F3AEFB8-1F45-4CA2-8FE4-52C3DBC5C2B2@mac.com> References: <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <0C84506D-EB2C-4FE7-B280-00F63FD86D20@mac.com> <20060204092908.GA11291@uiuc.edu> <5335B50A-C9F2-4C1F-81ED-DF7BC9B5B000@redivi.com> <6F3AEFB8-1F45-4CA2-8FE4-52C3DBC5C2B2@mac.com> Message-ID: On Feb 4, 2006, at 2:57 AM, Ronald Oussoren wrote: > > On 4-feb-2006, at 11:16, Bob Ippolito wrote: > >> >> On Feb 4, 2006, at 1:29 AM, Nicholas Riley wrote: >> >>> On Sat, Feb 04, 2006 at 09:41:32AM +0100, Ronald Oussoren wrote: >>>> An alternative to fat might be 'ppc,i386'. That is longer, but is >>>> clearer about which architectures are supported (just in case >>>> someone >>>> decides to donate support for a threeway universal build). Patching >>>> setuptools to know that an architecture string that contains a >>>> comma >>>> is actually a list of architectures shouldn't be too hard. >>> >>> This sounds like a good idea, and this is not just a legacy issue >>> with >>> ppc64 - we'll likely have a 64-bit x86 Mac variant to handle within >>> the year. >> >> Even more reason to leave fat as ppc,i386 -- which are all 32 bit >> builds... Currently, I'm pretty sure ppc64 won't even build at all. > > So what? "fat" or "universal" is ambigious, "i386,ppc" is not. That > seems a good > reason to adapt the more verbose label to me, especially in the > context of setuptools. fat or universal is not really ambiguous. They mean i386,ppc in Apple terms. The only other "supported" architecture is ppc64, and that can only speak POSIX and behaves completely differently. I'll be very surprised (and annoyed) if they switch architectures again any time soon :) When/if x86-64 happens, we'll just have to wait and see if they end up really supporting it, or shoving it off to the side like they do ppc64. At some point a "MacPython 64bit" might make sense (for people doing really big number crunching), but it doesn't really make any sense to have that be universal because 64 bit apps on OS X can only really talk to libSystem. > If someone were to donate a patch for a ppc64 universal build[*] it > will also > require an architecture label, if it were to reuse 'fat' you'd get > two types of > universal eggs: ones that support ppc64 and ones that don't. > That's no good if you > want to support automatic installation, as setuptools does. An > explicit list of supported > architectures is forward compatible and doesn't require more work > right now: just > do a global substitute that replaces 'fat' by 'i386,ppc' and you're > done. Inserting > logic that treats 'i386,ppc' can be done when adding the > hypothetical ppc64 build I > mentioned earlier. ppc64 is not going to happen universal. It's a different Python with a different usage scenario and a different set of modules that are compatible with it. If someone compiles a 64-bit Python they're going to have to do it separately (and mangle all of the checks for __APPLE__ and darwin because ppc64 is basically a pure POSIX beast with no frills). > [*] which won't be me, it seems that I'll be skipping the entire G5 > generation I have a G5, but not one with > 4G of RAM to make use of :) -bob From ronaldoussoren at mac.com Sun Feb 5 07:42:46 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 5 Feb 2006 07:42:46 +0100 Subject: [Pythonmac-SIG] First experiences with the python24-fat tree. In-Reply-To: <9DCC99C7-8A8E-42E4-99A6-1F35EC92D885@redivi.com> References: <761024FC-0133-4819-AB25-4DF7131A18A6@mac.com> <456A7F97-37DE-40E6-8622-111AB1E78D68@mac.com> <9DCC99C7-8A8E-42E4-99A6-1F35EC92D885@redivi.com> Message-ID: On 5-feb-2006, at 4:57, Bob Ippolito wrote: > > > CONFIGURE_MACOSX_DEPLOYMENT_TARGET=@CONFIGURE_MACOSX_DEPLOYMENT_TARGET > @ > ifneq ($(CONFIGURE_MACOSX_DEPLOYMENT_TARGET),"") > SHELL=/usr/bin/env MACOSX_DEPLOYMENT_TARGET=$ > (CONFIGURE_MACOSX_DEPLOYMENT_TARGET) /bin/sh > endif That will work, but if we're going to use GNU-ism's in the makefile I'd rather see 'export MACOSX_DEPLPYMENT_TARGET' (and rename CONFIGURE_MACOSX_DEPLOYMENT_TARGET to MACOSX_DEPLOYMENT_TARGET). Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060205/717b4a7d/attachment.bin From bob at redivi.com Sun Feb 5 07:46:59 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 4 Feb 2006 22:46:59 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> Message-ID: <5784286E-636B-4159-97F0-7FB2022A5D26@redivi.com> On Feb 3, 2006, at 12:10 PM, Bob Ippolito wrote: > I think the only things missing from my branch currently are: > > 1) 10.3.9 support I believe this is taken care of now that Ronald contributed the weak linking patch. > 2) Universal PythonLauncher This is done. > 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that in > Python and not hardcode everything) This isn't done yet, but what we have now is probably a fully usable universal Python. > This backwards incompatible change is mostly just a backport from > setuptools' pkg_resources module. > > $ python -c "from distutils.util import get_platform as p; print p()" > macosx-10.4.3-fat This output will now be: macosx-10.3-fat The version number is determined from MACOSX_DEPLOYMENT_TARGET (or CONFIGURE_MACOSX_DEPLOYMENT_TARGET). It's relatively safe to assume that modules compiled with this build will be compatible with Mac OS X 10.3.9 (as long as they don't use 10.4 specific features anyway). For modules that absolutely require 10.4 you can set the MACOSX_DEPLOYMENT_TARGET environment variable at build time (e.g. in setup.py) and then the package produced will have a different platform string. setuptools will need work if people actually do this, because it will need to know that a Mac OS X 10.4 user can use "macosx-10.3-fat" and "macosx-10.4-fat" packages. It's probably a better idea to just write all your code so that it uses weak symbols for anything that isn't in 10.3 and raises ImportError on initialization if it's not usable. On another note, I also moved the HAVE_BROKEN_POLL check to runtime instead of compile time. Mac OS X 10.4.4's poll isn't broken, so we should be able to use it. I'm not sure which versions of Mac OS X have a broken poll, but the ones that have a working poll will have a select.poll object. This may also benefit other operating systems where poll was broken during compile time but was fixed in some update. -bob From ronaldoussoren at mac.com Sun Feb 5 15:25:14 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 5 Feb 2006 15:25:14 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <5784286E-636B-4159-97F0-7FB2022A5D26@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <5784286E-636B-4159-97F0-7FB2022A5D26@redivi.com> Message-ID: <2E9E9F24-52FB-429D-AD17-43D5E4A21A6B@mac.com> On 5-feb-2006, at 7:46, Bob Ippolito wrote: > > On another note, I also moved the HAVE_BROKEN_POLL check to runtime > instead of compile time. Mac OS X 10.4.4's poll isn't broken, so > we should be able to use it. I'm not sure which versions of Mac OS > X have a broken poll, but the ones that have a working poll will > have a select.poll object. This may also benefit other operating > systems where poll was broken during compile time but was fixed in > some update. .. or the other way around :-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060205/056288ad/attachment.bin From ronaldoussoren at mac.com Sun Feb 5 15:48:36 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 5 Feb 2006 15:48:36 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <5784286E-636B-4159-97F0-7FB2022A5D26@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <5784286E-636B-4159-97F0-7FB2022A5D26@redivi.com> Message-ID: <7EFC7A17-285C-4ED6-8E4C-DF52FDEFD648@mac.com> On 5-feb-2006, at 7:46, Bob Ippolito wrote: > > On Feb 3, 2006, at 12:10 PM, Bob Ippolito wrote: > >> I think the only things missing from my branch currently are: >> >> 1) 10.3.9 support > > I believe this is taken care of now that Ronald contributed the > weak linking patch. If anyone wants support for 10.3.x with x <= 8 now would be the right time to speak up and volunteer resources :-) > >> 2) Universal PythonLauncher > > This is done. > >> 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all that in >> Python and not hardcode everything) > > This isn't done yet, but what we have now is probably a fully > usable universal Python. I'll work on this, I probably still know what needs to be done from when I tried to build a Python 2.4.2 compatible package using this script. > >> This backwards incompatible change is mostly just a backport from >> setuptools' pkg_resources module. >> >> $ python -c "from distutils.util import get_platform as p; print p()" >> macosx-10.4.3-fat > > This output will now be: > macosx-10.3-fat > > The version number is determined from MACOSX_DEPLOYMENT_TARGET (or > CONFIGURE_MACOSX_DEPLOYMENT_TARGET). It's relatively safe to > assume that modules compiled with this build will be compatible > with Mac OS X 10.3.9 (as long as they don't use 10.4 specific > features anyway). I'm not 100% sure I'm happy with this. You can now accidently create binary packages that claim to run on 10.3 yet don't. But as you say, this will likely affect only a very small number of packages (PyObjC being one of those, that's on my TODO list already). > > For modules that absolutely require 10.4 you can set the > MACOSX_DEPLOYMENT_TARGET environment variable at build time (e.g. > in setup.py) and then the package produced will have a different > platform string. setuptools will need work if people actually do > this, because it will need to know that a Mac OS X 10.4 user can > use "macosx-10.3-fat" and "macosx-10.4-fat" packages. It's > probably a better idea to just write all your code so that it uses > weak symbols for anything that isn't in 10.3 and raises ImportError > on initialization if it's not usable. Setuptools already contains code for this (using 10.3 packages on 10.4) in pkg_resources.compatible_platforms for the stock python distribution. That should also work with the python24-fat tree. The only thing that would require work is accepting a cpu-specific version if a fat package is not available. The only reason that might be useful is stuf like psyco which is only available for one of cpu- type. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060205/d8cbc808/attachment.bin From bob at redivi.com Sun Feb 5 19:59:51 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 5 Feb 2006 10:59:51 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <7EFC7A17-285C-4ED6-8E4C-DF52FDEFD648@mac.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <5784286E-636B-4159-97F0-7FB2022A5D26@redivi.com> <7EFC7A17-285C-4ED6-8E4C-DF52FDEFD648@mac.com> Message-ID: <91D52D24-199E-47CD-9CE1-44A49BE3D706@redivi.com> On Feb 5, 2006, at 6:48 AM, Ronald Oussoren wrote: > > On 5-feb-2006, at 7:46, Bob Ippolito wrote: > >> >> On Feb 3, 2006, at 12:10 PM, Bob Ippolito wrote: >> >>> I think the only things missing from my branch currently are: >>> >>> 1) 10.3.9 support >> >> I believe this is taken care of now that Ronald contributed the >> weak linking patch. > > If anyone wants support for 10.3.x with x <= 8 now would be the > right time to speak up and volunteer resources :-) In py2app I should at least be able to give a good error dialog if the app is built with the fat build but the target OS isn't >= 10.3.9, so this isn't all that urgent... >>> 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all >>> that in >>> Python and not hardcode everything) >> >> This isn't done yet, but what we have now is probably a fully >> usable universal Python. > > I'll work on this, I probably still know what needs to be done from > when I tried to build a Python 2.4.2 compatible package using this > script. The "only" thing that needs to be done is to change strings in these files during (or after I guess) frameworkinstall: OSX/Dist/resources/ReadMe.txt OSX/Dist/resources/Welcome.rtf OSX/PythonLauncher/PythonLauncher_app/Contents/Info.plist OSX/PythonLauncher/PythonLauncher_app/Contents/Resources/ factorySettings.plist OSXResources/framework/Info.plist OSXResources/framework/version.plist OSXResources/framework/InfoPlist.strings I was thinking it would be easiest to use string.Template to do this, with a dict populated mostly with distutils.sysconfig information but with a couple extra strings added such as the architectures supported, the full version, and the size of the package after installation. >>> This backwards incompatible change is mostly just a backport from >>> setuptools' pkg_resources module. >>> >>> $ python -c "from distutils.util import get_platform as p; print p >>> ()" >>> macosx-10.4.3-fat >> >> This output will now be: >> macosx-10.3-fat >> >> The version number is determined from MACOSX_DEPLOYMENT_TARGET (or >> CONFIGURE_MACOSX_DEPLOYMENT_TARGET). It's relatively safe to >> assume that modules compiled with this build will be compatible >> with Mac OS X 10.3.9 (as long as they don't use 10.4 specific >> features anyway). > > I'm not 100% sure I'm happy with this. You can now accidently > create binary packages that claim to run on 10.3 yet don't. But as > you say, this will likely affect only a very small number of > packages (PyObjC being one of those, that's on my TODO list already). The only way to check this would be to set MACOSX_MAX_VERSION_REQUIRED to 1030, but that would be bad too because then you couldn't write code that takes advantage of Mac OS X 10.4 features because you'd get a compile time error. In the setuptools branch of PyObjC the 10.3 and 10.4 specific modules are in separate distributions. We could simply set MACOSX_DEPLOYMENT_TARGET to 10.4 in the 10.4 setup.py and then it should build a package that claims 10.4. >> For modules that absolutely require 10.4 you can set the >> MACOSX_DEPLOYMENT_TARGET environment variable at build time (e.g. >> in setup.py) and then the package produced will have a different >> platform string. setuptools will need work if people actually do >> this, because it will need to know that a Mac OS X 10.4 user can >> use "macosx-10.3-fat" and "macosx-10.4-fat" packages. It's >> probably a better idea to just write all your code so that it uses >> weak symbols for anything that isn't in 10.3 and raises >> ImportError on initialization if it's not usable. > > Setuptools already contains code for this (using 10.3 packages on > 10.4) in pkg_resources.compatible_platforms for the stock python > distribution. That should also work with the python24-fat tree. The > only thing that would require work is accepting a cpu-specific > version if a fat package is not available. The only reason that > might be useful is stuf like psyco which is only available for one > of cpu-type. Well the way everything is setup, it's not going to be reasonable to build a package that claims to be specific to a given architecture using the universal Python. We'd need to have Yet Another Distutils Hack that takes the architecture list off of the command line or something and modifies the compiler/linker flags.. ick. We do still need to patch setuptools because distutils.util.get_platform() is going to say 10.3, so we'd need to insert the code that knows what the actual version of the OS is. I can't think of anything that only works on one architecture... even psyco has a C-based ivm that makes some smaller optimizations on non- x86 platforms... -bob From ronaldoussoren at mac.com Sun Feb 5 20:23:16 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 5 Feb 2006 20:23:16 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <91D52D24-199E-47CD-9CE1-44A49BE3D706@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> <02485383-E1FC-41C5-AC38-C8E5339BCC15@redivi.com> <343CBEDD-583D-4A42-ABE0-A2C27246BBAF@mac.com> <1A67F74B-9ED6-4974-8B1A-0D5EF6379905@redivi.com> <00FD052A-E4CD-49F7-A081-FB885A4F9525@redivi.com> <5BCC583D-C6B1-4B76-836B-A606B38DE06B@redivi.com> <5784286E-636B-4159-97F0-7FB2022A5D26@redivi.com> <91D52D24-199E-47CD-9CE1-4! 4A49BE! 3D706@redivi.com> Message-ID: <4B9565D0-652F-4903-BC70-6731C837B452@mac.com> On 5-feb-2006, at 19:59, Bob Ippolito wrote: > On Feb 5, 2006, at 6:48 AM, Ronald Oussoren wrote: > >> >> On 5-feb-2006, at 7:46, Bob Ippolito wrote: >> >>> >>> On Feb 3, 2006, at 12:10 PM, Bob Ippolito wrote: >>> >>>> I think the only things missing from my branch currently are: >>>> >>>> 1) 10.3.9 support >>> >>> I believe this is taken care of now that Ronald contributed the >>> weak linking patch. >> >> If anyone wants support for 10.3.x with x <= 8 now would be the >> right time to speak up and volunteer resources :-) > > In py2app I should at least be able to give a good error dialog if > the app is built with the fat build but the target OS isn't >= > 10.3.9, so this isn't all that urgent... > >>>> 3) Revamped Mac/OSX/Dist scripts (probably should rewrite all >>>> that in >>>> Python and not hardcode everything) >>> >>> This isn't done yet, but what we have now is probably a fully >>> usable universal Python. >> >> I'll work on this, I probably still know what needs to be done >> from when I tried to build a Python 2.4.2 compatible package using >> this script. > > The "only" thing that needs to be done is to change strings in > these files during (or after I guess) frameworkinstall: > > OSX/Dist/resources/ReadMe.txt > OSX/Dist/resources/Welcome.rtf > OSX/PythonLauncher/PythonLauncher_app/Contents/Info.plist > OSX/PythonLauncher/PythonLauncher_app/Contents/Resources/ > factorySettings.plist > OSXResources/framework/Info.plist > OSXResources/framework/version.plist > OSXResources/framework/InfoPlist.strings > > I was thinking it would be easiest to use string.Template to do > this, with a dict populated mostly with distutils.sysconfig > information but with a couple extra strings added such as the > architectures supported, the full version, and the size of the > package after installation. > >>>> This backwards incompatible change is mostly just a backport from >>>> setuptools' pkg_resources module. >>>> >>>> $ python -c "from distutils.util import get_platform as p; print >>>> p()" >>>> macosx-10.4.3-fat >>> >>> This output will now be: >>> macosx-10.3-fat >>> >>> The version number is determined from MACOSX_DEPLOYMENT_TARGET >>> (or CONFIGURE_MACOSX_DEPLOYMENT_TARGET). It's relatively safe to >>> assume that modules compiled with this build will be compatible >>> with Mac OS X 10.3.9 (as long as they don't use 10.4 specific >>> features anyway). >> >> I'm not 100% sure I'm happy with this. You can now accidently >> create binary packages that claim to run on 10.3 yet don't. But as >> you say, this will likely affect only a very small number of >> packages (PyObjC being one of those, that's on my TODO list already). > > The only way to check this would be to set > MACOSX_MAX_VERSION_REQUIRED to 1030, but that would be bad too > because then you couldn't write code that takes advantage of Mac OS > X 10.4 features because you'd get a compile time error. Let's just keep the current behaviour (that is packages claiming that they'll run on 10.3), we can always change this if it turns out that this is a problem. Neither of expects it will be a problem, so we should be safe ;-) > > In the setuptools branch of PyObjC the 10.3 and 10.4 specific > modules are in separate distributions. We could simply set > MACOSX_DEPLOYMENT_TARGET to 10.4 in the 10.4 setup.py and then it > should build a package that claims 10.4. I want to use weak linking in the wrappers to ensure that a single binary distribution will be useable on 10.3 and later without loosing features. That's not rocket-science, but requires some work. > >>> For modules that absolutely require 10.4 you can set the >>> MACOSX_DEPLOYMENT_TARGET environment variable at build time (e.g. >>> in setup.py) and then the package produced will have a different >>> platform string. setuptools will need work if people actually do >>> this, because it will need to know that a Mac OS X 10.4 user can >>> use "macosx-10.3-fat" and "macosx-10.4-fat" packages. It's >>> probably a better idea to just write all your code so that it >>> uses weak symbols for anything that isn't in 10.3 and raises >>> ImportError on initialization if it's not usable. >> >> Setuptools already contains code for this (using 10.3 packages on >> 10.4) in pkg_resources.compatible_platforms for the stock python >> distribution. That should also work with the python24-fat tree. >> The only thing that would require work is accepting a cpu-specific >> version if a fat package is not available. The only reason that >> might be useful is stuf like psyco which is only available for one >> of cpu-type. > > Well the way everything is setup, it's not going to be reasonable > to build a package that claims to be specific to a given > architecture using the universal Python. We'd need to have Yet > Another Distutils Hack that takes the architecture list off of the > command line or something and modifies the compiler/linker flags.. > ick. Time for a MacOSXCompiler class? The hack would have to look at extra_compile_args and extra_link_args, if those contain '-arch' arguments it should strip the architecture calls from the default compile flags. > > We do still need to patch setuptools because > distutils.util.get_platform() is going to say 10.3, so we'd need to > insert the code that knows what the actual version of the OS is. If you need to specify another platform you can use a setuptools- specific argument in setup.py. > > I can't think of anything that only works on one architecture... > even psyco has a C-based ivm that makes some smaller optimizations > on non-x86 platforms... Yet another thing not to worry about then :-) Ronald > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060205/c6523fa3/attachment-0001.bin From bob at redivi.com Sun Feb 5 23:00:20 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 5 Feb 2006 14:00:20 -0800 Subject: [Pythonmac-SIG] pkg_resources and Mac OS X compatibility In-Reply-To: <6D4EE44B-ECA5-4014-B339-16BB6DA4CE3A@redivi.com> References: <6D4EE44B-ECA5-4014-B339-16BB6DA4CE3A@redivi.com> Message-ID: <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> With the way that we're returning the distutils platform on the universal branch of Mac OS X, we need another patch to pkg_resources. The reason for this is that distutils.util.get_platform() returns the platform that it is trying to produce binaries for, which is often not the exact current platform. More specifically, our current strategy is to produce a version of Python that will build extensions that are compatible with Mac OS X 10.3, but the actual building of extensions requires Mac OS X 10.4 or later (because the toolchain doesn't exist on Mac OS X 10.3). In some rare cases, people will want to produce packages that explicitly require Mac OS X 10.4 or later, which they can do by setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when running setup.py. This will influence the value returned by disutils.util.get_platform(), and will influence the compiler and linker if extensions are built. This patch adds an internal _get_max_platform(plat) function that returns the actual runtime version of Mac OS X, for use in compatible_platforms. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: setuptools-r42250-fat.patch Type: application/octet-stream Size: 1239 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060205/ea316c35/attachment.obj From bob at redivi.com Sun Feb 5 23:07:33 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 5 Feb 2006 14:07:33 -0800 Subject: [Pythonmac-SIG] pkg_resources and Mac OS X compatibility In-Reply-To: <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> References: <6D4EE44B-ECA5-4014-B339-16BB6DA4CE3A@redivi.com> <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> Message-ID: <9FF4B86E-D69B-4749-8347-D76A4708E1E2@redivi.com> On Feb 5, 2006, at 2:00 PM, Bob Ippolito wrote: > With the way that we're returning the distutils platform on the > universal branch of Mac OS X, we need another patch to > pkg_resources. The reason for this is that > distutils.util.get_platform() returns the platform that it is > trying to produce binaries for, which is often not the exact > current platform. More specifically, our current strategy is to > produce a version of Python that will build extensions that are > compatible with Mac OS X 10.3, but the actual building of > extensions requires Mac OS X 10.4 or later (because the toolchain > doesn't exist on Mac OS X 10.3). > > In some rare cases, people will want to produce packages that > explicitly require Mac OS X 10.4 or later, which they can do by > setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when > running setup.py. This will influence the value returned by > disutils.util.get_platform(), and will influence the compiler and > linker if extensions are built. > > This patch adds an internal _get_max_platform(plat) function that > returns the actual runtime version of Mac OS X, for use in > compatible_platforms. Oops, wrong patch.. here's the correct one. Sorry about that: -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: setuptools-r42250-fat-1.patch Type: application/octet-stream Size: 1250 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060205/1fb218d0/attachment.obj From samrobertsmith at gmail.com Mon Feb 6 09:34:45 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 00:34:45 -0800 Subject: [Pythonmac-SIG] not appear Message-ID: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> Hi there, The version of My Mac is Mac OX 10.4.4; I guess that Python 2.3.5 came with the Mac OX10.4.4 I wanted to install Python 2.4.2; It worked fine till "Make Install". After I reentered the terminal, I still saw Python 2.3.5 instead of 2.4.2. Ver confused... From pythonmac at justinmitchell.net Mon Feb 6 10:05:34 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Mon, 6 Feb 2006 04:05:34 -0500 Subject: [Pythonmac-SIG] not appear In-Reply-To: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> Message-ID: <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> On 2/6/06, linda.s wrote: > Hi there, > The version of My Mac is > Mac OX 10.4.4; I guess that Python 2.3.5 came with the Mac OX10.4.4 > I wanted to install Python 2.4.2; It worked fine till "Make > Install". After I reentered the terminal, I still saw Python 2.3.5 > instead of 2.4.2. > Ver confused... I haven't tried installing it from source, but my guess is that it installed python with the '/usr/local' prefix, which means that the python binary would be in /usr/local/bin/python. If not, try "which python" to see if it's somewhere else in your path. Justin From samrobertsmith at gmail.com Mon Feb 6 10:20:46 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 01:20:46 -0800 Subject: [Pythonmac-SIG] not appear In-Reply-To: <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> Message-ID: <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> On 2/6/06, Justin Mitchell wrote: > On 2/6/06, linda.s wrote: > > Hi there, > > The version of My Mac is > > Mac OX 10.4.4; I guess that Python 2.3.5 came with the Mac OX10.4.4 > > I wanted to install Python 2.4.2; It worked fine till "Make > > Install". After I reentered the terminal, I still saw Python 2.3.5 > > instead of 2.4.2. > > Ver confused... > > I haven't tried installing it from source, but my guess is that it > installed python with the '/usr/local' prefix, which means that the > python binary would be in /usr/local/bin/python. If not, try "which > python" to see if it's somewhere else in your path. > > Justin Thanks. Two questions: How to install Python 2.4.2 without installing form source? I could not find the file. Where is the bin directory (I could not find it) Thanks a lot for the help. Linda From pythonmac at justinmitchell.net Mon Feb 6 10:36:38 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Mon, 6 Feb 2006 04:36:38 -0500 Subject: [Pythonmac-SIG] not appear In-Reply-To: <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> Message-ID: <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> On 2/6/06, linda.s wrote: > On 2/6/06, Justin Mitchell wrote: > > On 2/6/06, linda.s wrote: > > > Hi there, > > > The version of My Mac is > > > Mac OX 10.4.4; I guess that Python 2.3.5 came with the Mac OX10.4.4 > > > I wanted to install Python 2.4.2; It worked fine till "Make > > > Install". After I reentered the terminal, I still saw Python 2.3.5 > > > instead of 2.4.2. > > > Ver confused... > > > > I haven't tried installing it from source, but my guess is that it > > installed python with the '/usr/local' prefix, which means that the > > python binary would be in /usr/local/bin/python. If not, try "which > > python" to see if it's somewhere else in your path. > > > > Justin > Thanks. > Two questions: > How to install Python 2.4.2 without installing form source? I could > not find the file. > Where is the bin directory (I could not find it) > Thanks a lot for the help. > Linda I just used the 2.4.1 release found here: http://undefined.org/python/ - Justin From samrobertsmith at gmail.com Mon Feb 6 10:40:58 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 01:40:58 -0800 Subject: [Pythonmac-SIG] not appear In-Reply-To: <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> Message-ID: <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> > I just used the 2.4.1 release found here: http://undefined.org/python/ > > - Justin Thanks. Just curious, where is the bin directory (I could not find it)? L. From samrobertsmith at gmail.com Mon Feb 6 10:46:36 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 01:46:36 -0800 Subject: [Pythonmac-SIG] install again? Message-ID: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> How to smoothly remove two former pythons from my Mac? I have Python 2.3.5 installed in the machine. I tried to install Python 2.4.2 from source but it did not appear. How can I smoothly remove both of them and install a another python version? Thanks! Linda From david.warde.farley at utoronto.ca Mon Feb 6 10:54:54 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Mon, 6 Feb 2006 04:54:54 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> Message-ID: On 6-Feb-06, at 4:46 AM, linda.s wrote: > How to smoothly remove two former pythons from my Mac? > I have Python 2.3.5 installed in the machine. I tried to install > Python 2.4.2 from source but it did not appear. > How can I smoothly remove both of them and install a another python > version? You shouldn't try to remove 2.3.5; that's Apple's Python, leave it alone. As for the "installed from source" one, it would've been overwritten by the binary packaged one. Does this mean you got Python 2.4 from binary working? - David From samrobertsmith at gmail.com Mon Feb 6 11:00:16 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 02:00:16 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> Message-ID: <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> On 2/6/06, David Warde-Farley wrote: > > On 6-Feb-06, at 4:46 AM, linda.s wrote: > > > How to smoothly remove two former pythons from my Mac? > > I have Python 2.3.5 installed in the machine. I tried to install > > Python 2.4.2 from source but it did not appear. > > How can I smoothly remove both of them and install a another python > > version? > > You shouldn't try to remove 2.3.5; that's Apple's Python, leave it > alone. > > As for the "installed from source" one, it would've been overwritten > by the binary packaged one. > > Does this mean you got Python 2.4 from binary working? > > - David > Actually I downloaded python 2.4.2 and install it from source. The installation appeared to be fine until "make install" was complete. However, after I reenter the terminal and call Python, it still showed Python 2.3.5 instead of Python 2.4.2, very confused... Some one suggested me to download MacPython. So I am thinking about removing the Python 2.4.2 from my machine (still curious why it did not appear). L. From david.warde.farley at utoronto.ca Mon Feb 6 11:06:20 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Mon, 6 Feb 2006 05:06:20 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> Message-ID: <5FD4CAF6-1CBD-45DC-82E7-8CE0590EABD8@utoronto.ca> On 6-Feb-06, at 5:00 AM, linda.s wrote: > Actually I downloaded python 2.4.2 and install it from source. The > installation appeared to be fine until "make install" was complete. > However, after I reenter the terminal and call Python, it still showed > Python 2.3.5 instead of Python 2.4.2, very confused... Some one > suggested me to download MacPython. So I am thinking about removing > the Python 2.4.2 from my machine (still curious why it did not > appear). > L. You need to make sure /usr/local/bin is in your path before /usr/bin. To do this if your shell is bash, type export PATH=/usr/local/bin:$PATH or in tcsh setenv PATH /usr/local/bin:$PATH You should add one of these lines to your startup file (.bash_profile if you're using bash, I don't know the tcsh equivalent) so that this is the default for new terminals. This should be better documented somewhere... - David From charles.hartman at conncoll.edu Mon Feb 6 13:42:45 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 6 Feb 2006 07:42:45 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> Message-ID: On Feb 6, 2006, at 5:00 AM, linda.s wrote: > Python 2.3.5 instead of Python 2.4.2, very confused... Some one > suggested me to download MacPython. So I am thinking about removing > the Python 2.4.2 from my machine (still curious why it did not > appear). You just want to change your PATH. If your built-from-scratch is ok, pointing directly to it to run it (on the command line or in the PATH) will work. If not, install the binary. coh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060206/c314335e/attachment.htm From samrobertsmith at gmail.com Mon Feb 6 13:52:54 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 04:52:54 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> Message-ID: <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> On 2/6/06, Charles Hartman wrote: > > > On Feb 6, 2006, at 5:00 AM, linda.s wrote: > > Python 2.3.5 instead of Python 2.4.2, very confused... Some one > suggested me to download MacPython. So I am thinking about removing > the Python 2.4.2 from my machine (still curious why it did not > appear). > You just want to change your PATH. If your built-from-scratch is ok, > pointing directly to it to run it (on the command line or in the PATH) will > work. If not, install the binary. > > coh Yes. It works after I type export PATH=/usr/local/bin:$PATH. But next time if I open the terminal, I need do it again. How can I make it permanent? Linda. From Larry.A.Meyn at nasa.gov Mon Feb 6 14:46:28 2006 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Mon, 6 Feb 2006 05:46:28 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> Message-ID: <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> Create the following text file and save it as ".bash_profile" in your home directory. --Larry # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=/usr/local/bin:/$PATH;export PATH # End of File On Feb 6, 2006, at 4:52 AM, linda.s wrote: > On 2/6/06, Charles Hartman wrote: >> >> >> On Feb 6, 2006, at 5:00 AM, linda.s wrote: >> >> Python 2.3.5 instead of Python 2.4.2, very confused... Some one >> suggested me to download MacPython. So I am thinking about removing >> the Python 2.4.2 from my machine (still curious why it did not >> appear). >> You just want to change your PATH. If your built-from-scratch is ok, >> pointing directly to it to run it (on the command line or in the >> PATH) will >> work. If not, install the binary. >> >> coh > Yes. It works after I type export PATH=/usr/local/bin:$PATH. > But next time if I open the terminal, I need do it again. > How can I make it permanent? > Linda. > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060206/e4999858/attachment.html From samrobertsmith at gmail.com Mon Feb 6 15:14:00 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 06:14:00 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> Message-ID: <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> On 2/6/06, Larry Meyn wrote: > Create the following text file and save it as ".bash_profile" in your home > directory. > --Larry > > # .bash_profile > > # Get the aliases and functions > if [ -f ~/.bashrc ]; then > . ~/.bashrc > fi > > # User specific environment and startup programs > > PATH=/usr/local/bin:/$PATH;export PATH > > # End of File It did not work from the creating of .bash_profile. If I typed "export PATH=/usr/local/bin:$PATH." It worked in the command line but it did not work in the code. From pecora at anvil.nrl.navy.mil Mon Feb 6 15:26:49 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon, 06 Feb 2006 09:26:49 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> Message-ID: <43E75CA9.7090504@anvil.nrl.navy.mil> linda.s wrote: > On 2/6/06, Larry Meyn wrote: > >> Create the following text file and save it as ".bash_profile" in your home >> directory. >> --Larry >> >> # .bash_profile >> >> # Get the aliases and functions >> if [ -f ~/.bashrc ]; then >> . ~/.bashrc >> fi >> >> # User specific environment and startup programs >> >> PATH=/usr/local/bin:/$PATH;export PATH >> >> # End of File >> > It did not work from the creating of .bash_profile. If I typed > "export PATH=/usr/local/bin:$PATH." It worked in the command line but > it did not work in the code. > _______________________________________________ > Did you open a new terminal window after you edited the .bash_profile ? That's when .profile type files are 'run', i.e. only at the start of a terminal session. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From charles.hartman at conncoll.edu Mon Feb 6 15:43:48 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 6 Feb 2006 09:43:48 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E75CA9.7090504@anvil.nrl.navy.mil> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> Message-ID: <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> Hence, yet again, a plea for newbies everywhere: I continue to believe that it really, really shouldn't be necessary for people who want to write programs in Python for the Mac to do all this. Great to learn as much as possible, yes, always -- but to require people, just to get started, to learn about shells and the Terminal, which they may never have dealt with before, even if they have a variety of Mac programming experience, is not to put Python on its best footing. Charles On Feb 6, 2006, at 9:26 AM, Louis Pecora wrote: > linda.s wrote: >> On 2/6/06, Larry Meyn wrote: >> >>> Create the following text file and save it as ".bash_profile" in >>> your home >>> directory. >>> --Larry >>> >>> # .bash_profile >>> >>> # Get the aliases and functions >>> if [ -f ~/.bashrc ]; then >>> . ~/.bashrc >>> fi >>> >>> # User specific environment and startup programs >>> >>> PATH=/usr/local/bin:/$PATH;export PATH >>> >>> # End of File >>> >> It did not work from the creating of .bash_profile. If I typed >> "export PATH=/usr/local/bin:$PATH." It worked in the command line but >> it did not work in the code. >> _______________________________________________ >> > > Did you open a new terminal window after you edited > the .bash_profile ? > That's when .profile type files are 'run', i.e. only at the start > of a > terminal session. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060206/b0185d77/attachment-0001.htm From samrobertsmith at gmail.com Mon Feb 6 15:45:52 2006 From: samrobertsmith at gmail.com (linda.s) Date: Mon, 6 Feb 2006 06:45:52 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E75CA9.7090504@anvil.nrl.navy.mil> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> Message-ID: <1d987df30602060645s575c0625x782e2fdb25e9bb48@mail.gmail.com> On 2/6/06, Louis Pecora wrote: > linda.s wrote: > > On 2/6/06, Larry Meyn wrote: > > > >> Create the following text file and save it as ".bash_profile" in your home > >> directory. > >> --Larry > >> > >> # .bash_profile > >> > >> # Get the aliases and functions > >> if [ -f ~/.bashrc ]; then > >> . ~/.bashrc > >> fi > >> > >> # User specific environment and startup programs > >> > >> PATH=/usr/local/bin:/$PATH;export PATH > >> > >> # End of File > >> > > It did not work from the creating of .bash_profile. If I typed > > "export PATH=/usr/local/bin:$PATH." It worked in the command line but > > it did not work in the code. > > _______________________________________________ > > > > Did you open a new terminal window after you edited the .bash_profile ? > That's when .profile type files are 'run', i.e. only at the start of a > terminal session. > > -- > Cheers, > > Lou Pecora Yes. I did that. No Python 2.4.2 until type the command into command list. Linda. From sw at wordtech-software.com Mon Feb 6 16:06:42 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon, 06 Feb 2006 10:06:42 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> Message-ID: <43E76602.8040405@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles Hartman wrote: > Hence, yet again, a plea for newbies everywhere: > > I continue to believe that it really, really shouldn't be necessary for > people who want to write programs in Python for the Mac to do all this. > Great to learn as much as possible, yes, always -- but to require > people, just to get started, to learn about shells and the Terminal, > which they may never have dealt with before, even if they have a variety > of Mac programming experience, is not to put Python on its best footing. > It *isn't* necessary to do all that. Just use the vendor-provided Python, type "python" in your shell, and you are ready to go. However, there are limits to how much complexity can be hidden. Under the hood, OS X is Unix, and if you want to program in a Unix environment, that requires a certain amount of knowledge. There's just no way around it. Additionally, if one has "a variety of Mac programming experience," then learning the conventions of the Unix shell shouldn't prove too difficult. The only exception to this that I can think of is if one's Mac programming experience consists solely of AppleScript. Just to continue the conversation, what do *you* think is the best approach? How should Python be made easier than it already is (and, frankly, compared to C, it's pretty easy)? What special difficulties or obstacles does the Mac platform present to learning Python that are not also present on other platforms? - -- Cheers, Kevin Walzer, PhD WordTech Software - "Tame the Terminal" http://www.wordtech-software.com sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD52YCJmdQs+6YVcoRAnmpAJ9U26KfdoTRqfnwEaHfhm5MAgp+PgCdFDyw ziWilLVNw4Y6X0JyTXuDJNI= =OY0G -----END PGP SIGNATURE----- From charles.hartman at conncoll.edu Mon Feb 6 16:43:55 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 6 Feb 2006 10:43:55 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E76602.8040405@wordtech-software.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> Message-ID: <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> Oh well, "other platforms" -- if that means Linux of course you have to learn those same things, but you undoubtedly already know them. If it means Windows, I'd rather drive a truck, and I'm thinking particularly of potential users who feel the same way. There are a lot of programming environments on the Mac besides Applescript that work from the GUI without any need to delve. Runtime Revolution and Breve are two examples that come to mind immediately. I'm thinking, for example, of someone who has worked in one of those very-high-level environments and wants to deepen her/his understanding and control. Turn to C, or rather C++? Oh dear. So how about Python? I think it's a great, an ideal choice. These are the people who, 25 years ago, would have picked up Turbo Pascal and gotten a great start on a lifelong obsession. Python should get them (and vice versa). But while Tiger comes with Python, the moment you look for (for example) a GUI library, you learn that there's a much-superior Python (2.4), for which you can download a nice, familiar binary from Bob's site or from ActiveState. Good. And you can download a binary of (for example) wxPython. Good. And then you have to do this Terminal stuff. No, the Terminal stuff isn't difficult. You find out (though as I recall it is *not* immediately obvious) that there are only a few simple things you need to learn to do. The point is that you're now engaged, however peripherally, with a whole other huge set of questions and conditions, and suddenly the learning curve for Python *looks* much steeper. The problem, as I see it, is that you encounter this stuff right at the very beginning. Everything for getting started with Python is off-the-shelf easy -- except of course that to get it running you just have to add the following lines to your profile and . . . what?? You start looking at docs, and quickly encounter references to directories that you can't even find among the folders on your OSX filesystem. Of course OSX is Unix "under the hood"; but not everybody -- not even everybody interested in programming the Mac -- has gone into the dark spaces under the hood. The alternative to "under the hood" includes a lot more than just pushing buttons to get & send email, though this may be hard to remember once you've gone under the hood . . . I don't know, maybe I was just traumatized at an early age (or rather a late one). I got over it, and I suppose everyone else can too. I'm the wrong person to ask. Maybe linda.s might have a more useful perspective at this point? Charles On Feb 6, 2006, at 10:06 AM, Kevin Walzer wrote: > Just to continue the conversation, what do *you* think is the best > approach? How should Python be made easier than it already is (and, > frankly, compared to C, it's pretty easy)? What special > difficulties or > obstacles does the Mac platform present to learning Python that are > not > also present on other platforms? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060206/00b71ce3/attachment.html From sw at wordtech-software.com Mon Feb 6 17:19:54 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon, 06 Feb 2006 11:19:54 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> Message-ID: <43E7772A.1000705@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles Hartman wrote: > > There are a lot of programming environments on the Mac besides > Applescript that work from the GUI without any need to delve. Runtime > Revolution and Breve are two examples that come to mind immediately. I'm > thinking, for example, of someone who has worked in one of those > very-high-level environments and wants to deepen her/his understanding > and control. I haven't heard of breve, but RunRev is an expensive, proprietary IDE. One of the things you get for the dollars you spend is button-pushing convenience: everything is there, easily accessed. You can just start coding without fiddling with configuration. And because you're paying several hundred dollars for the full-featured IDE, that's the way it should be. You're paying someone else to sweat the details of implementation. > No, the Terminal stuff isn't difficult. You find out (though as I recall > it is *not* immediately obvious) that there are only a few simple things > you need to learn to do. The point is that you're now engaged, however > peripherally, with a whole other huge set of questions and conditions, > and suddenly the learning curve for Python *looks* much steeper. The > problem, as I see it, is that you encounter this stuff right at the very > beginning. Everything for getting started with Python is off-the-shelf > easy -- except of course that to get it running you just have to add the > following lines to your profile and . . . what?? You start looking at > docs, and quickly encounter references to directories that you can't > even find among the folders on your OSX filesystem. I suppose if some company saw a business case for it--i.e., people would buy it--then they could package up a binary distribution of Python that handles *all* of the implementation details, i.e. it not only installs everything in the right place but configures your environment for you, and also makes it easy to install extension packages, and perhaps even provides a slick IDE on top of it. But really, the binary distributions provided by Bob and ActiveState and Robin accomplish about 80% of this already. What's required from the user, under this scenario, is a small investment of time (as compared to a large investment of time building everything yourself, or a large investment of dollars buying a fully-configured environment). Not to mention: Bob and Ronald and others are sweating all the details, on-list, of getting Python to build as a universal binary. I sure wouldn't want to have to figure that out for myself. Kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD53cpJmdQs+6YVcoRAk2AAKCJnV0K/ipaPE2i76s2h0MJg3RsgACeMCTA SBsSZDzWbObqx5lvegCb+hU= =6gg+ -----END PGP SIGNATURE----- From charles.hartman at conncoll.edu Mon Feb 6 17:24:07 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 6 Feb 2006 11:24:07 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E7772A.1000705@wordtech-software.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7772A.1000705@wordtech-software.com> Message-ID: <26DA8C0D-74A8-4C40-AAA2-648D4F033AE3@conncoll.edu> Of course I don't disagree with any of this (except that a version of Revolution is available under academic license for about $60 as I recall). *Certainly* I'm grateful for the work Bob, Ronald, and others are doing to make the whole edifice stand up. I'm not complaining. I'm speculating that if the (rather small) gaps in the unpack-it-and-run scenario were filled, there might be a useful additonal user base for Python on the Mac. That's all. Charles On Feb 6, 2006, at 11:19 AM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Charles Hartman wrote: >> >> There are a lot of programming environments on the Mac besides >> Applescript that work from the GUI without any need to delve. Runtime >> Revolution and Breve are two examples that come to mind >> immediately. I'm >> thinking, for example, of someone who has worked in one of those >> very-high-level environments and wants to deepen her/his >> understanding >> and control. > > I haven't heard of breve, but RunRev is an expensive, proprietary IDE. > One of the things you get for the dollars you spend is button-pushing > convenience: everything is there, easily accessed. You can just start > coding without fiddling with configuration. And because you're paying > several hundred dollars for the full-featured IDE, that's the way it > should be. You're paying someone else to sweat the details of > implementation. > > >> No, the Terminal stuff isn't difficult. You find out (though as I >> recall >> it is *not* immediately obvious) that there are only a few simple >> things >> you need to learn to do. The point is that you're now engaged, >> however >> peripherally, with a whole other huge set of questions and >> conditions, >> and suddenly the learning curve for Python *looks* much steeper. The >> problem, as I see it, is that you encounter this stuff right at >> the very >> beginning. Everything for getting started with Python is off-the- >> shelf >> easy -- except of course that to get it running you just have to >> add the >> following lines to your profile and . . . what?? You start looking at >> docs, and quickly encounter references to directories that you can't >> even find among the folders on your OSX filesystem. > > I suppose if some company saw a business case for it--i.e., people > would > buy it--then they could package up a binary distribution of Python > that > handles *all* of the implementation details, i.e. it not only installs > everything in the right place but configures your environment for you, > and also makes it easy to install extension packages, and perhaps even > provides a slick IDE on top of it. > > But really, the binary distributions provided by Bob and > ActiveState and > Robin accomplish about 80% of this already. What's required from the > user, under this scenario, is a small investment of time (as > compared to > a large investment of time building everything yourself, or a large > investment of dollars buying a fully-configured environment). > > Not to mention: Bob and Ronald and others are sweating all the > details, > on-list, of getting Python to build as a universal binary. I sure > wouldn't want to have to figure that out for myself. > > Kevin > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFD53cpJmdQs+6YVcoRAk2AAKCJnV0K/ipaPE2i76s2h0MJg3RsgACeMCTA > SBsSZDzWbObqx5lvegCb+hU= > =6gg+ > -----END PGP SIGNATURE----- From daniel at brightfire.com Mon Feb 6 17:03:36 2006 From: daniel at brightfire.com (Daniel Lord) Date: Mon, 6 Feb 2006 08:03:36 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 19 In-Reply-To: References: Message-ID: <9E29FFC1-6EEA-4FFD-9251-3A02067DE18B@brightfire.com> > > From: Charles Hartman > Date: 6 February 2006 06:43:48 GMT-08:00 > To: Louis Pecora > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] install again? > > > Hence, yet again, a plea for newbies everywhere: > > I continue to believe that it really, really shouldn't be necessary > for people who want to write programs in Python for the Mac to do > all this. Great to learn as much as possible, yes, always -- but to > require people, just to get started, to learn about shells and the > Terminal, which they may never have dealt with before, even if they > have a variety of Mac programming experience, is not to put Python > on its best footing. You don't have to do this to get started. This only became necessary because the person installed a non-official Python release. Stick with the default version Apple ships and it is indeed simple--one need do none of this. I understand the frustration and confusion over having to delve into some of the technical details regarding command search ordering, but every operating system solves the problem in a technical way (even Windows) although it is transparent to the average user when it gives the expected results. Installing two version of Microsoft Words on Windows will cause the same problem--one has to be set to be the default and the other will take a little or even a lot of work to run. Microsoft will try to prevent two versions from being installed to avoid this problem. In fact, Windows annoys me often when launching non-Microsoft applications to ask if I wouldn't rather have Microsoft's application set as the default. In this case Microsoft is trying to keep the command searching straight for you--but only because these are end-user applications that are launched transparently without the command line. Microsoft WIndows provides no help when looking for commands from the DOS Shell either. In fact, there is a lot more information available on UNIX for free than for the inner working of WIndows. As for Apple and Python: Apple supports Python just fine-only one version of Python comes installed and it is always found from the command line. By installing 2.4, a user has installed a non-Apple- official version so the user has to take responsibility for setting it up properly. Apple has a rigorous testing process and releases software when they are ready for fully support it for their environment. Because 2.3 is the official Apple version, the creators of the 2.4 binary package did not want to overwrite 2.3 and assume the liability for the users system. Imagine how much more frustrated you'd be if that happened and then something broke? If one wants to 'push' the metaphorical envelope and run a non- official version of Python, one must accept the risk that one may make mistakes and also take on the additional burden of educating oneself to avoid problems. There is an assumption that when one is using development tools, one knows a bit more of the technical details on using the operating system. If one doesn't understand the PATH environment variable, then the concept of site-packages and module scope and precedence and searching fundamental to Python will be lost as well--they are very similar. There are many informative, well-written tutorials out on the web one can use to learn about the UNIX environment, the BASH shell and it is easy to create an environment where one can run both 2.3 and 2.4 safely. take a deep breath and devote 15 minutes to reading one. It will benefit you greatly I promise. Many Python books also describe setting up one's environment. But no one is forcing you to. If the added effort is not to your liking, I'd suggest you stay with 2.3 and keep it simple. But don't blame Python, Apple, or the great group of folks here who unselfishly keep Mac Python going. Daniel Lord Intro to Shell variables and path: http://heather.cs.ucdavis.edu/ ~matloff/UnixAndC/Unix/ShellIntro.html Learn about these commands: which, echo $PATH, alias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060206/928106de/attachment-0001.htm From pythonmac at justinmitchell.net Mon Feb 6 20:27:00 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Mon, 6 Feb 2006 14:27:00 -0500 Subject: [Pythonmac-SIG] not appear In-Reply-To: <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> Message-ID: <220f68650602061127v515abc2frc20068199a471143@mail.gmail.com> On 2/6/06, linda.s wrote: > > I just used the 2.4.1 release found here: http://undefined.org/python/ > > > > - Justin > > Thanks. > Just curious, where is the bin directory (I could not find it)? > L. > I thought it was /usr/local/bin/python. If not, try using "locate" to find it. If your locate database hasn't been updated, but "sudo /usr/libexec/locate.updatedb" first. - Justin From bob at redivi.com Mon Feb 6 20:36:11 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 6 Feb 2006 11:36:11 -0800 Subject: [Pythonmac-SIG] not appear In-Reply-To: <220f68650602061127v515abc2frc20068199a471143@mail.gmail.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> <220f68650602061127v515abc2frc20068199a471143@mail.gmail.com> Message-ID: <618D3674-95E8-4636-9D59-18126A5DB815@redivi.com> On Feb 6, 2006, at 11:27 AM, Justin Mitchell wrote: > On 2/6/06, linda.s wrote: >>> I just used the 2.4.1 release found here: http://undefined.org/ >>> python/ >>> >>> - Justin >> >> Thanks. >> Just curious, where is the bin directory (I could not find it)? >> L. >> > > I thought it was /usr/local/bin/python. If not, try using "locate" to > find it. If your locate database hasn't been updated, but "sudo > /usr/libexec/locate.updatedb" first. The framework build's bin directory is technically way down inside the framework, but there are symlinks in /usr/local/bin. -bob From Chris.Barker at noaa.gov Mon Feb 6 21:00:27 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 06 Feb 2006 12:00:27 -0800 Subject: [Pythonmac-SIG] not appear In-Reply-To: <618D3674-95E8-4636-9D59-18126A5DB815@redivi.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> <220f68650602061127v515abc2frc20068199a471143@mail.gmail.com> <618D3674-95E8-4636-9D59-18126A5DB815@redivi.com> Message-ID: <43E7AADB.4000507@noaa.gov> Bob Ippolito wrote: > The framework build's bin directory is technically way down inside > the framework, but there are symlinks in /usr/local/bin. However: linda.s wrote: > The > installation appeared to be fine until "make install" was complete. So it looks like the OP didn't do a Framework build. What all this means is that you shouldn't build from source unless you know what you are doing, and have a good reason to. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From janssen at parc.com Mon Feb 6 21:09:43 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 6 Feb 2006 12:09:43 PST Subject: [Pythonmac-SIG] install again? In-Reply-To: Your message of "Mon, 06 Feb 2006 07:06:42 PST." <43E76602.8040405@wordtech-software.com> Message-ID: <06Feb6.120952pst."58633"@synergy1.parc.xerox.com> Kevin Walzer replies to Charles Hartman: > Charles Hartman wrote: > > Hence, yet again, a plea for newbies everywhere: > > > > I continue to believe that it really, really shouldn't be necessary for > > people who want to write programs in Python for the Mac to do all this. > > Great to learn as much as possible, yes, always -- but to require > > people, just to get started, to learn about shells and the Terminal, > > which they may never have dealt with before, even if they have a variety > > of Mac programming experience, is not to put Python on its best footing. > > > > It *isn't* necessary to do all that. Just use the vendor-provided > Python, type "python" in your shell, and you are ready to go. And where does the newbie find that info? Here's what a newbie sees when they follow the MacPython link on www.python.org: (in bold) "Download Python for Macintosh" implying that you need to *do* that! Followed by: "Through version 2.3, Python for the Macintosh was maintained by Jack Jansen. See Jack's MacPython Page." The last updates here were done in 2004. None of the python.org pages point to pythonmac.org. And pythonmac.org is still organized around the idea that you have to install Python on a Mac before using it. Jack Jansen's now-out-of-date pages lead the parade on pythonmac.org. The next problem comes in when you want something out of the stdlib, like PIL or Numeric. Everybody packaging for MacOS X isn't packaging for the 2.3.5 supplied Python; instead, there are package managers and Python2.4Fixes and eggs and nobody-quite-knows-what to install and master if you want to use one of these additional tools. Not really true, of course, but that's what it looks like. It's a mess. I've been using Python since 1992, and I still am not sure that I understand what the MacPython community is doing, though I'm sure that the technical content of whatever it is that they are doing is great! So I just use the 2.3.5 standard Apple install, and download and build every non-standard package from scratch. Bill From Chris.Barker at noaa.gov Mon Feb 6 21:15:22 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 06 Feb 2006 12:15:22 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> Message-ID: <43E7AE5A.6070600@noaa.gov> Charles Hartman wrote: > Maybe linda.s might have a more useful perspective > at this point? Charles, I totally agree with you about newbies and Python. However, linda.s compiled python from source. Anyone who is compiling from source should darn well be able to figure out how to add something to her path. Which brings up the question: why did linda.s compile the source? I'm going to make a guess that she didn't have a good reason, but didn't find the binary installers right away. What this means is that much of the problem is documentation. This has been talked about before, and I think everyone agree that we need to improve it, but someone needs to do it. One other point: right now there are two "recommended" binaries for OS-X: Bob's 2.4.1 framework build ActiveState's 2.4.2 framework build. However, Bob's is not the latest, and ActiveState's comes with licensing restrictions and no readline. So there is no ideal build right now. Bob is working on a Universal build at the moment, and it will be the latest, so hopefully we will soon have a single binary installer that we can recommend to newbies. Daniel Lord wrote: > As for Apple and Python: Apple supports Python just fine- No, they don't. They don't keep it up to date, they are unlikely to keep backward compatibility, and they provide no way to do GUI programmer (not quite true, I think they provided an out-of-date version of wxPython with Tiger). A large fraction of folks wanting to program on the mac will want to do GUI programming. You are also very likely to need additional packages, so that needs to be easy also. > By installing 2.4, a user has installed a > non-Apple-official version so the user has to take responsibility for > setting it up properly. I think Charles point is that the user shouldn't need to take that responsibility, the packager could instead. > Because 2.3 is the official Apple version, the creators of > the 2.4 binary package did not want to overwrite 2.3 and assume the > liability for the users system. Actually, it's also because Apple has included some closed source stuff in their Python. Replacing it without that WOULD break some things. > There is an assumption that when one is using development > tools, one knows a bit more of the technical details on using the > operating system. This is quite true. I think Charles is right, that Python could be a great newbie-friendly development tool for OS-X, but that would require fixing more than this. Really, it would be great if someone bundles up a good python distribution with a good IDE and a good GUI library (PyObjC or wxPython or TKinter). Add some good docs and viola! I think this could even be commercially viable, but someone's got to do it. In the meantime, I do think with a little work, we can make it easier. > But don't blame Python, Apple, or > the great group of folks here who unselfishly keep Mac Python going. I don't think there is blaming: more like expression of frustration and suggestions for improvement. Charles, if you want to help, here's my suggestion: Re-write the main pythonmac.org page, then post your version to this list for discussion. If it is well liked, Bob has already said he'd be glad to replace the current page. Here are my suggestions for a how to write that page: Welcome to Python on the Mac! Intro- links to other python resources, etc. What Python should I use? -- brief discussion of the options. --The "Recommended Option" -- for users without special needs or newbies that don't know what they need ----- Link to Binary Python 2.4.* installer ----- Instructions of stuff to do after installing: -- Install TigerPython24Fix -- Add /usr/local/bin to your PATH -- Note: couldn't those steps be optionally done by the installer? ----- Link to Collection of packages on Pythonmac.org ----- Link to Wiki pages for people that need to use other Pythons. Perhaps build instructions, etc. What do I do now? -- How to run from command line -- IDE/editor options -- Pointers to "learn python" resources NOTE: I think we can recommend the same thing at this point for all users of OS-X 10.3 and 10.4. It also looks like the new Universal build may become the news recommended Python for OS-X 10.3.9 and above, but it's not ready yet. I was thinking of a decision tree, based on what version of OS-X you're running, and what you want to do (web development, GUI programming, etc), but I think we can, in fact have a single setup that will be best for most people running 10.3 and greater, so we can keep it simple. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Mon Feb 6 21:29:35 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 6 Feb 2006 12:29:35 -0800 Subject: [Pythonmac-SIG] not appear In-Reply-To: <43E7AADB.4000507@noaa.gov> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> <220f68650602061127v515abc2frc20068199a471143@mail.gmail.com> <618D3674-95E8-4636-9D59-18126A5DB815@redivi.com> <43E7AADB.4000507@noaa.gov> Message-ID: On Feb 6, 2006, at 12:00 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> The framework build's bin directory is technically way down inside >> the framework, but there are symlinks in /usr/local/bin. > > However: > > linda.s wrote: >> The >> installation appeared to be fine until "make install" was complete. > > So it looks like the OP didn't do a Framework build. > > What all this means is that you shouldn't build from source unless you > know what you are doing, and have a good reason to. A unix build puts the binaries in /usr/local/bin too unless you change the prefix or something. Either way you need to know how to manage your PATH. -bob From bob at redivi.com Mon Feb 6 21:34:24 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 6 Feb 2006 12:34:24 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <06Feb6.120952pst."58633"@synergy1.parc.xerox.com> References: <06Feb6.120952pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 6, 2006, at 12:09 PM, Bill Janssen wrote: > Kevin Walzer replies to Charles Hartman: >> Charles Hartman wrote: >>> Hence, yet again, a plea for newbies everywhere: >>> >>> I continue to believe that it really, really shouldn't be >>> necessary for >>> people who want to write programs in Python for the Mac to do all >>> this. >>> Great to learn as much as possible, yes, always -- but to require >>> people, just to get started, to learn about shells and the Terminal, >>> which they may never have dealt with before, even if they have a >>> variety >>> of Mac programming experience, is not to put Python on its best >>> footing. >>> >> >> It *isn't* necessary to do all that. Just use the vendor-provided >> Python, type "python" in your shell, and you are ready to go. > > And where does the newbie find that info? > > Here's what a newbie sees when they follow the MacPython link on > www.python.org: > > (in bold) "Download Python for Macintosh" > > implying that you need to *do* that! Followed by: > > "Through version 2.3, Python for the Macintosh was maintained by Jack > Jansen. See Jack's MacPython Page." > > The last updates here were done in 2004. > > None of the python.org pages point to pythonmac.org. And > pythonmac.org > is still organized around the idea that you have to install Python on > a Mac before using it. Jack Jansen's now-out-of-date pages lead the > parade on pythonmac.org. So file some bugs. You know where the sourceforge tracker is. > The next problem comes in when you want something out of the stdlib, > like PIL or Numeric. Everybody packaging for MacOS X isn't packaging > for the 2.3.5 supplied Python; instead, there are package managers and > Python2.4Fixes and eggs and nobody-quite-knows-what to install and > master if you want to use one of these additional tools. Not really > true, of course, but that's what it looks like. I've said it a hundred times -- if someone wants to be responsible for making pythonmac.org's content more friendly then I'm totally willing to dish out access. I don't have time or interest for it. -bob From Andrew.J.Kennedy at ge.com Mon Feb 6 23:27:30 2006 From: Andrew.J.Kennedy at ge.com (Kennedy, Andrew (GE Healthcare)) Date: Mon, 6 Feb 2006 16:27:30 -0600 Subject: [Pythonmac-SIG] redraw problem with Notebook within Notebook on Mac OS X Message-ID: <7DF59EAC75A1F145A1F6E9574220257E0A60B111@MKEMLVEM07.e2k.ad.ge.com> > Hi folks, > > I'm having a problem with redrawing in the following context. I have a Notebook, and one of the pages in that notebook defines another Notebook. If you select the page that doesn't contain a notebook, and then cause a redraw to take place (just change focus away from the window), the controls from the page containing the notebook show through into the current page. > > Here's some simple code that demonstrates the problem. Run the code, pick Page 2, and then cause the window to lose focus and the problem will be manifestly obvious. Any pointers with regards to where I should look? Also cross-posted to the Pmw-general mailing list. The problem only manifests itself on the Mac, the same code under the PC or Linux environment will run without issue. > > System information... Mac OS X 10.3.9, Python 2.4.1 Framework build, Tcl/Tk 8.4.6 Framework build, Pmw 1.2 > > Thanks very much, > Andrew > > > > import Tkinter > import Pmw > > root = Tkinter.Tk() > > nb1 = Pmw.NoteBook(root) > pg1 = nb1.add('Page 1') > pg2 = nb1.add('Page 2') > nb2 = Pmw.NoteBook(pg1) > pg3 = nb2.add('Page 3') > pg4 = nb2.add('Page 4') > button1 = Tkinter.Button(pg3,text='Button1',width=10) > button1.grid(row=0,column=0) > button2 = Tkinter.Button(pg2,text='Button2',width=20) > button2.pack() > nb2.pack(fill='both',expand=True) > nb1.pack(fill='both',expand=True) > > root.mainloop() > From charles.hartman at conncoll.edu Tue Feb 7 00:05:55 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 6 Feb 2006 18:05:55 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E7AE5A.6070600@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> Message-ID: <7CEF1E9B-63D0-4D67-AFE7-2D648433CD48@conncoll.edu> Me & my big mouth. OK, I will take a serious look at the page, and see whether I can construct something that at least gets to the point of having blanks that someone with knowledge can fill in. Charles On Feb 6, 2006, at 3:15 PM, Christopher Barker wrote: > Charles, if you want to help, here's my suggestion: > > Re-write the main pythonmac.org page, then post your version to this > list for discussion. If it is well liked, Bob has already said he'd > be glad to replace the current page. > > Here are my suggestions for a how to write that page: > > Welcome to Python on the Mac! > > Intro- > links to other python resources, etc. > > What Python should I use? > -- brief discussion of the options. > > > --The "Recommended Option" -- for users without special needs or > newbies that don't know what they need > ----- Link to Binary Python 2.4.* installer > ----- Instructions of stuff to do after installing: > -- Install TigerPython24Fix > -- Add /usr/local/bin to your PATH > -- Note: couldn't those steps be optionally done by the > installer? > ----- Link to Collection of packages on Pythonmac.org > > ----- Link to Wiki pages for people that need to use other Pythons. > Perhaps build instructions, etc. > > What do I do now? > -- How to run from command line > -- IDE/editor options > -- Pointers to "learn python" resources > > NOTE: I think we can recommend the same thing at this point for all > users of OS-X 10.3 and 10.4. It also looks like the new Universal > build > may become the news recommended Python for OS-X 10.3.9 and above, but > it's not ready yet. > > I was thinking of a decision tree, based on what version of OS-X > you're > running, and what you want to do (web development, GUI programming, > etc), but I think we can, in fact have a single setup that will be > best > for most people running 10.3 and greater, so we can keep it simple. > > -Chris > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From pecora at anvil.nrl.navy.mil Tue Feb 7 00:16:56 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon, 06 Feb 2006 18:16:56 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E7AE5A.6070600@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> Message-ID: <43E7D8E8.203@anvil.nrl.navy.mil> Christopher Barker wrote: > > I don't think there is blaming: more like expression of frustration and > suggestions for improvement. > > Charles, if you want to help, here's my suggestion: > > Re-write the main pythonmac.org page, then post your version to this > list for discussion. If it is well liked, Bob has already said he'd > be glad to replace the current page. > > Here are my suggestions for a how to write that page: > > Welcome to Python on the Mac! > > Intro- > links to other python resources, etc. > > What Python should I use? > -- brief discussion of the options. > > > --The "Recommended Option" -- for users without special needs or > newbies that don't know what they need > ----- Link to Binary Python 2.4.* installer > ----- Instructions of stuff to do after installing: > -- Install TigerPython24Fix > -- Add /usr/local/bin to your PATH > -- Note: couldn't those steps be optionally done by the installer? > ----- Link to Collection of packages on Pythonmac.org > > ----- Link to Wiki pages for people that need to use other Pythons. > Perhaps build instructions, etc. > > What do I do now? > -- How to run from command line > -- IDE/editor options > -- Pointers to "learn python" resources > > NOTE: I think we can recommend the same thing at this point for all > users of OS-X 10.3 and 10.4. It also looks like the new Universal build > may become the news recommended Python for OS-X 10.3.9 and above, but > it's not ready yet. > > I was thinking of a decision tree, based on what version of OS-X you're > running, and what you want to do (web development, GUI programming, > etc), but I think we can, in fact have a single setup that will be best > for most people running 10.3 and greater, so we can keep it simple. > > -Chris > Chris, This is right on the money and would be a GREAT start. Newbies could get up and running much faster instead of running away as some do now. I guess you hit the problem right when you asked, who has the time to do it? You at least have provided a very good outline for a starting page. I sympathize with Mr. Hartman and have felt the same frustrations while simultaneously appreciating and admiring the work you, Bob I., Robert Kern, and many others do to keep things running and current. So it is with very mixed feelings that any of us mere users post a complaint. You got it right, though. It is not a complaint, but a frustration that, if addressed even at the simple level you suggest, will bring many new people into Python. Now, if I only had the time and knowledge to fill in your outline. Sigh. Thank you. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From bob at redivi.com Tue Feb 7 00:21:05 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 6 Feb 2006 15:21:05 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E7AE5A.6070600@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> Message-ID: <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> On Feb 6, 2006, at 12:15 PM, Christopher Barker wrote: > NOTE: I think we can recommend the same thing at this point for all > users of OS-X 10.3 and 10.4. It also looks like the new Universal > build > may become the news recommended Python for OS-X 10.3.9 and above, but > it's not ready yet. Caveat emptor. You can not build extensions on 10.3.9 when using a universal build. The toolchain required (gcc4, 10.4 SDK, etc.) is just not available on that platform... and the CCFLAGS, LDFLAGS, etc. are all primed for that. Specifically, it would fall over on - isysroot, because that's gcc4 only, and also -arch i386 because Apple's public compilers didn't have support for that at that time. That said, you'd be able to use it, and install all the eggs/mpkgs you want, but you would not be able to use it with a compiler. That is, unless someone goes through the trouble of figuring out all the distutils.sysconfig hacks to make that work -- and it sure as hell isn't going to be me since I don't really have (or want) a 10.3 machine to test with. If you were able to compile extensions with 10.3.9 using the universal build, then you would only be able to produce PPC-only builds, and we'd need to add more hacks to setuptools so that it also accepts architecture specific binaries... right now it declares its architecture as "fat" and will only use eggs marked as fat. That goes both ways, users of the universal build can't use "legacy" eggs (marked with ppc or i386 architecture) from the current builds. -bob From pecora at anvil.nrl.navy.mil Tue Feb 7 00:21:19 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon, 06 Feb 2006 18:21:19 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <7CEF1E9B-63D0-4D67-AFE7-2D648433CD48@conncoll.edu> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <7CEF1E9B-63D0-4D67-AFE7-2D648433CD48@conncoll.edu> Message-ID: <43E7D9EF.4010509@anvil.nrl.navy.mil> Charles Hartman wrote: > Me & my big mouth. OK, I will take a serious look at the page, and > see whether I can construct something that at least gets to the point > of having blanks that someone with knowledge can fill in. > > Charles > > Charles, It might not be a big job. If you get it going and post to this list many can fill in. In fact, novices like me can even fill in some things we learned to get up and running which might not be thought of by the gurus, but another newbie will run into head on. The gurus can at least look it over and bless it. Hopefully, that would spread out the work. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From Chris.Barker at noaa.gov Tue Feb 7 00:39:52 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 06 Feb 2006 15:39:52 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> Message-ID: <43E7DE48.6070107@noaa.gov> Bob Ippolito wrote: > Caveat emptor. You can not build extensions on 10.3.9 when using a > universal build. Fair enough. No is going to be running 10.3 on an Intel Mac. If you want to develop for Intel users, you need 10.4. Period. However, given that, I think we should perhaps just suggest that 10.3.* users stick with a PPC only build. That would give us two builds to support with pre-built binaries, but a bunch are already done. I'm sorry to say that I just switched to 10.4, so I wont' be building an packages for 10.3. > That said, you'd be able to use it, and install all the eggs/mpkgs you > want, but you would not be able to use it with a compiler. The other option is to say: "If you don't intend to build your own packages, use the universal build", but I think that's risky, and a newbie might not think s/he is going to build anything, but will discover later that they need to. > That goes both ways, users of the universal build can't use "legacy" > eggs (marked with ppc or i386 architecture) from the current builds. That's OK. I think we can rally the community to build a good collection of stuff one the universal build comes out. Maybe none of them will be tested on Intel, but so be it! Bob, what do you think the timescale is for a universal build? If it's soon, then we should work on re-0writing the web site as though it's ready to go. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Tue Feb 7 00:59:54 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 6 Feb 2006 15:59:54 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E7DE48.6070107@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> Message-ID: <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> On Feb 6, 2006, at 3:39 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> Caveat emptor. You can not build extensions on 10.3.9 when using a >> universal build. > > Fair enough. No is going to be running 10.3 on an Intel Mac. If you > want > to develop for Intel users, you need 10.4. Period. > > However, given that, I think we should perhaps just suggest that > 10.3.* > users stick with a PPC only build. That would give us two builds to > support with pre-built binaries, but a bunch are already done. I'm > sorry > to say that I just switched to 10.4, so I wont' be building an > packages > for 10.3. Personally, once the universal build is out, that is the *only* one I am building eggs and/or mpkgs for. I suppose it would be worthwhile to create some more patches to setuptools so that PPC-only users can use fat eggs, and universal users can use PPC-only eggs (unless they're on Intel). >> That said, you'd be able to use it, and install all the eggs/mpkgs >> you >> want, but you would not be able to use it with a compiler. > > The other option is to say: "If you don't intend to build your own > packages, use the universal build", but I think that's risky, and a > newbie might not think s/he is going to build anything, but will > discover later that they need to. It would be possible to have a script that flips the Makefile to one that is capable of building PPC-only binaries I guess. >> That goes both ways, users of the universal build can't use "legacy" >> eggs (marked with ppc or i386 architecture) from the current builds. > > That's OK. I think we can rally the community to build a good > collection > of stuff one the universal build comes out. Maybe none of them will be > tested on Intel, but so be it! > > Bob, what do you think the timescale is for a universal build? If it's > soon, then we should work on re-0writing the web site as though it's > ready to go. I'd say soon... The only issues left are to sort out the distribution scripts and some more testing I guess. -bob From lanceboyle at qwest.net Tue Feb 7 01:32:55 2006 From: lanceboyle at qwest.net (lanceboyle at qwest.net) Date: Mon, 6 Feb 2006 17:32:55 -0700 Subject: [Pythonmac-SIG] install again? In-Reply-To: <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> Message-ID: I agree pretty much completely with Charles Harman, Bill Janssen, and others. I learned programming in 1974 and have programmed ever since for my own engineering work. I use and have used many languages, trying to pick the best one for the job. I have gripes with many of the specialized languages/environments meant for technical work, so I prefer to work in a "real" language. For many years that was Pascal, and nowadays it's mostly Ada (not intended as a slight to Python). But I digress. Having Unix under the Mac has been a great boon in the availability of software. (I wouldn't, for example, be using free GNU Ada otherwise.) But I find myself spending far more time pissing around with the compiler/OS etc. than I used to in the old days. This is not progress. Not to ruffle feathers, but to offer a constructive criticism: The Unix culture and the Macintosh culture are at odds with one another. It is _not_ necessary to program with a good language while suffering the details of what's under the hood. As examples of this, I offer the much-missed THINK Pascal. (See the several threads on THINK Pascal on the MacPascal list.) This was the epitome of power and ease-of-use, in my opinion. I suspect (I have only played with it) that another example is REALbasic, recently Cocoa-able. Every time I bring this topic up in a Unix-y setting (SciPy recently), I get slammed. So please listen. Try to make software that can be used by people who aren't part of the "inside" crowd. This requires letting go of your ego and imagining what the world looks like from their viewpoint. Pretend you're setting up airport traffic signs for people from out of town, not the locals. Make an Installer for Dummies. Make an IDE that works in the Mac way. (Where are you, Glenn?) Make Cocoa access automatic with the installation. Make a simplified, high-level Cocoa-based GUI API. Make an easy and cohereht add-on method. Make adding SciPy and Chaco a no-brainer. (Oops--wrong list.) Never require a user to build his/her own software. Don't expand the user's lexicon with the likes of mpkg, egg, setuptools, patches, distutils, and so on. You are making end-user software. Remember that most of the people who use or would use Python don't program for a living, or don't even like to program--they do it because they have to. Hell, go get THINK Pascal and see what I'm talking about. (E.g., the entire Toolbox was predefined. The debugger was sublime.) It's free now, long ago abandoned but still used and supported by fans who are loath to run OS 9 but for it. Python with a good Mac-way IDE has so much potential to reach the same usability as THINK Pascal did in 1984. And of course, thanks to the dedicated people who make it possible for me have anything at all to on which to suggest improvements. 8^) Jerry On Feb 6, 2006, at 8:43 AM, Charles Hartman wrote: > Oh well, "other platforms" -- if that means Linux of course you > have to learn those same things, but you undoubtedly already know > them. If it means Windows, I'd rather drive a truck, and I'm > thinking particularly of potential users who feel the same way. > > Charles > > > > On Feb 6, 2006, at 10:06 AM, Kevin Walzer wrote: > >> Just to continue the conversation, what do *you* think is the best >> approach? How should Python be made easier than it already is (and, >> frankly, compared to C, it's pretty easy)? What special >> difficulties or >> obstacles does the Mac platform present to learning Python that >> are not >> also present on other platforms? > From Chris.Barker at noaa.gov Tue Feb 7 02:18:54 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 06 Feb 2006 17:18:54 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> Message-ID: <43E7F57E.6020906@noaa.gov> lanceboyle at qwest.net wrote: > I agree pretty much completely with Charles Harman, Bill Janssen, and > others. So do I, however.... This is Open Source software! Which doesn't mean that it can't be great in every way, but it does mean that it is developed for different reasons than commercial software, and it will have different features. All of us that contribute to the MacPython community have other jobs, and are only contributing what we can out of the goodness of our hearts, essentially. The reason much open source software is short on easy installers and documentation for newbies is that the people capable of developing those things don't need them. > This > requires letting go of your ego and imagining what the world looks > like from their viewpoint. No, it doesn't. It means taking our own precious time to make something for someone else, just to be nice. That's asking a LOT > Make an Installer > for Dummies. Make an IDE that works in the Mac way. (Where are you, > Glenn?) Make Cocoa access automatic with the installation. Make a > simplified, high-level Cocoa-based GUI API. Make an easy and coherent > add-on method. Make adding SciPy and Chaco a no-brainer. (Oops--wrong > list.) Never require a user to build his/her own software. Don't > expand the user's lexicon with the likes of mpkg, egg, setuptools, > patches, distutils, and so on. That would be a great list IF the primary goal was creating a easy tool for newbies to use. I think there is real commercial potential in making such a tool based on Python, but I'm not in the business of selling software, I'm in the business of doing Oceanography. > You are making end-user software. No, we're not. Most of the Python, MacPython, SciPy etc. community is making software for ourselves to use. Other end users are a nice bonus. > Python with a good Mac-way IDE has so much potential to reach the > same usability as THINK Pascal did in 1984. Yes, it does, but it won't be built until someone who is capable of building it wants it enough to put the time it. I suspect that that will only happen if someone decides to try to make money from it. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From charles.hartman at conncoll.edu Tue Feb 7 02:45:20 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 6 Feb 2006 20:45:20 -0500 Subject: [Pythonmac-SIG] New Page, first proposal Message-ID: OK, here's the first donkey -- please step up to the line & fire when ready. The project is to build a new front page for pythonmac.org that will serve as a welcome and introduction for anyone who wants to write Python programs on the Mac. (An assumption behind this is that the site will come up quickly in any curious person's search for information on the topic, which in turn assumes a link from python.org, and also I hope a prominent one slapped onto the top of the MacPython site.) For a page title that covers the ground broadly and accurately, I propose Python on the Mac Problems with that? Better suggestions? Four stages in the project are foreseeable: 1. Establish the basic organization of the page 2. Collect the essential technical data, and probably also less essential materials to be relegated to secondary pages 3. Produce some friendly prose 4. Build the html for the page #4 is fun, and I wouldn't mind doing it in DreamWeaver if nobody else has better tools and skills. #3 is easy enough, though checking it for accuracy needs to be a community effort. I am not competent to do #2, but this list is full of people who are. Here I'm proposing an approach to #1. I suggest the page be organized by audience, and that it begin by addressing the needs of users most in danger of being scared off. (Obviously what follows is not the friendly-prose stage -- just a stab at a logical organization.) ===== the Python-on-the-Mac page ======================= [1] "If you're a Mac user who wants to learn to write Python programs": note Apple distro, be politely disparaging toward it, provide links to Bob's framework, with notes (how extensive is this?) on other stuff required ActiveState's framework, with similar notes provide links to how-to-program sites how-to-program-in-Python sites how-to-program-for-the-Mac sites [2] "If you want an editor or full-fledged IDE (rather than using the Terminal)": provide links, with brief descriptions, to Wing IDE BBEdit/TextWrangler ?? discuss briefly the non-terrors of working in the Terminal [3] "If you want to write programs with windows and buttons": discuss why libraries would be helpful provide links, with brief descriptions, to wxPython TKinter ?? [4] "If your programs need other specialized tools": provide links, with brief descriptions, to PIL Numeric SciPy [5] "If you want to write C (or other) extensions, or embed Python, or ?": Describe the current state of considerations about target Mac system (10.3, 10.4, Intel) Provide links to PyObjC ?? ========================================= A couple of questions right off the bat: 1. I'm not at all clear whether it's necessary to address the question of platform (is the user running 10.3 or 10.4? does the sub- version matter?) before that last, extensions stage. How many packages under [3] or [4], for example, require a certain OS version? If we don't need to address this before [5] (whose audience won't have trouble with it), that's very very good: it saves a lot of combinatoric mess. If we do, then can it be a sidebar on the page? How much of a decision tree is there, or does there have to be? 2. Would it be legitimate to start the page off with a little list of things to do for those who get worried by too many choices? For me, the list would be (1) get Bob's framework (2) pick and install an IDE (3) go get one of the following books or read the following instructional sites. Beginning with a list seems too arbitrary. But it really mustn't take the reader long to deduce that last for herself/himself. 3. Once this sketch is fleshed out fully enough to be not misleading, I fear that keeping it on a single page may get cumbersome. If that happens, do we prefer a couple of sequential pages ("Next?") or some kind of branch? A hard question before we get there -- but the kind of thing that it would be helpful to decide early, for reasons don't have to explain to programmers, though I have to explain them to my students frequently. Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060206/05ff7b0f/attachment.htm From charles.hartman at conncoll.edu Tue Feb 7 02:56:03 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 6 Feb 2006 20:56:03 -0500 Subject: [Pythonmac-SIG] a beginner's list Message-ID: <74489EE5-58DB-4286-9935-CDD2185B69DE@conncoll.edu> This is a little separate from my previous message, though it speaks to question #2 in that message. Somebody who comes idly to the idea of programming in Python, and finds the pythonmac page, will be happy if the result is an afternoon's work that ends in a "hello world," possibly in a window. Using my own arbitrary preferences, that would entail: 1. downloading & installing Bob's framework 2. downloading & installing TigerPython24Fix 3. adding /usr/local/bin to the PATH 4. downloading & installing wxPython 5. downloading & installing [fill in name of IDE] 6. starting to browse how-to-program sites and writing some bits Have I forgotten anything? Is anything here unnecessary? Is it possible (I guess this is a question for Bob, which he may have answered 237 times already--sorry) to make 2 and 3 automatic or semi- automatic parts of 1? Charles From chairos at gmail.com Tue Feb 7 05:00:25 2006 From: chairos at gmail.com (Jon Rosebaugh) Date: Mon, 6 Feb 2006 22:00:25 -0600 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <74489EE5-58DB-4286-9935-CDD2185B69DE@conncoll.edu> References: <74489EE5-58DB-4286-9935-CDD2185B69DE@conncoll.edu> Message-ID: On 2/6/06, Charles Hartman wrote: > 4. downloading & installing wxPython > 5. downloading & installing [fill in name of IDE] Can I politely suggest PyObjC? In my opinion, unless you need a cross-platform GUI, you're much better off starting and staying with PyObjC. From bob at redivi.com Tue Feb 7 05:24:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 6 Feb 2006 20:24:34 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E7F57E.6020906@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7F57E.6020906@noaa.gov> Message-ID: <04F3EFC4-5824-40CB-92FC-A6D8EBB65389@redivi.com> On Feb 6, 2006, at 5:18 PM, Christopher Barker wrote: > lanceboyle at qwest.net wrote: >> I agree pretty much completely with Charles Harman, Bill Janssen, and >> others. > > So do I, however.... Who doesn't? I want world peace too ;) > This is Open Source software! Which doesn't mean that it can't be > great > in every way, but it does mean that it is developed for different > reasons than commercial software, and it will have different features. > > All of us that contribute to the MacPython community have other jobs, > and are only contributing what we can out of the goodness of our > hearts, > essentially. The reason much open source software is short on easy > installers and documentation for newbies is that the people capable of > developing those things don't need them. Precisely. I do what I do primarily for my own benefit, but I go the extra mile or two to help other people get along. Making everything perfect and easy for everyone is a trip across the globe, though, and I just don't have that kind of vacation time. >> This >> requires letting go of your ego and imagining what the world looks >> like from their viewpoint. > > No, it doesn't. It means taking our own precious time to make > something > for someone else, just to be nice. That's asking a LOT I'll tell you what: I'll drop the ego and get a new pair of glasses in exchange for five or six million dollars.. that'll let me put my company on hold while I placate the needs of the MacPython community. >> You are making end-user software. > > No, we're not. Most of the Python, MacPython, SciPy etc. community is > making software for ourselves to use. Other end users are a nice > bonus. If "end-user" means "me" then yes. Otherwise, no. >> Python with a good Mac-way IDE has so much potential to reach the >> same usability as THINK Pascal did in 1984. > > Yes, it does, but it won't be built until someone who is capable of > building it wants it enough to put the time it. I suspect that that > will > only happen if someone decides to try to make money from it. Maybe when I retire in 20 years :) -bob From janssen at parc.com Tue Feb 7 05:33:34 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 6 Feb 2006 20:33:34 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Mon, 06 Feb 2006 17:56:03 PST." <74489EE5-58DB-4286-9935-CDD2185B69DE@conncoll.edu> Message-ID: <06Feb6.203343pst."58633"@synergy1.parc.xerox.com> Charles, I love the fact that you've taken the time to think through this! Hurrah! However... > Somebody who comes idly to the idea of programming in Python, and > finds the pythonmac page, will be happy if the result is an > afternoon's work that ends in a "hello world," possibly in a window. > Using my own arbitrary preferences, that would entail: > > 1. downloading & installing Bob's framework > 2. downloading & installing TigerPython24Fix > 3. adding /usr/local/bin to the PATH > 4. downloading & installing wxPython > 5. downloading & installing [fill in name of IDE] > 6. starting to browse how-to-program sites and writing some bits I think this is a wonderful example of the mindset that's wrong with the current situation. An afternoon's work? Who would want to do that just to fool around, when Python is *pre-installed* on the Mac? Who wants to open windows? Why is a GUI automatically necessary? And if it is, all you need is already there on 10.4, in three minutes: 1) Click on Applications/Utilities/Terminal. 2) In the terminal window, enter the following line: % pythonw 3) You will see a prompt ">>>". At the prompt, enter the following line: >>> print "Hello, World!" and you will see "Hello, World!" written back to you. 4) To do this in a window, enter the following lines at the ">>>" prompt: >>> import wx >>> app = wx.PySimpleApp() >>> frame = wx.Frame(None, -1, "Hello World").Show(1) >>> app.MainLoop() That's it! Maybe with a pointer to the wxPythonWiki getting started page (which I stole this code from): http://wiki.wxpython.org/index.cgi/Getting_20Started#head-bc009992ceb90dddb7eb3db953e25d1792da2cdd *Don't* deprecate the Apple pre-installed Python! Rejoice in it! And then hint that even better things are available in 2.4.x... Once a newbie decides to get serious about Python, *then* they can think about upgrading their installation. Bill From bob at redivi.com Tue Feb 7 08:47:04 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 6 Feb 2006 23:47:04 -0800 Subject: [Pythonmac-SIG] Supporting arch specific eggs with a fat Python and setuptools Message-ID: <3B1DD8F2-BE3D-4186-BCED-C8D8D23D96F1@redivi.com> With the recent introduction of i386 architecture Macs, it's becoming a necessity to support two architectures for the platform: PPC and i386. Fortunately this is done somewhat easily using Apple's GCC 4 compiler and their linker toolchain. Ronald and I have already basically made all of the necessary changes to Python (in a branch on another svn server) and distutils in order to make Python compile with multiple architectures, and to make distutils also do the right thing. This solution works great (in theory and limited testing) for everyone except Mac OS X 10.3 users. We have gone out of our way to ensure that this build of Python is compatible with Mac OS X 10.3.9 so that those users aren't totally left in the dark, but there is a problem: the GCC 4 toolchain required to build extensions is not available to Mac OS X 10.3 users. They simply can not build binaries compatible with i386.. and if they could, they couldn't link it together as a universal binary. Bummer. The workaround for this issue is to have a way to swap out the Makefile with a PPC-only Makefile for those users. The problem with that is setuptools. Currently setuptools doesn't include a lot of intelligence for choosing eggs given multiple choices. Here's a scenario of various Python builds and the naming of eggs they produce: Mac OS X 10.4 with current means: pysqlite-2.0.5-py2.4-macosx-10.4-ppc.egg Mac OS X 10.3 with current means, or with the universal build and a swapped Makefile: pysqlite-2.0.5-py2.4-macosx-10.3-ppc.egg Mac OS X 10.4 with the universal build: pysqlite-2.0.5-py2.4-macosx-10.3-fat.egg The decision of which egg to choose is subjective, but the greatest benefit overall is achieved by choosing the maximally compatible version: pysqlite-2.0.5-py2.4-macosx-10.3-fat.egg For users of Mac OS X, here is the egg-sorting algorithm I'm proposing. This sort must be used only with eggs that are compatible with the current architecture -- which means either "fat" or _macosx_arch(os.uname()[4].replace(' ', '_')). Also allowing _macosx_arch and universally allowing fat are going to require another patch to setuptools (that I have not yet written, because it's not the right thing to do until egg-sorting is right). # a and b must only differ in platform specifics! def cmp_platform_eggs(a, b): if a.arch == "fat" and b.arch == "fat": pass elif a.arch == "fat": return 1 elif b.arch == "fat": return -1 # lower version sorts higher return -cmp(a.macosx_version, b.macosx_version) This sort means that fat will always be preferred, and lower requirements sort higher. This makes it easier for people who wish to redistribute self-contained applications to other users (a la py2app, py2exe, cx_Freeze), which is a very important use case for this platform. -bob From hengist.podd at virgin.net Tue Feb 7 12:47:07 2006 From: hengist.podd at virgin.net (has) Date: Tue, 7 Feb 2006 11:47:07 +0000 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb6.203343pst."58633"@synergy1.parc.xerox.com> References: <06Feb6.203343pst."58633"@synergy1.parc.xerox.com> Message-ID: Bill Janssen wrote: >I think this is a wonderful example of the mindset that's wrong with >the current situation. An afternoon's work? > >>> print "Hello, World!" Bill nails it. Charles has done some good work here (first draft is always the hardest); now let's kick the tar out of it so it'll grow incredibly big and strong. Bless the Scientific Method. :) If you're serious about marketing to new users, and not just serving the existing community, then technical arguments be damned: it's all about creating the right "Wow is this stuff so fast and easy!" first impression. Because if we don't, there's plenty other P-languages that'll be happy to grab 'em instead. Therefore, you have to provide a two-track approach: 1. The "Python in 30 seconds or less" hook to snag new users and casual passers-by, leveraging what's already installed whenever possible. 2. The "Python for serious developers" to get 'em kitted out with the latest and greatest once we've won them over and they wish to go further. >*Don't* deprecate the Apple pre-installed Python! Rejoice in it! And >then hint that even better things are available in 2.4.x... Amen. Never denigrate (in the newcomer's eyes) the product you're trying to sell. Python 2.3.x might not be the latest and greatest, but it still meets a whole lot of needs for virtually zero effort. Therefore, the pitch should be: Pre-installed Python = Great Cutting-edge Python = Even Greater HTH has p.s. Apologies for not contributing more right now, but I'm a bit up to the ears in deadline work. Hopefully when it calms down a bit... -- http://freespace.virgin.net/hamish.sanderson/ From pje at telecommunity.com Tue Feb 7 14:37:11 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 07 Feb 2006 08:37:11 -0500 Subject: [Pythonmac-SIG] pkg_resources and Mac OS X compatibility In-Reply-To: <9FF4B86E-D69B-4749-8347-D76A4708E1E2@redivi.com> References: <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> <6D4EE44B-ECA5-4014-B339-16BB6DA4CE3A@redivi.com> <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> Message-ID: <5.1.1.6.0.20060207083254.038944b8@mail.telecommunity.com> At 02:07 PM 2/5/2006 -0800, Bob Ippolito wrote: >On Feb 5, 2006, at 2:00 PM, Bob Ippolito wrote: >>With the way that we're returning the distutils platform on the >>universal branch of Mac OS X, we need another patch to >>pkg_resources. The reason for this is that >>distutils.util.get_platform() returns the platform that it is >>trying to produce binaries for, which is often not the exact >>current platform. More specifically, our current strategy is to >>produce a version of Python that will build extensions that are >>compatible with Mac OS X 10.3, but the actual building of >>extensions requires Mac OS X 10.4 or later (because the toolchain >>doesn't exist on Mac OS X 10.3). >> >>In some rare cases, people will want to produce packages that >>explicitly require Mac OS X 10.4 or later, which they can do by >>setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when >>running setup.py. This will influence the value returned by >>disutils.util.get_platform(), and will influence the compiler and >>linker if extensions are built. >> >>This patch adds an internal _get_max_platform(plat) function that >>returns the actual runtime version of Mac OS X, for use in >>compatible_platforms. > >Oops, wrong patch.. here's the correct one. Sorry about that: I've implemented a similar - but different - patch. Yours causes setuptools' tests to fail on non-Mac platforms, including non-Mac darwin. From pje at telecommunity.com Tue Feb 7 14:43:05 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 07 Feb 2006 08:43:05 -0500 Subject: [Pythonmac-SIG] Supporting arch specific eggs with a fat Python and setuptools In-Reply-To: <3B1DD8F2-BE3D-4186-BCED-C8D8D23D96F1@redivi.com> Message-ID: <5.1.1.6.0.20060207083812.0389aa60@mail.telecommunity.com> At 11:47 PM 2/6/2006 -0800, Bob Ippolito wrote: >This sort must be used only with eggs that are compatible >with the current architecture -- which means either "fat" or >_macosx_arch(os.uname()[4].replace(' ', '_')). Also allowing >_macosx_arch and universally allowing fat are going to require >another patch to setuptools (that I have not yet written, because >it's not the right thing to do until egg-sorting is right). > > # a and b must only differ in platform specifics! > def cmp_platform_eggs(a, b): > if a.arch == "fat" and b.arch == "fat": > pass > elif a.arch == "fat": > return 1 > elif b.arch == "fat": > return -1 > # lower version sorts higher > return -cmp(a.macosx_version, b.macosx_version) > >This sort means that fat will always be preferred, and lower >requirements sort higher. This makes it easier for people who wish >to redistribute self-contained applications to other users (a la >py2app, py2exe, cx_Freeze), which is a very important use case for >this platform. The way I'd recommend implementing this is via a _platform_key() function that takes a platform string and converts it to something that sorts the way you want it to; higher values are preferred to lower values. Note that pkg_resources sorts distributions by version and other precedence information first; platform is the very *last* thing considered in a sort. It also can't be guaranteed that you'll be comparing your custom object with a common platform. So please try to write the patch with these constraints in mind. On the line that's currently line 1758 of pkg_resources.py, you'll see a reference to 'self.platform'; change that to '_platform_key(self.platform)' once you've got your precedence algorithm figured out. Note also that self.platform can be None, so _platform_key should not assume its parameter is a string. From bob at redivi.com Tue Feb 7 20:48:15 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 7 Feb 2006 11:48:15 -0800 Subject: [Pythonmac-SIG] pkg_resources and Mac OS X compatibility In-Reply-To: <5.1.1.6.0.20060207083254.038944b8@mail.telecommunity.com> References: <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> <6D4EE44B-ECA5-4014-B339-16BB6DA4CE3A@redivi.com> <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> <5.1.1.6.0.20060207083254.038944b8@mail.telecommunity.com> Message-ID: <3CD0B049-6130-49C2-9CAD-ED230DD24A8E@redivi.com> On Feb 7, 2006, at 5:37 AM, Phillip J. Eby wrote: > At 02:07 PM 2/5/2006 -0800, Bob Ippolito wrote: >> On Feb 5, 2006, at 2:00 PM, Bob Ippolito wrote: >>> With the way that we're returning the distutils platform on the >>> universal branch of Mac OS X, we need another patch to >>> pkg_resources. The reason for this is that >>> distutils.util.get_platform() returns the platform that it is >>> trying to produce binaries for, which is often not the exact >>> current platform. More specifically, our current strategy is to >>> produce a version of Python that will build extensions that are >>> compatible with Mac OS X 10.3, but the actual building of >>> extensions requires Mac OS X 10.4 or later (because the toolchain >>> doesn't exist on Mac OS X 10.3). >>> >>> In some rare cases, people will want to produce packages that >>> explicitly require Mac OS X 10.4 or later, which they can do by >>> setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when >>> running setup.py. This will influence the value returned by >>> disutils.util.get_platform(), and will influence the compiler and >>> linker if extensions are built. >>> >>> This patch adds an internal _get_max_platform(plat) function that >>> returns the actual runtime version of Mac OS X, for use in >>> compatible_platforms. >> >> Oops, wrong patch.. here's the correct one. Sorry about that: > > I've implemented a similar - but different - patch. Yours causes > setuptools' tests to fail on non-Mac platforms, including non-Mac > darwin. Could you explain how? I don't see it. The condition is:: if m is not None and sys.platform == "darwin": ... How does that fail on pure Darwin? The condition should be False because m has to be None at that point and the branch shouldn't happen. -bob From pje at telecommunity.com Tue Feb 7 21:42:33 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 07 Feb 2006 15:42:33 -0500 Subject: [Pythonmac-SIG] pkg_resources and Mac OS X compatibility In-Reply-To: <3CD0B049-6130-49C2-9CAD-ED230DD24A8E@redivi.com> References: <5.1.1.6.0.20060207083254.038944b8@mail.telecommunity.com> <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> <6D4EE44B-ECA5-4014-B339-16BB6DA4CE3A@redivi.com> <6B099161-BDFF-42A3-BF33-5D3748878B66@redivi.com> <5.1.1.6.0.20060207083254.038944b8@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20060207153653.0215d718@mail.telecommunity.com> At 11:48 AM 2/7/2006 -0800, Bob Ippolito wrote: >On Feb 7, 2006, at 5:37 AM, Phillip J. Eby wrote: >>I've implemented a similar - but different - patch. Yours causes >>setuptools' tests to fail on non-Mac platforms, including non-Mac >>darwin. > >Could you explain how? I don't see it. The condition is:: > > if m is not None and sys.platform == "darwin": > ... Note that that's because I added the "darwin" check; it wasn't in your original patch. >How does that fail on pure Darwin? The condition should be False >because m has to be None at that point and the branch shouldn't happen. You're making the assumption that platform compatibility checks between Mac OS X version strings only happen when you're *running* on Mac OS X, but the test suite contains tests for the platform compatibility checking code that runs on all platforms. Thus, the "m is not None" condition can apply regardless of platform, at least for test purposes. From Chris.Barker at noaa.gov Tue Feb 7 22:32:24 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 07 Feb 2006 13:32:24 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <04F3EFC4-5824-40CB-92FC-A6D8EBB65389@redivi.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7F57E.6020906@noaa.gov> <04F3EFC4-5824-40CB-92FC-A6D8EBB65389@redivi.com> Message-ID: <43E911E8.20706@noaa.gov> Bob Ippolito wrote: > I'll tell you what: I'll drop the ego and get a new pair of glasses in > exchange for five or six million dollars.. I'll bet I could package up Python, PyObjC etc. with good installers and tutorials for only about a one million dollars. Then maybe another million to start marketing it. Anyone want to fund my new company? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From w.northcott at unsw.edu.au Wed Feb 8 01:39:55 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Wed, 8 Feb 2006 11:39:55 +1100 Subject: [Pythonmac-SIG] Problems with PyOpenGL build and fixes? In-Reply-To: References: Message-ID: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> I downloaded and installed Bob's binary of wxPython for 2.4, which seems to work nicely but expects PyOpenGL to be installed. So I tried installing it and fell right back into the header file messes again. Issues so far: 1. the current source tarball has a big problem. There is a script, get_gl_extensions.py, at the top level of the cvs code which adds a heap of cruft starting '#include on to the end of almost all the wrapper .i files. This include does not work on MacOS but even changing it to just results in a load of 'syntax error's. Using CVS code gets over this. It seems the offending script was merged to the head in July 2005. Does any one know why? 2. config/ darwin.cfg adds /System/Library/Frameworks/ Kernel.framework/Headers to the header search path. This creates a problem because '#include then includes the Kernel framework version of stat.h which lacks necessary declarations. This issue has also been reported by others on PyOpenGL mail lists. Does anyone know why the Kernel framework is used? 3. around src/config.h:96 there is code like #ifdef CGL_PLATFORM #include #include #include #else this leaves certain functions undeclared such as CGLGetCurrentContext. Altering the code thus removes these problems #ifdef CGL_PLATFORM #include #include #include #include #else this change has a side benefit of rendering the include_dirs on line 14 of darwin.cfg unnecessary. A directive like '#include ' automatically searches the standard framework search path (~/ Library/Frameworks:/Library/Frameworks:/System/Library/Frameworks) for an OpenGL.framework and the loads the header from the Headers directory in that framework. 4. at src/gle/src/texgen.c around line 14 there is the following: #ifdef __APPLE_CC__ /#include /* Darwin has a bug that doesn't define u_short in */ /#include /* malloc.h, so we have to get it through stdio.h. */ #else #include #endif this results in malloc and realloc not being declared. I have no idea how this code got concocted. All the sources I have consulted (Apple's documentation, Opengroup standards and even my 1988 copy of K&R) say malloc and realloc are provided by . Changing the code as below results in all the warnings going away #ifdef __APPLE_CC__ #include #else #include #endif With these changes the cvs code for PyOpenGL builds happily, although there are still a lot of warnings. Thanks Bill Northcott PS This build works happily with _POSIX_C_SOURCES defined! From bob at redivi.com Wed Feb 8 01:58:08 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 7 Feb 2006 16:58:08 -0800 Subject: [Pythonmac-SIG] Problems with PyOpenGL build and fixes? In-Reply-To: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> References: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> Message-ID: <5FDFB8BC-4A33-4EEE-955F-0DEC3BFB3B3B@redivi.com> On Feb 7, 2006, at 4:39 PM, Bill Northcott wrote: > I downloaded and installed Bob's binary of wxPython for 2.4, which > seems to work nicely but expects PyOpenGL to be installed. So I > tried installing it and fell right back into the header file messes > again. I'm pretty sure that is the same build as was on the wxPython site at the time, I don't recall building it myself. PyOpenGL should be on http://pythonmac.org/packages too -bob From chrisporter9 at wi.rr.com Wed Feb 8 06:13:50 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Tue, 7 Feb 2006 23:13:50 -0600 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb6.203343pst.58633@synergy1.parc.xerox.com> Message-ID: I'm afraid this criticism is spot on. I got a python program from a programmer. I want to run it on my Mac. And here, Mac comes with Python! Very nice. That shouldn't be downplayed. All I needed was the Python that was already installed, plus a couple added things. (I needed Python to talk to MySQL, and that I had to install MySQL, so there was likely no native ability to do so on the Mac I've got.) So the Python I'm using is Mac's own, and it runs my programmer's code lickety split. From a few hours frustrated search on the web, to a couple of posts on this list and a few minutes installing libraries and ... stuff, and that's all it took to get me to be a "Python user" (yes, I can hear my programmer snorting from here). A nice web page with something like all the suggestions below, and also a way to use the Python installed would be both enticing and useful. Maybe something about "If your goal is... to create programs, see here. to run programs, see here. to have Python interact with other programs on your Mac, see here. to install new versions, see here. to update your version, see here. to add special libraries, see here. For neat programs or utilities that help you use Python on your Mac... A List of jargon... (what's a library? IDE? those strange letters in front of Python? a fix? a framework? an egg?) > Charles, I love the fact that you've taken the time to think through > this! Hurrah! > > However... > > > Somebody who comes idly to the idea of programming in Python, and > > finds the pythonmac page, will be happy if the result is an > > afternoon's work that ends in a "hello world," possibly in a window. > > Using my own arbitrary preferences, that would entail: > > > > 1. downloading & installing Bob's framework > > 2. downloading & installing TigerPython24Fix > > 3. adding /usr/local/bin to the PATH > > 4. downloading & installing wxPython > > 5. downloading & installing [fill in name of IDE] > > 6. starting to browse how-to-program sites and writing some bits > > > I think this is a wonderful example of the mindset that's wrong with > the current situation. An afternoon's work? Who would want to do > that just to fool around, when Python is *pre-installed* on the Mac? > > Who wants to open windows? Why is a GUI automatically necessary? > > And if it is, all you need is already there on 10.4, in three minutes: > > 1) Click on Applications/Utilities/Terminal. > > 2) In the terminal window, enter the following line: > > % pythonw > > 3) You will see a prompt ">>>". At the prompt, enter the following line: > > >>> print "Hello, World!" > > and you will see "Hello, World!" written back to you. > > 4) To do this in a window, enter the following lines at the ">>>" prompt: > > >>> import wx > >>> app = wx.PySimpleApp() > >>> frame = wx.Frame(None, -1, "Hello World").Show(1) > >>> app.MainLoop() > > That's it! > > Maybe with a pointer to the wxPythonWiki getting started page (which I > stole this code from): > > http://wiki.wxpython.org/index.cgi/Getting_20Started#head-bc009992ceb90dddb7eb3db953e25d1792da2cdd > > *Don't* deprecate the Apple pre-installed Python! Rejoice in it! And > then hint that even better things are available in 2.4.x... > > Once a newbie decides to get serious about Python, *then* they can > think about upgrading their installation. > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Wed Feb 8 08:07:35 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 07 Feb 2006 23:07:35 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: Message-ID: <43E998B7.3000809@noaa.gov> Chris Porter wrote: > And here, Mac comes with Python! Very nice. > That shouldn't be downplayed. All I needed was the Python that was already > installed, plus a couple added things. (I needed Python to talk to MySQL, and > that I had to install MySQL, so there was likely no native ability to do so on > the Mac I've got.) This is my point. You couldn't actually get anything done without downloading and installing _something_. Once you're doing that, it would have made very little difference if you had downloaded and installed a new version of Python as well. However, what would have made a difference is whether or not a package for the MySQL lib were easily available or not. That's why whatever the MacPython community endorses and documents should be a version with as broad package support as possible. I think that's 2.4.*, rather than the Apple supplied python. In addition, if you have your code running just fine and dandy under Apple's python, then you upgrade to 10.5, chances are that your app will no longer work, as Apple is likely to yank their python out from under you. If it were running with a user-installed Python, chances are it would keep working. -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 From bob at redivi.com Wed Feb 8 08:25:31 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 7 Feb 2006 23:25:31 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <43E998B7.3000809@noaa.gov> References: <43E998B7.3000809@noaa.gov> Message-ID: On Feb 7, 2006, at 11:07 PM, Christopher Barker wrote: > Chris Porter wrote: >> And here, Mac comes with Python! Very nice. >> That shouldn't be downplayed. All I needed was the Python that was >> already >> installed, plus a couple added things. (I needed Python to talk to >> MySQL, and >> that I had to install MySQL, so there was likely no native ability >> to do so on >> the Mac I've got.) > > This is my point. You couldn't actually get anything done without > downloading and installing _something_. Once you're doing that, it > would > have made very little difference if you had downloaded and installed a > new version of Python as well. > > However, what would have made a difference is whether or not a package > for the MySQL lib were easily available or not. That's why whatever > the > MacPython community endorses and documents should be a version with as > broad package support as possible. I think that's 2.4.*, rather > than the > Apple supplied python. > > In addition, if you have your code running just fine and dandy under > Apple's python, then you upgrade to 10.5, chances are that your app > will > no longer work, as Apple is likely to yank their python out from under > you. If it were running with a user-installed Python, chances are it > would keep working. For that reason (and many others) it's a hell of a lot easier, support-wise, to say that everyone should install a non-Apple build. All we really have to do to make the experience better is to do what Darwinports does and hack their .profile (or whatever) upon installation such that it ends up in PATH automagically. Practicality beats purity in this case. There's plenty of other things that could be done, such as replacing PythonLauncher with something that'll pop open a console if you double-click on a ".py" file like it does on win32. Right now, there's a lot of lower level things that need to be fixed that are much higher priority. The experienced users doing all this hacking need something that works more than they need something that's easy and kinda works. The workaround in the meantime has to be documentation, and that task is better done by people who aren't more comfortable in Terminal than Finder (read as: not me) :) -bob From kevino at theolliviers.com Wed Feb 8 10:06:49 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 8 Feb 2006 01:06:49 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <43E998B7.3000809@noaa.gov> References: <43E998B7.3000809@noaa.gov> Message-ID: <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> Hi Chris, On Feb 7, 2006, at 11:07 PM, Christopher Barker wrote: > Chris Porter wrote: >> And here, Mac comes with Python! Very nice. >> That shouldn't be downplayed. All I needed was the Python that was >> already >> installed, plus a couple added things. (I needed Python to talk to >> MySQL, and >> that I had to install MySQL, so there was likely no native ability >> to do so on >> the Mac I've got.) > > This is my point. You couldn't actually get anything done without > downloading and installing _something_. Once you're doing that, it > would > have made very little difference if you had downloaded and installed a > new version of Python as well. It's important to note, though, that you're looking at a use case of someone who's already familiar with databases, MySQL, etc. and knows exactly what they want to use Python to do. But there are lots of other use cases, most particularly people simply evaluating the basic capabilities of the language or just getting started programming, where people wouldn't need to install extension modules (at least, not right away) and who probably would do fine with the Apple- installed Python. I doubt most people who start with the existing Python 2.3 will stick with it, unless of course it happens to work and do everything they need it to do. (I was fine with 2.3 for over a year after 2.4 was released, believe it or not!) But it will take them far enough that they will realize that this 'Python' is a good thing and determine they'd like to upgrade to 2.4. > However, what would have made a difference is whether or not a package > for the MySQL lib were easily available or not. That's why whatever > the > MacPython community endorses and documents should be a version with as > broad package support as possible. I think that's 2.4.*, rather > than the > Apple supplied python. If broad package support was going to happen on Mac, I really think it would have happened by now. The packaging effort that has happened has been led by a couple of volunteers, and a few random extension developers, and I don't see why standardizing on Python 2.4 will change that, because anyone who wants to create a package even today can just package against whatever Python they have and post it on their web site or somewhere else. Whoever can use it, can use it. Users can ask for other packages if they want them. I think you have to think about why exactly people aren't packaging, and to give you some 'data' on the issue, I'll tell you why I don't package: I don't have time to support or maintain the packages. As much as I love the Python community, I can't afford to be a point of support when something breaks, or when someone needs an upgrade, etc. and I don't believe in just dumping things in somebody's lap and saying "good luck!" I can't speak for anyone else, but I think it's a logical way of thinking. Plus, the size of the Mac userbase in consideration of other platforms is mostly unknown. We all have to choose where to devote our time. The only solutions to this that I see are either to get a bunch of money and devoting it to packaging efforts, which isn't likely to happen, or do a quick writeup for beginners about what setup.py commands can be used to install most Python packages. Get them started. Sometimes all this stuff seems so hard just because the user lacks one critical piece of information or one step in a process that we all think is simple and obvious. I must have thought to myself "wow, you can do that?!" about five times when reading Robin's wxPython build process docs. He was "just* trying to help users learn how to build wxPython, but his docs were so clear and so detailed that he helped me learn more about how building software on *nix works. As someone coming from a Win, and now Mac, background, I thought those docs were more helpful than most of the "real" *nix docs out there because Robin didn't assume I was already a *nix scripting guru. In short, you might be surprised at how many potential Mac Python users would really be helped simply by reading Bill Jannsen's step-by- step tutorial. I strongly feel we should put that up for beginners' in some sort of "30-second Python quick start", as was suggested earlier. Instant gratification has been found, in some instances ;-), to have a positive impact on peoples' first impression of your product or service. ;-) > In addition, if you have your code running just fine and dandy under > Apple's python, then you upgrade to 10.5, chances are that your app > will > no longer work, as Apple is likely to yank their python out from under > you. What do you mean by this? None of my Panther scripts stopped working under Tiger (I do have a couple ;-), and I didn't even touch Python 2.4 on Mac until around October, where they still worked as they always did on 2.3. Why should I now assume 10.5 is going to break all my apps? Thanks, Kevin > If it were running with a user-installed Python, chances are it > would keep working. > > -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 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Wed Feb 8 10:49:36 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 01:49:36 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> Message-ID: On Feb 8, 2006, at 1:06 AM, Kevin Ollivier wrote: >> In addition, if you have your code running just fine and dandy under >> Apple's python, then you upgrade to 10.5, chances are that your app >> will >> no longer work, as Apple is likely to yank their python out from >> under >> you. > > What do you mean by this? None of my Panther scripts stopped working > under Tiger (I do have a couple ;-), and I didn't even touch Python > 2.4 on Mac until around October, where they still worked as they > always did on 2.3. Why should I now assume 10.5 is going to break all > my apps? Unless you're a unix person, there's very few useful things you can do with Python 2.3 sans third party extensions (especially on Panther, where wx and tkinter were not shipped). All of those extensions, or at least a .pth hack if you just did an upgrade, need to be installed to keep that working. Applications built with py2app or bundlebuilder are even worse off. Mac OS X 10.5 will surely ship with at least 2.4.2, which means all extensions built against any previous vendor Python will break, period. Additionally, all of the WASTE-based stuff (the shipping Python IDE, the worthless PackageManager, etc.) is incompatible with i386. Only the most basic mostly platform independent scripts are going to work with Mac OS X 10.5. If a third party Python is used, it will work forever... or at least as long as Apple maintains basic API compatibility with the version of the OS it was built with (whether through emulation or otherwise). I have Python applications built on Mac OS X 10.2 that work on i386 Mac OS X 10.4 because they used a third party Python. If those applications had depended on /usr/bin/python and extensions linked against it, then it would be toast -- especially because bundlebuilder doesn't have a PPC bootstrap. bundlebuilder-built applications (assuming semi-standalone), without Info.plist changes, will launch with an i386 Python and almost definitely won't work at all unless they don't include any extensions at all. If we do strongly recommend that only third party builds of Python are used, then we don't have to say "I told you so" to as many people when their apps break a year or two later. The package database and the documentation also become shorter and more maintainable if only recent third party builds are supported. There will be much less confusion if there's one-- and preferably only one --obvious way to use Python on Mac OS X. Given these caveats and limited resources, the vendor Python is absolutely irrelevant as far as I am concerned. If someone wants to deal with separate support and documentation for what ships with Mac OS X 10.3, Mac OS X 10.4, and Mac OS X 10.5 then have fun, but I am NOT interested in that. -bob From w.northcott at unsw.edu.au Wed Feb 8 13:18:32 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Wed, 8 Feb 2006 23:18:32 +1100 Subject: [Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff In-Reply-To: <5FDFB8BC-4A33-4EEE-955F-0DEC3BFB3B3B@redivi.com> References: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> <5FDFB8BC-4A33-4EEE-955F-0DEC3BFB3B3B@redivi.com> Message-ID: <83BA29D9-2158-41AB-A4AE-4E011BCF750F@unsw.edu.au> Not happy with the replies I received, I have ground this very small and think I now understand what is going on. Try the following test program: #define _POSIX_C_SOURCE 200112L #include int main () { } Save it once as posix_test.c and again as posix_test.cpp. Try to compile them: [PM-G5BN:Shared/Public/Python] billn% gcc posix_test.c [PM-G5BN:Shared/Public/Python] billn% gcc posix_test.cpp In file included from /System/Library/Frameworks/ CoreServices.framework/Frameworks/CarbonCore.framework/Headers/ CarbonCore.h:65, from /System/Library/Frameworks/ CoreServices.framework/Headers/CoreServices.h:21, from /System/Library/Frameworks/Carbon.framework/ Headers/carbon.h:20, from posix_test.cpp:3: /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/MacMemory.h: In function `void BlockZero(void*, long int)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/MacMemory.h:1585: error: ` bzero' undeclared (first use this function) /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/MacMemory.h:1585: error: (Each undeclared identifier is reported only once for each function it appears in.) In file included from /System/Library/Frameworks/ CoreServices.framework/Frameworks/CarbonCore.framework/Headers/ CarbonCore.h:161, from /System/Library/Frameworks/ CoreServices.framework/Headers/CoreServices.h:21, from /System/Library/Frameworks/Carbon.framework/ Headers/carbon.h:20, from posix_test.cpp:3: /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function `long double gammal(long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2031: error: ` gamma' undeclared (first use this function) /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function `long int rinttoll(long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2145: error: ` rinttol' undeclared (first use this function) /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function `long int roundtoll(long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2183: error: ` roundtol' undeclared (first use this function) [PM-G5BN:Shared/Public/Python] billn% The POSIX specifications only cover C not C++. It is nonsense to define _POSIX_C_SOURCE or _XOPEN_SOURCE in a C++ program. So it seems to me that the correct fix for the problems is not to to drop the _POSIX_C_SOURCE and _XOPEN_SOURCE definitions. That is throwing the baby out with the bathwater. The right approach is to wrap them in '#if !defined(__cplusplus). Nothing I have seen so far provides any evidence to contradict Apple's assertion that Tiger is POSIX compliant. Cheers Bill Northcott From charles.hartman at conncoll.edu Wed Feb 8 14:44:41 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 08:44:41 -0500 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> Message-ID: <4C609983-339C-49AE-8509-CA22B9DC4F83@conncoll.edu> I'm watching these responses & collecting views. (Obviously I'm also watching for comments on my "New Page, first proposal" outlline.) I'll propose changes to the page organization when things settle out a little more. Charles Charles Hartman Professor of English, Poet in Residence Connecticut College charles.hartman at conncoll.edu *the Scandroid* is at cherry.conncoll.edu/cohar/Programs.htm From chrisporter9 at wi.rr.com Wed Feb 8 15:36:04 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Wed, 8 Feb 2006 08:36:04 -0600 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <43E998B7.3000809@noaa.gov> Message-ID: > Chris Porter wrote: > > And here, Mac comes with Python! Very nice. > > That shouldn't be downplayed. All I needed was the Python that was already > > installed, plus a couple added things. (I needed Python to talk to MySQL, and > > that I had to install MySQL, so there was likely no native ability to do so on > > the Mac I've got.) > > This is my point. You couldn't actually get anything done without > downloading and installing _something_. Once you're doing that, it would > have made very little difference if you had downloaded and installed a > new version of Python as well. > > However, what would have made a difference is whether or not a package > for the MySQL lib were easily available or not. That's why whatever the > MacPython community endorses and documents should be a version with as > broad package support as possible. I think that's 2.4.*, rather than the > Apple supplied python. > > In addition, if you have your code running just fine and dandy under > Apple's python, then you upgrade to 10.5, chances are that your app will > no longer work, as Apple is likely to yank their python out from under > you. If it were running with a user-installed Python, chances are it > would keep working. That's something the page should shout to the world about! (because I had no idea about this) "The advantages of not using Apple's versions!" From hengist.podd at virgin.net Wed Feb 8 15:56:50 2006 From: hengist.podd at virgin.net (has) Date: Wed, 8 Feb 2006 14:56:50 +0000 Subject: [Pythonmac-SIG] a beginner's list (Or: everyone's talking; no-one's listening) In-Reply-To: <43E998B7.3000809@noaa.gov> References: <43E998B7.3000809@noaa.gov> Message-ID: Christopher Barker wrote: >This is my point. You couldn't actually get anything done without downloading and installing _something_. Once you're doing that, it would have made very little difference if you had downloaded and installed a new version of Python as well. I think what's happening in this discussion is we've got two camps talking past one another. One side sees the problem primarily as a marketing issue: "How can we attract the widest possible audience, i.e. both serious and casual users?" The other sees it as a purely technical issue: "How can we provide the latest, best tools for the minimum amount of time and work?" It's the classic OSS conundrum: nobody's getting paid to do any of this, so they either focus on supporting areas that they're already working in themselves, or they get a missionary streak and commit to supporting areas outside of their own interests. The first approach provides a fair amount of benefit for a little extra work; the second provides greater benefit but requires more work to support, i.e. a long term commitment to support work that provides no personal gain (except karma). I have no problem with folk like Chris and Bob saying they're only interested in supporting serious comers. They just need to acknowledge that such a "pro-oriented" focus won't, and isn't intended to, appeal to all sections of the audience out there. (Hint: casual browsers are liable to mis-read this stance as "NO PLAYING ON THE GRASS: YOU MUST DO EVERYTHING WE SAY OR WE AREN'T TALKING TO YOU!" and head straight to another language were they'll feel more welcome.) I have no problem with the more evangelically minded saying "pro-market's fine, but we want to attract lots of non-pros too". They just need to acknowledge that they're not looking for assistance from the pro-camp to help out with the non-pro-oriented marketing and support work. (They also need to sit down and think carefully about just how much unrewarded missionary work they're willing to commit to on a long-term basis; it's all too easy to come up with grandiose plans that turn to dust after six months when it dawns just how big a commitment they've taken on.) So there's two options to this whole "let's market Mac Python" thing. Either go for the "my way or the highway" approach, which'll largely look after itself but cater to only a subset of the possible market and let Ruby take the rest. OR agree to work alongside one another as two fairly independent teams, one catering to the casual end of the market, the other to the serious. If folk can agree on the latter approach, both camps should set up on the same website, and each look after their own sections of interest. As for the frontpage, split it across the middle: top half for the cheery "let's introduce you to Python in 30 seconds" spiel; bottom half for "here be teh hardcore haxxors; come be one with us if you think you're hard enough". And somewhere in the middle, you can have a Top 10 lists of why it's really worth upgrading to the latest and greatest Python et-al, providing a natural path for casual users to follow once we've got our hooks in 'em good and proper. has -- http://freespace.virgin.net/hamish.sanderson/ From pecora at anvil.nrl.navy.mil Wed Feb 8 17:18:27 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 08 Feb 2006 11:18:27 -0500 Subject: [Pythonmac-SIG] a beginner's list (Or: everyone's talking; no-one's listening) In-Reply-To: References: <43E998B7.3000809@noaa.gov> Message-ID: <43EA19D3.5000005@anvil.nrl.navy.mil> has wrote: > So there's two options to this whole "let's market Mac Python" thing. Either go for the "my way or the highway" approach, which'll largely look after itself but cater to only a subset of the possible market and let Ruby take the rest. OR agree to work alongside one another as two fairly independent teams, one catering to the casual end of the market, the other to the serious. > > If folk can agree on the latter approach, both camps should set up on the same website, and each look after their own sections of interest. As for the frontpage, split it across the middle: top half for the cheery "let's introduce you to Python in 30 seconds" spiel; bottom half for "here be teh hardcore haxxors; come be one with us if you think you're hard enough". And somewhere in the middle, you can have a Top 10 lists of why it's really worth upgrading to the latest and greatest Python et-al, providing a natural path for casual users to follow once we've got our hooks in 'em good and proper. > > has > I agree with the 2 teams approach and hope I can add something to the non-pro/scientific user end. I would encourage Charles H. to get the new web page up sooner than later. That's not demanding he work and I watch, but I think that seeing a page in our browsers with place holders for things to be done would be helpful. It would show us visually what needs to be filled in and, for me, certainly would be clearer where I can add my limited knowledge. We can feed him info as we learn about different parts. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From janssen at parc.com Wed Feb 8 17:43:03 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 08:43:03 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Tue, 07 Feb 2006 21:13:50 PST." Message-ID: <06Feb8.084306pst."58633"@synergy1.parc.xerox.com> I think a "jargon list" is a great idea! Bill From pecora at anvil.nrl.navy.mil Wed Feb 8 17:50:11 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 08 Feb 2006 11:50:11 -0500 Subject: [Pythonmac-SIG] More on Beginner's list - the 2.4.1 Install Message-ID: <43EA2143.1020608@anvil.nrl.navy.mil> OK, you guys have twisted this non-pro's arm enough. I just installed Python 2.4.1 on my Tiger machine from Bob Ippolito's site (not the active state one, but the framework). Yes, I followed up with the TigerFix install. But I still get Python 2.3.5 when I start python in my terminal. HAHAHAHAHAHA. Chris, Bob, just kidding. Just kidding. I've seen that one so much on this list that even I remembered to edit my .tcshrc file and put /usr/local/bin before /usr/bin. So for Charles H. and all of us working on the Beginner's list. For the install of 2.4.1 as a separate, better Python we need to add, 1) Get the Python 2.4.1 package from Bob Ippolito's site [the link here] (thank you, Bob, very much) 2) If you're running Tiger (10.4.x) also get the TigerFix package [the link here] 3) Install Python 2.4.1 -- maybe a little detail for those who haven't seen .dmg files and packages. 4) Install TigerFix 5) Edit your appropriate terminal login file (.profile, .bash_profile, .tcshrc, etc -- maybe listing which go with which shell and maybe for the novices how you find and edit hidden files!). Put /usr/local/bin before /usr/bin in the path. I guess the whole path thing should be spelled out. 6) Remind people that if they are using pythonw so they can open GUI things, that pythonw 2.4.1 is also installed with the 2.4.1 package and is used automatically once you change the login file. In the vein of someone else here who recommended we not denigrate the Apple installed Python, I agree. Just treat that like software companies do a demo or "stripped-down" version of their application. You can use it for simple stuff. Take Python for a test drive and see if you like it. How nice. No need to puzzle over complex installation and package dependencies. Just hop in and turn the key. Then, oh, by the way, if you want a better version that offers even more, here's a simple way to get it (directions as above). I'm sure there's more that can be added to this and I'm willing to write more (including about paths -- as much/little as I know) for the beginner's list. Charles H. tell me what might help. To everyone, Please correct any of the above. I am not an expert. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From charles.hartman at conncoll.edu Wed Feb 8 17:42:53 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 11:42:53 -0500 Subject: [Pythonmac-SIG] a beginner's list (Or: everyone's talking; no-one's listening) In-Reply-To: <43EA19D3.5000005@anvil.nrl.navy.mil> References: <43E998B7.3000809@noaa.gov> <43EA19D3.5000005@anvil.nrl.navy.mil> Message-ID: On Feb 8, 2006, at 11:18 AM, Louis Pecora wrote: > > I agree with the 2 teams approach and hope I can add something to the > non-pro/scientific user end. I would encourage Charles H. to get the > new web page up sooner than later. That's not demanding he work and I > watch, but I think that seeing a page in our browsers with place > holders > for things to be done would be helpful. It would show us visually > what > needs to be filled in and, for me, certainly would be clearer where I > can add my limited knowledge. We can feed him info as we learn about > different parts. I'd like to get some feedback on the organization I proposed before I start trying to flesh anything out. The better the organization before I start, the less confusing (not to mention time-consuming) the work to refine it. I don't promise anything by the end of the weekend, but I'll hope to crank out a first (and text-only, not html) mock-up. Keep them cards & letters comin'. Charles From pecora at anvil.nrl.navy.mil Wed Feb 8 18:00:58 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 08 Feb 2006 12:00:58 -0500 Subject: [Pythonmac-SIG] a beginner's list (Or: everyone's talking; no-one's listening) In-Reply-To: References: <43E998B7.3000809@noaa.gov> <43EA19D3.5000005@anvil.nrl.navy.mil> Message-ID: <43EA23CA.8020504@anvil.nrl.navy.mil> Charles Hartman wrote: > > On Feb 8, 2006, at 11:18 AM, Louis Pecora wrote: > > > I'd like to get some feedback on the organization I proposed before I > start trying to flesh anything out. The better the organization before > I start, the less confusing (not to mention time-consuming) the work > to refine it. I don't promise anything by the end of the weekend, but > I'll hope to crank out a first (and text-only, not html) mock-up. > > Keep them cards & letters comin'. > > Charles > Agree. Here's what you wrote: Somebody who comes idly to the idea of programming in Python, and finds the pythonmac page, will be happy if the result is an afternoon's work that ends in a "hello world," possibly in a window. Using my own arbitrary preferences, that would entail: 1. downloading & installing Bob's framework 2. downloading & installing TigerPython24Fix 3. adding /usr/local/bin to the PATH 4. downloading & installing wxPython 5. downloading & installing [fill in name of IDE] 6. starting to browse how-to-program sites and writing some bits ----------------------------------------------------------------------------- I like what Chris Baker had (If I can remember it). It involved a division into various categories like: o Getting right into the Python already on your Mac (yes, it's already there!) o Getting a more powerful (better word here?) version of python (2.4.1) that will work better with other packages and provide more features (Charles, your list here, items 1. to 3. for a three-step process and an easy install of 2.4.1 o Add-ons (other packages, better word here?): a short list, where to get them, how to install them, pointers to other more complete lists. Here we put wxPython, IDEs, o Your item 6. ----------------------------------------------------------------------------- I found Chris B.'s list (which I like). It offers some good categories and overlaps the above. Hope this helps. [from Chris B.] Welcome to Python on the Mac! Intro- links to other python resources, etc. What Python should I use? -- brief discussion of the options. --The "Recommended Option" -- for users without special needs or newbies that don't know what they need ----- Link to Binary Python 2.4.* installer ----- Instructions of stuff to do after installing: -- Install TigerPython24Fix -- Add /usr/local/bin to your PATH -- Note: couldn't those steps be optionally done by the installer? ----- Link to Collection of packages on Pythonmac.org ----- Link to Wiki pages for people that need to use other Pythons. Perhaps build instructions, etc. What do I do now? -- How to run from command line -- IDE/editor options -- Pointers to "learn python" resources -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From pecora at anvil.nrl.navy.mil Wed Feb 8 18:03:56 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 08 Feb 2006 12:03:56 -0500 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb8.084306pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.084306pst."58633"@synergy1.parc.xerox.com> Message-ID: <43EA247C.7090704@anvil.nrl.navy.mil> Bill Janssen wrote: > I think a "jargon list" is a great idea! > > Bill > _______________________________________________ > Absolutely. I read a thread that had so much about Eggs and Cheese Shop that I thought I was reading my shopping list. I'm still not quite sure what these are even though I made some attempt to find out. No, I am not stupid ... well not too much. A jargon page with some links would be nice. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From janssen at parc.com Wed Feb 8 18:03:53 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 09:03:53 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Wed, 08 Feb 2006 01:49:36 PST." Message-ID: <06Feb8.090401pst."58633"@synergy1.parc.xerox.com> > Unless you're a unix person, there's very few useful things you can > do with Python 2.3 sans third party extensions Ah, I think I'm beginning to understand all the confusion. MacOS X is the largest-selling UNIX distro in the world. Linux and Solaris people are deserting in droves and moving to Apple machines running OS X. There's a huge and growing population of Unix people using Macs. So this ("unix person") is a non-negligible audience. May even be a majority of Mac users by now. Full disclosure: I'm a UNIX person. The first thing I do when I get a new Mac is make sure X11 is installed on it, and in my Login Items. The second thing I do is build an X11 version of GNU Emacs from the CVS repository. I don't mind the Terminal's oddities because I never use it; all my shells are in Emacs shell buffers. I rarely use the Finder; it seems a fairly dorky program. But I like the Mac as a very nice UNIX platform with cute visual glitz. I pretty much never write Mac-specific code. For me, the supplied Python works pretty well; I can't write past Python 2.3 anyway (though I'd like to), because there are lots of machines in my target population that still aren't running 2.4, so I have to be conservative. Just going to 2.3 is a bit daring -- you have to check to see where it is in the Debian packaging chain, for instance. A great deal of my code works with just the basic Python and stdlib. Sometimes I need to require PIL or reportlab or Medusa. And on the Mac, just unpacking the sources for those extensions and then saying "python setup.py install" (in a shell) works just fine. The additional complexity of installing packages and eggs seems overkill. I can see that if you are a pre-MacOSX Mac person, used to all the groundbreaking UI complexity of Apple in the 80's and 90's, your view and your needs might be different. Or if you are a for-Mac developer. But most people aren't. Bill From janssen at parc.com Wed Feb 8 18:08:40 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 09:08:40 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Wed, 08 Feb 2006 06:36:04 PST." Message-ID: <06Feb8.090846pst."58633"@synergy1.parc.xerox.com> > > In addition, if you have your code running just fine and dandy under > > Apple's python, then you upgrade to 10.5, chances are that your app will > > no longer work, as Apple is likely to yank their python out from under > > you. If it were running with a user-installed Python, chances are it > > would keep working. > > That's something the page should shout to the world about! > (because I had no idea about this) > > "The advantages of not using Apple's versions!" You had no idea about it because it's not going to happen. "Apple is likely to yank their python out from under you"? Come on, this is absurd. In 10.5, /usr/bin/python is likely to be Python 2.4 instead of 2.3, but the odds are 9999 to 1 that it will be there, and the Python community has taken great pains to make sure 2.4 is backwards-compatible with 2.3. We can only quote odds because none of us work for Apple, but still, in my opinion -- what troll-bait! Bill From charles.hartman at conncoll.edu Wed Feb 8 18:20:55 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 12:20:55 -0500 Subject: [Pythonmac-SIG] a beginner's list (Or: everyone's talking; no-one's listening) In-Reply-To: <43EA23CA.8020504@anvil.nrl.navy.mil> References: <43E998B7.3000809@noaa.gov> <43EA19D3.5000005@anvil.nrl.navy.mil> <43EA23CA.8020504@anvil.nrl.navy.mil> Message-ID: <5C4868F8-27EE-4490-B296-D960A3E93DB0@conncoll.edu> See my earlier message, subject "New Page, first proposal", for a possible organization of the page that builds on Chris Barker's suggestons (and others). The "beginner's list" thread is (just) an offshoot of one question posed there. Charles On Feb 8, 2006, at 12:00 PM, Louis Pecora wrote: > Charles Hartman wrote: >> >> On Feb 8, 2006, at 11:18 AM, Louis Pecora wrote: >> >> >> I'd like to get some feedback on the organization I proposed >> before I start trying to flesh anything out. The better the >> organization before I start, the less confusing (not to mention >> time-consuming) the work to refine it. I don't promise anything by >> the end of the weekend, but I'll hope to crank out a first (and >> text-only, not html) mock-up. >> >> Keep them cards & letters comin'. >> >> Charles >> > Agree. > > Here's what you wrote: > > Somebody who comes idly to the idea of programming in Python, and > finds the pythonmac page, will be happy if the result is an > afternoon's work that ends in a "hello world," possibly in a > window. Using my own arbitrary preferences, that would entail: > > 1. downloading & installing Bob's framework > 2. downloading & installing TigerPython24Fix > 3. adding /usr/local/bin to the PATH > 4. downloading & installing wxPython > 5. downloading & installing [fill in name of IDE] > 6. starting to browse how-to-program sites and writing some bits > > ---------------------------------------------------------------------- > ------- > > I like what Chris Baker had (If I can remember it). It involved a > division into various categories like: > > o Getting right into the Python already on your Mac (yes, it's > already there!) > > o Getting a more powerful (better word here?) version of python > (2.4.1) that will work better with other packages and provide more > features (Charles, your list here, items 1. to 3. for a three-step > process and an easy install of 2.4.1 > > o Add-ons (other packages, better word here?): a short list, > where to get them, how to install them, pointers to other more > complete lists. Here we put wxPython, IDEs, > o Your item 6. > > ---------------------------------------------------------------------- > ------- > > I found Chris B.'s list (which I like). It offers some good > categories and overlaps the above. Hope this helps. > > > [from Chris B.] > > Welcome to Python on the Mac! > > Intro- > links to other python resources, etc. > > What Python should I use? > -- brief discussion of the options. > > > --The "Recommended Option" -- for users without special needs or > newbies that don't know what they need > ----- Link to Binary Python 2.4.* installer > ----- Instructions of stuff to do after installing: > -- Install TigerPython24Fix > -- Add /usr/local/bin to your PATH > -- Note: couldn't those steps be optionally done by the > installer? > ----- Link to Collection of packages on Pythonmac.org > > ----- Link to Wiki pages for people that need to use other > Pythons. Perhaps build instructions, etc. > > What do I do now? > -- How to run from command line > -- IDE/editor options > -- Pointers to "learn python" resources > > > > > > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > From Chris.Barker at noaa.gov Wed Feb 8 19:06:48 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 10:06:48 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: Message-ID: <43EA3338.4070306@noaa.gov> I wrote this yesterday, but didn't get a chance to click send before catching a bus. Thanks for doing this Charles. (I've put in my responses to multiple post here) > also I hope a prominent one slapped onto the top of the MacPython > site.) Do you mean Jack Jansen's site? > For a page title that covers the ground broadly and accurately, I > propose Python on the Mac Looks good, Does "Mac" now mean OS-X unambiguously? > Four stages in the project are foreseeable: 1. Establish the basic > organization of the page 2. Collect the essential technical data, and > probably also less essential materials to be relegated to secondary > pages 3. Produce some friendly prose 4. Build the html for the page One more step: Develop a consensus as to the "standard" way to use Python in the Mac to be recommended to newbies. Also, the Main Page (or pages) should be brief, with the more complicated instructions and discussion put in the Wiki. > Here I'm proposing an approach to #1. I suggest the page be organized > by audience, I think the main page should be oriented to the newbie, with obvious links to more complicated topics. > ===== the Python-on-the-Mac page ======================= > > [1] "If you're a Mac user who wants to learn to write Python > programs": note Apple distro, be politely disparaging toward it, > provide links to Bob's framework, with notes (how extensive is this?) > on other stuff required ActiveState's framework, with similar notes Maybe a link to a Wiki page about "other MacPython distributions: Apples, fink, darwinports, Activestate, compiling from source. One, and only one (maybe two, for 10.4 and 10.4 -- see below), distribution should be suggested on the main page. > [2] "If you want an editor or full-fledged IDE (rather than using the > Terminal)": provide links, with brief descriptions, to Wing IDE > BBEdit/TextWrangler ?? discuss briefly the non-terrors of working in > the Terminal This is tough, as I think there is still no really good, bug free IDE (at least no open source ones). I wish there was one we could really recommend. > [3] "If you want to write programs with windows and buttons": > [4] "If your programs need other specialized tools": I think these should be links to Wiki Pages: """ You can write a variety of different kinds of software with Python, depending on what your goals are, there are different libraries you can use: For simple command line tools, you can just use python and the terminal. For Web Application development: For GUI programming: This is a pretty big one. I think it should be structured a bit like; Coding for just the mac: Coding for cross platform: Discussion of TK and wx, and links to pages about each of them. For Scientific programming: """ > [5] "If you want to write C (or other) extensions, or embed Python, > or ?": Describe the current state of considerations about target Mac > system This is an advanced topic that should be in the Wiki. I don't know that it needs a mention on the Main page at all. > 1. I'm not at all clear whether it's necessary to address the > question of platform (is the user running 10.3 or 10.4? does the > sub-version matter?) before that last, extensions stage. I may or may not, depending on what we decide the "standard" Distribution should be. At the moment, I'm inclined to say this: If you're running OS-X 10.3.*: Bob's Framework Build of 2.4.1 (or better yet, a new one of 2.4.2, if someone wants to built it) If you're running OS-X 10.4.* The new, upcoming Universal Framework Build. Ideally, there is a Wiki page explaining a bunch of the issues, but I think this keeps it simple, and will fit most needs. Then we need Pointers to download pages for packages: One page for the 10.3 build. One page for the 10.4 build. Maybe a link to a page with all the other packages that are no at pythonmac.org/packages > 2. Would it be legitimate to start the page off with a little list of > things to do for those who get worried by too many choices? Yes. > For me, the list would be (1) get Bob's framework (2) pick and > install an IDE Given the state of IDEs and their installers, don't start there. Start with a the terminal and a text editor. > (3) go get one of the following books or read the following > instructional sites. Or point them to: http://wiki.python.org/moin/BeginnersGuide > 3. Once this sketch is fleshed out fully enough to be not misleading, > I fear that keeping it on a single page may get cumbersome. If that > happens, do we prefer a couple of sequential pages ("Next?") or some > kind of branch? I think I answered that: One page and the rest in the Wiki, except the download pages. > Somebody who comes idly to the idea of programming in Python, and > finds the pythonmac page, will be happy if the result is an > afternoon's work that ends in a "hello world," possibly in a window. > Using my own arbitrary preferences, that would entail: > > 1. downloading & installing Bob's framework 2. downloading & > installing TigerPython24Fix 3. adding /usr/local/bin to the PATH We really should build an installer that does the three of these at once (with the PATH editing optional). I have no idea how to do that, though. > 4. downloading & installing wxPython I don't think wxPython is that starting point. And I'm a big wxPython fan. > 5. downloading & installing [fill in name of IDE] Until there is one robust enough to really recommend, we're not there yet. How's SPE doing on the mac these days? Also, different IDEs are different, they each need their own tutorial, ideally one Mac-centered, but that's no our job. I do think a little "getting started" tutorial with a editor and the command line is a good idea, however. enough that they can read one of the intro books and know what to do. Bill Janssen wrote: > Who wants to open windows? Why is a GUI automatically necessary? I agree, it's not. And if your goal is web programming, it never will be. > And if it is, all you need is already there on 10.4 Here's where I'm not sure. I do like that it's this easy, and I know the fact that python comes with OS-X has been good marketing for me in my organization. As for the Apple-supplied Python. Yes, it's fine. I used it for a good while. However, it really is getting pretty old. That isn't a problem in and of itself, but people are now making third-party packages that require 2.4, and most of the people building and distributing binaries are doing it for 2.4.1 also. While it's easier for a newbie to get started with the built-in python, they may well hit a brick wall soon. I think that anyone doing any real work with Python is going to need use a third party package pretty soon in the game. As they can't use only pre-installed stuff, it's not that big a deal for them to install a new python as well, if we make it easy. I'm a bit wary of saying to newbies: "Here you go, look how easy this is!", then when they start doing more, saying: "By the way, no that you're really doing something real, you need to go do this extra stuff" I'm not convinced about this. I may vote for a link near the top of the main page labeled "The ultra-quick easy intro to Python", to a Wiki page with this: , in three minutes: > 1) Click on Applications/Utilities/Terminal. > > 2) In the terminal window, enter the following line: > > % pythonw > > 3) You will see a prompt ">>>". At the prompt, enter the following > line: > >>>> print "Hello, World!" > > and you will see "Hello, World!" written back to you. > > 4) To do this in a window, enter the following lines at the ">>>" > prompt: > >>>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1, >>>> "Hello World").Show(1) app.MainLoop() > > That's it! Then maybe a little discussion of why (and when) one might want to download a newer Python. Also a pointer back to the page that discusses what GUI toolkit tone might want to use. > *Don't* deprecate the Apple pre-installed Python! Rejoice in it! > And then hint that even better things are available in 2.4.x... I think it needs to be a strong suggestion, rather than a hint. A big part of this is that having a large collection of pre-built packages is key, and I don't see that happening for Apple's Python. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From charles.hartman at conncoll.edu Wed Feb 8 19:21:57 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 13:21:57 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EA3338.4070306@noaa.gov> References: <43EA3338.4070306@noaa.gov> Message-ID: <11BE1F65-F496-4B06-AC1C-F7E172D891ED@conncoll.edu> Thanks Chris. What's below is not a complete response, just a couple of specific, interim notes while I study up on the rest. Charles On Feb 8, 2006, at 1:06 PM, Christopher Barker wrote: >> also I hope a prominent one slapped onto the top of the MacPython >> site.) > Do you mean Jack Jansen's site? Yes. I'm thinking of what shows up at the top of likely Google searches; I think that's pythonmac.org and "MacPython Website." >> For a page title that covers the ground broadly and accurately, I >> propose Python on the Mac > Looks good, Does "Mac" now mean OS-X unambiguously? That's a good question. (And what *is* the situation for OS9ers who want Python?) >> For me, the list would be (1) get Bob's framework (2) pick and >> install an IDE > Given the state of IDEs and their installers, don't start there. Start > with a the terminal and a text editor. I have reservations about this. Particularly if, as you say and as I agree, the target audience is newcomers to Python (assumed not to be newcomers to the Mac), then a way to avoid starting with the Terminal is essential -- in fact, I'd say it's a primary motive in doing this project at all. Hence my support of: >> Somebody who comes idly to the idea of programming in Python, and >> finds the pythonmac page, will be happy if the result is an >> afternoon's work that ends in a "hello world," possibly in a window. >> Using my own arbitrary preferences, that would entail: >> 1. downloading & installing Bob's framework 2. downloading & >> installing TigerPython24Fix 3. adding /usr/local/bin to the PATH > We really should build an installer that does the three of these at > once > (with the PATH editing optional). I have no idea how to do that, > though. But it's true that this is a reasonable alternative beginning path: > I do think a little "getting started" tutorial with a editor and the > command line is a good idea, however. enough that they can read one of > the intro books and know what to do. Here's a similar crux: > Bill Janssen wrote: >> Who wants to open windows? Why is a GUI automatically necessary? One answer: exactly the people conceived as the likely entry-level audience for this page. If you're a Mac user, confronted with a programming language/environment, one of the first things you'll want to know is how to make a little windowing app (whether you know that's what it's called or not). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/f5b1237f/attachment.html From Chris.Barker at noaa.gov Wed Feb 8 19:32:48 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 10:32:48 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> Message-ID: <43EA3950.1010807@noaa.gov> Kevin Ollivier wrote: > It's important to note, though, that you're looking at a use case of > someone who's already familiar with databases, MySQL, etc. and knows > exactly what they want to use Python to do. The only point was that they knew what they wanted to do, and it involved external packages. If they were less familiar, my point would be stronger. > where > people wouldn't need to install extension modules (at least, not right > away) and who probably would do fine with the Apple-installed Python. This is key: 1) you really can't get far without extension modules 2) Where do you put the learning/effort curve? (a) up front: do this extra work, and you're set. (b) later: Here's an ultra easy way to do it --- then when you try to do something real, you'll need to do the extra work then. (b) is probably better fro selling something -- "get them hooked, then tell them how much work they really have to do". That's why most commercial software is structured this way. (a) is better for getting people quickly to where they really need to b if they are going to use Python for real, and I think we can get (a) easy enough that it's not a big deal. The real impediment to getting total newbie/casual users excited about Python on OS-X is the lack of a nice, fully integrated IDE/GUI toolkit with tutorials and all. We'd all like to see that, but none of us need it enough to build it. > (I was fine with 2.3 for over a year after 2.4 was released, > believe it or not!) So was I, but it's really getting pretty old now! > If broad package support was going to happen on Mac, I really think it > would have happened by now. I disagree, but maybe I'm wrong. I think that if we focus on one python version, and create an easy way for people to contribute packages, we can get a better collection. With Py2App and bdist_mpkg, it's really, really, easy to build one, once you've gotten it to build at all. That's been the case for a while, but I do think if we can focus the community, we can do much better. I need to build the packages for my colleagues anyway, if it's easy to contribute them, I will. > I'll tell you why I don't package: > I don't have time to support or maintain the packages. As much as I love > the Python community, I can't afford to be a point of support when > something breaks, or when someone needs an upgrade, etc. and I don't > believe in just dumping things in somebody's lap and saying "good luck!" Here's where I actually agree with your previous point. I have the same issues. I built a matplotlib package (for 2.3 and 2.4, actually) and contributed it to pythonmac.org. Soon enough, MPL was upgraded, and I got the occasional note asking for an upgraded package. I didn't need it myself, so I didn't do it. However, I still think it was helpful that an OS-X user could easily install and try our MPL. If they liked it, they could go through the effort to build the latest version themselves. This is different than the Apple-supplied python issue. I'm only suggesting that we recommend an alternative because we can provide one that's easy to install. I'd never tell newbies to python to go and build their own from the tarball! > do a quick writeup for beginners about what setup.py commands can be > used to install most Python packages. We should certainly do that. However, there are OS-X users without a compiler installed. This is a real problem, and Apple doesn't even make it that easy to install the compiler. Linux users all have compilers. Windows users all get binaries -- the closer we can get to that for the Mac the better. > I must have thought to myself "wow, you can do that?!" about > five times when reading Robin's wxPython build process docs. There is no replacement for good docs, and those are good, but let's face it, there are a LOT of questions on wxPython-users from people trying to build it themselves. > In short, you might be surprised at how many potential Mac Python users > would really be helped simply by reading Bill Jannsen's step-by-step > tutorial. I strongly feel we should put that up for beginners' in some > sort of "30-second Python quick start", as was suggested earlier. > Instant gratification has been found, in some instances ;-), to have a > positive impact on peoples' first impression of your product or service. > ;-) I do think that's a good idea too, but don't let them get too far before suggesting an upgraded Python. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From chrisporter9 at wi.rr.com Wed Feb 8 19:35:45 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Wed, 8 Feb 2006 12:35:45 -0600 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EA3338.4070306@noaa.gov> Message-ID: (snip) > > Then we need Pointers to download pages for packages: > > One page for the 10.3 build. How does a build differ from a system? > One page for the 10.4 build. > > Maybe a link to a page with all the other packages that are no at > pythonmac.org/packages > > > > 2. Would it be legitimate to start the page off with a little list of > > things to do for those who get worried by too many choices? > > Yes. > > > For me, the list would be (1) get Bob's framework (2) pick and > > install an IDE > > Given the state of IDEs and their installers, don't start there. Start > with a the terminal and a text editor. > > > (3) go get one of the following books or read the following > > instructional sites. > > Or point them to: > http://wiki.python.org/moin/BeginnersGuide > > > 3. Once this sketch is fleshed out fully enough to be not misleading, > > I fear that keeping it on a single page may get cumbersome. If that > > happens, do we prefer a couple of sequential pages ("Next?") or some > > kind of branch? > > I think I answered that: One page and the rest in the Wiki, except the > download pages. > > > Somebody who comes idly to the idea of programming in Python, and > > finds the pythonmac page, will be happy if the result is an > > afternoon's work that ends in a "hello world," possibly in a window. > > Using my own arbitrary preferences, that would entail: > > > > 1. downloading & installing Bob's framework 2. downloading & > > installing TigerPython24Fix 3. adding /usr/local/bin to the PATH > > We really should build an installer that does the three of these at once > (with the PATH editing optional). I have no idea how to do that, though. > > > 4. downloading & installing wxPython > I don't think wxPython is that starting point. And I'm a big wxPython fan. > > > 5. downloading & installing [fill in name of IDE] > > Until there is one robust enough to really recommend, we're not there > yet. How's SPE doing on the mac these days? Also, different IDEs are > different, they each need their own tutorial, ideally one Mac-centered, > but that's no our job. > > I do think a little "getting started" tutorial with a editor and the > command line is a good idea, however. enough that they can read one of > the intro books and know what to do. > > Bill Janssen wrote: > > > Who wants to open windows? Why is a GUI automatically necessary? > > I agree, it's not. And if your goal is web programming, it never will be. > > > And if it is, all you need is already there on 10.4 > > Here's where I'm not sure. I do like that it's this easy, and I know the > fact that python comes with OS-X has been good marketing for me in my > organization. > > As for the Apple-supplied Python. Yes, it's fine. I used it for a good > while. However, it really is getting pretty old. That isn't a problem in > and of itself, but people are now making third-party packages that > require 2.4, and most of the people building and distributing binaries > are doing it for 2.4.1 also. While it's easier for a newbie to get > started with the built-in python, they may well hit a brick wall soon. > > I think that anyone doing any real work with Python is going to need use > a third party package pretty soon in the game. As they can't use only > pre-installed stuff, it's not that big a deal for them to install a new > python as well, if we make it easy. > > I'm a bit wary of saying to newbies: "Here you go, look how easy this > is!", then when they start doing more, saying: "By the way, no that > you're really doing something real, you need to go do this extra stuff" > > I'm not convinced about this. I may vote for a link near the top of the > main page labeled "The ultra-quick easy intro to Python", to a Wiki page > with this: > > , in three minutes: > > 1) Click on Applications/Utilities/Terminal. > > > > 2) In the terminal window, enter the following line: > > > > % pythonw I tried typing in python, and got the same response as typing in pythonw. Then I tried "pythonx" "pythona" and "pythong", all of which got me something like this: -bash: pythona: command not found Be nice to know why only some letters after 'python' are allowed. > > 3) You will see a prompt ">>>". At the prompt, enter the following > > line: > > > >>>> print "Hello, World!" > > > > and you will see "Hello, World!" written back to you. >>> print "Hellow Wordl" Hellow Wordl (pretty obvious why I'm not a programmer) > > 4) To do this in a window, enter the following lines at the ">>>" > > prompt: What? What window? Any window? Is window some particular application? > >>>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1, > >>>> "Hello World").Show(1) app.MainLoop() Tried this in a Terminal (window), this is what I got: >>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1,"Hello World").Show(1) app.MainLoop() File "", line 1 import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1,"Hello World").Show(1) app.MainLoop() ^ SyntaxError: invalid syntax (tried it in BBEdit, in an unsaved window, got an "This file doesn?t appear to contain a valid ?shebang? line (application error code: 26304)") Saved it to disk as "Text.py" and tried reopening it and clicking "run" in BBEdit, got this: "/Users/chris/Desktop/Text.py:1: SyntaxError: invalid syntax" > > That's it! Hmmmm. Perhaps there's some threshold of knowledge I've not obtained (yes, pretty obviously), but what I'm getting at is perhaps there could be something on the page that says, "For users of this page, we are going to assume you know: That python is a programming language. That window means... That you are generally familiar with the Terminal app That you know how to construct a program and save it to disk, and run it. That ...." > Then maybe a little discussion of why (and when) one might want to > download a newer Python. Also a pointer back to the page that discusses > what GUI toolkit tone might want to use. > > > *Don't* deprecate the Apple pre-installed Python! Rejoice in it! > > And then hint that even better things are available in 2.4.x... > > I think it needs to be a strong suggestion, rather than a hint. A big > part of this is that having a large collection of pre-built packages is > key, and I don't see that happening for Apple's Python. > > > -Chris > From ronaldoussoren at mac.com Wed Feb 8 19:36:49 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 8 Feb 2006 19:36:49 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43E911E8.20706@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7F57E.6020906@noaa.gov> <04F3EFC4-5824-40CB-92FC-A6D8EBB65389@redivi.com> <43E911E8.20706@noaa.gov> Message-ID: On 7-feb-2006, at 22:32, Christopher Barker wrote: > Bob Ippolito wrote: >> I'll tell you what: I'll drop the ego and get a new pair of >> glasses in >> exchange for five or six million dollars.. > > I'll bet I could package up Python, PyObjC etc. with good > installers and > tutorials for only about a one million dollars. Then maybe another > million to start marketing it. Anyone want to fund my new company? I might want to partner ;-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/7df676a9/attachment.bin From janssen at parc.com Wed Feb 8 19:40:50 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 10:40:50 PST Subject: [Pythonmac-SIG] More on Beginner's list - the 2.4.1 Install In-Reply-To: Your message of "Wed, 08 Feb 2006 08:50:11 PST." <43EA2143.1020608@anvil.nrl.navy.mil> Message-ID: <06Feb8.104056pst."58633"@synergy1.parc.xerox.com> > In the vein of someone else here who recommended we not denigrate the > Apple installed Python, I agree. Just treat that like software > companies do a demo or "stripped-down" version of their application. > You can use it for simple stuff. Take Python for a test drive and see > if you like it. How nice. No need to puzzle over complex installation > and package dependencies. Just hop in and turn the key. In fact, you can go through the whole Python tutorial on the python.org site using the Apple python. Bill From Chris.Barker at noaa.gov Wed Feb 8 19:44:54 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 10:44:54 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb8.090846pst.58633@synergy1.parc.xerox.com> References: <06Feb8.090846pst.58633@synergy1.parc.xerox.com> Message-ID: <43EA3C26.4010208@noaa.gov> Bill Janssen wrote: > You had no idea about it because it's not going to happen. "Apple is > likely to yank their python out from under you"? Come on, this is > absurd. In 10.5, /usr/bin/python is likely to be Python 2.4 instead > of 2.3, but the odds are 9999 to 1 that it will be there, and the > Python community has taken great pains to make sure 2.4 is > backwards-compatible with 2.3. > > We can only quote odds because none of us work for Apple, but still, > in my opinion -- what troll-bait! It was not intended that way. Yes, Apple will most likely supply a Python with 10.5. It will also most likely be a 2.4.*. What I don't see any evidence for is them keeping 2.3.5 around as well. What that means is that all the packages you have compiled and installed for 2.3.* will no longer work. Yes, python-only scripts that use usr/bin/python will most likely work, but that's it. If you think Apple will keep 2.3.* around, in addition to a newer 2.4.*, then tell us why. They didn't keep 2.2* around when 10.3 came out. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Wed Feb 8 19:44:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 8 Feb 2006 19:44:13 +0100 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> Message-ID: <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> On 8-feb-2006, at 10:49, Bob Ippolito wrote: > > Mac OS X 10.5 will surely ship with at least 2.4.2, Maybe, maybe not. Who knows what apple will do? ;-) ;-) I agree that anyone that ships Python applications shouldn't rely on Apple's python unless they have a very good reason to do so (such as wanting to use Apple's Quartz wrappers). > > Given these caveats and limited resources, the vendor Python is > absolutely irrelevant as far as I am concerned. If someone wants to > deal with separate support and documentation for what ships with Mac > OS X 10.3, Mac OS X 10.4, and Mac OS X 10.5 then have fun, but I am > NOT interested in that. This is a very good reason for not pointing newbies to the system python on pythonmac.org: unless anyone steps up to *seriously* support the system python there won't be properly packages extension packages for the system python. I do support system python for PyObjC, but even there it is mostly "lets check if it still works" around release time. For day-to-day work I'm using a framework installation of Python 2.4. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/9969e2be/attachment-0001.bin From rutledge.50 at osu.edu Wed Feb 8 19:40:14 2006 From: rutledge.50 at osu.edu (linc) Date: Wed, 08 Feb 2006 13:40:14 -0500 Subject: [Pythonmac-SIG] a beginner's list Message-ID: <1139424014.15280.26.camel@localhost.localdomain> > > Full disclosure: I'm a UNIX person. The first thing > I do when I get a > new Mac is make sure X11 is installed on it, and in my > Login Items. > The second thing I do is build an X11 version of GNU > Emacs from the > CVS repository. > Hi, This caught my eye. I have been using a Cocoa-based Emacs for a year or two, and it only has one font, kind of clumsy on my clamshell with the low resolution. Any tips on doing this, or do you know of any binary builds available? A real Emacs with X support would be awesome. Thanks, linc -- ACHTUNG!!! Das machine is nicht fur gefingerpoken und mittengrabben. Ist easy schnappen der springenwerk, blowenfusen und corkenpoppen mit spitzensparken. Ist nicht fur gewerken by das dummkopfen. Das rubbernecken sightseeren keepen hands in das pockets. Relaxen und vatch das blinkenlights!!! From ronaldoussoren at mac.com Wed Feb 8 19:45:53 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 8 Feb 2006 19:45:53 +0100 Subject: [Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff In-Reply-To: <83BA29D9-2158-41AB-A4AE-4E011BCF750F@unsw.edu.au> References: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> <5FDFB8BC-4A33-4EEE-955F-0DEC3BFB3B3B@redivi.com> <83BA29D9-2158-41AB-A4AE-4E011BCF750F@unsw.edu.au> Message-ID: <87CA49C9-140C-4C20-8CA7-7ED81C473E2C@mac.com> On 8-feb-2006, at 13:18, Bill Northcott wrote: > Not happy with the replies I received, I have ground this very small > and think I now understand what is going on. > > Try the following test program: > #define _POSIX_C_SOURCE 200112L > #include > int main () > { > } Is that a valid POSIX program? Don't define _POSIX_C_SOURCE if you use system libraries that are not part of POSIX. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/81e45f1c/attachment.bin From bob at redivi.com Wed Feb 8 20:00:26 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 11:00:26 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> Message-ID: <291A0072-D4EC-4042-AB78-F1C995B22B40@redivi.com> On Feb 8, 2006, at 10:44 AM, Ronald Oussoren wrote: > > On 8-feb-2006, at 10:49, Bob Ippolito wrote: > >> >> Given these caveats and limited resources, the vendor Python is >> absolutely irrelevant as far as I am concerned. If someone wants to >> deal with separate support and documentation for what ships with Mac >> OS X 10.3, Mac OS X 10.4, and Mac OS X 10.5 then have fun, but I am >> NOT interested in that. > > This is a very good reason for not pointing newbies to the system > python > on pythonmac.org: unless anyone steps up to *seriously* support the > system python there won't be properly packages extension packages for > the system python. > > I do support system python for PyObjC, but even there it is mostly > "lets check if it still works" around release time. For day-to-day > work > I'm using a framework installation of Python 2.4. I "support" the system Python 2.3 for what I develop also, with the same rigor that you do. Before doing a release, I'll python2.3 setup.py test (or whatever is appropriate) and if no red flags come up it's out the door. I do not do any real testing with anything but a framework build of Python 2.4 on Mac OS X 10.4. This is probably more harm than help though, because it gives people less reason to use a supported distribution. Perhaps I'll stop bothering with Python 2.3 altogether. -bob From pecora at anvil.nrl.navy.mil Wed Feb 8 20:21:41 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 08 Feb 2006 14:21:41 -0500 Subject: [Pythonmac-SIG] Fwd: New Page, first proposal In-Reply-To: <79459BD5-5BF8-411D-BD68-420759F3CD34@conncoll.edu> References: <79459BD5-5BF8-411D-BD68-420759F3CD34@conncoll.edu> Message-ID: <43EA44C5.60402@anvil.nrl.navy.mil> Charles, First, good start. You've really thought this through and I see the replies are coming fast and hard. Second, Chris Barker ( I called you Baker before, my apologies) had some good replies most of which I agree with. I will add what little I have to his. I think the issue of a standard Python version is important, but I still emphasize not disparaging Apple's, but treating it as a demo/test-drive version. Most people understand the concept of demo programs that they can try out and then full-featured versions that they can graduate to. I would not give that up. It's a nice, easy intro for anyone. That will mean a little tutorial in the beginner's section on how to use the pre-installed 2.3.x version. It's worth it. I would not relegate the C/C++ extensions to another page. Many technical people come from the land of MatLab or Mathematica, etc. and are fully aware of the idea of extending a programming front end using some type of faster compiled functions. Catch their eye on the first page. Then a link to more info. Chris suggested the first page be beginner-oriented (I think he meant that), but I would just say keep the short headers for the advanced stuff and up the visibility of the beginner's page early on (probably in your [1]). And now just a few more suggestions, Charles Hartman wrote: > > > Begin forwarded message: > >> *From: *Charles Hartman > > >> >> For a page title that covers the ground broadly and accurately, I propose >> Python on the Mac >> Problems with that? Better suggestions? A subtitle ? What you need to use Python on Mac OS X. (that addresses Chris' OS X or Classic question) >> >> Four stages in the project are foreseeable: >> 1. Establish the basic organization of the page >> 2. Collect the essential technical data, and probably also less >> essential materials >> to be relegated to secondary pages >> 3. Produce some friendly prose >> 4. Build the html for the page >> >> #4 is fun, and I wouldn't mind doing it in DreamWeaver if nobody else >> has better tools and skills. #3 is easy enough, though checking it >> for accuracy needs to be a community effort. I am not competent to do >> #2, but this list is full of people who are. Glad you can do #4, because I don't have a clue (I guess you can do Wiki since Chris keeps saying it -- that would be nice). #3 I can help with for beginners (because I'm not that far from one). >> >> ===== the Python-on-the-Mac page ======================= >> >> [1] "If you're a Mac user who wants to learn to write Python programs": >> note Apple distro, be politely disparaging toward it, provide links to Here's where you put a prominent link to a BEGINNER'S PAGE. and maybe mentioning here Apple's distro as a test drive (don't be disparaging, just emphasize how much better the advanced version is). >> Bob's framework, with notes (how extensive is this?) on other stuff >> required >> ActiveState's framework, with similar notes >> provide links to >> how-to-program sites >> how-to-program-in-Python sites >> how-to-program-for-the-Mac sites >> >> SWIG, pyrex, --- I'm sure others will suggest many more. Let me read more replies to catch up. More later. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From delza at livingcode.org Wed Feb 8 20:26:16 2006 From: delza at livingcode.org (Dethe Elza) Date: Wed, 8 Feb 2006 11:26:16 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: Message-ID: On 8-Feb-06, at 10:35 AM, Chris Porter wrote: > How does a build differ from a system? I think build refers to a version of Python, and system refers to a version of OS X. > I tried typing in python, and got the same response as typing in > pythonw. > Then I tried "pythonx" "pythona" and "pythong", all of which got me > something like this: pythonw is a special invocation of python that allows you to talk to the window manager (the "w" is for "windows"). Regular python at the command-line isn't allowed to open windows due to some weirdness with how Apple created the window manager. > -bash: pythona: command not found > > Be nice to know why only some letters after 'python' are allowed. Adding random letters to the end of commands doesn't work. >>> 4) To do this in a window, enter the following lines at the ">>>" >>> prompt: > > > What? What window? Any window? Is window some particular > application? This refers to putting "Hello World" in a window (actually a blank window with "Hello World" in the title bar. The window is the one you create with the following lines. >>>>>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1, >>>>>> "Hello World").Show(1) app.MainLoop() > > > Tried this in a Terminal (window), this is what I got: > >>>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, >>>> -1,"Hello World").Show(1) app.MainLoop() The newlines or semicolons must have gotten obliterated. Either of these work for me: import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1, "Hello World").Show(1) app.MainLoop() # or import wx; app=wx.PySimpleApp(); frame = wx.Frame(None, -1, "Hello World").Show(1); app.MainLoop() > "For users of this page, we are going to assume you know: > That python is a programming language. > That window means... > That you are generally familiar with the Terminal app > That you know how to construct a program and save it to disk, and > run it. > That ...." Hmmm. If they don't know that Python is a programming language, why are they here? Familiarity with the terminal app and knowing how to save python as a text file are certainly prerequisites at this point though. --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 From hengist.podd at virgin.net Wed Feb 8 20:28:56 2006 From: hengist.podd at virgin.net (has) Date: Wed, 8 Feb 2006 19:28:56 +0000 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb8.090401pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.090401pst."58633"@synergy1.parc.xerox.com> Message-ID: Bill Janssen wrote: >I can see that if you are a pre-MacOSX Mac person, used to all the >groundbreaking UI complexity of Apple in the 80's and 90's, your view >and your needs might be different. Or if you are a for-Mac developer. >But most people aren't. A *very* good point. Us longtime Mac-heads are thinking of the issue as "How do we market MACpython?" But we also need to appeal to folk who use PYTHON, and who just happen to be on a Mac at the time. Sure, these folks could just as easily go to www.python.org for (almost?) all the info they need, but being on a Mac they're naturally going to approach the native community first. I guess that makes three different market segments to consider then: - casual scripters - professional Mac-oriented developers - professional Unix developers who want to use Python on OS X just the same as they'd use Python on any other *nix has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed Feb 8 20:36:35 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 11:36:35 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: Message-ID: On Feb 8, 2006, at 10:35 AM, Chris Porter wrote: > (snip) >> >> Then we need Pointers to download pages for packages: >> >> One page for the 10.3 build. > > How does a build differ from a system? > >> One page for the 10.4 build. This has been talked about a lot recently. The way it's built determines what range of systems it's compatible with. For example, the in-progress 2.4.2 universal build is compatible with Mac OS X 10.3.9 and later, and builds extensions compatible with both i386 and PPC architectures. The only problem with this build is that Mac OS X 10.3.9 users can't use it to build extensions at all (out of the box, anyway). >>> For me, the list would be (1) get Bob's framework (2) pick and >>> install an IDE >> >> Given the state of IDEs and their installers, don't start there. >> Start >> with a the terminal and a text editor. Perhaps one of the text editors that has a "run in Python" button would be a good middle-ground, with lots of screenshots or a screencast. >>> Somebody who comes idly to the idea of programming in Python, and >>> finds the pythonmac page, will be happy if the result is an >>> afternoon's work that ends in a "hello world," possibly in a window. >>> Using my own arbitrary preferences, that would entail: >>> >>> 1. downloading & installing Bob's framework 2. downloading & >>> installing TigerPython24Fix 3. adding /usr/local/bin to the PATH >> >> We really should build an installer that does the three of these >> at once >> (with the PATH editing optional). I have no idea how to do that, >> though. Well, TigerPython24Fix is only relevant to that *particular* build. If we do a 2.4.2 build then it only has to do 1. and 3. >>> 5. downloading & installing [fill in name of IDE] >> >> Until there is one robust enough to really recommend, we're not there >> yet. How's SPE doing on the mac these days? Also, different IDEs are >> different, they each need their own tutorial, ideally one Mac- >> centered, >> but that's no our job. >> >> I do think a little "getting started" tutorial with a editor and the >> command line is a good idea, however. enough that they can read >> one of >> the intro books and know what to do. wx based applications like SPE will probably give Mac users a bad first impression.. they don't look or act very natively. >> Bill Janssen wrote: >> >>> Who wants to open windows? Why is a GUI automatically necessary? >> >> I agree, it's not. And if your goal is web programming, it never >> will be. That's an excellent point. Leading into a getting started with TurboGears or Django tutorial would be beneficial to that crowd. >> , in three minutes: >>> 1) Click on Applications/Utilities/Terminal. >>> >>> 2) In the terminal window, enter the following line: >>> >>> % pythonw > > > I tried typing in python, and got the same response as typing in > pythonw. > Then I tried "pythonx" "pythona" and "pythong", all of which got me > something like this: > > -bash: pythona: command not found > > Be nice to know why only some letters after 'python' are allowed. http://www.google.com/search?q=pythonw There is python and pythonw -- that's it. At least until you install third party scripts that have "python" in their name like ipython. >>>>>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1, >>>>>> "Hello World").Show(1) app.MainLoop() > > > Tried this in a Terminal (window), this is what I got: > >>>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, >>>> -1,"Hello World").Show(1) app.MainLoop() > File "", line 1 > import wx app = wx.PySimpleApp() frame = wx.Frame(None, > -1,"Hello World").Show(1) app.MainLoop() > ^ > SyntaxError: invalid syntax That's because all of the newlines are missing for whatever reason. It should be import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1, "Hello World").Show(1) app.MainLoop() -bob From charles.hartman at conncoll.edu Wed Feb 8 20:38:19 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 14:38:19 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: Message-ID: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> On Feb 8, 2006, at 2:26 PM, Dethe Elza wrote: > Hmmm. If they don't know that Python is a programming language, why > are they here? Familiarity with the terminal app and knowing how to > save python as a text file are certainly prerequisites at this point > though. I agree with the first point -- we're not looking *that* broadly for a Python audience. But my main motive for working on this question is the hope that the second point will *not* be true. One characteristic of the Mac-user- just-coming-to-Python audience that I'm aiming to help, or entice, or at least not alienate, is unfamiliarity at the Terminal that may inclulde distaste and border on panic. Terminal is Unix. OS X is not, in a sense. Some people have come to Mac now that its OS is "really" Unix. A much larger number -- including, I believe, a fair number of potential Python programmers -- come to OS X from OS 9 or System 7 or 8 or Apple ][. I just don't believe it should be necessary for those people, at first, to take on even the beginnings of Unix in order to brave taking on Python. (We can sucker 'em in to the delights of the command line later on.) Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/843f3586/attachment.htm From bob at redivi.com Wed Feb 8 20:40:02 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 11:40:02 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb8.090846pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.090846pst."58633"@synergy1.parc.xerox.com> Message-ID: <9B659B38-C368-408B-BB67-B77F176D6B62@redivi.com> On Feb 8, 2006, at 9:08 AM, Bill Janssen wrote: >>> In addition, if you have your code running just fine and dandy under >>> Apple's python, then you upgrade to 10.5, chances are that your >>> app will >>> no longer work, as Apple is likely to yank their python out from >>> under >>> you. If it were running with a user-installed Python, chances are it >>> would keep working. >> >> That's something the page should shout to the world about! >> (because I had no idea about this) >> >> "The advantages of not using Apple's versions!" > > You had no idea about it because it's not going to happen. "Apple is > likely to yank their python out from under you"? Come on, this is > absurd. In 10.5, /usr/bin/python is likely to be Python 2.4 instead > of 2.3, but the odds are 9999 to 1 that it will be there, and the > Python community has taken great pains to make sure 2.4 is > backwards-compatible with 2.3. Yes, you will still be able to run simple scripts that depend on only the standard library and whatever third party stuff Apple consistently ships with Mac OS X. The majority of people use at least some extensions, and any application bundles built with bundlebuilder or py2app are surely toast (unless they depend only on what ships). -bob From ronaldoussoren at mac.com Wed Feb 8 20:59:56 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 8 Feb 2006 20:59:56 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> Message-ID: <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> On 7-feb-2006, at 0:59, Bob Ippolito wrote: >> >> Bob, what do you think the timescale is for a universal build? If >> it's >> soon, then we should work on re-0writing the web site as though it's >> ready to go. > > I'd say soon... The only issues left are to sort out the distribution > scripts and some more testing I guess. Having a working build environment would also be nice. 'make frameworkinstall' fails if builddir != srcdir. I'm working on this right now. BTW. The distribution script is mostly done but I stopped because I got annoyed by the aformentioned build problems. Hopefully I can finish it this week. BTW2. Does anyone know why the python is linked using c++? Would that cause problems if you build python itself using gcc 4 on Tiger and then use g++ 3.3 to build extensions on 10.3 (say because you want to build wxPython)? Ronald > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/e5bd360c/attachment.bin From bob at redivi.com Wed Feb 8 21:21:49 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 12:21:49 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> Message-ID: <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> On Feb 8, 2006, at 11:59 AM, Ronald Oussoren wrote: > > On 7-feb-2006, at 0:59, Bob Ippolito wrote: >>> >>> Bob, what do you think the timescale is for a universal build? If >>> it's >>> soon, then we should work on re-0writing the web site as though it's >>> ready to go. >> >> I'd say soon... The only issues left are to sort out the distribution >> scripts and some more testing I guess. > > Having a working build environment would also be nice. 'make > frameworkinstall' > fails if builddir != srcdir. I'm working on this right now. It worked for me.. I never build in srcdir. What's the problem? > BTW. The distribution script is mostly done but I stopped because > I got annoyed by the aformentioned build problems. Hopefully I can > finish it > this week. > > BTW2. Does anyone know why the python is linked using c++? Would > that cause > problems if you build python itself using gcc 4 on Tiger and then > use g++ 3.3 > to build extensions on 10.3 (say because you want to build wxPython)? http://mail.python.org/pipermail/python-dev/2003-July/036775.html """ This change was needed to support various C++ compilers that would fail to link Modules/ccpython.cc with the C compiler. """ The question then becomes, why does the main program need to be compiled with C++? -bob From ronaldoussoren at mac.com Wed Feb 8 21:42:45 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 8 Feb 2006 21:42:45 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> Message-ID: On 8-feb-2006, at 21:21, Bob Ippolito wrote: > > On Feb 8, 2006, at 11:59 AM, Ronald Oussoren wrote: > >> >> On 7-feb-2006, at 0:59, Bob Ippolito wrote: >>>> >>>> Bob, what do you think the timescale is for a universal build? >>>> If it's >>>> soon, then we should work on re-0writing the web site as though >>>> it's >>>> ready to go. >>> >>> I'd say soon... The only issues left are to sort out the >>> distribution >>> scripts and some more testing I guess. >> >> Having a working build environment would also be nice. 'make >> frameworkinstall' >> fails if builddir != srcdir. I'm working on this right now. > > It worked for me.. I never build in srcdir. What's the problem? $make frameworkinstall ... gcc -arch ppc -arch i386 -isysroot / -fno-strict-aliasing -Wno-long- double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG - g -O3 -Wall -Wstrict-prototypes -I. -I../Include -c -o Mac/OSX/ PythonLauncher/main.o ../Mac/OSX/PythonLauncher/main.m lipo: can't create output file: Mac/OSX/PythonLauncher/main.o (No such file or directory) svn diff says that everything is fine. Maybe it's because I'm building a DTK system and I haven't bothered upgrading it because I'm running headless and didn't have a screen lying around when update came in. Anyway, don't like your solution for building PythonLauncher. I've replaced it by a Makefile.in in Mac/OSX/PythonLauncher, that way all logic for building PythonLauncher is nicely located in the Mac/OSX/PythonLauncher directory. I might rewrite Mac/OSX/Makefile as well now that I'm working on this. > >> BTW. The distribution script is mostly done but I stopped because >> I got annoyed by the aformentioned build problems. Hopefully I can >> finish it >> this week. >> >> BTW2. Does anyone know why the python is linked using c++? Would >> that cause >> problems if you build python itself using gcc 4 on Tiger and then >> use g++ 3.3 >> to build extensions on 10.3 (say because you want to build wxPython)? > > http://mail.python.org/pipermail/python-dev/2003-July/036775.html > > """ > This change was needed to support various C++ compilers that would > fail to link Modules/ccpython.cc with the C compiler. > """ > > The question then becomes, why does the main program need to be > compiled with C++? That's the same as my question (although I did phrase it very awkwardly, use s/the python is/the python executable is/ to fix that). Maybe it is necessary to ensure proper behaviour for C++ extensions with global variables that have constructors, in which case we'd probably be hosed. Does anyone has a Python extension that does this lying around (compiled using g+ +-3 on Panther)? The 10.3 system I'm testing the universal build on doesn't have a compiler installed, the only other system with 10.3 is my main machine. I'll have to install various flavours of 10.3 on an external disk one of these days ;-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/da596c95/attachment-0001.bin From bob at redivi.com Wed Feb 8 21:56:54 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 12:56:54 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> Message-ID: <9BA605DB-91BC-4126-A1B9-5D5B973391B2@redivi.com> On Feb 8, 2006, at 12:42 PM, Ronald Oussoren wrote: > > On 8-feb-2006, at 21:21, Bob Ippolito wrote: > >> >> On Feb 8, 2006, at 11:59 AM, Ronald Oussoren wrote: >> >>> >>> On 7-feb-2006, at 0:59, Bob Ippolito wrote: >>>>> >>>>> Bob, what do you think the timescale is for a universal build? >>>>> If it's >>>>> soon, then we should work on re-0writing the web site as though >>>>> it's >>>>> ready to go. >>>> >>>> I'd say soon... The only issues left are to sort out the >>>> distribution >>>> scripts and some more testing I guess. >>> >>> Having a working build environment would also be nice. 'make >>> frameworkinstall' >>> fails if builddir != srcdir. I'm working on this right now. >> >> It worked for me.. I never build in srcdir. What's the problem? > > $make frameworkinstall > ... > gcc -arch ppc -arch i386 -isysroot / -fno-strict-aliasing -Wno- > long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - > DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Include -c -o > Mac/OSX/PythonLauncher/main.o ../Mac/OSX/PythonLauncher/main.m > lipo: can't create output file: Mac/OSX/PythonLauncher/main.o (No > such file or directory) > > > svn diff says that everything is fine. Maybe it's because I'm > building a DTK system and I haven't bothered upgrading it because > I'm running headless and didn't have a screen lying around when > update came in. Doesn't your Makefile.pre.in have this? Mac/OSX/PythonLauncher: mkdir -p $@ PythonLauncher: $(LIBRARY) Mac/OSX/PythonLauncher $(PYTHONLAUNCHER_OBJS) > Anyway, don't like your solution for building PythonLauncher. I've > replaced it by a Makefile.in in Mac/OSX/PythonLauncher, that way > all logic for building > PythonLauncher is nicely located in the Mac/OSX/PythonLauncher > directory. I might rewrite Mac/OSX/Makefile as well now that I'm > working on this. I don't like it much either. Please go for it. >>> BTW. The distribution script is mostly done but I stopped because >>> I got annoyed by the aformentioned build problems. Hopefully I >>> can finish it >>> this week. >>> >>> BTW2. Does anyone know why the python is linked using c++? Would >>> that cause >>> problems if you build python itself using gcc 4 on Tiger and then >>> use g++ 3.3 >>> to build extensions on 10.3 (say because you want to build >>> wxPython)? >> >> http://mail.python.org/pipermail/python-dev/2003-July/036775.html >> >> """ >> This change was needed to support various C++ compilers that would >> fail to link Modules/ccpython.cc with the C compiler. >> """ >> >> The question then becomes, why does the main program need to be >> compiled with C++? > > That's the same as my question (although I did phrase it very > awkwardly, use > s/the python is/the python executable is/ to fix that). > > Maybe it is necessary to ensure proper behaviour for C++ extensions > with global > variables that have constructors, in which case we'd probably be > hosed. Does anyone > has a Python extension that does this lying around (compiled using g > ++-3 on Panther)? > > The 10.3 system I'm testing the universal build on doesn't have a > compiler installed, > the only other system with 10.3 is my main machine. I'll have to > install various flavours > of 10.3 on an external disk one of these days ;-) gcc might not be one of those compilers that requires the executable to be linked with C++. I can't imagine it would have that restriction, given the amount of frameworks that Apple develops in C+ + or Objective-C++ and the fact that almost all Cocoa executables are linked with just gcc... -bob From ronaldoussoren at mac.com Wed Feb 8 22:16:18 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 8 Feb 2006 22:16:18 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> Message-ID: <7692CE6C-D0DD-4277-85B5-A82EE07B1375@mac.com> On 8-feb-2006, at 21:53, Bill Noon wrote: > > On Feb 8, 2006, at 3:42 PM, Ronald Oussoren wrote: > >> Maybe it is necessary to ensure proper behaviour for C++ >> extensions with global >> variables that have constructors, in which case we'd probably be >> hosed. Does anyone >> has a Python extension that does this lying around (compiled using >> g++-3 on Panther)? >> > > OmniOrb is one of these. Prior to 10.4, it had to be linked to > static libraries to get all the c++ constructors to fire properly. > > My latest builds with 10.4 and python 2.4 work fine. Is that this omniorb: http://omniorb.sourceforge.net/ ? Do you by any change have a binary of the python extension for Panther lying about? (for python 2.4 of course). A script that would tell if the c++ constructors would also be nice :-) Ronald > > --Bill Noon > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/2267ec36/attachment.bin From noon at snow.nrcc.cornell.edu Wed Feb 8 21:53:51 2006 From: noon at snow.nrcc.cornell.edu (Bill Noon) Date: Wed, 8 Feb 2006 15:53:51 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> Message-ID: On Feb 8, 2006, at 3:42 PM, Ronald Oussoren wrote: > Maybe it is necessary to ensure proper behaviour for C++ extensions > with global > variables that have constructors, in which case we'd probably be > hosed. Does anyone > has a Python extension that does this lying around (compiled using g > ++-3 on Panther)? > OmniOrb is one of these. Prior to 10.4, it had to be linked to static libraries to get all the c++ constructors to fire properly. My latest builds with 10.4 and python 2.4 work fine. --Bill Noon From kevino at theolliviers.com Wed Feb 8 22:20:44 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 8 Feb 2006 13:20:44 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> Message-ID: <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> Hi Bob, On Feb 8, 2006, at 1:49 AM, Bob Ippolito wrote: > > On Feb 8, 2006, at 1:06 AM, Kevin Ollivier wrote: > >>> In addition, if you have your code running just fine and dandy under >>> Apple's python, then you upgrade to 10.5, chances are that your app >>> will >>> no longer work, as Apple is likely to yank their python out from >>> under >>> you. >> >> What do you mean by this? None of my Panther scripts stopped working >> under Tiger (I do have a couple ;-), and I didn't even touch Python >> 2.4 on Mac until around October, where they still worked as they >> always did on 2.3. Why should I now assume 10.5 is going to break all >> my apps? > > Unless you're a unix person, there's very few useful things you can > do with Python 2.3 sans third party extensions (especially on > Panther, where wx and tkinter were not shipped). All of those > extensions, or at least a .pth hack if you just did an upgrade, > need to be installed to keep that working. Applications built with > py2app or bundlebuilder are even worse off. > > Mac OS X 10.5 will surely ship with at least 2.4.2, which means all > extensions built against any previous vendor Python will break, > period. Additionally, all of the WASTE-based stuff (the shipping > Python IDE, the worthless PackageManager, etc.) is incompatible > with i386. Only the most basic mostly platform independent scripts > are going to work with Mac OS X 10.5. It's a bit confusing to talk as if needing new extensions == breakage. (You know you're a geek when it's second nature to write equality tests like this. ;-) I remember Python 2.1 and I've had to upgrade several times, and I never thought of re-installing my extensions as 'fixing what broke'. I called it 'upgrading'. Some people may see initially see what appears to be broken scripts, but unfortunately that would just be because they aren't aware of issues that may occur when upgrading their Python install. I don't think the proper solution is to keep them from upgrading; we just need to build awareness that a new Python major version means new extensions. > If a third party Python is used, it will work forever... or at > least as long as Apple maintains basic API compatibility with the > version of the OS it was built with (whether through emulation or > otherwise). > > I have Python applications built on Mac OS X 10.2 that work on i386 > Mac OS X 10.4 because they used a third party Python. If those > applications had depended on /usr/bin/python and extensions linked > against it, then it would be toast -- especially because > bundlebuilder doesn't have a PPC bootstrap. bundlebuilder-built > applications (assuming semi-standalone), without Info.plist > changes, will launch with an i386 Python and almost definitely > won't work at all unless they don't include any extensions at all. > > If we do strongly recommend that only third party builds of Python > are used, then we don't have to say "I told you so" to as many > people when their apps break a year or two later. The package > database and the documentation also become shorter and more > maintainable if only recent third party builds are supported. > There will be much less confusion if there's one-- and preferably > only one --obvious way to use Python on Mac OS X. Given these > caveats and limited resources, the vendor Python is absolutely > irrelevant as far as I am concerned. Right, but I knew this before you wrote your message, because I've long known your position on support and maintenance. And I've never said anything against it. When I say "some people can use 2.3", I'm not advocating officially supporting 2.3 on this list. When people say "let them start out with Apple's Python" they don't mean that deployers and active Python users should dump 2.4, etc. What we're talking about is small and simple steps to get newbies started. The existing Python community obviously doesn't need this kind of guidance - they need a whole different support mechanism, which I think you, along with Jack and others, have already gone great lengths to provide. That being said, I think you'd be surprised how even new users could survive with "any" Python if they had a clear understanding of 1) how to get started and 2) how to build extension modules from 'source'. This talk of building supported Pythons, and supported extensions, is nice, but the reality is that there's only so much volunteers can do. I think we're better off teaching users how to handle the common issues that they may come across, like dealing with a package with no binary/installer for their Python. Teaching a Python to fish rather than giving them fish, or something like that. :-) As for deployment, well, just write a few sentences about what you should do to properly deploy an app and why, and link to some sample py2app scripts, etc. Done. > If someone wants to deal with separate support and documentation > for what ships with Mac OS X 10.3, Mac OS X 10.4, and Mac OS X 10.5 > then have fun, but I am NOT interested in that. No one (that I'm aware of) is saying that. A "30-second getting started" tutorial doesn't mean producing an entire support infrastructure around the various "Apple Pythons" (or a support infrastructure for any particular version, really). It's just "here, Python is included on OS X, here's how to give it a spin, and here's some links to learn more about what Python can do". That's all. (At least in my idea, and I think Bill J.'s as well.) If you look at the new beginner's page that's being talked about (as far as I've read the messages, anyways), it starts (as did Jack's MacPython page) with notes about what your options are. Beginners don't want options; they want to be told what to do. They also prefer 0 minutes setup time to 5 minutes setup time. Seeing a bunch of paragraphs (even before they read them) says to the user - uh, oh, this is going to be complicated.... That's what makes Bill Janssen's tutorial great. They read "30-second getting started tutorial", which sounds pretty appealing, then they click on it, and in one minute, they've *seen* how Python works, rather than spending that minute reading about whether they should use Apple's Python, not use Apple's Python, and what about extensions and deploying, etc. Then, after that one minute doing hello world, they can follow the Python and wx tutorials (we can point them to the wx demo too) to learn all sorts of other neat stuff they can do with it. Then, once we've got them thinking "this is great, I want this!" then maybe they'll be a little more interested in reading about whether or not they should upgrade to 2.4. We can have all the information for existing Python users trying to sort out their options, deal with upgrade issues, deploy apps, etc., but let's have a clearer starting path for beginners too. Thanks, Kevin > -bob > From bob at redivi.com Wed Feb 8 22:31:08 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 13:31:08 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <685A7AAB-2CD0-4C5B-A711-0F37ED442C2B@mac.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> <685A7AAB-2CD0-4C5B-A711-0F37ED442C2B@mac.com> Message-ID: On Feb 8, 2006, at 1:08 PM, Ronald Oussoren wrote: > > On 8-feb-2006, at 21:42, Ronald Oussoren wrote: > >> >> On 8-feb-2006, at 21:21, Bob Ippolito wrote: >> >>> >>> On Feb 8, 2006, at 11:59 AM, Ronald Oussoren wrote: >>> >>>> >>>> On 7-feb-2006, at 0:59, Bob Ippolito wrote: >>>>>> >>>>>> Bob, what do you think the timescale is for a universal build? >>>>>> If it's >>>>>> soon, then we should work on re-0writing the web site as >>>>>> though it's >>>>>> ready to go. >>>>> >>>>> I'd say soon... The only issues left are to sort out the >>>>> distribution >>>>> scripts and some more testing I guess. >>>> >>>> Having a working build environment would also be nice. 'make >>>> frameworkinstall' >>>> fails if builddir != srcdir. I'm working on this right now. >>> >>> It worked for me.. I never build in srcdir. What's the problem? >> >> $make frameworkinstall >> ... >> gcc -arch ppc -arch i386 -isysroot / -fno-strict-aliasing -Wno- >> long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - >> DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Include -c -o >> Mac/OSX/PythonLauncher/main.o ../Mac/OSX/PythonLauncher/main.m >> lipo: can't create output file: Mac/OSX/PythonLauncher/main.o (No >> such file or directory) >> >> >> svn diff says that everything is fine. Maybe it's because I'm >> building a DTK system and I haven't bothered upgrading it because >> I'm running headless and didn't have a screen lying around when >> update came in. >> >> Anyway, don't like your solution for building PythonLauncher. I've >> replaced it by a Makefile.in in Mac/OSX/PythonLauncher, that way >> all logic for building >> PythonLauncher is nicely located in the Mac/OSX/PythonLauncher >> directory. I might rewrite Mac/OSX/Makefile as well now that I'm >> working on this. > > The attached patch: > - Uses MACOSX_DEPLOYMENT_TARGET instead of > CONFIGURE_MACOSX_DEPLOYMENT_TARGET in the toplevel Makefile and > distutils > - Uses 'export MACOSX_DEPLOYMENT_TARGET' to get the value into the > environment from the Makefile, including some configure trickery > that will only enable this line on OSX > - Moves Mac/OSX/Makefile to Mac/OSX/Makefile.in and inserts some > values using configure > - Create Mac/OSX/PythonLauncher/Makefile.in and use that to build > and install PythonLauncher.app, you should move the resource files > from the application template to Mac/OSX/PythonLauncher after > applying the patch. Sounds good, I'll merge this as soon as I have a little time... probably in a few hours. > BTW. I patched configure by hand. > BTW2. This just ensures make frameworkinstall works, I haven't > tested the output yet. > BTW3. What is the plan w.r.t. merging our patches back into the > python repository? I'd like to get all of this into Python 2.5 at > the very least. My plan is to make everything work first, and then worry about upstream. I don't have time to go through that process and this one in parallel. -bob From bob at redivi.com Wed Feb 8 22:34:54 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 13:34:54 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> Message-ID: <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> On Feb 8, 2006, at 1:20 PM, Kevin Ollivier wrote: > Hi Bob, > > On Feb 8, 2006, at 1:49 AM, Bob Ippolito wrote: > >> >> On Feb 8, 2006, at 1:06 AM, Kevin Ollivier wrote: >> >>>> In addition, if you have your code running just fine and dandy >>>> under >>>> Apple's python, then you upgrade to 10.5, chances are that your app >>>> will >>>> no longer work, as Apple is likely to yank their python out from >>>> under >>>> you. >>> >>> What do you mean by this? None of my Panther scripts stopped working >>> under Tiger (I do have a couple ;-), and I didn't even touch Python >>> 2.4 on Mac until around October, where they still worked as they >>> always did on 2.3. Why should I now assume 10.5 is going to break >>> all >>> my apps? >> >> Unless you're a unix person, there's very few useful things you can >> do with Python 2.3 sans third party extensions (especially on >> Panther, where wx and tkinter were not shipped). All of those >> extensions, or at least a .pth hack if you just did an upgrade, >> need to be installed to keep that working. Applications built with >> py2app or bundlebuilder are even worse off. >> >> Mac OS X 10.5 will surely ship with at least 2.4.2, which means all >> extensions built against any previous vendor Python will break, >> period. Additionally, all of the WASTE-based stuff (the shipping >> Python IDE, the worthless PackageManager, etc.) is incompatible >> with i386. Only the most basic mostly platform independent scripts >> are going to work with Mac OS X 10.5. > > It's a bit confusing to talk as if needing new extensions == > breakage. (You know you're a geek when it's second nature to write > equality tests like this. ;-) I remember Python 2.1 and I've had to > upgrade several times, and I never thought of re-installing my > extensions as 'fixing what broke'. I called it 'upgrading'. Some > people may see initially see what appears to be broken scripts, but > unfortunately that would just be because they aren't aware of issues > that may occur when upgrading their Python install. I don't think the > proper solution is to keep them from upgrading; we just need to build > awareness that a new Python major version means new extensions. We're talking about upgrading Mac OS X, which implicitly upgrades Python and obsoletes all of your extensions. I'd call that breaking. -bob From Chris.Barker at noaa.gov Wed Feb 8 22:39:08 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 13:39:08 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> Message-ID: <43EA64FC.50907@noaa.gov> Charles Hartman wrote: > I just don't believe it should > be necessary for those people, at first, to take on even the beginnings > of Unix in order to brave taking on Python. How are they going to do it? Is there a single free IDE that you think is ready for this kind of user (including the install)? I don't know of one. Without an IDE, you have the terminal (which is an IDE, as a matter of fact, but not a GUI one!) You're right that it shouldn't be necessary, but I think it still is. The lowest common denominator at this point needs to be a willingness to learn a bit about using the terminal and an editor. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From noon at snow.nrcc.cornell.edu Wed Feb 8 22:45:25 2006 From: noon at snow.nrcc.cornell.edu (Bill Noon) Date: Wed, 8 Feb 2006 16:45:25 -0500 Subject: [Pythonmac-SIG] install again? In-Reply-To: <7692CE6C-D0DD-4277-85B5-A82EE07B1375@mac.com> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> <7692CE6C-D0DD-4277-85B5-A82EE07B1375@mac.com> Message-ID: On Feb 8, 2006, at 4:16 PM, Ronald Oussoren wrote: > > Is that this omniorb: http://omniorb.sourceforge.net/ ? Yep. > > Do you by any change have a binary of the python extension for > Panther lying about? (for python 2.4 of course). A script that would > tell if the c++ constructors would also be nice :-) OmniOrb is not a good, simple test case. It creates about a half a dozen libraries and several python modules. Building on MacOSX isn't very clean. The only version I have for Panther was built against python 2.3 (and static libraries). If you have a version of python2.4 for Panther you want me to test, we can try it that way. > > Ronald > >> >> --Bill Noon >> > --Bill From Chris.Barker at noaa.gov Wed Feb 8 23:00:38 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 14:00:38 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <06Feb8.090401pst.58633@synergy1.parc.xerox.com> Message-ID: <43EA6A06.8050001@noaa.gov> has wrote: > - professional Unix developers who want to use Python on OS X just > the same as they'd use Python on any other *nix If this means non-GUI apps, then they don't need any help from us, except maybe one line about how python acts exactly the same from the command line on OS-X as it does on any other *nix. The MacPython page should focus on what is different or special about using python on OS-X -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From david.warde.farley at utoronto.ca Wed Feb 8 23:07:57 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Wed, 8 Feb 2006 17:07:57 -0500 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <43EA6A06.8050001@noaa.gov> References: <06Feb8.090401pst.58633@synergy1.parc.xerox.com> <43EA6A06.8050001@noaa.gov> Message-ID: <0B1BEA46-9C1E-4C99-A954-D2BA98215512@utoronto.ca> On 8-Feb-06, at 5:00 PM, Christopher Barker wrote: > has wrote: >> - professional Unix developers who want to use Python on OS X just >> the same as they'd use Python on any other *nix > > If this means non-GUI apps, then they don't need any help from us, > except maybe one line about how python acts exactly the same from the > command line on OS-X as it does on any other *nix. The exception would be any of the POSIX stuff that behaves different on OS X, albeit subtley. I'm sure there are such things but I can't think of any right now. - David From kevino at theolliviers.com Wed Feb 8 23:11:29 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 8 Feb 2006 14:11:29 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> Message-ID: <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> On Feb 8, 2006, at 1:34 PM, Bob Ippolito wrote: [snip] >> >> It's a bit confusing to talk as if needing new extensions == >> breakage. (You know you're a geek when it's second nature to write >> equality tests like this. ;-) I remember Python 2.1 and I've had to >> upgrade several times, and I never thought of re-installing my >> extensions as 'fixing what broke'. I called it 'upgrading'. Some >> people may see initially see what appears to be broken scripts, but >> unfortunately that would just be because they aren't aware of issues >> that may occur when upgrading their Python install. I don't think the >> proper solution is to keep them from upgrading; we just need to build >> awareness that a new Python major version means new extensions. > > We're talking about upgrading Mac OS X, which implicitly upgrades > Python and obsoletes all of your extensions. I'd call that breaking. As does just explicitly upgrading your Python. I don't see why it's breaking if you install Leopard, but upgrading if you install MacPython 2.4 from pythonmac.org. Either way, your 2.3 extensions don't work and you have to start from scratch. And either way, if you thought things would "just work" you're in for a rude awakening. So what's the difference? Kevin > -bob > From dtaylor at ski.org Wed Feb 8 23:23:01 2006 From: dtaylor at ski.org (Douglas Taylor) Date: Wed, 08 Feb 2006 14:23:01 -0800 Subject: [Pythonmac-SIG] [Fwd: [visionegg] 2 problems setting up 2 screen window (OSX 10.3.9)] Message-ID: <43EA6F45.4@ski.org> Hi All, I'm forwarding this message I sent to the VisionEgg list as they couldn't help me there. Basically there are 2 problems. 1) I can't hide the toolbar when not in FULLSCREEN. From the post below it seems it used to work. 2) If I try and cover both monitors with the window the screens whithens out and I can see no rendering when I ask for a 2048x768 window. If I go down to 2046x768 it works fine but there are 2 lines of the background screen visible. I am using pygame 1.7.0 Thanks for any help. Doug Taylor -------- Original Message -------- Subject: [visionegg] 2 problems setting up 2 screen window (OSX 10.3.9) Date: Wed, 08 Feb 2006 12:07:34 -0800 From: Douglas Taylor Reply-To: visionegg at freelists.org To: visionegg at freelists.org Hi Andrew and All, I'm trying to get a 2 screen setup going to demo some stereo stimuli. The following works as advertised import os os.environ['SDL_VIDEO_WINDOW_POS']="0,0" Trying to get rid of the toolbar does not. I followed the example from Andrew's post > import pygame.macosx > pygame.macosx.app.mainMenu().setMenuBarVisible_(False) http://mail.python.org/pipermail/pythonmac-sig/2003-August/008482.html The error I get pygame.macosx.app.mainMenu().setMenuBarVisible_(False) AttributeError: 'module' object has no attribute 'app' My pygame is pygame version 1.7.0 (OK) Do I need a newer version of pygame? I have 2 monitors both at 1024x768 resolution. When I request a window 2048x768 the window is whited out and no rendering can be seen. The max. screen size I could ask for is 2046x768 to see my stim. Any ideas what going on here? Thanks for any help. Doug ====================================== The Vision Egg mailing list Archives: http://www.freelists.org/archives/visionegg Website: http://www.visionegg.org/mailinglist.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/9323b55b/attachment.htm From Chris.Barker at noaa.gov Wed Feb 8 23:42:11 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 14:42:11 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> Message-ID: <43EA73C3.6020708@noaa.gov> Kevin Ollivier wrote: > As does just explicitly upgrading your Python. I don't see why it's > breaking if you install Leopard, but upgrading if you install MacPython > 2.4 from pythonmac.org. Either way, your 2.3 extensions don't work and > you have to start from scratch. And either way, if you thought things > would "just work" you're in for a rude awakening. > > So what's the difference? The difference is that when you upgrade OS-X to leopard, you may or may not know that you are upgrading Python, and if you did know, you may not want to. I started this with a reference to a particular poster, that had installed some sort of Python app (I'm guessing a web app), and he got it work by installing the needed extensions. When (If) he upgrades OS-X, that app will break. Almost every other app he has installed on his system will continue to work, but the python based one will not. This would apply to any app using the built in python and any extensions: simple scripts, py2app bundles, etc. If those were using a user installed python build, they would continue to work when the OS was upgraded. It's kind of like having apps linked against certain versions of shared libs, except that I think Apple makes a point of keeping old versions of their system libs around when the put out new ones. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From charles.hartman at conncoll.edu Wed Feb 8 23:42:26 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 17:42:26 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EA64FC.50907@noaa.gov> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> Message-ID: <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> I'm afraid that you're right about this, and I think it's the biggest obstacle to the project of getting (non-Unix) Mac users interested in Python when they go looking for a language, or just looking to get started on programming. Does the old PythonIDE come with OSX's Python? I really feel -- do people really think I'm wrong about this? -- that even PythonIDE, limited as it is, is a better beginners' recommendation than the Terminal. The trouble with the Terminal -- from the point of view of the dyed- in-the-wool Mac user I'm talking about -- is twofold: diverted from your enthusiasm for learning Python, you have to learn a new operating system interface ("how do I see what folder I'm in and what files are in it?"); and you can get yourself into trouble. ("I had to learn sudo to do X, and it's great, and now I'm going to try . . .") This is why people are afraid of Terminal, and the fear isn't *totally* irrational. Charles On Feb 8, 2006, at 4:39 PM, Christopher Barker wrote: > Charles Hartman wrote: >> I just don't believe it should >> be necessary for those people, at first, to take on even the >> beginnings of Unix in order to brave taking on Python. > > How are they going to do it? Is there a single free IDE that you > think is ready for this kind of user (including the install)? I > don't know of one. > > Without an IDE, you have the terminal (which is an IDE, as a matter > of fact, but not a GUI one!) > > You're right that it shouldn't be necessary, but I think it still > is. The lowest common denominator at this point needs to be a > willingness to learn a bit about using the terminal and an editor. > > -Chris > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov From pecora at anvil.nrl.navy.mil Thu Feb 9 00:01:16 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 08 Feb 2006 18:01:16 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> Message-ID: <43EA783C.60707@anvil.nrl.navy.mil> Charles Hartman wrote: > I'm afraid that you're right about this, and I think it's the biggest > obstacle to the project of getting (non-Unix) Mac users interested in > Python when they go looking for a language, or just looking to get > started on programming. > > Does the old PythonIDE come with OSX's Python? > > I really feel -- do people really think I'm wrong about this? -- that > even PythonIDE, limited as it is, is a better beginners' > recommendation than the Terminal. > > The trouble with the Terminal -- from the point of view of the dyed- > in-the-wool Mac user I'm talking about -- is twofold: > diverted from your enthusiasm for learning Python, you have to learn > a new > operating system interface ("how do I see what folder I'm in and > what files > are in it?"); and > you can get yourself into trouble. ("I had to learn sudo to do X, > and it's great, > and now I'm going to try . . .") > This is why people are afraid of Terminal, and the fear isn't > *totally* irrational. > > Charles > > > Yes, you have a point as does Chris. We will not solve this now since, as Chris says, the best solution is a good working GUI-IDE. I have not tried to use the old MacPython IDE in some time. I remember it started to have some strange behavior though, like jumping twice on one click in the scroll bar. There were also some path problems that, I think, require a different solution from the Terminal solution. More confusion? Maybe. Perhaps the question to answer is, how many more people will MacPython IDE lure in and then how many of those will we lose when they find out they _have_ to switch to terminal and learn some Unix? I know we can only guess this, but if we think the number is small, the Terminal approach will not be so bad. It's what we are Ultimately stuck with. In addtion you are forgetting that we can have them install TextWrangler (a no-brainer) and then run scripts from there. Almost an IDE in some ways. I work that way from BBEdit and it's fine. Write script, hit 'Run.' Terminal window opens up. Of course, this does not address an interactive session ... or does it. I never tried that in BBEdit. Possible? The more I think about it, the less terrible the Terminal sounds. Starting as session there is easy. Any files saved go to the user's top directory. A next step is just to show them how to change directories. Well, everyone should think about it since this is basic to the way the Beginner's section is formed. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From ed at leafe.com Wed Feb 8 23:51:33 2006 From: ed at leafe.com (Ed Leafe) Date: Wed, 8 Feb 2006 17:51:33 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EA64FC.50907@noaa.gov> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> Message-ID: On Feb 8, 2006, at 4:39 PM, Christopher Barker wrote: >> I just don't believe it should >> be necessary for those people, at first, to take on even the >> beginnings >> of Unix in order to brave taking on Python. > > How are they going to do it? Is there a single free IDE that you think > is ready for this kind of user (including the install)? I don't > know of one. That's certainly the goal of Dabo, but you are absolutely correct that we're not ready yet. -- Ed Leafe -- http://leafe.com -- http://dabodev.com From charles.hartman at conncoll.edu Thu Feb 9 00:14:12 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 18:14:12 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EA783C.60707@anvil.nrl.navy.mil> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> <43EA783C.60707@anvil.nrl.navy.mil> Message-ID: <80FD7B29-CF95-4772-B5D0-1289D017A7ED@conncoll.edu> On Feb 8, 2006, at 6:01 PM, Louis Pecora wrote: > Charles Hartman wrote: >> I'm afraid that you're right about this, and I think it's the >> biggest obstacle to the project of getting (non-Unix) Mac users >> interested in Python when they go looking for a language, or just >> looking to get started on programming. >> >> Does the old PythonIDE come with OSX's Python? >> >> I really feel -- do people really think I'm wrong about this? -- >> that even PythonIDE, limited as it is, is a better beginners' >> recommendation than the Terminal. >> >> The trouble with the Terminal -- from the point of view of the >> dyed- in-the-wool Mac user I'm talking about -- is twofold: >> diverted from your enthusiasm for learning Python, you have to >> learn a new >> operating system interface ("how do I see what folder I'm in >> and what files >> are in it?"); and >> you can get yourself into trouble. ("I had to learn sudo to do >> X, and it's great, >> and now I'm going to try . . .") >> This is why people are afraid of Terminal, and the fear isn't >> *totally* irrational. >> >> Charles >> >> >> > > Yes, you have a point as does Chris. We will not solve this now > since, as Chris says, the best solution is a good working GUI- > IDE. I have not tried to use the old MacPython IDE in some time. > I remember it started to have some strange behavior though, like > jumping twice on one click in the scroll bar. There were also some > path problems that, I think, require a different solution from the > Terminal solution. More confusion? Maybe. > Perhaps the question to answer is, how many more people will > MacPython IDE lure in and then how many of those will we lose when > they find out they _have_ to switch to terminal and learn some > Unix? I know we can only guess this, but if we think the number is > small, the Terminal approach will not be so bad. It's what we are > Ultimately stuck with. But we're not. I never use the Terminal with Python. I use WingIDE (can't recommend to beginners because it uses X11). Why should Mac- type beginners have a *less* friendly interface than that? > In addtion you are forgetting that we can have them install > TextWrangler (a no-brainer) and then run scripts from there. > Almost an IDE in some ways. I work that way from BBEdit and it's > fine. Write script, hit 'Run.' Terminal window opens up. Of > course, this does not address an interactive session ... or does > it. I never tried that in BBEdit. Possible? I don't think you can do interactive from the BareBones editors. (?) Nor is their relation of source file to output particularly (graphically) clear. I've done it, but I would not recommend it as a way for someone to get started. Terminal is easier. (But:) > The more I think about it, the less terrible the Terminal sounds. > Starting as session there is easy. Any files saved go to the > user's top directory. A next step is just to show them how to > change directories. I don't think you're completely entering into the beginner's mindset -- I mean in particular the beginner who is used to the Mac, never did Unix, never did DOS, etc. Yes, it's all easy for you not too hard for me, but this doesn't change what I've been saying. And it's not just Terminal Phobia. It's also a distraction. Learning a new language (especially a *first* language, and there's no reason Python shouldn't be that) is hard -- hard on the concentration, hard on the memory. Learning even a simple subset of UI commands at the same time, which have no apparent conceptual connection to the problems you're attending to in writing your first programs, makes it harder. I just don't see why we need to leave that obstacle in the way. > Well, everyone should think about it since this is basic to the way > the Beginner's section is formed. You're absolutely right. This is the (*the*?) question that I think we need to settle, to some degree, before any organization of a new page can make much sense. From dreedmac at columbus.rr.com Thu Feb 9 00:34:47 2006 From: dreedmac at columbus.rr.com (David Reed) Date: Wed, 8 Feb 2006 18:34:47 -0500 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <1139424014.15280.26.camel@localhost.localdomain> References: <1139424014.15280.26.camel@localhost.localdomain> Message-ID: On Feb 8, 2006, at 1:40 PM, linc wrote: >> >> Full disclosure: I'm a UNIX person. The first thing >> I do when I get a >> new Mac is make sure X11 is installed on it, and >> in my >> Login Items. >> The second thing I do is build an X11 version of GNU >> Emacs from the >> CVS repository. >> > Hi, > This caught my eye. I have been using a Cocoa-based Emacs for a > year or > two, and it only has one font, kind of clumsy on my clamshell with the > low resolution. Any tips on doing this, or do you know of any binary > builds available? A real Emacs with X support would be awesome. > > Thanks, > linc Darwinports and/or fink has emacs w/ X11 support. I believe you have to specify +x11 or something like that when installing with fink. You can reply privately to this - just curious where at OSU you work? Do you do Mac programming there? Dave From Chris.Barker at noaa.gov Thu Feb 9 00:35:14 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 15:35:14 -0800 Subject: [Pythonmac-SIG] a beginner's list (Or: everyone's talking; no-one's listening) In-Reply-To: References: <43E998B7.3000809@noaa.gov> Message-ID: <43EA8032.4030004@noaa.gov> has wrote: > I think what's happening in this discussion is we've got two camps > talking past one another. > > One side sees the problem primarily as a marketing issue: "How can we > attract the widest possible audience, i.e. both serious and casual > users?" > > The other sees it as a purely technical issue: "How can we provide > the latest, best tools for the minimum amount of time and work?" Well, no. The primary developers are primarily interested in the latest, best tools, yes. But everyone involved in this conversation is trying got figure out how best to market to casual users -- the truly serious ones are all set. > I have no problem with folk like Chris and Bob saying they're only > interested in supporting serious comers. That's not at all what I'm saying. I'm not interested in supporting the totally casual newbie, but only because that's not a marketing issue. We don't have the integrated IDE-GUI Toolkit-docs to support them. Let them buy RealBasic or RuntimeRevolution, or whatever. I am interested in supported users that are casual enough that they may not have the Apple developer tools installed, but are interested in at least learning to use the terminal and an editor a bit. > and isn't intended to, appeal to all sections of the audience out > there. I think we can have a single approach that support everyone between the "I'd like to learn a bit about the terminal" user to the "I'll compile it myself, but I'd rather not, if there's a binary that meets my needs" user with the same approach. > If folk can agree on the latter approach, both camps should set up on > the same website, and each look after their own sections of interest. I don't think there is any problem here. Bob is responsible for the pythonmac.org site, and He's made it very clear that he'd be glad to see it updated for newbies, but he's not going to do the work. Fortunately, Charles is ;-) > As for the frontage, split it across the middle: top half for the > cheery "let's introduce you to Python in 30 seconds" spiel; bottom > half for"here be the hardcore haxxors; come be one with us if you > think you're hard enough". And somewhere in the middle, you can have a > Top 10 lists of why it's really worth upgrading to the latest and > greatest Python et-al, providing a natural path for casual users to > follow once we've got our hooks in 'em good and proper. That's a pretty good structure. I think the real debate here really boils down to one issue: What do we present as the "standard" python to use on OS-X: the Apple supplied python or the Framework build of 2.4.1. then of course, there's a lot of details to be worked out. However, I think a consensus is building: -- define the Framework installer for 2.4 as the "standard" and most supported python for OS-X. (the existing build for 10.3 and the universal build for 10.4) -- also provide at least a quick tutorial for newbies, based on the built-in Python, and put a link to it near the top of the main page. -- At the end of that tutorial, give an explanation of why (and when) one might want to install the newer build of Python for further work. Does anyone strongly disagree with this? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Thu Feb 9 00:55:43 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 15:55:43 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <80FD7B29-CF95-4772-B5D0-1289D017A7ED@conncoll.edu> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> <43EA783C.60707@anvil.nrl.navy.mil> <80FD7B29-CF95-4772-B5D0-1289D017A7ED@conncoll.edu> Message-ID: <43EA84FF.5080600@noaa.gov> Charles Hartman wrote: > But we're not. I never use the Terminal with Python. I use WingIDE > (can't recommend to beginners because it uses X11). Um, why not? I think X11 now comes with OS-X by default. Or does it jsut look&feel too non-Macish. However, I think we need to have a totally open source (or at least free-as-in-beer) approach, even if we have recommendations for commercial products as well. > Nor is their relation of source file to output particularly > (graphically) clear. What does it set the working directory to when you run a script? >> The more I think about it, the less terrible the Terminal sounds. >> Starting as session there is easy. Any files saved go to the >> user's top directory. A next step is just to show them how to >> change directories. I agree. It really is easy enough. For most people. > Learning even a simple subset of UI commands at the > same time, which have no apparent conceptual connection to the > problems you're attending to in writing your first programs, makes it > harder. I just don't see why we need to leave that obstacle in the way. We don't have the tools to not do it, that's why. However, if we make sure the installer automagically takes care of the PATH issue, we can then recommend the "Open Terminal Here" applet, and things get pretty easy: navigate around to your script in the Finder, click "Open Terminal Here", type "python NameOfMyScript.py", hit return, and your code runs. Hit the up-arrow, then return, and it runs again. They don't even need to know that the terminal isn't a special tool for running python scripts! BTW, "Open Terminal Here" is a nifty applet you can put in your finder that you can click on, and a terminal window will open, and cd itself to the directory that the finder is currently viewing. It's clearly an ugly hack, but it does the job: http://www.entropy.ch/software/applescript/welcome.html Why the heck Apple doesn't build that functionality into finder is beyond me. > You're absolutely right. This is the (*the*?) question that I think > we need to settle, to some degree, before any organization of a new > page can make much sense. I don't think so. We know we want the "Easy start for Newbies" page, we don't have to know what to write in it before writing the rest. Let's not get too ambitious right now. If we can just clean up and make clear that main page on PythonMac.org and we'll have made some good progress. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From kevino at theolliviers.com Thu Feb 9 01:22:27 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 8 Feb 2006 16:22:27 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <43EA73C3.6020708@noaa.gov> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> <43EA73C3.6020708@noaa.gov> Message-ID: Hi Chris, On Feb 8, 2006, at 2:42 PM, Christopher Barker wrote: > Kevin Ollivier wrote: >> As does just explicitly upgrading your Python. I don't see why it's >> breaking if you install Leopard, but upgrading if you install >> MacPython >> 2.4 from pythonmac.org. Either way, your 2.3 extensions don't work >> and >> you have to start from scratch. And either way, if you thought things >> would "just work" you're in for a rude awakening. >> >> So what's the difference? > > The difference is that when you upgrade OS-X to leopard, you may or > may > not know that you are upgrading Python, and if you did know, you > may not > want to. I do get your point about allowing people to postpone upgrades, but what I don't like is how you phrase it - you're talking about "keeping Apple Python from breaking your extensions". My point is: When people upgrade Python, anyway, anyhow, their extensions will break. MacPython 2.4 doesn't do anything more or less than Apple's Python in stopping that; it simply lets you put off upgrading your Python should you want to do so. Python extensions always break when you upgrade the major Python version. Users *should* be aware of this, regardless of what platform they use or where they get their Python from. I really don't think they should be told it is something only to worry about when using Apple's Python. There is nothing OS X specific about this problem at all, and nothing Apple can do to resolve the problem except stop updating Python or stop bundling, both of which would be very bad. Thanks, Kevin From janssen at parc.com Thu Feb 9 01:48:34 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 16:48:34 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Wed, 08 Feb 2006 10:40:14 PST." <1139424014.15280.26.camel@localhost.localdomain> Message-ID: <06Feb8.164841pst."58633"@synergy1.parc.xerox.com> It's very simple to build Emacs from scratch for X11 on the Mac. I follow the instructions posted by Andrew Choi at http://members.shaw.ca/akochoi-emacs/stories/obtaining-and-building.html. Basically, make sure you have the developer tools installed, then: 1) Install GNU texinfo: $ cd /tmp $ curl -O ftp://ftp.gnu.org/gnu/texinfo/texinfo-4.8.tar.gz $ tar zxf texinfo-4.8.tar.gz $ cd texinfo-4.8 $ ./configure $ make $ sudo make install 2) Check out, build, and install Emacs: $ cd /tmp $ export CVS_RSH="ssh" $ cvs -z3 -d:ext:anoncvs at savannah.gnu.org:/cvsroot/emacs co emacs $ cd emacs $ ./configure --with-x --without-carbon --without-x-toolkit $ make bootstrap $ sudo make install I add the --without-x-toolkit because I like it that way, not because it's necessary. It's a great antique environment for doing Python programming and running Python shells. M-x pdb. Bill From w.northcott at unsw.edu.au Thu Feb 9 01:50:01 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Thu, 9 Feb 2006 11:50:01 +1100 Subject: [Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff In-Reply-To: <87CA49C9-140C-4C20-8CA7-7ED81C473E2C@mac.com> References: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> <5FDFB8BC-4A33-4EEE-955F-0DEC3BFB3B3B@redivi.com> <83BA29D9-2158-41AB-A4AE-4E011BCF750F@unsw.edu.au> <87CA49C9-140C-4C20-8CA7-7ED81C473E2C@mac.com> Message-ID: <086569E9-771E-4D2A-B306-2931DAA1AB69@unsw.edu.au> On 09/02/2006, at 5:45 AM, Ronald Oussoren wrote: >> #define _POSIX_C_SOURCE 200112L >> #include >> int main () >> { >> } > > Is that a valid POSIX program? Don't define _POSIX_C_SOURCE if you use > system libraries that are not part of POSIX. It is valid if somewhat minimal program in both C and C++. As far as I understand the Posix etc. standards, they define system library functions which must be provided, along with their functional definitions and the headers which must be used to access them. A C program is valid POSIX code if it uses the POSIX definitions of the system functions and includes. You can use any other libraries you like as long as they do not use any of the POSIX function names. So, yes I think that is valid POSIX C code. The real problem here is that C++ is not part of the POSIX standard. So no C++ program can be POSIX compliant. That is why the 'correct' tm fix is to conditionalise the POSIX defines with #ifndef __cplusplus or an equivalent. I have now established that if that is done all of WXPython will build perfectly happily. This is not the first time I have run into this sort of issue with some C/Fortran package that permits C++ extensions. People easily forget that C++ (unlike Objective-C) is not a superset of C. It is a different language. The coders on the main package all too easily hack up C headers without bothering to think that they may get included in a C++ program and not function as they do in C. As my test program, demonstrates Apple's Carbon is quite happy on a POSIX compliant system in a C program but NOT in C++ program. This is not a failure to comply with the POSIX standards, because C++ is not POSIX compliant. Cheers Bill From janssen at parc.com Thu Feb 9 01:52:02 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 16:52:02 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Wed, 08 Feb 2006 10:44:54 PST." <43EA3C26.4010208@noaa.gov> Message-ID: <06Feb8.165207pst."58633"@synergy1.parc.xerox.com> > What I don't see > any evidence for is them keeping 2.3.5 around as well. What that means > is that all the packages you have compiled and installed for 2.3.* will > no longer work. I agree. In fact, those extensions won't even be there, because they are by default installed under /System, so the new OS installation will remove them just as it will remove 2.3.5. I don't think this will disconcert or surprise anyone -- any needed additional packages will just have to be re-installed. So what? Another advantage of using the pre-supplied version. > Yes, python-only scripts that use usr/bin/python will > most likely work, but that's it. Yep, that's what we're looking for. Bill From w.northcott at unsw.edu.au Thu Feb 9 01:54:49 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Thu, 9 Feb 2006 11:54:49 +1100 Subject: [Pythonmac-SIG] wxPython 2.6.2.1 source build a new issue In-Reply-To: References: Message-ID: If you try to build wxWidgets from the wxPython 2.6.2.1 sources with '--enable-optimize --disable-debug', configure creates setup.h in a release directory but the Makefile looks for it in a debug directory. Whoops! Maybe this is related to the problem with the monolithic build. Bill northcott From ronaldoussoren at mac.com Wed Feb 8 22:08:58 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 8 Feb 2006 22:08:58 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> Message-ID: <685A7AAB-2CD0-4C5B-A711-0F37ED442C2B@mac.com> On 8-feb-2006, at 21:42, Ronald Oussoren wrote: > > On 8-feb-2006, at 21:21, Bob Ippolito wrote: > >> >> On Feb 8, 2006, at 11:59 AM, Ronald Oussoren wrote: >> >>> >>> On 7-feb-2006, at 0:59, Bob Ippolito wrote: >>>>> >>>>> Bob, what do you think the timescale is for a universal build? >>>>> If it's >>>>> soon, then we should work on re-0writing the web site as though >>>>> it's >>>>> ready to go. >>>> >>>> I'd say soon... The only issues left are to sort out the >>>> distribution >>>> scripts and some more testing I guess. >>> >>> Having a working build environment would also be nice. 'make >>> frameworkinstall' >>> fails if builddir != srcdir. I'm working on this right now. >> >> It worked for me.. I never build in srcdir. What's the problem? > > $make frameworkinstall > ... > gcc -arch ppc -arch i386 -isysroot / -fno-strict-aliasing -Wno- > long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic - > DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Include -c -o > Mac/OSX/PythonLauncher/main.o ../Mac/OSX/PythonLauncher/main.m > lipo: can't create output file: Mac/OSX/PythonLauncher/main.o (No > such file or directory) > > > svn diff says that everything is fine. Maybe it's because I'm > building a DTK system and I haven't bothered upgrading it because > I'm running headless and didn't have a screen lying around when > update came in. > > Anyway, don't like your solution for building PythonLauncher. I've > replaced it by a Makefile.in in Mac/OSX/PythonLauncher, that way > all logic for building > PythonLauncher is nicely located in the Mac/OSX/PythonLauncher > directory. I might rewrite Mac/OSX/Makefile as well now that I'm > working on this. The attached patch: - Uses MACOSX_DEPLOYMENT_TARGET instead of CONFIGURE_MACOSX_DEPLOYMENT_TARGET in the toplevel Makefile and distutils - Uses 'export MACOSX_DEPLOYMENT_TARGET' to get the value into the environment from the Makefile, including some configure trickery that will only enable this line on OSX - Moves Mac/OSX/Makefile to Mac/OSX/Makefile.in and inserts some values using configure - Create Mac/OSX/PythonLauncher/Makefile.in and use that to build and install PythonLauncher.app, you should move the resource files from the application template to Mac/OSX/PythonLauncher after applying the patch. BTW. I patched configure by hand. BTW2. This just ensures make frameworkinstall works, I haven't tested the output yet. BTW3. What is the plan w.r.t. merging our patches back into the python repository? I'd like to get all of this into Python 2.5 at the very least. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: misc-fixes.patch Type: application/octet-stream Size: 31665 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/3f6acefe/attachment-0001.obj -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060208/3f6acefe/attachment-0001.bin From janssen at parc.com Thu Feb 9 02:05:00 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 17:05:00 PST Subject: [Pythonmac-SIG] a beginner's list (Or: everyone's talking; no-one's listening) In-Reply-To: Your message of "Wed, 08 Feb 2006 15:35:14 PST." <43EA8032.4030004@noaa.gov> Message-ID: <06Feb8.170502pst."58633"@synergy1.parc.xerox.com> > However, I think a consensus is building: Yeah, among the usual suspects. > -- define the Framework installer for 2.4 as the "standard" and most > supported python for OS-X. (the existing build for 10.3 and the > universal build for 10.4) I completely disagree with this. The "standard" is what comes with the OS; by default that's the "most supported" python -- every Mac has it. I certainly have no problem with pointing out to people that it's a few years old, and that there are packages which can be downloaded and installed to provide an additional side-by-side version that's newer and better. If you're unhappy with what's in the stdlib and what's not, go gripe on python-dev via PEPs and reasoned discussion. (I, for instance, think that there should be a standard portable GUI toolkit, based on pycairo, in the stdlib.) However, I think a lot of the confusion around this topic is that when you install 2.4.x, there are now two Pythons on your Mac, and they get in each other's way unless you are careful. Someone should be more than just a script writer to get into that situation. I think installing a second version of Python on the Mac should be restricted to folks who need it or want it; it shouldn't be encouraged in general. > -- also provide at least a quick tutorial for newbies, based on the > built-in Python, and put a link to it near the top of the main page. I'd put it *on* the main page, on top, and I'll volunteer to write it. Maybe I already did write it. > -- At the end of that tutorial, give an explanation of why (and when) > one might want to install the newer build of Python for further work. Exactly. Great idea. One thing I'd add, between the two, is a short example of installing an additional package, like PIL or reportlab, using the Terminal. Perhaps these steps: 1) Using Python with the stdlib. 2) Adding an external package to the standard Python. 3) Adding a more recent version of Python. How to do it and what to watch out for. 4) Mongo packages, like Scientific Python, pre-built with a newer Python. 5) Mac-specific tools, like bundlebuilder and py2app and PyObjC. Bill From Chris.Barker at noaa.gov Thu Feb 9 02:11:33 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 08 Feb 2006 17:11:33 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> <43EA73C3.6020708@noaa.gov> Message-ID: <43EA96C5.4020406@noaa.gov> Kevin Ollivier wrote: > My point is: When people upgrade > Python, anyway, anyhow, their extensions will break. MacPython 2.4 > doesn't do anything more or less than Apple's Python in stopping that; > it simply lets you put off upgrading your Python should you want to do so. Right. To be softer: I think it's a good idea to only base your stuff on things you either control or you're confident your OS vendor won't change in the next release. That's why I advocate installing your own Python. > Python extensions always break when you upgrade the major Python > version. Users *should* be aware of this, regardless of what platform > they use or where they get their Python from. Sure. > nothing Apple can do to resolve the problem except stop updating Python > or stop bundling, both of which would be very bad. Yes, they could. They could keep 2.3.5 around and add 2.4.* to it, rather than replacing it. That's what I do when I upgrade. Then all my utilities still work, while I slowly add all the extensions to the new version. I had 1.5.6, 2.0, 2.2 and 2.3 on my Linux box for a while! I'm not sure Apple should do that, and if they did, I'm not sure how long they should keep it up -- you could get a lot of python versions lying around after a while! By the way, Kevin, do you have any idea how hard it's going to be to build wxPython far and with the universal python Bob et. al are working on? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From janssen at parc.com Thu Feb 9 02:37:49 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 17:37:49 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Wed, 08 Feb 2006 14:42:11 PST." <43EA73C3.6020708@noaa.gov> Message-ID: <06Feb8.173752pst."58633"@synergy1.parc.xerox.com> Christopher Barker writes: > When (If) he upgrades OS-X, > that app will break. Almost every other app he has installed on his > system will continue to work, but the python based one will not. This > would apply to any app using the built in python and any extensions: > simple scripts, py2app bundles, etc. Hmmm. I upgrade a lot, even move from Solaris to Mac OS X, and most (all?) of my Python programs continue to work against /usr/bin/python. If apps don't, that seems to me to be a problem with the current state of Python apps, not with Python. File a bug report with whoever supports building apps with Python (Apple doesn't seem to be the place). I can see that this would be a major concern for developers targetting the Mac platform. But confusing the user by making them install a second Python wouldn't seem to be the right answer to this problem (to me, at least). In fact, it seems (to me) a really user-hostile approach, and a good reason to look for a different app. If I was building an app that was written in Python, given the current state of MacPython and what I've read on this list over the years, I'd try to include the whole Python VM in that app bundle. Bill From bob at redivi.com Thu Feb 9 02:40:19 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 17:40:19 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> Message-ID: <685A46E0-ACA5-4DA7-8ABF-624DE7A8973E@redivi.com> On Feb 8, 2006, at 2:42 PM, Charles Hartman wrote: > I'm afraid that you're right about this, and I think it's the biggest > obstacle to the project of getting (non-Unix) Mac users interested in > Python when they go looking for a language, or just looking to get > started on programming. > > Does the old PythonIDE come with OSX's Python? No, it has never shipped with Mac OS X. The old Python IDE is dead, forget it ever existed. It hasn't been touched in god knows how many years and a dependency it has is "non- free" and not available for i386. > I really feel -- do people really think I'm wrong about this? -- that > even PythonIDE, limited as it is, is a better beginners' > recommendation than the Terminal. It's not even an option, we'd need to pick something else. IDLE is the only suitable library candidate for a beginners IDE, but only on Mac OS X 10.4 and later (since 10.3 did not ship with Tcl/Tk). Technically IDLE should even work on a stock Mac OS X 10.4 system if the user went to the scary terminal and typed: pythonw -c "import idlelib.idle" -bob From kevino at theolliviers.com Thu Feb 9 02:41:38 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 8 Feb 2006 17:41:38 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <43EA96C5.4020406@noaa.gov> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> <43EA73C3.6020708@noaa.gov> <43EA96C5.4020406@noaa.gov> Message-ID: <26B518F0-374C-42B6-B1D4-0BD9CC17A656@theolliviers.com> Hi Chris, On Feb 8, 2006, at 5:11 PM, Christopher Barker wrote: > Kevin Ollivier wrote: >> My point is: When people upgrade Python, anyway, anyhow, their >> extensions will break. MacPython 2.4 doesn't do anything more or >> less than Apple's Python in stopping that; it simply lets you put >> off upgrading your Python should you want to do so. > > Right. To be softer: I think it's a good idea to only base your > stuff on things you either control or you're confident your OS > vendor won't change in the next release. That's why I advocate > installing your own Python. > >> Python extensions always break when you upgrade the major Python >> version. Users *should* be aware of this, regardless of what >> platform they use or where they get their Python from. > > Sure. > >> nothing Apple can do to resolve the problem except stop updating >> Python or stop bundling, both of which would be very bad. > > Yes, they could. They could keep 2.3.5 around and add 2.4.* to it, > rather than replacing it. That's what I do when I upgrade. Then all > my utilities still work, while I slowly add all the extensions to > the new version. I had 1.5.6, 2.0, 2.2 and 2.3 on my Linux box for > a while! > > I'm not sure Apple should do that, and if they did, I'm not sure > how long they should keep it up -- you could get a lot of python > versions lying around after a while! Yes, true, I had thought about that earlier but forgot to mention it. :-) Actually, OS X and Python both seem to be updating with less frequency, so they may not mind just adding 2.3 to the mix. We'll have to see, I guess. It might be nice if they commit to including two versions, i.e. removing 2.3 when 2.5 gets into OS X, which IMHO might be a nice solution to the issue. We'll have to see when Leopard arrives. > By the way, Kevin, do you have any idea how hard it's going to be > to build wxPython far and with the universal python Bob et. al are > working on? I haven't built the Universal Python sources Bob uploaded yet, but I don't anticipate any major issues. The one thing that might happen is duplicate -isysroot entries because that gets added into wx-config if you build Universal for wxWidgets itself. But sometime in the next week or two I hope to devote some time to ironing that out. Kevin > -Chris > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov From bob at redivi.com Thu Feb 9 02:42:42 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 17:42:42 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EA84FF.5080600@noaa.gov> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> <43EA783C.60707@anvil.nrl.navy.mil> <80FD7B29-CF95-4772-B5D0-1289D017A7ED@conncoll.edu> <43EA84FF.5080600@noaa.gov> Message-ID: On Feb 8, 2006, at 3:55 PM, Christopher Barker wrote: > Charles Hartman wrote: >> But we're not. I never use the Terminal with Python. I use WingIDE >> (can't recommend to beginners because it uses X11). > > Um, why not? I think X11 now comes with OS-X by default. Or does it > jsut > look&feel too non-Macish. It comes with OS X, but it doesn't install by default. -bob From janssen at parc.com Thu Feb 9 02:42:36 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 17:42:36 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Wed, 08 Feb 2006 15:14:12 PST." <80FD7B29-CF95-4772-B5D0-1289D017A7ED@conncoll.edu> Message-ID: <06Feb8.174237pst."58633"@synergy1.parc.xerox.com> > But we're not. I never use the Terminal with Python. I use WingIDE > (can't recommend to beginners because it uses X11). Why should Mac- > type beginners have a *less* friendly interface than that? Because it doesn't come with the system. > I don't think you're completely entering into the beginner's mindset > -- I mean in particular the beginner who is used to the Mac, Do these people still exist? This sounds like a 2001-2002 point, back when most existing Mac users were used to System 7/8/9. Bill From bob at redivi.com Thu Feb 9 02:47:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 17:47:12 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> Message-ID: On Feb 8, 2006, at 2:11 PM, Kevin Ollivier wrote: > > On Feb 8, 2006, at 1:34 PM, Bob Ippolito wrote: > > [snip] > >>> >>> It's a bit confusing to talk as if needing new extensions == >>> breakage. (You know you're a geek when it's second nature to write >>> equality tests like this. ;-) I remember Python 2.1 and I've had to >>> upgrade several times, and I never thought of re-installing my >>> extensions as 'fixing what broke'. I called it 'upgrading'. Some >>> people may see initially see what appears to be broken scripts, but >>> unfortunately that would just be because they aren't aware of issues >>> that may occur when upgrading their Python install. I don't think >>> the >>> proper solution is to keep them from upgrading; we just need to >>> build >>> awareness that a new Python major version means new extensions. >> >> We're talking about upgrading Mac OS X, which implicitly upgrades >> Python and obsoletes all of your extensions. I'd call that breaking. > > As does just explicitly upgrading your Python. I don't see why it's > breaking if you install Leopard, but upgrading if you install > MacPython 2.4 from pythonmac.org. Either way, your 2.3 extensions > don't work and you have to start from scratch. And either way, if you > thought things would "just work" you're in for a rude awakening. The difference is that if I didn't know better, I'd get really pissed off if I upgraded my OS and all of my very important work stuff breaks and makes me waste a day tracking down what needs to be fixed. That's not what an OS upgrade is supposed to do. It doesn't do that for anything except applications that depend on moving targets like the system's Python or Perl interpreter. If a third party Python had been used all along, the user has freedom to upgrade their OS *and/or* their interpreter on their schedule. -bob From bob at redivi.com Thu Feb 9 02:48:48 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 17:48:48 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb8.165207pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.165207pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 8, 2006, at 4:52 PM, Bill Janssen wrote: >> What I don't see >> any evidence for is them keeping 2.3.5 around as well. What that >> means >> is that all the packages you have compiled and installed for 2.3.* >> will >> no longer work. > > I agree. In fact, those extensions won't even be there, because they > are by default installed under /System, so the new OS installation > will remove them just as it will remove 2.3.5. I don't think this > will disconcert or surprise anyone -- any needed additional packages > will just have to be re-installed. So what? Another advantage of > using the pre-supplied version. Not correct, nor is it an advantage. Extensions are installed to / Library/Python/2.3 or /Library/Python/2.3/site-packages, depending on if you're using 10.3 or 10.4. -bob From bob at redivi.com Thu Feb 9 03:06:31 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 18:06:31 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb8.174237pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.174237pst."58633"@synergy1.parc.xerox.com> Message-ID: <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> On Feb 8, 2006, at 5:42 PM, Bill Janssen wrote: >> But we're not. I never use the Terminal with Python. I use WingIDE >> (can't recommend to beginners because it uses X11). Why should Mac- >> type beginners have a *less* friendly interface than that? > > Because it doesn't come with the system. Nothing relevant comes with the system except for Terminal and TextEdit... >> I don't think you're completely entering into the beginner's mindset >> -- I mean in particular the beginner who is used to the Mac, > > Do these people still exist? This sounds like a 2001-2002 point, back > when most existing Mac users were used to System 7/8/9. Of course they exist. Used to the Mac is used to the Mac, whether or not UNIX happens to be living underneath these days. -bob From bob at redivi.com Thu Feb 9 03:13:46 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 18:13:46 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb8.173752pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.173752pst."58633"@synergy1.parc.xerox.com> Message-ID: <45BE551C-9250-4F92-8171-3F69F48042C8@redivi.com> On Feb 8, 2006, at 5:37 PM, Bill Janssen wrote: > Christopher Barker writes: >> When (If) he upgrades OS-X, >> that app will break. Almost every other app he has installed on his >> system will continue to work, but the python based one will not. This >> would apply to any app using the built in python and any extensions: >> simple scripts, py2app bundles, etc. > > Hmmm. I upgrade a lot, even move from Solaris to Mac OS X, and most > (all?) of my Python programs continue to work against /usr/bin/python. > If apps don't, that seems to me to be a problem with the current state > of Python apps, not with Python. File a bug report with whoever > supports building apps with Python (Apple doesn't seem to be the > place). I can see that this would be a major concern for developers > targetting the Mac platform. But confusing the user by making them > install a second Python wouldn't seem to be the right answer to this > problem (to me, at least). In fact, it seems (to me) a really > user-hostile approach, and a good reason to look for a different app. You're a UNIX user, you already know what you are doing, you don't count. Wrong. Extensions are extensions and they target a specific version of Python. There's nothing that can be done about that; the ABI changes. I'd have to guess that at least 95% of user-facing Python- based applications on Mac OS X are going to need at least one extension that doesn't ship with OS X. There are some exceptions to this, such as Tomato Torrent which has an Objective-C/Cocoa GUI and communicates via pipes with the pure- Python BitTorrent application launched using /usr/bin/python. I'm not entirely sure I'd consider that a Python application, though. The 95% may shrink now that wxPython and tkinter are shipped with Mac OS X. It may shrink even further when/if ctypes becomes part of Python 2.5 (if that happens), and further still if PyObjC ends up shipping with some version of OS X. However, for all practical purposes, your argument doesn't apply to the current or immediate future of Python on any platform that doesn't do package management for you. > If I was building an app that was written in Python, given the current > state of MacPython and what I've read on this list over the years, I'd > try to include the whole Python VM in that app bundle. It's good to see that someone has been paying attention :) -bob From w.northcott at unsw.edu.au Thu Feb 9 03:13:46 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Thu, 9 Feb 2006 13:13:46 +1100 Subject: [Pythonmac-SIG] wxPython 2.6.2.1 source build a final summary In-Reply-To: References: Message-ID: This is a final summary of my experiences building wxPython 2.6.2.1 sources on MacOS X 10.4.4 with ActivePython 2.4.2.10 and Xcode 2.2.1 with gcc-3.3 and g77. To avoid the problems with _POSIX_C_SOURCE and friends, I conditionalized the defines for _POSIX_C_SOURCE _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED with #if !defined(__cplusplus). This has enabled me to build a number of modules including wxPython without problem. The C sources are quite happy with the POSIX defines and the C++ sources don't get them. It seems to me that these changes should be made in Python. The configure test for strcasecmp seems wrong to me. As I see it, most modern operating environments are standards compliant. So they will have strings.h and it will contain strcasecmp. The use of string.h should be just a fall back. All that is necessary to fix this is to swap the tests around to check for strings.h first followed by string.h and the hack as a final default. I still feel much happier using the _POSIX_C_SOURCE define to always get strcasecmp from strings.h. That will always work in a C program by definition. The problem is C++. Really you should not use strcasecmp in a C++ program. The 'right' answer is to have a C source file defining a small utility function wxstrcasecmp() and link this with the C++ object files. That way you can be sure that POSIX compliance will do it for you. With those changes, wxPython now builds for me from source and it runs Bob's demo programs. without recompiling them. Cheers Bill Northcott From janssen at parc.com Thu Feb 9 03:14:44 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 18:14:44 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Wed, 08 Feb 2006 17:48:48 PST." Message-ID: <06Feb8.181447pst."58633"@synergy1.parc.xerox.com> > Extensions are installed to / > Library/Python/2.3 or /Library/Python/2.3/site-packages, depending on > if you're using 10.3 or 10.4. Ah, my mistake. Thanks for pointing it out. I suppose that with an Upgrade install of 10.5, that data under /Library would be preserved. That's too bad. Bill From brendansimons at yahoo.ca Thu Feb 9 03:12:24 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Wed, 8 Feb 2006 21:12:24 -0500 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: Message-ID: Some quick thoughts on previous posts: Lou Pecora wrote: > In addtion you are forgetting that we can have them install > TextWrangler (a no-brainer) and then run scripts from there. > Almost an IDE in some ways. I work that way from BBEdit and it's > fine. Write script, hit 'Run.' Terminal window opens up. Of > course, this does not address an interactive session ... or does > it. I never tried that in BBEdit. Possible? Not in textwrangler, but wxPython comes with a nice interactive shell (with code completion!) "PyCrust". It's built as a .app, so it installs and works like any other application on OS X http:// prdownloads.sourceforge.net/wxpython/wxPython2.6-osx-docs- demos-2.6.2.1-macosx10.3-py2.4.dmg As to the parent question, I was extremely happy learning Python in Textwrangler until I broke down and bought Komodo. SPE is almost there, but still needs a binary install. On the other hand, the terminal is already there on everyone's machine. Christopher Barker wrote: > BTW, "Open Terminal Here" is a nifty applet you can put in your > finder that you can click on, and a terminal window will open, and > cd itself to the directory that the finder is currently viewing. > It's clearly an ugly hack, but it does the job: Here's another easy way to do the same thing: Open the terminal. Type "ls" followed by a space, but don't hit return. Now click on the finder and open the folder you want Terminal to access. In the titlebar of the finder window, next to the folder's name, is a little folder icon. Drag that icon to your terminal window (Expose helps if you have lots of windows open). Terminal will spell out the folder's path for you. Now return to Terminal and hit enter. > However, I think a consensus is building: > -- define the Framework installer for 2.4 as the "standard" and > most supported python for OS-X. (the existing build for 10.3 and > the universal build for 10.4) > -- also provide at least a quick tutorial for newbies, based on > the built-in Python, and put a link to it near the top of the main > page. > -- At the end of that tutorial, give an explanation of why (and > when) one might want to install the newer build of Python for > further work. I agree, but I would switch the order/emphasis. The page should start with a "Try it yourself" link, where we show them how Python can let them do useful and interesting things out of the box. Under that link, and at the end of the tutorial, you can have a "Get Better" link which details how to use framework python, easyinstall etc. www.rubyonrails.org has the right idea. Brendan -- Brendan Simons __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From janssen at parc.com Thu Feb 9 03:18:50 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 18:18:50 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Wed, 08 Feb 2006 18:06:31 PST." <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> Message-ID: <06Feb8.181852pst."58633"@synergy1.parc.xerox.com> Bob Ippolito reponds to my question: > > Do these people still exist? This sounds like a 2001-2002 point, back > > when most existing Mac users were used to System 7/8/9. > > Of course they exist. Used to the Mac is used to the Mac, whether or > not UNIX happens to be living underneath these days. I seem to know a lot of Mac users where Unix lives on top, not underneath. Would be interesting to do a field study to investigate the changing demographics of Mac users. But my point was simply that it seems hard to be a Mac user these days without some basic use of the Terminal. Bill From janssen at parc.com Thu Feb 9 03:29:21 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 18:29:21 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Wed, 08 Feb 2006 17:40:19 PST." <685A46E0-ACA5-4DA7-8ABF-624DE7A8973E@redivi.com> Message-ID: <06Feb8.182922pst."58633"@synergy1.parc.xerox.com> > Technically IDLE should even work on a stock Mac OS X 10.4 system if > the user went to the scary terminal and typed: > > pythonw -c "import idlelib.idle" Sure enough! Cool! What's more, it puts menus in the menubar, and they're reasonably useful. Bill From janssen at parc.com Thu Feb 9 03:36:03 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 18:36:03 PST Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: Your message of "Wed, 08 Feb 2006 18:13:46 PST." <45BE551C-9250-4F92-8171-3F69F48042C8@redivi.com> Message-ID: <06Feb8.183608pst."58633"@synergy1.parc.xerox.com> Bob Ippolito writes: > You're a UNIX user, you already know what you are doing, you don't > count. > > Wrong. Wrong what? Are you saying that saying that I don't count is wrong? > I'd have to guess that at least 95% of user-facing Python- > based applications on Mac OS X are going to need at least one > extension that doesn't ship with OS X. I think here you are talking about a Mac app bundle, right? I think that's probably right. Bill From bob at redivi.com Thu Feb 9 03:58:21 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 18:58:21 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <06Feb8.183608pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.183608pst."58633"@synergy1.parc.xerox.com> Message-ID: <926C7502-67D4-489A-BD87-FEFE0F2B29DA@redivi.com> On Feb 8, 2006, at 6:36 PM, Bill Janssen wrote: > Bob Ippolito writes: >> You're a UNIX user, you already know what you are doing, you don't >> count. >> >> Wrong. > > Wrong what? Are you saying that saying that I don't count is wrong? That's out of context. I was replying to your statements in order. This one in particular: """ > (all?) of my Python programs continue to work against /usr/bin/python. > If apps don't, that seems to me to be a problem with the current state > of Python apps, not with Python. """ And the qualification for "Wrong" was: Extensions are extensions and they target a specific version of Python. There's nothing that can be done about that; the ABI changes. >> I'd have to guess that at least 95% of user-facing Python- >> based applications on Mac OS X are going to need at least one >> extension that doesn't ship with OS X. > > I think here you are talking about a Mac app bundle, right? I think > that's probably right. I'm talking about most user-facing applications, app bundles or otherwise. Do you really develop all of your applications using only stdin, stdout, sockets, and the stdlib? No SciPy, databases, PIL, etc? I can't think of a single moderately popular Python application that doesn't require at least one extension. I write very few applications that don't at least talk to a database, but maybe I'm missing something. -bob From bob at redivi.com Thu Feb 9 04:01:47 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 19:01:47 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb8.181852pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.181852pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 8, 2006, at 6:18 PM, Bill Janssen wrote: > Bob Ippolito reponds to my question: >>> Do these people still exist? This sounds like a 2001-2002 point, >>> back >>> when most existing Mac users were used to System 7/8/9. >> >> Of course they exist. Used to the Mac is used to the Mac, whether or >> not UNIX happens to be living underneath these days. > > I seem to know a lot of Mac users where Unix lives on top, not > underneath. Would be interesting to do a field study to investigate > the changing demographics of Mac users. I am one of those too, of course, but I do know a lot of Mac users who spend most of their time in applications like Photoshop, Dreamweaver, BBEdit, etc. and rarely venture towards the Terminal. Not quite the same audience, but at least some of them would be potential Python users by way of appscript or web development tools. > But my point was simply that it seems hard to be a Mac user these days > without some basic use of the Terminal. That's not true at all. -bob From kevino at theolliviers.com Thu Feb 9 04:13:48 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 8 Feb 2006 19:13:48 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> Message-ID: <56194992-3505-48E1-B248-958ACF8EA164@theolliviers.com> Hi Bob, On Feb 8, 2006, at 5:47 PM, Bob Ippolito wrote: > > On Feb 8, 2006, at 2:11 PM, Kevin Ollivier wrote: > >> >> On Feb 8, 2006, at 1:34 PM, Bob Ippolito wrote: >> >> [snip] >> >>>> >>>> It's a bit confusing to talk as if needing new extensions == >>>> breakage. (You know you're a geek when it's second nature to write >>>> equality tests like this. ;-) I remember Python 2.1 and I've had to >>>> upgrade several times, and I never thought of re-installing my >>>> extensions as 'fixing what broke'. I called it 'upgrading'. Some >>>> people may see initially see what appears to be broken scripts, but >>>> unfortunately that would just be because they aren't aware of >>>> issues >>>> that may occur when upgrading their Python install. I don't >>>> think the >>>> proper solution is to keep them from upgrading; we just need to >>>> build >>>> awareness that a new Python major version means new extensions. >>> >>> We're talking about upgrading Mac OS X, which implicitly upgrades >>> Python and obsoletes all of your extensions. I'd call that >>> breaking. >> >> As does just explicitly upgrading your Python. I don't see why it's >> breaking if you install Leopard, but upgrading if you install >> MacPython 2.4 from pythonmac.org. Either way, your 2.3 extensions >> don't work and you have to start from scratch. And either way, if you >> thought things would "just work" you're in for a rude awakening. > > The difference is that if I didn't know better, I'd get really > pissed off if I upgraded my OS and all of my very important work > stuff breaks and makes me waste a day tracking down what needs to > be fixed. That's not what an OS upgrade is supposed to do. It > doesn't do that for anything except applications that depend on > moving targets like the system's Python or Perl interpreter. I'd get really pissed off if I didn't know better and things stopped working regardless of how I upgraded Python. You'd consider whose Python broke your stuff into your decision to get upset? All Apple is doing is including Python with their OS, and occasionally updating it. That these updates can cause not-so- pleasant things to happen due to how Python works is not Apple's fault. A lot of the speech on here practically accuses Apple of causing the problem and it's really not fair. > If a third party Python had been used all along, the user has > freedom to upgrade their OS *and/or* their interpreter on their > schedule. Sure, but it's got nothing to do with problems in Apple's Python and everything to do with avoiding upgrades to avoid updating extensions. So be straight with users - tell them things break when Python is upgraded to a new major version; don't tell them (or suggest) things break because Apple is doing it. Kevin > -bob > From janssen at parc.com Thu Feb 9 04:24:53 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 19:24:53 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Wed, 08 Feb 2006 19:01:47 PST." Message-ID: <06Feb8.192503pst."58633"@synergy1.parc.xerox.com> > I am one of those too, of course, but I do know a lot of Mac users > who spend most of their time in applications like Photoshop, > Dreamweaver, BBEdit, etc. and rarely venture towards the Terminal. > Not quite the same audience, but at least some of them would be > potential Python users by way of appscript or web development tools. Sure, that make perfect sense. > > But my point was simply that it seems hard to be a Mac user these days > > without some basic use of the Terminal. > > That's not true at all. OK, I'm probably the wrong person to assess that. So it seems that a old Unix-style Python program which reads from stdin (or a file or a tty) and writes to stdout would be difficult to explain to someone who has never used a command line. And there's essentially no way to get Idle started without using a command line. Bill From kevino at theolliviers.com Thu Feb 9 04:33:46 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 8 Feb 2006 19:33:46 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb8.192503pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.192503pst."58633"@synergy1.parc.xerox.com> Message-ID: Hi Bill, On Feb 8, 2006, at 7:24 PM, Bill Janssen wrote: >> I am one of those too, of course, but I do know a lot of Mac users >> who spend most of their time in applications like Photoshop, >> Dreamweaver, BBEdit, etc. and rarely venture towards the Terminal. >> Not quite the same audience, but at least some of them would be >> potential Python users by way of appscript or web development tools. > > Sure, that make perfect sense. > >>> But my point was simply that it seems hard to be a Mac user these >>> days >>> without some basic use of the Terminal. >> >> That's not true at all. > > OK, I'm probably the wrong person to assess that. > > So it seems that a old Unix-style Python program which reads from > stdin (or a file or a tty) and writes to stdout would be difficult to > explain to someone who has never used a command line. And there's > essentially no way to get Idle started without using a command line. What about an app bundle that just starts IDLE? Kevin > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From charles.hartman at conncoll.edu Thu Feb 9 04:40:45 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 8 Feb 2006 22:40:45 -0500 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: Message-ID: Well, so PythonIDE is dead. (It hasn't been well for a long time.) How ready-for-prime-time is IDLE? What drawbacks are there to recommending it to beginners? What can't you do? Do I remember that it uses TKinter? Does it make wx impossible to use? I haven't used it, so I'm asking out of ignorance, not simply rhetorically. Charles From bob at redivi.com Thu Feb 9 04:43:28 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 19:43:28 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <56194992-3505-48E1-B248-958ACF8EA164@theolliviers.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> <56194992-3505-48E1-B248-958ACF8EA164@theolliviers.com> Message-ID: <4B63B3CC-4729-4337-B215-58BA8B34FF77@redivi.com> On Feb 8, 2006, at 7:13 PM, Kevin Ollivier wrote: > On Feb 8, 2006, at 5:47 PM, Bob Ippolito wrote: > >> >> On Feb 8, 2006, at 2:11 PM, Kevin Ollivier wrote: >> >>> >>> On Feb 8, 2006, at 1:34 PM, Bob Ippolito wrote: >>> >>> [snip] >>> >>>>> >>>>> It's a bit confusing to talk as if needing new extensions == >>>>> breakage. (You know you're a geek when it's second nature to write >>>>> equality tests like this. ;-) I remember Python 2.1 and I've >>>>> had to >>>>> upgrade several times, and I never thought of re-installing my >>>>> extensions as 'fixing what broke'. I called it 'upgrading'. Some >>>>> people may see initially see what appears to be broken scripts, >>>>> but >>>>> unfortunately that would just be because they aren't aware of >>>>> issues >>>>> that may occur when upgrading their Python install. I don't >>>>> think the >>>>> proper solution is to keep them from upgrading; we just need to >>>>> build >>>>> awareness that a new Python major version means new extensions. >>>> >>>> We're talking about upgrading Mac OS X, which implicitly upgrades >>>> Python and obsoletes all of your extensions. I'd call that >>>> breaking. >>> >>> As does just explicitly upgrading your Python. I don't see why it's >>> breaking if you install Leopard, but upgrading if you install >>> MacPython 2.4 from pythonmac.org. Either way, your 2.3 extensions >>> don't work and you have to start from scratch. And either way, if >>> you >>> thought things would "just work" you're in for a rude awakening. >> >> The difference is that if I didn't know better, I'd get really >> pissed off if I upgraded my OS and all of my very important work >> stuff breaks and makes me waste a day tracking down what needs to >> be fixed. That's not what an OS upgrade is supposed to do. It >> doesn't do that for anything except applications that depend on >> moving targets like the system's Python or Perl interpreter. > > I'd get really pissed off if I didn't know better and things stopped > working regardless of how I upgraded Python. You'd consider whose > Python broke your stuff into your decision to get upset? Installing Python 2.4 on a machine that has Python 2.3 installed doesn't break anything... except for any tools you have written that depend on the PATH. distutils-installed scripts are robust against PATH changes as they point to a specific Python binary. It's not an upgrade and it's not harmful. Upgrading the OS if you depend on its Python *is* potentially an upgrade and potentially *is* harmful. There's also the problem of distribution of apps to other machines... we can solve that with a third party Python, but not with Apple's. > All Apple is doing is including Python with their OS, and > occasionally updating it. That these updates can cause not-so- > pleasant things to happen due to how Python works is not Apple's > fault. A lot of the speech on here practically accuses Apple of > causing the problem and it's really not fair. My biggest problem with their releases is that once there's a bug you're stuck with it for at least 18 months. Also, their process isn't very transparent. Very few people who know how to evaluate their patches get the opportunity to do so before they hit gold master and it's frozen for years. There are threading bugs in Python 2.3 that I personally ran into. That was the day I stopped using Python 2.3 altogether because I knew that version of 2.3 was frozen in time forever on Mac OS X. For example, Mac OS X 10.4 shipped with floating point bugs that broke Python in various ways. They'd have found this out if they ran its regression tests, but apparently that's not part of their process. It's simply not a trustable release. In this case we were fortunate that it was a libSystem bug that they were interested in fixing.. but had it been a typo in their Python Makefile or something, we'd be screwed like we were on Mac OS X 10.2 with the rogue -arch i386 flag that broke extension building on their Python 2.2.0. >> If a third party Python had been used all along, the user has >> freedom to upgrade their OS *and/or* their interpreter on their >> schedule. > > Sure, but it's got nothing to do with problems in Apple's Python and > everything to do with avoiding upgrades to avoid updating extensions. > So be straight with users - tell them things break when Python is > upgraded to a new major version; don't tell them (or suggest) things > break because Apple is doing it. That's not quite true because it's possible to have a couple different installations of Python on a given machine, but only one vendor Python. If you depend on the vendor's Python, any upgrade by the vendor could break your installation. If you have your own Python installation(s) you can keep them working for as long as you want or need them to, because the vendor's C ABI is stable where their Python ABI is not. -bob From bob at redivi.com Thu Feb 9 04:46:32 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 19:46:32 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <06Feb8.192503pst."58633"@synergy1.parc.xerox.com> Message-ID: <28932E3F-0850-4E96-AB9A-1935D8E8C5AD@redivi.com> On Feb 8, 2006, at 7:33 PM, Kevin Ollivier wrote: > On Feb 8, 2006, at 7:24 PM, Bill Janssen wrote: > >>> I am one of those too, of course, but I do know a lot of Mac users >>> who spend most of their time in applications like Photoshop, >>> Dreamweaver, BBEdit, etc. and rarely venture towards the Terminal. >>> Not quite the same audience, but at least some of them would be >>> potential Python users by way of appscript or web development tools. >> >> Sure, that make perfect sense. >> >>>> But my point was simply that it seems hard to be a Mac user these >>>> days >>>> without some basic use of the Terminal. >>> >>> That's not true at all. >> >> OK, I'm probably the wrong person to assess that. >> >> So it seems that a old Unix-style Python program which reads from >> stdin (or a file or a tty) and writes to stdout would be difficult to >> explain to someone who has never used a command line. And there's >> essentially no way to get Idle started without using a command line. > > What about an app bundle that just starts IDLE? But if we're going to have them download something, why not a better suite of tools to begin with? -bob From berkowit at silcom.com Thu Feb 9 04:44:49 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Wed, 08 Feb 2006 19:44:49 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Message-ID: On 2/8/06 7:33 PM, "Kevin Ollivier" wrote: > What about an app bundle that just starts IDLE? Or you could just supply an AppleScript applet installer to double-click. All it needs, apparently, is do shell script "pythonw -c 'import idlelib.idle'" All OS X users have 'do shell script' built in. All OS 10.4 users have pythonw built in. They don't even have to look at the code, just double-click the file (which can be disguised with a suitable icon by pasting one into Get Info in the Finder, if you want). -- Paul Berkowitz From janssen at parc.com Thu Feb 9 05:29:34 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 8 Feb 2006 20:29:34 PST Subject: [Pythonmac-SIG] My stab at a new page Message-ID: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. This is the kind of thing I'd like to see replace the page at http://www.python.org/download/download_mac.html. Bill From bob at redivi.com Thu Feb 9 07:38:22 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 22:38:22 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: Message-ID: On Feb 8, 2006, at 7:40 PM, Charles Hartman wrote: > > Well, so PythonIDE is dead. (It hasn't been well for a long time.) > > How ready-for-prime-time is IDLE? What drawbacks are there to > recommending it to beginners? What can't you do? Do I remember that > it uses TKinter? Does it make wx impossible to use? I haven't used > it, so I'm asking out of ignorance, not simply rhetorically. IDLE does use tkinter. Being a Tk based UI it will not follow Mac conventions and its going to act a little quirky Since IDLE runs its shells and scripts in subprocesses, wx (or any other GUI framework) is possible to use if and only if IDLE was started via "pythonw". If IDLE is started with just "python" then wx will not operate. I believe the Tk that ships with OS X 10.4 does have the CPS hack that allows it to work even if started with python, but that doesn't help wx at all. -bob From ronaldoussoren at mac.com Thu Feb 9 07:40:55 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 9 Feb 2006 07:40:55 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> <7692CE6C-D0DD-4277-85B5-A82EE07B13! 75@mac! !.com> Message-ID: On 8-feb-2006, at 22:45, Bill Noon wrote: > > On Feb 8, 2006, at 4:16 PM, Ronald Oussoren wrote: > >> >> Is that this omniorb: http://omniorb.sourceforge.net/ ? > > Yep. > >> >> Do you by any change have a binary of the python extension for >> Panther lying about? (for python 2.4 of course). A script that would >> tell if the c++ constructors would also be nice :-) > OmniOrb is not a good, simple test case. It creates about a half a > dozen libraries and several python modules. Building on MacOSX > isn't very clean. That's not really a problem, I need some kind of test to determine if we can get away with loading C++ code compiled with g++-3.3 into a python build with gcc 4. Boost might also be an option for testing. > > The only version I have for Panther was built against python 2.3 > (and static libraries). > > If you have a version of python2.4 for Panther you want me to test, > we can try it that way. I'd like to have a binary that was build with an existing python 2.4 (Bob's "unofficial official" build) on Panther, but don't bother building just for this test; I'll reboot into 10.3 to build some test code. Ronald > >> >> Ronald >> >>> >>> --Bill Noon >>> >> > > --Bill > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060209/2be298b7/attachment.bin From ronaldoussoren at mac.com Thu Feb 9 07:42:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 9 Feb 2006 07:42:13 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060200h251545e4y2d8c2546469a3ad7@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> <685A7AAB-2CD0-4C5B-A711-0F37ED442C2B@mac.com> Message-ID: On 8-feb-2006, at 22:31, Bob Ippolito wrote: >> BTW3. What is the plan w.r.t. merging our patches back into the >> python repository? I'd like to get all of this into Python 2.5 at >> the very least. > > My plan is to make everything work first, and then worry about > upstream. I don't have time to go through that process and this > one in parallel. Fine by me, it's better to have something that works right before trying to please the folks on python-dev :-) Ronald > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060209/f5852266/attachment.bin From bob at redivi.com Thu Feb 9 07:44:55 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 8 Feb 2006 22:44:55 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 8, 2006, at 8:29 PM, Bill Janssen wrote: > I've made up a sample page, at http://bill.janssen.org/new- > macpython-page.html. > > This is the kind of thing I'd like to see replace the page at > http://www.python.org/download/download_mac.html. import statements don't use quotes (import idlelib.idle, not import "idlelib.idle") OS X 10.3 did not ship with Tkinter so IDLE isn't going to work there OS X 10.2 did not ship with a usable version of Python. Python 2.2.0, especially the way they built it, is nearly unusably bug- ridden. It's hardly even worth mentioning that Python shipped with that release of the OS. If they don't use "pythonw" to start Python, they won't be able to talk to GUI stuff except for what happens to be tkinter based. The instructions will have to say to use pythonw. Though IDLE and other tkinter-based stuff will work due to a hack that's in that release of Tk (the one that ships with 10.4, anyway), nothing else will, so you really need to tell people to use pythonw. pythonw is perfectly good at running every Python app, so there's no reason to have them run anything else for any purpose... -bob From ronaldoussoren at mac.com Thu Feb 9 07:44:58 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 9 Feb 2006 07:44:58 +0100 Subject: [Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff In-Reply-To: <086569E9-771E-4D2A-B306-2931DAA1AB69@unsw.edu.au> References: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> <5FDFB8BC-4A33-4EEE-955F-0DEC3BFB3B3B@redivi.com> <83BA29D9-2158-41AB-A4AE-4E011BCF750F@unsw.edu.au> <87CA49C9-140C-4C20-8CA7-7ED81C473E2C@mac.com> <086569E9-771E-4D2A-B306-2931DAA1AB69@unsw.edu.au> Message-ID: On 9-feb-2006, at 1:50, Bill Northcott wrote: > On 09/02/2006, at 5:45 AM, Ronald Oussoren wrote: >>> #define _POSIX_C_SOURCE 200112L >>> #include >>> int main () >>> { >>> } >> >> Is that a valid POSIX program? Don't define _POSIX_C_SOURCE if you >> use >> system libraries that are not part of POSIX. > > It is valid if somewhat minimal program in both C and C++. As far > as I understand the Posix etc. standards, they define system > library functions which must be provided, along with their > functional definitions and the headers which must be used to access > them. A C program is valid POSIX code if it uses the POSIX > definitions of the system functions and includes. You can use any > other libraries you like as long as they do not use any of the > POSIX function names. So, yes I think that is valid POSIX C code. > > The real problem here is that C++ is not part of the POSIX > standard. So no C++ program can be POSIX compliant. That is why > the 'correct' tm fix is to conditionalise the POSIX defines with > #ifndef __cplusplus or an equivalent. I have now established that > if that is done all of WXPython will build perfectly happily. This has nothing to do with C++ vs. C, but that Carbon/Carbon.h is not POSIX compliant (and that's likely also true for other Apple headers). Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060209/7c4670e5/attachment.bin From david.warde.farley at utoronto.ca Thu Feb 9 07:50:25 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Thu, 9 Feb 2006 01:50:25 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: <1B48631B-E5BE-4562-BB8F-2AB1E8A4BA88@utoronto.ca> This is a great start. Do you think it might be a good idea to put this up on the PythonMac wiki so that others on the list can contribute? I can foresee this turning into a really good resource. - Dave On 8-Feb-06, at 11:29 PM, Bill Janssen wrote: > I've made up a sample page, at http://bill.janssen.org/new- > macpython-page.html. > > This is the kind of thing I'd like to see replace the page at > http://www.python.org/download/download_mac.html. > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From w.northcott at unsw.edu.au Thu Feb 9 13:11:43 2006 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Thu, 9 Feb 2006 23:11:43 +1100 Subject: [Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff In-Reply-To: References: <286B74E0-7FA2-4AAE-9F08-90E590BA2F2F@unsw.edu.au> <5FDFB8BC-4A33-4EEE-955F-0DEC3BFB3B3B@redivi.com> <83BA29D9-2158-41AB-A4AE-4E011BCF750F@unsw.edu.au> <87CA49C9-140C-4C20-8CA7-7ED81C473E2C@mac.com> <086569E9-771E-4D2A-B306-2931DAA1AB69@unsw.edu.au> Message-ID: <65995FD5-98BF-4691-9883-0F19224015C0@unsw.edu.au> On 09/02/2006, at 5:44 PM, Ronald Oussoren wrote: > > This has nothing to do with C++ vs. C, but that Carbon/Carbon.h is > not POSIX compliant (and that's likely also true for other Apple > headers). Why do you say it is not POSIX compliant? As my test program demonstrates, it works correctly in a C program with the POSIX feature macro defined. That is what the standard requires. So why do you say it is not compliant? Bill From charles.hartman at conncoll.edu Thu Feb 9 14:18:47 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 9 Feb 2006 08:18:47 -0500 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: Message-ID: <09FFB94B-291D-42A4-95E1-C7CEC45C0061@conncoll.edu> I have an IDLE.app on my 10.4 machine. Since I haven't really used it, I can't remember if it came with Tiger, or showed up when I installed Python 2.4 -- does everyone with OS 10.4 have it? Is it just a shell to call idlelib? If so, is there any way to tell whether it calls with python or with pythonw? Charles On Feb 9, 2006, at 1:38 AM, Bob Ippolito wrote: > Since IDLE runs its shells and scripts in subprocesses, wx (or any > other GUI framework) is possible to use if and only if IDLE was > started via "pythonw". If IDLE is started with just "python" then > wx will not operate. I believe the Tk that ships with OS X 10.4 > does have the CPS hack that allows it to work even if started with > python, but that doesn't help wx at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060209/5c7cdf47/attachment.htm From sw at wordtech-software.com Thu Feb 9 14:26:27 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu, 09 Feb 2006 08:26:27 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <06Feb8.192503pst."58633"@synergy1.parc.xerox.com> Message-ID: <43EB4303.2040000@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Ollivier wrote: > > > What about an app bundle that just starts IDLE? +1 on this idea. That's the way IDLE currently ships, and I think it's very useful. I myself don't like running Python GUI applications from the command-line: I like to see an application name in the menu, not "Python." That's more newbie-friendly as well. (This is how I packaged apps when I was shipping SPE for the Mac, for instance. It's also how Robin Dunn packages the demos for wxPython.) No one has said anything about the "applet" packaging concept as we discuss moving forward with this stuff. I'm assuming that this is because the tools based on WASTE aren't going to be ported (such as applet builder), and also because "applet" is part of Bundlebuilder, which has been deprecated in favor of py2app. However, the "applet" method is really an easy way to package apps that have the external dependencies already installed on one's machine: I always use the "buildapplet.py" script that came with the older MacPython distributions. This is a good use case for IDLE, as its dependencies (tkinter) come by default on the Mac. Using py2app or its variants would be overkill here. Will the applet still be available as a packaging model, deprecated, or obsoleted by the changes that are coming? - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD60MCJmdQs+6YVcoRApLmAJ9qegJmORlNx/x3Elwq9Rt+GyNNmgCcCsHm qABbn9rkWErW9CSqGrOt4ys= =FUXP -----END PGP SIGNATURE----- From hengist.podd at virgin.net Thu Feb 9 16:34:34 2006 From: hengist.podd at virgin.net (has) Date: Thu, 9 Feb 2006 15:34:34 +0000 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> Message-ID: Ronald Oussoren wrote: >>Mac OS X 10.5 will surely ship with at least 2.4.2, > >Maybe, maybe not. Who knows what apple will do? ;-) ;-) My bet is they start the Ascent to Transcendence any day now... >This is a very good reason for not pointing newbies to the system python >on pythonmac.org: unless anyone steps up to *seriously* support the >system python there won't be properly packages extension packages for >the system python. My concern would be that someone steps up with the noble intent of supporting a large number of repackagings, only for their enthusiasm to wear off after a few months after they realise how much long-term work they've committed themselves to. (i.e. Don't bite off more than you can chew.) The sensible thing would probably be to work out what the dozen most-used 3rd-party packages for casual users are likely to be, and commit to maintaining pkgs those for the next year or two. A modest number like that shouldn't create too onerous a workload; enough for the default Python to keep casual users happy without turning into an excessive duplication of effort. e.g. I'm happy to continue providing both 2.3 and 2.4 binary installers for appscript as it's no more work for me, so that's one of the dirty dozen covered right there. As has been said elsewhere, if the aim is to market Python to a broad audience then it's at least as much an exercise in influencing perceptions as technical merit. And often folk just don't like to be presented with a long list of things to download and install before they're able to do anything. e.g. Back before Nick stepped in with his all-in-one installer, some folks fair moaned about having to install a half-dozen simple distutils packages in order to use appscript. Even though the latter approach only took an extra minute or two in practice, in the end it was simpler and much more effective to cater to their "unreasonable" demands than lecture them on why "they" were "wrong". Like I say, perceptions count. And first impressions more than anything else. Technical arguments alone aren't enough; things have to *look* and *sound* simple too. >I do support system python for PyObjC, but even there it is mostly >"lets check if it still works" around release time. For day-to-day work >I'm using a framework installation of Python 2.4. And it's all much appreciated. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From janssen at parc.com Thu Feb 9 18:37:23 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 09:37:23 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Wed, 08 Feb 2006 20:29:34 PST." <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: <06Feb9.093729pst."58633"@synergy1.parc.xerox.com> I fixed a couple of the problems Bob noted, and added some links to pictures (how to start the Terminal, and what the IDLE IDE looks like). I'm conflicted about "pythonw". On the one hand, this works for everything, whereas "python" doesn't. On the other hand, why isn't this just what "python" invokes, and how do we explain that to people? Another example of the surface complexity of the MacPython infrastructure. Bill > I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. > > This is the kind of thing I'd like to see replace the page at > http://www.python.org/download/download_mac.html. > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From sw at wordtech-software.com Thu Feb 9 18:49:59 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu, 09 Feb 2006 12:49:59 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.093729pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.093729pst."58633"@synergy1.parc.xerox.com> Message-ID: <43EB80C7.9090806@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Janssen wrote: > > I'm conflicted about "pythonw". On the one hand, this works for > everything, whereas "python" doesn't. On the other hand, why isn't > this just what "python" invokes, and how do we explain that to people? > Another example of the surface complexity of the MacPython > infrastructure. > "pythonw" invokes GUI applications, "python" invokes console applications. When installing an extension, I don't type "pythonw setup.py install." - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD64DHJmdQs+6YVcoRAuAZAJ9QkZVwkcl4owAMzWkNiRXQvvKNzgCfRD56 NrogiTxFiOOkz7vvd+3psM0= =tQys -----END PGP SIGNATURE----- From Benjamin.Schollnick at xerox.com Thu Feb 9 18:50:17 2006 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Thu, 9 Feb 2006 12:50:17 -0500 Subject: [Pythonmac-SIG] My stab at a new page Message-ID: <266589E1B9392B4C9195CC25A07C73B90183D26F@usa0300ms04.na.xerox.net> > I fixed a couple of the problems Bob noted, and added some > links to pictures (how to start the Terminal, and what the > IDLE IDE looks like). Looks good... But I would suggest... Python on the Macintosh You're in luck! Python comes pre-installed on Apple's Macintosh series of computers that run OS X, for versions of OS X greater than 10.1. is a little clumsy... How about.... Python on the Macintosh Any Mac OS X (10.1+) users are in luck! Python comes pre-installed on every Macintosh that is running OS X 10.1 or higher. Since Apple has nicely included Python with their Operating systems you can get started simply by opening a terminal window (see below). Once you have experimented with Python you may want to consider upgrading to a newer version of Python. For details on upgrading, see "If you want a newer version of Python" below. - Benjamin From janssen at parc.com Thu Feb 9 19:52:09 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 10:52:09 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 09:49:59 PST." <43EB80C7.9090806@wordtech-software.com> Message-ID: <06Feb9.105219pst."58633"@synergy1.parc.xerox.com> > "pythonw" invokes GUI applications, "python" invokes console > applications. When installing an extension, I don't type "pythonw > setup.py install." But you could. No, my conceptual problem is just that you shouldn't need that extra "w", and once you start explaining why it's there, there's no good place to stop. You start bushwhacking into a thicket of MacPython complexity which scares people away. Bill From chrisporter9 at wi.rr.com Thu Feb 9 20:08:10 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Thu, 9 Feb 2006 13:08:10 -0600 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.093729pst.58633@synergy1.parc.xerox.com> Message-ID: > I fixed a couple of the problems Bob noted, and added some links to > pictures (how to start the Terminal, and what the IDLE IDE looks > like). I like it. > I'm conflicted about "pythonw". On the one hand, this works for > everything, whereas "python" doesn't. On the other hand, why isn't > this just what "python" invokes, and how do we explain that to people? Is it used a lot? Then you would probably need to describe both, with something like: "You can run a Python interpreter by double-clicking on Applications / Utilities / Terminal, then typing "python" or "pythonw" into the window that opens up. Typing "pythonw" will prompt Terminal to provide the subsequent python prompt to.... (do whatever it is that pythonw does)" Otherwise, the normal "python" prompts will not be able to (do whatever it is that pythonw does) Most people find that typing "pythonw" gives them more options they find useful when programming in python." > Another example of the surface complexity of the MacPython > infrastructure. I would suggest this: "On MacOS X 10.4 (Tiger) you can even bring up a simple IDE by typing, at the prompt," to "On MacOS X 10.4 (Tiger) you can even bring up a simple Integrated Developement Environment (IDE) by typing, at the prompt," > Bill > > > I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html From sw at wordtech-software.com Thu Feb 9 20:32:55 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu, 09 Feb 2006 14:32:55 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: <43EB98E7.1080801@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Janssen wrote: > I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. > > This is the kind of thing I'd like to see replace the page at > http://www.python.org/download/download_mac.html. > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > OK, going through the page line-by-line: 1. Link to the "Macintosh Library Module": A lot of that stuff will be rendered obsolete the minute Bob releases the universal build of MacPython. PythonIDE, Package Manager, etc.: not gonna be included. At a minimum, you should note that this stuff is "legacy." Also, who writes this stuff and where should a bug be filed? 2. Ditto for "Apple Events." Does anyone use gensuitemodule or even know what it means? (I don't.) I don't use appscripting, but I do know enough to know that it's pretty much the standard way (by now) of accessing Apple Events? has, what do you think? 3. The stuff on launching IDLE from Terminal: doesn't work for me. I get these error messages: Warning: configHandler.py - IdleConf.GetOption - problem retrieving configration option 'enable' from section 'CodeContext'. returning default value: 1 Warning: configHandler.py - IdleConf.GetOption - problem retrieving configration option 'enable' from section 'CodeContext'. returning default value: 1 Warning: configHandler.py - IdleConf.GetOption - problem retrieving configration option 'enable' from section 'CodeContext'. returning default value: 1 Failed to import extension: CodeContext If I'm a newbie, I'm going to go, "Huh?", then "shrug," and move on to Realbasic. There needs to be something double-clickable there for a newbie to use. PythonIDE, though it had many flaws, was useful this way. BTW, what happened to PyOXIDE? It had major bugs, but was promising as a "next-generation" basic IDE for Python development on the Mac. IDLE will do in a pinch, but only if it can be started in a standard (non-terminal) way. 4. Maintainer: does Python on the Mac even have an official maintainer anymore? Has Jack Jansen resigned? Is it "maintainer-by-committee"? I can't help but think this is part of the reason Python seems adrift as a Mac development platform: the group is having a hard time even agreeing on who it's serving (hard-core developers? newbies?). The outstanding technical support we are getting from the experts such as Bob, for instance in terms of building universal binaries, is getting the most essential daily tasks done; but this isn't the same as having a leadership focus to actually make strategic decisions about Python on the Mac platform. I mention this because I think it's important to state accurately how Python on the Mac is maintained: by a loose group of experts rather than a dedicated maintainer. That will help people know what to expect. - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD65jmJmdQs+6YVcoRAvDvAJ0cq+eirvmVEY+T2DrGxCVYuEHILACfdVzB WJNO6v5sV8sJ0/wjhlgdhjk= =LSrM -----END PGP SIGNATURE----- From bob at redivi.com Thu Feb 9 20:41:58 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 11:41:58 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.105219pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.105219pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 9, 2006, at 10:52 AM, Bill Janssen wrote: >> "pythonw" invokes GUI applications, "python" invokes console >> applications. When installing an extension, I don't type "pythonw >> setup.py install." > > But you could. > > No, my conceptual problem is just that you shouldn't need that extra > "w", and once you start explaining why it's there, there's no good > place to stop. You start bushwhacking into a thicket of MacPython > complexity which scares people away. If we recommend that the user installs a particular framework build of Python, we could distribute it such that python and pythonw are indistinguishable. This issue then disappears. -bob From bob at redivi.com Thu Feb 9 20:48:43 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 11:48:43 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43EB98E7.1080801@wordtech-software.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> <43EB98E7.1080801@wordtech-software.com> Message-ID: On Feb 9, 2006, at 11:32 AM, Kevin Walzer wrote: > 4. Maintainer: does Python on the Mac even have an official maintainer > anymore? Has Jack Jansen resigned? Is it "maintainer-by-committee"? I > can't help but think this is part of the reason Python seems adrift > as a > Mac development platform: the group is having a hard time even > agreeing > on who it's serving (hard-core developers? newbies?). The outstanding > technical support we are getting from the experts such as Bob, for > instance in terms of building universal binaries, is getting the most > essential daily tasks done; but this isn't the same as having a > leadership focus to actually make strategic decisions about Python on > the Mac platform. I mention this because I think it's important to > state > accurately how Python on the Mac is maintained: by a loose group of > experts rather than a dedicated maintainer. That will help people know > what to expect. Python does not currently have an official Mac maintainer. Jack hasn't officially resigned, but he has been "too busy" for probably a few years now. I'm too busy to do real maintenance. Nobody else has stepped up. It's currently somewhat of a "maintainer-by-necessity". The people doing the maintenance are mostly just Ronald and I, with bits and pieces filled by other members of the Python development community that happen to use Mac OS X as well. The people currently doing maintenance tasks are doing it mostly because they need it done for their own work. Once it's fixed enough for them to use, it sits and waits until there's another problem. Clearly the current distribution and the people responsible for it aren't going very far to serve newbies... -bob From charles.hartman at conncoll.edu Thu Feb 9 20:55:10 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 9 Feb 2006 14:55:10 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb9.105219pst."58633"@synergy1.parc.xerox.com> Message-ID: That's exactly the kind of fix that -- together with a handful of others -- could make this make-over work. Incorporating the TigerPython24Fix and TigerPython23Compat patches would be another small, huge step. Can the 2.4 installer look at the system and decide which of these is needed? The third piece is a front-end script (part of the installer?? that would be ideal) that checks the user's shell (bash, tcsh, etc) and, perhaps after asking permission, adds the relevant thing to the path. Charles Charles On Feb 9, 2006, at 2:41 PM, Bob Ippolito wrote: > > On Feb 9, 2006, at 10:52 AM, Bill Janssen wrote: > >>> "pythonw" invokes GUI applications, "python" invokes console >>> applications. When installing an extension, I don't type "pythonw >>> setup.py install." >> >> But you could. >> >> No, my conceptual problem is just that you shouldn't need that extra >> "w", and once you start explaining why it's there, there's no good >> place to stop. You start bushwhacking into a thicket of MacPython >> complexity which scares people away. > > If we recommend that the user installs a particular framework build > of Python, we could distribute it such that python and pythonw are > indistinguishable. This issue then disappears. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Thu Feb 9 20:56:58 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 11:56:58 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <09FFB94B-291D-42A4-95E1-C7CEC45C0061@conncoll.edu> References: <09FFB94B-291D-42A4-95E1-C7CEC45C0061@conncoll.edu> Message-ID: <6E39543A-869C-41C9-9450-5C552D91A881@redivi.com> On Feb 9, 2006, at 5:18 AM, Charles Hartman wrote: > I have an IDLE.app on my 10.4 machine. Since I haven't really used > it, I can't remember if it came with Tiger, or showed up when I > installed Python 2.4 -- does everyone with OS 10.4 have it? Is it > just a shell to call idlelib? If so, is there any way to tell > whether it calls with python or with pythonw? It came with the MacPython 2.4 that you installed. It's a bundlebuilder applet, so it's effectively run with pythonw. -bob From bob at redivi.com Thu Feb 9 21:04:14 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 12:04:14 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb9.105219pst."58633"@synergy1.parc.xerox.com> Message-ID: <5EDEC5BE-F8A8-489D-83D7-9D01FB40D8CA@redivi.com> On Feb 9, 2006, at 11:55 AM, Charles Hartman wrote: > That's exactly the kind of fix that -- together with a handful of > others -- could make this make-over work. > > Incorporating the TigerPython24Fix and TigerPython23Compat patches > would be another small, huge step. Can the 2.4 installer look at > the system and decide which of these is needed? TigerPython24Fix is irrelevant for the next build. TigerPython23Compat only allows the system Python 2.3 to use packages targetted for the system Python 2.3 on Mac OS X 10.3. > The third piece is a front-end script (part of the installer?? that > would be ideal) that checks the user's shell (bash, tcsh, etc) and, > perhaps after asking permission, adds the relevant thing to the path. Yeah, this would likely be a post-install script in a sub-pkg that the user could disable using the "Customize" function. It would happen by default. It's somewhat difficult to present the user a forced choice during the installer, especially considering they might be doing it headless (e.g. with Apple Remote Desktop, or as a sub-pkg of some larger mpkg), with /usr/sbin/installer, etc. > Charles > > > Charles > On Feb 9, 2006, at 2:41 PM, Bob Ippolito wrote: > >> >> On Feb 9, 2006, at 10:52 AM, Bill Janssen wrote: >> >>>> "pythonw" invokes GUI applications, "python" invokes console >>>> applications. When installing an extension, I don't type "pythonw >>>> setup.py install." >>> >>> But you could. >>> >>> No, my conceptual problem is just that you shouldn't need that extra >>> "w", and once you start explaining why it's there, there's no good >>> place to stop. You start bushwhacking into a thicket of MacPython >>> complexity which scares people away. >> >> If we recommend that the user installs a particular framework build >> of Python, we could distribute it such that python and pythonw are >> indistinguishable. This issue then disappears. >> >> -bob >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > From rodneys at io.com Thu Feb 9 21:09:28 2006 From: rodneys at io.com (Rodney Somerstein) Date: Thu, 9 Feb 2006 15:09:28 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: At 8:29 PM -0800 2/8/06, Bill Janssen wrote: >I've made up a sample page, at >http://bill.janssen.org/new-macpython-page.html. > >This is the kind of thing I'd like to see replace the page at >http://www.python.org/download/download_mac.html. Bill, As the sort of somewhat sophisticated novice python developer (how is that for a contradiction of terms?) that you folks seem to be targeting, I really like this page. It could use a little bit of cleaning up, such as possibly describing why to use IDLE, how using a newer version of Python can help the user, etc. It is a great start. I look forward to seeing something as straightforward as this replacing the current page. Now, what I really want to see added is something that explains how I can write a program in Python on the Mac and create standalone applications that can run on someone else's computer without them having to install anything else. The descriptions of packaging for Python that I have read here are fairly arcane and not at all straightforward for new developers. As much as I like the general idea of Python, this is the one thing that seems to make the language not ready for end-user applications. It might seem that this isn't Mac specific. But, since the packaging of Python apps on the Mac seems to be different than on other platforms, having a link to it from the main page would be a useful thing. It could certainly be far down the page rather than right at the beginning. Even better would be a discussion of how to move such apps to other operating systems as well. Python may be more elegant than Java, but I can easily give someone a Java app to run on their computer. I'm not confident I could do this for much beyond helloworld with Python and expect it to run since there wouldn't likely be the libraries that I need. Thanks, -Rodney From janssen at parc.com Thu Feb 9 21:25:35 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 12:25:35 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 11:32:55 PST." <43EB98E7.1080801@wordtech-software.com> Message-ID: <06Feb9.122544pst."58633"@synergy1.parc.xerox.com> > 1. Link to the "Macintosh Library Module": A lot of that stuff will be > rendered obsolete the minute Bob releases the universal build of > MacPython. PythonIDE, Package Manager, etc.: not gonna be included. At a > minimum, you should note that this stuff is "legacy." Also, who writes > this stuff and where should a bug be filed? > > 2. Ditto for "Apple Events." Does anyone use gensuitemodule or even know > what it means? (I don't.) I don't use appscripting, but I do know enough > to know that it's pretty much the standard way (by now) of accessing > Apple Events? has, what do you think? Hey, I'm linking to the official documentation. That's what people will use, till it changes. All this other stuff scattered around is blue-sky wild-ass future, till it's documented. You can file documentation bugs at http://sourceforge.net/bugs/?group_id=5470. I'd suggest category "Documentation", group "Platform-specific". Bill From janssen at parc.com Thu Feb 9 21:38:01 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 12:38:01 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 11:48:43 PST." Message-ID: <06Feb9.123809pst."58633"@synergy1.parc.xerox.com> > Python does not currently have an official Mac maintainer. Bingo! And no one has stepped up to document the amazing torrent of productive activity since Jack "retired". As a result, the useful pieces are scattered all over, the official documentation is wildly out of date, and there's not even a useful web page for MacPython. Add to this the fact that the pre-installed Python is widely held to be useless by well-respected and influential members of the community. A parochial and self-defeating assessment, I think. By the way, is anyone a designated point-man to work with Apple on the release it packages for the next OS? Is there anyone from Apple even on this list? > Clearly the current distribution and the people responsible for it > aren't going very far to serve newbies... It's worse than that, IMO. I've got a great deal of respect and appreciation for those, like Bob and Ronald, working hard on advancing the technology pieces. Great work, just what we all need! But unless there's some effective delivery vehicle for getting that work to the customer, much of it will be wasted. Bill From bob at redivi.com Thu Feb 9 22:14:42 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 13:14:42 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.123809pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.123809pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 9, 2006, at 12:38 PM, Bill Janssen wrote: >> Python does not currently have an official Mac maintainer. > > Bingo! And no one has stepped up to document the amazing torrent of > productive activity since Jack "retired". As a result, the useful > pieces are scattered all over, the official documentation is wildly > out of date, and there's not even a useful web page for MacPython. > > Add to this the fact that the pre-installed Python is widely held to > be useless by well-respected and influential members of the community. > A parochial and self-defeating assessment, I think. It is useless to me. I can't build redistributable applications with it, and it has VM bugs that cause some of my programs to crash without reason. It's a support nightmare because it's different for every release of OS X. 10.3 has 2.3.0 with just CoreGraphics, 10.4 has 2.3.5 with wx, CoreGraphics and tkinter, who knows what 10.5 will have. If we tell everyone to use a particular 2.4.2 release then we don't have to deal with any of that nonsense. It's also showing its age -- some software packages are starting to require or strongly recommend Python 2.4 for usage (e.g. TurboGears). The minimal effort it takes to use a third party installation of Python is well worth it, and it becomes more useful as time goes on. Doubly so now that Leopard is approaching, because users can upgrade without losing all of their Python work to major version upgrade death. It's great and convenient that Apple ships a Python interpreter, but it's only useful for running a subset of UNIX based Python applications and scripts. I don't think it should even be a consideration for people writing software with Python. > By the way, is anyone a designated point-man to work with Apple on the > release it packages for the next OS? Is there anyone from Apple even > on this list? I don't know if anyone in Cupertino is on this list, but I have contacts at Apple. I was more or less the point person for the last release. >> Clearly the current distribution and the people responsible for it >> aren't going very far to serve newbies... > > It's worse than that, IMO. > > I've got a great deal of respect and appreciation for those, like Bob > and Ronald, working hard on advancing the technology pieces. Great > work, just what we all need! But unless there's some effective > delivery vehicle for getting that work to the customer, much of it > will be wasted. It's not a waste because the work done helps me accomplish what I need to do. I do it because I need it to be done, not because I want to help people. I do a lot of things to help people, but that's rarely ever my primary motivation in the context of open source. There's an open invitation for someone to coddle new users and maintain a straightforward web presence. We all know that it would be beneficial, and it's time for someone to step up and do it already. It's been discussed ad nauseam for the past few years, but talking apparently doesn't make anything happen. -bob From bob at redivi.com Thu Feb 9 22:20:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 13:20:00 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 9, 2006, at 12:09 PM, Rodney Somerstein wrote: > At 8:29 PM -0800 2/8/06, Bill Janssen wrote: >> I've made up a sample page, at >> http://bill.janssen.org/new-macpython-page.html. >> >> This is the kind of thing I'd like to see replace the page at >> http://www.python.org/download/download_mac.html. > > Bill, > > As the sort of somewhat sophisticated novice python developer (how is > that for a contradiction of terms?) that you folks seem to be > targeting, I really like this page. It could use a little bit of > cleaning up, such as possibly describing why to use IDLE, how using a > newer version of Python can help the user, etc. It is a great start. > > I look forward to seeing something as straightforward as this > replacing the current page. > > Now, what I really want to see added is something that explains how I > can write a program in Python on the Mac and create standalone > applications that can run on someone else's computer without them > having to install anything else. The descriptions of packaging for > Python that I have read here are fairly arcane and not at all > straightforward for new developers. As much as I like the general > idea of Python, this is the one thing that seems to make the language > not ready for end-user applications. > > It might seem that this isn't Mac specific. But, since the packaging > of Python apps on the Mac seems to be different than on other > platforms, having a link to it from the main page would be a useful > thing. It could certainly be far down the page rather than right at > the beginning. Even better would be a discussion of how to move such > apps to other operating systems as well. Python may be more elegant > than Java, but I can easily give someone a Java app to run on their > computer. I'm not confident I could do this for much beyond > helloworld with Python and expect it to run since there wouldn't > likely be the libraries that I need. py2app is the solution for application packaging, and you must use it with a third party Python installation (e.g. Python 2.4.1) in order to come up with something that's redistributable and robust. If you happen to use the system Python, then you will produce a package that only runs on the particular release of Mac OS X that you build it with. In other words, when you or your users upgrade to Mac OS X 10.5, any system-Python built application bundle will cease to function at all. It is actually not much different than on other platforms. Many py2exe-based setup scripts work identically with py2app if you change the import statement. Mac-specific features of course require Mac- specific solutions, but the standard stuff is identical. There is some minimal documentation: http://undefined.org/python/ py2app.html Any other questions you have can probably be answered by py2exe documentation and/or this list. -bob From vinogri at mcmaster.ca Thu Feb 9 21:20:34 2006 From: vinogri at mcmaster.ca (I. Vinogradov) Date: Thu, 09 Feb 2006 15:20:34 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: On Wed, 8 Feb 2006 20:29:34 PST Bill Janssen wrote: > I've made up a sample page, at > http://bill.janssen.org/new-macpython-page.html. What about other sources for python2.4 such as fink and darwinports? Will they be frown upon or required to comply with framework installation? Regards, Ivan. From bob at redivi.com Thu Feb 9 22:33:17 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 13:33:17 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: Message-ID: <502C2180-2270-479C-92FE-8DCE8C5FB7DA@redivi.com> On Feb 9, 2006, at 12:20 PM, I. Vinogradov wrote: > On Wed, 8 Feb 2006 20:29:34 PST > Bill Janssen wrote: >> I've made up a sample page, at >> http://bill.janssen.org/new-macpython-page.html. > > What about other sources for python2.4 such as fink and darwinports? > Will they be frown upon or required to comply with framework > installation? It's the job of Fink or DarwinPorts to sustain their Python communities. There are already too many choices, I'd really like to avoid even more confusion. Also, the topic of Fink and DarwinPorts rarely ever comes up on this list, so there isn't much reason for us to bother. The way that Python is used in such an environment is closer to how it is used on a Linux or BSD distribution, given that it has managed packages and is only usable from a shell. They are also like a separate operating system, typically the only library they use from Mac OS X is libSystem -- they duplicate almost everything else. I don't know if anything has changed in the past two years, but neither offered a framework build last I checked -- which means that neither are capable of running GUI applications from the shell (unless X11 counts). You can still technically use them to build GUI apps via py2app, but I certainly wouldn't recommend either of those platforms for that purpose. If you do happen to build a redistributable app with DarwinPorts or Fink, you'll essentially be redistributing an OS and a Python interpreter because those systems have their own versions of almost everything. -bob From janssen at parc.com Thu Feb 9 22:39:28 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 13:39:28 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 12:09:28 PST." Message-ID: <06Feb9.133934pst."58633"@synergy1.parc.xerox.com> > Now, what I really want to see added is something that explains how I > can write a program in Python on the Mac and create standalone > applications that can run on someone else's computer without them > having to install anything else. Great idea, Rodney. I think we probably need a number of pages like this, kind of an FAQ set. I think the main page should just cover one or two things (how to run python, how to upgrade), and lots of pointers to these pages. Each of these should be fairly clear, with pointers off to more complicated explanations. Here's the start of a list: 1) What's the difference between "python" and "pythonw"? 2) What's the advantage of upgrading? 3) What do I do if I want to use pre-built packages? 4) How do I use the Apple GUI toolkit from Python? 5) How do I use Apple Events from Python? 6) How do I build a real Mac application written in Python? 7) How do I install extra modules, like PIL, for the system Python? 8) What IDE's are available, and what are their relative merits? Bill From janssen at parc.com Thu Feb 9 22:48:53 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 13:48:53 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 13:14:42 PST." Message-ID: <06Feb9.134859pst."58633"@synergy1.parc.xerox.com> > It is useless to me. That's what I mean by parochial. Bob, I completely understand and sympathize with what you are saying here. And for your purposes, these are completely legitimate complaints. But there are lots of "pure Unix" programs which it works quite well for. I do a lot of text processing, web-page re-writing, web spidering, etc. which works fine with the pre-installed Python. I do image0-processing with PIL and PDF generation with ReportLab which works fine. And to not support -- even celebrate -- those uses is, IMO, self-defeating. > The minimal effort it takes to use a third party installation of > Python is well worth it, and it becomes more useful as time goes on. > Doubly so now that Leopard is approaching, because users can upgrade > without losing all of their Python work to major version upgrade death. To begin with, I don't see a stability in the current state of MacPython that gives me confidence in this assurance. But I agree that the effort of installation is minimal, and should be encouraged. Should we officially encourage Apple not to include Python in their next release? That would solve lots of these problems, I think. Bill From bob at redivi.com Thu Feb 9 23:05:01 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 14:05:01 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.134859pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.134859pst."58633"@synergy1.parc.xerox.com> Message-ID: <76582A9A-DD00-4461-81A3-AB7A21030A74@redivi.com> On Feb 9, 2006, at 1:48 PM, Bill Janssen wrote: >> It is useless to me. > > That's what I mean by parochial. > > Bob, I completely understand and sympathize with what you are saying > here. And for your purposes, these are completely legitimate > complaints. I'd say pragmatic, not parochial. I understand your concerns but why should we spend our precious and limited resources bothering with a Python distribution that can only support a subset of uses. If we ignore the vendor's interpreter then our documentation becomes MUCH simpler as there will be one -- and preferably only one -- way to do it: install a Python interpreter that is recent and can run the full scope of Python applications. We also get to ignore the issues of which version of Mac OS X they are using because 10.3 and 10.4 will behave the same, and we have the opportunity to fix the issues that constantly plague users such as python vs pythonw (we can simply make the symlinks in /usr/local/bin both point at pythonw). > But there are lots of "pure Unix" programs which it works quite well > for. I do a lot of text processing, web-page re-writing, web > spidering, etc. which works fine with the pre-installed Python. I do > image0-processing with PIL and PDF generation with ReportLab which > works fine. And to not support -- even celebrate -- those uses is, > IMO, self-defeating. Sure, but all of that stuff works even better with a newer distribution of Python due to enhancements in the interpreter. There's no disadvantage to glossing over the fact that there is an interpreter that ships with OS X. >> The minimal effort it takes to use a third party installation of >> Python is well worth it, and it becomes more useful as time goes on. >> Doubly so now that Leopard is approaching, because users can upgrade >> without losing all of their Python work to major version upgrade >> death. > > To begin with, I don't see a stability in the current state of > MacPython that gives me confidence in this assurance. But I agree > that the effort of installation is minimal, and should be encouraged. Right now, the current state of MacPython is effectively the current state of Python itself. If you don't trust Python 2.4, how do you trust Python 2.3? Given Apple's track record of making Python worse (though they are consistently improving), your viewpoint makes no sense to me. > Should we officially encourage Apple not to include Python in their > next release? That would solve lots of these problems, I think. Our problem with Apple's bundling of Python is purely a documentation issue (and the stubbornness of those who insist that it should be used -- even celebrated -- despite its disadvantages). If we make the proposed PATH change script to the installer, we can ignore the system Python just as easily as we could if it wasn't there at all. There's little good reason for us to petition for its removal, and there's good reason for them to keep it there: they use it. -bob From bob at redivi.com Thu Feb 9 23:07:10 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 14:07:10 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.133934pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.133934pst."58633"@synergy1.parc.xerox.com> Message-ID: <32A811CA-70A0-4569-8A8A-0B224452514A@redivi.com> On Feb 9, 2006, at 1:39 PM, Bill Janssen wrote: >> Now, what I really want to see added is something that explains how I >> can write a program in Python on the Mac and create standalone >> applications that can run on someone else's computer without them >> having to install anything else. > > Great idea, Rodney. I think we probably need a number of pages like > this, kind of an FAQ set. I think the main page should just cover one > or two things (how to run python, how to upgrade), and lots of > pointers to these pages. Each of these should be fairly clear, with > pointers off to more complicated explanations. > > Here's the start of a list: > > 1) What's the difference between "python" and "pythonw"? > 2) What's the advantage of upgrading? > 3) What do I do if I want to use pre-built packages? > 4) How do I use the Apple GUI toolkit from Python? > 5) How do I use Apple Events from Python? > 6) How do I build a real Mac application written in Python? > 7) How do I install extra modules, like PIL, for the system Python? > 8) What IDE's are available, and what are their relative merits? Some of these questions are already answered by http://pythonmac.org/ wiki/FAQ -- for the questions that aren't currently answered, feel free to contribute. -bob From vinogri at mcmaster.ca Thu Feb 9 23:49:27 2006 From: vinogri at mcmaster.ca (I. Vinogradov) Date: Thu, 09 Feb 2006 17:49:27 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <502C2180-2270-479C-92FE-8DCE8C5FB7DA@redivi.com> Message-ID: On Thu, 9 Feb 2006 13:33:17 -0800 Bob Ippolito wrote: > It's the job of Fink or DarwinPorts to sustain their Python > communities. There are already too many choices, I'd really like to > avoid even more confusion. Perhaps this could be mentioned on the Bill's page to the effect that it's discouraged to use those sources. > The way that Python is used in such an environment is closer to how > it is used on a Linux or BSD distribution, given that it has managed > packages and is only usable from a shell. They are convinient in a sense that they provide one source for all the extensions for mac. IIRC both are mentioned on SciPy installation instructions. Nevermind that on Tiger SciPy install is a whole ugly can of worms. Cutting down on number of standards is a good thing in this case. Regards, Ivan. From bob at redivi.com Fri Feb 10 00:04:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 15:04:12 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: Message-ID: <1F25F6ED-C5BD-4AA9-BA70-BBABC5F4B6DA@redivi.com> On Feb 9, 2006, at 2:49 PM, I. Vinogradov wrote: > On Thu, 9 Feb 2006 13:33:17 -0800 > Bob Ippolito wrote: > >> It's the job of Fink or DarwinPorts to sustain their Python >> communities. There are already too many choices, I'd really like to >> avoid even more confusion. > > Perhaps this could be mentioned on the Bill's page to the effect that > it's discouraged to use those sources. I wouldn't explicitly discourage it.. I would rather have the page state that it's focus is to recommend and support users of a particular framework distribution of Python, and that the information may not apply to other sources of Python such as from Fink or DarwinPorts. >> The way that Python is used in such an environment is closer to how >> it is used on a Linux or BSD distribution, given that it has managed >> packages and is only usable from a shell. > > > They are convinient in a sense that they provide one source for all > the > extensions for mac. IIRC both are mentioned on SciPy installation > instructions. Nevermind that on Tiger SciPy install is a whole ugly > can > of worms. > > Cutting down on number of standards is a good thing in this case. The extension problem (on win32 and Mac OS X anyway) is going to be fixed by setuptools sooner than later... it just needs some more time. -bob From janssen at parc.com Fri Feb 10 00:51:36 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 15:51:36 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 14:49:27 PST." Message-ID: <06Feb9.155139pst."58633"@synergy1.parc.xerox.com> > > It's the job of Fink or DarwinPorts to sustain their Python > > communities. There are already too many choices, I'd really like to > > avoid even more confusion. > > Perhaps this could be mentioned on the Bill's page to the effect that > it's discouraged to use those sources. Fine by me. I try not to use either one, and advise others not to use them. Bill From janssen at parc.com Fri Feb 10 00:56:20 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 15:56:20 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 14:05:01 PST." <76582A9A-DD00-4461-81A3-AB7A21030A74@redivi.com> Message-ID: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> > If we ignore the vendor's interpreter then our documentation becomes > MUCH simpler as there will be one -- and preferably only one -- way > to do it: install a Python interpreter that is recent and can run the > full scope of Python applications. I think I'm almost convinced on this point, save for the problem of /usr/bin/python and the default PATH. > If we make > the proposed PATH change script to the installer, we can ignore the > system Python just as easily as we could if it wasn't there at all. It is extremely difficult (almost impossible) to make such scripts work properly on Unix, with the variety of shells and environments that people use. > There's little good reason for us to petition for its removal, and > there's good reason for them to keep it there: they use it. If they shipped, instead, the current version of MacPython, would that make the issue moot? That is, would you still "insist" on an upgrade before a user could use Python? Could a Mac ever ship with an acceptable pre-installed Python? If not, perhaps the solution for Apple is to move /usr/bin/python to some other spot, like /usr/libexec/, or some such place. Bill From bob at redivi.com Fri Feb 10 01:10:08 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 16:10:08 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> Message-ID: <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> On Feb 9, 2006, at 3:56 PM, Bill Janssen wrote: >> If we ignore the vendor's interpreter then our documentation becomes >> MUCH simpler as there will be one -- and preferably only one -- way >> to do it: install a Python interpreter that is recent and can run the >> full scope of Python applications. > > I think I'm almost convinced on this point, save for the problem of > /usr/bin/python and the default PATH. > >> If we make >> the proposed PATH change script to the installer, we can ignore the >> system Python just as easily as we could if it wasn't there at all. > > It is extremely difficult (almost impossible) to make such scripts > work properly on Unix, with the variety of shells and environments > that people use. This is practice, not theory. Only a small subset of the target audience knows what they're doing wrt PATH and .profile (or whatever is appropriate). DarwinPorts has a simple 99.9% solution in their postflight script: check if /opt/local/bin is in the path, if not, then append a line to their .cshrc if their SHELL is *csh and append a line to their .profile if their SHELL is *sh. >> There's little good reason for us to petition for its removal, and >> there's good reason for them to keep it there: they use it. > > If they shipped, instead, the current version of MacPython, would that > make the issue moot? That is, would you still "insist" on an upgrade > before a user could use Python? Could a Mac ever ship with an > acceptable pre-installed Python? If not, perhaps the solution for > Apple is to move /usr/bin/python to some other spot, like > /usr/libexec/, or some such place. The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. -bob From Chris.Barker at noaa.gov Fri Feb 10 01:13:12 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 09 Feb 2006 16:13:12 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> Message-ID: <43EBDA98.1060603@noaa.gov> Ronald Oussoren wrote: > That's not really a problem, I need some kind of test to determine if we > can get away with loading C++ code compiled with g++-3.3 into a python > build with gcc 4. Boost might also be an option for testing. matplotlib has a lot of C++ in it. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From kevino at theolliviers.com Fri Feb 10 01:17:28 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 9 Feb 2006 16:17:28 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> References: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> Message-ID: Hi Bob, On Feb 9, 2006, at 4:10 PM, Bob Ippolito wrote: [snip] > The issue of not being able to produce redistributable applications > still exists, and also backwards compatibility with previous versions > of Mac OS X. I haven't had time to respond to your other emails yet, but I've seen you mention this several times and I was wondering - why is it not possible to produce re-distributable applications with the system Python? (A thread title, etc. would be fine too if this was answered somewhere.) Thanks, Kevin > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Fri Feb 10 02:03:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 17:03:53 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> Message-ID: <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> On Feb 9, 2006, at 4:17 PM, Kevin Ollivier wrote: > Hi Bob, > > On Feb 9, 2006, at 4:10 PM, Bob Ippolito wrote: > > [snip] > >> The issue of not being able to produce redistributable applications >> still exists, and also backwards compatibility with previous versions >> of Mac OS X. > > I haven't had time to respond to your other emails yet, but I've seen > you mention this several times and I was wondering - why is it not > possible to produce re-distributable applications with the system > Python? (A thread title, etc. would be fine too if this was answered > somewhere.) The largest issue is that you can't legally redistribute the Python interpreter that ships with Mac OS X, so you can't create standalone applications. Even if you could, it wouldn't have a chance of being backwards compatible with the way that Apple builds things. Semi-standalone applications are fragile and only work on a particular minor version of OS X... for example, anything you build against it is only compatible with Mac OS X 10.4. It won't be compatible with Mac OS X 10.3, and it won't be compatible with Mac OS X 10.5 or anything farther away in either direction. Using a third party Python has a chance of being backwards compatible (some apps built on 10.4 work on 10.3) and it virtually guarantees forwards compatibility (apps I built standalone with py2app on 10.2 still work on 10.4, even with i386 hardware). -bob From Chris.Barker at noaa.gov Fri Feb 10 02:07:51 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 09 Feb 2006 17:07:51 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43EBDA98.1060603@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> <43EBDA98.1060603@noaa.gov> Message-ID: <43EBE767.6030302@noaa.gov> Christopher Barker wrote: > matplotlib has a lot of C++ in it. and there are binaries built for 2.4 on 10.3 on pythonmac.org, if that helps. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Fri Feb 10 02:09:54 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 09 Feb 2006 17:09:54 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> Message-ID: <43EBE7E2.3080107@noaa.gov> Hi all, Lots of comments on the whole thread.... Bob Ippolito wrote: > Nothing relevant comes with the system except for Terminal and > TextEdit... Which is a lousy editor for Python anyway. Brendan Simons wrote: > SPE is almost there, but still needs a binary install. Would it be there with a good installer? >> BTW, "Open Terminal Here" is a nifty applet > Here's another easy way to do the same thing: Open the terminal. > Type "ls" followed by a space, but don't hit return. Now click on > the finder and open the folder you want Terminal to access. In the > titlebar of the finder window, next to the folder's name, is a little > folder icon. Drag that icon to your terminal window (Expose helps if > you have lots of windows open). Terminal will spell out the folder's > path for you. Now return to Terminal and hit enter. I now about that, but that's a LOT more than one click -- get Open Terminal Here -- you'll be glad you did! Bob Ippolito wrote: > The 95% may shrink now that wxPython and tkinter are shipped with Mac OS > X. Except that the version of wx they ship isn't one anyone should use it they can help it. wxPython was a rapidly moving target on OS-X when they chose that version. > further still if PyObjC ends up shipping with > some version of OS X. That would make a big difference. >> If I was building an app that was written in Python, given the current >> state of MacPython and what I've read on this list over the years, I'd >> try to include the whole Python VM in that app bundle. Which means you need to use a user installed python. Bill Janssen wrote: > I think here you are talking about a Mac app bundle, right? I think > that's probably right. It applies just as much to a script with a #! line that relies on installed packages. Do you really develop without any external packages? Kevin Ollivier wrote: > I'd get really pissed off if I didn't know better and things stopped > working regardless of how I upgraded Python. You'd consider whose Python > broke your stuff into your decision to get upset? We really seem to be talking at cross purposes here. If I upgrade *python*, I expect things that depend on it to break, though in fact, when I upgrade python, I usually leave the old version in place so that nothing breaks. I put a version in my #! lines just for that reason. However, when I upgrade OS-X, I want my currently installed apps to keep working. And, in fact, they do, except the ones that depend on python. I just upgraded to OS-X 10.4. For ages, I've been using both Apples python2.3 and Bob's 2.4. All my scripts that have #!/usr/bin/env python2.3 in them are now broken. All the scripts that have #!/usr/bin/env python2.4 in them still work. If I'd started with 2.4 from the beginning, nothing would have broken. It's not hard to fix, particularly since I have a fully functional 2.4 already, but I'm not a newbie, either. > All Apple is doing is including Python with their OS, and occasionally > updating it. That these updates can cause not-so-pleasant things to > happen due to how Python works is not Apple's fault. A lot of the speech > on here practically accuses Apple of causing the problem and it's really > not fair. What they are doing is analogous to removing a bunch of shared libraries when you did an OS upgrade. IF you knew they were likely to do that you'd darn well better statically link your apps. > tell them things break when Python is upgraded > to a new major version; don't tell them (or suggest) things break > because Apple is doing it. Tell them that Apple is likely to upgrade python for you when you upgrade the OS, whether you want them to or not. however -- that's all we're saying. > What about an app bundle that just starts IDLE? Yes, we should make one of those! Kevin Walzer wrote: > No one has said anything about the "applet" packaging concept as we > discuss moving forward with this stuff. I'd like a way to build Applets: things that look like an App, but do depend on everything installed in your python. It probably wouldn't be hard to hack Py2App to do this. IIRC, Bob was open to the idea, but wasn't interested in writing the code himself. > "pythonw" invokes GUI applications, "python" invokes console > applications. When installing an extension, I don't type "pythonw > setup.py install." But would there be any harm if you did? > If we recommend that the user installs a particular framework build > of Python, we could distribute it such that python and pythonw are > indistinguishable. This issue then disappears. Excellent idea! Is there any downside in having "python" do what "pythonw" does now? Rodney Somerstein wrote: > Now, what I really want to see added is something that explains how I > can write a program in Python on the Mac and create standalone > applications that can run on someone else's computer without them > having to install anything else. Let's have py2app be a standard part of the 2.4 package. It'd be great if the standard upgrade package had and did everything you need to get started. I suggest easy-install as well. I. Vinogradov wrote: > What about other sources for python2.4 such as fink and darwinports? > Will they be frown upon or required to comply with framework > installation? We can't require a darn thing about fink or darwinports. They should be mentioned, under something like: If you are using fink or darwinports for other unix-y software.... or If you want to have complete unix-y environment in your Mac.... Bill Janssen wrote: > and there's not even a useful web page for MacPython. At least we're fixing that! Thanks for all your work, Bill. > Is there anyone from Apple even on this list? non one that has admitted it -- earlier there was a discussion about whether Apple was to blame for any of these issues. they clearly are, as they don't ever have anyone on this list. I don't think Apple has really figured out how to work with the open source community yet. > I've got a great deal of respect and appreciation for those, like Bob > and Ronald, working hard on advancing the technology pieces. Great > work, just what we all need! But unless there's some effective > delivery vehicle for getting that work to the customer, much of it > will be wasted. Bob's always made easy to install packages of his builds -- it could be better, but it's there, and far from wasted. Also, patches get into the main python source, and even Apple gets those eventually! It's just not that bad. All we really need is a couple better web pages, and a few more pre-built packages, and we'll be serving all but the total mac-centered newbies. What those folks need is a complete environment with a single installer. Bob Ippolito wrote: > If we ignore the vendor's interpreter then our documentation becomes > MUCH simpler as there will be one -- and preferably only one -- way > to do it: This has been my point from the beginning. There are a LOT of options, but we really need to have a "One Standard Way" to do python on the Mac that we publicize on the Web. A little extra into-tutorial with the built in Python is a fine way, but I think it should be clear that it's a good idea to install a new python package once you get going. That way there is ONE set of packages to pick from to download, etc, etc. I'd like the "One true way" to be the Apple installed python, but that's really not going to work. We've run that topic into the ground. We may still need one version for 10.3 and one for 10.4, but that's as complicated as it should get. > We also get to ignore the issues > of which version of Mac OS X they are using because 10.3 and 10.4 > will behave the same. Um, aren't there issues with not being able to use the universal version with less than 10.3.9, and not being able to build extensions on 10.3 at all with the universal version? > Our problem with Apple's bundling of Python is purely a documentation > issue (and the stubbornness of those who insist that it should be > used -- even celebrated -- despite its disadvantages). If we make > the proposed PATH change script to the installer, we can ignore the > system Python just as easily as we could if it wasn't there at all. yea!! > Some of these questions are already answered by http://pythonmac.org/ > wiki/FAQ -- for the questions that aren't currently answered, feel > free to contribute. Exactly. the page we are working on should be just the main page. All the various suggestions for other sections are good, but should be Wiki pages, maintenance is much easier that way. > check if /opt/local/bin is in the path, if not, > then append a line to their .cshrc if their SHELL is *csh and append > a line to their .profile if their SHELL is *sh. We could probably just do .profile...anyone messing with what shell they use should know how to add something to their PATH. Wow! that was a lot. I hope I'll have some time to really comment on Bill's prototype page tonight. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From tomp at earthlink.net Fri Feb 10 02:25:36 2006 From: tomp at earthlink.net (Tom Pollard) Date: Thu, 9 Feb 2006 20:25:36 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 9, 2006, at 6:56 PM, Bill Janssen wrote: >> If we make >> the proposed PATH change script to the installer, we can ignore the >> system Python just as easily as we could if it wasn't there at all. > > It is extremely difficult (almost impossible) to make such scripts > work properly on Unix, with the variety of shells and environments > that people use. Well, there are really only two flavors of shell - csh and sh. I'm sure it would be quite possible to create a post-install script that did the right thing for 98% of the people who used it. Those lost 2% are Unix geeks who can easily make the required changes by hand, with a bit of minimal documentation. Tom From karl at elemtech.com Thu Feb 9 22:27:36 2006 From: karl at elemtech.com (Karl Merkley) Date: Thu, 9 Feb 2006 14:27:36 -0700 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.123809pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.123809pst."58633"@synergy1.parc.xerox.com> Message-ID: <4b0ebef1ed87c6b6d17d795195d731d2@elemtech.com> On Feb 9, 2006, at 1:38 PM, Bill Janssen wrote: >> Python does not currently have an official Mac maintainer. > > Bingo! And no one has stepped up to document the amazing torrent of > productive activity since Jack "retired". As a result, the useful > pieces are scattered all over, the official documentation is wildly > out of date, and there's not even a useful web page for MacPython. > > Add to this the fact that the pre-installed Python is widely held to > be useless by well-respected and influential members of the community. > A parochial and self-defeating assessment, I think. > From a lurkers point of view . . . I think the starting point of the whole page is the perfect way to begin. There are many of us who find that python 2.3 is just fine for the kind of things that we are trying to do. Telling a newbie that this is a great tool but you need to do an update is just going to be overwhelming. Case in point. The other day I volunteered some time at the local elementary school and the computer teacher was looking for something to give to some more advanced 10 to 12 year olds. I told him that his Mac's all have python installed and it comes with a turtle graphics module. "Turtle?", he says. "Does it work like the old Logo system?" After ten minutes of showing him how to get started and answering things like "What's this terminal window thing" he's off and running and very excited. It cost him very little time, no money out of his budget, no software to install on 30 machines, and suddenly he has a whole new tool to play with and expose his kids to some simple programming concepts. Now he's off learning python. That's how it should work for a newbie. Karl From mday at mac.com Fri Feb 10 02:48:38 2006 From: mday at mac.com (Mark Day) Date: Thu, 9 Feb 2006 17:48:38 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EBE7E2.3080107@noaa.gov> References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> Message-ID: <4B9607FD-B2C0-48E7-B61C-9495E61411C4@mac.com> On Feb 9, 2006, at 5:09 PM, Christopher Barker wrote: >> Is there anyone from Apple even on this list? > > non one that has admitted it I'm an Apple employee. I know there have been others on this list, too, though I have no idea if they're still here. I don't maintain Apple's python, and I have no idea whether the people who do are on this list. I notice that there is a bug report asking for Python 2.4 be added to the release. I just now added a comment to that bug saying it would be nice to keep 2.3 as well as adding 2.4 (so that scripts which explicitly reference 2.3 could continue to work, and so you could explicitly run 2.3 if you had extensions compiled for 2.3). I also saw a bug report asking for PyObjC to be included; I'd definitely like to see that! -Mark From bob at redivi.com Fri Feb 10 02:56:56 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 17:56:56 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43EBE7E2.3080107@noaa.gov> References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> Message-ID: On Feb 9, 2006, at 5:09 PM, Christopher Barker wrote: >> "pythonw" invokes GUI applications, "python" invokes console >> applications. When installing an extension, I don't type "pythonw >> setup.py install." > > But would there be any harm if you did? No >> If we recommend that the user installs a particular framework build >> of Python, we could distribute it such that python and pythonw are >> indistinguishable. This issue then disappears. > > Excellent idea! Is there any downside in having "python" do what > "pythonw" does now? Not that I can imagine... maybe a few nanoseconds wasted on invocation to launch the executable and execv the real interpreter. > Rodney Somerstein wrote: > >> Now, what I really want to see added is something that explains how I >> can write a program in Python on the Mac and create standalone >> applications that can run on someone else's computer without them >> having to install anything else. > > Let's have py2app be a standard part of the 2.4 package. It'd be great > if the standard upgrade package had and did everything you need to get > started. I suggest easy-install as well. I'd prefer to wait on that until it's more mature. Shipping setuptools isn't a bad idea, but it's a one-liner to install it.. > Bill Janssen wrote: >> and there's not even a useful web page for MacPython. > > At least we're fixing that! Thanks for all your work, Bill. > >> Is there anyone from Apple even on this list? > > non one that has admitted it -- earlier there was a discussion about > whether Apple was to blame for any of these issues. they clearly > are, as > they don't ever have anyone on this list. I don't think Apple has > really > figured out how to work with the open source community yet. Some Apple employees do a pretty good job at working with open source communities when they have the time to do so.. but they're usually too busy, and it's really their own initiative. Personally I haven't been very pleased with their open source interactions, but it could be worse. > Bob Ippolito wrote: > >> If we ignore the vendor's interpreter then our documentation becomes >> MUCH simpler as there will be one -- and preferably only one -- way >> to do it: > > This has been my point from the beginning. There are a LOT of options, > but we really need to have a "One Standard Way" to do python on the > Mac > that we publicize on the Web. > > A little extra into-tutorial with the built in Python is a fine > way, but > I think it should be clear that it's a good idea to install a new > python > package once you get going. That way there is ONE set of packages to > pick from to download, etc, etc. > > I'd like the "One true way" to be the Apple installed python, but > that's > really not going to work. We've run that topic into the ground. > > We may still need one version for 10.3 and one for 10.4, but that's as > complicated as it should get. > >> We also get to ignore the issues >> of which version of Mac OS X they are using because 10.3 and 10.4 >> will behave the same. > > Um, aren't there issues with not being able to use the universal > version > with less than 10.3.9, and not being able to build extensions on > 10.3 at > all with the universal version? The universal version is indeed not compatible with 10.3.0-10.3.8, but upgrading to 10.3.9 is free. I think it's safe at this point to say 10.3.9 is absolutely required to use the supported version of Python. The extension thing we can hack around by installing two copies of the Makefile and having distutils pick a PPC-only Makefile if it detects 10.3. >> Some of these questions are already answered by http://pythonmac.org/ >> wiki/FAQ -- for the questions that aren't currently answered, feel >> free to contribute. > > Exactly. the page we are working on should be just the main page. All > the various suggestions for other sections are good, but should be > Wiki > pages, maintenance is much easier that way. It might be a good idea to highlight the really frequent FAQs and link to their answers on the wiki. >> check if /opt/local/bin is in the path, if not, >> then append a line to their .cshrc if their SHELL is *csh and append >> a line to their .profile if their SHELL is *sh. > > We could probably just do .profile...anyone messing with what shell > they > use should know how to add something to their PATH. > > Wow! that was a lot. Well we might as well just crib the script from DarwinPorts and change the paths... supporting tcsh is important for the people who started with <= 10.2 and upgraded their way to >= 10.3. I held out with tcsh for a while personally, but I left it at bash last time I AppleCare'ed my powerbook and wiped the machine. -bob From samrobertsmith at gmail.com Fri Feb 10 03:45:48 2006 From: samrobertsmith at gmail.com (linda.s) Date: Thu, 9 Feb 2006 18:45:48 -0800 Subject: [Pythonmac-SIG] install again? In-Reply-To: References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> Message-ID: <1d987df30602091845g5264a07ek9d38bcf11bcd1faf@mail.gmail.com> I know the reason that I got confused is I do not know Mac/UNIX well. Is there any good tutorial to read (I understand there are many but just no idea where to start)? Thanks, Linda. From bob at redivi.com Fri Feb 10 03:53:21 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 18:53:21 -0800 Subject: [Pythonmac-SIG] PATH manipulation and /usr/local/bin Message-ID: <37847865-5D05-4533-AA7D-D493757DD7E4@redivi.com> Since we're going to manipulating the PATH with the installer, should we still bother with the symlinks in /usr/local/bin? We definitely want the Framework's bin dir on the PATH because that's where scripts will be installed to... so the /usr/local/bin links seem a bit redundant. If we do this, then the Python installation process is completely self-contained except for the Applications dir. Maybe "make frameworkinstall" should still install the symlinks for compatibility with people building their own from source, but I'm not sure if it's better to keep doing it or to just document that the behavior has changed. -bob From janssen at parc.com Fri Feb 10 04:24:55 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 19:24:55 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 16:10:08 PST." <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> Message-ID: <06Feb9.192505pst."58633"@synergy1.parc.xerox.com> > Could a Mac ever ship with an > > acceptable pre-installed Python? If not, perhaps the solution for > > Apple is to move /usr/bin/python to some other spot, like > > /usr/libexec/, or some such place. > > The issue of not being able to produce redistributable applications > still exists, and also backwards compatibility with previous versions > of Mac OS X. So you're saying that the pre-installed version could never be really acceptable. In that case, perhaps we only need convince Apple to move /usr/bin/python to some more system-y place that wouldn't usually be on users' paths. We then in the MacPython world take the position that Python isn't really pre-installed on Macs, and the place for a person to start would be to download the installer and run it. Perhaps then in addition the installer could symlink /usr/local/bin/pythonw to /usr/bin/python, thereby solving the PATH issue. Bill From janssen at parc.com Fri Feb 10 04:29:47 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 19:29:47 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Thu, 09 Feb 2006 17:09:54 PST." <43EBE7E2.3080107@noaa.gov> Message-ID: <06Feb9.192950pst."58633"@synergy1.parc.xerox.com> > Bill Janssen wrote: > > I think here you are talking about a Mac app bundle, right? I think > > that's probably right. > > It applies just as much to a script with a #! line that relies on > installed packages. Do you really develop without any external packages? Sure. I do a lot of text processing, and the Unicode and re support in standard Python are pretty much good enough for much of that work. Almost the only extension packages I use are PIL, Medusa, and ReportLab. All just install and work pretty well with "python setup.py install". Bill From janssen at parc.com Fri Feb 10 04:32:55 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 19:32:55 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 13:27:36 PST." <4b0ebef1ed87c6b6d17d795195d731d2@elemtech.com> Message-ID: <06Feb9.193255pst."58633"@synergy1.parc.xerox.com> > Case in point. The other day I volunteered some time at the local > elementary school and the computer teacher was looking for something to > give to some more advanced 10 to 12 year olds. I told him that his > Mac's all have python installed and it comes with a turtle graphics > module. "Turtle?", he says. "Does it work like the old Logo system?" > After ten minutes of showing him how to get started and answering > things like "What's this terminal window thing" he's off and running > and very excited. It cost him very little time, no money out of his > budget, no software to install on 30 machines, and suddenly he has a > whole new tool to play with and expose his kids to some simple > programming concepts. Now he's off learning python. That's how it > should work for a newbie. Wow! Great success story, Karl. Bill From janssen at parc.com Fri Feb 10 04:35:10 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 9 Feb 2006 19:35:10 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Thu, 09 Feb 2006 17:56:56 PST." Message-ID: <06Feb9.193510pst."58633"@synergy1.parc.xerox.com> > > Exactly. the page we are working on should be just the main page. All > > the various suggestions for other sections are good, but should be > > Wiki > > pages, maintenance is much easier that way. > > It might be a good idea to highlight the really frequent FAQs and > link to their answers on the wiki. I think this would be a pretty good way to start building a FAQ. Bill From bob at redivi.com Fri Feb 10 04:52:46 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 19:52:46 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb9.193510pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.193510pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 9, 2006, at 7:35 PM, Bill Janssen wrote: >>> Exactly. the page we are working on should be just the main page. >>> All >>> the various suggestions for other sections are good, but should be >>> Wiki >>> pages, maintenance is much easier that way. >> >> It might be a good idea to highlight the really frequent FAQs and >> link to their answers on the wiki. > > I think this would be a pretty good way to start building a FAQ. There already is a FAQ, and it's been there for a very long time. We don't have to start building anything -- just link to the most popular ones. -bob From bob at redivi.com Fri Feb 10 04:56:11 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 19:56:11 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.192505pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.192505pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 9, 2006, at 7:24 PM, Bill Janssen wrote: >> Could a Mac ever ship with an >>> acceptable pre-installed Python? If not, perhaps the solution for >>> Apple is to move /usr/bin/python to some other spot, like >>> /usr/libexec/, or some such place. >> >> The issue of not being able to produce redistributable applications >> still exists, and also backwards compatibility with previous versions >> of Mac OS X. > > So you're saying that the pre-installed version could never be really > acceptable. In that case, perhaps we only need convince Apple to move > /usr/bin/python to some more system-y place that wouldn't usually be > on users' paths. > > We then in the MacPython world take the position that Python isn't > really pre-installed on Macs, and the place for a person to start > would be to download the installer and run it. Perhaps then in > addition the installer could symlink /usr/local/bin/pythonw to > /usr/bin/python, thereby solving the PATH issue. That's not an acceptable solution. We need to support versions of OS X that currently exist, and we can't depend on Apple to do anything. -bob From skip at pobox.com Fri Feb 10 05:07:49 2006 From: skip at pobox.com (skip at pobox.com) Date: Thu, 9 Feb 2006 22:07:49 -0600 Subject: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior... Message-ID: <17388.4501.402538.439935@montanaro.dyndns.org> I want to manipulate iCal from the command line. Thanks to appscript it looks like I'll be able to do what I want. I wrote a simple skeleton script: #!/usr/bin/pythonw """ %(prog)s - manipulate iCal """ import sys import os import getopt from appscript import * ... etc ... I made it executable and tried executing it from the bash prompt in a Terminal window. No go. The system treats it like a shell script and passes it off to the Bourne shell. Naturally, this doesn't go over too well. If I run it as "/usr/bin/pythonw ical.py ..." it works just fine. Am I missing something? Thx, -- Skip Montanaro http://www.musi-cal.com/ skip at pobox.com From brendansimons at yahoo.ca Fri Feb 10 05:08:50 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu, 9 Feb 2006 23:08:50 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: Message-ID: <52DC2AC1-2C2D-479D-8DC3-560F3795CCBC@yahoo.ca> On 9-Feb-06, at 8:10 PM, Chris Barker wrote: > > > Brendan Simons wrote: >> SPE is almost there, but still needs a binary install. > > Would it be there with a good installer? Maybe. However its under active development and changes frequently. > >>> BTW, "Open Terminal Here" is a nifty applet > >> Here's another easy way to do the same thing: Open the >> terminal. Type "ls" followed by a space, but don't hit return. >> Now click on the finder and open the folder you want Terminal to >> access. In the titlebar of the finder window, next to the >> folder's name, is a little folder icon. Drag that icon to your >> terminal window (Expose helps if you have lots of windows open). >> Terminal will spell out the folder's path for you. Now return to >> Terminal and hit enter. > > I now about that, but that's a LOT more than one click -- get Open > Terminal Here -- you'll be glad you did! True enough. BTW, I meant to use "cd", rather than "ls" in the example. > >> further still if PyObjC ends up shipping with some version of OS X. > > That would make a big difference. Thirded. Glad to hear it's been added to the Apple buglist. -Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060209/fe43fe8b/attachment.htm From rodneys at io.com Fri Feb 10 05:09:15 2006 From: rodneys at io.com (Rodney Somerstein) Date: Thu, 9 Feb 2006 23:09:15 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: At 1:20 PM -0800 2/9/06, Bob Ippolito wrote: >py2app is the solution for application packaging, and you must use >it with a third party Python installation (e.g. Python 2.4.1) in >order to come up with something that's redistributable and robust. >If you happen to use the system Python, then you will produce a >package that only runs on the particular release of Mac OS X that >you build it with. In other words, when you or your users upgrade >to Mac OS X 10.5, any system-Python built application bundle will >cease to function at all. > >It is actually not much different than on other platforms. Many >py2exe-based setup scripts work identically with py2app if you >change the import statement. Mac-specific features of course >require Mac- specific solutions, but the standard stuff is identical. > >There is some minimal documentation: http://undefined.org/python/ py2app.html In general, I know this. I try to at least skim the messages on this list on a regular basis to keep up with what is going on in the MacPython world. But, for someone who is new to Python, the documentation you are pointing to is pretty rough going. It would be really nice to have a more basic introduction to what py2app actually does. Then, a step by step description of how to make it work, rather than just jumping into setup.py scripts. (Where does setup.py come from? The documentation doesn't say. I'm not asking this, just pointing out that it will be confusing to someone just trying to learn this stuff. They are going to want to know why they have to "build their application" when they already have it running.) >Any other questions you have can probably be answered by py2exe >documentation and/or this list. Yes, I'm sure they can be. I don't see any reference to actually taking a look at the py2exe documentation. Everything states that it is similar, but for the Mac. It doesn't say take a look there if you need more help. Or to ask here. But this discussion is about how to make this easier for people to get into. Having to ask here isn't that bad. Everyone here is very friendly and helpful. But, many people don't like to subscribe to mailing lists, especially to ask one question. Most of the discussions that go on here are *WAY* over the heads of beginners and even many intermediate Python users. And, the answers often times make assumptions about what the user knows rather than offering basic advice. I'm not complaining, really. I know that you and everyone here do this on your own time and do your best to help everyone. Python on the Mac really needs a very easily accessible discussion board for people to read and ask questions. python-mac is intimidating to someone getting started. Those who aren't so timid may stick it out, but many people will likely skim the messages on the python.org website and walk away after deciding that this stuff is just too tough. The ones who are already programmers aren't the ones I'm talking about. I'm more talking about the new scripter or maybe someone who has done a little bit of AppleScript or possibly HTML and basic JavaScript. While I can articulate what I want to see and can put myself in the place of the absolute beginner (I'm not too far from that myself with Python and I teach technical courses to varying skill levels of users for a living), I unfortunately don't have the Python background to write this material myself. I hope this helps get across what I'm looking for and what I think will benefit people trying to get started with Python on the Mac. -Rodney From rodneys at io.com Fri Feb 10 05:17:07 2006 From: rodneys at io.com (Rodney Somerstein) Date: Thu, 9 Feb 2006 23:17:07 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.133934pst."58633"@synergy1.parc.xerox.com> References: <06Feb9.133934pst."58633"@synergy1.parc.xerox.com> Message-ID: At 1:39 PM -0800 2/9/06, Bill Janssen wrote: >Great idea, Rodney. I think we probably need a number of pages like >this, kind of an FAQ set. I think the main page should just cover one >or two things (how to run python, how to upgrade), and lots of >pointers to these pages. Each of these should be fairly clear, with >pointers off to more complicated explanations. > >Here's the start of a list: > >1) What's the difference between "python" and "pythonw"? >2) What's the advantage of upgrading? >3) What do I do if I want to use pre-built packages? >4) How do I use the Apple GUI toolkit from Python? >5) How do I use Apple Events from Python? >6) How do I build a real Mac application written in Python? >7) How do I install extra modules, like PIL, for the system Python? >8) What IDE's are available, and what are their relative merits? Bill, You seem to have a good handle on what is needed to get new users involved in working with Python on the Mac. Even some of the questions that you list here might be a little too complex for new users. For example, question 3 probably needs to state something about all of the pre-built packages that are available before asking how to use them. Question 6 needs to at least talk about what is involved if the user wants this application to run on multiple platforms, not just Mac. For example, can they build on the Mac and the distribute on other platforms? Or do you have to build on each platform? It is likely that your idea of pointing to more complicated explanations could take care of each of kind of points that I'm raising. My key idea that I'm trying to point out is that for such a list to be useful to beginners, it needs to not make so many assumptions about what they know. An introductory paragraph in each question can help out quite a bit. For example, is it actually safe to assume that a new user even knows what the Apple GUI toolkit is? A sentence or two talking about the great UI functionality that Apple makes available and that it can be accessed from Python should be there before launching into an explanation of how to actually do so. Remember, this should serve people who haven't programmed before as well as people who have but are just new to Python. -Rodney From bob at redivi.com Fri Feb 10 06:32:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 21:32:53 -0800 Subject: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior... In-Reply-To: <17388.4501.402538.439935@montanaro.dyndns.org> References: <17388.4501.402538.439935@montanaro.dyndns.org> Message-ID: <97182535-1F3A-41E2-A094-DC44715F7E76@redivi.com> On Feb 9, 2006, at 8:07 PM, skip at pobox.com wrote: > > I want to manipulate iCal from the command line. Thanks to > appscript it > looks like I'll be able to do what I want. > > I wrote a simple skeleton script: > > #!/usr/bin/pythonw Sounds like you're using OS X 10.3. It shipped with pythonw as a shell script, not an executable. You need to point it at the actual binary: /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app/Contents/MacOS/Python If you upgrade to 10.4, this should work. -bob From bob at redivi.com Fri Feb 10 06:36:49 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 9 Feb 2006 21:36:49 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: <0FDE9DA5-1A85-44E3-AA34-EC298E87B2E6@redivi.com> On Feb 9, 2006, at 8:09 PM, Rodney Somerstein wrote: > At 1:20 PM -0800 2/9/06, Bob Ippolito wrote: >> py2app is the solution for application packaging, and you must use >> it with a third party Python installation (e.g. Python 2.4.1) in >> order to come up with something that's redistributable and robust. >> If you happen to use the system Python, then you will produce a >> package that only runs on the particular release of Mac OS X that >> you build it with. In other words, when you or your users upgrade >> to Mac OS X 10.5, any system-Python built application bundle will >> cease to function at all. >> >> It is actually not much different than on other platforms. Many >> py2exe-based setup scripts work identically with py2app if you >> change the import statement. Mac-specific features of course >> require Mac- specific solutions, but the standard stuff is identical. >> >> There is some minimal documentation: http://undefined.org/python/ >> py2app.html > > In general, I know this. I try to at least skim the messages on this > list on a regular basis to keep up with what is going on in the > MacPython world. But, for someone who is new to Python, the > documentation you are pointing to is pretty rough going. It would be > really nice to have a more basic introduction to what py2app actually > does. Then, a step by step description of how to make it work, rather > than just jumping into setup.py scripts. (Where does setup.py come > from? The documentation doesn't say. I'm not asking this, just > pointing out that it will be confusing to someone just trying to > learn this stuff. They are going to want to know why they have to > "build their application" when they already have it running.) > >> Any other questions you have can probably be answered by py2exe >> documentation and/or this list. > > Yes, I'm sure they can be. I don't see any reference to actually > taking a look at the py2exe documentation. Everything states that it > is similar, but for the Mac. It doesn't say take a look there if you > need more help. Or to ask here. py2app is not a polished product and is not geared towards people that don't already know what they're doing. If you want to see more basic docs, ask enough specific questions so that you understand the material and write the documentation yourself. Send it to me, and I'll make sure it goes in to the next release. This is open source, that's how it works. -bob From samrobertsmith at gmail.com Fri Feb 10 10:56:28 2006 From: samrobertsmith at gmail.com (linda.s) Date: Fri, 10 Feb 2006 01:56:28 -0800 Subject: [Pythonmac-SIG] uninstall Message-ID: <1d987df30602100156o7a697279web2769ae73ce797b@mail.gmail.com> If I installed some version of python i do not like, how do i remove them? In windows, it is easy to uninstall them, but no idea about how to do in Mac (just drag it to the the icon of trashcan?)? Linda. From bob at redivi.com Fri Feb 10 11:52:25 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 02:52:25 -0800 Subject: [Pythonmac-SIG] uninstall In-Reply-To: <1d987df30602100156o7a697279web2769ae73ce797b@mail.gmail.com> References: <1d987df30602100156o7a697279web2769ae73ce797b@mail.gmail.com> Message-ID: On Feb 10, 2006, at 1:56 AM, linda.s wrote: > If I installed some version of python i do not like, how do i > remove them? > In windows, it is easy to uninstall them, but no idea about how to do > in Mac (just drag it to the the icon of trashcan?)? It depends on which version of Python it is and how you installed it.. You'll have to be more specific. -bob From samrobertsmith at gmail.com Fri Feb 10 11:55:19 2006 From: samrobertsmith at gmail.com (linda.s) Date: Fri, 10 Feb 2006 02:55:19 -0800 Subject: [Pythonmac-SIG] uninstall In-Reply-To: References: <1d987df30602100156o7a697279web2769ae73ce797b@mail.gmail.com> Message-ID: <1d987df30602100255s3958d869qf35b68ea02726f56@mail.gmail.com> On 2/10/06, Bob Ippolito wrote: > > On Feb 10, 2006, at 1:56 AM, linda.s wrote: > > > If I installed some version of python i do not like, how do i > > remove them? > > In windows, it is easy to uninstall them, but no idea about how to do > > in Mac (just drag it to the the icon of trashcan?)? > > It depends on which version of Python it is and how you installed > it.. You'll have to be more specific. > > -bob I installed python 2.4.2 from source. Why version matters (curious:))? Linda From bob at redivi.com Fri Feb 10 12:05:15 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 03:05:15 -0800 Subject: [Pythonmac-SIG] uninstall In-Reply-To: <1d987df30602100255s3958d869qf35b68ea02726f56@mail.gmail.com> References: <1d987df30602100156o7a697279web2769ae73ce797b@mail.gmail.com> <1d987df30602100255s3958d869qf35b68ea02726f56@mail.gmail.com> Message-ID: On Feb 10, 2006, at 2:55 AM, linda.s wrote: > On 2/10/06, Bob Ippolito wrote: >> >> On Feb 10, 2006, at 1:56 AM, linda.s wrote: >> >>> If I installed some version of python i do not like, how do i >>> remove them? >>> In windows, it is easy to uninstall them, but no idea about how >>> to do >>> in Mac (just drag it to the the icon of trashcan?)? >> >> It depends on which version of Python it is and how you installed >> it.. You'll have to be more specific. >> >> -bob > I installed python 2.4.2 from source. > Why version matters (curious:))? The version number is in the path names. Did you install it with "./ configure && sudo make install" or "./configure --enable-framework && sudo make frameworkinstall"? -bob From samrobertsmith at gmail.com Fri Feb 10 12:14:46 2006 From: samrobertsmith at gmail.com (linda.s) Date: Fri, 10 Feb 2006 03:14:46 -0800 Subject: [Pythonmac-SIG] uninstall In-Reply-To: References: <1d987df30602100156o7a697279web2769ae73ce797b@mail.gmail.com> <1d987df30602100255s3958d869qf35b68ea02726f56@mail.gmail.com> Message-ID: <1d987df30602100314k20265eb1tfe854fbc450d1df2@mail.gmail.com> On 2/10/06, Bob Ippolito wrote: > > On Feb 10, 2006, at 2:55 AM, linda.s wrote: > > > On 2/10/06, Bob Ippolito wrote: > >> > >> On Feb 10, 2006, at 1:56 AM, linda.s wrote: > >> > >>> If I installed some version of python i do not like, how do i > >>> remove them? > >>> In windows, it is easy to uninstall them, but no idea about how > >>> to do > >>> in Mac (just drag it to the the icon of trashcan?)? > >> > >> It depends on which version of Python it is and how you installed > >> it.. You'll have to be more specific. > >> > >> -bob > > I installed python 2.4.2 from source. > > Why version matters (curious:))? > > The version number is in the path names. Did you install it with "./ > configure && sudo make install" or "./configure --enable-framework && > sudo make frameworkinstall"? > > -bob "./configure && sudo make install" From skip at pobox.com Fri Feb 10 13:12:25 2006 From: skip at pobox.com (skip at pobox.com) Date: Fri, 10 Feb 2006 06:12:25 -0600 Subject: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior... In-Reply-To: <97182535-1F3A-41E2-A094-DC44715F7E76@redivi.com> References: <17388.4501.402538.439935@montanaro.dyndns.org> <97182535-1F3A-41E2-A094-DC44715F7E76@redivi.com> Message-ID: <17388.33577.739171.199409@montanaro.dyndns.org> >> #!/usr/bin/pythonw Bob> Sounds like you're using OS X 10.3. It shipped with pythonw as a Bob> shell script, not an executable. Yes, thanks. Shoulda thought to actually look at /usr/bin/pythonw... Skip From pecora at anvil.nrl.navy.mil Fri Feb 10 14:36:36 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Fri, 10 Feb 2006 08:36:36 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> References: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> Message-ID: <43EC96E4.9030901@anvil.nrl.navy.mil> Bob Ippolito wrote: > > The largest issue is that you can't legally redistribute the Python > interpreter that ships with Mac OS X, so you can't create standalone > applications. Even if you could, it wouldn't have a chance of being > backwards compatible with the way that Apple builds things. > > This seems to be where this argument goes: the user/newbies vs. the developers. Can we break this knot? Sure a developer wants a system that guarantees no barriers for anyone trying to use his product. Sure a newbie or just a user wants no barriers to just get up and running. If each side insists on having its way, this will go nowhere. I thought it had a chance for a few days and now I'm having my doubts. I sense developers here want everyone to get the latest and greatest python so then their product is a no-brainer to use (sorry about the slang). Of course, users/newbies want to just jump in there and go without pain. I'm a user so perhaps that explains why I am more on the user side. You shouldn't be forcing everyone to adopt a python system that then suits your marketing model. Why a compromise can't be reached here is beyond me. Does this happen with Perl? Ruby? I'm not sure how helpful that was, but I need to vent. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From charles.hartman at conncoll.edu Fri Feb 10 14:49:05 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri, 10 Feb 2006 08:49:05 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43EC96E4.9030901@anvil.nrl.navy.mil> References: <06Feb9.155625pst."58633"@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> <43EC96E4.9030901@anvil.nrl.navy.mil> Message-ID: <1C83B77D-5156-4FFB-99B8-525459118D39@conncoll.edu> It seems to me (as *much* closer to a newbie than a developer) that simply recommending the download & install of Python 2.4.x not only wouldn't put a major obstacle in the way of beginners, but wouldn't seem to, either. That one step isn't a problem -- if we can get to the point where that's the only step (because no Fix or Compat is needed, the PATH gets tweaked, etc). Charles On Feb 10, 2006, at 8:36 AM, Louis Pecora wrote: > Bob Ippolito wrote: >> >> The largest issue is that you can't legally redistribute the Python >> interpreter that ships with Mac OS X, so you can't create standalone >> applications. Even if you could, it wouldn't have a chance of being >> backwards compatible with the way that Apple builds things. >> >> > > This seems to be where this argument goes: the user/newbies vs. the > developers. Can we break this knot? Sure a developer wants a system > that guarantees no barriers for anyone trying to use his product. > Sure > a newbie or just a user wants no barriers to just get up and running. > > If each side insists on having its way, this will go nowhere. I > thought it had a chance for a few days and now I'm having my doubts. > > I sense developers here want everyone to get the latest and greatest > python so then their product is a no-brainer to use (sorry about the > slang). Of course, users/newbies want to just jump in there and go > without pain. I'm a user so perhaps that explains why I am more on > the > user side. You shouldn't be forcing everyone to adopt a python system > that then suits your marketing model. > > Why a compromise can't be reached here is beyond me. Does this happen > with Perl? Ruby? > > I'm not sure how helpful that was, but I need to vent. > > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From skip at pobox.com Fri Feb 10 15:59:57 2006 From: skip at pobox.com (skip at pobox.com) Date: Fri, 10 Feb 2006 08:59:57 -0600 Subject: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior... In-Reply-To: <17388.33577.739171.199409@montanaro.dyndns.org> References: <17388.4501.402538.439935@montanaro.dyndns.org> <97182535-1F3A-41E2-A094-DC44715F7E76@redivi.com> <17388.33577.739171.199409@montanaro.dyndns.org> Message-ID: <17388.43629.948204.423623@montanaro.dyndns.org> >>> #!/usr/bin/pythonw Bob> Sounds like you're using OS X 10.3. It shipped with pythonw as a Bob> shell script, not an executable. skip> Yes, thanks. Shoulda thought to actually look at skip> /usr/bin/pythonw... Alas, explicitly specifying the long path didn't work either. It bombs on import of appscript: Traceback (most recent call last): File "/Users/skip/cmd/ical.py", line 11, in ? from appscript import * File "/Library/Python/2.3/appscript/__init__.py", line 16, in ? from specifier import app, CommandError File "/Library/Python/2.3/appscript/specifier.py", line 9, in ? import aem File "/Library/Python/2.3/aem/__init__.py", line 25, in ? from send import * File "/Library/Python/2.3/aem/send/__init__.py", line 103, in ? raise RuntimeError, "Can't send Apple events: no access to Window Manager. (aem-based scripts must be run within a GUI process; e.g. use 'pythonw', not 'python', if running script in shell)" RuntimeError: Can't send Apple events: no access to Window Manager. (aem-based scripts must be run within a GUI process; e.g. use 'pythonw', not 'python', if running script in shell) even when run from a Terminal window. Skip From hengist.podd at virgin.net Fri Feb 10 16:20:26 2006 From: hengist.podd at virgin.net (has) Date: Fri, 10 Feb 2006 15:20:26 +0000 Subject: [Pythonmac-SIG] My stab at a new page Message-ID: Bill Janssen wrote: > > 1. Link to the "Macintosh Library Module": A lot of that stuff will be > > rendered obsolete the minute Bob releases the universal build of > > MacPython. PythonIDE, Package Manager, etc.: not gonna be included. At a > > minimum, you should note that this stuff is "legacy." > > > > 2. Ditto for "Apple Events." Does anyone use gensuitemodule or even know > > what it means? > >Hey, I'm linking to the official documentation. That's what people >will use, till it changes. All this other stuff scattered around is >blue-sky wild-ass future, till it's documented. Problem with the official Mac-specific modules and documentation is there's quite of stuff in there that hasn't been correct/usable since OS 9. It's just that nobody's gotten around to dealing with it. Experienced users already know which bits to avoid, so there's not huge impetus to clean it out properly. Doesn't mean you want to steer newbies towards it though. e.g. There's precious little point in linking to gensuitemodule: while it's always been a bit flaky, it appears to be pretty well broken in Tiger. (I've tried it a few times and it just barfs up a variety of errors, and I've seen other reports so it's not just me.) You'd be better not linking to anything at all than linking to obsolete/broken junk like that, because it just makes the rest of Mac Python look bad. FWIW, I did start looking into the issue, but I'm not really qualified to make a call on a lot of the stuff there and I had more immediate things to be getting on with anyway. Still, from my notes, if it's any use: - mac, macpath -- deprecate now. (Are these ever used on OS X?) - macfs -- already deprecated. - FrameWork, gensuitemodule, aetools, aepack, aetypes, MiniAEFrame -- deprecate now. - findertools, Nav, nsremote, W -- deprecate now. - os/os.path -- docs appear to contain various misleading statements about using Python on Mac that apply only to OS 9, not OS X; fix/remove those statements. - EasyDialogs -- still used on OS X but lacks Unicode support and strings are limited to 255-chars - MacOS -- OS9 docs could be stripped out; GetCreatorAndType() and Set CreatorAndType() need fixed or deprecated (don't work on bundles) There's almost certainly more that could be axed by someone who knows what they're looking at. Maybe when I've more time I'll try to do more on this; be nice if it was addressed for Python 2.5. (Wonder what 2.5's schedule is?) HTH has -- http://freespace.virgin.net/hamish.sanderson/ From robert.kern at gmail.com Fri Feb 10 16:25:52 2006 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 10 Feb 2006 09:25:52 -0600 Subject: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior... In-Reply-To: <17388.43629.948204.423623@montanaro.dyndns.org> References: <17388.4501.402538.439935@montanaro.dyndns.org> <97182535-1F3A-41E2-A094-DC44715F7E76@redivi.com> <17388.33577.739171.199409@montanaro.dyndns.org> <17388.43629.948204.423623@montanaro.dyndns.org> Message-ID: <43ECB080.2040600@gmail.com> skip at pobox.com wrote: > >>> #!/usr/bin/pythonw > > Bob> Sounds like you're using OS X 10.3. It shipped with pythonw as a > Bob> shell script, not an executable. > > skip> Yes, thanks. Shoulda thought to actually look at > skip> /usr/bin/pythonw... > > Alas, explicitly specifying the long path didn't work either. It bombs on > import of appscript: Try #!/usr/bin/env /usr/bin/pythonw -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From skip at pobox.com Fri Feb 10 16:34:32 2006 From: skip at pobox.com (skip at pobox.com) Date: Fri, 10 Feb 2006 09:34:32 -0600 Subject: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior... In-Reply-To: <43ECB080.2040600@gmail.com> References: <17388.4501.402538.439935@montanaro.dyndns.org> <97182535-1F3A-41E2-A094-DC44715F7E76@redivi.com> <17388.33577.739171.199409@montanaro.dyndns.org> <17388.43629.948204.423623@montanaro.dyndns.org> <43ECB080.2040600@gmail.com> Message-ID: <17388.45704.499771.578430@montanaro.dyndns.org> >> Alas, explicitly specifying the long path didn't work either. It >> bombs on import of appscript: Robert> Try Robert> #!/usr/bin/env /usr/bin/pythonw Cool! Works like a charm. Thanks... Skip From gandreas at gandreas.com Fri Feb 10 16:24:08 2006 From: gandreas at gandreas.com (gandreas at gandreas.com) Date: Fri, 10 Feb 2006 09:24:08 -0600 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43EB98E7.1080801@wordtech-software.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> <43EB98E7.1080801@wordtech-software.com> Message-ID: <00329A97-797E-49F6-99A0-3147912D92DD@gandreas.com> On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: > If I'm a newbie, I'm going to go, "Huh?", then "shrug," and move on to > Realbasic. There needs to be something double-clickable there for a > newbie to use. PythonIDE, though it had many flaws, was useful this > way. > BTW, what happened to PyOXIDE? It had major bugs, but was > promising as > a "next-generation" basic IDE for Python development on the Mac. PyOXIDE isn't dead - it's just sleeping. Seriously, there are several issues: 1) Lack of available time 2) It mostly does everything _I_ need (I actually use it on a fairly regular basis, and I have no burning need to add new features) 3) It needs to basically be re-written - it started as an editor with python embedded in it (i.e., use the python.framework and the various python embedding routines). Unfortunately, with 2.4 and the corresponding PyObjC, that just plain doesn't work well - PyObjC pretty much requires the thing to be a PyObjC-based application ("application embedded in python"), instead of an application embedding python. 4) The whole "what version, what extensions" mess that is being discussed here (sometimes I need to use the quartz binding stuff, which precludes other things, for example) 5) The whole "what is the goal/underlying philosophy" problem that is tangentially being discussed here (personally, I write just simple scripts that end up being run on the command line, but I like the "interactive" form that the old PythonIDE & PyOXIDE provide where you can repeatedly run the same script, have an interactive console attached to that name space to examine things, call stuff, etc... which obviously doesn't work the same for somebody building a PyObjC standalone app vs wxPython app vs beginner who just wants to learn how to do something) So given #2, it hasn't been worth my time (#1) to solve #4 & #5 (I've at least got a plan for #5 which should help reduce the scope of #4) and overcome #3. I really should at least release the 2.4 (partial) supporting build, not to mention there are a ton of bug fixes in the underlying IDEKit it's built on... Glenn Andreas gandreas at gandreas.com wicked fun! Widgetarium | the quickest path to widgets From bob at redivi.com Fri Feb 10 18:27:13 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 09:27:13 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <00329A97-797E-49F6-99A0-3147912D92DD@gandreas.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> <43EB98E7.1080801@wordtech-software.com> <00329A97-797E-49F6-99A0-3147912D92DD@gandreas.com> Message-ID: <418BB214-3B67-48C2-8D4C-4DF571F88A26@redivi.com> On Feb 10, 2006, at 7:24 AM, gandreas at gandreas.com wrote: > > On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: >> If I'm a newbie, I'm going to go, "Huh?", then "shrug," and move >> on to >> Realbasic. There needs to be something double-clickable there for a >> newbie to use. PythonIDE, though it had many flaws, was useful this >> way. >> BTW, what happened to PyOXIDE? It had major bugs, but was >> promising as >> a "next-generation" basic IDE for Python development on the Mac. > > > PyOXIDE isn't dead - it's just sleeping. > > Seriously, there are several issues: > > 1) Lack of available time > 2) It mostly does everything _I_ need (I actually use it on a fairly > regular basis, and I have no burning need to add new features) > 3) It needs to basically be re-written - it started as an editor with > python embedded in it (i.e., use the python.framework and the various > python embedding routines). Unfortunately, with 2.4 and the > corresponding PyObjC, that just plain doesn't work well - PyObjC > pretty much requires the thing to be a PyObjC-based application > ("application embedded in python"), instead of an application > embedding python. That's not true, and I've told you the correct way to fix that... That's why py2app can build plugins. -bob From janssen at parc.com Fri Feb 10 18:39:57 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 09:39:57 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Thu, 09 Feb 2006 19:52:46 PST." Message-ID: <06Feb10.094001pst."58633"@synergy1.parc.xerox.com> > > I think this would be a pretty good way to start building a FAQ. > > There already is a FAQ, and it's been there for a very long time. We > don't have to start building anything -- just link to the most > popular ones. Where the heck is it? Bill From bob at redivi.com Fri Feb 10 18:47:29 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 09:47:29 -0800 Subject: [Pythonmac-SIG] uninstall In-Reply-To: <1d987df30602100314k20265eb1tfe854fbc450d1df2@mail.gmail.com> References: <1d987df30602100156o7a697279web2769ae73ce797b@mail.gmail.com> <1d987df30602100255s3958d869qf35b68ea02726f56@mail.gmail.com> <1d987df30602100314k20265eb1tfe854fbc450d1df2@mail.gmail.com> Message-ID: On Feb 10, 2006, at 3:14 AM, linda.s wrote: > On 2/10/06, Bob Ippolito wrote: >> >> On Feb 10, 2006, at 2:55 AM, linda.s wrote: >> >>> On 2/10/06, Bob Ippolito wrote: >>>> >>>> On Feb 10, 2006, at 1:56 AM, linda.s wrote: >>>> >>>>> If I installed some version of python i do not like, how do i >>>>> remove them? >>>>> In windows, it is easy to uninstall them, but no idea about how >>>>> to do >>>>> in Mac (just drag it to the the icon of trashcan?)? >>>> >>>> It depends on which version of Python it is and how you installed >>>> it.. You'll have to be more specific. >>>> >>>> -bob >>> I installed python 2.4.2 from source. >>> Why version matters (curious:))? >> >> The version number is in the path names. Did you install it with "./ >> configure && sudo make install" or "./configure --enable-framework && >> sudo make frameworkinstall"? >> >> -bob > "./configure && sudo make install" That would install these files: /usr/local/bin/python /usr/local/bin/python2.4 /usr/local/bin/pydoc /usr/local/bin/idle /usr/local/bin/smptd.py /usr/local/man/man1/python.1 And these directories: /usr/local/include/python2.4 /usr/local/lib/python2.4 Note that if you have since installed a framework build of Python, then /usr/local/bin/python and /usr/local/bin/python2.4 have already been replaced and you should not delete them. -bob From david.warde.farley at utoronto.ca Fri Feb 10 18:49:07 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Fri, 10 Feb 2006 12:49:07 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb10.094001pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.094001pst."58633"@synergy1.parc.xerox.com> Message-ID: <71F84743-63E1-4D1D-B2A8-4772514EA29E@utoronto.ca> On 10-Feb-06, at 12:39 PM, Bill Janssen wrote: >>> I think this would be a pretty good way to start building a FAQ. >> >> There already is a FAQ, and it's been there for a very long time. We >> don't have to start building anything -- just link to the most >> popular ones. > > Where the heck is it? More to the point, why isn't it on the wiki? :P (My last cry for collaboratively editable documentation apparently fell on deaf ears... ) - Dave From bob at redivi.com Fri Feb 10 18:51:08 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 09:51:08 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb10.094001pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.094001pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 10, 2006, at 9:39 AM, Bill Janssen wrote: >>> I think this would be a pretty good way to start building a FAQ. >> >> There already is a FAQ, and it's been there for a very long time. We >> don't have to start building anything -- just link to the most >> popular ones. > > Where the heck is it? I linked to it in a message to you earlier in this thread, but since you asked: http://pythonmac.org/wiki/FAQ The wiki is linked to from the front page, and the FAQ is the absolute first thing mentioned on the front page of pythonmac.org. Additionally, searching with any of the obvious terms on google is going to bring it up as the first link.. such as "macpython faq" "pythonmac faq" Hell, there's even a link to it from Jack's MacPython page! -bob From janssen at parc.com Fri Feb 10 18:51:29 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 09:51:29 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Thu, 09 Feb 2006 20:17:07 PST." Message-ID: <06Feb10.095136pst."58633"@synergy1.parc.xerox.com> > You seem to have a good handle on what is needed to get new users > involved in working with Python on the Mac. Even some of the > questions that you list here might be a little too complex for new > users. The problem is that there are many kinds of "new users". There are experienced programmers who understand the Mac, and are familiar with, say, Objective-C and Cocoa and Java, but are looking at Python for the first time. They want to know the things that Bob and Ron keep working on, things like "How do a build an app in Python?" and "How do I use Cocoa, or Apple Events, or ... in Python?" or "How do I use Python with Xcode?" And they want the Python tutorial. There are Python programmers coming from Windows or Linux, who want to know primarily how to get Python on their Mac, and what special things about the Mac they need to know to avoid tripping over their feet while using Python. They know about things like site-packages, but not about /Library vs. /System/Library, or frameworks, or various Apple-specific gcc bindings for dynamic linking. Then there are people like Karl described yesterday in his story about the computer teacher descovering Python's turtle graphics, who are looking for low-entry (no installers) ways to do scripting or education. A good entry page tries to speak usefully to all of these communities at the same time, without speaking down to any of them. Bill From janssen at parc.com Fri Feb 10 18:55:43 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 09:55:43 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 07:20:26 PST." Message-ID: <06Feb10.095551pst."58633"@synergy1.parc.xerox.com> > Problem with the official Mac-specific modules and documentation is > there's quite of stuff in there that hasn't been correct/usable since > OS 9. It's just that nobody's gotten around to dealing with > it. Experienced users already know which bits to avoid, so there's not > huge impetus to clean it out properly. Doesn't mean you want to steer > newbies towards it though. It sounds like we should ask the Python-doc folks to remove the Macintosh docs entirely. Maybe post it with appropriate warnings on pythonmac.org instead. Bill From gandreas at gandreas.com Fri Feb 10 19:02:24 2006 From: gandreas at gandreas.com (gandreas at gandreas.com) Date: Fri, 10 Feb 2006 12:02:24 -0600 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <418BB214-3B67-48C2-8D4C-4DF571F88A26@redivi.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> <43EB98E7.1080801@wordtech-software.com> <00329A97-797E-49F6-99A0-3147912D92DD@gandreas.com> <418BB214-3B67-48C2-8D4C-4DF571F88A26@redivi.com> Message-ID: <0CC4AC0B-F68E-4D38-955C-4EC2D0C83008@gandreas.com> On Feb 10, 2006, at 11:27 AM, Bob Ippolito wrote: > > On Feb 10, 2006, at 7:24 AM, gandreas at gandreas.com wrote: > >> >> On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: >>> If I'm a newbie, I'm going to go, "Huh?", then "shrug," and move >>> on to >>> Realbasic. There needs to be something double-clickable there for a >>> newbie to use. PythonIDE, though it had many flaws, was useful this >>> way. >>> BTW, what happened to PyOXIDE? It had major bugs, but was >>> promising as >>> a "next-generation" basic IDE for Python development on the Mac. >> >> >> PyOXIDE isn't dead - it's just sleeping. >> >> Seriously, there are several issues: >> >> 1) Lack of available time >> 2) It mostly does everything _I_ need (I actually use it on a fairly >> regular basis, and I have no burning need to add new features) >> 3) It needs to basically be re-written - it started as an editor with >> python embedded in it (i.e., use the python.framework and the various >> python embedding routines). Unfortunately, with 2.4 and the >> corresponding PyObjC, that just plain doesn't work well - PyObjC >> pretty much requires the thing to be a PyObjC-based application >> ("application embedded in python"), instead of an application >> embedding python. > > That's not true, and I've told you the correct way to fix that... > That's why py2app can build plugins. > > -bob > Perhaps "requires" is too strong a word - how about "is easiest to use if" instead? Still, the current architecture of PyOXIDE (links with Python.framework, and calls the various PyRun_SimpleString, PyRun_SimpleFile and other commands as listed at via various UI callbacks, tries to manage the GIL, etc...) has a high impedance match against the way PyObjC works (since it wants to take care of all the details for you, made worse when _that_ code does UI work). My point is that the better way is just to make PyOXIDE a py2app based creature from the start (and then python code calls the IDE framework), though moving all the python code into py2app generated plugins is an interesting option (with it's own benefits/drawbacks). If it were trivial to fix, I'd have done it already... Glenn Andreas gandreas at gandreas.com wicked fun! Widgetarium | the quickest path to widgets From bob at redivi.com Fri Feb 10 19:03:30 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 10:03:30 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <71F84743-63E1-4D1D-B2A8-4772514EA29E@utoronto.ca> References: <06Feb10.094001pst."58633"@synergy1.parc.xerox.com> <71F84743-63E1-4D1D-B2A8-4772514EA29E@utoronto.ca> Message-ID: <4CC39A83-925E-4E58-B37C-1CE6455B69DF@redivi.com> On Feb 10, 2006, at 9:49 AM, David Warde-Farley wrote: > > On 10-Feb-06, at 12:39 PM, Bill Janssen wrote: > >>>> I think this would be a pretty good way to start building a FAQ. >>> >>> There already is a FAQ, and it's been there for a very long >>> time. We >>> don't have to start building anything -- just link to the most >>> popular ones. >> >> Where the heck is it? > > More to the point, why isn't it on the wiki? :P How did you not find it on the wiki? It's the very first thing linked to on the wiki! -bob From david.warde.farley at utoronto.ca Fri Feb 10 19:08:29 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Fri, 10 Feb 2006 13:08:29 -0500 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <4CC39A83-925E-4E58-B37C-1CE6455B69DF@redivi.com> References: <06Feb10.094001pst."58633"@synergy1.parc.xerox.com> <71F84743-63E1-4D1D-B2A8-4772514EA29E@utoronto.ca> <4CC39A83-925E-4E58-B37C-1CE6455B69DF@redivi.com> Message-ID: <3B2F6FD3-0EFC-47E6-A2AF-424163E4A588@utoronto.ca> Argh. Right. Note to self: actually go check before asking stupid questions. - David On 10-Feb-06, at 1:03 PM, Bob Ippolito wrote: > > On Feb 10, 2006, at 9:49 AM, David Warde-Farley wrote: > >> >> On 10-Feb-06, at 12:39 PM, Bill Janssen wrote: >> >>>>> I think this would be a pretty good way to start building a FAQ. >>>> >>>> There already is a FAQ, and it's been there for a very long >>>> time. We >>>> don't have to start building anything -- just link to the most >>>> popular ones. >>> >>> Where the heck is it? >> >> More to the point, why isn't it on the wiki? :P > > How did you not find it on the wiki? It's the very first thing > linked to on the wiki! > > -bob > From bob at redivi.com Fri Feb 10 19:15:27 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 10:15:27 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.095136pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.095136pst."58633"@synergy1.parc.xerox.com> Message-ID: <190419B8-41FD-4DA3-B704-8FFA89EE7881@redivi.com> On Feb 10, 2006, at 9:51 AM, Bill Janssen wrote: >> You seem to have a good handle on what is needed to get new users >> involved in working with Python on the Mac. Even some of the >> questions that you list here might be a little too complex for new >> users. > > The problem is that there are many kinds of "new users". > > There are experienced programmers who understand the Mac, and are > familiar with, say, Objective-C and Cocoa and Java, but are looking at > Python for the first time. They want to know the things that Bob and > Ron keep working on, things like "How do a build an app in Python?" > and "How do I use Cocoa, or Apple Events, or ... in Python?" or "How > do I use Python with Xcode?" And they want the Python tutorial. > > There are Python programmers coming from Windows or Linux, who want to > know primarily how to get Python on their Mac, and what special things > about the Mac they need to know to avoid tripping over their feet > while using Python. They know about things like site-packages, but > not about /Library vs. /System/Library, or frameworks, or various > Apple-specific gcc bindings for dynamic linking. These two can be presented together.. the second set would be something like "Python differences between Mac OS X and other platforms". > Then there are people like Karl described yesterday in his story about > the computer teacher descovering Python's turtle graphics, who are > looking for low-entry (no installers) ways to do scripting or > education. > > A good entry page tries to speak usefully to all of these communities > at the same time, without speaking down to any of them. Do you really think that there is a large enough audience that would be willing to read pages of documentation, but not be willing to install anything? The situation Karl describes wouldn't have happened by the computer teacher's own hand.. it was only possible because someone knowledgeable was in the room to tell them about Python and also to give them a minimal UNIX crash course. A web page might be ammo for someone like Karl to give out, but it likely wouldn't have done anything for the teacher without Karl. With a downloadable package that sorts out all the issues that need to be documented, then we would be able to skirt the whole issue of the UNIX crash course. Download this package, double-click to install, double-click to start IDLE (or whatever) here. Yes, it might be easier for a teacher with 20 computers to teach rather than install, but how often is that the case? I also think that if we give people the option to use Python without installing anything, then they'll choose that option and be disappointed because the experience with a newer version has a few years more polish and bug fixes... and can simply get them farther because it doesn't have any of the limitations that the pre-installed one has. Another thing to consider would be to do something similar to Movable Python: http://www.voidspace.org.uk/python/movpy/ In this case we would distribute Python as an application, and that application when run by itself could have options to "make this Python the default from Terminal" or something. -bob From janssen at parc.com Fri Feb 10 19:44:02 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 10:44:02 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 10:15:27 PST." <190419B8-41FD-4DA3-B704-8FFA89EE7881@redivi.com> Message-ID: <06Feb10.104411pst."58633"@synergy1.parc.xerox.com> > > A good entry page tries to speak usefully to all of these communities > > at the same time, without speaking down to any of them. > > Do you really think that there is a large enough audience that would > be willing to read pages of documentation, but not be willing to > install anything? No. That's why the *first* page is so important. That's why I put the example of the terminal and "type 'python'" on there. > I also think that if we give people the option to use Python without > installing anything, then they'll choose that option and be > disappointed because the experience with a newer version has a few > years more polish and bug fixes... and can simply get them farther > because it doesn't have any of the limitations that the pre-installed > one has. Not for Python newbies. They've never *seen* the more advanced versions. Python 2.3 all by itself is a pretty nifty programming experience, to someone who's not a developer, but wants to write a script or a simple program. Experienced Python users will of course probably want to install the newer version first. > With a downloadable package that sorts out all the issues that need > to be documented, then we would be able to skirt the whole issue of > the UNIX crash course. Download this package, double-click to > install, double-click to start IDLE (or whatever) here. I agree. If the 2.4.x installer were bundled with TigerPython24Fix and some quick-start IDLE app into a single installer, that would be great, and an improvement over the current situation. (And could it please *not* have the word "fix" in the title?) By the way, Apple seems to believe that the educational environment is important. If someone wanted to write up a page called, "How to get your Mac-using class started with Turtle graphics in 10 minutes", I think that would be a positive contribution. > Another thing to consider would be to do something similar to Movable > Python: > http://www.voidspace.org.uk/python/movpy/ > > In this case we would distribute Python as an application, and that > application when run by itself could have options to "make this > Python the default from Terminal" or something. I like this idea, too. Can we make it happen? Any volunteers? Bill From bob at redivi.com Fri Feb 10 19:53:41 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 10:53:41 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <0CC4AC0B-F68E-4D38-955C-4EC2D0C83008@gandreas.com> References: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> <43EB98E7.1080801@wordtech-software.com> <00329A97-797E-49F6-99A0-3147912D92DD@gandreas.com> <418BB214-3B67-48C2-8D4C-4DF571F88A26@redivi.com> <0CC4AC0B-F68E-4D38-955C-4EC2D0C83008@gandreas.com> Message-ID: <81C06ED1-4D3B-4870-AC21-F858AC858CE9@redivi.com> On Feb 10, 2006, at 10:02 AM, gandreas at gandreas.com wrote: > > On Feb 10, 2006, at 11:27 AM, Bob Ippolito wrote: > >> >> On Feb 10, 2006, at 7:24 AM, gandreas at gandreas.com wrote: >> >>> >>> On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: >>>> If I'm a newbie, I'm going to go, "Huh?", then "shrug," and move >>>> on to >>>> Realbasic. There needs to be something double-clickable there for a >>>> newbie to use. PythonIDE, though it had many flaws, was useful this >>>> way. >>>> BTW, what happened to PyOXIDE? It had major bugs, but was >>>> promising as >>>> a "next-generation" basic IDE for Python development on the Mac. >>> >>> >>> PyOXIDE isn't dead - it's just sleeping. >>> >>> Seriously, there are several issues: >>> >>> 1) Lack of available time >>> 2) It mostly does everything _I_ need (I actually use it on a fairly >>> regular basis, and I have no burning need to add new features) >>> 3) It needs to basically be re-written - it started as an editor >>> with >>> python embedded in it (i.e., use the python.framework and the >>> various >>> python embedding routines). Unfortunately, with 2.4 and the >>> corresponding PyObjC, that just plain doesn't work well - PyObjC >>> pretty much requires the thing to be a PyObjC-based application >>> ("application embedded in python"), instead of an application >>> embedding python. >> >> That's not true, and I've told you the correct way to fix that... >> That's why py2app can build plugins. > > > Perhaps "requires" is too strong a word - how about "is easiest to > use if" instead? > > Still, the current architecture of PyOXIDE (links with > Python.framework, and calls the various PyRun_SimpleString, > PyRun_SimpleFile and other commands as listed at ftp.python.org/doc/ext/embedding.html> via various UI callbacks, > tries to manage the GIL, etc...) has a high impedance match against > the way PyObjC works (since it wants to take care of all the details > for you, made worse when _that_ code does UI work). My point is that > the better way is just to make PyOXIDE a py2app based creature from > the start (and then python code calls the IDE framework), though > moving all the python code into py2app generated plugins is an > interesting option (with it's own benefits/drawbacks). It would work just fine if you were managing all that stuff correctly. PyObjC and py2app definitely manage the GIL correctly with the tests and field experience to prove it... > If it were trivial to fix, I'd have done it already... I didn't say it was trivial, but it doesn't require a rewrite. The majority of the work would be removing code. -bob From bob at redivi.com Fri Feb 10 20:02:42 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 11:02:42 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.104411pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.104411pst."58633"@synergy1.parc.xerox.com> Message-ID: <7A192F89-5B61-4C62-8995-FA4E92D2DA12@redivi.com> On Feb 10, 2006, at 10:44 AM, Bill Janssen wrote: >>> A good entry page tries to speak usefully to all of these >>> communities >>> at the same time, without speaking down to any of them. >> >> Do you really think that there is a large enough audience that would >> be willing to read pages of documentation, but not be willing to >> install anything? > > No. That's why the *first* page is so important. That's why I put > the example of the terminal and "type 'python'" on there. > >> I also think that if we give people the option to use Python without >> installing anything, then they'll choose that option and be >> disappointed because the experience with a newer version has a few >> years more polish and bug fixes... and can simply get them farther >> because it doesn't have any of the limitations that the pre-installed >> one has. > > Not for Python newbies. They've never *seen* the more advanced > versions. Python 2.3 all by itself is a pretty nifty programming > experience, to someone who's not a developer, but wants to write a > script or a simple program. Experienced Python users will of course > probably want to install the newer version first. Yes, but someone who wants to write a script or a simple program and isn't a developer doesn't imply that they're a terminal jockey. If we get them a double-clickable installer that gets them at least IDLE, then they're set and they don't have to learn UNIX in the process. >> With a downloadable package that sorts out all the issues that need >> to be documented, then we would be able to skirt the whole issue of >> the UNIX crash course. Download this package, double-click to >> install, double-click to start IDLE (or whatever) here. > > I agree. If the 2.4.x installer were bundled with TigerPython24Fix > and some quick-start IDLE app into a single installer, that would be > great, and an improvement over the current situation. (And could it > please *not* have the word "fix" in the title?) It *is* a fix, which is no longer necessary with the current branch (or if built on 2.4). Also, the installer has always had IDLE.app. >> Another thing to consider would be to do something similar to Movable >> Python: >> http://www.voidspace.org.uk/python/movpy/ >> >> In this case we would distribute Python as an application, and that >> application when run by itself could have options to "make this >> Python the default from Terminal" or something. > > I like this idea, too. Can we make it happen? Any volunteers? I'd look into it after we get universal framework build with current conventions out the door. -bob From kevino at theolliviers.com Fri Feb 10 20:14:17 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 10 Feb 2006 11:14:17 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <190419B8-41FD-4DA3-B704-8FFA89EE7881@redivi.com> References: <06Feb10.095136pst."58633"@synergy1.parc.xerox.com> <190419B8-41FD-4DA3-B704-8FFA89EE7881@redivi.com> Message-ID: <488D9570-E3B3-4224-A5A0-8376B4A3231A@theolliviers.com> Hi Bob, On Feb 10, 2006, at 10:15 AM, Bob Ippolito wrote: [snip] > Do you really think that there is a large enough audience that would > be willing to read pages of documentation, but not be willing to > install anything? Yes. (Though there shouldn't need to be several pages of docs.) Many users (that I know of) ask themselves the following before downloading software, especially OSS software, and even more so for "non-official" builds: 1) Will this affect my existing install or do something I don't want it to do? 2) Can I uninstall it? 3) Are the promises that 'everything will work fine' on the web site really true? 4) What can I do if it DOES mess up my install and I can't install it / uninstaller doesn't work? Have you ever installed some third-party software that crapped on your machine in one way or another? Unfortunately, for most of us that's a rhetorical question, not a real one. ;-) In OSS, people just deal with this because often they know how to fix it themselves. It just pisses them off and tells them to stay away. For people who are less knowledgeable about that stuff, though, these are scary questions and because they feel they may not be able to correct the issue without a full restore, they don't install things on a whim. Application bundles are far less scary because you can just dump them in the trash, but with this kind of stuff you can't. And note, before *anyone* mistakes me, I'm not saying *anything* about the quality of the MacPython 2.4 package. I use it myself, and I think it's great. And lots of people will download it, no doubt. But new people don't have the sort of background with the community we do. They don't know who's on these lists, what kinds of software they produce, what their standards of quality are, etc. Some of those people would just like to avoid finding out those answers the hard way if they can, and I personally understand that feeling. Some basic information about what problems they could expect with Apple Python would let them prioritize what is most important to them, and what they can expect by going either route. For example, I'd do something like the following for a download section: """ Download the latest Python While Apple includes Python with OS X, their version does not get updated often and contains some bugs and potential issues, and cannot be used to deploy OS X application bundles. For these reasons, many people could benefit from upgrading their Python installation to the latest version from pythonmac.org. For more information, see the FAQ "Differences between Apple's Python and MacPython 2.4?". See also "What should I expect when upgrading to MacPython 2.4?" To upgrade your Python, take the following steps: """ > The situation Karl describes wouldn't have happened by the computer > teacher's own hand.. it was only possible because someone > knowledgeable was in the room to tell them about Python and also to > give them a minimal UNIX crash course. A web page might be ammo for > someone like Karl to give out, but it likely wouldn't have done > anything for the teacher without Karl. > > With a downloadable package that sorts out all the issues that need > to be documented, then we would be able to skirt the whole issue of > the UNIX crash course. Download this package, double-click to > install, double-click to start IDLE (or whatever) here. Yes, it > might be easier for a teacher with 20 computers to teach rather than > install, but how often is that the case? I don't know; do you? What if there are lots of people like that not on these lists? What if they do these things but we just don't hear about it because right now it all just works fine? The community on the mailing lists are typically not representative of the entire community, be it Python or any other OSS project. Many, many people passively use software rather than actively become involved in the community. (This is the only Python list I'm on, for example, and it wasn't until I wanted to help Robin, Stefan and Jack move the wxPythonMac port forward that I was on wx lists either.) These passive users are completely 'under the radar' in terms of what we perceive the community to be, are they not? I'd rather assume many of these people do exist than that they don't, because I'd rather consider and address their needs rather than ignore them. As Ocham's Razor states, simple as possible but no simpler, and if we're just ignoring whole target groups of users, then I think we've moved towards "too simple". And again, I'm not talking about support here, I'm talking about documentation. None of us has to support any user we don't want to support. > I also think that if we give people the option to use Python without > installing anything, then they'll choose that option and be > disappointed because the experience with a newer version has a few > years more polish and bug fixes... and can simply get them farther > because it doesn't have any of the limitations that the pre-installed > one has. I was never disappointed in Apple's Python. (Annoyed at the site- packages move, though.) But we're playing dueling use cases. If you don't hit the bug cases, and don't care about upgrading extensions, you're are pretty much fine. If not, you're disappointed. Simple as that. Let's not tell users "we know what's best for you". Frankly, even though I use MacPython 2.4 now (due to a need to upgrade), I used Python 2.3 just fine for a long time even under Tiger, and all this business about me being 'disappointed' never materialized; I was perfectly happy with it and it made me wonder why people were so intent on telling me not to use something that works perfectly fine for me. I think it discredits us to have this attitude of "Apple's Python doesn't work at all", because when people try it and it does work (as it did for me), it looks like we're just showing an irrational bias. If we instead gave them specific information about what doesn't work, for Apple Python with the latest Tiger and Panther releases (some of which I didn't know until yesterday!), and that MacPython 2.4 fixes these problems, I think we'd come across as helpful and supportive instead. Python users are newbies, but not children. They're ability to think is just fine, they just need information, in a clear, concise, and jargon-free format, about the products to make an informed decision. Teaching a Python to fish rather than giving them a fish, and all that. ;-) You already wrote a lot of the 'documentation' for this, someone just needs to gather it up and put whatever's not there yet into the FAQ, and most importantly, make that FAQ visible from python.org. We can avoid cluttering the front page with all sorts of information for special cases by creating links rather than writing paragraph upon paragraph. People do click on links, and if we make good use of them the front page doesn't have to look complex and cluttered. That's what links were made for. :-) Thanks, Kevin > Another thing to consider would be to do something similar to Movable > Python: > http://www.voidspace.org.uk/python/movpy/ > > In this case we would distribute Python as an application, and that > application when run by itself could have options to "make this > Python the default from Terminal" or something. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From rodneys at io.com Fri Feb 10 20:24:53 2006 From: rodneys at io.com (Rodney Somerstein) Date: Fri, 10 Feb 2006 14:24:53 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.095136pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.095136pst."58633"@synergy1.parc.xerox.com> Message-ID: At 9:51 AM -0800 2/10/06, Bill Janssen wrote: >The problem is that there are many kinds of "new users". > This is true. The trick, in my view, is to make sure to define terms when they are first used. That way, the actual beginners have a chance of following along and the more experienced "new users" will skim over that sentence or two and get to the meat of what they are trying to find out. I don't see any other useful way to serve everyone on a single getting started page without either setting the bar too high for true newbies or frustrating the more experienced folks. Links to pages for more detailed explanations can prevent the basic definitions from taking up too much room. But a simple sentence or two of introduction to each topic with novices in mind will go a long way toward eliminating assumptions of what people know. -Rodney From vinogri at mcmaster.ca Fri Feb 10 20:50:49 2006 From: vinogri at mcmaster.ca (I. Vinogradov) Date: Fri, 10 Feb 2006 14:50:49 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb8.202938pst."58633"@synergy1.parc.xerox.com> Message-ID: On Wed, 8 Feb 2006 20:29:34 PST Bill Janssen wrote: > I've made up a sample page, at > http://bill.janssen.org/new-macpython-page.html. > > This is the kind of thing I'd like to see replace the page at > http://www.python.org/download/download_mac.html. > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig My Powerbook is gone for repairs, nothing much to do without it, so I have added some shapes and colours to Bill Janssen's page: https://univmail.cis.mcmaster.ca/~vinogri/mp/default.html I take no credit for this whatsoever, just hoping it will be useful as a template for pythonmac.org. Naturally, without Mac it's hard to make pictures, otherwise there would be more detailed instructions. Cheers, Ivan. From Chris.Barker at noaa.gov Fri Feb 10 20:58:00 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 10 Feb 2006 11:58:00 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb8.202938pst.58633@synergy1.parc.xerox.com> Message-ID: <43ECF048.5070503@noaa.gov> Rodney Somerstein wrote: > . It would be > really nice to have a more basic introduction to what py2app actually > does. Why don't you write that, put it in the Wiki, then ask this list for technical review. That's what Wikis are for, and I think often recent newbies are the best people to write newbie docs, when you still remember what questions you have. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Fri Feb 10 21:37:55 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 10 Feb 2006 12:37:55 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> Message-ID: <43ECF9A3.1090202@noaa.gov> Bob Ippolito wrote: >> Let's have py2app be a standard part of the 2.4 package. It'd be great >> if the standard upgrade package had and did everything you need to get >> started. I suggest easy-install as well. > > I'd prefer to wait on that until it's more mature. Why? it's what we use now, and it's the best there is. Anyone wanting to create stand-alones is going to need it. There's always room for it to be upgraded in the future. >Shipping setuptools isn't a bad idea, but it's a one-liner to install it.. Yes, but it then puts the scripts in the weird bin directory buried in the Framework, and one extra step is one extra step too many. > The extension thing we can hack around by installing two copies of the > Makefile and having distutils pick a PPC-only Makefile if it detects 10.3. OK. as long as that hack is built in to the installer, that's great. > It might be a good idea to highlight the really frequent FAQs and link > to their answers on the wiki. Absolutely I think that page should largely be a bunch of links to the Wiki. > Well we might as well just crib the script from DarwinPorts and change > the paths... Why not just add it to the PATH for all the common shells. It's not going to hurt me to have my .cshrc edited (or created) if I use bash, and then if I ever switch shells there it is. > Since we're going to manipulating the PATH with the installer, should > we still bother with the symlinks in /usr/local/bin? We definitely > want the Framework's bin dir on the PATH because that's where scripts > will be installed to... so the /usr/local/bin links seem a bit > redundant. If we do this, then the Python installation process is > completely self-contained except for the Applications dir. hmmm. In general, I'm not thrilled with every app creating it's own addition to the PATH, it reminds me of DOS pain. I really like that in *nix, there are only a few, standard, places for executables. Given that, another option is to Create a ~/.pydistutils.cfg file with: --------------------------------------------- [easy_install] script_dir = /usr/local/bin --------------------------------------------- or whatever is appropriate. That may be getting too complicated, however. > The problem is that there are many kinds of "new users". > > There are experienced programmers who understand the Mac, > There are Python programmers coming from Windows or Linux, > A good entry page tries to speak usefully to all of these communities > at the same time, without speaking down to any of them. I think the solution is to start out with a decision tree right at the start: If you are an experienced programmer who understand the Mac: If you are Python programmers coming from Windows or Linux: etc.... -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Fri Feb 10 21:58:00 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 10 Feb 2006 12:58:00 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43EC96E4.9030901@anvil.nrl.navy.mil> References: <06Feb9.155625pst.58633@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> <43EC96E4.9030901@anvil.nrl.navy.mil> Message-ID: <43ECFE58.9070404@noaa.gov> Louis Pecora wrote: > This seems to be where this argument goes: the user/newbies vs. the > developers. I don't think so. This entire conversation is about supporting the newbies. The disagreements are about how best to do that. > You shouldn't be forcing everyone to adopt a python system > that then suits your marketing model. I know why I'm pushing for the "Install the 2.4 version" approach, and it's precisely to support newbies, not to fit a marketing model. If we make it clear that there is one "Standard" way to do python on the Mac, then it's easier for everyone: - Newbies don't have to make a decision they don't understand the implications of. - We don't have to field questions about more than one version. - When they need to add an extension package, there is only one set of pre-built packages to look at. - Extension package builders and maintainers only need to target one version, and as a result, more packages will work on the Mac. (you should see what's in the matplotlib setup.py: a fragile mess inside the "darwin" section, looking around for whether you're running fink, or darwinports, etc. so that libs can be found. What a pain!) Those are some of the reasons that I think we need to establish a single, standard, "Recommended by the MacPython community" version. The Apple python is simply not an option as that standard (for reasons very well discussed here!), so Bob's build is it, unless someone else steps up to make something different. None of this helps the power users: we can go build our own from source, use fink, whatever. Now the marketing: yes, the smaller the barrier to entry to getting someone hooked, the better. On some level, I generally prefer to get people started with an approach that will carry them far, rather than the easiest way to get started, then tell them they need to do it differently as they get going. However, I do think there is a real advantage to showing people a bit about python without them having to download or install something. I think we can accomplish this on the main page of pythonmac.org, with a link something like: New to Python? The 30 second quick start: That will link to a Wiki page that tells people how to fire up the terminal and print hello world, maybe do a mini wx app: there have been some good suggestions on this thread already. At the end of maybe 15 minutes worth (or maybe more, I'm not sure what's best) of getting started, point them to a page that talks about what kind of extension packages there are, and advise about why and how to install a new version. The goal is to show just enough to get newbies interested, then set them up with a system that will carry them well into their python career. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Fri Feb 10 21:59:49 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 10 Feb 2006 12:59:49 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <1C83B77D-5156-4FFB-99B8-525459118D39@conncoll.edu> References: <06Feb9.155625pst.58633@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> <43EC96E4.9030901@anvil.nrl.navy.mil> <1C83B77D-5156-4FFB-99B8-525459118D39@conncoll.edu> Message-ID: <43ECFEC5.8000004@noaa.gov> Charles Hartman wrote: > It seems to me (as *much* closer to a newbie than a developer) that > simply recommending the download & install of Python 2.4.x not only > wouldn't put a major obstacle in the way of beginners, but wouldn't > seem to, either. Exactly. It's not like anyone but Linux users expects everything to be pre-installed on their machine! You have to download something to try out RealBasic, or whatever, as well. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From njriley at uiuc.edu Fri Feb 10 22:00:12 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri, 10 Feb 2006 15:00:12 -0600 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43ECF9A3.1090202@noaa.gov> References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> <43ECF9A3.1090202@noaa.gov> Message-ID: <20060210210012.GA24833@uiuc.edu> On Fri, Feb 10, 2006 at 12:37:55PM -0800, Christopher Barker wrote: > Yes, but it then puts the scripts in the weird bin directory buried in > the Framework, and one extra step is one extra step too many. This definitely needs to be a FAQ, at least, if not a changed default in the Python framework install. I've seen this catch a large number of people using Python web apps that install scripts for management, such as Trac, TurboGears and so forth. Even if we could just recommend a ~/.pydistutils.cfg like this: [install] install_scripts = /usr/local/bin we'd be better off. -- Nicholas Riley | From sw at wordtech-software.com Fri Feb 10 22:06:20 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri, 10 Feb 2006 16:06:20 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43ECFE58.9070404@noaa.gov> References: <06Feb9.155625pst.58633@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> <43EC96E4.9030901@anvil.nrl.navy.mil> <43ECFE58.9070404@noaa.gov> Message-ID: <43ED004C.9070403@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Barker wrote: > Louis Pecora wrote: >> This seems to be where this argument goes: the user/newbies vs. the >> developers. > > I don't think so. This entire conversation is about supporting the > newbies. The disagreements are about how best to do that. > >> You shouldn't be forcing everyone to adopt a python system >> that then suits your marketing model. > > I know why I'm pushing for the "Install the 2.4 version" approach, and > it's precisely to support newbies, not to fit a marketing model. > > If we make it clear that there is one "Standard" way to do python on the > Mac, then it's easier for everyone: > > - Newbies don't have to make a decision they don't understand the > implications of. > > - We don't have to field questions about more than one version. > > - When they need to add an extension package, there is only one set of > pre-built packages to look at. > > - Extension package builders and maintainers only need to target one > version, and as a result, more packages will work on the Mac. (you > should see what's in the matplotlib setup.py: a fragile mess inside the > "darwin" section, looking around for whether you're running fink, or > darwinports, etc. so that libs can be found. What a pain!) > > Those are some of the reasons that I think we need to establish a > single, standard, "Recommended by the MacPython community" version. +1 for what Chris is advocating here. A good model for this is Tk Aqua: see http://tcltkaqua.sourceforge.net. For the past few years this has been the standard way to get the "latest and greatest" Tcl/Tk for the Mac. It's been superseded a bit by ActiveState's distribution, but because ActiveState has licensing restrictions, that's not for everyone. ActivePython is also an example to consider that's a little more relevant. Not to recommend ActivePython itself, as its licensing is more restrictive than the build that will result from this discussion, but it is a self-contained, easily-installed, well-documented, and up-to-date bundle of Python and packages. - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD7QBMJmdQs+6YVcoRAjwhAJ4hBw+Ne2VGWQ+/jsH1Wh8MYGka9QCcCwyA D5oEKIwaFMLXgy/juNZPGEA= =J/8l -----END PGP SIGNATURE----- From bob at redivi.com Fri Feb 10 22:29:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 13:29:12 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <20060210210012.GA24833@uiuc.edu> References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> <43ECF9A3.1090202@noaa.gov> <20060210210012.GA24833@uiuc.edu> Message-ID: On Feb 10, 2006, at 1:00 PM, Nicholas Riley wrote: > On Fri, Feb 10, 2006 at 12:37:55PM -0800, Christopher Barker wrote: >> Yes, but it then puts the scripts in the weird bin directory >> buried in >> the Framework, and one extra step is one extra step too many. > > This definitely needs to be a FAQ, at least, if not a changed default > in the Python framework install. I've seen this catch a large number > of people using Python web apps that install scripts for management, > such as Trac, TurboGears and so forth. Even if we could just > recommend a ~/.pydistutils.cfg like this: > > [install] > install_scripts = /usr/local/bin > > we'd be better off. My current plan is to add the framework's bin path to the installer's post-flight. Pros: We can skip /usr/local/bin entirely and avoid the chance that the user wants other things in /usr/local/bin to come in a different order on PATH. We don't have to tweak a single distutils setting Cons: Different than what we do now Transitionally, probably the right answer is to keep the symlinks in / usr/local/bin, but only put the framework's bin dir on the PATH. -bob From bob at redivi.com Fri Feb 10 22:53:18 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 13:53:18 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43ED004C.9070403@wordtech-software.com> References: <06Feb9.155625pst.58633@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> <43EC96E4.9030901@anvil.nrl.navy.mil> <43ECFE58.9070404@noaa.gov> <43ED004C.9070403@wordtech-software.com> Message-ID: <8635252A-6BC3-4826-BA11-A11DF55668F0@redivi.com> On Feb 10, 2006, at 1:06 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Christopher Barker wrote: >> Louis Pecora wrote: >>> This seems to be where this argument goes: the user/newbies vs. the >>> developers. >> >> I don't think so. This entire conversation is about supporting the >> newbies. The disagreements are about how best to do that. >> >>> You shouldn't be forcing everyone to adopt a python system >>> that then suits your marketing model. >> >> I know why I'm pushing for the "Install the 2.4 version" approach, >> and >> it's precisely to support newbies, not to fit a marketing model. >> >> If we make it clear that there is one "Standard" way to do python >> on the >> Mac, then it's easier for everyone: >> >> - Newbies don't have to make a decision they don't understand the >> implications of. >> >> - We don't have to field questions about more than one version. >> >> - When they need to add an extension package, there is only one >> set of >> pre-built packages to look at. >> >> - Extension package builders and maintainers only need to target one >> version, and as a result, more packages will work on the Mac. (you >> should see what's in the matplotlib setup.py: a fragile mess >> inside the >> "darwin" section, looking around for whether you're running fink, or >> darwinports, etc. so that libs can be found. What a pain!) >> >> Those are some of the reasons that I think we need to establish a >> single, standard, "Recommended by the MacPython community" version. > > +1 for what Chris is advocating here. > > A good model for this is Tk Aqua: see http:// > tcltkaqua.sourceforge.net. > For the past few years this has been the standard way to get the > "latest and greatest" Tcl/Tk for the Mac. It's been superseded a > bit by > ActiveState's distribution, but because ActiveState has licensing > restrictions, that's not for everyone. > > ActivePython is also an example to consider that's a little more > relevant. Not to recommend ActivePython itself, as its licensing is > more > restrictive than the build that will result from this discussion, > but it > is a self-contained, easily-installed, well-documented, and up-to-date > bundle of Python and packages. The licensing issues with ActivePython were clarified last year: It is explicitly legal to redistribute self-contained application bundles (a la py2exe or py2app) built with ActiveState's distributions. This gives it a leg up on Apple's distro (which has no such clause; components of OS X are not redistributable), and makes it a candidate Python distribution for almost anyone. Personally, I have tried it out a bit on one of my machines and found a couple bugs that were quickly resolved. Nothing outstanding and nothing major, and the turnaround was quick. Currently, ActivePython on Mac OS X is almost exactly the same thing that we're going to be shipping with the universal build of 2.4.2. The differences will be: 1. They aren't shipping readline, we will 2. We'll probably ship universal first 3. I don't believe they have the PATH hack in their installer 4. They ship with an ActivePython icon for pythonw, we'll stick with the current icon. Currently, ActivePython's 2.4.2 distro is a pretty good solution over our 2.4.1 because it doesn't require the OS X 10.4 fix and it's Python 2.4.2 instead of 2.4.1... The other differences are negligible other than the fact that we ship readline and they don't. On Win32, there is more of a reason to use ActivePython because they ship win32all and its IDE (which is different from IDLE). Of course, that's just an install away with the python.org distro, but it's one less step. This would be roughly equivalent to us shipping PyObjC for Mac I guess. -bob From bob at redivi.com Fri Feb 10 23:09:05 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 14:09:05 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <8635252A-6BC3-4826-BA11-A11DF55668F0@redivi.com> References: <06Feb9.155625pst.58633@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> <43EC96E4.9030901@anvil.nrl.navy.mil> <43ECFE58.9070404@noaa.gov> <43ED004C.9070403@wordtech-software.com> <8635252A-6BC3-4826-BA11-A11DF55668F0@redivi.com> Message-ID: <48A9D8E6-D10F-4C4E-86A3-F1FEA289493B@redivi.com> On Feb 10, 2006, at 1:53 PM, Bob Ippolito wrote: > > On Feb 10, 2006, at 1:06 PM, Kevin Walzer wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Christopher Barker wrote: >>> Louis Pecora wrote: >>>> This seems to be where this argument goes: the user/newbies vs. >>>> the >>>> developers. >>> >>> I don't think so. This entire conversation is about supporting the >>> newbies. The disagreements are about how best to do that. >>> >>>> You shouldn't be forcing everyone to adopt a python system >>>> that then suits your marketing model. >>> >>> I know why I'm pushing for the "Install the 2.4 version" approach, >>> and >>> it's precisely to support newbies, not to fit a marketing model. >>> >>> If we make it clear that there is one "Standard" way to do python >>> on the >>> Mac, then it's easier for everyone: >>> >>> - Newbies don't have to make a decision they don't understand the >>> implications of. >>> >>> - We don't have to field questions about more than one version. >>> >>> - When they need to add an extension package, there is only one >>> set of >>> pre-built packages to look at. >>> >>> - Extension package builders and maintainers only need to target one >>> version, and as a result, more packages will work on the Mac. (you >>> should see what's in the matplotlib setup.py: a fragile mess >>> inside the >>> "darwin" section, looking around for whether you're running fink, or >>> darwinports, etc. so that libs can be found. What a pain!) >>> >>> Those are some of the reasons that I think we need to establish a >>> single, standard, "Recommended by the MacPython community" version. >> >> +1 for what Chris is advocating here. >> >> A good model for this is Tk Aqua: see http:// >> tcltkaqua.sourceforge.net. >> For the past few years this has been the standard way to get the >> "latest and greatest" Tcl/Tk for the Mac. It's been superseded a >> bit by >> ActiveState's distribution, but because ActiveState has licensing >> restrictions, that's not for everyone. >> >> ActivePython is also an example to consider that's a little more >> relevant. Not to recommend ActivePython itself, as its licensing is >> more >> restrictive than the build that will result from this discussion, >> but it >> is a self-contained, easily-installed, well-documented, and up-to- >> date >> bundle of Python and packages. > > The licensing issues with ActivePython were clarified last year: It > is explicitly legal to redistribute self-contained application > bundles (a la py2exe or py2app) built with ActiveState's > distributions. This gives it a leg up on Apple's distro (which has > no such clause; components of OS X are not redistributable), and > makes it a candidate Python distribution for almost anyone. > Personally, I have tried it out a bit on one of my machines and found > a couple bugs that were quickly resolved. Nothing outstanding and > nothing major, and the turnaround was quick. > > Currently, ActivePython on Mac OS X is almost exactly the same thing > that we're going to be shipping with the universal build of 2.4.2. > The differences will be: > > 1. They aren't shipping readline, we will > 2. We'll probably ship universal first > 3. I don't believe they have the PATH hack in their installer > 4. They ship with an ActivePython icon for pythonw, we'll stick with > the current icon. 5. We're also shipping some bug fixes that aren't in Python yet, like doing the select.poll check at runtime instead of configure time. Mac OS X 10.4.4 has a fully working poll implementation, but I believe some point version back in the day didn't. Some applications depend on select.poll and associated constants being there. I can't think of anything open source at the moment, but I know people who have internal apps that depend on poll because it has higher performance for their deployment environment. -bob From janssen at parc.com Fri Feb 10 23:11:24 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 14:11:24 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 11:50:49 PST." Message-ID: <06Feb10.141131pst."58633"@synergy1.parc.xerox.com> Nice, thanks! Bill From janssen at parc.com Fri Feb 10 23:22:49 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 14:22:49 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 11:02:42 PST." <7A192F89-5B61-4C62-8995-FA4E92D2DA12@redivi.com> Message-ID: <06Feb10.142256pst."58633"@synergy1.parc.xerox.com> > If we get them a double-clickable installer that gets them at least > IDLE, then they're set and they don't have to learn UNIX in the process. I agree. It looks like one good thing to do would be to build an installer that installs a regular App that's just a wrapper around IDLE (and uses the system Python). People who just want to try Python but don't want to install a complete separate version could use this. Though it sounds like there are some technical issues about "just running" IDLE on 10.3 and 10.4. Maybe this can't be done. The upgrade installer should also include and install such an App, but this App (though looking identical to the other) would use the 2.4.x upgrade install of Python. Bill From Chris.Barker at noaa.gov Fri Feb 10 23:28:01 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 10 Feb 2006 14:28:01 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <8635252A-6BC3-4826-BA11-A11DF55668F0@redivi.com> References: <06Feb9.155625pst.58633@synergy1.parc.xerox.com> <6B55EB60-3328-428A-80C8-F77BEC7D743A@redivi.com> <9AAE4BA1-97F7-4EEA-9229-B08DA82C0230@redivi.com> <43EC96E4.9030901@anvil.nrl.navy.mil> <43ECFE58.9070404@noaa.gov> <43ED004C.9070403@wordtech-software.com> <8635252A-6BC3-4826-BA11-A11DF55668F0@redivi.com> Message-ID: <43ED1371.1020200@noaa.gov> Bob Ippolito wrote: > Currently, ActivePython on Mac OS X is almost exactly the same thing > that we're going to be shipping with the universal build of 2.4.2. The > differences will be: > > 1. They aren't shipping readline, we will This matters quite a bit, I think. > 2. We'll probably ship universal first Always good to be on the bleeding edge! > 3. I don't believe they have the PATH hack in their installer That matters too: we've spent enough time nattering on about that to prove it! > 4. They ship with an ActivePython icon for pythonw, we'll stick with the > current icon. I don't give a *&&^^& what the icon is. I don't know why, but somehow I feel better about depending on Bob I., than I do about depending on ActiveState. As long as Bob os willing to build what we've been discussing, I say we go with that. There does need to be a mention of other Python installers somewhere anyway, and ActiveState should certainly be listed. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From janssen at parc.com Fri Feb 10 23:31:50 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 14:31:50 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 11:02:42 PST." <7A192F89-5B61-4C62-8995-FA4E92D2DA12@redivi.com> Message-ID: <06Feb10.143151pst."58633"@synergy1.parc.xerox.com> > > I agree. If the 2.4.x installer were bundled with TigerPython24Fix > > and some quick-start IDLE app into a single installer, that would be > > great, and an improvement over the current situation. (And could it > > please *not* have the word "fix" in the title?) > > It *is* a fix, which is no longer necessary with the current branch > (or if built on 2.4). Does that mean that if I download the 2.4.x upgrade installer and run it on my 10.4.4 machine, I do not need to run the TigerPython24Fix? Why do I need to run it separately anyway? Why isn't just part of the regular upgrade installer, run if necessary? And for that matter, why not include TigerPython23Compat as part of the MacPython installer? And how about bundling tcltkaqua into it, as well? > Also, the installer has always had IDLE.app. I'm glad to hear that about IDLE.app. But I'm depressed again when I read pages like http://rlai.cs.ualberta.ca/RLAI/RLsoftware/PythonLinks.html#IDLE. My impression from reading that is that MacPython IDLE.app is extensively broken. Bill From bob at redivi.com Fri Feb 10 23:34:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 14:34:53 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.142256pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.142256pst."58633"@synergy1.parc.xerox.com> Message-ID: <1710742E-883B-4C93-886C-2F9354E84AE9@redivi.com> On Feb 10, 2006, at 2:22 PM, Bill Janssen wrote: >> If we get them a double-clickable installer that gets them at least >> IDLE, then they're set and they don't have to learn UNIX in the >> process. > > I agree. It looks like one good thing to do would be to build an > installer that installs a regular App that's just a wrapper around > IDLE (and uses the system Python). People who just want to try Python > but don't want to install a complete separate version could use this. > Though it sounds like there are some technical issues about "just > running" IDLE on 10.3 and 10.4. Maybe this can't be done. 10.3 doesn't ship with Tkinter at all, so it can't be done there without also installing Tcl/Tk Aqua. We'd have to document that for users of Mac OS X 10.3; I don't want to bundle it. -bob From janssen at parc.com Fri Feb 10 23:34:50 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 14:34:50 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 12:59:49 PST." <43ECFEC5.8000004@noaa.gov> Message-ID: <06Feb10.143456pst."58633"@synergy1.parc.xerox.com> > Charles Hartman wrote: > > It seems to me (as *much* closer to a newbie than a developer) that > > simply recommending the download & install of Python 2.4.x not only > > wouldn't put a major obstacle in the way of beginners, but wouldn't > > seem to, either. > > Exactly. It's not like anyone but Linux users expects everything to be > pre-installed on their machine! You have to download something to try > out RealBasic, or whatever, as well. > > -Chris I don't know about that. The Mac philosophy is something like, "It just works". I hear that a lot from new Mac users around here. Bill From janssen at parc.com Fri Feb 10 23:37:09 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 14:37:09 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 13:53:18 PST." <8635252A-6BC3-4826-BA11-A11DF55668F0@redivi.com> Message-ID: <06Feb10.143712pst."58633"@synergy1.parc.xerox.com> > This would be roughly equivalent to us shipping PyObjC for Mac I guess. Which I'd recommend. Bill From bob at redivi.com Fri Feb 10 23:58:51 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 14:58:51 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.143151pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.143151pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 10, 2006, at 2:31 PM, Bill Janssen wrote: >>> I agree. If the 2.4.x installer were bundled with TigerPython24Fix >>> and some quick-start IDLE app into a single installer, that would be >>> great, and an improvement over the current situation. (And could it >>> please *not* have the word "fix" in the title?) >> >> It *is* a fix, which is no longer necessary with the current branch >> (or if built on 2.4). > > Does that mean that if I download the 2.4.x upgrade installer and run > it on my 10.4.4 machine, I do not need to run the TigerPython24Fix? > > Why do I need to run it separately anyway? Why isn't just part of the > regular upgrade installer, run if necessary? I'm tired of saying this. ONE last time. TigerPython24Fix fixes a bug in the current release (it's questionable as to if it's a bug in 10.4, or the build of 2.4, but it's a bug nonetheless). Discussing this is completely irrelevant because it's an already solved issue. Please forget it exists - I'm tired of discussing it. > And for that matter, why not include TigerPython23Compat as part of > the MacPython installer? TigerPython23Compat allows OS X 10.4's installation Python 2.3 to use packages built with OS X 10.3. Not very relevant to a Python 2.4. > And how about bundling tcltkaqua into it, as well? Tcl/Tk Aqua ships with OS X 10.4 and it's a relatively large dependency to just include for the sake of OS X 10.3 users. >> Also, the installer has always had IDLE.app. > > I'm glad to hear that about IDLE.app. But I'm depressed again when I > read pages like > http://rlai.cs.ualberta.ca/RLAI/RLsoftware/PythonLinks.html#IDLE. My > impression from reading that is that MacPython IDLE.app is extensively > broken. Those are reasons not to use IDLE with the built-in Python 2.3. Those issues are all trivial to fix for any build that we produce. -bob From bob at redivi.com Sat Feb 11 00:15:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 15:15:12 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.143456pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.143456pst."58633"@synergy1.parc.xerox.com> Message-ID: <959EC80A-66B2-4D92-ADFC-560AD454E844@redivi.com> On Feb 10, 2006, at 2:34 PM, Bill Janssen wrote: >> Charles Hartman wrote: >>> It seems to me (as *much* closer to a newbie than a developer) that >>> simply recommending the download & install of Python 2.4.x not only >>> wouldn't put a major obstacle in the way of beginners, but wouldn't >>> seem to, either. >> >> Exactly. It's not like anyone but Linux users expects everything >> to be >> pre-installed on their machine! You have to download something to try >> out RealBasic, or whatever, as well. > > I don't know about that. The Mac philosophy is something like, "It > just works". I hear that a lot from new Mac users around here. Working properly and shipping with everything you could possibly need are two entirely different things. When they download RealBasic it just works, but it didn't come with their Mac. When they download the new Python 2.4 framework, it will be closer to just working -- but it won't be fully Mac-like until there's the "movable python" inspired version available that does not have a required installation procedure. The Python 2.3 build that ships with 10.3 and 10.4 definitely does not "just work" unless you're looking to do purely UNIX based things and you don't need to use distutils (e.g. by default scripts go to / System/.../nowhere/bin which requires root to install to and doesn't live on the PATH). The current Python 2.4.x releases aren't a hell of a lot better at "just working", but the Python 2.4 builds we *will* be shipping do a much better job approximating that ideology (PATH hack, better documentation, fixes to distutils and the installation layout, etc.). Personally I don't find Linux to "just work" at all as a developer. If I need a package outside of their package management system I have to go f*!(ing crazy figuring out which *-dev packages i need to install in order to get it to configure and make install correctly. I often need "bleeding edge" software such as the latest Python and PostgreSQL release. Maybe I just hate Debian, this probably isn't an issue with all (most?) Linux distributions. *BSD and Mac OS X don't have this problem because they ship packages with all the headers and such installed. Much easier to get what I need done. -bob From janssen at parc.com Sat Feb 11 00:15:07 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 15:15:07 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 11:14:17 PST." <488D9570-E3B3-4224-A5A0-8376B4A3231A@theolliviers.com> Message-ID: <06Feb10.151517pst."58633"@synergy1.parc.xerox.com> > For these reasons, many > people could benefit from upgrading their Python installation to the > latest version from pythonmac.org. For more information, see the FAQ > "Differences between Apple's Python and MacPython 2.4?". See also > "What should I expect when upgrading to MacPython 2.4?" To upgrade > your Python, take the following steps: Kevin, That would be a great addition! Could you please make these pages exist in the Wiki and add FAQ entries to point to them? Thanks! Bill From janssen at parc.com Sat Feb 11 00:37:30 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 15:37:30 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 13:53:18 PST." <8635252A-6BC3-4826-BA11-A11DF55668F0@redivi.com> Message-ID: <06Feb10.153732pst."58633"@synergy1.parc.xerox.com> I've put up a new page, with a slightly different address: http://bill.janssen.org/mac/new-macpython-page.html. It includes pointers to the Wiki and the FAQ, leads with the suggestion to upgrade, keeps the simple example, but drops the use of IDLE, and no longer points to the (seriously damaged) existing standard MacPython documentation. Bill From Chris.Barker at noaa.gov Sat Feb 11 00:47:38 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 10 Feb 2006 15:47:38 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.143456pst.58633@synergy1.parc.xerox.com> References: <06Feb10.143456pst.58633@synergy1.parc.xerox.com> Message-ID: <43ED261A.7090604@noaa.gov> Bill Janssen wrote: > I don't know about that. The Mac philosophy is something like, "It > just works". I hear that a lot from new Mac users around here. Linux users expect it to be installed already, or come with their distro, but don't expect it to work without tweaking config files. ;-) Mac users expect to have to buy it or download it and install it, but then expect it to "just work". That's changed a bit with OS-X and all the nice i* apps, but you still can't get that much "real work" done on a Mac without installing some software. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Sat Feb 11 00:50:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 15:50:44 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.153732pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.153732pst."58633"@synergy1.parc.xerox.com> Message-ID: <1D846C4F-88DD-4075-9010-8A7FD1DCCBDA@redivi.com> On Feb 10, 2006, at 3:37 PM, Bill Janssen wrote: > I've put up a new page, with a slightly different address: > > http://bill.janssen.org/mac/new-macpython-page.html. > > It includes pointers to the Wiki and the FAQ, leads with the > suggestion to upgrade, keeps the simple example, but drops the use of > IDLE, and no longer points to the (seriously damaged) existing > standard MacPython documentation. For reference: 10.0 - Cheetah 10.1 - Puma 10.2 - Jaguar 10.3 - Panther 10.4 - Jaguar 10.5 - Leopard Also, the trademark is "Mac OS X" not "MacOS X" or "Mac-OS/X" or "MACOSX" ;) -bob From charles.hartman at conncoll.edu Sat Feb 11 01:40:18 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri, 10 Feb 2006 19:40:18 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.143151pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.143151pst."58633"@synergy1.parc.xerox.com> Message-ID: <761513FC-21FB-4F29-9CD7-35384482A2C1@conncoll.edu> On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: > And how about bundling tcltkaqua into it, as well? Because some of us, at least, have no interest in tcl. I'm not clear whether its presence interferes with wx (thing #421 that I'm not clear about), but it doesn't help; why should I want it on my system? The answer might be, because Apple puts it in their (therefore in mine). Is that true? Anyway I'm not clear about the logic of this. Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060210/672dd796/attachment.html From charles.hartman at conncoll.edu Sat Feb 11 01:43:05 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri, 10 Feb 2006 19:43:05 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.143456pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.143456pst."58633"@synergy1.parc.xerox.com> Message-ID: On Feb 10, 2006, at 5:34 PM, Bill Janssen wrote: >> Charles Hartman wrote: >>> It seems to me (as *much* closer to a newbie than a developer) that >>> simply recommending the download & install of Python 2.4.x not only >>> wouldn't put a major obstacle in the way of beginners, but wouldn't >>> seem to, either. >> >> Exactly. It's not like anyone but Linux users expects everything >> to be >> pre-installed on their machine! You have to download something to try >> out RealBasic, or whatever, as well. >> >> -Chris > > I don't know about that. The Mac philosophy is something like, "It > just works". I hear that a lot from new Mac users around here. The audience we're imagining is one looking to branch out a little -- into programming, to begin with, into Python in particular. If that involves downloading something, that's perfectly familiar territory. If I were a Mac user interested in a new approach to word processing I'd expect to download Nisus Writer, or whatever. (For that matter, Word doesn't come free on Macs.) I think the Python is parallel, from that psychological standpoint. (The fact that Apple ships a version of Python is a red herring here.) Charles From janssen at parc.com Sat Feb 11 02:22:21 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 17:22:21 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 15:50:44 PST." <1D846C4F-88DD-4075-9010-8A7FD1DCCBDA@redivi.com> Message-ID: <06Feb10.172227pst."58633"@synergy1.parc.xerox.com> > For reference: > > 10.0 - Cheetah > 10.1 - Puma > 10.2 - Jaguar > 10.3 - Panther > 10.4 - Jaguar > 10.5 - Leopard > > Also, the trademark is "Mac OS X" not "MacOS X" or "Mac-OS/X" or > "MACOSX" ;) Sorry, Housecat was a (temporary) joke. I'll fix the Mac OS X refs. Though, frankly, I don't care what the trademark is, and I think people tend in real usage to use "MacOS". Bill From janssen at parc.com Sat Feb 11 02:24:15 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 17:24:15 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 15:15:12 PST." <959EC80A-66B2-4D92-ADFC-560AD454E844@redivi.com> Message-ID: <06Feb10.172422pst."58633"@synergy1.parc.xerox.com> > If I need a package outside of their package management system I have > to go f*!(ing crazy figuring out which *-dev packages i need to > install in order to get it to configure and make install correctly. Agreed. I'd like that to be different with MacPython. Bill From janssen at parc.com Sat Feb 11 02:27:26 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 17:27:26 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 14:58:51 PST." Message-ID: <06Feb10.172727pst."58633"@synergy1.parc.xerox.com> > Please forget [TigerPython24Fix] exists - I'm > tired of discussing it. Fine. The next installer won't have it or need it, and I'll remove the bit about it on my sample page. > > And for that matter, why not include TigerPython23Compat as part of > > the MacPython installer? > > TigerPython23Compat allows OS X 10.4's installation Python 2.3 to use > packages built with OS X 10.3. Not very relevant to a Python 2.4. > OK, thanks. > > And how about bundling tcltkaqua into it, as well? > > Tcl/Tk Aqua ships with OS X 10.4 and it's a relatively large > dependency to just include for the sake of OS X 10.3 users. But IDLE.app won't work without it on 10.3, if I read this correctly. It doesn't have to install on 10.4, the pre-flight scripts can check this. > >> Also, the installer has always had IDLE.app. > > > > I'm glad to hear that about IDLE.app. But I'm depressed again when I > > read pages like > > http://rlai.cs.ualberta.ca/RLAI/RLsoftware/PythonLinks.html#IDLE. My > > impression from reading that is that MacPython IDLE.app is extensively > > broken. > > Those are reasons not to use IDLE with the built-in Python 2.3. > Those issues are all trivial to fix for any build that we produce. OK, great. The Alberta page was referring to the IDLE.app that came with the MacPython installer; so that's just something to put on the TODO list for the installer. Bill From janssen at parc.com Sat Feb 11 02:31:45 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 17:31:45 PST Subject: [Pythonmac-SIG] current state of scripting: appscript vs. aeve? Message-ID: <06Feb10.173152pst."58633"@synergy1.parc.xerox.com> Is there a winner yet? The appscript wiki page seems to have been modified more recently than the aeve one. It seems that the gensuitemodule is still the way to go. Bill From janssen at parc.com Sat Feb 11 02:34:11 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 17:34:11 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 16:40:18 PST." <761513FC-21FB-4F29-9CD7-35384482A2C1@conncoll.edu> Message-ID: <06Feb10.173417pst."58633"@synergy1.parc.xerox.com> > > And how about bundling tcltkaqua into it, as well? > > Because some of us, at least, have no interest in tcl. I'm not clear > whether its presence interferes with wx (thing #421 that I'm not > clear about), but it doesn't help; why should I want it on my system? Because you can't run IDLE without it. Maybe in a perfect world we'll have an installer that will allow you to do a custom install and uncheck the tcltkaqua entry before running the install. > The answer might be, because Apple puts it in their (therefore in > mine). Is that true? Anyway I'm not clear about the logic of this. Apparently, for 10.4. Bill From janssen at parc.com Sat Feb 11 02:35:14 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 17:35:14 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 16:43:05 PST." Message-ID: <06Feb10.173522pst."58633"@synergy1.parc.xerox.com> > The audience we're imagining is one looking to branch out a little -- > into programming, to begin with, into Python in particular. That's *one* of the audiences. > If that > involves downloading something, that's perfectly familiar territory. > If I were a Mac user interested in a new approach to word processing > I'd expect to download Nisus Writer, or whatever. (For that matter, > Word doesn't come free on Macs.) I think the Python is parallel, from > that psychological standpoint. (The fact that Apple ships a version > of Python is a red herring here.) I think I agree with this. Bill From bob at redivi.com Sat Feb 11 02:47:40 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 17:47:40 -0800 Subject: [Pythonmac-SIG] current state of scripting: appscript vs. aeve? In-Reply-To: <06Feb10.173152pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.173152pst."58633"@synergy1.parc.xerox.com> Message-ID: <5C614D4D-5102-4AE3-BF92-A732AF337721@redivi.com> On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: > Is there a winner yet? The appscript wiki page seems to have been > modified more recently than the aeve one. appscript is the winner. I don't care to maintain aeve, and gensuitemodule is just plain broken. > It seems that the gensuitemodule is still the way to go. Definitely not. It hasn't ever worked very well on OS X. IIRC, it can't even do Finder correctly (either that or iTunes, I forget which). -bob From charles.hartman at conncoll.edu Sat Feb 11 02:50:33 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri, 10 Feb 2006 20:50:33 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.172227pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.172227pst."58633"@synergy1.parc.xerox.com> Message-ID: <8028C99F-28E8-4F63-B8C1-E5DB2D72665B@conncoll.edu> On Feb 10, 2006, at 8:22 PM, Bill Janssen wrote: > Though, frankly, I don't care what the trademark is, and I think > people tend in real usage to use "MacOS". Well . . . not for people I know. "OSX" ["OS X"] is more common in my experience, especially among those aware that OS9 was a Mac OS. And I suspect we *do* care what the trademark is -- this isn't a sanctioned Apple website, but isn't there some value to conforming to the mother ship's ways? Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060210/3ac575a1/attachment.htm From bob at redivi.com Sat Feb 11 02:50:59 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 10 Feb 2006 17:50:59 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.173417pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.173417pst."58633"@synergy1.parc.xerox.com> Message-ID: <84CF64FA-5E6C-409C-9B0F-05095CA3301E@redivi.com> On Feb 10, 2006, at 5:34 PM, Bill Janssen wrote: >>> And how about bundling tcltkaqua into it, as well? >> >> Because some of us, at least, have no interest in tcl. I'm not clear >> whether its presence interferes with wx (thing #421 that I'm not >> clear about), but it doesn't help; why should I want it on my system? > > Because you can't run IDLE without it. Maybe in a perfect world we'll > have an installer that will allow you to do a custom install and > uncheck the tcltkaqua entry before running the install. I think it's safe to have a note that says something like this -- Attention Mac OS X 10.3 users: To use IDLE (the Python IDE) and other Tkinter based applications, you must first install tcltkaqua. Better than adding 3 or 4 MB to the download. -bob From janssen at parc.com Sat Feb 11 03:01:03 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 18:01:03 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Fri, 10 Feb 2006 15:37:30 PST." <06Feb10.153732pst."58633"@synergy1.parc.xerox.com> Message-ID: <06Feb10.180107pst."58633"@synergy1.parc.xerox.com> I've updated it to take into account Bob's comments. http://bill.janssen.org/mac/new-macpython-page.html. It still kind of assumes that the installers will automagically do everything that needs doing. I assume that will be truer with the universal installer. Should there be a paragraph just before the one that starts, "As a bonus", saying something about how to run IDLE.app once you've downloaded and installed the upgrade? Bill From rodneys at io.com Sat Feb 11 03:04:13 2006 From: rodneys at io.com (Rodney Somerstein) Date: Fri, 10 Feb 2006 21:04:13 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43ECF048.5070503@noaa.gov> References: <06Feb8.202938pst.58633@synergy1.parc.xerox.com> <43ECF048.5070503@noaa.gov> Message-ID: At 11:58 AM -0800 2/10/06, Christopher Barker wrote: >Rodney Somerstein wrote: >>. It would be really nice to have a more basic introduction to what >>py2app actually does. > >Why don't you write that, put it in the Wiki, then ask this list for >technical review. That's what Wikis are for, and I think often >recent newbies are the best people to write newbie docs, when you >still remember what questions you have. Thanks for the suggestion. I suppose I should have expected this when I posted. While I can explain the basic concept of what py2app does, my knowledge pretty much stops there. Given that I'm not much beyond the helloworld level or using Python right now, I will decline for the moment. Due to time constraints, I will not likely move much beyond this in the short-term future. So, I could write one to two sentences that it takes to explain the purpose of py2app. Beyond that, someone else would need to fill in the details. -Rodney From janssen at parc.com Sat Feb 11 03:07:33 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 18:07:33 PST Subject: [Pythonmac-SIG] current state of scripting: appscript vs. aeve? In-Reply-To: Your message of "Fri, 10 Feb 2006 17:47:40 PST." <5C614D4D-5102-4AE3-BF92-A732AF337721@redivi.com> Message-ID: <06Feb10.180742pst."58633"@synergy1.parc.xerox.com> I've updated the Applescript wiki page accordingly. Bill > > On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: > > > Is there a winner yet? The appscript wiki page seems to have been > > modified more recently than the aeve one. > > appscript is the winner. I don't care to maintain aeve, and > gensuitemodule is just plain broken. > > > It seems that the gensuitemodule is still the way to go. > > Definitely not. It hasn't ever worked very well on OS X. IIRC, it > can't even do Finder correctly (either that or iTunes, I forget which). > > -bob > From janssen at parc.com Sat Feb 11 03:14:09 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 10 Feb 2006 18:14:09 PST Subject: [Pythonmac-SIG] update the IDLE "gentle introduction" for the Mac with new screenshots? Message-ID: <06Feb10.181418pst."58633"@synergy1.parc.xerox.com> There's a nice little tutorial guide introduction to IDLE at http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/index.html. It's been translated into 13 other languages by various people. But no one has translated it into Mac by providing Mac screenshots to replace the Windows ones there. Bill From hengist.podd at virgin.net Sat Feb 11 04:30:24 2006 From: hengist.podd at virgin.net (has) Date: Sat, 11 Feb 2006 03:30:24 +0000 Subject: [Pythonmac-SIG] current state of scripting: appscript vs. aeve? In-Reply-To: <5C614D4D-5102-4AE3-BF92-A732AF337721@redivi.com> References: <06Feb10.173152pst."58633"@synergy1.parc.xerox.com> <5C614D4D-5102-4AE3-BF92-A732AF337721@redivi.com> Message-ID: Bob wrote: >>It seems that the gensuitemodule is still the way to go. > >Definitely not. It hasn't ever worked very well on OS X. IIRC, it can't even do Finder correctly (either that or iTunes, I forget which). Yup. gsm's always been a bit flaky, and now appears to be pining for the fjords too [1]. I'll see about cleaning up the relevant wiki pages when I've some spare time; that AppleScript page is hardly appealing. has [1] http://mail.python.org/pipermail/pythonmac-sig/2006-February/016133.html -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Sat Feb 11 04:39:33 2006 From: hengist.podd at virgin.net (has) Date: Sat, 11 Feb 2006 03:39:33 +0000 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.095551pst."58633"@synergy1.parc.xerox.com> References: <06Feb10.095551pst."58633"@synergy1.parc.xerox.com> Message-ID: Bill Janssen wrote: > > Problem with the official Mac-specific modules and documentation is >> there's quite of stuff in there that hasn't been correct/usable since >> OS 9. It's just that nobody's gotten around to dealing with >> it. Experienced users already know which bits to avoid, so there's not >> huge impetus to clean it out properly. Doesn't mean you want to steer >> newbies towards it though. > >It sounds like we should ask the Python-doc folks to remove the >Macintosh docs entirely. Maybe post it with appropriate warnings on >pythonmac.org instead. Might be a good idea; there's probably more discouraging cruft than useful stuff in it right now, and it'd probably be quicker to clean it up separately and resubmit afterwards (assuming anything's left:) than submit piles of individual patches against it in-situ. has -- http://freespace.virgin.net/hamish.sanderson/ From skip at pobox.com Sat Feb 11 05:46:06 2006 From: skip at pobox.com (skip at pobox.com) Date: Fri, 10 Feb 2006 22:46:06 -0600 Subject: [Pythonmac-SIG] appscript introspection? Message-ID: <17389.27662.815348.297434@montanaro.dyndns.org> I'm trying to drive iCal using appscript. I can follow simple examples, mostly like a parrot though. This works, for example: ev = app('iCal').calendars.filter(its.title=="Home").events events = zip(ev.start_date.get(), ev.end_date.get(), ev.summary.get(), ev.description.get()) but I haven't found anywhere that lists all the attributes of an event, so I can't tell what it has other than start_date, end_date, summary and description. If I don't have an example to use as a cheat sheet, how can I tell how to add an alarm to an event? Where can I find such information? Thx, -- Skip Montanaro http://www.musi-cal.com/ skip at pobox.com From nad at acm.org Sat Feb 11 06:35:46 2006 From: nad at acm.org (Ned Deily) Date: Fri, 10 Feb 2006 21:35:46 -0800 Subject: [Pythonmac-SIG] appscript introspection? References: <17389.27662.815348.297434@montanaro.dyndns.org> Message-ID: In article <17389.27662.815348.297434 at montanaro.dyndns.org>, skip at pobox.com wrote: > I'm trying to drive iCal using appscript. I can follow simple examples, > mostly like a parrot though. This works, for example: > > ev = app('iCal').calendars.filter(its.title=="Home").events > events = zip(ev.start_date.get(), ev.end_date.get(), > ev.summary.get(), ev.description.get()) > > but I haven't found anywhere that lists all the attributes of an event, so I > can't tell what it has other than start_date, end_date, summary and > description. If I don't have an example to use as a cheat sheet, how can I > tell how to add an alarm to an event? Where can I find such information? 1. appscript supplies a help method for appscript objects. See: In your example: >>> ev.help() ========================================================================= ======= Appscript Help (-t) Reference: app(u'/Applications/iCal.app').calendars.filter(its.title == 'Home').events ------------------------------------------------------------------------- ------- Description of reference Element: events -- Terminology for event class Class: event -- This class represents an event. Parent: (Bad terminology: can't find class with AE code '****'.) Properties: description : Unicode -- The events notes. start_date : DateTime -- The event start date. end_date : DateTime -- The event end date. allday_event : Boolean -- True if the event is an all-day event recurrence : Unicode -- The iCalendar (RFC 2445) string describing the event recurrence, if defined sequence : Integer (r/o) -- The event version. stamp_date : DateTime (r/o) -- The event modification date. excluded_dates : list of DateTime -- The exception dates. status : k.cancelled | k.confirmed | k.none | k.tentative -- The event status. summary : Unicode -- This is the event summary. location : Unicode -- This is the event location. uid : Unicode (r/o) -- A unique event key. url : Unicode -- The URL associated to the event. Elements: attendees -- display_alarms -- mail_alarms -- open_file_alarms -- sound_alarms -- ========================================================================= ======= app(u'/Applications/iCal.app').calendars.filter(its.title == 'Home').events >>> 2. It may be more convenient to use Script Editor.app to browse the application's terminology resources. But, as has has noted here before, you can't always trust what any application says is available. There's often a lot of trial and error to discover what works and what doesn't. See, for example: -- Ned Deily, nad at acm.org From hengist.podd at virgin.net Sat Feb 11 10:38:54 2006 From: hengist.podd at virgin.net (has) Date: Sat, 11 Feb 2006 09:38:54 +0000 Subject: [Pythonmac-SIG] appscript introspection? Message-ID: Ned Deily nad at acm.org wrote: > > but I haven't found anywhere that lists all the attributes of an event, > >1. appscript supplies a help method for appscript objects. You can also render terminology to HTML file using the htmldoc module. Easiest way is via HTMLDictionary . HTH has -- http://freespace.virgin.net/hamish.sanderson/ From skip at pobox.com Sat Feb 11 14:19:59 2006 From: skip at pobox.com (skip at pobox.com) Date: Sat, 11 Feb 2006 07:19:59 -0600 Subject: [Pythonmac-SIG] appscript introspection? In-Reply-To: References: <17389.27662.815348.297434@montanaro.dyndns.org> Message-ID: <17389.58495.833944.706457@montanaro.dyndns.org> ned> 1. appscript supplies a help method for appscript objects. has> You can also render terminology to HTML file using the htmldoc has> module. Easiest way is via HTMLDictionary Thanks for the excellent help. They are just what I need... Skip From uche.ogbuji at fourthought.com Thu Feb 9 23:08:36 2006 From: uche.ogbuji at fourthought.com (Uche Ogbuji) Date: Thu, 09 Feb 2006 15:08:36 -0700 Subject: [Pythonmac-SIG] [XML-SIG] PyXML 0.8.4 and expat byteorder In-Reply-To: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> References: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> Message-ID: <43EBBD64.9050502@fourthought.com> Bob Ippolito wrote: > Here's the PyXML patch that gets expat byteorder from pyconfig.h. I > don't know who the maintainer is nor do I have any interest in > subscribing to xml-sig (this CC will probably bounce, or get stuck in > mod queue for days/weeks/forever). If you give a damn about PyXML > please make sure to get the patch to the right person. > > I've never even installed the 4Suite stuff, so I'm not going to put > together a patch for that. Such a patch should be roughly the same as > this one. Never a worry. 4Suite developers track expat *very* closely (and even contribute back to expat itself). We came across and addressed this issue months ago. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Articles: http://uche.ogbuji.net/tech/publications/ From uche.ogbuji at fourthought.com Thu Feb 9 22:57:50 2006 From: uche.ogbuji at fourthought.com (Uche Ogbuji) Date: Thu, 09 Feb 2006 14:57:50 -0700 Subject: [Pythonmac-SIG] [XML-SIG] PyXML 0.8.4 and expat byteorder In-Reply-To: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> References: <11FE3731-82C4-4D1E-9ECF-AE50ABE314E4@redivi.com> Message-ID: <43EBBADE.8050506@fourthought.com> Bob Ippolito wrote: > Here's the PyXML patch that gets expat byteorder from pyconfig.h. I > don't know who the maintainer is nor do I have any interest in > subscribing to xml-sig (this CC will probably bounce, or get stuck in > mod queue for days/weeks/forever). If you give a damn about PyXML > please make sure to get the patch to the right person. > > I've never even installed the 4Suite stuff, so I'm not going to put > together a patch for that. Such a patch should be roughly the same as > this one. You can relax. 4Suite developers track expat *very* closely (and even contribute back to expat itself). We came across and addressed this issue months ago. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Articles: http://uche.ogbuji.net/tech/publications/ From ronaldoussoren at mac.com Sat Feb 11 19:56:23 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 19:56:23 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <685A46E0-ACA5-4DA7-8ABF-624DE7A8973E@redivi.com> References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> <685A46E0-ACA5-4DA7-8ABF-624DE7A8973E@redivi.com> Message-ID: <480B44CB-BF25-4E62-9E7F-B98000C7A71B@mac.com> On 9-feb-2006, at 2:40, Bob Ippolito wrote: > > On Feb 8, 2006, at 2:42 PM, Charles Hartman wrote: > >> I'm afraid that you're right about this, and I think it's the biggest >> obstacle to the project of getting (non-Unix) Mac users interested in >> Python when they go looking for a language, or just looking to get >> started on programming. >> >> Does the old PythonIDE come with OSX's Python? > > No, it has never shipped with Mac OS X. > > The old Python IDE is dead, forget it ever existed. It hasn't been > touched in god knows how many years and a dependency it has is "non- > free" and not available for i386. > >> I really feel -- do people really think I'm wrong about this? -- that >> even PythonIDE, limited as it is, is a better beginners' >> recommendation than the Terminal. > > It's not even an option, we'd need to pick something else. IDLE is > the only suitable library candidate for a beginners IDE, but only on > Mac OS X 10.4 and later (since 10.3 did not ship with Tcl/Tk). Tcl/Tk is avaible as a seperate download for 10.3 > > Technically IDLE should even work on a stock Mac OS X 10.4 system if > the user went to the scary terminal and typed: > > pythonw -c "import idlelib.idle" Seems like nice little project for someone that does want to push Apple's python, build a (tiny) download that contains 'IDLE.app'. And presto, you have a simple IDE for someone that doesn't want to use the terminal ;-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/768b0309/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 20:53:23 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 20:53:23 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <49997463-912C-46C7-BAB6-8B95666407F3@conncoll.edu> <43EA64FC.50907@noaa.gov> <1F314044-E260-4463-B0BC-D07B1791BD40@conncoll.edu> <43EA783C.60707@anvil.nrl.navy.mil> <80FD7B29-CF95-4772-B5D0-1289D017A7ED@conncoll.edu> <43EA84FF.5080600@noaa.gov> Message-ID: <2743E51B-92F4-4C2F-854E-F8539A697F86@mac.com> On 9-feb-2006, at 2:42, Bob Ippolito wrote: > > On Feb 8, 2006, at 3:55 PM, Christopher Barker wrote: > >> Charles Hartman wrote: >>> But we're not. I never use the Terminal with Python. I use WingIDE >>> (can't recommend to beginners because it uses X11). >> >> Um, why not? I think X11 now comes with OS-X by default. Or does it >> jsut >> look&feel too non-Macish. > > It comes with OS X, but it doesn't install by default. It also looks too non-Macish: the menubar of X11 application is al wrong, it is not at the top of the screen. This often confuses me (and I'm more a unix user than a mac user). Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/46109f31/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 21:03:44 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:03:44 +0100 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <56194992-3505-48E1-B248-958ACF8EA164@theolliviers.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <38FE93D2-CF0B-4F12-897B-349E0455BE69@theolliviers.com> <72C809A0-AA32-443F-AD31-06C61EC46375@redivi.com> <478722D2-DBE2-4DE3-84CD-1C5490245555@theolliviers.com> <56194992-3505-48E1-B248-958ACF8EA164@theolliviers.com> Message-ID: On 9-feb-2006, at 4:13, Kevin Ollivier wrote: >> >> The difference is that if I didn't know better, I'd get really >> pissed off if I upgraded my OS and all of my very important work >> stuff breaks and makes me waste a day tracking down what needs to >> be fixed. That's not what an OS upgrade is supposed to do. It >> doesn't do that for anything except applications that depend on >> moving targets like the system's Python or Perl interpreter. > > I'd get really pissed off if I didn't know better and things stopped > working regardless of how I upgraded Python. You'd consider whose > Python broke your stuff into your decision to get upset? > > All Apple is doing is including Python with their OS, and > occasionally updating it. That these updates can cause not-so- > pleasant things to happen due to how Python works is not Apple's > fault. A lot of the speech on here practically accuses Apple of > causing the problem and it's really not fair. I'm pretty sure Bob isn't accusing Apple of anything, but keeps trying to hammer down the point that relying on Apple's Python framework for end-user applications is not a smart thing. I'd be very upset if some random GUI program stopped working after an OS upgrade. If the program is any good end-users shouldn't have to know the language it is programmed in. BTW. This doesn't mean you should never use the system version of python. If you control the OS version (such as with in-house deployments) or the user knows the program integrates with the system version of python (a Python IDE or other power-tools) you might as well use the system python. The same goes for pure python scripts, python is much nicer than shell-scripts for a lot of systems-management stuff. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/8b23ab3d/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 21:16:21 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:16:21 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb8.192503pst.58633@synergy1.parc.xerox.com> References: <06Feb8.192503pst.58633@synergy1.parc.xerox.com> Message-ID: <5300FDFA-BB8F-4043-B35B-5DDC02B45D35@mac.com> On 9-feb-2006, at 4:24, Bill Janssen wrote: >> I am one of those too, of course, but I do know a lot of Mac users >> who spend most of their time in applications like Photoshop, >> Dreamweaver, BBEdit, etc. and rarely venture towards the Terminal. >> Not quite the same audience, but at least some of them would be >> potential Python users by way of appscript or web development tools. > > Sure, that make perfect sense. > >>> But my point was simply that it seems hard to be a Mac user these >>> days >>> without some basic use of the Terminal. >> >> That's not true at all. > > OK, I'm probably the wrong person to assess that. > > So it seems that a old Unix-style Python program which reads from > stdin (or a file or a tty) and writes to stdout would be difficult to > explain to someone who has never used a command line. And there's > essentially no way to get Idle started without using a command line. If you install py2app and then run the setup script below you'll end up with IDLE-2.3.app in the dist directory. This application bundle is 64KByte small and will start the IDLE GUI. Feel free to enhance this with a nice icon. # Begin of setup.py import idlelib, os import py2app from distutils.core import setup setup( name="IDLE-2.3", app=[os.path.join(os.path.dirname(idlelib.__file__), 'idle.py')], options=(dict( py2app=dict(argv_emulation=True) )), ) # End of setup.py > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/c281b340/attachment-0001.bin From ronaldoussoren at mac.com Sat Feb 11 21:22:18 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:22:18 +0100 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> Message-ID: <156C7531-2FAE-4A28-905D-7DDC70DDC122@mac.com> On 9-feb-2006, at 16:34, has wrote: > > As has been said elsewhere, if the aim is to market Python to a > broad audience then it's at least as much an exercise in > influencing perceptions as technical merit. And often folk just > don't like to be presented with a long list of things to download > and install before they're able to do anything. e.g. Back before > Nick stepped in with his all-in-one installer, some folks fair > moaned about having to install a half-dozen simple distutils > packages in order to use appscript. Even though the latter approach > only took an extra minute or two in practice, in the end it was > simpler and much more effective to cater to their "unreasonable" > demands than lecture them on why "they" were "wrong". Totally off-topic, but if you'd move to setuptools you can keep several separate packages, but users could install using 'easy_install appscript' which would then take care of the dependencies for you. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/d5824fa3/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 21:34:45 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:34:45 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.122544pst.58633@synergy1.parc.xerox.com> References: <06Feb9.122544pst.58633@synergy1.parc.xerox.com> Message-ID: <1597E4B0-7E73-4109-9EB6-8215B120C666@mac.com> On 9-feb-2006, at 21:25, Bill Janssen wrote: >> 1. Link to the "Macintosh Library Module": A lot of that stuff >> will be >> rendered obsolete the minute Bob releases the universal build of >> MacPython. PythonIDE, Package Manager, etc.: not gonna be >> included. At a >> minimum, you should note that this stuff is "legacy." Also, who >> writes >> this stuff and where should a bug be filed? >> >> 2. Ditto for "Apple Events." Does anyone use gensuitemodule or >> even know >> what it means? (I don't.) I don't use appscripting, but I do know >> enough >> to know that it's pretty much the standard way (by now) of accessing >> Apple Events? has, what do you think? > > Hey, I'm linking to the official documentation. That's what people > will use, till it changes. All this other stuff scattered around is > blue-sky wild-ass future, till it's documented. Eeks, are you linking to http://docs.python.org/mac/mac.html? Most of that is empty and of no use to users. > > You can file documentation bugs at http://sourceforge.net/bugs/? > group_id=5470. But that is of little use unless you volunteer to write the documentation as well. Jack seems to be the only one of the core python developers that knows enought about the mac specific modules to write documentation, and he left the documentation empty by design: it should be easy enough to fetch information from Apple's documentation for the C API. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/5fa1c54c/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 21:39:47 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:39:47 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb9.123809pst.58633@synergy1.parc.xerox.com> Message-ID: <41C71664-9927-45C0-815C-8C77E05B3A40@mac.com> On 9-feb-2006, at 22:14, Bob Ippolito wrote: >> >> I've got a great deal of respect and appreciation for those, like Bob >> and Ronald, working hard on advancing the technology pieces. Great >> work, just what we all need! But unless there's some effective >> delivery vehicle for getting that work to the customer, much of it >> will be wasted. > > It's not a waste because the work done helps me accomplish what I > need to do. I do it because I need it to be done, not because I want > to help people. I do a lot of things to help people, but that's > rarely ever my primary motivation in the context of open source. > > There's an open invitation for someone to coddle new users and > maintain a straightforward web presence. We all know that it would > be beneficial, and it's time for someone to step up and do it > already. It's been discussed ad nauseam for the past few years, but > talking apparently doesn't make anything happen. I want to second that :-). I work on Python on OSX because I use Python on OSX. To be blunt, I don't really care about end-users beyond what I'm doing now. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/0dec07f7/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 21:45:10 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:45:10 +0100 Subject: [Pythonmac-SIG] install again? In-Reply-To: <43EBDA98.1060603@noaa.gov> References: <1d987df30602060146k730ecc67nd13b78cc21c42739@mail.gmail.com> <1d987df30602060452x3cb0b78s539a38c17526e50a@mail.gmail.com> <07A5B236-9502-4448-9904-D75B01AD5F39@nasa.gov> <1d987df30602060614y396b9edcwb9dd25f9a5d614c7@mail.gmail.com> <43E75CA9.7090504@anvil.nrl.navy.mil> <4C072582-3C77-4707-A65C-9E321AFC805A@conncoll.edu> <43E76602.8040405@wordtech-software.com> <03EC1D19-C9B4-4210-8010-82E5A96719C1@conncoll.edu> <43E7AE5A.6070600@noaa.gov> <98E9A532-A99A-4D2A-BE1F-E60A8C53ABB5@redivi.com> <43E7DE48.6070107@noaa.gov> <465C0ED9-82FB-4C13-BE24-A74429A28438@redivi.com> <167CEED4-1239-4A63-B142-4B079D3CFB3A@mac.com> <83D0123A-0AE9-44E2-AC6C-84595D6DAF8C@redivi.com> <43EBDA98.1060603@noaa.gov> Message-ID: On 10-feb-2006, at 1:13, Christopher Barker wrote: > Ronald Oussoren wrote: >> That's not really a problem, I need some kind of test to determine >> if we >> can get away with loading C++ code compiled with g++-3.3 into a >> python >> build with gcc 4. Boost might also be an option for testing. > > matplotlib has a lot of C++ in it. > > -Chris > And later on Chris wrote: > and there are binaries built for 2.4 on 10.3 on pythonmac.org, if that > helps. > > -Chris Thanks. I'll have a look at this after I finish my packaging script for the universal build (and catch up with the avalanche of e-mail messages on the pythonmac list) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/8fed4262/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 21:53:48 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:53:48 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> Message-ID: On 10-feb-2006, at 2:56, Bob Ippolito wrote: >> >>> We also get to ignore the issues >>> of which version of Mac OS X they are using because 10.3 and 10.4 >>> will behave the same. >> >> Um, aren't there issues with not being able to use the universal >> version >> with less than 10.3.9, and not being able to build extensions on >> 10.3 at >> all with the universal version? > > The universal version is indeed not compatible with 10.3.0-10.3.8, > but upgrading to 10.3.9 is free. I think it's safe at this point to > say 10.3.9 is absolutely required to use the supported version of > Python. Unless someone volunteers to do the required work to support earlier versions of the OS. I don't mind requireing at least 10.3.9. > > The extension thing we can hack around by installing two copies of > the Makefile and having distutils pick a PPC-only Makefile if it > detects 10.3. I was thinking more along the line of hacking distutils to detect that it is running on 10.3 and then removing 10.4+ specific flags (all -arch flags and the -isysroot thingy) from CFLAGS. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/1b98c81d/attachment-0001.bin From ronaldoussoren at mac.com Sat Feb 11 21:58:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 21:58:13 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb9.192505pst.58633@synergy1.parc.xerox.com> References: <06Feb9.192505pst.58633@synergy1.parc.xerox.com> Message-ID: <44F40EB7-8533-4713-8F7A-964CE81202D3@mac.com> On 10-feb-2006, at 4:24, Bill Janssen wrote: >> Could a Mac ever ship with an >>> acceptable pre-installed Python? If not, perhaps the solution for >>> Apple is to move /usr/bin/python to some other spot, like >>> /usr/libexec/, or some such place. >> >> The issue of not being able to produce redistributable applications >> still exists, and also backwards compatibility with previous versions >> of Mac OS X. > > So you're saying that the pre-installed version could never be really > acceptable. In that case, perhaps we only need convince Apple to move > /usr/bin/python to some more system-y place that wouldn't usually be > on users' paths. > > We then in the MacPython world take the position that Python isn't > really pre-installed on Macs, and the place for a person to start > would be to download the installer and run it. Perhaps then in > addition the installer could symlink /usr/local/bin/pythonw to > /usr/bin/python, thereby solving the PATH issue. That won't happen. Replacing system components is completely wrong, what if someone finds a security bug in /usr/bin/python and Apple ships a security update to fix it [*]. The installer should update the user's path to ensure that our version of python is earlier on the PATH. Ronald [*] the first part being very unlikely of course :-) > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/eebaac0d/attachment.bin From markus at johalla.de Sat Feb 11 21:48:42 2006 From: markus at johalla.de (Markus) Date: Sat, 11 Feb 2006 21:48:42 +0100 Subject: [Pythonmac-SIG] Fink vs. MacPython Message-ID: Hi! Somewhere deep in the latest discussion I read a remark by Bob that he would not recommend the use of Finks python (there also was another that he didn't like Debian so that may explain it :) I came from Debian to OS X and nearly the first thing I did was to install Fink and thusly python. The three extensions I needed so far did install with 'python setup.py install' and everything works fine for me. So why is Fink 'bad'? Am I missing some features I would have had with MacPython? thanks, Markus From bob at redivi.com Sat Feb 11 22:03:10 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 13:03:10 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> Message-ID: <0550EC8E-C423-4281-A977-27A56C04005C@redivi.com> On Feb 11, 2006, at 12:53 PM, Ronald Oussoren wrote: > > On 10-feb-2006, at 2:56, Bob Ippolito wrote: >> >> The extension thing we can hack around by installing two copies of >> the Makefile and having distutils pick a PPC-only Makefile if it >> detects 10.3. > > I was thinking more along the line of hacking distutils to detect that > it is running on 10.3 and then removing 10.4+ specific flags (all - > arch > flags and the -isysroot thingy) from CFLAGS. That would work too, but it's probably easier to have a separate Makefile present because it's easier to implement. Probably also a bit easier to make work with dumb extensions that aren't built with distutils (like subversion's Python bindings).. since they'd just have to add a little conditional to the Makefile- finding code, rather than re-implementing the flags mangling. -bob From ronaldoussoren at mac.com Sat Feb 11 22:03:46 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 22:03:46 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <52DC2AC1-2C2D-479D-8DC3-560F3795CCBC@yahoo.ca> References: <52DC2AC1-2C2D-479D-8DC3-560F3795CCBC@yahoo.ca> Message-ID: On 10-feb-2006, at 5:08, Brendan Simons wrote: > > On 9-Feb-06, at 8:10 PM, Chris Barker wrote: >> >> >> Brendan Simons wrote: >>> SPE is almost there, but still needs a binary install. >> >> Would it be there with a good installer? > > Maybe. However its under active development and changes frequently. > >> >>>> BTW, "Open Terminal Here" is a nifty applet >> >>> Here's another easy way to do the same thing: Open the >>> terminal. Type "ls" followed by a space, but don't hit return. >>> Now click on the finder and open the folder you want Terminal to >>> access. In the titlebar of the finder window, next to the >>> folder's name, is a little folder icon. Drag that icon to your >>> terminal window (Expose helps if you have lots of windows >>> open). Terminal will spell out the folder's path for you. Now >>> return to Terminal and hit enter. >> >> I now about that, but that's a LOT more than one click -- get Open >> Terminal Here -- you'll be glad you did! > > True enough. BTW, I meant to use "cd", rather than "ls" in the > example. > > >> >>> further still if PyObjC ends up shipping with some version of OS X. >> >> That would make a big difference. > > Thirded. Glad to hear it's been added to the Apple buglist. I'm not so sure if I would like this, that would make it a lot harder to provide updates to PyObjC for the system version of Python. Although the "Apple ships my software with the OS"-factor would be pretty neat :-). On the other hand, I don't use Apple's python much anyway. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/ef2eb883/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 22:14:53 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 22:14:53 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <43ECF9A3.1090202@noaa.gov> References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> <43ECF9A3.1090202@noaa.gov> Message-ID: On 10-feb-2006, at 21:37, Christopher Barker wrote: > Bob Ippolito wrote: >>> Let's have py2app be a standard part of the 2.4 package. It'd be >>> great >>> if the standard upgrade package had and did everything you need >>> to get >>> started. I suggest easy-install as well. >> >> I'd prefer to wait on that until it's more mature. > > Why? it's what we use now, and it's the best there is. Anyone > wanting to > create stand-alones is going to need it. There's always room for it to > be upgraded in the future. I guess that depends on what the Python 2.4 package is. I'd like to keep it as close as possible to python.org source distribution. > >> Shipping setuptools isn't a bad idea, but it's a one-liner to >> install > it.. > > Yes, but it then puts the scripts in the weird bin directory buried in > the Framework, and one extra step is one extra step too many. That is not an issue if the installer for Python places that weird bin directory on the PATH. > >> The extension thing we can hack around by installing two copies of >> the >> Makefile and having distutils pick a PPC-only Makefile if it >> detects 10.3. > > OK. as long as that hack is built in to the installer, that's great. It should be build into distutils, not the installer, but otherwise I agree. > >> Since we're going to manipulating the PATH with the installer, should >> we still bother with the symlinks in /usr/local/bin? We definitely >> want the Framework's bin dir on the PATH because that's where scripts >> will be installed to... so the /usr/local/bin links seem a bit >> redundant. If we do this, then the Python installation process is >> completely self-contained except for the Applications dir. > > hmmm. In general, I'm not thrilled with every app creating it's own > addition to the PATH, it reminds me of DOS pain. I really like that in > *nix, there are only a few, standard, places for executables. Given > that, another option is to Create a ~/.pydistutils.cfg file with: If we'd do that we'd have to create a distutils.cfg somewhere in the python library (e.g. the system-wide version of .pydistuls.cfg). As I've mentioned before I prefer having every app in it's own directory, that makes it a lot easier to muck about with multiple versions of python. BTW. In most modern unices 3th-party apps are supposed to install in their own directory in /opt ;-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/2936b282/attachment.bin From bob at redivi.com Sat Feb 11 22:17:28 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 13:17:28 -0800 Subject: [Pythonmac-SIG] Fink vs. MacPython In-Reply-To: References: Message-ID: <3E0CB5FA-0855-4F40-8466-04FAEB45221D@redivi.com> On Feb 11, 2006, at 12:48 PM, Markus wrote: > Somewhere deep in the latest discussion I read a remark by Bob that > he would not recommend the use of Finks python (there also was > another that he didn't like Debian so that may explain it :) > > I came from Debian to OS X and nearly the first thing I did was to > install Fink and thusly python. The three extensions I needed so far > did install with 'python setup.py install' and everything works fine > for me. > > So why is Fink 'bad'? Am I missing some features I would have had > with MacPython? There are several disadvantages to using Fink or DarwinPorts Python which have been spelled out earlier in the thread. While they are perfectly fine for running UNIX and X11 apps, they're not good for doing Mac-specific work. Why even call it MacPython if it's not a Python distribution that actually takes advantage of the platform? This whole gigantic discussion is about making MacPython more friendly. To do so, we must consolidate our efforts and offer documentation and support for One Way To Do It, which is going to be a framework build of Python 2.4.2 with a lot of hacks to make it universal. No other method will be explicitly endorsed by this particular community effort. We're not trying to disparage the use of other distributions, but if you do, then you might be on your own. This Pythonmac-SIG list is still fine for discussing anything relevant to the platform, but the majority of the participants in discussions here are using a framework build (either 2.4 or Apple's). -bob From ronaldoussoren at mac.com Sat Feb 11 22:20:24 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 22:20:24 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb10.153732pst.58633@synergy1.parc.xerox.com> References: <06Feb10.153732pst.58633@synergy1.parc.xerox.com> Message-ID: <57A72A8E-22B9-49F7-B30C-A3E3892F21C1@mac.com> On 11-feb-2006, at 0:37, Bill Janssen wrote: > I've put up a new page, with a slightly different address: > > http://bill.janssen.org/mac/new-macpython-page.html. I noticed you use an icon that contains a realistic picture of a snake. Please keep in mind that lots of people are scared of snakes, please see the archives for more information. not-getting-the-snakephobia-ly yours, Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/f53ce7b7/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 22:22:00 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 22:22:00 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <761513FC-21FB-4F29-9CD7-35384482A2C1@conncoll.edu> References: <06Feb10.143151pst.58633@synergy1.parc.xerox.com> <761513FC-21FB-4F29-9CD7-35384482A2C1@conncoll.edu> Message-ID: <133E62D7-2C66-406F-BB0E-180C8D0DFA2F@mac.com> On 11-feb-2006, at 1:40, Charles Hartman wrote: > > On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: > >> And how about bundling tcltkaqua into it, as well? > > Because some of us, at least, have no interest in tcl. I'm not > clear whether its presence interferes with wx (thing #421 that I'm > not clear about), but it doesn't help; why should I want it on my > system? Because _tkinter, and hence IDLE use it? IDLE seems to be the only ready-to-use acceptable Python IDE right now. Not that I want to bundle Tcl/Tk, Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/3475b82f/attachment.bin From ronaldoussoren at mac.com Sat Feb 11 22:27:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 22:27:59 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <0550EC8E-C423-4281-A977-27A56C04005C@redivi.com> References: <06Feb8.174237pst.58633@synergy1.parc.xerox.com> <94BC8D09-E521-476E-95E9-7A780F34F0F3@redivi.com> <43EBE7E2.3080107@noaa.gov> <0550EC8E-C423-4281-A977-27A56C04005C@redivi.com> Message-ID: <9BACEE61-BEEA-4037-9F06-BD8973A6FAE7@mac.com> On 11-feb-2006, at 22:03, Bob Ippolito wrote: > > On Feb 11, 2006, at 12:53 PM, Ronald Oussoren wrote: > >> >> On 10-feb-2006, at 2:56, Bob Ippolito wrote: >>> >>> The extension thing we can hack around by installing two copies of >>> the Makefile and having distutils pick a PPC-only Makefile if it >>> detects 10.3. >> >> I was thinking more along the line of hacking distutils to detect >> that >> it is running on 10.3 and then removing 10.4+ specific flags (all - >> arch >> flags and the -isysroot thingy) from CFLAGS. > > That would work too, but it's probably easier to have a separate > Makefile present because it's easier to implement. Not for me, my test machine for 10.3 doesn't have a compiler :-) > > Probably also a bit easier to make work with dumb extensions that > aren't built with distutils (like subversion's Python bindings).. > since they'd just have to add a little conditional to the Makefile- > finding code, rather than re-implementing the flags mangling. To badly parafrase you: extensions that don't use distutils to build suck and are broken. If we must support those we could add a pkg- config style script. Ronald > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/18cae532/attachment.bin From bob at redivi.com Sat Feb 11 22:29:32 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 13:29:32 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <52DC2AC1-2C2D-479D-8DC3-560F3795CCBC@yahoo.ca> Message-ID: <5F99AF6C-538B-4763-8B86-1B0083004493@redivi.com> On Feb 11, 2006, at 1:03 PM, Ronald Oussoren wrote: > > On 10-feb-2006, at 5:08, Brendan Simons wrote: > >> >> On 9-Feb-06, at 8:10 PM, Chris Barker wrote: >>> >>> >>>> further still if PyObjC ends up shipping with some version of >>>> OS X. >>> >>> That would make a big difference. >> >> Thirded. Glad to hear it's been added to the Apple buglist. > > I'm not so sure if I would like this, that would make it a lot > harder to provide updates to PyObjC for the system version of > Python. Although the "Apple ships my software with the OS"-factor > would be pretty neat :-). On the other hand, I don't use Apple's > python much anyway. They might as well ship it, and then we can treat it the same as we do everything else they ship: if it's not good enough for your purposes, here's a third party Python distribution and upgrades. It would be terribly useful if I could use PyObjC in system scripts or whatever for 10.5+. -bob From ronaldoussoren at mac.com Sat Feb 11 22:32:58 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 11 Feb 2006 22:32:58 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <5F99AF6C-538B-4763-8B86-1B0083004493@redivi.com> References: <52DC2AC1-2C2D-479D-8DC3-560F3795CCBC@yahoo.ca> <5F99AF6C-538B-4763-8B86-1B0083004493@redivi.com> Message-ID: <4ECB3506-C1ED-439F-952F-4CE33249ABA1@mac.com> On 11-feb-2006, at 22:29, Bob Ippolito wrote: > On Feb 11, 2006, at 1:03 PM, Ronald Oussoren wrote: > >> >> On 10-feb-2006, at 5:08, Brendan Simons wrote: >> >>> >>> On 9-Feb-06, at 8:10 PM, Chris Barker wrote: >>>> >>>> >>>>> further still if PyObjC ends up shipping with some version of >>>>> OS X. >>>> >>>> That would make a big difference. >>> >>> Thirded. Glad to hear it's been added to the Apple buglist. >> >> I'm not so sure if I would like this, that would make it a lot >> harder to provide updates to PyObjC for the system version of >> Python. Although the "Apple ships my software with the OS"-factor >> would be pretty neat :-). On the other hand, I don't use Apple's >> python much anyway. > > They might as well ship it, and then we can treat it the same as we > do everything else they ship: if it's not good enough for your > purposes, here's a third party Python distribution and upgrades. > > It would be terribly useful if I could use PyObjC in system scripts > or whatever for 10.5+. That would indeed be nice. And it's not as if PyObjC is changing very much at the moment. Ronald > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/6365f95c/attachment.bin From charles.hartman at conncoll.edu Sat Feb 11 23:43:10 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat, 11 Feb 2006 17:43:10 -0500 Subject: [Pythonmac-SIG] Fink vs. MacPython In-Reply-To: <3E0CB5FA-0855-4F40-8466-04FAEB45221D@redivi.com> References: <3E0CB5FA-0855-4F40-8466-04FAEB45221D@redivi.com> Message-ID: On Feb 11, 2006, at 4:17 PM, Bob Ippolito wrote: > This whole gigantic discussion is about making MacPython more > friendly. To do so, we must consolidate our efforts and offer > documentation and support for One Way To Do It, which is going to be > a framework build of Python 2.4.2 with a lot of hacks to make it > universal. (--and easy -- e.g., auto-fixing of the PATH . . .) I agree whole-heartedly that this is the core of what we're trying to do. So Darwinports, Fink, and (dare I say it) even ActiveState are really beside the point. All worth a mention, somewhere in something pointed to from the main page, but clearly off the trail we're trying to make clear. Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/35bb4a64/attachment-0001.htm From charles.hartman at conncoll.edu Sat Feb 11 23:50:56 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat, 11 Feb 2006 17:50:56 -0500 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <133E62D7-2C66-406F-BB0E-180C8D0DFA2F@mac.com> References: <06Feb10.143151pst.58633@synergy1.parc.xerox.com> <761513FC-21FB-4F29-9CD7-35384482A2C1@conncoll.edu> <133E62D7-2C66-406F-BB0E-180C8D0DFA2F@mac.com> Message-ID: On Feb 11, 2006, at 4:22 PM, Ronald Oussoren wrote: > > On 11-feb-2006, at 1:40, Charles Hartman wrote: > >> >> On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: >> >>> And how about bundling tcltkaqua into it, as well? >> >> Because some of us, at least, have no interest in tcl. I'm not >> clear whether its presence interferes with wx (thing #421 that I'm >> not clear about), but it doesn't help; why should I want it on my >> system? > > Because _tkinter, and hence IDLE use it? IDLE seems to be the only > ready-to-use acceptable Python IDE right now. I'm not very happy about that (and I don't know that anyone else is, either; Bob I. has described some of the problems with IDLE), but if it's the way it is it's the way it is. But here I am, a rank beginner, I look at the descriptions of wxPython and its rivals and decide I like wx -- can I install that, and begin building apps with it, from IDLE? We all seem to recognize the need for flexibility in preferences about IDEs (since there's no clear, free, Mac-native choice). But GUI libraries may be different. I feel it's important not to foreclose the wx possibility, and I'm still not clear about what that entails, though a recent post by Bob (which I can't find at the moment) partially addressed this. Charles > Not that I want to bundle Tcl/Tk, --especially given the download/install overhead, right? From bob at redivi.com Sun Feb 12 00:00:03 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 15:00:03 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb10.143151pst.58633@synergy1.parc.xerox.com> <761513FC-21FB-4F29-9CD7-35384482A2C1@conncoll.edu> <133E62D7-2C66-406F-BB0E-180C8D0DFA2F@mac.com> Message-ID: <5AD1B55D-A566-46C1-93F9-2E5649868A58@redivi.com> On Feb 11, 2006, at 2:50 PM, Charles Hartman wrote: > > On Feb 11, 2006, at 4:22 PM, Ronald Oussoren wrote: > >> >> On 11-feb-2006, at 1:40, Charles Hartman wrote: >> >>> >>> On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: >>> >>>> And how about bundling tcltkaqua into it, as well? >>> >>> Because some of us, at least, have no interest in tcl. I'm not >>> clear whether its presence interferes with wx (thing #421 that >>> I'm not clear about), but it doesn't help; why should I want it >>> on my system? >> >> Because _tkinter, and hence IDLE use it? IDLE seems to be the only >> ready-to-use acceptable Python IDE right now. > > I'm not very happy about that (and I don't know that anyone else > is, either; Bob I. has described some of the problems with IDLE), > but if it's the way it is it's the way it is. But here I am, a rank > beginner, I look at the descriptions of wxPython and its rivals and > decide I like wx -- can I install that, and begin building apps > with it, from IDLE? Yes, assuming IDLE is started up and configured properly that will work fine. IDLE is one of the few IDEs that is designed properly such that it runs scripts in a subprocess. > We all seem to recognize the need for flexibility in preferences > about IDEs (since there's no clear, free, Mac-native choice). But > GUI libraries may be different. I feel it's important not to > foreclose the wx possibility, and I'm still not clear about what > that entails, though a recent post by Bob (which I can't find at > the moment) partially addressed this. Huh? wx possibility? I'm totally confused, what relevance does wx have to any of this discussion? >> Not that I want to bundle Tcl/Tk, > > --especially given the download/install overhead, right? Yes, it's a few megs. OS X 10.4 ships with it, so we don't have to include it -- just state that 10.3 users will need to acquire it separately. -bob From hengist.podd at virgin.net Sat Feb 11 23:31:16 2006 From: hengist.podd at virgin.net (has) Date: Sat, 11 Feb 2006 22:31:16 +0000 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <156C7531-2FAE-4A28-905D-7DDC70DDC122@mac.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> <156C7531-2FAE-4A28-905D-7DDC70DDC122@mac.com> Message-ID: Ronald Oussoren wrote: >Totally off-topic, but if you'd move to setuptools you can keep several separate packages, but users could install using 'easy_install appscript' which would then take care of the dependencies for you. I think setuptools is going to be a great solution and definitely plan to more there eventually. For now though, the mpkg-based distribution provides a lower barrier to entry (one less thing to install first), and it's a familiar format to all Mac users. One of the obvious audiences for appscript is existing AppleScripters, who aren't always overly enthusiastic about approaching unfamiliar technology, so it keeps things simple for them. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Sun Feb 12 00:04:43 2006 From: hengist.podd at virgin.net (has) Date: Sat, 11 Feb 2006 23:04:43 +0000 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: References: <52DC2AC1-2C2D-479D-8DC3-560F3795CCBC@yahoo.ca> Message-ID: Ronald Oussoren wrote: >>>> further still if PyObjC ends up shipping with some version of OS X. > >I'm not so sure if I would like this, that would make it a lot harder to provide updates to PyObjC for the system version of Python. Although the "Apple ships my software with the OS"-factor would be pretty neat :-). On the other hand, I don't use Apple's python much anyway. Its value would be as a PR win, like getting a PyObjC article on ADC, and that has practical value all of its own. The technological benefits are minimal-to-none at best; but as you say, who cares? Adds a bit of corporate respectability, provides another route for outsiders to hear about it. It's one more puff to add when singing its praises. I mean, Apple already bundle PerlObjC; you wouldn't want punters getting the impression that PerlObjC possesses something you don't, do you? has -- http://freespace.virgin.net/hamish.sanderson/ From skip at pobox.com Sun Feb 12 00:19:51 2006 From: skip at pobox.com (skip at pobox.com) Date: Sat, 11 Feb 2006 17:19:51 -0600 Subject: [Pythonmac-SIG] How to fetch iCal todo description? Message-ID: <17390.28951.192322.966471@montanaro.dyndns.org> I'm plugging away at my little ical appscript interface. The help postings were, well, helpful. Thanks for those. I'm stuck trying to figure out how to get the notes for a todo. If I create a todo via iCal and add a note to it, I don't see any property of the todo instance that contains that note. The HTMLDictionary output doesn't list "description" or "note" as one of the properties of a todo item, yet it's clearly there in iCal. If I export my todos, I see a DESCRIPTION field in the generated .ics file: BEGIN:VCALENDAR VERSION:2.0 X-WR-CALNAME:Home ... BEGIN:VTODO PRIORITY:0 DTSTAMP:20060211T195419Z UID:D83B6B12-9B38-11DA-9E55-0003939F0506 SEQUENCE:6 STATUS:COMPLETED DTSTART;TZID=America/Chicago:20060211T132904 SUMMARY:another release COMPLETED:20060211T060000Z DESCRIPTION:This is a note for the todo...\nAnother line. DUE;TZID=America/Chicago:20060221T000000 END:VTODO ... END:VCALENDAR Any clue how I can fetch it via appscript? Thx, -- Skip Montanaro http://www.musi-cal.com/ skip at pobox.com From berkowit at silcom.com Sun Feb 12 00:47:29 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Sat, 11 Feb 2006 15:47:29 -0800 Subject: [Pythonmac-SIG] How to fetch iCal todo description? In-Reply-To: <17390.28951.192322.966471@montanaro.dyndns.org> Message-ID: On 2/11/06 3:19 PM, "skip at pobox.com" wrote: > I'm stuck trying to figure out how to get the notes for a todo. Which OS are you in? In Panther, 'description' is missing from the AppleScript dictionary. In Tiger, it's there (plus other stuff and several bug fixes). Since appscript would be accessing the same attributes as AppleScript, that would be the explanation, if you're in OS 10.3. Upgrade to Tiger. (Or would it matter if has was in Panther when he wrote the appscript libraries, even if you're in Tiger? I don't think that should matter: surely you're getting your own iCal's aete. has?) The first version or two of all the iApps are crap from the scriptability angle. They seem to improve a lot with later versions: iCal in Tiger is pretty good, as is Address Book in Panther (and Tiger). Please always include which version of software and OS you're discussing. -- Paul Berkowitz From bob at redivi.com Sun Feb 12 00:52:17 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 15:52:17 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> <156C7531-2FAE-4A28-905D-7DDC70DDC122@mac.com> Message-ID: <61C83985-E074-4A23-BA55-2C7BEA7DC29C@redivi.com> On Feb 11, 2006, at 2:31 PM, has wrote: > Ronald Oussoren wrote: > >> Totally off-topic, but if you'd move to setuptools you can keep >> several separate packages, but users could install using >> 'easy_install appscript' which would then take care of the >> dependencies for you. > > I think setuptools is going to be a great solution and definitely > plan to more there eventually. For now though, the mpkg-based > distribution provides a lower barrier to entry (one less thing to > install first), and it's a familiar format to all Mac users. One of > the obvious audiences for appscript is existing AppleScripters, who > aren't always overly enthusiastic about approaching unfamiliar > technology, so it keeps things simple for them. They're not mutually exclusive. Do both. Just don't use pkg_resources or entry points yet. -bob From skip at pobox.com Sun Feb 12 01:07:57 2006 From: skip at pobox.com (skip at pobox.com) Date: Sat, 11 Feb 2006 18:07:57 -0600 Subject: [Pythonmac-SIG] How to fetch iCal todo description? In-Reply-To: References: <17390.28951.192322.966471@montanaro.dyndns.org> Message-ID: <17390.31837.779221.770395@montanaro.dyndns.org> Paul> On 2/11/06 3:19 PM, "skip at pobox.com" wrote: >> I'm stuck trying to figure out how to get the notes for a todo. Paul> Which OS are you in? OSX 10.3.9 and iCal 1.5.5. Paul> In Panther, 'description' is missing from the AppleScript Paul> dictionary. In Tiger, it's there (plus other stuff and several bug Paul> fixes). Since appscript would be accessing the same attributes as Paul> AppleScript, that would be the explanation, if you're in OS Paul> 10.3. I see. I just saw your note from 2003: http://lists.apple.com/archives/Applescript-users/2003/Nov/msg00673.html and filed a bug report. :-} Paul> Upgrade to Tiger. *sigh* Okay, maybe a Tiger upgrade would be worth it at this point. (Is 10.5 in beta yet?) I could really make use of basic iCal access without having access to the GUI. I rarely have my 'book at work, but am generally ssh-ed into it. Being able to add and display events & todos from the shell would be very useful. Paul> The first version or two of all the iApps are crap from the Paul> scriptability angle. They seem to improve a lot with later Paul> versions: iCal in Tiger is pretty good, as is Address Book in Paul> Panther (and Tiger). This is good news. Paul> Please always include which version of software and OS you're Paul> discussing. My apologies. It didn't occur to me that it would be a bug in iCal. I thought I was just doing something wrong (looking for the wrong property or going about getting that bit of information the wrong way). Skip From hengist.podd at virgin.net Sun Feb 12 03:12:10 2006 From: hengist.podd at virgin.net (has) Date: Sun, 12 Feb 2006 02:12:10 +0000 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: <61C83985-E074-4A23-BA55-2C7BEA7DC29C@redivi.com> References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> <156C7531-2FAE-4A28-905D-7DDC70DDC122@mac.com> <61C83985-E074-4A23-BA55-2C7BEA7DC29C@redivi.com> Message-ID: Bob Ippolito wrote: >>>Totally off-topic, but if you'd move to setuptools you can keep several separate packages, but users could install using 'easy_install appscript' which would then take care of the dependencies for you. >> >>I think setuptools is going to be a great solution and definitely plan to more there eventually. For now though, the mpkg-based distribution > >They're not mutually exclusive. Do both. Just don't use pkg_resources or entry points yet. Since that's more work for me, what benefit would setuptools distros provide over the point-n-click package installer, which is already very simple and works for anyone? Ta, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Sun Feb 12 03:46:33 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 18:46:33 -0800 Subject: [Pythonmac-SIG] a beginner's list In-Reply-To: References: <43E998B7.3000809@noaa.gov> <99C05BFB-BC37-45D6-9541-07A338595B23@theolliviers.com> <02DDD959-7B4F-4BD6-A5FF-B133D4013523@mac.com> <156C7531-2FAE-4A28-905D-7DDC70DDC122@mac.com> <61C83985-E074-4A23-BA55-2C7BEA7DC29C@redivi.com> Message-ID: On Feb 11, 2006, at 6:12 PM, has wrote: > Bob Ippolito wrote: > >>>> Totally off-topic, but if you'd move to setuptools you can keep >>>> several separate packages, but users could install using >>>> 'easy_install appscript' which would then take care of the >>>> dependencies for you. >>> >>> I think setuptools is going to be a great solution and definitely >>> plan to more there eventually. For now though, the mpkg-based >>> distribution >> >> They're not mutually exclusive. Do both. Just don't use >> pkg_resources or entry points yet. > > Since that's more work for me, what benefit would setuptools > distros provide over the point-n-click package installer, which is > already very simple and works for anyone? The major benefit is that people who develop setuptools-based applications can say (in their setup.py): install_requires=['appscript'] And then if someone does this: easy_install app_requiring_appscript Then it will Just Work. If you have binary eggs up, they don't even need a compiler to be installed. The work involved in supporting setuptools one or two lines per setup.py, so you really shouldn't even have to ask what the benefits are.. it's trivial. - from distutils.core import setup + from setuptools import setup setup(... + install_requires=['other', 'components', 'that', 'are', 'needed'], ) On top of that, you'll have to register your modules on Cheese Shop in order for this to be useful, but you should be doing that anyway. This is also trivial. # register on cheese shop, build an egg and source distribution, sign it all with GPG, and upload to cheese shop python setup.py register bdist_egg sdist upload -s And if you don't have setuptools installed already.. well, that's trivial too: python -c "import urllib; urllib.main()" \ http://peak.telecommunity.com/dist/ez_setup.py \ | sudo python - -U setuptools -bob From daniel at brightfire.com Sun Feb 12 04:37:06 2006 From: daniel at brightfire.com (Daniel Lord) Date: Sat, 11 Feb 2006 19:37:06 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59 In-Reply-To: References: Message-ID: <69BA87F3-4D68-46BE-AC23-EC386FC8D365@brightfire.com> On Feb 11, 2006, at 6:32 PM, pythonmac-sig-request at python.org wrote: > Ronald Oussoren wrote: > >> Totally off-topic, but if you'd move to setuptools you can keep >> several separate packages, but users could install using >> 'easy_install appscript' which would then take care of the >> dependencies for you. > > I think setuptools is going to be a great solution and definitely > plan to more there eventually. For now though, the mpkg-based > distribution provides a lower barrier to entry (one less thing to > install first), and it's a familiar format to all Mac users. One of > the obvious audiences for appscript is existing AppleScripters, who > aren't always overly enthusiastic about approaching unfamiliar > technology, so it keeps things simple for them. > > Cheers, > > has > -- > http://freespace.virgin.net/hamish.sanderson/ this is a personal opinion so I don't expect consensus. I _like_ appscript. A lot. HAS did a great job with it. And while I like the power of Apple Events, I do not like Applescript--the syntax is not standard by design--it varies from application to application which in theory means flexibility but in practice means entropy and chaos. And some application developers cannot even get the AETE right and so their scripting is broken or at least crippled. Applescript does not have decent control structures nor regular expression support. Its file system syntax is horrific. I applaud the idea and the 'dream'-- it just fell far short in practice. So using Python or Perl, whose syntax and language elements don't vary much from application to application is much better. The objects can vary--just not how to address them. I have used Mac::Glue with Perl, appscript with Python satisfactorily though I wish Apple would build in Apple Event support for those languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/92231633/attachment.htm From vinogri at mcmaster.ca Sun Feb 12 04:39:31 2006 From: vinogri at mcmaster.ca (I. Vinogradov) Date: Sat, 11 Feb 2006 22:39:31 -0500 Subject: [Pythonmac-SIG] xcode as IDE? Message-ID: Hello All, while on the topic of IDEs, would it be possible to somehow adapt Xcode to the task? It has Python keyword highlight, and PyObjC is one of the possible types of documents. I have some vague notion that perhaps a pure python file template can be made, that uses framework installation and all. Is something like that even possible? Regards, Ivan. From bob at redivi.com Sun Feb 12 05:06:33 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 20:06:33 -0800 Subject: [Pythonmac-SIG] xcode as IDE? In-Reply-To: References: Message-ID: On Feb 11, 2006, at 7:39 PM, I. Vinogradov wrote: > while on the topic of IDEs, would it be possible to somehow adapt > Xcode > to the task? It has Python keyword highlight, and PyObjC is one of the > possible types of documents. > > I have some vague notion that perhaps a pure python file template can > be made, that uses framework installation and all. Is something like > that even possible? Xcode isn't a very good IDE for anything but the languages it supports natively. It does not have public APIs to change that, either. If you use Xcode as an IDE, it won't be much more than a glorified text editor with syntax highlighting. I wish it was a good idea to use Xcode, but they haven't built it in such a way that allows third parties to add value. It makes a little sense with PyObjC because we've put together some py2app integration with Xcode, but it's a really ugly hack and doesn't work all that reliably because the custom build+run target is for some crazy reason stored as a user setting rather than a project setting. It's also prone to break at any Xcode update because it needs to read the undocumented Xcode project file format in order to get the information it needs. If you're considering Xcode, you'd be better off with Eclipse for Python development. Eclipse is bigger, slower, and uglier -- but at least it can provide more functionality than a text editor. -bob From bob at redivi.com Sun Feb 12 05:11:24 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 20:11:24 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59 In-Reply-To: <69BA87F3-4D68-46BE-AC23-EC386FC8D365@brightfire.com> References: <69BA87F3-4D68-46BE-AC23-EC386FC8D365@brightfire.com> Message-ID: <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote: > > On Feb 11, 2006, at 6:32 PM, pythonmac-sig-request at python.org wrote: > >> Ronald Oussoren wrote: >> >>> Totally off-topic, but if you'd move to setuptools you can keep >>> several separate packages, but users could install using >>> 'easy_install appscript' which would then take care of the >>> dependencies for you. >> >> I think setuptools is going to be a great solution and definitely >> plan to more there eventually. For now though, the mpkg-based >> distribution provides a lower barrier to entry (one less thing to >> install first), and it's a familiar format to all Mac users. One >> of the obvious audiences for appscript is existing AppleScripters, >> who aren't always overly enthusiastic about approaching unfamiliar >> technology, so it keeps things simple for them. > > this is a personal opinion so I don't expect consensus. I _like_ > appscript. A lot. HAS did a great job with it. And while I like the > power of Apple Events, I do not like Applescript--the syntax is not > standard by design--it varies from application to application which > in theory means flexibility but in practice means entropy and > chaos. And some application developers cannot even get the AETE > right and so their scripting is broken or at least crippled. > Applescript does not have decent control structures nor regular > expression support. Its file system syntax is horrific. I applaud > the idea and the 'dream'--it just fell far short in practice. So > using Python or Perl, whose syntax and language elements don't vary > much from application to application is much better. The objects > can vary--just not how to address them. I have used Mac::Glue with > Perl, appscript with Python satisfactorily though I wish Apple > would build in Apple Event support for those languages. That's irrelevant to appscript. If you're disappointed with the inconsistency of a given application's scripting dictionary then complain to the developer. Apple can't do a damn thing about it (unless of course they're the developer of the given app). Apple can't "build in support" for Python that would really be any different than what current solutions offer. What they could do is offer better tools for creating scripting dictionaries, and more documentation on the topic, but that's about it. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/6a540f58/attachment.html From daniel at brightfire.com Sun Feb 12 05:48:27 2006 From: daniel at brightfire.com (Daniel Lord) Date: Sat, 11 Feb 2006 20:48:27 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59 In-Reply-To: <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> References: <69BA87F3-4D68-46BE-AC23-EC386FC8D365@brightfire.com> <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> Message-ID: <527461CE-E5CF-470F-AB9A-0B591B443D48@brightfire.com> On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote: > > On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote: > >> >> On Feb 11, 2006, at 6:32 PM, pythonmac-sig-request at python.org wrote: >> >>> Ronald Oussoren wrote: >>> >>>> Totally off-topic, but if you'd move to setuptools you can keep >>>> several separate packages, but users could install using >>>> 'easy_install appscript' which would then take care of the >>>> dependencies for you. >>> >>> I think setuptools is going to be a great solution and definitely >>> plan to more there eventually. For now though, the mpkg-based >>> distribution provides a lower barrier to entry (one less thing to >>> install first), and it's a familiar format to all Mac users. One >>> of the obvious audiences for appscript is existing >>> AppleScripters, who aren't always overly enthusiastic about >>> approaching unfamiliar technology, so it keeps things simple for >>> them. >> >> this is a personal opinion so I don't expect consensus. I _like_ >> appscript. A lot. HAS did a great job with it. And while I like >> the power of Apple Events, I do not like Applescript--the syntax >> is not standard by design--it varies from application to >> application which in theory means flexibility but in practice >> means entropy and chaos. And some application developers cannot >> even get the AETE right and so their scripting is broken or at >> least crippled. Applescript does not have decent control >> structures nor regular expression support. Its file system syntax >> is horrific. I applaud the idea and the 'dream'--it just fell far >> short in practice. So using Python or Perl, whose syntax and >> language elements don't vary much from application to application >> is much better. The objects can vary--just not how to address >> them. I have used Mac::Glue with Perl, appscript with Python >> satisfactorily though I wish Apple would build in Apple Event >> support for those languages. > > That's irrelevant to appscript. If you're disappointed with the > inconsistency of a given application's scripting dictionary then > complain to the developer. Apple can't do a damn thing about it > (unless of course they're the developer of the given app). Apple > can't "build in support" for Python that would really be any > different than what current solutions offer. What they could do is > offer better tools for creating scripting dictionaries, and more > documentation on the topic, but that's about it. > > -bob > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/cd32c68b/attachment.htm From daniel at brightfire.com Sun Feb 12 05:48:57 2006 From: daniel at brightfire.com (Daniel Lord) Date: Sat, 11 Feb 2006 20:48:57 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59 In-Reply-To: <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> References: <69BA87F3-4D68-46BE-AC23-EC386FC8D365@brightfire.com> <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> Message-ID: On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote: > What they could do is offer better tools for creating scripting > dictionaries, and more documentation on the topic, but that's about > it. > > -bob > BINGO! You win! That's the point. From daniel at brightfire.com Sun Feb 12 06:05:54 2006 From: daniel at brightfire.com (Daniel Lord) Date: Sat, 11 Feb 2006 21:05:54 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59 In-Reply-To: <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> References: <69BA87F3-4D68-46BE-AC23-EC386FC8D365@brightfire.com> <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> Message-ID: On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote: > > On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote: > >> >> On Feb 11, 2006, at 6:32 PM, pythonmac-sig-request at python.org wrote: >> >>> Ronald Oussoren wrote: >>> >>>> Totally off-topic, but if you'd move to setuptools you can keep >>>> several separate packages, but users could install using >>>> 'easy_install appscript' which would then take care of the >>>> dependencies for you. >>> >>> I think setuptools is going to be a great solution and definitely >>> plan to more there eventually. For now though, the mpkg-based >>> distribution provides a lower barrier to entry (one less thing to >>> install first), and it's a familiar format to all Mac users. One >>> of the obvious audiences for appscript is existing >>> AppleScripters, who aren't always overly enthusiastic about >>> approaching unfamiliar technology, so it keeps things simple for >>> them. >> >> this is a personal opinion so I don't expect consensus. I _like_ >> appscript. A lot. HAS did a great job with it. And while I like >> the power of Apple Events, I do not like Applescript--the syntax >> is not standard by design--it varies from application to >> application which in theory means flexibility but in practice >> means entropy and chaos. And some application developers cannot >> even get the AETE right and so their scripting is broken or at >> least crippled. Applescript does not have decent control >> structures nor regular expression support. Its file system syntax >> is horrific. I applaud the idea and the 'dream'--it just fell far >> short in practice. So using Python or Perl, whose syntax and >> language elements don't vary much from application to application >> is much better. The objects can vary--just not how to address >> them. I have used Mac::Glue with Perl, appscript with Python >> satisfactorily though I wish Apple would build in Apple Event >> support for those languages. > > That's irrelevant to appscript. If you're disappointed with the > inconsistency of a given application's scripting dictionary then > complain to the developer. Apple can't do a damn thing about it > (unless of course they're the developer of the given app). Apple > can't "build in support" for Python that would really be any > different than what current solutions offer. What they could do is > offer better tools for creating scripting dictionaries, and more > documentation on the topic, but that's about it. > > -bob > Ah but it is, I disagree. Apple is the OS and platform vendor. It is their decisions on frameworks, tools, and languages that constrain us. And with Applescript they boxed us in with a poorly-thought-out and insufficiently-defined concept for a language and platform that allows dabbling but little else in practice. It is a failure--even on a low-market share platform it has little penetration and for a good reason--it is 'crap shoot' to use. Poorly and inconsistently supported. Sure blame the docs. In the end, the documentation for a tool is as important or even _more_ important than the tool even when its structure is flawed. So fine. Let's agree to disagree. I'll let Applescript's adoption number speak for my side of the argument. When is it going to be ported to Linux or WIndows like Python and Perl have? Applescript could work with COM and .Net Why hasn't anyone done it if its so great? Res ipsa loquitur. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/f4dae10e/attachment.html From bob at redivi.com Sun Feb 12 06:29:54 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 11 Feb 2006 21:29:54 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59 In-Reply-To: References: <69BA87F3-4D68-46BE-AC23-EC386FC8D365@brightfire.com> <1F40EDB8-848E-41C4-9011-4AA46EDE11C0@redivi.com> Message-ID: <26FD96E4-9967-448C-ADFC-F4654C49FF06@redivi.com> On Feb 11, 2006, at 9:05 PM, Daniel Lord wrote: > > On Feb 11, 2006, at 8:11 PM, Bob Ippolito wrote: > >> >> On Feb 11, 2006, at 7:37 PM, Daniel Lord wrote: >> >>> >>> On Feb 11, 2006, at 6:32 PM, pythonmac-sig-request at python.org wrote: >>> >>>> Ronald Oussoren wrote: >>>> >>>>> Totally off-topic, but if you'd move to setuptools you can keep >>>>> several separate packages, but users could install using >>>>> 'easy_install appscript' which would then take care of the >>>>> dependencies for you. >>>> >>>> I think setuptools is going to be a great solution and >>>> definitely plan to more there eventually. For now though, the >>>> mpkg-based distribution provides a lower barrier to entry (one >>>> less thing to install first), and it's a familiar format to all >>>> Mac users. One of the obvious audiences for appscript is >>>> existing AppleScripters, who aren't always overly enthusiastic >>>> about approaching unfamiliar technology, so it keeps things >>>> simple for them. >>> >>> this is a personal opinion so I don't expect consensus. I _like_ >>> appscript. A lot. HAS did a great job with it. And while I like >>> the power of Apple Events, I do not like Applescript--the syntax >>> is not standard by design--it varies from application to >>> application which in theory means flexibility but in practice >>> means entropy and chaos. And some application developers cannot >>> even get the AETE right and so their scripting is broken or at >>> least crippled. Applescript does not have decent control >>> structures nor regular expression support. Its file system syntax >>> is horrific. I applaud the idea and the 'dream'--it just fell far >>> short in practice. So using Python or Perl, whose syntax and >>> language elements don't vary much from application to application >>> is much better. The objects can vary--just not how to address >>> them. I have used Mac::Glue with Perl, appscript with Python >>> satisfactorily though I wish Apple would build in Apple Event >>> support for those languages. >> >> That's irrelevant to appscript. If you're disappointed with the >> inconsistency of a given application's scripting dictionary then >> complain to the developer. Apple can't do a damn thing about it >> (unless of course they're the developer of the given app). Apple >> can't "build in support" for Python that would really be any >> different than what current solutions offer. What they could do >> is offer better tools for creating scripting dictionaries, and >> more documentation on the topic, but that's about it. > > Ah but it is, I disagree. Apple is the OS and platform vendor. It > is their decisions on frameworks, tools, and languages that > constrain us. And with Applescript they boxed us in with a poorly- > thought-out and insufficiently-defined concept for a language and > platform that allows dabbling but little else in practice. It is a > failure--even on a low-market share platform it has little > penetration and for a good reason--it is 'crap shoot' to use. > Poorly and inconsistently supported. Sure blame the docs. In the > end, the documentation for a tool is as important or even _more_ > important than the tool even when its structure is flawed. So fine. > Let's agree to disagree. I'll let Applescript's adoption number > speak for my side of the argument. When is it going to be ported to > Linux or WIndows like Python and Perl have? Applescript could work > with COM and .Net Why hasn't anyone done it if its so great? Res > ipsa loquitur. Well, COM isn't really used anywhere but Win32, and Apple Events are basically Apple's version of out-of-process COM. Yes, it's crappy as a language, and it's also very old. However, switching to COM wouldn't do a damn thing for anyone. COM sucks too -- it's actually worse technically. Apple Events are actually a lot more like SOAP than COM, but how they should switch to something HTTP based isn't all that clear yet. There's nothing obvious that's 10x better. Obviously it'll tie in with Bonjour, but SOAP isn't exactly a winner. We'll just have to see what happens. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/cf7e6ba1/attachment.htm From berkowit at silcom.com Sun Feb 12 07:35:57 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Sat, 11 Feb 2006 22:35:57 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 59 In-Reply-To: <26FD96E4-9967-448C-ADFC-F4654C49FF06@redivi.com> Message-ID: On 2/11/06 9:29 PM, "Bob Ippolito" wrote: > > Well, COM isn't really used anywhere but Win32, and Apple Events are basically > Apple's version of out-of-process COM.? Yes, it's crappy as a language, and > it's also very old.? However, switching to COM wouldn't do a damn thing for > anyone.? COM sucks too -- it's actually worse technically. > > Apple Events are actually a lot more like SOAP than COM, but how they should > switch to something HTTP based isn't all that clear yet.? There's nothing > obvious that's 10x better.? Obviously it'll tie in with Bonjour, but SOAP > isn't exactly a winner.? We'll just have to see what happens. The lead AppleScript engineer has had a totally revamped, rational, OO, "AppleScript 2" (or "AppleScript X" depending on whom you talk to), on the cards for a few years now. He has been prevented from proceeding with it for the time being. None of the AppleScript team will divulge whether this will ever see the light of day - they may not know. -- Paul Berkowitz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060211/39392310/attachment.html From ronaldoussoren at mac.com Sun Feb 12 09:20:49 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 09:20:49 +0100 Subject: [Pythonmac-SIG] xcode as IDE? In-Reply-To: References: Message-ID: <7E99E096-D266-4623-8443-92A941E71101@mac.com> On 12-feb-2006, at 4:39, I. Vinogradov wrote: > Hello All, > > while on the topic of IDEs, would it be possible to somehow adapt > Xcode > to the task? It has Python keyword highlight, and PyObjC is one of the > possible types of documents. Xcode isn't a very useful python environment right now. It is basicly just a complicated text editor with syntax coloring support. I'd very much like to see good Python support in Xcode to make it easier to use Xcode's tools for Python scripts, but that is not going to happen without support from Apple. I have filed a feature request at Apple to implement Python support in Xcode or at least open up the Xcode APIs to make it possible to do this ourselves. Please file another feature request (at bugreport.apple.com), more requests for a feature seems to give the request more weight at Apple. BTW. PyObjC is one of the possible types of projects because PyObjC's installer includes a number of project and file templates. > > I have some vague notion that perhaps a pure python file template can > be made, that uses framework installation and all. Is something like > that even possible? That is easy, but see above (and Bob's mail) for reasons why this is not very useful. Ronald > > Regards, Ivan. > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/80ac7fc3/attachment.bin From hengist.podd at virgin.net Sun Feb 12 08:49:05 2006 From: hengist.podd at virgin.net (has) Date: Sun, 12 Feb 2006 07:49:05 +0000 Subject: [Pythonmac-SIG] How to fetch iCal todo description? Message-ID: skip wrote: >I'm stuck trying to figure out how to get the notes for a todo. If I create >a todo via iCal and add a note to it, I don't see any property of the todo >instance that contains that note. The HTMLDictionary output doesn't list >"description" or "note" as one of the properties of a todo item, yet it's >clearly there in iCal. It's definitely there in 10.3 and 10.4, even if they have bodged up the dictionary a bit in 10.4. todo -- This class represents a task. Parent: (Bad terminology: can't find class with AE code '****'.) Properties: completion_date DateTime -- The todo completion date. due_date DateTime -- The todo due date. priority k.no_priority | k.low_priority | k.medium_priority | k.high_priority -- The todo priority. sequence (r/o) Integer -- The todo version. stamp_date (r/o) DateTime -- The todo modification date. summary Unicode -- This is the todo summary. description Unicode -- The todo notes. ***************** uid (r/o) Unicode -- A unique todo key. url Unicode -- The URL associated to the todo. Elements: display_alarms -- mail_alarms -- open_file_alarms -- sound_alarms -- Try: ical = app('iCal') ical.calendars[1].todos.end.make(new=k.todo, with_properties={k.description:'hello world'}) print ical.calendars[1].todos[-1].description() has -- http://freespace.virgin.net/hamish.sanderson/ From skip at pobox.com Sun Feb 12 17:21:11 2006 From: skip at pobox.com (skip at pobox.com) Date: Sun, 12 Feb 2006 10:21:11 -0600 Subject: [Pythonmac-SIG] How to fetch iCal todo description? In-Reply-To: References: Message-ID: <17391.24695.731990.833322@montanaro.dyndns.org> has> It's definitely there in 10.3 and 10.4, ... ... has> Properties: ... has> description Unicode -- The todo notes. ***************** ... Note when I looked (OSX 10.3.9, iCal 1.5.5). I ran out and bought Tiger last night. It's there now... Thanks, Skip From berkowit at silcom.com Sun Feb 12 18:22:33 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Sun, 12 Feb 2006 09:22:33 -0800 Subject: [Pythonmac-SIG] How to fetch iCal todo description? In-Reply-To: Message-ID: Whoa! So now you're saying that - in spite of AppleScript not having 'description' in the iCal 1.5.5 dictionary in Panther - appscript can still get it? Do you mind explaining how that might be possible, has? Note that there are some OS versions and script editors (e.g. Script Debugger 4 in OS 10.4.4) which - when you try to open an AppleScript dictionary of an iApp on another partition with another OS installed, actually shows you the dictionary of the iApp on your currently booted OS. (Cocoa sdef applications insist on opening when you try to look at their dictionaries, and only the version of the Apple iApp applications belonging to your booted OS can open.) Other script editors and OS versions (e,g, Script Editor 2.1.1 and Smile 3.0.6 in OS 10.4.4) simply refuse to open invalid iApp version dictionaries. Do you think maybe you've been taken in by this, has? Perhaps you're in Tiger and thought you were looking at iCal 1.5.x's dictionary? You weren't - it was iCal 2.0.x's dictionary. That has 'description' of todo. iCal 1.5.x does not. It is fully documented that iCal 1.5 in Panther did NOT have 'description' in its AppleScript dictionary. As Skip says, I reported that on AppleScript-Users in 2003. I also, more effectively I think, made a bug report at bugreporter.apple.com . I also tried to bring it up at WWDC 2004 but there was no one there to discuss it with, although I did send an urgent reminder through an intermediary. Nevertheless, they did act on my bug report. (I was asked to check it out in a very late beta of 10.4.). My understanding was that appscript worked through the same dictionary as AppleScript. If you're now saying that appscript could somehow access a property named 'description' of todo, even though no such property exists in the Panther iCal 1.5.5 AppleScript dictionary (although of course the UI todo does indeed have "Notes") - how exactly does it do it? Or have you been fooled by OS X's way of blocking older versions of iApps from opening in later booted OS versions and thus from exposing their dictionaries? -- Paul Berkowitz > From: has > Date: Sun, 12 Feb 2006 07:49:05 +0000 > To: > Subject: Re: [Pythonmac-SIG] How to fetch iCal todo description? > > skip wrote: > >> I'm stuck trying to figure out how to get the notes for a todo. If I create >> a todo via iCal and add a note to it, I don't see any property of the todo >> instance that contains that note. The HTMLDictionary output doesn't list >> "description" or "note" as one of the properties of a todo item, yet it's >> clearly there in iCal. > > It's definitely there in 10.3 and 10.4, even if they have bodged up the > dictionary a bit in 10.4. > > todo -- This class represents a task. > Parent: > (Bad terminology: can't find class with AE code '****'.) > Properties: > completion_date DateTime -- The todo completion date. > due_date DateTime -- The todo due date. > priority k.no_priority | k.low_priority | k.medium_priority | k.high_priority > -- The todo priority. > sequence (r/o) Integer -- The todo version. > stamp_date (r/o) DateTime -- The todo modification date. > summary Unicode -- This is the todo summary. > description Unicode -- The todo notes. ***************** > uid (r/o) Unicode -- A unique todo key. > url Unicode -- The URL associated to the todo. > Elements: > display_alarms -- > mail_alarms -- > open_file_alarms -- > sound_alarms -- > > Try: > > ical = app('iCal') > ical.calendars[1].todos.end.make(new=k.todo, > with_properties={k.description:'hello world'}) > print ical.calendars[1].todos[-1].description() > > has > -- > http://freespace.virgin.net/hamish.sanderson/ > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From janssen at parc.com Sun Feb 12 19:23:37 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 12 Feb 2006 10:23:37 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Sat, 11 Feb 2006 10:56:23 PST." <480B44CB-BF25-4E62-9E7F-B98000C7A71B@mac.com> Message-ID: <06Feb12.102339pst."58633"@synergy1.parc.xerox.com> > Seems like nice little project for someone that does want to push > Apple's python, > build a (tiny) download that contains 'IDLE.app'. And presto, you have > a simple IDE for someone that doesn't want to use the terminal ;-) 10.4 only, of course. Bill From janssen at parc.com Sun Feb 12 19:25:27 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 12 Feb 2006 10:25:27 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Sat, 11 Feb 2006 12:16:21 PST." <5300FDFA-BB8F-4043-B35B-5DDC02B45D35@mac.com> Message-ID: <06Feb12.102534pst."58633"@synergy1.parc.xerox.com> > > So it seems that a old Unix-style Python program which reads from > > stdin (or a file or a tty) and writes to stdout would be difficult to > > explain to someone who has never used a command line. And there's > > essentially no way to get Idle started without using a command line. > > If you install py2app and then run the setup script below you'll end > up with IDLE-2.3.app in the dist directory. Don't you have to use the command line to run the setup script? Bill From janssen at parc.com Sun Feb 12 19:28:56 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 12 Feb 2006 10:28:56 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Sat, 11 Feb 2006 12:58:13 PST." <44F40EB7-8533-4713-8F7A-964CE81202D3@mac.com> Message-ID: <06Feb12.102859pst."58633"@synergy1.parc.xerox.com> > > So you're saying that the pre-installed version could never be really > > acceptable. In that case, perhaps we only need convince Apple to move > > /usr/bin/python to some more system-y place that wouldn't usually be > > on users' paths. > > > > We then in the MacPython world take the position that Python isn't > > really pre-installed on Macs, and the place for a person to start > > would be to download the installer and run it. Perhaps then in > > addition the installer could symlink /usr/local/bin/pythonw to > > /usr/bin/python, thereby solving the PATH issue. > > That won't happen. Replacing system components is completely wrong, > what if someone finds a security bug in /usr/bin/python and Apple ships > a security update to fix it [*]. The installer should update the user's > path to ensure that our version of python is earlier on the PATH. I guess that would be one way to get Apple to ship Python updates :-). You missed the first part of my message, I think. The system version would be installed under /usr/libexec/, or some such place, not under /usr/bin/. That would leave /usr/bin free for the MacPython gang to install its version, or at least a symlink to /usr/local/bin/pythonw. Bill From ronaldoussoren at mac.com Sun Feb 12 19:27:54 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 19:27:54 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb12.102534pst.58633@synergy1.parc.xerox.com> References: <06Feb12.102534pst.58633@synergy1.parc.xerox.com> Message-ID: <304454AD-FCE0-4F2B-96A8-436A06E9B649@mac.com> On 12-feb-2006, at 19:25, Bill Janssen wrote: >>> So it seems that a old Unix-style Python program which reads from >>> stdin (or a file or a tty) and writes to stdout would be >>> difficult to >>> explain to someone who has never used a command line. And there's >>> essentially no way to get Idle started without using a command line. >> >> If you install py2app and then run the setup script below you'll end >> up with IDLE-2.3.app in the dist directory. > > Don't you have to use the command line to run the setup script? Someone will have to do that, but this end-result can be stuffed into a DMG and made available on the web. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/309b5982/attachment.bin From ronaldoussoren at mac.com Sun Feb 12 19:30:56 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 19:30:56 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb12.102859pst.58633@synergy1.parc.xerox.com> References: <06Feb12.102859pst.58633@synergy1.parc.xerox.com> Message-ID: On 12-feb-2006, at 19:28, Bill Janssen wrote: >>> So you're saying that the pre-installed version could never be >>> really >>> acceptable. In that case, perhaps we only need convince Apple to >>> move >>> /usr/bin/python to some more system-y place that wouldn't usually be >>> on users' paths. >>> >>> We then in the MacPython world take the position that Python isn't >>> really pre-installed on Macs, and the place for a person to start >>> would be to download the installer and run it. Perhaps then in >>> addition the installer could symlink /usr/local/bin/pythonw to >>> /usr/bin/python, thereby solving the PATH issue. >> >> That won't happen. Replacing system components is completely wrong, >> what if someone finds a security bug in /usr/bin/python and Apple >> ships >> a security update to fix it [*]. The installer should update the >> user's >> path to ensure that our version of python is earlier on the PATH. > > I guess that would be one way to get Apple to ship Python updates :-). > > You missed the first part of my message, I think. The system version > would be installed under /usr/libexec/, or some such place, not under > /usr/bin/. That would leave /usr/bin free for the MacPython gang to > install its version, or at least a symlink to /usr/local/bin/pythonw. The system version is installed in /usr/bin. Or do you mean we should only support some future version where Apple doesn't place python in /usr/bin (which I hope doesn't happen)? Ronald > > Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/86458a61/attachment.bin From janssen at parc.com Sun Feb 12 19:36:54 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 12 Feb 2006 10:36:54 PST Subject: [Pythonmac-SIG] xcode as IDE? In-Reply-To: Your message of "Sat, 11 Feb 2006 20:06:33 PST." Message-ID: <06Feb12.103654pst."58633"@synergy1.parc.xerox.com> Bob writes: > the custom build+run target is > for some crazy reason stored as a user setting rather than a project > setting. It's also prone to break at any Xcode update because it > needs to read the undocumented Xcode project file format in order to > get the information it needs. And, Ivan, if you care about using Xcode with Python, please file bug reports with Apple about these issues. Bill From hengist.podd at virgin.net Sun Feb 12 20:17:33 2006 From: hengist.podd at virgin.net (has) Date: Sun, 12 Feb 2006 19:17:33 +0000 Subject: [Pythonmac-SIG] How to fetch iCal todo description? Message-ID: Paul Berkowitz wrote: >So now you're saying that - in spite of AppleScript not having 'description' >in the iCal 1.5.5 dictionary in Panther - appscript can still get it? Do you >mind explaining how that might be possible, has? I did check 1.5.5 in 10.4, but I know it's not iCal 2.0's dictionary I was looking at because the two dictionaries look different. iCal's .scriptTerminology file defines a 'description' property for calendar, event and todo classes, and always has. If they're not showing up on 10.3 it could be because the definitions themselves are suspect (there's an unfamiliar 'Sex' key), and 10.3 is fussier than 10.4 about this. I suspect that rather than fix the .scriptTerminology they relaxed the .scriptTerminology->aete conversion in 10.4. I'm not rebooting into 10.3 to check this theory just now though, but feel free to dink about with it yourself. But it'd certainly explain why I could see the properties on 10.4 while someone on 10.3 wouldn't. Plus it means that the problem may well be fixable on 10.3 with a bit of judicious editing of the relevant entries. has -- http://freespace.virgin.net/hamish.sanderson/ From berkowit at silcom.com Sun Feb 12 20:32:00 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Sun, 12 Feb 2006 11:32:00 -0800 Subject: [Pythonmac-SIG] How to fetch iCal todo description? In-Reply-To: Message-ID: On 2/12/06 11:17 AM, "has" wrote: > iCal's .scriptTerminology file defines a 'description' property for calendar, > event and todo classes, and always has. If they're not showing up on 10.3 it > could be because the definitions themselves are suspect (there's an unfamiliar > 'Sex' key), and 10.3 is fussier than 10.4 about this. I suspect that rather > than fix the .scriptTerminology they relaxed the .scriptTerminology->aete > conversion in 10.4. 'description' of event and of calendar did show up in 10.3, just not description of todo. (And I have a vague recollection that 'description' of calendar gave you the entire iCal data for the calendar instead of just the little description you see in the UI's Info pane, as 10.4 does correctly. But I might be wrong, since I never knew about that little description until last week and am also not in 10.3 to check.) 'description' of event always worked properly in 10.3. Do you see any differences between event's and todo's 'description'? I suspect the bug might have been in the deeper implementation links from dictionary to object. > > I'm not rebooting into 10.3 to check this theory just now though, but feel > free to dink about with it yourself. But it'd certainly explain why I could > see the properties on 10.4 while someone on 10.3 wouldn't. Plus it means that > the problem may well be fixable on 10.3 with a bit of judicious editing of the > relevant entries. Hmmm? -- Paul Berkowitz From janssen at parc.com Sun Feb 12 20:38:46 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 12 Feb 2006 11:38:46 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Sun, 12 Feb 2006 10:30:56 PST." Message-ID: <06Feb12.113849pst."58633"@synergy1.parc.xerox.com> > The system version is installed in /usr/bin. Or do you mean we should > only support some future version where Apple doesn't place python in > /usr/bin (which I hope doesn't happen)? Yes, that was the idea. /usr/libexec/python, or some other directory unlikely to be on the user's path by default. I don't know about "only support". "Hope for" was more like it. Bill From janssen at parc.com Sun Feb 12 20:43:23 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 12 Feb 2006 11:43:23 PST Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: Your message of "Sun, 12 Feb 2006 10:27:54 PST." <304454AD-FCE0-4F2B-96A8-436A06E9B649@mac.com> Message-ID: <06Feb12.114325pst."58633"@synergy1.parc.xerox.com> I understand that there is a version of IDLE.app already in the 2.4.1 installer. Bill From bob at redivi.com Sun Feb 12 20:48:52 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 12 Feb 2006 11:48:52 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb12.113849pst."58633"@synergy1.parc.xerox.com> References: <06Feb12.113849pst."58633"@synergy1.parc.xerox.com> Message-ID: <0D764F00-F7CA-46CE-99E9-6160CE46419C@redivi.com> On Feb 12, 2006, at 11:38 AM, Bill Janssen wrote: >> The system version is installed in /usr/bin. Or do you mean we should >> only support some future version where Apple doesn't place python in >> /usr/bin (which I hope doesn't happen)? > > Yes, that was the idea. /usr/libexec/python, or some other directory > unlikely to be on the user's path by default. > > I don't know about "only support". "Hope for" was more like it. It's not really a good idea, and it certainly has near zero chance of happening -- ever. Asking Apple to move their Python interpreter is dead in the water. -bob From bob at redivi.com Sun Feb 12 20:50:39 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 12 Feb 2006 11:50:39 -0800 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <06Feb12.114325pst."58633"@synergy1.parc.xerox.com> References: <06Feb12.114325pst."58633"@synergy1.parc.xerox.com> Message-ID: <8EE96FD2-B8F7-4F8E-A5F1-F0B0628131E4@redivi.com> On Feb 12, 2006, at 11:43 AM, Bill Janssen wrote: > I understand that there is a version of IDLE.app already in the 2.4.1 > installer. Yes. The given setup.py only creates an IDLE.app for the vendor Python 2.3 that ships with OS X. It's just a follow-up to an earlier conversation in the thread, it's not a recommendation for something we should be distributing. -bob From ronaldoussoren at mac.com Sun Feb 12 22:20:52 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 22:20:52 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <0D764F00-F7CA-46CE-99E9-6160CE46419C@redivi.com> References: <06Feb12.113849pst.58633@synergy1.parc.xerox.com> <0D764F00-F7CA-46CE-99E9-6160CE46419C@redivi.com> Message-ID: On 12-feb-2006, at 20:48, Bob Ippolito wrote: > > On Feb 12, 2006, at 11:38 AM, Bill Janssen wrote: > >>> The system version is installed in /usr/bin. Or do you mean we >>> should >>> only support some future version where Apple doesn't place python in >>> /usr/bin (which I hope doesn't happen)? >> >> Yes, that was the idea. /usr/libexec/python, or some other directory >> unlikely to be on the user's path by default. >> >> I don't know about "only support". "Hope for" was more like it. > > It's not really a good idea, and it certainly has near zero chance > of happening -- ever. Asking Apple to move their Python > interpreter is dead in the water. I sure hope so. /usr/bin/python has its uses. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/5d3f35e2/attachment.bin From ronaldoussoren at mac.com Sun Feb 12 22:24:33 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 22:24:33 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: References: <06Feb10.143151pst.58633@synergy1.parc.xerox.com> <761513FC-21FB-4F29-9CD7-35384482A2C1@conncoll.edu> <133E62D7-2C66-406F-BB0E-180C8D0DFA2F@mac.com> Message-ID: On 11-feb-2006, at 23:50, Charles Hartman wrote: > >> Not that I want to bundle Tcl/Tk, > > --especially given the download/install overhead, right? Mostly because my primary platform is 10.4 and I already have installed AquaTclTk on my 10.3 test system. This makes testing the bundled installation hard. Doing it correctly also isn't entirely trivial: you have pick the subset of AquaTclTk that is needed for _tkinter because of the size of the full package and make sure that the bundled subset won't replace whatever the user has already installed. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/92bbcc6f/attachment.bin From ronaldoussoren at mac.com Sun Feb 12 22:28:33 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 22:28:33 +0100 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb12.113849pst.58633@synergy1.parc.xerox.com> References: <06Feb12.113849pst.58633@synergy1.parc.xerox.com> Message-ID: <4DC96479-875E-42AF-9394-33EEA9E3D518@mac.com> On 12-feb-2006, at 20:38, Bill Janssen wrote: >> The system version is installed in /usr/bin. Or do you mean we should >> only support some future version where Apple doesn't place python in >> /usr/bin (which I hope doesn't happen)? > > Yes, that was the idea. /usr/libexec/python, or some other directory > unlikely to be on the user's path by default. > > I don't know about "only support". "Hope for" was more like it. If you want to install MacPython's python interpreter as /usr/bin/python without replacing system compontents the MacPython distribution wouldn't be useable on any existing OSX version. That's what I meant with "only support". Even if Apple were to move it's python interpreter of the default PATH (and I hope they won't do that), I wouldn't be in favor of installing into /usr/bin. It is very annoying when software gets installed into system locations, especially when you don't quite know what got installed. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/e4178f6f/attachment-0001.bin From ronaldoussoren at mac.com Sun Feb 12 22:37:23 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 22:37:23 +0100 Subject: [Pythonmac-SIG] New Page, first proposal In-Reply-To: <8EE96FD2-B8F7-4F8E-A5F1-F0B0628131E4@redivi.com> References: <06Feb12.114325pst.58633@synergy1.parc.xerox.com> <8EE96FD2-B8F7-4F8E-A5F1-F0B0628131E4@redivi.com> Message-ID: On 12-feb-2006, at 20:50, Bob Ippolito wrote: > > On Feb 12, 2006, at 11:43 AM, Bill Janssen wrote: > >> I understand that there is a version of IDLE.app already in the 2.4.1 >> installer. > > Yes. The given setup.py only creates an IDLE.app for the vendor > Python 2.3 that ships with OS X. It's just a follow-up to an > earlier conversation in the thread, it's not a recommendation for > something we should be distributing. I had a gigantic backlog thanks to this thread :-). The setup script was written to make a point: it is very easy to create a tiny application bundle that will give you a clickable IDLE icon that will use the python that ships with OS X. I wrote this after someone suggested that this could be accomplished using an applescript applet. I lost track in the discussion about whether the pythonmac.org site should mention the system python at all, but if it should this application could be used to give users a simple GUI environment. Then point them to the full MacPython distribution if they like what they see :-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/dc59e8a4/attachment.bin From janssen at parc.com Sun Feb 12 23:55:46 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 12 Feb 2006 14:55:46 PST Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: Your message of "Sun, 12 Feb 2006 13:20:52 PST." Message-ID: <06Feb12.145550pst."58633"@synergy1.parc.xerox.com> > > It's not really a good idea, and it certainly has near zero chance > > of happening -- ever. Asking Apple to move their Python > > interpreter is dead in the water. > > I sure hope so. /usr/bin/python has its uses. I wish someone would explain to me what /usr/bin/python can do that /usr/libexec/python cannot do. Bill From bob at redivi.com Mon Feb 13 00:09:19 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 12 Feb 2006 15:09:19 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb12.145550pst."58633"@synergy1.parc.xerox.com> References: <06Feb12.145550pst."58633"@synergy1.parc.xerox.com> Message-ID: <0CD7AFCE-13C2-40DE-89AA-C6985CD8C81E@redivi.com> On Feb 12, 2006, at 2:55 PM, Bill Janssen wrote: >>> It's not really a good idea, and it certainly has near zero chance >>> of happening -- ever. Asking Apple to move their Python >>> interpreter is dead in the water. >> >> I sure hope so. /usr/bin/python has its uses. > > I wish someone would explain to me what /usr/bin/python can do that > /usr/libexec/python cannot do. It's standard, and that's how it currently works. There is no good reason to change anything Even if they did decide to change it, the change would simply cause us to do twice as much work for the next couple years to support both layouts. -bob From ronaldoussoren at mac.com Sun Feb 12 22:19:24 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 12 Feb 2006 22:19:24 +0100 Subject: [Pythonmac-SIG] Build script for Universal Python Message-ID: Bob, The attached patch replaces the script in Mac/OSX/Dist by a python script that builds a "batteries included" universal binary. The attached background.jpg should be placed in Mac/OSX/Dist/resources (and hopefully someone donates a nicer image). Due to lack of time I haven't tested the installer and contained binaries yet. Things that should be fixed: 1. 'make frameworkinstall' will no longer install files in /usr/local/ bin. 2. the postflight script should be rewritten, it creates a shellscript version of pythonw 3. the package is a ".pkg" instead of an ".mpkg". This should make it possible to create an installer that is truely "batteries included" in the future. 4. the package doesn't update user profiles (should be an optional .pkg in the .mpkg). 5. there's still 'python' and 'pythonw' that behave differently, python should be replaced by pythonw and pythonw should be a symlink to python for backward compatibility. 6. A patch for distutils that allows compiling on 10.3.9 7. A patch for distutils that recognizes '-arch' and '-isysroot' in extra_compile_args and extra_link_args and removes those flags from CFLAGS/LDFLAGS 8. The Python documentation is no longer installed as a help book. What definitely should be tested: 1. Run 'regrtest -uall' on 10.3.9(PPC), 10.4.4(PPC) and 10.4.4(Intel) 2. Try to use existing 10.3 packages with this build, especially C++ ones. Ronald -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cur-diff.txt Url: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/d01970d3/attachment-0001.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: background.jpg Type: image/jpeg Size: 21714 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/d01970d3/attachment-0001.jpg -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060212/d01970d3/attachment-0001.bin From bob at redivi.com Mon Feb 13 01:37:16 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 12 Feb 2006 16:37:16 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: References: Message-ID: On Feb 12, 2006, at 1:19 PM, Ronald Oussoren wrote: > The attached patch replaces the script in Mac/OSX/Dist by a python > script that builds a "batteries included" universal binary. The > attached background.jpg should be placed in Mac/OSX/Dist/resources > (and hopefully someone donates a nicer image). > > Due to lack of time I haven't tested the installer and contained > binaries yet. > > Things that should be fixed: > 1. 'make frameworkinstall' will no longer install files in /usr/ > local/bin. > 2. the postflight script should be rewritten, it creates a > shellscript version of pythonw > 3. the package is a ".pkg" instead of an ".mpkg". This should make > it possible to create an installer that is truely "batteries > included" in the future. .mpkg can depend on other .mpkg... that's not really worth mentioning. You need a .pkg file *somewhere* because .mpkg can only reference .pkg or .mpkg. > 4. the package doesn't update user profiles (should be an > optional .pkg in the .mpkg). In order to make it optional, the outer shell needs to be a .mpkg and it needs to reference an optional .pkg that does this in postflight. > 5. there's still 'python' and 'pythonw' that behave differently, > python should be replaced by pythonw and pythonw should be a > symlink to python for backward compatibility. > 6. A patch for distutils that allows compiling on 10.3.9 > 7. A patch for distutils that recognizes '-arch' and '-isysroot' in > extra_compile_args and extra_link_args and removes those flags from > CFLAGS/LDFLAGS Aren't 5. and 6. the same thing? > 8. The Python documentation is no longer installed as a help book. I wonder how hard this is to add to IDLE, or if we can just link to HTML docs. I'm not personally a big fan of Help Book anyway. -bob From skip at pobox.com Mon Feb 13 02:50:20 2006 From: skip at pobox.com (skip at pobox.com) Date: Sun, 12 Feb 2006 19:50:20 -0600 Subject: [Pythonmac-SIG] ical.py loose in the wild Message-ID: <17391.58844.13400.495098@montanaro.dyndns.org> My little iCal event/todo manipulator is loose and available from my Python Bits page: http://orca.mojam.com/~skip/python/ It allows you to add or print iCal events and todos from the command line. You can also feed appropriately formatted email messages to it and turn them into todos or events. Skip From gabor at nekomancer.net Mon Feb 13 11:00:39 2006 From: gabor at nekomancer.net (=?ISO-8859-1?Q?G=E1bor_Farkas?=) Date: Mon, 13 Feb 2006 11:00:39 +0100 Subject: [Pythonmac-SIG] Fink vs. MacPython In-Reply-To: References: Message-ID: <43F058C7.6070502@nekomancer.net> Markus wrote: > Hi! > > Somewhere deep in the latest discussion I read a remark by Bob that > he would not recommend the use of Finks python (there also was > another that he didn't like Debian so that may explain it :) > > I came from Debian to OS X and nearly the first thing I did was to > install Fink and thusly python. The three extensions I needed so far > did install with 'python setup.py install' and everything works fine > for me. > > So why is Fink 'bad'? Am I missing some features I would have had > with MacPython? as others already stated, if you want to interact with the "apple" part of the operating system (gui & things like that), then that simply cannot be done with fink-python. on the other hand, if you need to work with the "non-gui" part (for example use postgresql-with-python, sqlite-with-python, anything-with-python), then that's much easier with fink or darwinports. gabor From energias.renovables.ya at gmail.com Mon Feb 13 13:22:42 2006 From: energias.renovables.ya at gmail.com (Perico) Date: Mon, 13 Feb 2006 13:22:42 +0100 Subject: [Pythonmac-SIG] runnig code step by step Message-ID: <55C2A915-2246-4CF8-A5BE-9E748C10B7C6@gmail.com> I have that piece of code: while 1: a=raw_input("Press a key to continue") I'd like to change the last line, I don't want to control a key press if not I want to control a button of the form My question is if somthing exists to control the push button event. See you. Peter. From ken at sparklight.com Mon Feb 13 15:10:28 2006 From: ken at sparklight.com (Ken Brooks) Date: Mon, 13 Feb 2006 09:10:28 -0500 Subject: [Pythonmac-SIG] Readline In-Reply-To: <43CD2F98.5050303@noaa.gov> References: <43CD2F98.5050303@noaa.gov> Message-ID: Finally choosing to find the time, I installed MacPython 2.4.1. But now I need documentation, and Google was not helpful. What keystrokes have new meanings in the MacPython interactive window as a result of having readline? Ken At 9:55 AM -0800 1/17/06, Christopher Barker wrote: >Ken Brooks wrote: >>Still nothing changes! So how does the debug loop work? How can I >>reload a module short of relaunching the environment?? > ^^^^^^ > >You've just inadvertently answered your own question. That's what we mean when we say "Python fits your brain": > >>>> reload(foo) > >Python caches modules so that if one module is imported in ten different places, it doesn't reload them each time. To force a reload you use, appropriately enough, the reload function. > >>2. I really wish for the "doskey" feature that lets you easily >>retrieve and edit a line previously typed to the interactive >>interpreter. Does it exist here? > >Yup. It's called readline. Apple doesn't ship it with OS-X, because it's licensed under the GPL, but you can install in separately, or you can install a new version of python that has it. > >See: >http://undefined.org/python/ > >for a newer Python, and: > >http://www.pythonmac.org/packages/ > >For an assortment of add-on packages > >There is a readline for th python 2.3 that came with OS-X 10.4 there. It may work with 10.4 also, if you install "TigerPython23Compat" from that page also. > >All that being said, you might want to try one of the fancier python shells for interactive use, like ipython. Or, just write your entire script in a file (or multiple files) and restart python each time. It's rare that something take that long to run that re-starting is a problem. You can start it with: > >$ python -i MyScript.py > >and you'll get the interpreter prompt when it's done running. > >-Chris > > >- > >Christopher Barker, Ph.D. >Oceanographer > >NOAA/OR&R/HAZMAT (206) 526-6959 voice >7600 Sand Point Way NE (206) 526-6329 fax >Seattle, WA 98115 (206) 526-6317 main reception > >Chris.Barker at noaa.gov From ken at sparklight.com Mon Feb 13 17:44:23 2006 From: ken at sparklight.com (Ken Brooks) Date: Mon, 13 Feb 2006 11:44:23 -0500 Subject: [Pythonmac-SIG] Debugger Message-ID: Same issue, different topic: Google "macpython debugger" reveals many commentators who revel in the fact that it has one, and no info on how to invoke it. MacPython help has no such topic, either. Where is it documented? Ken Brooks Sparkling Light Software From sw at wordtech-software.com Mon Feb 13 18:00:44 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon, 13 Feb 2006 12:00:44 -0500 Subject: [Pythonmac-SIG] Debugger In-Reply-To: References: Message-ID: <43F0BB3C.6040000@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ken Brooks wrote: > Same issue, different topic: Google "macpython debugger" reveals many commentators who revel in the fact that it has one, and no info on how to invoke it. MacPython help has no such topic, either. Where is it documented? > > Ken Brooks > Sparkling Light Software > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > IDLE seems to have a debugger tool built-in. PythonIDE does not as far as I can tell. And PythonIDE is about to go to the bit bucket, once the universal build of MacPython is released. - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8Ls7JmdQs+6YVcoRAj8iAJ9BwTW6I7mGkxNT86ukbdzmbu/yZQCfRZLW mDD/vsXRBPko9Z9X292+kAQ= =J6gA -----END PGP SIGNATURE----- From bob at redivi.com Mon Feb 13 18:01:59 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 09:01:59 -0800 Subject: [Pythonmac-SIG] Debugger In-Reply-To: References: Message-ID: <84035E2C-6F8C-4BB9-8BBD-14EAAFCD5D67@redivi.com> On Feb 13, 2006, at 8:44 AM, Ken Brooks wrote: > Same issue, different topic: Google "macpython debugger" reveals > many commentators who revel in the fact that it has one, and no > info on how to invoke it. MacPython help has no such topic, > either. Where is it documented? It's not documented, and the PythonIDE has been deprecated for years. Don't bother with it, because it's disappearing in the release anyway since it has no hope of being Intel compatible. I believe there's a debugger in IDLE, and the one in Wing IDE is pretty good (but that's a commercial X11 app). Normally I just use pdb, which is strictly console based. -bob From Chris.Barker at noaa.gov Mon Feb 13 18:06:06 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 13 Feb 2006 09:06:06 -0800 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <06Feb12.102859pst.58633@synergy1.parc.xerox.com> References: <06Feb12.102859pst.58633@synergy1.parc.xerox.com> Message-ID: <43F0BC7E.40104@noaa.gov> Bill Janssen wrote: > You missed the first part of my message, I think. The system version > would be installed under /usr/libexec/, or some such place, not under > /usr/bin/. That is a good idea, but how do we get Apple to do it? > That would leave /usr/bin free for the MacPython gang to > install its version, or at least a symlink to /usr/local/bin/pythonw. Except that, ideally, third parties should NEVER put ANYTHING in /usr/bin. However, if we put out stuff in /usr/local/bin (or /opt/whatever), and there was no "python" on the standard path, we'd have less confusion. Way back when Redhat used python1.5 with a bunch of added extensions for its admen tools. All their tools had "usr/local/bin/env python" in the #! line. This was a pain in the *&$^&%* when you wanted to upgrade your standard python, just like it's a pin now with Apple. However, all they needed to do was put a darn version on the #! line: /usr/bin/env python1.5 Apple could do the same thing, then all their admin tools would be insulated from adding additional, newer pythons anywhere on the PATH. I can't do anything about what Apple does, but I always put a version number in all my #! lines. This makes sure it uses the python version I want it used with, regardless of environment It also makes it clear to me, and anyone else that may read that script, what version is was developed against. Yes, when I get rid of that version of python, I need to go change a bunch of #! lines, but I like that too, because it assures that I am aware of what I've changed, and I can test against the new version of python when I do it. I like to see this as a universal practice in the Python world -Chris NOTE: Even better would be a way to specify multiple versions in order of preference, and a python launcher that would sort that out for you. This would be particularly nice on Windows, where you can only associate *.py with one thing. Maybe some day I'll want that enough to write it! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Mon Feb 13 18:07:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 09:07:34 -0800 Subject: [Pythonmac-SIG] Readline In-Reply-To: References: <43CD2F98.5050303@noaa.gov> Message-ID: <70C013EF-DE65-4E58-BB72-EEDF3BDE64B6@redivi.com> Standard readline keys mostly.. this should be all you need: http://cnswww.cns.cwru.edu/~chet/readline/rluserman.html http://docs.python.org/dev/tut/node15.html -bob On Feb 13, 2006, at 6:10 AM, Ken Brooks wrote: > Finally choosing to find the time, I installed MacPython 2.4.1. > But now I need documentation, and Google was not helpful. What > keystrokes have new meanings in the MacPython interactive window as > a result of having readline? > > Ken > > At 9:55 AM -0800 1/17/06, Christopher Barker wrote: >> Ken Brooks wrote: >>> Still nothing changes! So how does the debug loop work? How can I >>> reload a module short of relaunching the environment?? >> ^^^^^^ >> >> You've just inadvertently answered your own question. That's what >> we mean when we say "Python fits your brain": >> >>>>> reload(foo) >> >> Python caches modules so that if one module is imported in ten >> different places, it doesn't reload them each time. To force a >> reload you use, appropriately enough, the reload function. >> >>> 2. I really wish for the "doskey" feature that lets you easily >>> retrieve and edit a line previously typed to the interactive >>> interpreter. Does it exist here? >> >> Yup. It's called readline. Apple doesn't ship it with OS-X, >> because it's licensed under the GPL, but you can install in >> separately, or you can install a new version of python that has it. >> >> See: >> http://undefined.org/python/ >> >> for a newer Python, and: >> >> http://www.pythonmac.org/packages/ >> >> For an assortment of add-on packages >> >> There is a readline for th python 2.3 that came with OS-X 10.4 >> there. It may work with 10.4 also, if you install >> "TigerPython23Compat" from that page also. >> >> All that being said, you might want to try one of the fancier >> python shells for interactive use, like ipython. Or, just write >> your entire script in a file (or multiple files) and restart >> python each time. It's rare that something take that long to run >> that re-starting is a problem. You can start it with: >> >> $ python -i MyScript.py >> >> and you'll get the interpreter prompt when it's done running. >> >> -Chris >> >> >> - >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> NOAA/OR&R/HAZMAT (206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> Chris.Barker at noaa.gov > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Mon Feb 13 18:18:53 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 13 Feb 2006 09:18:53 -0800 Subject: [Pythonmac-SIG] Debugger In-Reply-To: <84035E2C-6F8C-4BB9-8BBD-14EAAFCD5D67@redivi.com> References: <84035E2C-6F8C-4BB9-8BBD-14EAAFCD5D67@redivi.com> Message-ID: <43F0BF7D.40409@noaa.gov> Bob Ippolito wrote: > I believe there's a debugger in IDLE, and the one in Wing IDE is > pretty good (but that's a commercial X11 app). Normally I just use > pdb, which is strictly console based. If you have wxPython, there is also WinPdb: SPE comes bundled with it, and it can be used on its own. Does PyOxide have a debugger? You'd also be amazed at how far you can get with the command line and a bunch of sprinkled print statements. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Mon Feb 13 19:11:25 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 13 Feb 2006 19:11:25 +0100 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: References: Message-ID: On 13-feb-2006, at 1:37, Bob Ippolito wrote: > On Feb 12, 2006, at 1:19 PM, Ronald Oussoren wrote: > >> The attached patch replaces the script in Mac/OSX/Dist by a python >> script that builds a "batteries included" universal binary. The >> attached background.jpg should be placed in Mac/OSX/Dist/resources >> (and hopefully someone donates a nicer image). >> >> Due to lack of time I haven't tested the installer and contained >> binaries yet. >> >> Things that should be fixed: >> 1. 'make frameworkinstall' will no longer install files in /usr/ >> local/bin. >> 2. the postflight script should be rewritten, it creates a >> shellscript version of pythonw >> 3. the package is a ".pkg" instead of an ".mpkg". This should make >> it possible to create an installer that is truely "batteries >> included" in the future. > > .mpkg can depend on other .mpkg... that's not really worth > mentioning. You need a .pkg file *somewhere* because .mpkg can > only reference .pkg or .mpkg. If we do the work for an .mpkg now it will be easier to create a truly fat distribution later on. Given the amount of time we seem to have available to work on this I'd rather do the work now that we're interested in working on this. > >> 4. the package doesn't update user profiles (should be an >> optional .pkg in the .mpkg). > > In order to make it optional, the outer shell needs to be a .mpkg > and it needs to reference an optional .pkg that does this in > postflight. Either that or the package should launch a GUI that asks if it should update your profile. I'd prefer the mpkg solution, although a GUI also has advantages: what if the package is installed by an admin user, but used by some other user (say a teacher that installs packages and students that use them). We could also patch /etc/ profile, but I'd prefer not to do that. > >> 5. there's still 'python' and 'pythonw' that behave differently, >> python should be replaced by pythonw and pythonw should be a >> symlink to python for backward compatibility. >> 6. A patch for distutils that allows compiling on 10.3.9 >> 7. A patch for distutils that recognizes '-arch' and '-isysroot' >> in extra_compile_args and extra_link_args and removes those flags >> from CFLAGS/LDFLAGS > > Aren't 5. and 6. the same thing? Do you mean 6 and 7? Those patches will touch the same part of the tree and will likely be one patch. > >> 8. The Python documentation is no longer installed as a help book. > > I wonder how hard this is to add to IDLE, or if we can just link to > HTML docs. I'm not personally a big fan of Help Book anyway. I just read the source for pydoc, we could install the HTML docs in Python.framework/Resources/English.lproj/Documentation. Idlelib would need a patch to support this location. There's already specific configuration for windows and linux in there (in idlelib.EditorWindow) I just remembered something else that needs to be done some time: create better icons, it's time to leave the 10 ton weight behind (or at the very least the current rendition of it). I won't do this though, given my skills in that deparment the icons would get worse instead of better. Ronald > > -bob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060213/ff4bbd8d/attachment-0001.bin From bob at redivi.com Mon Feb 13 19:17:55 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 10:17:55 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: References: Message-ID: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: > > On 13-feb-2006, at 1:37, Bob Ippolito wrote: > >> wonder how hard this is to add to IDLE, or if we can just link to >> HTML docs. I'm not personally a big fan of Help Book anyway. > > I just read the source for pydoc, we could install the HTML docs in > Python.framework/Resources/English.lproj/Documentation. Idlelib > would need a patch to support this location. There's already > specific configuration for windows and linux in there (in > idlelib.EditorWindow) That sounds fine, we're going to be making a couple IDLE hacks anyway. > I just remembered something else that needs to be done some time: > create better icons, it's time to leave the 10 ton weight behind > (or at the very least the current rendition of it). I won't do this > though, given my skills in that deparment the icons would get worse > instead of better. That's a good idea, but last I tried to get one of my friends to do something about that it turned out to be "too realistic". I'm not going to bother wasting anyone else's time. BTW, I've moved the repository to: http://svn.pythonmac.org/python24/python24-fat/ I also set up a little trac instance: http://trac.pythonmac.org/python24 -bob From ronaldoussoren at mac.com Mon Feb 13 19:28:18 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 13 Feb 2006 19:28:18 +0100 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> Message-ID: <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> On 13-feb-2006, at 19:17, Bob Ippolito wrote: > > On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: > >> >> On 13-feb-2006, at 1:37, Bob Ippolito wrote: >> >>> wonder how hard this is to add to IDLE, or if we can just link to >>> HTML docs. I'm not personally a big fan of Help Book anyway. >> >> I just read the source for pydoc, we could install the HTML docs >> in Python.framework/Resources/English.lproj/Documentation. Idlelib >> would need a patch to support this location. There's already >> specific configuration for windows and linux in there (in >> idlelib.EditorWindow) > > That sounds fine, we're going to be making a couple IDLE hacks anyway. Are we? We have a lot of patches anyway, adding another patch to teach idlelib about the document locations that pydoc recognizes won't be the most controversial one in our set of patches. > >> I just remembered something else that needs to be done some time: >> create better icons, it's time to leave the 10 ton weight behind >> (or at the very least the current rendition of it). I won't do >> this though, given my skills in that deparment the icons would get >> worse instead of better. > > That's a good idea, but last I tried to get one of my friends to do > something about that it turned out to be "too realistic". I'm not > going to bother wasting anyone else's time. I remember that. Is that icon still available? That icon was a lot better than what we have now, if anyone complains about the realism they can come up with another icon :-). > > BTW, I've moved the repository to: > http://svn.pythonmac.org/python24/python24-fat/ Would you mind giving me check-in privileges? > > I also set up a little trac instance: > http://trac.pythonmac.org/python24 Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060213/7fc5c384/attachment.bin From bob at redivi.com Mon Feb 13 19:46:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 10:46:00 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> Message-ID: <7288F292-9C9E-4814-8C1D-AF8915F148F2@redivi.com> On Feb 13, 2006, at 10:28 AM, Ronald Oussoren wrote: > > On 13-feb-2006, at 19:17, Bob Ippolito wrote: > >> >> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: >> >>> >>> On 13-feb-2006, at 1:37, Bob Ippolito wrote: >>> >>>> wonder how hard this is to add to IDLE, or if we can just link >>>> to HTML docs. I'm not personally a big fan of Help Book anyway. >>> >>> I just read the source for pydoc, we could install the HTML docs >>> in Python.framework/Resources/English.lproj/Documentation. >>> Idlelib would need a patch to support this location. There's >>> already specific configuration for windows and linux in there (in >>> idlelib.EditorWindow) >> >> That sounds fine, we're going to be making a couple IDLE hacks >> anyway. > > Are we? We have a lot of patches anyway, adding another patch to > teach idlelib about the document locations that pydoc recognizes > won't be the most controversial one in our set of patches. We need to at least change the default key bindings to Mac OS rather than Windows... we also want to make sure that it starts a pythonw- capable interpreter among other little details. >>> I just remembered something else that needs to be done some time: >>> create better icons, it's time to leave the 10 ton weight behind >>> (or at the very least the current rendition of it). I won't do >>> this though, given my skills in that deparment the icons would >>> get worse instead of better. >> >> That's a good idea, but last I tried to get one of my friends to >> do something about that it turned out to be "too realistic". I'm >> not going to bother wasting anyone else's time. > > I remember that. Is that icon still available? That icon was a lot > better than what we have now, if anyone complains about the realism > they can come up with another icon :-). I think I've still got a copy somewhere, but it would take a bit to find the originals because all of my working macs have been to applecare since then so it's living somewhere on an external drive... >> BTW, I've moved the repository to: >> http://svn.pythonmac.org/python24/python24-fat/ > > Would you mind giving me check-in privileges? Sure, send me htpasswd -n output for email : password and I'll stick it in there. -bob From Chris.Barker at noaa.gov Mon Feb 13 19:46:12 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 13 Feb 2006 10:46:12 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> Message-ID: <43F0D3F4.3070400@noaa.gov> Ronald Oussoren wrote: > I remember that. Is that icon still available? Isn't it used in the Wiki? (the wiki seems to be down at the moment) > That icon was a lot > better than what we have now, if anyone complains about the realism > they can come up with another icon :-). And I second that: I love it! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Mon Feb 13 19:59:47 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 10:59:47 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <43F0D3F4.3070400@noaa.gov> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43F0D3F4.3070400@noaa.gov> Message-ID: <9BCF3FB7-EB06-4059-ADB7-10889DFDF75B@redivi.com> On Feb 13, 2006, at 10:46 AM, Christopher Barker wrote: > Ronald Oussoren wrote: >> I remember that. Is that icon still available? > > Isn't it used in the Wiki? (the wiki seems to be down at the moment) Should work now. -bob From njriley at uiuc.edu Mon Feb 13 20:13:04 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 13 Feb 2006 13:13:04 -0600 Subject: [Pythonmac-SIG] My stab at a new page In-Reply-To: <43F0BC7E.40104@noaa.gov> References: <06Feb12.102859pst.58633@synergy1.parc.xerox.com> <43F0BC7E.40104@noaa.gov> Message-ID: <20060213191304.GA61220@uiuc.edu> On Mon, Feb 13, 2006 at 09:06:06AM -0800, Christopher Barker wrote: > Bill Janssen wrote: > > You missed the first part of my message, I think. The system version > > would be installed under /usr/libexec/, or some such place, not under > > /usr/bin/. > > That is a good idea, but how do we get Apple to do it? So the end result is that the system Python (and Perl, Tcl, Ruby, ...) isn't visible? Yuck - as started earlier in this thread, there are plenty of people for whom the system Python 2.3.x is plenty usable. Not everyone creates bundled applications for redistribution, or needs Python 2.4. > Way back when Redhat used python1.5 with a bunch of added extensions for > its admen tools. All their tools had "usr/local/bin/env python" in the > #! line. This was a pain in the *&$^&%* when you wanted to upgrade your > standard python, just like it's a pin now with Apple. > > However, all they needed to do was put a darn version on the #! line: > > /usr/bin/env python1.5 > > Apple could do the same thing, then all their admin tools would be > insulated from adding additional, newer pythons anywhere on the PATH. What Apple does now, i.e. #!/usr/bin/python (see the contents of /usr/libexec/fax, for example), is better - what if you had a replacement Python 2.3 which didn't have Apple's CoreGraphics bindings in it, for example? It's not always going to be the case that Apple provides a Python version one major version behind the current one. Also, a lot of Apple's tools run from within a GUI context where the path is set by the loginwindow environment (~/.MacOSX/environment.plist), not by your shell initialization files, which makes absolute paths more attractive. They could use #!/usr/bin/python2.3, I guess... > NOTE: Even better would be a way to specify multiple versions in > order of preference, and a python launcher that would sort that out > for you. This would be particularly nice on Windows, where you can > only associate *.py with one thing. Maybe some day I'll want that > enough to write it! Apple does something similar with its Java launching mechanism; you can specify "exactly this JVM version" or "this major version" or "at least this version" and so forth in the Info.plist file. It'd be nice if Apple provided a standard way to handle versioning for any system-provided interpreter, though whatever they did would only be likely to apply to bundled applications, not command-line stuff. -- Nicholas Riley | From kevino at theolliviers.com Mon Feb 13 20:14:53 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Mon, 13 Feb 2006 11:14:53 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> Message-ID: <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> Hi Ronald, On Feb 13, 2006, at 10:28 AM, Ronald Oussoren wrote: > > On 13-feb-2006, at 19:17, Bob Ippolito wrote: > >> >> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: >> >>> >>> On 13-feb-2006, at 1:37, Bob Ippolito wrote: >>> >>>> wonder how hard this is to add to IDLE, or if we can just link >>>> to HTML docs. I'm not personally a big fan of Help Book anyway. >>> >>> I just read the source for pydoc, we could install the HTML docs >>> in Python.framework/Resources/English.lproj/Documentation. >>> Idlelib would need a patch to support this location. There's >>> already specific configuration for windows and linux in there (in >>> idlelib.EditorWindow) >> >> That sounds fine, we're going to be making a couple IDLE hacks >> anyway. > > Are we? We have a lot of patches anyway, adding another patch to > teach idlelib about the document locations that pydoc recognizes > won't be the most controversial one in our set of patches. > >> >>> I just remembered something else that needs to be done some time: >>> create better icons, it's time to leave the 10 ton weight behind >>> (or at the very least the current rendition of it). I won't do >>> this though, given my skills in that deparment the icons would >>> get worse instead of better. >> >> That's a good idea, but last I tried to get one of my friends to >> do something about that it turned out to be "too realistic". I'm >> not going to bother wasting anyone else's time. > > I remember that. Is that icon still available? That icon was a lot > better than what we have now, if anyone complains about the realism > they can come up with another icon :-). There are other potential designs for icons; for example, have you seen the snake icon for the wxPython demo (once it's loaded, it changes from the weight icon to the snake)? (Sorry, yes, I know who I'm asking. ;-) I also pointed out some other alternatives on some thread on this list in Nov. 2003, thread "MacPython logo redux". But then others complained, surprise, that it's too cartoony. :-) The problem is not that there's no other icons, it's just that we're not going to make everyone happy. The Apple/snake icon, from an image perspective (and that's all it is...), has several problems with it. First, real snakes are scary and some people don't like looking at scary things. I had to put stickers over the cover of my O'Reilly Python library reference book because the snake on there creeps my wife out. I think I'll have a harder time now getting her to use Python... I won't even get into the biblical connotations, etc. of a mean-looking snake wrapped around an apple, but I think being non-offensive is, probably, a good idea if we're still talking about making Python appeal to others. As has been stated before in this discussion, we probably won't offend "too many people" with these things, but why do we have to offend anyone at all? A non-offensive 12-ton weight is at least better than a somewhat offensive snake. A more cartoonish/abstract design like the wxPython one won't spook anyone or have scary connotations, and while some people may not like it, it's closer to the Windows Python icon and heck, icons like Adium's are actually some of my favorites. There's also the issue that at small sizes, the snake becomes unrecognizable anyways making the icon look like an Apple with a yellow something at the bottom. But of course, this was all dregged up and discussed before. I really wish Python itself would get a standard icon across platforms, but that's another story. (The web site redesign seems totally stalled....) I'll get back to your other emails later, but really first I need to update the FAQ, and I intended to do it this weekend but got caught up in some expected, and some unexpected, business. ;-) Thanks, Kevin >> >> BTW, I've moved the repository to: >> http://svn.pythonmac.org/python24/python24-fat/ > > Would you mind giving me check-in privileges? > >> >> I also set up a little trac instance: >> http://trac.pythonmac.org/python24 > > Ronald_______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From janssen at parc.com Mon Feb 13 20:25:25 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 13 Feb 2006 11:25:25 PST Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: Your message of "Mon, 13 Feb 2006 10:46:00 PST." <7288F292-9C9E-4814-8C1D-AF8915F148F2@redivi.com> Message-ID: <06Feb13.112531pst."58633"@synergy1.parc.xerox.com> > We need to at least change the [IDLE] default key bindings to Mac OS > rather than Windows... we also want to make sure that it starts a > pythonw-capable interpreter among other little details. There's a list at http://rlai.cs.ualberta.ca/RLAI/RLsoftware/PythonLinks.html#IDLE. Bill From bob at redivi.com Mon Feb 13 20:43:57 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 11:43:57 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> Message-ID: <31CBFB68-4B1F-49AC-8B4F-B20093182A8B@redivi.com> On Feb 13, 2006, at 11:14 AM, Kevin Ollivier wrote: > Hi Ronald, > > On Feb 13, 2006, at 10:28 AM, Ronald Oussoren wrote: > >> >> On 13-feb-2006, at 19:17, Bob Ippolito wrote: >> >>> >>> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: >>> >>>> >>>> On 13-feb-2006, at 1:37, Bob Ippolito wrote: >>>> >>>>> wonder how hard this is to add to IDLE, or if we can just link >>>>> to HTML docs. I'm not personally a big fan of Help Book anyway. >>>> >>>> I just read the source for pydoc, we could install the HTML docs >>>> in Python.framework/Resources/English.lproj/Documentation. >>>> Idlelib would need a patch to support this location. There's >>>> already specific configuration for windows and linux in there >>>> (in idlelib.EditorWindow) >>> >>> That sounds fine, we're going to be making a couple IDLE hacks >>> anyway. >> >> Are we? We have a lot of patches anyway, adding another patch to >> teach idlelib about the document locations that pydoc recognizes >> won't be the most controversial one in our set of patches. >> >>> >>>> I just remembered something else that needs to be done some >>>> time: create better icons, it's time to leave the 10 ton weight >>>> behind (or at the very least the current rendition of it). I >>>> won't do this though, given my skills in that deparment the >>>> icons would get worse instead of better. >>> >>> That's a good idea, but last I tried to get one of my friends to >>> do something about that it turned out to be "too realistic". I'm >>> not going to bother wasting anyone else's time. >> >> I remember that. Is that icon still available? That icon was a lot >> better than what we have now, if anyone complains about the >> realism they can come up with another icon :-). > > There are other potential designs for icons; for example, have you > seen the snake icon for the wxPython demo (once it's loaded, it > changes from the weight icon to the snake)? (Sorry, yes, I know who > I'm asking. ;-) I also pointed out some other alternatives on some > thread on this list in Nov. 2003, thread "MacPython logo redux". > But then others complained, surprise, that it's too cartoony. :-) > The problem is not that there's no other icons, it's just that > we're not going to make everyone happy. I'm not trying to start this thread again. We'll stick with the 12 ton icon until someone volunteers an icon that nobody is afraid of and is less ugly. Please, everyone, do not continue this conversation until you have a serious candidate icon for replacing the 12 ton weight. We don't need ideas or opinions, we need pixels. -bob From vinogri at mcmaster.ca Mon Feb 13 21:56:32 2006 From: vinogri at mcmaster.ca (I. Vinogradov) Date: Mon, 13 Feb 2006 15:56:32 -0500 Subject: [Pythonmac-SIG] idle icon. In-Reply-To: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> Message-ID: here's a crude draft of a concept, especially for those disliking snakes: http://univmail.cis.mcmaster.ca/~vinogri/mp/logopage.html From ronaldoussoren at mac.com Mon Feb 13 22:28:00 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 13 Feb 2006 22:28:00 +0100 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> Message-ID: <65197831-6BDA-47E8-BC84-1767298C12AB@mac.com> On 13-feb-2006, at 20:14, Kevin Ollivier wrote: > Hi Ronald, > > On Feb 13, 2006, at 10:28 AM, Ronald Oussoren wrote: > >> >> On 13-feb-2006, at 19:17, Bob Ippolito wrote: >> >>> >>> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: >>> >>>> >>>> On 13-feb-2006, at 1:37, Bob Ippolito wrote: >>>> >>>>> wonder how hard this is to add to IDLE, or if we can just link >>>>> to HTML docs. I'm not personally a big fan of Help Book anyway. >>>> >>>> I just read the source for pydoc, we could install the HTML docs >>>> in Python.framework/Resources/English.lproj/Documentation. >>>> Idlelib would need a patch to support this location. There's >>>> already specific configuration for windows and linux in there >>>> (in idlelib.EditorWindow) >>> >>> That sounds fine, we're going to be making a couple IDLE hacks >>> anyway. >> >> Are we? We have a lot of patches anyway, adding another patch to >> teach idlelib about the document locations that pydoc recognizes >> won't be the most controversial one in our set of patches. >> >>> >>>> I just remembered something else that needs to be done some >>>> time: create better icons, it's time to leave the 10 ton weight >>>> behind (or at the very least the current rendition of it). I >>>> won't do this though, given my skills in that deparment the >>>> icons would get worse instead of better. >>> >>> That's a good idea, but last I tried to get one of my friends to >>> do something about that it turned out to be "too realistic". I'm >>> not going to bother wasting anyone else's time. >> >> I remember that. Is that icon still available? That icon was a lot >> better than what we have now, if anyone complains about the >> realism they can come up with another icon :-). > > There are other potential designs for icons; for example, have you > seen the snake icon for the wxPython demo (once it's loaded, it > changes from the weight icon to the snake)? (Sorry, yes, I know who > I'm asking. ;-) I also pointed out some other alternatives on some > thread on this list in Nov. 2003, thread "MacPython logo redux". > But then others complained, surprise, that it's too cartoony. :-) > The problem is not that there's no other icons, it's just that > we're not going to make everyone happy. I haven't seen the icon, is it online somewhere? BTW. I do use wxPython at work, it is the easiest way to develop windows GUI's without leaving the comforts of my mac. > > The Apple/snake icon, from an image perspective (and that's all it > is...), has several problems with it. First, real snakes are scary > and some people don't like looking at scary things. I had to put > stickers over the cover of my O'Reilly Python library reference > book because the snake on there creeps my wife out. I think I'll > have a harder time now getting her to use Python... I won't even > get into the biblical connotations, etc. of a mean-looking snake > wrapped around an apple, but I think being non-offensive is, > probably, a good idea if we're still talking about making Python > appeal to others. As has been stated before in this discussion, we > probably won't offend "too many people" with these things, but why > do we have to offend anyone at all? A non-offensive 12-ton weight > is at least better than a somewhat offensive snake. > > A more cartoonish/abstract design like the wxPython one won't spook > anyone or have scary connotations, and while some people may not > like it, it's closer to the Windows Python icon and heck, icons > like Adium's are actually some of my favorites. There's also the > issue that at small sizes, the snake becomes unrecognizable anyways > making the icon look like an Apple with a yellow something at the > bottom. But of course, this was all dregged up and discussed before. > > I really wish Python itself would get a standard icon across > platforms, but that's another story. (The web site redesign seems > totally stalled....) A standard icon would be nice, but we really have to update the 10- ton icon its age is too obviously an OS9 icon. I know the snake is offensive/scary to some people, but I'm afraid that if we don't change now we'll never change. I don't mind having the snake icon on Bob's site in a first beta release of Universal Python if that stirs things up enough to get a less offensive icon in the final release. Bonus points for someone that is inspired by Monty Python. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060213/5d5f7864/attachment.bin From trentm at ActiveState.com Mon Feb 13 23:12:51 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 13 Feb 2006 14:12:51 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> Message-ID: <20060213221250.GB21702@activestate.com> > On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: > > > I just remembered something else that needs to be done some time: > > create better icons, it's time to leave the 10 ton weight behind > > (or at the very least the current rendition of it). I won't do this > > though, given my skills in that deparment the icons would get worse > > instead of better. Someone might want to politely approach Jasper Hauser: http://www.jasperhauser.nl/icon/ ... Under certain circumstances I'm willing to work (partially) for free on products if they are and stay freeware or opensource software. I have done so for both Camino and Adium, please email or message me and perhaps we will talk it over. ... He is even Dutch (or at least lives in the Netherlands)! :) Trent -- Trent Mick TrentM at ActiveState.com From bob at redivi.com Mon Feb 13 23:37:19 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 14:37:19 -0800 Subject: [Pythonmac-SIG] MacPython Icon In-Reply-To: <20060213221250.GB21702@activestate.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <20060213221250.GB21702@activestate.com> Message-ID: <79418784-6A74-48AF-9BE8-C90ECFA826DB@redivi.com> On Feb 13, 2006, at 2:12 PM, Trent Mick wrote: >> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: >> >>> I just remembered something else that needs to be done some time: >>> create better icons, it's time to leave the 10 ton weight behind >>> (or at the very least the current rendition of it). I won't do this >>> though, given my skills in that deparment the icons would get worse >>> instead of better. > > Someone might want to politely approach Jasper Hauser: > > http://www.jasperhauser.nl/icon/ > ... > Under certain circumstances I'm willing to work (partially) for > free > on products if they are and stay freeware or opensource > software. I > have done so for both Camino and Adium, please email or message me > and perhaps we will talk it over. > ... > > He is even Dutch (or at least lives in the Netherlands)! :) If someone does approach him or another person to do some design work, we should probably specify that we want something: 1. Monty Python related (to avoid the annoying offensive imagery arguments) 2. Doesn't even come close to infringing any trademarks (no apple, etc.) The problem with these constraints is that it's REALLY hard to come up with something that's recognizable. At least with the ugly 16 ton weight icon suite we have something people are probably used to :) -bob From kquirk at solidworks.com Tue Feb 14 00:03:18 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Mon, 13 Feb 2006 18:03:18 -0500 Subject: [Pythonmac-SIG] MacPython Icon Message-ID: I've just been talking with our group's artist about it. He's very talented. We've got a few good ideas -- he's going to noodle around tonight and I'll probably be able to post a couple of images tomorrow. Kent -----Original Message----- From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig-bounces at python.org] On Behalf Of Bob Ippolito Sent: Monday, February 13, 2006 5:37 PM To: Trent Mick Cc: PythonMac Subject: [Pythonmac-SIG] MacPython Icon On Feb 13, 2006, at 2:12 PM, Trent Mick wrote: >> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: >> >>> I just remembered something else that needs to be done some time: >>> create better icons, it's time to leave the 10 ton weight behind >>> (or at the very least the current rendition of it). I won't do this >>> though, given my skills in that deparment the icons would get worse >>> instead of better. > > Someone might want to politely approach Jasper Hauser: > > http://www.jasperhauser.nl/icon/ > ... > Under certain circumstances I'm willing to work (partially) for > free > on products if they are and stay freeware or opensource > software. I > have done so for both Camino and Adium, please email or message me > and perhaps we will talk it over. > ... > > He is even Dutch (or at least lives in the Netherlands)! :) If someone does approach him or another person to do some design work, we should probably specify that we want something: 1. Monty Python related (to avoid the annoying offensive imagery arguments) 2. Doesn't even come close to infringing any trademarks (no apple, etc.) The problem with these constraints is that it's REALLY hard to come up with something that's recognizable. At least with the ugly 16 ton weight icon suite we have something people are probably used to :) -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From janssen at parc.com Tue Feb 14 00:33:53 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 13 Feb 2006 15:33:53 PST Subject: [Pythonmac-SIG] final? try at new MacPython download page Message-ID: <06Feb13.153401pst."58633"@synergy1.parc.xerox.com> I've updated my strawman page at http://bill.janssen.org/mac/new-macpython-page.html. This is intended to replace the page currently at http://www.python.org/download/download_mac.html. I think this is about as good as we're going to get, for the moment. It points out to experienced Mac developers that you can call the various Cocoa libraries, manipulate Apple Events, and package up Mac apps with Python. It explains what installers to install, and in which order (we'll have to change it when the universal build comes out -- I'll volunteer to do that). For the merely curious, it shows how to start a Terminal window and run a python interpreter. It points out IDLE and the IDLE.app application. I don't feel the need to do too much for the Python newbie on this page. They are, after all, on the python.org site, and there are plenty of links for Python newbies on that site. I don't think the Mac brings anything particularly special to that. If no one objects too much, I'll figure out how to get it uploaded to the python.org site. Bill From daniel at brightfire.com Tue Feb 14 01:52:03 2006 From: daniel at brightfire.com (Daniel Lord) Date: Mon, 13 Feb 2006 16:52:03 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 69 In-Reply-To: References: Message-ID: <51077D4E-6051-4F32-BB44-23F00051E4BA@brightfire.com> On Feb 13, 2006, at 3:03 PM, pythonmac-sig-request at python.org wrote: > 1. Monty Python related (to avoid the annoying offensive imagery > arguments) Monty Python is copyrighted work. I would advise keeping a careful distance from anything commercially recognizable unless you put aside a significant settlement fund and lawyers fees for the settlement negotiation. But then you could gamble that Michael Palin et al are fans of open source software, want to contribute to the cause, and will let you use it gratis. Frankly, the language is named after a snake, a pretty noble beast actually, and I am not sure how Nature offends in this case. I think FORTRAN, PERL, C, Java, and C# are banal and unimaginitive in fact. Not that i think animals are good language names, but then what is? But the essence of naming is representation and memorability. I think Python is better than many in those respects. I suggest the collective community has 'bigger fish to fry' but since your are volunteers that is a suggestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060213/c14f7b54/attachment.html From charles.hartman at conncoll.edu Tue Feb 14 01:55:27 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 13 Feb 2006 19:55:27 -0500 Subject: [Pythonmac-SIG] final? try at new MacPython download page In-Reply-To: <06Feb13.153401pst."58633"@synergy1.parc.xerox.com> References: <06Feb13.153401pst."58633"@synergy1.parc.xerox.com> Message-ID: I think this looks good and smooth. Thanks for doing this work. The two big topics -- topics that loomed large for me when I started trying to figure out whether I wanted to use Python on the Mac -- aren't really addressed yet: alternative IDEs (Wing, SPE, PyOXIDE if it were working, etc) and GUI libraries (especially wxPython). The IDEs are important because IDLE doesn't exactly make Python competitive. The libraries are important for anyone who wants to make cross-platform GUI apps, and I think that may be a large proportion of potential users. If these doesn't go on the first page -- I guess the consensus may be against this -- then shouldn't they go in the FAQ? I see wxPython mentioned there, very much in passing, and with a virtual deprecation in the same sentence, and nothing about IDEs, unless my eyes just stumbled past it. The Vaults of Parnassus site http://www.vex.net/parnassus/ is kind of a grab-bag, but shouldn't we include a pointer to it or (better) foreground some of what it offers? Charles Hartman On Feb 13, 2006, at 6:33 PM, Bill Janssen wrote: > I've updated my strawman page at > http://bill.janssen.org/mac/new-macpython-page.html. > > This is intended to replace the page currently at > http://www.python.org/download/download_mac.html. > > I think this is about as good as we're going to get, for the moment. > It points out to experienced Mac developers that you can call the > various Cocoa libraries, manipulate Apple Events, and package up Mac > apps with Python. It explains what installers to install, and in > which order (we'll have to change it when the universal build comes > out -- I'll volunteer to do that). For the merely curious, it shows > how to start a Terminal window and run a python interpreter. It > points out IDLE and the IDLE.app application. > > I don't feel the need to do too much for the Python newbie on this > page. They are, after all, on the python.org site, and there are > plenty of links for Python newbies on that site. I don't think the > Mac brings anything particularly special to that. > > If no one objects too much, I'll figure out how to get it uploaded to > the python.org site. > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From janssen at parc.com Tue Feb 14 02:03:42 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 13 Feb 2006 17:03:42 PST Subject: [Pythonmac-SIG] final? try at new MacPython download page In-Reply-To: Your message of "Mon, 13 Feb 2006 16:55:27 PST." Message-ID: <06Feb13.170346pst."58633"@synergy1.parc.xerox.com> > If these doesn't go on the first page -- I guess the consensus may be > against this -- then shouldn't they go in the FAQ? I see wxPython > mentioned there, very much in passing, and with a virtual deprecation > in the same sentence, and nothing about IDEs, unless my eyes just > stumbled past it. Charles, Yes, I do think they should go in the FAQ. How about adding a page to the Wiki with your ideas about IDEs, and another about GUIs for MacPython? Seems to me there have been some appropriate postings about this recently, and perhaps the authors would contribute their text. Then add pointers to the FAQ Wiki page to point to these new pages. Bill From ed at leafe.com Tue Feb 14 02:10:33 2006 From: ed at leafe.com (Ed Leafe) Date: Mon, 13 Feb 2006 20:10:33 -0500 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 69 In-Reply-To: <51077D4E-6051-4F32-BB44-23F00051E4BA@brightfire.com> References: <51077D4E-6051-4F32-BB44-23F00051E4BA@brightfire.com> Message-ID: <3D496250-5C09-4931-9534-1D95CA4A9D16@leafe.com> On Feb 13, 2006, at 7:52 PM, Daniel Lord wrote: > Frankly, the language is named after a snake Nope. See the second paragraph of Guido's forward to "Programming Python": http://www.python.org/doc/essays/foreword.html -- Ed Leafe -- http://leafe.com -- http://dabodev.com From bob at redivi.com Tue Feb 14 02:13:41 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 17:13:41 -0800 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 34, Issue 69 In-Reply-To: <51077D4E-6051-4F32-BB44-23F00051E4BA@brightfire.com> References: <51077D4E-6051-4F32-BB44-23F00051E4BA@brightfire.com> Message-ID: On Feb 13, 2006, at 4:52 PM, Daniel Lord wrote: > > On Feb 13, 2006, at 3:03 PM, pythonmac-sig-request at python.org wrote: > >> 1. Monty Python related (to avoid the annoying offensive imagery >> arguments) > > Monty Python is copyrighted work. I would advise keeping a careful > distance from anything commercially recognizable unless you put > aside a significant settlement fund and lawyers fees for the > settlement negotiation. But then you could gamble that Michael > Palin et al are fans of open source software, want to contribute to > the cause, and will let you use it gratis. Frankly, the language > is named after a snake, a pretty noble beast actually, and I am not > sure how Nature offends in this case. I think FORTRAN, PERL, C, > Java, and C# are banal and unimaginitive in fact. Not that i think > animals are good language names, but then what is? But the essence > of naming is representation and memorability. I think Python is > better than many in those respects. I suggest the collective > community has 'bigger fish to fry' but since your are volunteers > that is a suggestion. Generic Monty Python references, such as the current 16-ton weight, don't tread anywhere near any copyrights or trademarks that I'm aware of. Python is not named after the snake, that's just coincidence. Snakes, especially in combination with apples, can cause irrational reactions (plenty of that in the archives last time this topic came up). However, that seems to be a very small, but vocal, minority. It may be best if we just choose to ignore their comments and go ahead with the obvious choice. The users we don't acquire due to the icon is probably very small in contrast with the users we'd gain given a good brand to recognize. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060213/f686e0fb/attachment.htm From bob at redivi.com Tue Feb 14 02:17:07 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 17:17:07 -0800 Subject: [Pythonmac-SIG] final? try at new MacPython download page In-Reply-To: References: <06Feb13.153401pst."58633"@synergy1.parc.xerox.com> Message-ID: <996F1A0F-BF69-4731-B345-75C05D4FBB08@redivi.com> On Feb 13, 2006, at 4:55 PM, Charles Hartman wrote: > I think this looks good and smooth. Thanks for doing this work. > > The two big topics -- topics that loomed large for me when I started > trying to figure out whether I wanted to use Python on the Mac -- > aren't really addressed yet: alternative IDEs (Wing, SPE, PyOXIDE if > it were working, etc) and GUI libraries (especially wxPython). > > The IDEs are important because IDLE doesn't exactly make Python > competitive. The libraries are important for anyone who wants to make > cross-platform GUI apps, and I think that may be a large proportion > of potential users. "IDLE doesn't exactly make Python competitive"... with what? What does Ruby, Perl, PHP, etc. have that beats IDLE? There's Eclipse for Java, but you can use that with Python also... Stuff like TextMate and Emacs also don't really exhibit any language preference. > If these doesn't go on the first page -- I guess the consensus may be > against this -- then shouldn't they go in the FAQ? I see wxPython > mentioned there, very much in passing, and with a virtual deprecation > in the same sentence, and nothing about IDEs, unless my eyes just > stumbled past it. The Vaults of Parnassus site > http://www.vex.net/parnassus/ > is kind of a grab-bag, but shouldn't we include a pointer to it or > (better) foreground some of what it offers? The vaults are probably dead, I'd just link to Cheese Shop. -bob From janssen at parc.com Tue Feb 14 02:45:48 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 13 Feb 2006 17:45:48 PST Subject: [Pythonmac-SIG] problems with 2.4.1 installer Message-ID: <06Feb13.174557pst."58633"@synergy1.parc.xerox.com> I just downloaded and ran the two recommended 10.4 Python installers. I noticed two things: 1. The readme for the 2.4.1 installer says it's for Mac OS X 10.3. It should say 10.3 and 10.4. 2. The IDLE app is bit hard to find, being in /Applications/MacPython-2.4/, along with a bunch of other (dead or dying?) apps, like PythonIDE and PackageManager. These problems should be addressed in the 2.4.2 release. Bill From janssen at parc.com Tue Feb 14 03:10:13 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 13 Feb 2006 18:10:13 PST Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: Your message of "Mon, 13 Feb 2006 17:45:48 PST." <06Feb13.174557pst."58633"@synergy1.parc.xerox.com> Message-ID: <06Feb13.181017pst."58633"@synergy1.parc.xerox.com> > 2. The IDLE app is bit hard to find, being in > /Applications/MacPython-2.4/, along with a bunch of other (dead or > dying?) apps, like PythonIDE and PackageManager. At the moment, I'd suggest changing the name of this folder to just "Python", and putting just "IDLE" and the "Tools" subfolder in it. Bill From bob at redivi.com Tue Feb 14 03:12:11 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 18:12:11 -0800 Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: <06Feb13.174557pst."58633"@synergy1.parc.xerox.com> References: <06Feb13.174557pst."58633"@synergy1.parc.xerox.com> Message-ID: <1C4C3A9E-EF29-40BA-9D65-5C9098052209@redivi.com> On Feb 13, 2006, at 5:45 PM, Bill Janssen wrote: > I just downloaded and ran the two recommended 10.4 Python installers. > I noticed two things: > > 1. The readme for the 2.4.1 installer says it's for Mac OS X 10.3. > It should say 10.3 and 10.4. It should, but it was built before 10.4 was released. Hence the need for the fix! > 2. The IDLE app is bit hard to find, being in > /Applications/MacPython-2.4/, along with a bunch of other (dead or > dying?) apps, like PythonIDE and PackageManager. This is intentional, that's not changing. -bob From bob at redivi.com Tue Feb 14 03:24:11 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 18:24:11 -0800 Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: <06Feb13.181017pst."58633"@synergy1.parc.xerox.com> References: <06Feb13.181017pst."58633"@synergy1.parc.xerox.com> Message-ID: <41A18EEC-6DE8-4BD5-882D-4F9E1A868EFB@redivi.com> On Feb 13, 2006, at 6:10 PM, Bill Janssen wrote: >> 2. The IDLE app is bit hard to find, being in >> /Applications/MacPython-2.4/, along with a bunch of other >> (dead or >> dying?) apps, like PythonIDE and PackageManager. > > At the moment, I'd suggest changing the name of this folder to just > "Python", and putting just "IDLE" and the "Tools" subfolder in it. We will be removing the irrelevant apps (PythonIDE, PackageManager). The version number is going to stay. I'm ambivalent as to whether it should be "Python" or "MacPython". "MacPython" has slight preference because that's how it's been for years. I see no reason to remove either BuildApplet or PythonLauncher for this release. The contents of /Applications/MacPython-2.4 with the current distribution are: BuildApplet, IDLE, PythonLauncher. It probably makes sense to add URL shortcuts to the docs and/or the website(s) though. -bob From kevino at theolliviers.com Tue Feb 14 03:27:44 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Mon, 13 Feb 2006 18:27:44 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <65197831-6BDA-47E8-BC84-1767298C12AB@mac.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> <65197831-6BDA-47E8-BC84-1767298C12AB@mac.com> Message-ID: <641BAA58-527E-44C9-AE05-40201633B011@theolliviers.com> Hi Ronald, On Feb 13, 2006, at 1:28 PM, Ronald Oussoren wrote: [snip] > I haven't seen the icon, is it online somewhere? BTW. I do use > wxPython at work, it is the easiest way to develop windows GUI's > without leaving the comforts of my mac. If you're running Tiger, go to /Developer/Examples/Python/wxPython/ demo/wxpdemo.ico. Run demo.py in that same folder to see the icon on the dock. It really doesn't look that bad, IMHO; it just lacks the realistic color shading OS X icons have. I'll try to track down who worked on it and see if they can or are willing to do an XP/OS X style update. > >> >> The Apple/snake icon, from an image perspective (and that's all it >> is...), has several problems with it. First, real snakes are scary >> and some people don't like looking at scary things. I had to put >> stickers over the cover of my O'Reilly Python library reference >> book because the snake on there creeps my wife out. I think I'll >> have a harder time now getting her to use Python... I won't even >> get into the biblical connotations, etc. of a mean-looking snake >> wrapped around an apple, but I think being non-offensive is, >> probably, a good idea if we're still talking about making Python >> appeal to others. As has been stated before in this discussion, we >> probably won't offend "too many people" with these things, but why >> do we have to offend anyone at all? A non-offensive 12-ton weight >> is at least better than a somewhat offensive snake. >> >> A more cartoonish/abstract design like the wxPython one won't >> spook anyone or have scary connotations, and while some people may >> not like it, it's closer to the Windows Python icon and heck, >> icons like Adium's are actually some of my favorites. There's also >> the issue that at small sizes, the snake becomes unrecognizable >> anyways making the icon look like an Apple with a yellow something >> at the bottom. But of course, this was all dregged up and >> discussed before. >> >> I really wish Python itself would get a standard icon across >> platforms, but that's another story. (The web site redesign seems >> totally stalled....) > > A standard icon would be nice, but we really have to update the 10- > ton icon its age is too obviously an OS9 icon. I know the snake is > offensive/scary to some people, but I'm afraid that if we don't > change now we'll never change. I don't mind having the snake icon > on Bob's site in a first beta release of Universal Python if that > stirs things up enough to get a less offensive icon in the final > release. Bonus points for someone that is inspired by Monty Python. I really don't think it will stir up anything; most people won't notice until it makes it's way into 10.5 or it is somehow made visible to the rest of the Python community. By the amount of people packaging for OS X, I really don't think the group of people closely following Python on OS X is very large at all, unfortunately. If we want to stir up things, I think we should look for and contact icon designers who will do free or discounted open source work. If we need to pay to get one, try contacting the main Python community and doing some fundraising. A single icon design usually isn't *that* expensive, and you can probably get something that really does adhere to Apple HIGs on icon design and that is at least acceptable to most people. Plus, we could then use it for XP, etc. as well. As for the design itself, I'd say go for a simple/abstract design, like the snake icon I pointed out. It's not all snakes that are "bad", just ones that look realistic and intimidating. Or, we could go with the Py letters, something like a Skype rounded bevel button with Py written inside it. It's simple, clean, and the Py obviously promotes the 'brand'. :-) We could also consider some sort of paper with Py written inside it to imply scripting, or perhaps use a gear shape instead of a plain round button style... In general, think simple, clean, abstract, nice colors. :-) I think that describes about every OS X icon I've seen. (some look 'realistic', but they are clearly not photo-realistic. They are semi-realistic but with more vibrant colors and appealing designs than reality would provide. ;-) And BTW, I was able to get a nice style free icon for my own wxPython app, EClass (see the icon at the top of http://eclass.net/), just by giving credit to the designer, so I think there are people out there interested in this sort of thing, especially for a high visibility project like Python. I totally agree with you about getting another icon, but if we're going to push on it now, IMHO let's try to do this right and make everyone at least grudgingly accepting of the icon. ;-) Thanks, Kevin > Ronald From janssen at parc.com Tue Feb 14 03:44:03 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 13 Feb 2006 18:44:03 PST Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: Your message of "Mon, 13 Feb 2006 18:24:11 PST." <41A18EEC-6DE8-4BD5-882D-4F9E1A868EFB@redivi.com> Message-ID: <06Feb13.184412pst."58633"@synergy1.parc.xerox.com> > > At the moment, I'd suggest changing the name of this folder to just > > "Python", and putting just "IDLE" and the "Tools" subfolder in it. > > We will be removing the irrelevant apps (PythonIDE, PackageManager). > The version number is going to stay. I'm ambivalent as to whether it > should be "Python" or "MacPython". "MacPython" has slight preference > because that's how it's been for years. I'd suggest Python because it's easier to see and react to, and Python is pretty standard on the Mac these days -- I think calling it MacPython will just need explaining and cause confusion. People think they're installing "Python". How about "Python 2.4"? Getting rid of the hyphen would also help with the visual cognition. > I see no reason to remove either BuildApplet or PythonLauncher for > this release. Fine, you're the expert. As long as they both work and aren't deprecated. Bill From bob at redivi.com Tue Feb 14 03:58:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 18:58:44 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: References: Message-ID: <41873179-630F-4069-8802-FC04D96ED99E@redivi.com> On Feb 13, 2006, at 10:11 AM, Ronald Oussoren wrote: > > On 13-feb-2006, at 1:37, Bob Ippolito wrote: > >> On Feb 12, 2006, at 1:19 PM, Ronald Oussoren wrote: >> >>> 8. The Python documentation is no longer installed as a help book. >> >> I wonder how hard this is to add to IDLE, or if we can just link >> to HTML docs. I'm not personally a big fan of Help Book anyway. > > I just read the source for pydoc, we could install the HTML docs in > Python.framework/Resources/English.lproj/Documentation. Idlelib > would need a patch to support this location. There's already > specific configuration for windows and linux in there (in > idlelib.EditorWindow) > > I just remembered something else that needs to be done some time: > create better icons, it's time to leave the 10 ton weight behind > (or at the very least the current rendition of it). I won't do this > though, given my skills in that deparment the icons would get worse > instead of better. It looks like if we put it here: dochome = os.path.join(sys.prefix, 'Doc', 'index.html') Which translates to: /Library/Frameworks/Python.framework/Versions/2.4/Doc/index.html Then the right thing will happen. The problem is that the docs are separate, so it'll be yet another hack in the build script to fetch this: http://python.org/ftp/python/doc/2.4.2/html-2.4.2.zip And then unzip it such that Python-Docs-2.4.2 ends up at os.path.join (sys.prefix, 'Doc') (either by symlink or rename). -bob From bob at redivi.com Tue Feb 14 04:38:23 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 13 Feb 2006 19:38:23 -0800 Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: <06Feb13.184412pst."58633"@synergy1.parc.xerox.com> References: <06Feb13.184412pst."58633"@synergy1.parc.xerox.com> Message-ID: <5549CFE8-2682-405C-83D1-38F0B36D37B5@redivi.com> On Feb 13, 2006, at 6:44 PM, Bill Janssen wrote: >>> At the moment, I'd suggest changing the name of this folder to just >>> "Python", and putting just "IDLE" and the "Tools" subfolder in it. >> >> We will be removing the irrelevant apps (PythonIDE, PackageManager). >> The version number is going to stay. I'm ambivalent as to whether it >> should be "Python" or "MacPython". "MacPython" has slight preference >> because that's how it's been for years. > > I'd suggest Python because it's easier to see and react to, and Python > is pretty standard on the Mac these days -- I think calling it > MacPython will just need explaining and cause confusion. People think > they're installing "Python". > > How about "Python 2.4"? Getting rid of the hyphen would also help > with the visual cognition. This sounds fine. -bob From janssen at parc.com Tue Feb 14 05:02:00 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 13 Feb 2006 20:02:00 PST Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: Your message of "Mon, 13 Feb 2006 19:38:23 PST." <5549CFE8-2682-405C-83D1-38F0B36D37B5@redivi.com> Message-ID: <06Feb13.200209pst."58633"@synergy1.parc.xerox.com> > > How about "Python 2.4"? Getting rid of the hyphen would also help > > with the visual cognition. > > This sounds fine. Great. Then I can put a pointer in the downloads page. Bill From artemispiperash at yahoo.com.au Tue Feb 14 08:41:35 2006 From: artemispiperash at yahoo.com.au (Harry Stratton) Date: Tue, 14 Feb 2006 18:41:35 +1100 (EST) Subject: [Pythonmac-SIG] Free Download Message-ID: <20060214074135.57171.qmail@web37111.mail.mud.yahoo.com> Hi, This may seem stupid, but I can't find any version of python that is not a document when downloaded. Please send me a link. John Mandrake. ____________________________________________________ Do you Yahoo!? The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database. http://au.movies.yahoo.com From bob at redivi.com Tue Feb 14 11:22:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 14 Feb 2006 02:22:12 -0800 Subject: [Pythonmac-SIG] Free Download In-Reply-To: <20060214074135.57171.qmail@web37111.mail.mud.yahoo.com> References: <20060214074135.57171.qmail@web37111.mail.mud.yahoo.com> Message-ID: <97073CE1-87AA-4B12-9036-65A89ACD6ED2@redivi.com> On Feb 13, 2006, at 11:41 PM, Harry Stratton wrote: > This may seem stupid, but I can't find any version of > python that is not a document when downloaded. Please > send me a link. You're going to have to be a little more specific about what version of Python you want and what OS you have, preferably also what you want to use it for. What downloads did you find, and what do you mean by the fact it's a document when downloaded? -bob From ghislain.delaunois at wanadoo.fr Mon Feb 13 10:54:24 2006 From: ghislain.delaunois at wanadoo.fr (ghislain delaunois) Date: Mon, 13 Feb 2006 10:54:24 +0100 Subject: [Pythonmac-SIG] Output window Message-ID: Dear all, I'm new in MacPython. I installed MacPython 2.4.1 for Mac OS X 10.3. and started working with PythonIDE, with a new file and a short script, but when I launch "Run all", the window "Output" does not display. I'm sure it works because when I quit PythonIDE, I see very briefly the Output window with the result of the run. Is there anybody who could help me? I would like to get both Edit and Output windows displayed together. Many thanks in advance. Ghislain From charles.hartman at conncoll.edu Mon Feb 13 22:13:38 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 13 Feb 2006 16:13:38 -0500 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <31CBFB68-4B1F-49AC-8B4F-B20093182A8B@redivi.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> <31CBFB68-4B1F-49AC-8B4F-B20093182A8B@redivi.com> Message-ID: <438BBA4B-3753-46E7-990E-900E45283E1C@conncoll.edu> On Feb 13, 2006, at 2:43 PM, Bob Ippolito wrote: > Please, everyone, do not continue this conversation until you have a > serious candidate icon for replacing the 12 ton weight. We don't > need ideas or opinions, we need pixels. I just sent this to Ron O. off-list, but since the conversation's ongoing, here's my candidate (as a .jpg, obviously, not yet an icon). I know some people are *afraid* of apples. But then they should be using Windows. Charles ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060213/12f9cf81/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Apple Python small proof.jpg Type: image/jpeg Size: 57496 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060213/12f9cf81/attachment-0001.jpg From sw at wordtech-software.com Tue Feb 14 14:10:30 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue, 14 Feb 2006 08:10:30 -0500 Subject: [Pythonmac-SIG] Free Download In-Reply-To: <20060214074135.57171.qmail@web37111.mail.mud.yahoo.com> References: <20060214074135.57171.qmail@web37111.mail.mud.yahoo.com> Message-ID: <43F1D6C6.7030507@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harry Stratton wrote: > Hi, > This may seem stupid, but I can't find any version of > python that is not a document when downloaded. Please > send me a link. > John Mandrake. > Where are you downloading Python from and what program are you using? - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8dbGJmdQs+6YVcoRAnV6AJ9mIpuhQSv6UaFRMn+3Ro6UOxbgDACeNpLS X7qAOeflGsndfwMHxhG6+88= =IUCN -----END PGP SIGNATURE----- From charles.hartman at conncoll.edu Tue Feb 14 14:11:06 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 14 Feb 2006 08:11:06 -0500 Subject: [Pythonmac-SIG] never mind Message-ID: Never mind. The previous message was supposed to get canceled. Charles From Hubert.Holin at lmd.polytechnique.fr Tue Feb 14 14:45:12 2006 From: Hubert.Holin at lmd.polytechnique.fr (Hubert Holin) Date: Tue, 14 Feb 2006 14:45:12 +0100 Subject: [Pythonmac-SIG] xcode as IDE? In-Reply-To: References: Message-ID: Paris (U.E.), le 14/02/2006 Bonjour On 12 f?vr. 2006, at 05:48, pythonmac-sig-request at python.org wrote: > From: Bob Ippolito > Date: 12 f?vrier 2006 05:06:33 HNEC > To: I.Vinogradov > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] xcode as IDE? > > > > On Feb 11, 2006, at 7:39 PM, I. Vinogradov wrote: > >> while on the topic of IDEs, would it be possible to somehow adapt >> Xcode >> to the task? It has Python keyword highlight, and PyObjC is one of >> the >> possible types of documents. >> >> I have some vague notion that perhaps a pure python file template can >> be made, that uses framework installation and all. Is something like >> that even possible? > > Xcode isn't a very good IDE for anything but the languages it > supports natively. It does not have public APIs to change that, > either. If you use Xcode as an IDE, it won't be much more than a > glorified text editor with syntax highlighting. I wish it was a > good idea to use Xcode, but they haven't built it in such a way > that allows third parties to add value. > > It makes a little sense with PyObjC because we've put together some > py2app integration with Xcode, but it's a really ugly hack and > doesn't work all that reliably because the custom build+run target > is for some crazy reason stored as a user setting rather than a > project setting. It's also prone to break at any Xcode update > because it needs to read the undocumented Xcode project file format > in order to get the information it needs. > > If you're considering Xcode, you'd be better off with Eclipse for > Python development. Eclipse is bigger, slower, and uglier -- but > at least it can provide more functionality than a text editor. > > -bob Well, I for one would welcome better XCode integration. I actually requested a new feature (4268839, "Integrated Python debugging.", 22-Sep-2005) and two enhancements (4268844, "Round- tripping for PyObjC/IB.", 22-Sep-2005 and 4268827, "ER: External targets should support build configurations", 22-Sep-2005) thru Apple's Bug Reporter. The other way around (just to be sure we can build them for non- Apple Python distributions), it would be nice to have an XCode project type "Python C++ extension". The main reason (good or not, this is another question), is that I want to use Apple's dev tools (including XCode) to develop in-house MAC software, using C++ (and Python, of course ;-) ) as much as possible, and not touching ObjC even with a 10-foot pole. I usually do several iterations, each useful in its own right: full command-line C++ (to build the foundation and for other team members), Python with C++ extensions (so that said team members stay reasonably sane just a bit longer...), PyObjC+Python+C++ 'cause I personally want to use a Mac app with native GUI. Note: theory done with paper and pencil (and Maple in times of yore... before they switched to the unethical activation scheme), and prototyping done (usually) with MATLAB (we do need more and more easily accessible Python packages...). As far as XCode being essentially a glorified text editor, w.r.t. Python, in my case it isn't even that, as I use TextWrangler as an "external editor" :-) . Merci Hubert Holin From kquirk at solidworks.com Tue Feb 14 17:11:12 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Tue, 14 Feb 2006 11:11:12 -0500 Subject: [Pythonmac-SIG] Build script for Universal Python Message-ID: My complaint about that one is that it's far too big for an icon, and shrunk to icon size it will be illegible. Here's a Monty Pythonic idea for an icon worked up by our artist: There are several variations possible of this idea, including incorporating an apple sticking out of the head as well. We also were toying with using the well-known Monty Python "foot" and tattooing it with the word Python, or spelling out Python in the "Life Of Brian" 'brick' typeface. Anyone think any of these ideas is worth pursuing? Kent ________________________________ From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig-bounces at python.org] On Behalf Of Charles Hartman Sent: Monday, February 13, 2006 4:14 PM To: Bob Ippolito Cc: PythonMac Subject: Re: [Pythonmac-SIG] Build script for Universal Python On Feb 13, 2006, at 2:43 PM, Bob Ippolito wrote: Please, everyone, do not continue this conversation until you have a serious candidate icon for replacing the 12 ton weight. We don't need ideas or opinions, we need pixels. I just sent this to Ron O. off-list, but since the conversation's ongoing, here's my candidate (as a .jpg, obviously, not yet an icon). I know some people are *afraid* of apples. But then they should be using Windows. Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060214/3483f4e5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1472 bytes Desc: image001.jpg Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060214/3483f4e5/attachment.jpe From bob at redivi.com Tue Feb 14 18:27:39 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 14 Feb 2006 09:27:39 -0800 Subject: [Pythonmac-SIG] Output window In-Reply-To: References: Message-ID: <68FE1BD1-5969-43D6-9EFA-4FBDAE92720F@redivi.com> On Feb 13, 2006, at 1:54 AM, ghislain delaunois wrote: > I'm new in MacPython. I installed MacPython 2.4.1 for Mac OS X 10.3. > and started working with PythonIDE, with a new file and a short > script, > but when I launch "Run all", the window "Output" does not display. I'm > sure it works because when I quit PythonIDE, I see very briefly the > Output window with the result of the run. > > Is there anybody who could help me? I would like to get both Edit and > Output windows displayed together. Don't use PythonIDE. PythonIDE is deprecated and will not be included in any future version of Python. It has been unmaintained for several years, and is not compatible with the new Intel macs. IDLE should work if you install this: http:// tcltkaqua.sourceforge.net/ -- it works out of the box on OS X 10.4, but 10.3 needs Tk installed. -bob From Chris.Barker at noaa.gov Tue Feb 14 20:11:44 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 14 Feb 2006 11:11:44 -0800 Subject: [Pythonmac-SIG] final? try at new MacPython download page In-Reply-To: References: <06Feb13.153401pst.58633@synergy1.parc.xerox.com> Message-ID: <43F22B70.2070002@noaa.gov> Charles Hartman wrote: > The two big topics -- topics that loomed large for me when I started > trying to figure out whether I wanted to use Python on the Mac -- > aren't really addressed yet: alternative IDEs (Wing, SPE, PyOXIDE if > it were working, etc) and GUI libraries (especially wxPython). > If these doesn't go on the first page -- I guess the consensus may be > against this -- then shouldn't they go in the FAQ? They should go in the Wiki, one page for each topic. The topics are too big for a FAQ. One of us needs to start writing them. > I see wxPython > mentioned there, very much in passing, and with a virtual deprecation > in the same sentence That may be out of date info. wxPython has improved a LOT in recent releases. It's a Wiki, we can update it. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Tue Feb 14 20:23:53 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 14 Feb 2006 11:23:53 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <641BAA58-527E-44C9-AE05-40201633B011@theolliviers.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> <65197831-6BDA-47E8-BC84-1767298C12AB@mac.com> <641BAA58-527E-44C9-AE05-40201633B011@theolliviers.com> Message-ID: <43F22E49.60400@noaa.gov> Kevin, you are completely right about the icon issue, but someone needs to lead the effort --- will you do it? If you want it to be adopted by the general Python community, Guido is the obvious one to ask. By the way, I've heard there is a (slow) effort afoot to update the python.org web site -- perhaps they've already done done icon work, or other graphic work that could be adapted. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From kevino at theolliviers.com Tue Feb 14 21:06:04 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Tue, 14 Feb 2006 12:06:04 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <43F22E49.60400@noaa.gov> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> <65197831-6BDA-47E8-BC84-1767298C12AB@mac.com> <641BAA58-527E-44C9-AE05-40201633B011@theolliviers.com> <43F22E49.60400@noaa.gov> Message-ID: Hi Chris, On Feb 14, 2006, at 11:23 AM, Christopher Barker wrote: > Kevin, you are completely right about the icon issue, but someone > needs to lead the effort --- will you do it? If you want it to be > adopted by the general Python community, Guido is the obvious one > to ask. By the way, I've heard there is a (slow) effort afoot to > update the python.org web site -- perhaps they've already done done > icon work, or other graphic work that could be adapted. I'm definitely willing to do it, with the caveat that I do have a couple other things on my plate that are priority right now. (Which is why I haven't been following/reply to this discussion as actively as I'd have liked to.) I should be able to at least put some time into it this weekend, though. Thanks, Kevin > -Chris > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov From ronaldoussoren at mac.com Tue Feb 14 22:55:45 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 14 Feb 2006 22:55:45 +0100 Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: <1C4C3A9E-EF29-40BA-9D65-5C9098052209@redivi.com> References: <06Feb13.174557pst.58633@synergy1.parc.xerox.com> <1C4C3A9E-EF29-40BA-9D65-5C9098052209@redivi.com> Message-ID: On 14-feb-2006, at 3:12, Bob Ippolito wrote: > >> 2. The IDLE app is bit hard to find, being in >> /Applications/MacPython-2.4/, along with a bunch of other >> (dead or >> dying?) apps, like PythonIDE and PackageManager. > > This is intentional, that's not changing. "This" being the folder name, PythonIDE and PackageManager won't be in the universal build. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060214/133864b9/attachment.bin From mmilczyn at techfak.uni-bielefeld.de Tue Feb 14 22:28:30 2006 From: mmilczyn at techfak.uni-bielefeld.de (Matthias Milczynski) Date: Tue, 14 Feb 2006 22:28:30 +0100 Subject: [Pythonmac-SIG] Pythonw and VPython and Fink Message-ID: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> Hello, I would like to use SPE (cool Python editor) with vpython, that I installed with fink (unfortunately there is no other possibility yet). My vpython stuff is located in /sw/lib/python2.4/site-packages/ visual, but I run SPE with /usr/local/bin/pythonw2.4. When I try to run any vpython script I encounter the following error: /////////////////////////////////////////////////////////////// Traceback (most recent call last): File "bounce.py", line 1, in ? from visual import * File "/sw/lib/python2.4/site-packages/visual/__init__.py", line 15, in ? import array_backend File "/sw/lib/python2.4/site-packages/visual/array_backend.py", line 1, in ? import cvisual ImportError: Failure linking new module: /sw/lib/python2.4/site- packages/cvisualmodule.so: Symbol not found: _PyObject_IsInstance Referenced from: /sw/lib/python2.4/site-packages/cvisualmodule.so Expected in: /Library/Frameworks/Python.framework/Versions/2.4/ Resources/Python.app/Contents/MacOS/Python /////////////////////////////////////////////////////////////// I assume that the solution of this problem would be to somehow get a fink-based pythonw, but this seems to be not avaiable. Can anybody help me with this? Thanks a lot!! Matthias From ronaldoussoren at mac.com Tue Feb 14 22:57:44 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 14 Feb 2006 22:57:44 +0100 Subject: [Pythonmac-SIG] problems with 2.4.1 installer In-Reply-To: <41A18EEC-6DE8-4BD5-882D-4F9E1A868EFB@redivi.com> References: <06Feb13.181017pst.58633@synergy1.parc.xerox.com> <41A18EEC-6DE8-4BD5-882D-4F9E1A868EFB@redivi.com> Message-ID: <20635846-1DBB-4D58-81BD-44BFD58A20AF@mac.com> On 14-feb-2006, at 3:24, Bob Ippolito wrote: > > I see no reason to remove either BuildApplet or PythonLauncher for > this release. PythonLauncher is the program that's used when you double click on .pyw files. We could move it insite the framework, but then you'd no longer have an easy way to change its preferences. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060214/eec0be0a/attachment.bin From ronaldoussoren at mac.com Tue Feb 14 23:01:01 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 14 Feb 2006 23:01:01 +0100 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <438BBA4B-3753-46E7-990E-900E45283E1C@conncoll.edu> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> <31CBFB68-4B1F-49AC-8B4F-B20093182A8B@redivi.com> <438BBA4B-3753-46E7-990E-900E45283E1C@conncoll.edu> Message-ID: <058A121D-428B-4471-BE01-935B83D5FD17@mac.com> On 13-feb-2006, at 22:13, Charles Hartman wrote: > > On Feb 13, 2006, at 2:43 PM, Bob Ippolito wrote: > >> Please, everyone, do not continue this conversation until you have a >> serious candidate icon for replacing the 12 ton weight. We don't >> need ideas or opinions, we need pixels. > > I just sent this to Ron O. off-list, but since the conversation's > ongoing, > here's my candidate (as a .jpg, obviously, not yet an icon). > > I know some people are *afraid* of apples. But then they should be > using Windows. As I already replied off-list, I don't like this picture at all. It is a lot less tastefull than the icon on Bob's website (which I do like). The only reason for having a discussion about the icon anyway is that some people claim that a photo-realistic snake-related image will scare some users away. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060214/2ebd6253/attachment.bin From bob at redivi.com Tue Feb 14 23:16:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 14 Feb 2006 14:16:34 -0800 Subject: [Pythonmac-SIG] Pythonw and VPython and Fink In-Reply-To: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> References: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> Message-ID: On Feb 14, 2006, at 1:28 PM, Matthias Milczynski wrote: > I would like to use SPE (cool Python editor) with vpython, that I > installed with fink (unfortunately there is no other possibility > yet). My vpython stuff is located in /sw/lib/python2.4/site-packages/ > visual, but I run SPE with /usr/local/bin/pythonw2.4. When I try to > run any vpython script I encounter the following error: > > /////////////////////////////////////////////////////////////// > > Traceback (most recent call last): > File "bounce.py", line 1, in ? > from visual import * > File "/sw/lib/python2.4/site-packages/visual/__init__.py", line > 15, in ? > import array_backend > File "/sw/lib/python2.4/site-packages/visual/array_backend.py", > line 1, in ? > import cvisual > ImportError: Failure linking new module: /sw/lib/python2.4/site- > packages/cvisualmodule.so: Symbol not found: _PyObject_IsInstance > Referenced from: /sw/lib/python2.4/site-packages/cvisualmodule.so > Expected in: /Library/Frameworks/Python.framework/Versions/2.4/ > Resources/Python.app/Contents/MacOS/Python > > > /////////////////////////////////////////////////////////////// > > I assume that the solution of this problem would be to somehow get a > fink-based pythonw, but this seems to be not avaiable. > Can anybody help me with this? You can't (reliably) import modules from one Python with another. It simply just doesn't work like that. Not too much you can do about it. pythonw is totally irrelevant. There is *nothing special* about pythonw, it is just a shell script or simple C program that effectively manipulates argv[0] and then launches a real Python interpreter. I can think of three possible workarounds: 1. Somehow configure SPE to use /sw/bin/python to fork its subprocesses (hopefully it uses subprocesses!) 2. Get or build a VPython that is compatible with Python.framework 3. Get or build a SPE for Fink. -bob From charles.hartman at conncoll.edu Wed Feb 15 02:12:41 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 14 Feb 2006 20:12:41 -0500 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <058A121D-428B-4471-BE01-935B83D5FD17@mac.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> <31CBFB68-4B1F-49AC-8B4F-B20093182A8B@redivi.com> <438BBA4B-3753-46E7-990E-900E45283E1C@conncoll.edu> <058A121D-428B-4471-BE01-935B83D5FD17@mac.com> Message-ID: <45949E88-82CF-4231-AEB2-2DCE80232E19@conncoll.edu> On Feb 14, 2006, at 5:01 PM, Ronald Oussoren wrote: > As I already replied off-list, I don't like this picture at all. It > is a lot > less tastefull than the icon on Bob's website (which I do like). > The only reason > for having a discussion about the icon anyway is that some people > claim that > a photo-realistic snake-related image will scare some users away. Yes, I posted it in the heat of discussion, never a good idea; and after that off-list reply, since my (oversize) image message was tangled in the queue, I tried to withdraw it, but apparently couldn't. I apologize. As for "taste," non est disputandum. Still, I agree. I think a 16-ton weight (whose major appearance in M. Python, as I recall, was to crush Arthur Pewty as retribution for being too much of a wimp to go back into the marriage counselor's office and stop him from carrying on with his, A.P.'s wife) is more tasteful. In any case, the last thing we need is PETA after us all. ;), or something Charles From janssen at parc.com Wed Feb 15 05:57:46 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 14 Feb 2006 20:57:46 PST Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: Your message of "Tue, 14 Feb 2006 14:01:01 PST." <058A121D-428B-4471-BE01-935B83D5FD17@mac.com> Message-ID: <06Feb14.205755pst."58633"@synergy1.parc.xerox.com> > The only reason for having a discussion about the icon anyway is > that some people claim that a photo-realistic snake-related image > will scare some users away. It almost seems inhumane to try to convince those people to use a language called "Python", anyway. Probably cause bad dreams or something. Bill From delza at livingcode.org Wed Feb 15 05:58:51 2006 From: delza at livingcode.org (Dethe Elza) Date: Tue, 14 Feb 2006 20:58:51 -0800 Subject: [Pythonmac-SIG] Pythonw and VPython and Fink In-Reply-To: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> References: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> Message-ID: On 14-Feb-06, at 1:28 PM, Matthias Milczynski wrote: > I assume that the solution of this problem would be to somehow get a > fink-based pythonw, but this seems to be not avaiable. > Can anybody help me with this? I think the solution is for VPython to be ported to Aqua instead of using X11 (so it can use regular OS X Python, not Fink, among other good things). Unfortunately the times I've tried to take this on, the VPython build system has thwarted me. Periodically I make time to try again, because I'd really like to have VPython, but refuse to install Fink again. --Dethe Every day computers are making people easier to use. --David Tompkin From daniel at brightfire.com Wed Feb 15 06:09:23 2006 From: daniel at brightfire.com (Daniel Lord) Date: Tue, 14 Feb 2006 21:09:23 -0800 Subject: [Pythonmac-SIG] Interesting Open Source Project: Cocoa Dialog In-Reply-To: References: Message-ID: <30650A13-FCFF-4D41-AD05-AD3101484A36@brightfire.com> (Unless of course its been mentioned here before and then in the words of SNL's immortal Emily Latella: "Never mind!") CocoaDialog seems to fill that gap between the command-line and PyObjC providing a 'quick and dirty' GUI interface for scripts (Python. Perl. Shell, Ruby, etc.) I just found it while 'googling up' up some AppKit NSTextContainer subtleties I was having trouble figuring out and I thought I'd pass it along. How Google put those two together I'll never know ;-) Clearly it doesn't replace PyObjC's power and breadth, but it might have a place in the toolbox for smaller projects. Kind of a Growl/ Display Dialog artifice. http://cocoadialog.sourceforge.net/documentation.html Daniel From robert.kern at gmail.com Wed Feb 15 06:15:13 2006 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 14 Feb 2006 23:15:13 -0600 Subject: [Pythonmac-SIG] Pythonw and VPython and Fink In-Reply-To: References: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> Message-ID: <43F2B8E1.8080702@gmail.com> Dethe Elza wrote: > I think the solution is for VPython to be ported to Aqua instead of > using X11 (so it can use regular OS X Python, not Fink, among other > good things). Framework builds of Python can use X11 just fine. I'm not sure that's the holdup. -- Robert Kern robert.kern at gmail.com "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 Wed Feb 15 06:15:19 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 14 Feb 2006 21:15:19 -0800 Subject: [Pythonmac-SIG] Pythonw and VPython and Fink In-Reply-To: References: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> Message-ID: <1E9ED138-324C-4D42-8742-74AD52200280@redivi.com> On Feb 14, 2006, at 8:58 PM, Dethe Elza wrote: > On 14-Feb-06, at 1:28 PM, Matthias Milczynski wrote: >> I assume that the solution of this problem would be to somehow get a >> fink-based pythonw, but this seems to be not avaiable. >> Can anybody help me with this? > > I think the solution is for VPython to be ported to Aqua instead of > using X11 (so it can use regular OS X Python, not Fink, among other > good things). Unfortunately the times I've tried to take this on, > the VPython build system has thwarted me. Periodically I make time > to try again, because I'd really like to have VPython, but refuse to > install Fink again. If someone buys me a quad g5, I'll gladly port VPython. The last time I looked into it, it just took too damn long any time I wanted to fiddle with the build. I have very little patience for slow edit +run cycles. -bob From janssen at parc.com Wed Feb 15 06:15:06 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 14 Feb 2006 21:15:06 PST Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: Your message of "Tue, 14 Feb 2006 11:23:53 PST." <43F22E49.60400@noaa.gov> Message-ID: <06Feb14.211510pst."58633"@synergy1.parc.xerox.com> > By the > way, I've heard there is a (slow) effort afoot to update the python.org > web site -- perhaps they've already done done icon work, or other > graphic work that could be adapted. http://beta.python.org/ They're using a logo from http://www.pythonology.com/logos. Personally, I prefer the foot, perhaps in front of or crushing an apple (not Apple's apple -- perhaps a photorealistic McIntosh), or Kevin's idea of Python spelled out in Life of Brian blocks. Bill From lanceboyle at qwest.net Wed Feb 15 06:16:09 2006 From: lanceboyle at qwest.net (lanceboyle at qwest.net) Date: Tue, 14 Feb 2006 22:16:09 -0700 Subject: [Pythonmac-SIG] Interesting Open Source Project: Cocoa Dialog In-Reply-To: <30650A13-FCFF-4D41-AD05-AD3101484A36@brightfire.com> References: <30650A13-FCFF-4D41-AD05-AD3101484A36@brightfire.com> Message-ID: <67976B6C-FF13-4B41-AFF0-43048865B393@qwest.net> Perhaps even better is the _most_excellent_ Pashua. http://www.bluem.net/downloads/pashua_en/ Jerry On Feb 14, 2006, at 10:09 PM, Daniel Lord wrote: > (Unless of course its been mentioned here before and then in the > words of SNL's immortal Emily Latella: "Never mind!") > > CocoaDialog seems to fill that gap between the command-line and > PyObjC providing a 'quick and dirty' GUI interface for scripts > (Python. Perl. Shell, Ruby, etc.) > I just found it while 'googling up' up some AppKit NSTextContainer > subtleties I was having trouble figuring out and I thought I'd pass > it along. How Google put those two together I'll never know ;-) > > Clearly it doesn't replace PyObjC's power and breadth, but it might > have a place in the toolbox for smaller projects. Kind of a Growl/ > Display Dialog artifice. > > http://cocoadialog.sourceforge.net/documentation.html > > Daniel > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Wed Feb 15 06:30:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 14 Feb 2006 21:30:12 -0800 Subject: [Pythonmac-SIG] Interesting Open Source Project: Cocoa Dialog In-Reply-To: <30650A13-FCFF-4D41-AD05-AD3101484A36@brightfire.com> References: <30650A13-FCFF-4D41-AD05-AD3101484A36@brightfire.com> Message-ID: On Feb 14, 2006, at 9:09 PM, Daniel Lord wrote: > (Unless of course its been mentioned here before and then in the > words of SNL's immortal Emily Latella: "Never mind!") I think something like it was mentioned a few years ago, but there haven't been any recent discussions about this particular application or the topic in general. > CocoaDialog seems to fill that gap between the command-line and > PyObjC providing a 'quick and dirty' GUI interface for scripts > (Python. Perl. Shell, Ruby, etc.) > I just found it while 'googling up' up some AppKit NSTextContainer > subtleties I was having trouble figuring out and I thought I'd pass > it along. How Google put those two together I'll never know ;-) One thing to note: CocoaDialog is GPL. This is probably OK for most contexts since you just communicate with it via pipes, but it certainly means that it'd never be a standard feature of either OS X or MacPython. > Clearly it doesn't replace PyObjC's power and breadth, but it might > have a place in the toolbox for smaller projects. Kind of a Growl/ > Display Dialog artifice. > > http://cocoadialog.sourceforge.net/documentation.html There's no reason why PyObjC couldn't ship with a library that had a set of "Easy Dialogs" to use from more CLI-oriented apps. It'd be a good project for someone who cares. I'd recommend simply re- implementing the old EasyDialogs API in PyObjC, and then extending it to support more modern features of OS X. -bob From delza at livingcode.org Wed Feb 15 06:34:52 2006 From: delza at livingcode.org (Dethe Elza) Date: Tue, 14 Feb 2006 21:34:52 -0800 Subject: [Pythonmac-SIG] Pythonw and VPython and Fink In-Reply-To: <43F2B8E1.8080702@gmail.com> References: <798FE018-1A5A-4865-9D25-378B3DB8B635@techfak.uni-bielefeld.de> <43F2B8E1.8080702@gmail.com> Message-ID: <790A3E46-67E5-45B6-9B79-917925020EDE@livingcode.org> > Framework builds of Python can use X11 just fine. I'm not sure > that's the holdup. The holdup is that it hasn't really been ported to OS X, they've just tweaked the Linux/Gnome version enough that you can build it on OS X, as long as you build GTK and friends first, and use X11, and get exactly the right version of Boost.Python, etc. OS X has a perfectly good OpenGL layer, which they've chosen to ignore. I don't think porting the actual code would be that big a deal, and I'd be willing to do it, but I end up struggling with their autoconf hacks--my configuration-fu is not up to it, and I'm not really interested in learning autoconf. I asked the VPython folks why they don't use distutils and they told me it was because a) distutils doesn't properly support C++, b) windows and macs don't necessarily have a compiler installed, and c) distutils requires that extensions be built with the exact compiler that built Python. None of these are actually true (I checked on the distutils list), but there you go. I like VPython and wish I could use it under Aqua. Sooner or later I'll take another stab at porting it or rewriting it in PyOpenGL. --Dethe "the city carries such a cargo of pathos and longing that daily life there vaccinates us against revelation" -- Pain Not Bread, The Rise and Fall of Human Breath From energias.renovables.ya at gmail.com Wed Feb 15 19:43:00 2006 From: energias.renovables.ya at gmail.com (Perico) Date: Wed, 15 Feb 2006 19:43:00 +0100 Subject: [Pythonmac-SIG] Fwd: runnig code step by step References: <55C2A915-2246-4CF8-A5BE-9E748C10B7C6@gmail.com> Message-ID: Hi guys!!! > > I have that piece of code: > > while 1: > a=raw_input("Press a key to continue") > > > I'd like to change the last line, I don't want to control a key > press if not I want to control a button of the form > > > My question is if somthing exists to control the push button event. > > See you. Peter. > > > From bob at redivi.com Wed Feb 15 20:05:55 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 15 Feb 2006 11:05:55 -0800 Subject: [Pythonmac-SIG] Fwd: runnig code step by step In-Reply-To: References: <55C2A915-2246-4CF8-A5BE-9E748C10B7C6@gmail.com> Message-ID: The easiest way is to change the text to say "press return to continue". The problem is that stdin defaults to reading a line at a time (at the OS level), and you have to go through a lot of trouble fiddling with obscure terminal settings if you want to be able to capture individual characters. It's really not worth doing in most cases. -bob On Feb 15, 2006, at 10:43 AM, Perico wrote: > Hi guys!!! > >> >> I have that piece of code: >> >> while 1: >> a=raw_input("Press a key to continue") >> >> >> I'd like to change the last line, I don't want to control a key >> press if not I want to control a button of the form >> >> >> My question is if somthing exists to control the push button event. >> >> See you. Peter. >> >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Wed Feb 15 20:56:27 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 15 Feb 2006 11:56:27 -0800 Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: <058A121D-428B-4471-BE01-935B83D5FD17@mac.com> References: <2FE45156-7870-44AD-B579-5D1EE907B0BA@redivi.com> <0693DBF5-6992-443E-ADCE-6055D009CDCA@mac.com> <43395636-0482-47A8-996C-428E1C2338A6@theolliviers.com> <31CBFB68-4B1F-49AC-8B4F-B20093182A8B@redivi.com> <438BBA4B-3753-46E7-990E-900E45283E1C@conncoll.edu> <058A121D-428B-4471-BE01-935B83D5FD17@mac.com> Message-ID: <43F3876B.1080106@noaa.gov> Ronald Oussoren wrote: > only reason > for having a discussion about the icon anyway is that some people claim > that > a photo-realistic snake-related image will scare some users away. The other reason is that we don't want to use an Apple trademark. > http://beta.python.org/ I don't love it, but it's fine, and it would scale well to different sizes. Using the same icon as the web site is a very good idea. Does anyone know how final that look for the web site is? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From janssen at parc.com Wed Feb 15 22:17:01 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 15 Feb 2006 13:17:01 PST Subject: [Pythonmac-SIG] Build script for Universal Python In-Reply-To: Your message of "Wed, 15 Feb 2006 11:56:27 PST." <43F3876B.1080106@noaa.gov> Message-ID: <06Feb15.131711pst."58633"@synergy1.parc.xerox.com> > Using the same icon as the web site is a very good idea. I'd actually rather use a different icon from the Web site, though incorporating design elements from the Web site's icon might be a good idea. I'm eager to see what Kevin and his designers come up with. Bill From janssen at parc.com Thu Feb 16 02:58:06 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 15 Feb 2006 17:58:06 PST Subject: [Pythonmac-SIG] add other Python distros to the downloads page? Message-ID: <06Feb15.175807pst."58633"@synergy1.parc.xerox.com> I was thinking of adding a section at the bottom with pointers to the ActiveState Python along with the fink and DarwinPorts Python downloads. Are there others we might mention? Isn't there a big SciPy installer, too. Bill From robert.kern at gmail.com Thu Feb 16 03:03:15 2006 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 15 Feb 2006 20:03:15 -0600 Subject: [Pythonmac-SIG] add other Python distros to the downloads page? In-Reply-To: <06Feb15.175807pst."58633"@synergy1.parc.xerox.com> References: <06Feb15.175807pst."58633"@synergy1.parc.xerox.com> Message-ID: <43F3DD63.50401@gmail.com> Bill Janssen wrote: > I was thinking of adding a section at the bottom with pointers to the > ActiveState Python along with the fink and DarwinPorts Python > downloads. Are there others we might mention? Isn't there a big > SciPy installer, too. You are probably thinking of MacEnthon. It was just a bunch of bdist_mpkg's tied together by a single mpkg. It is quite old and is not being updated. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From trentm at ActiveState.com Thu Feb 16 03:06:30 2006 From: trentm at ActiveState.com (Trent Mick) Date: Wed, 15 Feb 2006 18:06:30 -0800 Subject: [Pythonmac-SIG] add other Python distros to the downloads page? In-Reply-To: <06Feb15.175807pst."58633"@synergy1.parc.xerox.com> References: <06Feb15.175807pst."58633"@synergy1.parc.xerox.com> Message-ID: <20060216020630.GB446@activestate.com> [Bill Janssen wrote] > I was thinking of adding a section at the bottom with pointers to the > ActiveState Python along with the fink and DarwinPorts Python "ActivePython" we call it. > downloads. Are there others we might mention? Isn't there a big > SciPy installer, too. "enthon" they call it -- though it looks like they only have a distro for Windows. http://code.enthought.com/enthon/ I think mention of the other distros out there (along with a brief synopsis of them) would help users make an informed decision. Trent -- Trent Mick TrentM at ActiveState.com From bob at redivi.com Thu Feb 16 03:10:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 15 Feb 2006 18:10:00 -0800 Subject: [Pythonmac-SIG] add other Python distros to the downloads page? In-Reply-To: <20060216020630.GB446@activestate.com> References: <06Feb15.175807pst."58633"@synergy1.parc.xerox.com> <20060216020630.GB446@activestate.com> Message-ID: <9E984DA2-6A8C-47AE-AEE6-117FF5F5D87D@redivi.com> On Feb 15, 2006, at 6:06 PM, Trent Mick wrote: > [Bill Janssen wrote] >> I was thinking of adding a section at the bottom with pointers to the >> ActiveState Python along with the fink and DarwinPorts Python > > "ActivePython" we call it. > >> downloads. Are there others we might mention? Isn't there a big >> SciPy installer, too. > > "enthon" they call it -- though it looks like they only have a distro > for Windows. > http://code.enthought.com/enthon/ > > I think mention of the other distros out there (along with a brief > synopsis of them) would help users make an informed decision. We should probably have this stuff on a wiki page, which the main page links to. -bob From janssen at parc.com Thu Feb 16 04:35:22 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 15 Feb 2006 19:35:22 PST Subject: [Pythonmac-SIG] add other Python distros to the downloads page? In-Reply-To: Your message of "Wed, 15 Feb 2006 18:10:00 PST." <9E984DA2-6A8C-47AE-AEE6-117FF5F5D87D@redivi.com> Message-ID: <06Feb15.193523pst."58633"@synergy1.parc.xerox.com> All right, I've added a wiki page (have I mentioned how much I dislike wiki markup syntax? oh, well...) called PythonDistributionsForMac. Everybody, please review if you care, and fix as necessary. Trent, you'll want to add a fuller description of ActivePython. I'll put a link to this page at the bottom of the downloads page. Bill From nirs at freeshell.org Thu Feb 16 14:00:56 2006 From: nirs at freeshell.org (Nir Soffer) Date: Thu, 16 Feb 2006 15:00:56 +0200 Subject: [Pythonmac-SIG] Getting Terminal input and output encoding Message-ID: <30459fcba0f1f4dbfd3e2b113dd8f00d@freeshell.org> I'm trying to find a way to get the user encoding used for example for command line arguments e.g.: # creating an Hebrew file name... touch ????? ./foo.py * From my experience with Mac OS X 10.0-3, I know the foo.py will always get hebrew-name using utf-8. You can also see this when you type non-ASCII in the Terminal: $ touch \327\242\327\221\327\250\327\231\327\252 Will create the file named "?????" I noticed that it does not matter what encoding you set in the Terminal window setting, anything you type will use utf-8 encoding. Anyway, I could not find any documentation about this issue, expect this: "All BSD system functions expect their string parameters to be in UTF-8 encoding and nothing else. Code that calls BSD system routines should ensure that the contents of all const *char parameters are in canonical UTF-8 encoding." On Linux people are getting the encoding with: import locale locale.getpreferredencoding() But on OS X getpreferredencoding() returns useless results, at least for decoding command line arguments or printing readable output. For example: 1. Choose "Window Settings..." in the Terminal and set the Character Set Encoding to Unicode (UTF-8) 2. Try: >>> import locale >>> locale.getpreferredencoding() 'mac-roman' I have found this code trying to correct the behavior (from bzrlib): # work around egregious python 2.4 bug >>> import sys >>> sys.platform = 'posix' >>> import locale >>> locale.getpreferredencoding() 'US-ASCII' >>> sys.platform = 'darwin' Obviously this workaround does not work around this problem :-) So my conclusion is that Mac OS X uses always utf-8 for input to the shell. Unless I am missing something? Next, how can you get the Terminal output encoding? For example, what if a user changed the Character Set Encoding to Western (Mac OS Roman) - how can you detect this setting from Python? Best Regards, Nir Soffer From nirs at freeshell.org Thu Feb 16 16:15:02 2006 From: nirs at freeshell.org (Nir Soffer) Date: Thu, 16 Feb 2006 17:15:02 +0200 Subject: [Pythonmac-SIG] Getting Terminal input and output encoding In-Reply-To: <30459fcba0f1f4dbfd3e2b113dd8f00d@freeshell.org> References: <30459fcba0f1f4dbfd3e2b113dd8f00d@freeshell.org> Message-ID: <15389fbdaf17ea07a5edceffcace2050@freeshell.org> On 16 Feb, 2006, at 15:00, Nir Soffer wrote: > I noticed that it does not matter what encoding you set in the Terminal > window setting, anything you type will use utf-8 encoding. I was wrong, it does change the input encoding when you type or display strings. However, testing common commands from Python using os.system and in shell scripts show that commands want to get utf-8 input and return utf-8 input. If you change the terminal charset encoding you simply display the utf-8 strings as junk. Best Regards, Nir Soffer From trentm at ActiveState.com Thu Feb 16 21:25:58 2006 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 16 Feb 2006 12:25:58 -0800 Subject: [Pythonmac-SIG] add other Python distros to the downloads page? In-Reply-To: <06Feb15.193523pst."58633"@synergy1.parc.xerox.com> References: <9E984DA2-6A8C-47AE-AEE6-117FF5F5D87D@redivi.com> <06Feb15.193523pst."58633"@synergy1.parc.xerox.com> Message-ID: <20060216202558.GD15630@activestate.com> [Bill Janssen wrote] > All right, I've added a wiki page (have I mentioned how much I dislike > wiki markup syntax? oh, well...) called PythonDistributionsForMac. > Everybody, please review if you care, and fix as necessary. Trent, > you'll want to add a fuller description of ActivePython. Done. Thanks. Trent -- Trent Mick TrentM at ActiveState.com From samrobertsmith at gmail.com Fri Feb 17 08:49:37 2006 From: samrobertsmith at gmail.com (linda.s) Date: Thu, 16 Feb 2006 23:49:37 -0800 Subject: [Pythonmac-SIG] not appear In-Reply-To: References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> <220f68650602061127v515abc2frc20068199a471143@mail.gmail.com> <618D3674-95E8-4636-9D59-18126A5DB815@redivi.com> <43E7AADB.4000507@noaa.gov> Message-ID: <1d987df30602162349w5f8502afu6b308a0b7853617e@mail.gmail.com> On 2/6/06, Bob Ippolito wrote: > > On Feb 6, 2006, at 12:00 PM, Christopher Barker wrote: > > > Bob Ippolito wrote: > >> The framework build's bin directory is technically way down inside > >> the framework, but there are symlinks in /usr/local/bin. > > > > However: > > > > linda.s wrote: > >> The > >> installation appeared to be fine until "make install" was complete. > > > > So it looks like the OP didn't do a Framework build. > > > > What all this means is that you shouldn't build from source unless you > > know what you are doing, and have a good reason to. > > A unix build puts the binaries in /usr/local/bin too unless you > change the prefix or something. Either way you need to know how to > manage your PATH. > > -bob Can anyone tell me how to build the path? I still can not see my Python 2.4 appear. Thanks. Linda. From mjb at uma.pt Fri Feb 17 13:10:22 2006 From: mjb at uma.pt (Michael Barber) Date: Fri, 17 Feb 2006 12:10:22 +0000 Subject: [Pythonmac-SIG] not appear In-Reply-To: <1d987df30602162349w5f8502afu6b308a0b7853617e@mail.gmail.com> References: <1d987df30602060034p451d4756hd6d674263226bc64@mail.gmail.com> <220f68650602060105l77842aa4x222389c37f77eae7@mail.gmail.com> <1d987df30602060120w467a5bfer91e528d4232e56a1@mail.gmail.com> <220f68650602060136h1ea739b0n1bce6c15e48d7c45@mail.gmail.com> <1d987df30602060140t2186f3eel29d2eab572e5ca58@mail.gmail.com> <220f68650602061127v515abc2frc20068199a471143@mail.gmail.com> <618D3674-95E8-4636-9D59-18126A5DB815@redivi.com> <43E7AADB.4000507@noaa.gov> <1d987df30602162349w5f8502afu6b308a0b7853617e@mail.gmail.com> Message-ID: Linda, I'm a little confused about the difficulty you're having. Recent messages on this mailing list, particularly one from Larry Meyn on Feb 6, appear to have the usual solutions for setting the path. I suspect I know what the problem is, but might be way off because I'm not too sure what you've actually done and how your system is set-up. To shed a little light on what you have, and hopefully what's gone wrong, open a new Terminal window and paste in the following line: cd; ls -A; cat .*profile; ps; echo "$PATH"; which python2.4 Cut and paste the results into your reply. This should make clear exactly what shell you're using, what files you've already got to configure it and what their contents are, what your path currently looks like, and where your python2.4 is installed. -- Michael On Feb 17, 2006, at 7:49 AM, linda.s wrote: > Can anyone tell me how to build the path? > I still can not see my Python 2.4 appear. From dacresni at slu.edu Mon Feb 20 07:45:38 2006 From: dacresni at slu.edu (Nehemiah Dacres) Date: Mon, 20 Feb 2006 00:45:38 -0600 Subject: [Pythonmac-SIG] Fwd: python help In-Reply-To: <65fadfc30602162034j6d9f52d4y937e8366f6df1cc3@mail.gmail.com> References: <65fadfc30602162034j6d9f52d4y937e8366f6df1cc3@mail.gmail.com> Message-ID: <65fadfc30602192245s1b5976a2qc157f1ffa593482d@mail.gmail.com> Dear Python Help Group I am a student of Computer Science and i need help understanding how MacOS 10.4 (tiger) handles Python. the class I am in is "Intro to Object Oriented Programing" so they teach in python to reduce teaching of syntax so they can focus on O. Orientation. I need to import modules we create in class into my programs and i want to be able to do this as painlessly as possible per run. My first solution was to find where all the other third party modules are kept so i found "PyObjC" and there i found how to install the modules i needed for class. I got this to work and the terminal agreed, i ran homework from the terminal that day and they worked well. However lately I've been having problems. every sence then, ive been getting this error 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback and I really don't know what's going on. I know what PATH is and how to append it but my knowledge of unix stops at your tutorials in the tiger terminal, and that of Inside Mac (I never even got Fink and those X Droplets to work ) so I don't want to mess things up further than I already have. Recently (im certian it was a later date than when i changed that) Bittorrent stopped working. I ran it from withing the package and got this Last login: Thu Feb 16 20:52:55 on ttyp2 /Users/Username/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit Welcome to Darwin! adsl-70-130-208-110:~ Username$ /Users/Username/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "/Users/Username/Applications/BitTorrent.app/Contents/Resources/__main__.py", line 1, in ? import AppHelper File "./AppHelper.py", line 14, in ? File "./AppKit/__init__.py", line 8, in ? File "./AppKit/_AppKitSignatures.py", line 1, in ? File "./objc/__init__.py", line 20, in ? File "./objc/_convenience.py", line 21, in ? ImportError: No module named itertools 2006-02-16 21:02:44.085 BitTorrent[388] *** Uncaught exception: /Users/drue/wa/osx/main-embedded-interpreter.m:75 pyobjc_main() PyRun_SimpleFile failed with file '/Users/Username/Applications/BitTorrent.app/Contents/Resources/__main__.py'. See console for errors. Trace/BPT trap logout [Process completed] Most of that was greek to me but upon looking at the explanation the problem was clearly my python. (which was made even more obvious when looking at the resources folder: it seems Bittorent is a Python native app). This makes things even more dire because I've been using that program for my anime fix, it doesn't work for ANY account on the machine. the final change is that i found the location of the path in Extras.pth (/System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/python2.3) found that the last folder was just "python" instead of "python2.3" but after I remedied that, it still didn't work the situation is pretty bad but at least regular scripts work ( n=raw_input('enter the number up to which you want to take the product') n=int(n) k=raw_input('enter the number u want to skip') k=int(k) prod=1 for i in range (1,n+1,k): prod*=i print i print prod ) once with TextWrangler The terminal told me that it couldn't find the debugger file. i just found the file dbg.py and put it were the terminal said it was looking, and sence then i haven't gotten that message. Thank you, for your help python Student From ronaldoussoren at mac.com Mon Feb 20 18:56:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 20 Feb 2006 18:56:59 +0100 Subject: [Pythonmac-SIG] pythonw vs. python Message-ID: I've been thinking a little about pythonw vs. python. The former is needed because on OSX any API that needs a connection to the window server (anything that uses a native GUI and some other calls) need to be in an application bundle. pythonw is a program that can be placed anywhere on the PATH and exec's a normal python interpreter inside an application bundle. As of yesterday the python24-fat tree[1] will install a copy of pythonw as the normal python interpreter, that is both 'python' and 'pythonw' are the same program, the one that execs an interpreter inside an application bundle. This works, but at the cost of additional call to exec and therefore two application startups. I guess the additional cost should be lost in the noise, but the micro- optimizer in me isn't happy and especially so because everybody pays while almost nobody should need this feature. The common workaround for this is the undocumented function 'CPSEnableForegroundOperation'. Another workaround might be the TransformProcessType API introduced in OSX 10.3. Would it be worthwhile to look into these, or is it better to worry about other things instead. Ronald [1]: http://svn.pythonmac.org/python24/python24-fat From bob at redivi.com Mon Feb 20 19:51:58 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 20 Feb 2006 10:51:58 -0800 Subject: [Pythonmac-SIG] pythonw vs. python In-Reply-To: References: Message-ID: On Feb 20, 2006, at 9:56 AM, Ronald Oussoren wrote: > I've been thinking a little about pythonw vs. python. The former is > needed because on OSX any API that needs a connection to the window > server (anything that uses a native GUI and some other calls) need to > be in an application bundle. pythonw is a program that can be placed > anywhere on the PATH and exec's a normal python interpreter inside an > application bundle. > > As of yesterday the python24-fat tree[1] will install a copy of > pythonw as the normal python interpreter, that is both 'python' and > 'pythonw' are the same program, the one that execs an interpreter > inside an application bundle. This works, but at the cost of > additional call to exec and therefore two application startups. I > guess the additional cost should be lost in the noise, but the micro- > optimizer in me isn't happy and especially so because everybody pays > while almost nobody should need this feature. I'd rather eat the exec call than have to listen to endless drivel about these little differences between Mac OS X and other platforms. It shouldn't take very long to do that extra exec. I'm frankly VERY tired of the FAQs and would like to silence as many as possible with our next build, even if that means a little performance hit or a little extra deviation from python.org sources. In addition to this list, I also end up with personal email wrt MacPython, so this is an especially large nuisance for me. The people that absolutely need the performance wouldn't be starting Python ad infinitum anyway, they'd be using daemons and/or forking. If anything, higher startup cost encourages people to do the right thing ;) > The common workaround for this is the undocumented function > 'CPSEnableForegroundOperation'. Another workaround might be the > TransformProcessType API introduced in OSX 10.3. Would it be > worthwhile to look into these, or is it better to worry about other > things instead. The other reason not to do these things is that there's a lot of overhead to calling CPSEnableForegroundOperation and that it doesn't work after some amount of time. IIRC, TransformProcessType doesn't work for this purpose. I believe it still needs argv[0] to point inside of an application bundle. It might be useful in "fixing" a process where it has waited too long before CPSEnableForegroundOperation. I don't remember exactly, but the details aren't very interesting either way. The pythonw-everywhere solution is a lot easier and more reliable than making these changes to every library that makes Carbon or Cocoa calls. -bob From altern2 at gmail.com Mon Feb 20 20:49:30 2006 From: altern2 at gmail.com (altern) Date: Mon, 20 Feb 2006 20:49:30 +0100 Subject: [Pythonmac-SIG] python on tiger question Message-ID: <43FA1D4A.3080506@gmail.com> Hi all In a few weeks I will be giving some Python lectures and I am checking how to support students running Tiger. I don't run Tiger yet so I haven't gone trough the process of getting it to run on that system. In the workshop I would need to explain the students how to install it but also how to install properly packages such as pyOpenGL and pygame. I was wondering if following the instructions on this page http://bill.janssen.org/mac/new-macpython-page.html and downloading from the macpython packages download section the right packages for Tiger is enough or if there is anything else to configure. thanks -- enrike From bob at redivi.com Mon Feb 20 21:16:25 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 20 Feb 2006 12:16:25 -0800 Subject: [Pythonmac-SIG] python on tiger question In-Reply-To: <43FA1D4A.3080506@gmail.com> References: <43FA1D4A.3080506@gmail.com> Message-ID: <41AD8525-A707-4254-8714-9A226E20201D@redivi.com> On Feb 20, 2006, at 11:49 AM, altern wrote: > In a few weeks I will be giving some Python lectures and I am checking > how to support students running Tiger. I don't run Tiger yet so I > haven't gone trough the process of getting it to run on that system. > > In the workshop I would need to explain the students how to install it > but also how to install properly packages such as pyOpenGL and pygame. > > I was wondering if following the instructions on this page > http://bill.janssen.org/mac/new-macpython-page.html > and downloading from the macpython packages download section the right > packages for Tiger is enough or if there is anything else to > configure. Those instructions are sufficient. You can grab PyOpenGL and pygame from http://pythonmac.org/packages/ -- the Python 2.4 packages are easy to find since they're first. I think you'll need the following packages in order to properly bootstrap pygame: Numeric numarray PIL PyObjC PyOpenGL pygame -bob From keith.ray at gmail.com Mon Feb 20 22:05:33 2006 From: keith.ray at gmail.com (Keith Ray) Date: Mon, 20 Feb 2006 13:05:33 -0800 Subject: [Pythonmac-SIG] ascii <-> unicode <-> cocoa NSString Message-ID: <207ec7f00602201305j44e7770vc52c2f63ae74a799@mail.gmail.com> PyFIT gives me ascii strings,and I am trying to call cocoa (and eventually some applescript) functions from Python. I tried from Foundation import NSString from AppKit import NSWorkspace import os.path ....etc... ws = NSWorkspace.sharedWorkspace() uapplicationpath = unicode(self.applicationpath, 'ascii') self.launchsuccess = ws.launchApplication_( NSString.stringWithString_(uapplicationpath) ) but get a traceback: line 23, in result uapplicationpath = unicode(self.applicationpath, 'ascii') TypeError: decoding Unicode is not supported Help ? From bob at redivi.com Mon Feb 20 22:16:59 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 20 Feb 2006 13:16:59 -0800 Subject: [Pythonmac-SIG] ascii <-> unicode <-> cocoa NSString In-Reply-To: <207ec7f00602201305j44e7770vc52c2f63ae74a799@mail.gmail.com> References: <207ec7f00602201305j44e7770vc52c2f63ae74a799@mail.gmail.com> Message-ID: <545F533A-4702-4C62-A4E1-10BE3ABC24A5@redivi.com> On Feb 20, 2006, at 1:05 PM, Keith Ray wrote: > PyFIT gives me ascii strings,and I am trying to call cocoa (and > eventually some applescript) functions from Python. I tried > > from Foundation import NSString > from AppKit import NSWorkspace > import os.path > > ....etc... > > ws = NSWorkspace.sharedWorkspace() > uapplicationpath = unicode(self.applicationpath, 'ascii') > self.launchsuccess = ws.launchApplication_( > NSString.stringWithString_(uapplicationpath) ) > > but get a traceback: > > line 23, in result > uapplicationpath = unicode(self.applicationpath, 'ascii') > TypeError: decoding Unicode is not supported unicode(someUnicodeString, someEncoding) is always an error. You must already have a unicode string for self.applicationpath. $ python Python 2.4.2 (#2, Feb 4 2006, 22:23:07) [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> unicode(u'incorrect code', 'ascii') Traceback (most recent call last): File "", line 1, in ? TypeError: decoding Unicode is not supported -bob From ronaldoussoren at mac.com Mon Feb 20 22:22:00 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 20 Feb 2006 22:22:00 +0100 Subject: [Pythonmac-SIG] pythonw vs. python In-Reply-To: References: Message-ID: On 20-feb-2006, at 19:51, Bob Ippolito wrote: > > On Feb 20, 2006, at 9:56 AM, Ronald Oussoren wrote: > >> I've been thinking a little about pythonw vs. python. The former is >> needed because on OSX any API that needs a connection to the window >> server (anything that uses a native GUI and some other calls) need to >> be in an application bundle. pythonw is a program that can be placed >> anywhere on the PATH and exec's a normal python interpreter inside an >> application bundle. >> >> As of yesterday the python24-fat tree[1] will install a copy of >> pythonw as the normal python interpreter, that is both 'python' and >> 'pythonw' are the same program, the one that execs an interpreter >> inside an application bundle. This works, but at the cost of >> additional call to exec and therefore two application startups. I >> guess the additional cost should be lost in the noise, but the micro- >> optimizer in me isn't happy and especially so because everybody pays >> while almost nobody should need this feature. > > I'd rather eat the exec call than have to listen to endless drivel > about these little differences between Mac OS X and other > platforms. It shouldn't take very long to do that extra exec. I'm > frankly VERY tired of the FAQs and would like to silence as many as > possible with our next build, even if that means a little > performance hit or a little extra deviation from python.org > sources. In addition to this list, I also end up with personal > email wrt MacPython, so this is an especially large nuisance for me. I agree that python and pythonw should both work for GUI code, it is something we can take care of and something new users keep running into. This is one issue where we really could blame Apple, but that doesn't help us very much. Annoyingly RTFM doesn't help a lot, nobody seems to read documentation ;-( > > The people that absolutely need the performance wouldn't be > starting Python ad infinitum anyway, they'd be using daemons and/or > forking. If anything, higher startup cost encourages people to do > the right thing ;) I don't care for higher startup costs for GUI scripts, those should use py2app anyway. Plain boring unix scripts worry me a bit more. But even there the startup cost should be neglectibable when compared with the total runtime. Luckily the new pythonw is a C program, which means the overhead is even smaller than it is in the current MacPython release. > >> The common workaround for this is the undocumented function >> 'CPSEnableForegroundOperation'. Another workaround might be the >> TransformProcessType API introduced in OSX 10.3. Would it be >> worthwhile to look into these, or is it better to worry about other >> things instead. > > The other reason not to do these things is that there's a lot of > overhead to calling CPSEnableForegroundOperation and that it > doesn't work after some amount of time. IIRC, TransformProcessType > doesn't work for this purpose. I believe it still needs argv[0] to > point inside of an application bundle. It might be useful in > "fixing" a process where it has waited too long before > CPSEnableForegroundOperation. I don't remember exactly, but the > details aren't very interesting either way. > > The pythonw-everywhere solution is a lot easier and more reliable > than making these changes to every library that makes Carbon or > Cocoa calls. If calling CPSEnableForegroundOperation or TransformProcessType at the start of Py_Main doesn't help I'm not interested. I'm convinced: I'm happy with the current python24-fat tree where python and pythonw are the same program. Ronald From ronaldoussoren at mac.com Mon Feb 20 22:28:33 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 20 Feb 2006 22:28:33 +0100 Subject: [Pythonmac-SIG] ascii <-> unicode <-> cocoa NSString In-Reply-To: <207ec7f00602201305j44e7770vc52c2f63ae74a799@mail.gmail.com> References: <207ec7f00602201305j44e7770vc52c2f63ae74a799@mail.gmail.com> Message-ID: <64D8C4FE-7638-4197-885E-D03C5A445ED4@mac.com> On 20-feb-2006, at 22:05, Keith Ray wrote: > PyFIT gives me ascii strings,and I am trying to call cocoa (and > eventually some applescript) functions from Python. I tried > > from Foundation import NSString > from AppKit import NSWorkspace > import os.path > > ....etc... > > ws = NSWorkspace.sharedWorkspace() > uapplicationpath = unicode(self.applicationpath, 'ascii') > self.launchsuccess = ws.launchApplication_( > NSString.stringWithString_(uapplicationpath) ) > > but get a traceback: > > line 23, in result > uapplicationpath = unicode(self.applicationpath, 'ascii') > TypeError: decoding Unicode is not supported What is self.applicationpath? The error seems to indicate that it already is a unicode string. Ronald > > Help ? > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Mon Feb 20 22:47:21 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 20 Feb 2006 13:47:21 -0800 Subject: [Pythonmac-SIG] pythonw vs. python In-Reply-To: References: Message-ID: On Feb 20, 2006, at 1:22 PM, Ronald Oussoren wrote: > > On 20-feb-2006, at 19:51, Bob Ippolito wrote: > >> >> On Feb 20, 2006, at 9:56 AM, Ronald Oussoren wrote: >> >>> I've been thinking a little about pythonw vs. python. The former is >>> needed because on OSX any API that needs a connection to the window >>> server (anything that uses a native GUI and some other calls) >>> need to >>> be in an application bundle. pythonw is a program that can be placed >>> anywhere on the PATH and exec's a normal python interpreter >>> inside an >>> application bundle. >>> >>> As of yesterday the python24-fat tree[1] will install a copy of >>> pythonw as the normal python interpreter, that is both 'python' and >>> 'pythonw' are the same program, the one that execs an interpreter >>> inside an application bundle. This works, but at the cost of >>> additional call to exec and therefore two application startups. I >>> guess the additional cost should be lost in the noise, but the >>> micro- >>> optimizer in me isn't happy and especially so because everybody pays >>> while almost nobody should need this feature. >> >> I'd rather eat the exec call than have to listen to endless drivel >> about these little differences between Mac OS X and other >> platforms. It shouldn't take very long to do that extra exec. >> I'm frankly VERY tired of the FAQs and would like to silence as >> many as possible with our next build, even if that means a little >> performance hit or a little extra deviation from python.org >> sources. In addition to this list, I also end up with personal >> email wrt MacPython, so this is an especially large nuisance for me. > > I agree that python and pythonw should both work for GUI code, it > is something we can take care of and something new users keep > running into. This is one issue where we really could blame Apple, > but that doesn't help us very much. Annoyingly RTFM doesn't help a > lot, nobody seems to read documentation ;-( Yeah, I've wanted this issue fixed since the beginning. They really screwed this up, and haven't done a damn thing to fix it over the past 7 years or so. Nothing we can do about that, though. >> The people that absolutely need the performance wouldn't be >> starting Python ad infinitum anyway, they'd be using daemons and/ >> or forking. If anything, higher startup cost encourages people to >> do the right thing ;) > > I don't care for higher startup costs for GUI scripts, those should > use py2app anyway. Plain boring unix scripts worry me a bit more. > But even there the startup cost should be neglectibable when > compared with the total runtime. Luckily the new pythonw is a C > program, which means the overhead is even smaller than it is in the > current MacPython release. execv should be fast, and the startup of pythonw should be totally negligible. >>> The common workaround for this is the undocumented function >>> 'CPSEnableForegroundOperation'. Another workaround might be the >>> TransformProcessType API introduced in OSX 10.3. Would it be >>> worthwhile to look into these, or is it better to worry about other >>> things instead. >> >> The other reason not to do these things is that there's a lot of >> overhead to calling CPSEnableForegroundOperation and that it >> doesn't work after some amount of time. IIRC, >> TransformProcessType doesn't work for this purpose. I believe it >> still needs argv[0] to point inside of an application bundle. It >> might be useful in "fixing" a process where it has waited too long >> before CPSEnableForegroundOperation. I don't remember exactly, >> but the details aren't very interesting either way. >> >> The pythonw-everywhere solution is a lot easier and more reliable >> than making these changes to every library that makes Carbon or >> Cocoa calls. > > If calling CPSEnableForegroundOperation or TransformProcessType at > the start of Py_Main doesn't help I'm not interested. I'm > convinced: I'm happy with the current python24-fat tree where > python and pythonw are the same program. Calling them at the start of Py_Main would likely work, but it can make the code hang for a ridiculously long time (on the order of several seconds) in my experience. Not acceptable. The execv is an acceptable hit, but this is not. -bob From dave.opstad at monotypeimaging.com Mon Feb 20 22:37:07 2006 From: dave.opstad at monotypeimaging.com (Opstad, Dave) Date: Mon, 20 Feb 2006 16:37:07 -0500 Subject: [Pythonmac-SIG] ascii <-> unicode <-> cocoa NSString In-Reply-To: <207ec7f00602201305j44e7770vc52c2f63ae74a799@mail.gmail.com> Message-ID: On 2/20/06 1:05 PM, "Keith Ray" wrote: > Help ? You encode from Unicode, and decode to Unicode: >>> 'hi there'.decode('ascii') u'hi there' >>> u'hi there'.encode('ascii') 'hi there' Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060220/eadbe5f4/attachment.html From janssen at parc.com Mon Feb 20 23:12:54 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 20 Feb 2006 14:12:54 PST Subject: [Pythonmac-SIG] python on tiger question In-Reply-To: Your message of "Mon, 20 Feb 2006 11:49:30 PST." <43FA1D4A.3080506@gmail.com> Message-ID: <06Feb20.141301pst."58633"@synergy1.parc.xerox.com> > I was wondering if following the instructions on this page > http://bill.janssen.org/mac/new-macpython-page.html Clearly past time to move this to python.org :-). I'll take care of that. Bill From keith.ray at gmail.com Mon Feb 20 23:35:52 2006 From: keith.ray at gmail.com (Keith Ray) Date: Mon, 20 Feb 2006 14:35:52 -0800 Subject: [Pythonmac-SIG] appscript Message-ID: <207ec7f00602201435q77d57761o6d90018fd203b44e@mail.gmail.com> I'm trying to use python/appscript to send apply-events to a cocoa application, but it seems to be choking on parsing the aete... possibly because the aeta has been replaced by 'sdef' for holding scripting terminology. help? Traceback (most recent call last): File "/fitEtc/PyFIT/fit/fit/TypeAdapter.py", line 758, in _compareCellToResult result = self.get() File "/fitEtc/PyFIT/fit/fit/TypeAdapter.py", line 901, in get return self.method(self.target) File "/fitEtc/quickbooks_tests/test_my_automation/verify_company_file.py", line 28, in result app(self.applicationpath).open(File(self.filename)) File "/Library/Python/2.3/site-packages/appscript/specifier.py", line 392, in __init__ translationTables = tablesForLocalApp(path) File "/Library/Python/2.3/site-packages/appscript/translationtablereader.py", line 140, in tablesForLocalApp classes, enums, properties, elements, commands = buildTables(path) File "/Library/Python/2.3/site-packages/appscript/translationtablebuilder.py", line 98, in buildTables aeteparser.parse(getaete(path), p) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/osaterminology/aeteparser.py", line 254, in parse a.list(_parseSuite, receiver) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/osaterminology/aeteparser.py", line 64, in list fn(self, receiver) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/osaterminology/aeteparser.py", line 182, in _parseSuite aete.list(fn, receiver) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/osaterminology/aeteparser.py", line 64, in list fn(self, receiver) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/osaterminology/aeteparser.py", line 150, in _parseComparison description = aete.string() File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/osaterminology/aeteparser.py", line 48, in string count = ord(self._str[self._ptr]) IndexError: string index out of range ------ from fit.ColumnFixture import ColumnFixture from Foundation import NSString from AppKit import NSWorkspace import os.path from appscript import * from macfile import * class verify_company_file(ColumnFixture): _typeDict={ "filename": "String", "applicationpath": "String", "result": "String", } filename = "" applicationpath = "" launchsuccess = 0 def result(self): ws = NSWorkspace.sharedWorkspace() ws.launchApplication_( self.applicationpath ) app(self.applicationpath).open(File(self.filename)) return None -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060220/75ef7dcd/attachment.htm From bob at redivi.com Tue Feb 21 00:37:22 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 20 Feb 2006 15:37:22 -0800 Subject: [Pythonmac-SIG] appscript In-Reply-To: <207ec7f00602201435q77d57761o6d90018fd203b44e@mail.gmail.com> References: <207ec7f00602201435q77d57761o6d90018fd203b44e@mail.gmail.com> Message-ID: <4960A4F8-6F46-4408-AF0F-3E89CDB37D03@redivi.com> On Feb 20, 2006, at 2:35 PM, Keith Ray wrote: > I'm trying to use python/appscript to send apply-events to a cocoa > application, but it seems to be choking on parsing the aete... > possibly because the aeta has been replaced by 'sdef' for holding > scripting terminology. If all you want to do is open a file then you're far better off using NSWorkspace.sharedWorkspace().openFile_withApplication_ (self.filename, self.applicationpath). -bob From ronaldoussoren at mac.com Tue Feb 21 06:52:57 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 21 Feb 2006 06:52:57 +0100 Subject: [Pythonmac-SIG] appscript In-Reply-To: <207ec7f00602201435q77d57761o6d90018fd203b44e@mail.gmail.com> References: <207ec7f00602201435q77d57761o6d90018fd203b44e@mail.gmail.com> Message-ID: On 20-feb-2006, at 23:35, Keith Ray wrote: > I'm trying to use python/appscript to send apply-events to a cocoa > application, but it seems to be choking on parsing the aete... > possibly because the aeta has been replaced by 'sdef' for holding > scripting terminology. > > help? What happens if you create a small python script that contains something like: from appscript import * myapp = app("LocalApp") myapp.open(File("filename")) And likewise, what happens if you type 'open -a LocalApp filename' in the shell (also look in the console log with Console.app). In both cases replace LocalApp and filename by the real names. And finally, what versions of PyObjC and appscript are you using? Ronald > Traceback (most recent call last): > File "/fitEtc/PyFIT/fit/fit/TypeAdapter.py", line 758, in > _compareCellToResult > result = self.get() > File "/fitEtc/PyFIT/fit/fit/TypeAdapter.py", line 901, in get > return self.method(self.target) > File "/fitEtc/quickbooks_tests/test_my_automation/ > verify_company_file.py", line 28, in result > app(self.applicationpath).open(File(self.filename)) > File "/Library/Python/2.3/site-packages/appscript/specifier.py", > line 392, in __init__ > translationTables = tablesForLocalApp(path) > File "/Library/Python/2.3/site-packages/appscript/ > translationtablereader.py", line 140, in tablesForLocalApp > classes, enums, properties, elements, commands = buildTables(path) > File "/Library/Python/2.3/site-packages/appscript/ > translationtablebuilder.py", line 98, in buildTables > aeteparser.parse(getaete(path), p) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/osaterminology/aeteparser.py", line 254, in > parse > a.list(_parseSuite, receiver) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/osaterminology/aeteparser.py", line 64, in > list > fn(self, receiver) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/osaterminology/aeteparser.py", line 182, in > _parseSuite > aete.list(fn, receiver) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/osaterminology/aeteparser.py", line 64, in > list > fn(self, receiver) > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/osaterminology/aeteparser.py", line 150, in > _parseComparison > description = aete.string () > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/osaterminology/aeteparser.py", line 48, in > string > count = ord(self._str[self._ptr]) > > > IndexError: string index out of range ------ > > from fit.ColumnFixture import ColumnFixture > > from Foundation import NSString > from AppKit import NSWorkspace > import os.path > from appscript import * > from macfile import * > > class verify_company_file(ColumnFixture): > _typeDict={ > "filename": "String", > "applicationpath": "String", > "result": "String", > } > filename = "" > applicationpath = "" > launchsuccess = 0 > def result(self): > ws = NSWorkspace.sharedWorkspace() > ws.launchApplication_( self.applicationpath ) > app(self.applicationpath).open(File(self.filename)) > return None > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From sw at wordtech-software.com Wed Feb 22 00:01:28 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue, 21 Feb 2006 18:01:28 -0500 Subject: [Pythonmac-SIG] Tcl/Tk universal binary Message-ID: <43FB9BC8.8080202@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In case anyone plans to deploy a Tkinter application once the universal build of Python is ready, I've packaged up a universal build of Tcl/Tk Aqua. You can get the particulars at http://www.wordtech-software.com/tcl-tk-universal.html. Thanks, Kevin - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD+5vIJmdQs+6YVcoRAnmkAKCGn7dcQmjetdYNZtm2KPfMsSKS3ACeNS5S QU8w3vy+eVxKgcUGx/86MHM= =Uc7f -----END PGP SIGNATURE----- From keith.ray at gmail.com Wed Feb 22 01:13:12 2006 From: keith.ray at gmail.com (Keith Ray) Date: Tue, 21 Feb 2006 16:13:12 -0800 Subject: [Pythonmac-SIG] appscript In-Reply-To: References: <207ec7f00602201435q77d57761o6d90018fd203b44e@mail.gmail.com> Message-ID: <207ec7f00602211613i39c8a40fv6bc1168af293d847@mail.gmail.com> just adding one thing to the "sdef" file (created by Apple's Script Editor and edited with 'Sdef Editor") seems to be the problem -- Script Editor can't access the new thing either tell app "myapp" doFoo "test" -- fails end tell names copied off the installers: pyobjc-1.3.7-py2.3-macosx10.4 Appscript-Installer-1.2 On 2/20/06, Ronald Oussoren wrote: > > On 20-feb-2006, at 23:35, Keith Ray wrote: > > > I'm trying to use python/appscript to send apply-events to a cocoa > > application, but it seems to be choking on parsing the aete... > > possibly because the aeta has been replaced by 'sdef' for holding > > scripting terminology. > > > > help? > > What happens if you create a small python script that contains > something like: > > from appscript import * > > myapp = app("LocalApp") > myapp.open(File("filename")) > > And likewise, what happens if you type 'open -a LocalApp filename' in > the shell (also look in the console log with Console.app). In both > cases replace LocalApp and filename by the real names. > > And finally, what versions of PyObjC and appscript are you using? > > Ronald > > > > Traceback (most recent call last): > > File "/fitEtc/PyFIT/fit/fit/TypeAdapter.py", line 758, in > > _compareCellToResult > > result = self.get() > > File "/fitEtc/PyFIT/fit/fit/TypeAdapter.py", line 901, in get > > return self.method(self.target) > > File "/fitEtc/quickbooks_tests/test_my_automation/ > > verify_company_file.py", line 28, in result > > app(self.applicationpath).open(File(self.filename)) > > File "/Library/Python/2.3/site-packages/appscript/specifier.py", > > line 392, in __init__ > > translationTables = tablesForLocalApp(path) > > File "/Library/Python/2.3/site-packages/appscript/ > > translationtablereader.py", line 140, in tablesForLocalApp > > classes, enums, properties, elements, commands = buildTables(path) > > File "/Library/Python/2.3/site-packages/appscript/ > > translationtablebuilder.py", line 98, in buildTables > > aeteparser.parse(getaete(path), p) > > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > > python2.3/site-packages/osaterminology/aeteparser.py", line 254, in > > parse > > a.list(_parseSuite, receiver) > > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > > python2.3/site-packages/osaterminology/aeteparser.py", line 64, in > > list > > fn(self, receiver) > > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > > python2.3/site-packages/osaterminology/aeteparser.py", line 182, in > > _parseSuite > > aete.list(fn, receiver) > > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > > python2.3/site-packages/osaterminology/aeteparser.py", line 64, in > > list > > fn(self, receiver) > > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > > python2.3/site-packages/osaterminology/aeteparser.py", line 150, in > > _parseComparison > > description = aete.string () > > File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > > python2.3/site-packages/osaterminology/aeteparser.py", line 48, in > > string > > count = ord(self._str[self._ptr]) > > > > > > IndexError: string index out of range ------ > > > > from fit.ColumnFixture import ColumnFixture > > > > from Foundation import NSString > > from AppKit import NSWorkspace > > import os.path > > from appscript import * > > from macfile import * > > > > class verify_company_file(ColumnFixture): > > _typeDict={ > > "filename": "String", > > "applicationpath": "String", > > "result": "String", > > } > > filename = "" > > applicationpath = "" > > launchsuccess = 0 > > def result(self): > > ws = NSWorkspace.sharedWorkspace() > > ws.launchApplication_( self.applicationpath ) > > app(self.applicationpath).open(File(self.filename)) > > return None > > > > > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > -- C. Keith Ray From janssen at parc.com Thu Feb 23 04:53:48 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 22 Feb 2006 19:53:48 PST Subject: [Pythonmac-SIG] Download page on www.python.org now updated Message-ID: <06Feb22.195357pst."58633"@synergy1.parc.xerox.com> OK, the new downloads page is now in place on python.org, at http://www.python.org/download/download_mac.html. Thanks to Skip for moving the bits! Bill > > I was wondering if following the instructions on this page > > http://bill.janssen.org/mac/new-macpython-page.html > > Clearly past time to move this to python.org :-). I'll take care of > that. > > Bill From rowen at cesmail.net Thu Feb 23 20:19:11 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Thu, 23 Feb 2006 11:19:11 -0800 Subject: [Pythonmac-SIG] Download page on www.python.org now updated References: <06Feb22.195357pst."58633"@synergy1.parc.xerox.com> Message-ID: In article <06Feb22.195357pst."58633"@synergy1.parc.xerox.com>, Bill Janssen wrote: > OK, the new downloads page is now in place on python.org, at > http://www.python.org/download/download_mac.html. > > Thanks to Skip for moving the bits! Thanks for doing this. One suggestion: have users install Tcl/Tk 8.4.12 or at least 8.4.11 rather than 8.4.10. 8.4.11 is, in my opinion, the first really solid version of Aqua Tcl/Tk -- it fixed two bugs that were driving me nuts -- and 8.4.12 has been working fine for me. Here's a link to 8.4.12: -- Russell P.S. the sourceforge Tcl/Tk Aqua project has not been updated past 8.4.10. Anyone know if it ever will be, now that ActiveState is supplying installers? From rowen at cesmail.net Fri Feb 24 00:26:22 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Thu, 23 Feb 2006 15:26:22 -0800 Subject: [Pythonmac-SIG] Binary packages for numarray 1.5.1 and Numeric 24.2 Message-ID: I made binary distributions of the current versions of numarray and Numeric for MacOS 10.3+ and Python 2.4. They are here: . They pass their self-tests, except Numeric fails one test (identically whether installed from source or the package, so I suspect the test is broken). I hope somebody will put these on the python website. (If so, let me know and I'll take them down from the ftp site above). Overall I was blown away by how easy py2app made this process. However, I did run into a few issues: 1) I could not build packages for the built-in python 2.3. What I tried (among other things): - Install py2app from py2app-0.2-py2.3-macosx10.3.mpkg - Run bdist_mpkg. It fails with: ... File "/Library/Python/2.3/py2app/py2app/build_app.py", line 24, in ? import macholib.MachOStandalone ImportError: No module named MachOStandalone - I also tried modifying setup.py to import bdist_mpkg, but then python setup.py mpkg_bdist fails in the same way (while importing mpkg_bdist). This is no big deal to me, since I use Python 2.4, but if somebody can explain how to work around this, I'd be happy to supply packages for 2.3 as well. 2) Can I make the two py2apps (for python 2.4 and 2.3) coexist by renaming one set of binaries in /usr/local/bin, or might there be other subtle conflicts? (It would have been easy enough to try this myself, except for the first problem). 3) I tried to use bdist_mpkg to bundle Numeric 24.2 and got this error: AssertionError: distutils has already been patched by However, modifying setup.py to import bdist_mpkg and using python setup.py bdist_mpkg worked fine. -- Russell From janssen at parc.com Fri Feb 24 00:50:03 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 23 Feb 2006 15:50:03 PST Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: Your message of "Thu, 23 Feb 2006 11:19:11 PST." Message-ID: <06Feb23.155011pst."58633"@synergy1.parc.xerox.com> > One suggestion: have users install Tcl/Tk 8.4.12 or at least 8.4.11 > rather than 8.4.10. 8.4.11 is, in my opinion, the first really solid > version of Aqua Tcl/Tk -- it fixed two bugs that were driving me nuts -- > and 8.4.12 has been working fine for me. > > Here's a link to 8.4.12: > .0.227020-macosx-powerpc-threaded.dmg> I'm happy to update the page if this now reflects the conventional wisdom... Remember that we are just using this for IDLE. > P.S. the sourceforge Tcl/Tk Aqua project has not been updated past > 8.4.10. Anyone know if it ever will be, now that ActiveState is > supplying installers? I never use it, so I'd be the last to know. Bill From gandreas at gandreas.com Fri Feb 24 01:51:40 2006 From: gandreas at gandreas.com (gandreas at gandreas.com) Date: Thu, 23 Feb 2006 18:51:40 -0600 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.2 Message-ID: <31BE1E0A-9F35-45FB-9402-9A4385BE77EF@gandreas.com> So in an attempt to finally get rid of the potential morass that further work on PyOXIDE could be, I'm release a very early version of ScrIDE, a generic, extensible, scripting IDE. There are several major differences between the two - first, ScrIDE is designed to support multiple scripting languages, and to be able to do that, the second different is that _everything_ is run in separate processes, which means that you can easily select from different versions of python (or even easily pick between python and pythonw). Finally, it is highly extensible (all sorts of things controlled by various property lists which can be overridden and extended, including adding menu commands that pipe text to/from other processes). The debugger currently does not support breakpoints (but stepping, examination after exceptions, console commands "in context", etc... work), and some of the other browsing/introspection capabilities of PyOXIDE aren't present either yet (though you can get doc strings for simple objects). Still, it is able to do things like step through tkinter programs, for example... Glenn Andreas gandreas at gandreas.com wicked fun! Dominogy | Just place all the dominos on the board... From janssen at parc.com Fri Feb 24 02:18:29 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 23 Feb 2006 17:18:29 PST Subject: [Pythonmac-SIG] ANN: ScrIDE 0.2 In-Reply-To: Your message of "Thu, 23 Feb 2006 16:51:40 PST." <31BE1E0A-9F35-45FB-9402-9A4385BE77EF@gandreas.com> Message-ID: <06Feb23.171831pst."58633"@synergy1.parc.xerox.com> A thread viewer/inspector would be a really nice addition. Bill > So in an attempt to finally get rid of the potential morass that > further work on PyOXIDE could be, I'm release a very early version of > ScrIDE, a generic, extensible, scripting IDE. There are several > major differences between the two - first, ScrIDE is designed to > support multiple scripting languages, and to be able to do that, the > second different is that _everything_ is run in separate processes, > which means that you can easily select from different versions of > python (or even easily pick between python and pythonw). Finally, it > is highly extensible (all sorts of things controlled by various > property lists which can be overridden and extended, including adding > menu commands that pipe text to/from other processes). > > The debugger currently does not support breakpoints (but stepping, > examination after exceptions, console commands "in context", etc... > work), and some of the other browsing/introspection capabilities of > PyOXIDE aren't present either yet (though you can get doc strings for > simple objects). Still, it is able to do things like step through > tkinter programs, for example... > > > From vivacarlie at gmail.com Fri Feb 24 06:40:35 2006 From: vivacarlie at gmail.com (Nehemiah I.Dacres) Date: Thu, 23 Feb 2006 23:40:35 -0600 Subject: [Pythonmac-SIG] I may have wrecked my python Message-ID: <6E0D8C81-977B-4B79-8C57-8994CCC4BFDB@gmail.com> I am a student of Computer Science and i need help understanding how MacOSX handles Python. the class I am in is "Intro to Object Oriented Programing" so they teach in python to reduce teaching of syntax so they can focus on O. Orientation. I need to import modules we create in class into my programs and i want to be able to do this as painlessly as possible per run. My first solution was to find where all the other third party modules are kept so i found "PyObjC" and there i found how to install the modules i needed for class. I got this to work and the terminal agreed however lately I've been having problems. every sence then, ive been getting this error 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback and I really don't know what's going on. I know what PATH is and how to append it but my knowledge of unix stops at your tutorials in the tiger terminal, and that of Inside Mac (I never even got Fink and those X Droplets to work ) so I don't want to mess things up further than I already have. Recently (im certian it was a later date than when i changed that) Bittorrent stopped working. I ran it from withing the package and got this Last login: Thu Feb 16 20:52:55 on ttyp2 /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/ BitTorrent; exit Welcome to Darwin! adsl-70-130-208-110:~ Nehemiah$ /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "/Users/Nehemiah/Applications/BitTorrent.app/Contents/ Resources/__main__.py", line 1, in ? import AppHelper File "./AppHelper.py", line 14, in ? File "./AppKit/__init__.py", line 8, in ? File "./AppKit/_AppKitSignatures.py", line 1, in ? File "./objc/__init__.py", line 20, in ? File "./objc/_convenience.py", line 21, in ? ImportError: No module named itertools 2006-02-16 21:02:44.085 BitTorrent[388] *** Uncaught exception: /Users/drue/wa/osx/main-embedded-interpreter.m:75 pyobjc_main() PyRun_SimpleFile failed with file '/Users/Nehemiah/Applications/BitTorrent.app/Contents/Resources/ __main__.py'. See console for errors. Trace/BPT trap logout [Process completed] Most of that was greek to me but upon looking at the explanation the problem was clearly my python. (which was made even more obvious when looking at the resources folder: it seems Bittorent is a Python native app). This makes things even more dire because I've been using that program for my anime fix, it doesn't work for ANY account on the machine. the final change is that i found the location of the path in Extras.pth (/System/Library/Frameworks/Python.framework/Versions/2.3/ Extras/lib/python2.3) found that the last folder was just "python" instead of "python2.3" but after I remedied that, it still didn't work the situation is pretty bad but at least regular scripts work ( n=raw_input('enter the number up to which you want to take the product') n=int(n) k=raw_input('enter the number u want to skip') k=int(k) prod=1 for i in range (1,n+1,k): prod*=i print i print prod ) once with TextWrangler The terminal told me that it couldn't find the debugger file. i just found the file dbg.py and put it were the terminal said it was looking, and sence then i haven't gotten that message. Thank you, for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060223/9e2d34d6/attachment-0001.html From ryanwilcox at mac.com Fri Feb 24 16:40:40 2006 From: ryanwilcox at mac.com (Ryan Wilcox) Date: Fri, 24 Feb 2006 10:40:40 -0500 Subject: [Pythonmac-SIG] [py2app] building on 10.4 for 10.3? Message-ID: Hi guys, Can I build apps, using py2app on 10.4, that run on OS X 10.3 also? I know in the past the answer has been "maybe", but I wonder if that has changed with some of the new cross-development stuff in XCode 2.1+. I don't use any python extensions (well, beyond pyobjc), just one NSBundle that I load up when I need to execute C code. (Of course I would be using a non-system Python 2.4, and that's part of the project too, getting that up. Any specific recommendations/gottchas on that would be appreciated.) Thanks very much, _Ryan Wilcox -- Wilcox Development Solutions: Toolsmiths for the Internet Age PGP: 0x2F4E9C31 From bob at redivi.com Fri Feb 24 19:04:32 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 24 Feb 2006 12:04:32 -0600 Subject: [Pythonmac-SIG] [py2app] building on 10.4 for 10.3? In-Reply-To: References: Message-ID: <05BF2C73-DDEA-4783-95FB-F54463C2EB46@redivi.com> On Feb 24, 2006, at 9:40 AM, Ryan Wilcox wrote: > Can I build apps, using py2app on 10.4, that run on OS X 10.3 also? > I know in the past the answer has been "maybe", but I wonder if > that has changed with some of the new cross-development stuff in > XCode 2.1+. > > I don't use any python extensions (well, beyond pyobjc), just one > NSBundle that I load up when I need to execute C code. > > (Of course I would be using a non-system Python 2.4, and that's > part of the project too, getting that up. Any specific > recommendations/gottchas on that would be appreciated.) The answer has always been "yes, if everything you're using was built on 10.3"... the maybe is if you've built parts of it elsewhere. If you're just using PyObjC, make sure you have the 10.3 version installed and everything should work out fine. -bob From vivacarlie at gmail.com Sat Feb 25 07:32:17 2006 From: vivacarlie at gmail.com (Nehemiah Dacres) Date: Sat, 25 Feb 2006 00:32:17 -0600 Subject: [Pythonmac-SIG] Fwd: I may have wrecked my python In-Reply-To: <6E0D8C81-977B-4B79-8C57-8994CCC4BFDB@gmail.com> References: <6E0D8C81-977B-4B79-8C57-8994CCC4BFDB@gmail.com> Message-ID: <65fadfc30602242232n31038159mbbb3c8650037f2a6@mail.gmail.com> From: Nehemiah I. Dacres Date: Feb 23, 2006 11:40 PM Subject: I may have wrecked my python To: pythonmac-sig at python.org I am a student of Computer Science and i need help understanding how MacOSX handles Python. the class I am in is "Intro to Object Oriented Programing" so they teach in python to reduce teaching of syntax so they can focus on O. Orientation. I need to import modules we create in class into my programs and i want to be able to do this as painlessly as possible per run. My first solution was to find where all the other third party modules are kept so i found "PyObjC" and there i found how to install the modules i needed for class. I got this to work and the terminal agreed however lately I've been having problems. every sence then, ive been getting this error 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback and I really don't know what's going on. I know what PATH is and how to append it but my knowledge of unix stops at your tutorials in the tiger terminal, and that of Inside Mac (I never even got Fink and those X Droplets to work ) so I don't want to mess things up further than I already have. Recently (im certian it was a later date than when i changed that) Bittorrent stopped working. I ran it from withing the package and got this Last login: Thu Feb 16 20:52:55 on ttyp2 /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit Welcome to Darwin! adsl-70-130-208-110:~ Nehemiah$ /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "/Users/Nehemiah/Applications/BitTorrent.app/Contents/Resources/__main__.py", line 1, in ? import AppHelper File "./AppHelper.py", line 14, in ? File "./AppKit/__init__.py", line 8, in ? File "./AppKit/_AppKitSignatures.py", line 1, in ? File "./objc/__init__.py", line 20, in ? File "./objc/_convenience.py", line 21, in ? ImportError: No module named itertools 2006-02-16 21:02:44.085 BitTorrent[388] *** Uncaught exception: /Users/drue/wa/osx/main-embedded-interpreter.m:75 pyobjc_main() PyRun_SimpleFile failed with file '/Users/Nehemiah/Applications/BitTorrent.app/Contents/Resources/__main__.py'. See console for errors. Trace/BPT trap logout [Process completed] Most of that was greek to me but upon looking at the explanation the problem was clearly my python. (which was made even more obvious when looking at the resources folder: it seems Bittorent is a Python native app). This makes things even more dire because I've been using that program for my anime fix, it doesn't work for ANY account on the machine. the final change is that i found the location of the path in Extras.pth (/System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/python2.3) found that the last folder was just "python" instead of "python2.3" but after I remedied that, it still didn't work the situation is pretty bad but at least regular scripts work ( n=raw_input('enter the number up to which you want to take the product') n=int(n) k=raw_input('enter the number u want to skip') k=int(k) prod=1 for i in range (1,n+1,k): prod*=i print i print prod ) once with TextWrangler The terminal told me that it couldn't find the debugger file. i just found the file dbg.py and put it were the terminal said it was looking, and sence then i haven't gotten that message. Thank you, for your help From rsfinn at gmail.com Sat Feb 25 16:29:38 2006 From: rsfinn at gmail.com (Russell Finn) Date: Sat, 25 Feb 2006 09:29:38 -0600 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <-8253693222388543502@unknownmsgid> References: <-8253693222388543502@unknownmsgid> Message-ID: On 2/22/06, Bill Janssen wrote: > OK, the new downloads page is now in place on python.org, at > http://www.python.org/download/download_mac.html. > > Thanks to Skip for moving the bits! Congratulations all around... Guido has just announced (at his PyCon keynote) that the new web site (see beta.python.org) is going live a week from tomorrow (or Sunday, March 5), and has requested help migrating the content. I just checked and of course the "old" Macintosh content is present on the beta site (as well as an unfortunate item on the main download page indicating that only 2.3 is available for download on Mac OS X). There is info at on how to contribute to the new site. It looks like the content is stored in a subversion repository. Hopefully someone can handle this before the new site goes live. (If I can help, let me know...) -- Russell Finn From wgscott at chemistry.ucsc.edu Sat Feb 25 18:27:25 2006 From: wgscott at chemistry.ucsc.edu (William Scott) Date: Sat, 25 Feb 2006 09:27:25 -0800 Subject: [Pythonmac-SIG] Python 2.4.2 on Mac OS X 10.4.5: aquaTk GUI problem since 2.4.1 Message-ID: <54F48FBC-8671-4427-9A4F-FEB1CC311D8C@chemistry.ucsc.edu> Hi Folks: This is my first question here. I recently upgraded my Framework install of python. I can verify that the aqua version of Tkinter still works, using a "Hello" test button, and I can run the Pmw demos. The problem arises now with a more complicated program: pymol. This is an x-windows-based program with a pwm menu. When I start it, I now get the error: Tk_MacOSXSetupTkNotifier: first [load] of TkAqua has to occur in the main thread! I understand the limitations with the aqua Tk and multi-threading, but this works absolutely fine with Python2.4.1 and earlier. Is there some way to over-ride this protection mechanism (apart from regressing to 2.4.1)? Thanks. Bill Scott From skip at pobox.com Sat Feb 25 20:47:38 2006 From: skip at pobox.com (skip at pobox.com) Date: Sat, 25 Feb 2006 13:47:38 -0600 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: References: <-8253693222388543502@unknownmsgid> Message-ID: <17408.46170.7692.61943@montanaro.dyndns.org> Russell> I just checked and of course the "old" Macintosh content is Russell> present on the beta site (as well as an unfortunate item on the Russell> main download page indicating that only 2.3 is available for Russell> download on Mac OS X). Yeah, I plan to take care of that as well, just haven't had the chance. At the moment I'm trying to get the pyramid stuff working. Tim Parkin is helping me via the net. Once I've either gotten that taken care of (or given up on it) I will update the content and check in the relevant files. Skip From charles.hartman at conncoll.edu Sun Feb 26 02:08:45 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat, 25 Feb 2006 20:08:45 -0500 Subject: [Pythonmac-SIG] framework on Intel Message-ID: My interest in the universal build of 2.4.2 has gotten less abstract, because I just (just) got my Intel iMac. I guess I *might* figure out how to build Python 2.4 for myself, though it would be guaranteed to produce a lot of messages to list asking dumb questions . . . So I'm wondering if the binary installer is still looking very close? Or would it be smarter for me to download the current 2.4.1 PPC version and run under Rosetta for a while? (It will work, right?) One project I anticipate soon is following the recipe to compile the debugger part of WingIDE for Intel Macs, since apparently all of Wing works except that. Charles From janssen at parc.com Sun Feb 26 02:21:56 2006 From: janssen at parc.com (Bill Janssen) Date: Sat, 25 Feb 2006 17:21:56 PST Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: Your message of "Sat, 25 Feb 2006 07:29:38 PST." Message-ID: <06Feb25.172200pst."58633"@synergy1.parc.xerox.com> > Hopefully someone can handle this before the new site goes live. (If > I can help, let me know...) Sounds like Skip has a plan to do it. I'll keep an eye on it, too, and make sure it happens. Bill From wgscott at chemistry.ucsc.edu Sun Feb 26 04:18:10 2006 From: wgscott at chemistry.ucsc.edu (William Scott) Date: Sat, 25 Feb 2006 19:18:10 -0800 Subject: [Pythonmac-SIG] Python 2.4.2 on Mac OS X 10.4.5: aquaTk GUI problem since 2.4.1 In-Reply-To: <65fadfc30602251910l6f3f972y3abfd5094113c281@mail.gmail.com> References: <54F48FBC-8671-4427-9A4F-FEB1CC311D8C@chemistry.ucsc.edu> <65fadfc30602251910l6f3f972y3abfd5094113c281@mail.gmail.com> Message-ID: <75028414-1C2C-4710-896B-0099B1E2D0E0@chemistry.ucsc.edu> If you do a Framework install, you will have an empty site-packages directory here: /Library/Frameworks/Python.framework/Versions/Current/lib/python2.4/ site-packages Normally I use fink to install stuff like Numeric and Pmw and Scientific, so I just make a symbolic link like this: 1. If the site-packages directory is empty, remove it. 2. Replace it with a symbolic link like this: sudo ln -s /sw/lib/python2.4/site-packages Library/Frameworks/ Python.framework/Versions/Current/lib/python2.4/site-packages If you were using the original system Python2.3, it's site-packages directory resides at /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages locate site-packges should find everything on your system. HTH, Bill On Feb 25, 2006, at 7:10 PM, Nehemiah Dacres wrote: > replying to the aquatk problem > how did you upgrade your framework?, I may have broken my python, it > can't find site-packages or site (where ever that is). can you help > me? From vivacarlie at gmail.com Sun Feb 26 04:25:19 2006 From: vivacarlie at gmail.com (Nehemiah Dacres) Date: Sat, 25 Feb 2006 21:25:19 -0600 Subject: [Pythonmac-SIG] Fwd: I may have wrecked my python, ( last time i sent this, it was bounced cause I haddn't joined the SIG, i don know if you got this yet Message-ID: <65fadfc30602251925l7baf900esd81d9a0b9af76b00@mail.gmail.com> On 2/25/06, Nehemiah Dacres wrote: > From: Nehemiah I. Dacres > Date: Feb 23, 2006 11:40 PM > Subject: I may have wrecked my python > To: pythonmac-sig at python.org > > > I am a student of Computer Science and i need help understanding how > MacOSX handles Python. > the class I am in is "Intro to Object Oriented Programing" so they > teach in python to reduce teaching of syntax so they can focus on O. > Orientation. I need to import modules we create in class into my > programs and i want to be able to do this as painlessly as possible > per run. My first solution was to find where all the other third party > modules are kept so i found "PyObjC" and there i found how to install > the modules i needed for class. I got this to work and the terminal > agreed however lately I've been having problems. > every sence then, ive been getting this error > > 'import site' failed; use -v for traceback > 'import site' failed; use -v for traceback > 'import site' failed; use -v for traceback > Could not find platform independent libraries > Consider setting $PYTHONHOME to [:] > 'import site' failed; use -v for traceback > > and I really don't know what's going on. I know what PATH is and how > to append it but my knowledge of unix stops at your tutorials in the > tiger terminal, and that of Inside Mac (I never even got Fink and > those X Droplets to work ) so I don't want to mess things up further > than I already have. Recently (im certian it was a later date than > when i changed that) Bittorrent stopped working. I ran it from withing > the package and got this > > Last login: Thu Feb 16 20:52:55 on ttyp2 > /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit > Welcome to Darwin! > adsl-70-130-208-110:~ Nehemiah$ > /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; > exit > Could not find platform independent libraries > Consider setting $PYTHONHOME to [:] > 'import site' failed; use -v for traceback > Traceback (most recent call last): > File "/Users/Nehemiah/Applications/BitTorrent.app/Contents/Resources/__main__.py", > line 1, in ? > import AppHelper > File "./AppHelper.py", line 14, in ? > File "./AppKit/__init__.py", line 8, in ? > File "./AppKit/_AppKitSignatures.py", line 1, in ? > File "./objc/__init__.py", line 20, in ? > File "./objc/_convenience.py", line 21, in ? > ImportError: No module named itertools > 2006-02-16 21:02:44.085 BitTorrent[388] *** Uncaught exception: > > /Users/drue/wa/osx/main-embedded-interpreter.m:75 pyobjc_main() > PyRun_SimpleFile failed with file > '/Users/Nehemiah/Applications/BitTorrent.app/Contents/Resources/__main__.py'. > See console for errors. > Trace/BPT trap > logout > [Process completed] > > Most of that was greek to me but upon looking at the explanation the > problem was clearly my python. (which was made even more obvious when > looking at the resources folder: it seems Bittorent is a Python native > app). This makes things even more dire because I've been using that > program for my anime fix, it doesn't work for ANY account on the > machine. > the final change is that i found the location of the path in > Extras.pth (/System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/python2.3) > found that the last folder was just "python" instead of "python2.3" > but after I remedied that, it still didn't work > the situation is pretty bad but at least regular scripts work > ( > n=raw_input('enter the number up to which you want to take the product') > n=int(n) > k=raw_input('enter the number u want to skip') > k=int(k) > > prod=1 > for i in range (1,n+1,k): > prod*=i > print i > print prod > ) > once with TextWrangler The terminal told me that it couldn't find the > debugger file. i just found the file dbg.py and put it were the > terminal said it was looking, and sence then i haven't gotten that > message. > > Thank you, for your help > From keith.ray at gmail.com Sun Feb 26 05:19:07 2006 From: keith.ray at gmail.com (Keith Ray) Date: Sat, 25 Feb 2006 20:19:07 -0800 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <-7424595036457796307@unknownmsgid> References: <-7424595036457796307@unknownmsgid> Message-ID: <207ec7f00602252019t5aef7774u7e41cfb5234abd73@mail.gmail.com> the readme that comes with the downloaded disk image from this URL: http://python.org/ftp/python/2.4.1/MacPython-OSX-2.4.1-1.dmg says "This package will install MacPython 2.4.1 for Mac OS X 10.3." but the link is supposed to be the installer for 10.4 according to ... "On Mac OS X 10.4 (Tiger), download and run this installer (which gives you a PPC-only version of Python 2.4.1)" On 2/22/06, Bill Janssen wrote: > OK, the new downloads page is now in place on python.org, at > http://www.python.org/download/download_mac.html. > > Thanks to Skip for moving the bits! > > Bill > > > > I was wondering if following the instructions on this page > > > http://bill.janssen.org/mac/new-macpython-page.html > > > > Clearly past time to move this to python.org :-). I'll take care of > > that. > > > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- C. Keith Ray From bob at redivi.com Sun Feb 26 15:03:55 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 26 Feb 2006 08:03:55 -0600 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <207ec7f00602252019t5aef7774u7e41cfb5234abd73@mail.gmail.com> References: <-7424595036457796307@unknownmsgid> <207ec7f00602252019t5aef7774u7e41cfb5234abd73@mail.gmail.com> Message-ID: The content on the site is definitely correct. The same disk image is linked to for both Mac OS X 10.3 and Mac OS X 10.4, but 10.3 users need Tk and 10.4 users need a patch, so they have separate sets of instructions. -bob On Feb 25, 2006, at 10:19 PM, Keith Ray wrote: > the readme that comes with the downloaded disk image from this URL: > http://python.org/ftp/python/2.4.1/MacPython-OSX-2.4.1-1.dmg > says > > "This package will install MacPython 2.4.1 for Mac OS X 10.3." > > but the link is supposed to be the installer for 10.4 according to ... > > "On Mac OS X 10.4 (Tiger), download and run this installer (which > gives > you a PPC-only version of Python 2.4.1)" > > > On 2/22/06, Bill Janssen wrote: >> OK, the new downloads page is now in place on python.org, at >> http://www.python.org/download/download_mac.html. >> >> Thanks to Skip for moving the bits! >> >> Bill >> >>>> I was wondering if following the instructions on this page >>>> http://bill.janssen.org/mac/new-macpython-page.html >>> >>> Clearly past time to move this to python.org :-). I'll take care of >>> that. >>> >>> Bill >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > > -- > > C. Keith Ray > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Sun Feb 26 18:05:26 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 26 Feb 2006 18:05:26 +0100 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: References: Message-ID: On 26-feb-2006, at 2:08, Charles Hartman wrote: > My interest in the universal build of 2.4.2 has gotten less abstract, > because I just (just) got my Intel iMac. > > I guess I *might* figure out how to build Python 2.4 for myself, > though it would be guaranteed to produce a lot of messages to list > asking dumb questions . . . You could use the tree at http://svn.pythonmac.org/python24/python24- fat, check out using subversion and then build using: $ configure --enable-framework --enable-universal-sdk $ make $ sudo make frameworkinstall Please let us know of the results. The installer for the universal binary is very close to being finished, I'm currently working on creating an .mpkg instead of a single package. When that is finished we should have a working installer of a universal python 2.4 build. > > So I'm wondering if the binary installer is still looking very close? > Or would it be smarter for me to download the current 2.4.1 PPC > version and run under Rosetta for a while? (It will work, right?) Running the current version using Rosetta will work as well. Ronald From sw at wordtech-software.com Sun Feb 26 20:16:29 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun, 26 Feb 2006 14:16:29 -0500 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: References: Message-ID: <4401FE8D.3060903@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ronald Oussoren wrote: > You could use the tree at http://svn.pythonmac.org/python24/python24- > fat, > check out using subversion and then build using: > > $ configure --enable-framework --enable-universal-sdk > $ make > $ sudo make frameworkinstall > > Please let us know of the results. The installer for the universal > binary > is very close to being finished, I'm currently working on creating an > .mpkg instead of a single package. When that is finished we should have > a working installer of a universal python 2.4 build. > I gave the build a try. Didn't work. Here are my error messages: /usr/bin/install -c -m 555 Python.framework/Versions/2.4/Python /Library/Frameworks/Python.framework/Versions/2.4/Python c++ -u _PyMac_Error Python.framework/Versions/2.4/Python -o python.exe \ Modules/python.o \ -ldl /usr/bin/ld: Undefined symbols: _PyMac_Error _Py_Main collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Any ideas? - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEAf6MJmdQs+6YVcoRAtjFAKCB8BAsDJSPz3tCiASENcys1jbt6gCcCiCK n1RccDf7UH0yqNWtG4Qp7A8= =5h2e -----END PGP SIGNATURE----- From bob at redivi.com Sun Feb 26 20:24:25 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 26 Feb 2006 13:24:25 -0600 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: <4401FE8D.3060903@wordtech-software.com> References: <4401FE8D.3060903@wordtech-software.com> Message-ID: On Feb 26, 2006, at 1:16 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ronald Oussoren wrote: > >> You could use the tree at http://svn.pythonmac.org/python24/python24- >> fat, >> check out using subversion and then build using: >> >> $ configure --enable-framework --enable-universal-sdk >> $ make >> $ sudo make frameworkinstall >> >> Please let us know of the results. The installer for the universal >> binary >> is very close to being finished, I'm currently working on creating an >> .mpkg instead of a single package. When that is finished we should >> have >> a working installer of a universal python 2.4 build. >> > > > I gave the build a try. Didn't work. Here are my error messages: > > /usr/bin/install -c -m 555 Python.framework/Versions/2.4/Python > /Library/Frameworks/Python.framework/Versions/2.4/Python > c++ -u _PyMac_Error Python.framework/Versions/2.4/Python -o > python.exe \ > Modules/python.o \ > -ldl > /usr/bin/ld: Undefined symbols: > _PyMac_Error > _Py_Main > collect2: ld returned 1 exit status > make: *** [python.exe] Error 1 > > > Any ideas? Make sure that you have the latest build of Xcode and tell us what kind of machine you're building this on. -bob From sw at wordtech-software.com Sun Feb 26 20:27:34 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun, 26 Feb 2006 14:27:34 -0500 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: References: <4401FE8D.3060903@wordtech-software.com> Message-ID: <44020126.1070202@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Ippolito wrote: > > On Feb 26, 2006, at 1:16 PM, Kevin Walzer wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Ronald Oussoren wrote: >> >>> You could use the tree at http://svn.pythonmac.org/python24/python24- >>> fat, >>> check out using subversion and then build using: >>> >>> $ configure --enable-framework --enable-universal-sdk >>> $ make >>> $ sudo make frameworkinstall >>> >>> Please let us know of the results. The installer for the universal >>> binary >>> is very close to being finished, I'm currently working on creating an >>> .mpkg instead of a single package. When that is finished we should have >>> a working installer of a universal python 2.4 build. >>> >> >> >> I gave the build a try. Didn't work. Here are my error messages: >> >> /usr/bin/install -c -m 555 Python.framework/Versions/2.4/Python >> /Library/Frameworks/Python.framework/Versions/2.4/Python >> c++ -u _PyMac_Error Python.framework/Versions/2.4/Python -o python.exe \ >> Modules/python.o \ >> -ldl >> /usr/bin/ld: Undefined symbols: >> _PyMac_Error >> _Py_Main >> collect2: ld returned 1 exit status >> make: *** [python.exe] Error 1 >> >> >> Any ideas? > > Make sure that you have the latest build of Xcode and tell us what kind > of machine you're building this on. > > -bob > > > G3 PPC iBook (900 MHZ), running 10.4.5. Xcode 2.2. - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEAgEmJmdQs+6YVcoRAt4WAJkBiOPDvYi2h/dtaS9MlFr0Q9OE+wCcD6eh v4vy1uULpta0gWVPdb1xm20= =hluW -----END PGP SIGNATURE----- From kquirk at solidworks.com Sun Feb 26 20:43:28 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Sun, 26 Feb 2006 14:43:28 -0500 Subject: [Pythonmac-SIG] Fwd: I may have wrecked my python Message-ID: Yes, your message arrived. Several times. :-) I'm guessing you've probably started stuffing things into directories where you shouldn't be messing around. In general, on OS X, if it starts with /System or /usr, leave it alone, except for /usr/local. In particular, don't go messing with the system install of Python 2.3. The general way of adding stuff so that Python can find it is to add it to PYTHONPATH (not PATH). Don't go deleting modules or moving them around; anything that comes in the Python framework should be left the heck alone. If you've been mucking around in the system Python frameworks, you may have borked it. It may be safest just to reinstall OS X. Next time, when you get import failures, try adding to PYTHONPATH. Kent -----Original Message----- From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig-bounces at python.org] On Behalf Of Nehemiah Dacres Sent: Friday, February 24, 2006 10:32 PM To: pythonmac-sig at python.org Subject: [Pythonmac-SIG] Fwd: I may have wrecked my python From: Nehemiah I. Dacres Date: Feb 23, 2006 11:40 PM Subject: I may have wrecked my python To: pythonmac-sig at python.org I am a student of Computer Science and i need help understanding how MacOSX handles Python. the class I am in is "Intro to Object Oriented Programing" so they teach in python to reduce teaching of syntax so they can focus on O. Orientation. I need to import modules we create in class into my programs and i want to be able to do this as painlessly as possible per run. My first solution was to find where all the other third party modules are kept so i found "PyObjC" and there i found how to install the modules i needed for class. I got this to work and the terminal agreed however lately I've been having problems. every sence then, ive been getting this error 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback and I really don't know what's going on. I know what PATH is and how to append it but my knowledge of unix stops at your tutorials in the tiger terminal, and that of Inside Mac (I never even got Fink and those X Droplets to work ) so I don't want to mess things up further than I already have. Recently (im certian it was a later date than when i changed that) Bittorrent stopped working. I ran it from withing the package and got this Last login: Thu Feb 16 20:52:55 on ttyp2 /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit Welcome to Darwin! adsl-70-130-208-110:~ Nehemiah$ /Users/Nehemiah/Applications/BitTorrent.app/Contents/MacOS/BitTorrent; exit Could not find platform independent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "/Users/Nehemiah/Applications/BitTorrent.app/Contents/Resources/__main__ .py", line 1, in ? import AppHelper File "./AppHelper.py", line 14, in ? File "./AppKit/__init__.py", line 8, in ? File "./AppKit/_AppKitSignatures.py", line 1, in ? File "./objc/__init__.py", line 20, in ? File "./objc/_convenience.py", line 21, in ? ImportError: No module named itertools 2006-02-16 21:02:44.085 BitTorrent[388] *** Uncaught exception: /Users/drue/wa/osx/main-embedded-interpreter.m:75 pyobjc_main() PyRun_SimpleFile failed with file '/Users/Nehemiah/Applications/BitTorrent.app/Contents/Resources/__main__ .py'. See console for errors. Trace/BPT trap logout [Process completed] Most of that was greek to me but upon looking at the explanation the problem was clearly my python. (which was made even more obvious when looking at the resources folder: it seems Bittorent is a Python native app). This makes things even more dire because I've been using that program for my anime fix, it doesn't work for ANY account on the machine. the final change is that i found the location of the path in Extras.pth (/System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/pyt hon2.3) found that the last folder was just "python" instead of "python2.3" but after I remedied that, it still didn't work the situation is pretty bad but at least regular scripts work ( n=raw_input('enter the number up to which you want to take the product') n=int(n) k=raw_input('enter the number u want to skip') k=int(k) prod=1 for i in range (1,n+1,k): prod*=i print i print prod ) once with TextWrangler The terminal told me that it couldn't find the debugger file. i just found the file dbg.py and put it were the terminal said it was looking, and sence then i haven't gotten that message. Thank you, for your help _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From egb at usno.navy.mil Mon Feb 27 19:02:17 2006 From: egb at usno.navy.mil (Eric G. Barron) Date: Mon, 27 Feb 2006 13:02:17 -0500 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: References: Message-ID: <9E834B2B-3C6B-48AD-AD5D-182FBE3583E4@usno.navy.mil> On 26 Feb 2006, at 1205, Ronald Oussoren wrote: > You could use the tree at http://svn.pythonmac.org/python24/python24- > fat, > check out using subversion and then build using: > > $ configure --enable-framework --enable-universal-sdk > $ make > $ sudo make frameworkinstall > > Please let us know of the results. I built and installed revision 23 over the weekend. Things are working great after fixing one little thing that was preventing me from installing packages... In Lib/distutils/util.py, the second argument being sent to re.search () on lines 88-90 is plist.read() when it should be f.read(). Since I changed that, everything seems to be working perfectly. Thanks to everyone involved for all their work with this project! Eric From ronaldoussoren at mac.com Mon Feb 27 19:27:11 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 27 Feb 2006 19:27:11 +0100 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: <9E834B2B-3C6B-48AD-AD5D-182FBE3583E4@usno.navy.mil> References: <9E834B2B-3C6B-48AD-AD5D-182FBE3583E4@usno.navy.mil> Message-ID: <535DC046-CFC8-4CFC-837E-75EAF15FEFC1@mac.com> On 27-feb-2006, at 19:02, Eric G. Barron wrote: > > On 26 Feb 2006, at 1205, Ronald Oussoren wrote: > >> You could use the tree at http://svn.pythonmac.org/python24/python24- >> fat, >> check out using subversion and then build using: >> >> $ configure --enable-framework --enable-universal-sdk >> $ make >> $ sudo make frameworkinstall >> >> Please let us know of the results. > > I built and installed revision 23 over the weekend. Things are > working great after fixing one little thing that was preventing me > from installing packages... > > In Lib/distutils/util.py, the second argument being sent to re.search > () on lines 88-90 is plist.read() when it should be f.read(). Since > I changed that, everything seems to be working perfectly. I've checked in a fix for this. Ronald > > Thanks to everyone involved for all their work with this project! > > Eric > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From janssen at parc.com Mon Feb 27 19:32:03 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 27 Feb 2006 10:32:03 PST Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: Your message of "Sat, 25 Feb 2006 07:29:38 PST." Message-ID: <06Feb27.103207pst."58633"@synergy1.parc.xerox.com> > Guido has just announced (at his PyCon keynote) that the new web site > (see beta.python.org) is going live a week from tomorrow (or Sunday, > March 5), and has requested help migrating the content. I see that the content on the "downloads" page is different on the beta site, and wrong w.r.t. MacPython. Is that page (currently in rest format) going to be replaced with the page from the current web site (also wrong)? Should I just fix it? Bill From skip at pobox.com Mon Feb 27 22:46:04 2006 From: skip at pobox.com (skip at pobox.com) Date: Mon, 27 Feb 2006 15:46:04 -0600 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <06Feb27.103207pst."58633"@synergy1.parc.xerox.com> References: <06Feb27.103207pst."58633"@synergy1.parc.xerox.com> Message-ID: <17411.29468.745083.261535@montanaro.dyndns.org> >> Guido has just announced (at his PyCon keynote) that the new web site >> (see beta.python.org) is going live a week from tomorrow (or Sunday, >> March 5), and has requested help migrating the content. Bill> I see that the content on the "downloads" page is different on the Bill> beta site, and wrong w.r.t. MacPython. Is that page (currently in Bill> rest format) going to be replaced with the page from the current Bill> web site (also wrong)? Should I just fix it? I just converted it yesterday. Does this page http://beta.python.org/download/mac/ still look wrong to you? It's got the python-squeezing-the-apple icon for me. If that's not the case for you perhaps you just need to do a page reload or empty your browser's cache (or your proxy server's cache). Skip From janssen at parc.com Mon Feb 27 23:47:41 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 27 Feb 2006 14:47:41 PST Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: Your message of "Mon, 27 Feb 2006 13:46:04 PST." <17411.29468.745083.261535@montanaro.dyndns.org> Message-ID: <06Feb27.144747pst."58633"@synergy1.parc.xerox.com> I meant the "main" downloads page, which still pointed to Jack Jansen's installer for 2.3 (under the section for 2.4.2). I just removed that pointer. Bill From keith.ray at gmail.com Tue Feb 28 00:04:20 2006 From: keith.ray at gmail.com (Keith Ray) Date: Mon, 27 Feb 2006 15:04:20 -0800 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <4987736355806643180@unknownmsgid> References: <17411.29468.745083.261535@montanaro.dyndns.org> <4987736355806643180@unknownmsgid> Message-ID: <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> Once you install 2.4.1, does everything python-related just automatically start working with it, or do you need to re-install packages like appscript, PyFIT, and so on that have installed themselves off of /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packges/... ? (Will the installers for PyFIT, appscript, etc, do the right thing if run after installing 2.4.1?) Do you need to set up any environment variables to specify that the newer python is to be used instead of the old one? (if so, how do you set that up?) From ronaldoussoren at mac.com Tue Feb 28 07:59:41 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 28 Feb 2006 07:59:41 +0100 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <17411.29468.745083.261535@montanaro.dyndns.org> References: <06Feb27.103207pst.58633@synergy1.parc.xerox.com> <17411.29468.745083.261535@montanaro.dyndns.org> Message-ID: On 27-feb-2006, at 22:46, skip at pobox.com wrote: > >>> Guido has just announced (at his PyCon keynote) that the new web >>> site >>> (see beta.python.org) is going live a week from tomorrow (or Sunday, >>> March 5), and has requested help migrating the content. > > Bill> I see that the content on the "downloads" page is > different on the > Bill> beta site, and wrong w.r.t. MacPython. Is that page > (currently in > Bill> rest format) going to be replaced with the page from the > current > Bill> web site (also wrong)? Should I just fix it? > > I just converted it yesterday. Does this page > > http://beta.python.org/download/mac/ > > still look wrong to you? It's got the python-squeezing-the-apple > icon for > me. If that's not the case for you perhaps you just need to do a page > reload or empty your browser's cache (or your proxy server's cache). The page looks fine, but it might be better to remove the icon or replace it by the current MacPython icon (the 16 ton weight). It's not that I don't like the snake, but some people claim a lifelike snake will scare some (potential) users and furthermore the snake-icon isn't actually used by MacPython (yet?). Ronald > > Skip > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Tue Feb 28 08:04:06 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 28 Feb 2006 08:04:06 +0100 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> References: <17411.29468.745083.261535@montanaro.dyndns.org> <4987736355806643180@unknownmsgid> <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> Message-ID: <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96@mac.com> On 28-feb-2006, at 0:04, Keith Ray wrote: > Once you install 2.4.1, does everything python-related just > automatically start working with it, or do you need to re-install > packages like appscript, PyFIT, and so on that have installed > themselves off of > /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packges/... > ? You'll have to reinstall packages if you start using another major release of Python (that is move from 2.3 to 2.4). If you install from source files will end up in the right place automaticly, otherwise you'll have to make sure that you use the binary installer for the right version of Python. > > (Will the installers for PyFIT, appscript, etc, do the right thing if > run after installing 2.4.1?) > > Do you need to set up any environment variables to specify that the > newer python is to be used instead of the old one? (if so, how do you > set that up?) Yes, you will have to make sure that /Library/Frameworks/ Python.framework/Versions/2.4/bin is at the start of your PATH. If you use bash[1] is you should create a .bash_profile file in your home directory that contains the line PATH="/Library/Frameworks/Python.framework/Versions/ 2.4/bin:$PATH". The upcoming universal build of will do this for you (at least once I've checked in that part of the installer). Ronald [1] that is, "echo $0" says "sh" or "bash". > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From sw at wordtech-software.com Tue Feb 28 10:06:35 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue, 28 Feb 2006 04:06:35 -0500 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: References: Message-ID: <4404129B.5050204@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ronald Oussoren wrote: > On 26-feb-2006, at 2:08, Charles Hartman wrote: > >> My interest in the universal build of 2.4.2 has gotten less abstract, >> because I just (just) got my Intel iMac. >> >> I guess I *might* figure out how to build Python 2.4 for myself, >> though it would be guaranteed to produce a lot of messages to list >> asking dumb questions . . . > > You could use the tree at http://svn.pythonmac.org/python24/python24- > fat, > check out using subversion and then build using: > > $ configure --enable-framework --enable-universal-sdk > $ make > $ sudo make frameworkinstall > > Please let us know of the results. The installer for the universal > binary > is very close to being finished, I'm currently working on creating an > .mpkg instead of a single package. When that is finished we should have > a working installer of a universal python 2.4 build. > >> So I'm wondering if the binary installer is still looking very close? >> Or would it be smarter for me to download the current 2.4.1 PPC >> version and run under Rosetta for a while? (It will work, right?) > > Running the current version using Rosetta will work as well. > > Ronald > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > I tried to build again, and failed again. Here is where the error occurred: ld: warning can't open dynamic library: - -all_load/usr/lib/system/libmathCommon.A.dylib referenced from: /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) This looks weird. Possibly a problem on my system only? OS X 10.4.5, XCode 2.2. - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBBKbJmdQs+6YVcoRAsbsAJ0U46hMo9CVN0ifQSBcHgEW/AZdagCfZyHt BHUCBz4C0h7JkB0hUyONLvQ= =RlZA -----END PGP SIGNATURE----- From bob at redivi.com Tue Feb 28 15:21:03 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 28 Feb 2006 08:21:03 -0600 Subject: [Pythonmac-SIG] framework on Intel In-Reply-To: <4404129B.5050204@wordtech-software.com> References: <4404129B.5050204@wordtech-software.com> Message-ID: <6D00EF06-B048-47E1-B886-FE352E4FA5BE@redivi.com> On Feb 28, 2006, at 3:06 AM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ronald Oussoren wrote: >> On 26-feb-2006, at 2:08, Charles Hartman wrote: >> >>> My interest in the universal build of 2.4.2 has gotten less >>> abstract, >>> because I just (just) got my Intel iMac. >>> >>> I guess I *might* figure out how to build Python 2.4 for myself, >>> though it would be guaranteed to produce a lot of messages to list >>> asking dumb questions . . . >> >> You could use the tree at http://svn.pythonmac.org/python24/python24- >> fat, >> check out using subversion and then build using: >> >> $ configure --enable-framework --enable-universal-sdk >> $ make >> $ sudo make frameworkinstall >> >> Please let us know of the results. The installer for the universal >> binary >> is very close to being finished, I'm currently working on creating an >> .mpkg instead of a single package. When that is finished we should >> have >> a working installer of a universal python 2.4 build. >> >>> So I'm wondering if the binary installer is still looking very >>> close? >>> Or would it be smarter for me to download the current 2.4.1 PPC >>> version and run under Rosetta for a while? (It will work, right?) >> >> Running the current version using Rosetta will work as well. >> >> Ronald >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > I tried to build again, and failed again. Here is where the error > occurred: > > ld: warning can't open dynamic library: > - -all_load/usr/lib/system/libmathCommon.A.dylib referenced from: > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib > (checking for undefined symbols may be affected) (No such file or > directory, errno = 2) > > This looks weird. Possibly a problem on my system only? > OS X 10.4.5, XCode 2.2. My guess is that you didn't install the right SDKs or something when you installed Xcode. -bob From rowen at cesmail.net Tue Feb 28 19:13:51 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Tue, 28 Feb 2006 10:13:51 -0800 Subject: [Pythonmac-SIG] Download page on www.python.org now updated References: <17411.29468.745083.261535@montanaro.dyndns.org> <4987736355806643180@unknownmsgid> <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96@mac.com> Message-ID: In article <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96 at mac.com>, Ronald Oussoren wrote: > On 28-feb-2006, at 0:04, Keith Ray wrote: ... > > Do you need to set up any environment variables to specify that the > > newer python is to be used instead of the old one? (if so, how do you > > set that up?) > > Yes, you will have to make sure that /Library/Frameworks/ > Python.framework/Versions/2.4/bin > is at the start of your PATH. > > If you use bash[1] is you should create a .bash_profile file in your > home directory that > contains the line PATH="/Library/Frameworks/Python.framework/Versions/ > 2.4/bin:$PATH". It seems unfortunate to put that long complicated mess into the path, and then have to redo it when python 2.5 comes out. Bob's unofficial 2.4.1 installer puts links in /usr/local/bin. Will the universal build do that as well? Then all one needs to do is make sure /usr/local/bin in on the path. -- Russell From bob at redivi.com Tue Feb 28 19:33:45 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 28 Feb 2006 12:33:45 -0600 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: References: <17411.29468.745083.261535@montanaro.dyndns.org> <4987736355806643180@unknownmsgid> <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96@mac.com> Message-ID: <3B4482D4-B1F9-4439-8635-6C9C28284FD9@redivi.com> On Feb 28, 2006, at 12:13 PM, Russell E. Owen wrote: > In article <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96 at mac.com>, > Ronald Oussoren wrote: > >> On 28-feb-2006, at 0:04, Keith Ray wrote: > ... >>> Do you need to set up any environment variables to specify that the >>> newer python is to be used instead of the old one? (if so, how >>> do you >>> set that up?) >> >> Yes, you will have to make sure that /Library/Frameworks/ >> Python.framework/Versions/2.4/bin >> is at the start of your PATH. >> >> If you use bash[1] is you should create a .bash_profile file in your >> home directory that >> contains the line PATH="/Library/Frameworks/Python.framework/ >> Versions/ >> 2.4/bin:$PATH". > > It seems unfortunate to put that long complicated mess into the path, > and then have to redo it when python 2.5 comes out. The long way is the right way. Having to change your path when a new version of Python is installed is not a bad thing. > Bob's unofficial 2.4.1 installer puts links in /usr/local/bin. Will > the > universal build do that as well? Then all one needs to do is make sure > /usr/local/bin in on the path. However, anything you install with distutils is going to put its scripts in the framework's bin dir, so you have to add it to your path anyway, or create a .pydistutils.cfg that redirects the install_scripts location. bdist_mpkg works around this by assuming that you want /usr/local/bin, but that's a hack. -bob From bob at redivi.com Tue Feb 28 20:44:18 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 28 Feb 2006 13:44:18 -0600 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: References: <17411.29468.745083.261535@montanaro.dyndns.org> <4987736355806643180@unknownmsgid> <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96@mac.com> <3B4482D4-B1F9-4439-8635-6C9C28284FD9@redivi.com> Message-ID: On Feb 28, 2006, at 1:35 PM, Russell E Owen wrote: > At 12:33 PM -0600 2006-02-28, Bob Ippolito wrote: >> On Feb 28, 2006, at 12:13 PM, Russell E. Owen wrote: >> >>> In article <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96 at mac.com>, >>> Ronald Oussoren wrote: >>> >>> ...you will have to make sure that /Library/Frameworks/ >>> Python.framework/Versions/2.4/bin >>> is at the start of your PATH. >>> >>> If you use bash[1] is you should create a .bash_profile file in >>> your >>> home directory that >>> contains the line PATH="/Library/Frameworks/Python.framework/ >>> Versions/ >>> 2.4/bin:$PATH". >>> >>> It seems unfortunate to put that long complicated mess into the >>> path, >>> and then have to redo it when python 2.5 comes out. >> >> The long way is the right way. Having to change your path when a >> new version of Python is installed is not a bad thing. > > OK, I'll do the long path. > > But I'm still puzzled about hard-coding the version. Why not just use: > > PATH="/Library/Frameworks/Python.framework/Versions/ > Current/bin:$PATH" > > and automatically get the current version? It seems to me that > would be best for most users and that experts who want finer > control would know what to do. That's not necessarily a bad idea -bob From ronaldoussoren at mac.com Tue Feb 28 21:08:46 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 28 Feb 2006 21:08:46 +0100 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: References: <17411.29468.745083.261535@montanaro.dyndns.org> <4987736355806643180@unknownmsgid> <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96@mac.com> <3B4482D4-B1F9-4439-8635-6C9C28284FD9@redivi.com> Message-ID: On 28-feb-2006, at 20:44, Bob Ippolito wrote: > > On Feb 28, 2006, at 1:35 PM, Russell E Owen wrote: > >> At 12:33 PM -0600 2006-02-28, Bob Ippolito wrote: >>> On Feb 28, 2006, at 12:13 PM, Russell E. Owen wrote: >>> >>>> In article <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96 at mac.com>, >>>> Ronald Oussoren wrote: >>>> >>>> ...you will have to make sure that /Library/Frameworks/ >>>> Python.framework/Versions/2.4/bin >>>> is at the start of your PATH. >>>> >>>> If you use bash[1] is you should create a .bash_profile file in >>>> your >>>> home directory that >>>> contains the line PATH="/Library/Frameworks/Python.framework/ >>>> Versions/ >>>> 2.4/bin:$PATH". >>>> >>>> It seems unfortunate to put that long complicated mess into the >>>> path, >>>> and then have to redo it when python 2.5 comes out. >>> >>> The long way is the right way. Having to change your path when a >>> new version of Python is installed is not a bad thing. >> >> OK, I'll do the long path. >> >> But I'm still puzzled about hard-coding the version. Why not just >> use: >> >> PATH="/Library/Frameworks/Python.framework/Versions/ >> Current/bin:$PATH" >> >> and automatically get the current version? It seems to me that >> would be best for most users and that experts who want finer >> control would know what to do. > > That's not necessarily a bad idea +1. I've added this to my postinstall script for the universal build. Ronald > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Tue Feb 28 22:07:57 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 28 Feb 2006 22:07:57 +0100 Subject: [Pythonmac-SIG] universal binary installer, take 1 Message-ID: I've placed a DMG with an installer for a universal build of python 2.4.2. This is an initial release of this installer, there are probably issues with it. This installer features: - a universal binary of Python.framework - readline 5.1 - sleepycat db 4.4 - IDLE with Mac keybindings - Python Documentation, both in IDLE and pydoc - pythonw and python are equivalent - the installer will update your shell profile if needed Known issues: - "regrtest -uall" crashes somewhere in test_db3 (bus error) - I haven't tested this version on Intel or OSX 10.3 yet. - This version cannot build extensions on OSX 10.3, or any other system without Xcode 2.2.1 and the 10.4u SDK. The installer is here: http://homepage.mac.com/ronaldoussoren/.Public/ Universal%20MacPython%202.4.2.dmg Ronald From zbir at urbanape.com Tue Feb 28 22:46:44 2006 From: zbir at urbanape.com (Zachery Bir) Date: Tue, 28 Feb 2006 16:46:44 -0500 Subject: [Pythonmac-SIG] universal binary installer, take 1 In-Reply-To: References: Message-ID: On Feb 28, 2006, at 4:07 PM, Ronald Oussoren wrote: > Known issues: > > - I haven't tested this version on Intel or OSX 10.3 yet. Downloading and testing now on Mac OS X Intel. Zac From rowen at u.washington.edu Tue Feb 28 20:35:24 2006 From: rowen at u.washington.edu (Russell E Owen) Date: Tue, 28 Feb 2006 11:35:24 -0800 Subject: [Pythonmac-SIG] Download page on www.python.org now updated In-Reply-To: <3B4482D4-B1F9-4439-8635-6C9C28284FD9@redivi.com> References: <17411.29468.745083.261535@montanaro.dyndns.org> <4987736355806643180@unknownmsgid> <207ec7f00602271504v4d31178fw654340c53e0cee53@mail.gmail.com> <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96@mac.com> <3B4482D4-B1F9-4439-8635-6C9C28284FD9@redivi.com> Message-ID: At 12:33 PM -0600 2006-02-28, Bob Ippolito wrote: >On Feb 28, 2006, at 12:13 PM, Russell E. Owen wrote: > >>In article <6B3B4ACB-7FA1-4D24-8689-20ACEA656F96 at mac.com>, >> Ronald Oussoren wrote: >> >>...you will have to make sure that /Library/Frameworks/ >>Python.framework/Versions/2.4/bin >>is at the start of your PATH. >> >>If you use bash[1] is you should create a .bash_profile file in your >>home directory that >>contains the line PATH="/Library/Frameworks/Python.framework/Versions/ >>2.4/bin:$PATH". >> >>It seems unfortunate to put that long complicated mess into the path, >>and then have to redo it when python 2.5 comes out. > >The long way is the right way. Having to change your path when a new >version of Python is installed is not a bad thing. OK, I'll do the long path. But I'm still puzzled about hard-coding the version. Why not just use: PATH="/Library/Frameworks/Python.framework/Versions/ Current/bin:$PATH" and automatically get the current version? It seems to me that would be best for most users and that experts who want finer control would know what to do. -- Russell