From hengist.podd at virgin.net Tue Feb 1 01:07:02 2005 From: hengist.podd at virgin.net (has) Date: Tue Feb 1 01:07:44 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: <11784ef9dee718e4216b74f0213f1151@redivi.com> References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> <11784ef9dee718e4216b74f0213f1151@redivi.com> Message-ID: Bob wrote: >>I'd be happy to build a 10.2 version though if you can tell me how >>(given I'm not familiar with the CVS or making installers). > >After checking out the repository with subversion (or just doing a >recursive web get, I guess), and having recent version of py2app >installed (I suggest also using svn, as it builds python source a >bit nicer): > >% python setup.py bdist_mpkg OK, I'll try and have a bash at it sometime this week. (Wish me luck.;) >>p.s. I've submitted patches for Carbon.AE [1090958] and >>OSATerminology [1113328]; don't suppose you know if/when they'll >>make it into 2.4, and from there into your 2.3 retro-package? > >Unfortunately these patches need to be rewritten such that they >change the gensuitemodule scripts I think you mean bgen, yes?:) Don't suppose the patches could simply be applied to the existing C code now, and formal rewrites deferred until if/when the bgen scripts require other modifications? Or does it generate different C code for different Python versions/installations? >and Jack is really the only one good at doing that :) And the proverbial bus, while not actively running over poor Jack, does seem to be parked fairly firmly upon his foot at the moment. Curse these inconvenient "real lives" that some people seem to have. However, I do have to draw the line at learning bgen myself, as we'd be onto OS XVI by the time I've mastered it. :p has ("It rewrites the patches or it gets the hose again." ;p) -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Feb 1 02:09:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 1 02:09:59 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> <11784ef9dee718e4216b74f0213f1151@redivi.com> Message-ID: <250f0482dc8e7e6e61d57b0724dd1c75@redivi.com> On Jan 31, 2005, at 19:07, has wrote: > Bob wrote: > >>> p.s. I've submitted patches for Carbon.AE [1090958] and >>> OSATerminology [1113328]; don't suppose you know if/when they'll >>> make it into 2.4, and from there into your 2.3 retro-package? >> >> Unfortunately these patches need to be rewritten such that they >> change the gensuitemodule scripts > > I think you mean bgen, yes?:) Don't suppose the patches could simply > be applied to the existing C code now, and formal rewrites deferred > until if/when the bgen scripts require other modifications? Or does it > generate different C code for different Python versions/installations? Yeah I mean bgen... I'm confusing the evil code generators -- as I said, it's been quite a long time since I've looked at this stuff (sometime 2003). It's technically possible to apply the patches to the existing C code now.. but I think that Jack would sooner fix the bgen scripts than apply a kludge to the C source. Though, "sooner" might not be a good word for it :) -bob From janssen at parc.com Tue Feb 1 02:24:44 2005 From: janssen at parc.com (Bill Janssen) Date: Tue Feb 1 02:25:15 2005 Subject: [Pythonmac-SIG] Reading the resource fork with Python? Message-ID: <05Jan31.172449pst."58617"@synergy1.parc.xerox.com> Given a filename on an HFS volume, what call do I use to see if it has a resource fork, and if there's anything in it? How do I read that data? I'm trying to read the URL out of a .webloc file, if that helps. Bill From mwh at python.net Tue Feb 1 13:32:05 2005 From: mwh at python.net (Michael Hudson) Date: Tue Feb 1 13:32:07 2005 Subject: [Pythonmac-SIG] Reading the resource fork with Python? In-Reply-To: <05Jan31.172449pst."58617"@synergy1.parc.xerox.com> (Bill Janssen's message of "Mon, 31 Jan 2005 17:24:44 PST") References: <05Jan31.172449pst."58617"@synergy1.parc.xerox.com> Message-ID: <2mbrb48nqy.fsf@starship.python.net> Bill Janssen writes: > Given a filename on an HFS volume, what call do I use to see if it has > a resource fork, and if there's anything in it? How do I read that > data? rpath = os.path.join(yourpath, '..namedfork', 'rsrc') os.path.getsize(rpath) > 0 data = open(rpath).read() or, possibly more helpfully, from Carbon import Res try: rf = Res.FSpOpenResFile(yourpath, 0) except MacOS.Error, e: if e.args[0] == -39: # not a resource file pass else: raise else: for i in range(1, Res.Count1Types() + 1): typ = Res.Get1IndType(i) for j in range(1, Res.Count1Resources(typ) + 1): res = Res.Get1IndResource(typ, j) id_, typ2, name = res.GetResInfo() print repr(typ), id_, repr(name), len(res.data), if len(res.data) < 40: print repr(res.data) else: print Res.CloseResFile(rf) > I'm trying to read the URL out of a .webloc file, if that helps. Running the above on the only webloc file I seem to have lying around gives: 'drag' 128 '' 48 'TEXT' 256 '' 31 'http://www.ambrosiasw.com/news/' 'url ' 256 '' 31 'http://www.ambrosiasw.com/news/' Cheers, mwh -- I think if we have the choice, I'd rather we didn't explicitly put flaws in the reST syntax for the sole purpose of not insulting the almighty. -- /will on the doc-sig From charles.hartman at conncoll.edu Tue Feb 1 14:54:07 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 1 14:54:12 2005 Subject: [Pythonmac-SIG] Did I bust py2app? In-Reply-To: <227DB5E5-AE94-4C9B-AADC-DFF6E6C7A486@mac.com> References: <227DB5E5-AE94-4C9B-AADC-DFF6E6C7A486@mac.com> Message-ID: <8a8cef96c4dd2dac5ca96e10d0d9b7bf@conncoll.edu> On Jan 30, 2005, at 7:37 PM, Bob Ippolito wrote: > . . . you have junk from an early version of py2app. Thanks, as always. Working on a setup.py file again, I'm realizing I need to know more (surprise!). But where to look? I've read through the Distutils doc since that seems like essential background. And I've read the bit I get with help(py2app) in an interactive Python window. But I'm still not intelligently reading the sample setup.py files in examples etc. I need to know more about plists, for one thing -- is there a good little intro on them? Or am I wrong to emphasize them? My goal is to make setup.py files that will work for both py2app and py2exe, since I have to build Windows executables for some of my colleagues. And here's a *really* simple thing I don't understand: I've got a data file I need to include in my app. I know how to specify it on the py2app command line (python setup.py py2app --resources mydatafile) -- but where do I put it in the setup.py file? (I want it to get included in a py2exe build, too.) You see the kind of tutorial I'm looking for? Any pointers much appreciated. Charles Hartman From Henning.Ramm at mediapro-gmbh.de Tue Feb 1 15:44:48 2005 From: Henning.Ramm at mediapro-gmbh.de (Ramm, Henning) Date: Tue Feb 1 15:44:16 2005 Subject: [Pythonmac-SIG] algorithm wanted Message-ID: Hi there! I'm looking for a better algorithm... In a print project I must know if some page needs every CMYK separation or just some; I keep this info in a boolean list like [True, True, False, True] for C,M,K (no Y plate). But our workflow database needs a string like "CM0K" (plate letter or zero). How can I convert this best? Here is my code: class ProcessColors: _cmykMap = ['C', 'M', 'Y', 'K'] def __init__(self, C=False, M=False, Y=False, K=True): self.werte = [C,M,Y,K] def bool2str(self, werte=None): """converts a list of booleans to a CMYK color string, e.g. [True, False, False, True] to 'C00K'""" if not werte: werte = self.werte for i in range(0,4): if werte[i]: werte[i] = self._cmykMap[i] else: werte[i] = '0' return string.join(werte, '') def str2bool(self, werte='000K'): """converts a CMYK color string to a list of booleans, e.g. 'CM0K' to [True, True, False, True]""" werte = list(werte) for i in range(0,4): if werte[i]==self._cmykMap[i]: werte[i] = True else: werte[i] = False return werte I hope the same is possible without 'if' and 'for', perhaps some lambda+boolean wizardry? Best regards, ----------------------- Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Abt. Systembetreuung From eichin at metacarta.com Tue Feb 1 16:46:24 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: Tue Feb 1 16:46:35 2005 Subject: [Pythonmac-SIG] algorithm wanted In-Reply-To: References: Message-ID: <7gpszkmgfj.fsf@pikespeak.metacarta.com> It's certainly one of the things map+lambda are for >>> "".join(map(lambda x,y: {True:x, False:"0"}[y], _cmykMap, [True, False, True, True])) 'C0YK' but I'd break that down into a selector function (rather than a lambda) or something to make it readable, since it's way too far on the lisp side of things as far as expressiveness goes. The code you have isn't actually unclear, so consider *why* you want to make it compact. You could also work with for and zip: >>> def flagmap(tag, flag): ... if flag: return tag ... return "0" ... >>> [flagmap(tag, flag) for tag, flag in zip(_cmykMap, [True, False, True, True])] ['C', '0', 'Y', 'K'] (add "".join or string.join as appropriate.) What I don't see is why you have ProcessColors as a class, but I'm assuming there's context for that -- these converter functions are just that, functions, though I could see having a color object that also called them as methods, the idea of using a method of a color object to convert another color word in a way that has nothing to do with the color object itself seems an odd use of the object. From bob at redivi.com Tue Feb 1 16:58:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 1 16:58:40 2005 Subject: [Pythonmac-SIG] Did I bust py2app? In-Reply-To: <8a8cef96c4dd2dac5ca96e10d0d9b7bf@conncoll.edu> References: <227DB5E5-AE94-4C9B-AADC-DFF6E6C7A486@mac.com> <8a8cef96c4dd2dac5ca96e10d0d9b7bf@conncoll.edu> Message-ID: On Feb 1, 2005, at 8:54, Charles Hartman wrote: > On Jan 30, 2005, at 7:37 PM, Bob Ippolito wrote: > >> . . . you have junk from an early version of py2app. > > Thanks, as always. > > Working on a setup.py file again, I'm realizing I need to know more > (surprise!). But where to look? I've read through the Distutils doc > since that seems like essential background. And I've read the bit I > get with help(py2app) in an interactive Python window. But I'm still > not intelligently reading the sample setup.py files in examples etc. I > need to know more about plists, for one thing -- is there a good > little intro on them? Or am I wrong to emphasize them? My goal is to > make setup.py files that will work for both py2app and py2exe, since I > have to build Windows executables for some of my colleagues. "help(py2app)" is probably pretty useless, you want "python setup.py py2app --help" > And here's a *really* simple thing I don't understand: I've got a data > file I need to include in my app. I know how to specify it on the > py2app command line (python setup.py py2app --resources mydatafile) -- > but where do I put it in the setup.py file? (I want it to get included > in a py2exe build, too.) Add it to data_files in the setup(....).. both py2app and py2exe should understand that. setup( app = [....], data_files = [myfile], ) It would probably be helpful to look around in the py2app examples. -bob From Chris.Barker at noaa.gov Wed Feb 2 00:50:52 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 2 00:49:04 2005 Subject: [Pythonmac-SIG] Compiling matplotlib on OS-X without Fink In-Reply-To: <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> Message-ID: <420015DC.8070108@noaa.gov> Hi all, I just got matplotlib working on my box, so I thought I'd post this, so that it will be in the archives, and because I'd like others to try it and let me know if it doesn't work for you. One question for the knowledgeable folks here: I have /usr/include/zlib.h on my system, but I have no idea where I got it. I do know that it isn't on other systems in my office without the dev tools. Did it come with the dev tools, or something else I installed? Anyway, here's what worked for me: Installing matplotlib on OS-X (10.3.7) Here are my notes as to what it took to get matplotlib (0.71) installed and working on OS-X. I have so far kept a fink-free system, so that's what I've done here as well. I use it with the AGG back end for generating images for a web site, and hopefully with the wx backend for interactive use and embedding in wx Applications. 1) Requirements: ------------------------------------------- According to the matplotlib install docs (http://matplotlib.sourceforge.net/installing.html), you need the following: freetype (>= 2.1.7) libpng zlib Personally, I've been avoiding Fink, as it doesn't seem to play well with the rest of OS-X, including the Apple supplied Python, so I've looked elsewhere for these libs. a) Freetype: I seem to have it in: /usr/X11R6/include/freetype2 I don't think I installed it myself, so it probably came with Apple's X11, Which I did install. However, I seemed to be having problems with that version, so I looked, and it seems to be: libfreetype.6.3.dylib Given that freetype2 is currently at version 2.1.9, I have no idea what to make of that! So off to sourceforge to get a new freetype: http://freetype.sourceforge.net/index2.html where I got: freetype-2.1.9.tar.gz Following the instructions in docs/INSTALL.UNX: $ ./configure $ make $ sudo make install That puts it in /usr/local/..., which is a good place for it. b) zlib: I have: /usr/include/zlib.h I don't know where I might have gotten it, but there it is. NOTE: I checked on another system in my office, and it doesn't have zlib. It also doesn't have any developer tools installed, so you couldn't build anything on it anyway. If zlib comes with XCode tools, anyone who can build should have it. It also may have come with some other package I've installed, but I have no idea what. Let me know if you know. c) libpng: This, I didn't have on my system, except inside the wxWidgets source tree, so I went looking for it. Note that you need zlib to compile libpng, so make sure you have that first. I did a google search for "libpng OS-X". I found: http://www.libpng.org/pub/png/pngcode.html Which led me to the libpng sourceforge site. From there I downloaded: libpng-1.2.8.tar.gz unpacked it, and opened a terminal in the libpng-1.2.8 directory, and did: $ cp scripts/makefile.darwin ./makefile (note that according to the INSTALL, there is supposed to be a makefile.macosx, but it wasn't there) I took a look in the makefile, and found: ZLIBLIB=/usr/local/lib ZLIBINC=/usr/local/include Which is not where zlib is on my system. However, while I can find zlib.h, I couldn't fine the actual lib, so I tried make without changing anything. $ make Which seemed to work fine. zlib must be installed in a standard location, and gcc found it. $ sudo make install to install the lib into /usr/local/ (this was specified in the makefile, and it's a good place for it) $ make test and $ ./pngtest pngnow.png Which both seemed to pass. d) Numeric or numarray: I already have Numeric installed, from Bob Ippolito's PIMP (MacPython Package Manager) repostitory. (www.undefined.org/python) 2) Building matplotlib --------------------------------------------------------- First, I took a look at the matplotlib setup.py. It had "auto" for the back-end flags, so I thought I would give it a try that way: $python setup.py build That worked! $ sudo python setup.py install 4) And now to test! $python >>> import pylab Could not open font file /Library/Fonts/NISC18030.ttf No module named pygtk PyGTK version 1.99.16 or greater is required to run the GTK Matplotlib backends This turns out to be because the matlabrc file sets the GTKAgg back end as the default. You have two choices. 1) you can set the back end before importing pylab. >>> import matplotlib >>> matplotlib.use('Agg') >>> import pylab This works fine 2) Edit the matplotlibrc file. I found it in: /System/Library/Frameworks/Python.framework/Versions/2.3/share/matplotlib/.matplotlibrc Change the line: backend : GTKAgg # the default backend to backend : Agg # the default backend And you're all set to make images for the web, etc. I'm going to leave getting it to work with wxPython for another day. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Wed Feb 2 01:04:47 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 2 01:02:58 2005 Subject: [Pythonmac-SIG] How do I make a binary matplotlib distribution on OS-X? In-Reply-To: <420015DC.8070108@noaa.gov> References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> <420015DC.8070108@noaa.gov> Message-ID: <4200191F.1010101@noaa.gov> Hi all, See my previous message about building matplotlib on OS-X. Now that I've done that, I need to give it to some of my coworkers that don't have the dev tools installed, and are aghast at the idea of typing ./configure; make, make install. So, how do I make a binary distro? I know I can get distutils to do it, but it won't included the needed extra libs: freetype libpng zlib It seems I have three options: 1) Just give them a tarball of the compiled libs, ready to be dropped into /usr/local (I don't like that option, what If I clobber something?) 2) Somehow put the libs inside the matplotlib distro 3) Statically link those libs into the matplotlib extensions I have no idea how to do 2 or 3, but could probably figure it out. What do folks suggest? Any pointers? Also, what's up with the Packman databases? I think I saw a note from Bob saying he isn't maintaining his. Jack, are you maintaining yours? If either of these is being maintained, how would I get matplotlib into it? thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Larry.A.Meyn at nasa.gov Wed Feb 2 01:06:16 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Feb 2 01:06:30 2005 Subject: [Pythonmac-SIG] Compiling matplotlib on OS-X without Fink In-Reply-To: <420015DC.8070108@noaa.gov> References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> <420015DC.8070108@noaa.gov> Message-ID: <2554534e5e2df23c0ff873789bc6afe7@nasa.gov> Chris, An alternative way to get freetype, libpng and zlib for OS X is to use the the i-Installer (http://ii2.sourceforge.net/) distribution application. It is primarily for TeX on OS X, but it provides several other useful binaries for OS X. Larry On Feb 1, 2005, at 3:50 PM, Chris Barker wrote: > Hi all, > > I just got matplotlib working on my box, so I thought I'd post this, > so that it will be in the archives, and because I'd like others to try > it and let me know if it doesn't work for you. > > > One question for the knowledgeable folks here: > > I have /usr/include/zlib.h on my system, but I have no idea where I > got it. I do know that it isn't on other systems in my office without > the dev tools. Did it come with the dev tools, or something else I > installed? > > Anyway, here's what worked for me: > > Installing matplotlib on OS-X (10.3.7) > > Here are my notes as to what it took to get matplotlib (0.71) > installed and working on OS-X. I have so far kept a fink-free system, > so that's what I've done here as well. I use it with the AGG back end > for generating images for a web site, and hopefully with the wx > backend for interactive use and embedding in wx Applications. > > 1) Requirements: > ------------------------------------------- > According to the matplotlib install docs > (http://matplotlib.sourceforge.net/installing.html), you need the > following: > > freetype (>= 2.1.7) > libpng > zlib > > Personally, I've been avoiding Fink, as it doesn't seem to play well > with the rest of OS-X, including the Apple supplied Python, so I've > looked elsewhere for these libs. > > a) Freetype: > I seem to have it in: > > /usr/X11R6/include/freetype2 > > I don't think I installed it myself, so it probably came with Apple's > X11, Which I did install. > > However, I seemed to be having problems with that version, so I > looked, and it seems to be: > > libfreetype.6.3.dylib > > Given that freetype2 is currently at version 2.1.9, I have no idea > what to make of that! So off to sourceforge to get a new freetype: > > http://freetype.sourceforge.net/index2.html > > where I got: > > freetype-2.1.9.tar.gz > > Following the instructions in docs/INSTALL.UNX: > > $ ./configure > $ make > $ sudo make install > > That puts it in /usr/local/..., which is a good place for it. > > b) zlib: > I have: > /usr/include/zlib.h > > I don't know where I might have gotten it, but there it is. > > NOTE: I checked on another system in my office, and it doesn't have > zlib. It also doesn't have any developer tools installed, so you > couldn't build anything on it anyway. If zlib comes with XCode tools, > anyone who can build should have it. It also may have come with some > other package I've installed, but I have no idea what. Let me know if > you know. > > c) libpng: > This, I didn't have on my system, except inside the wxWidgets source > tree, so I went looking for it. > > Note that you need zlib to compile libpng, so make sure you have that > first. > > I did a google search for "libpng OS-X". I found: > > http://www.libpng.org/pub/png/pngcode.html > > Which led me to the libpng sourceforge site. > > From there I downloaded: > > libpng-1.2.8.tar.gz > > unpacked it, and opened a terminal in the libpng-1.2.8 directory, and > did: > > $ cp scripts/makefile.darwin ./makefile > > (note that according to the INSTALL, there is supposed to be a > makefile.macosx, but it wasn't there) > > I took a look in the makefile, and found: > > ZLIBLIB=/usr/local/lib > ZLIBINC=/usr/local/include > > Which is not where zlib is on my system. However, while I can find > zlib.h, I couldn't fine the actual lib, so I tried make without > changing anything. > > $ make > > Which seemed to work fine. zlib must be installed in a standard > location, and gcc found it. > > $ sudo make install > > to install the lib into /usr/local/ (this was specified in the > makefile, and it's a good place for it) > > $ make test > and > $ ./pngtest pngnow.png > > Which both seemed to pass. > > d) Numeric or numarray: > > I already have Numeric installed, from Bob Ippolito's PIMP (MacPython > Package Manager) repostitory. (www.undefined.org/python) > > 2) Building matplotlib > --------------------------------------------------------- > First, I took a look at the matplotlib setup.py. It had "auto" for the > back-end flags, so I thought I would give it a try that way: > > $python setup.py build > > That worked! > $ sudo python setup.py install > > 4) And now to test! > > $python > > >>> import pylab > Could not open font file /Library/Fonts/NISC18030.ttf > No module named pygtk > PyGTK version 1.99.16 or greater is required to run the GTK Matplotlib > backends > > This turns out to be because the matlabrc file sets the GTKAgg back > end as the default. You have two choices. > > 1) you can set the back end before importing pylab. > >>> import matplotlib > >>> matplotlib.use('Agg') > >>> import pylab > > This works fine > > 2) Edit the matplotlibrc file. I found it in: > /System/Library/Frameworks/Python.framework/Versions/2.3/share/ > matplotlib/.matplotlibrc > > Change the line: > backend : GTKAgg # the default backend > to > backend : Agg # the default backend > > And you're all set to make images for the web, etc. > > I'm going to leave getting it to work with wxPython for another day. > > -Chris > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker@noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > Larry Meyn Aerospace Operations Modeling Office M/S 210-10 NASA Ames Research Center Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov Phone: (650) 604-5038 Fax: (650) 604-0222 E-Fax: (425) 944-5526 sent via e-mail Larry Meyn Aerospace Operations Modeling Office M/S 210-10 NASA Ames Research Center Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov Phone: (650) 604-5038 Fax: (650) 604-0222 E-Fax: (425) 944-5526 sent via e-mail From bob at redivi.com Wed Feb 2 01:14:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 01:14:20 2005 Subject: [Pythonmac-SIG] How do I make a binary matplotlib distribution on OS-X? In-Reply-To: <4200191F.1010101@noaa.gov> References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> <420015DC.8070108@noaa.gov> <4200191F.1010101@noaa.gov> Message-ID: On Feb 1, 2005, at 19:04, Chris Barker wrote: > See my previous message about building matplotlib on OS-X. Now that > I've done that, I need to give it to some of my coworkers that don't > have the dev tools installed, and are aghast at the idea of typing > ./configure; make, make install. > > So, how do I make a binary distro? I know I can get distutils to do > it, but it won't included the needed extra libs: > > freetype > libpng > zlib zlib ships with OS X > It seems I have three options: > > 1) Just give them a tarball of the compiled libs, ready to be dropped > into /usr/local (I don't like that option, what If I clobber > something?) > > 2) Somehow put the libs inside the matplotlib distro That's possible > 3) Statically link those libs into the matplotlib extensions But this is better > I have no idea how to do 2 or 3, but could probably figure it out. This is (3) Make sure you don't have libpng.dylib or libfreetype.dylib sitting around on your link paths... Build them like this: ./configure --disable-shared --enable static Make sure you only have libpng.a and libfreetype.a on your link paths. It will link statically. > What do folks suggest? Any pointers? After you've linked matplotlib statically, use bdist_mpkg from py2app to make a redistributable .pkg installer for it. After installing py2app, you should have a tool in /usr/local/bin called "bdist_mpkg" that will Just Do It without any setup.py modifications to the target lib... so go into the matplotlib directory, type bdist_mpkg, and cross your fingers that a dist/matplotlib-xx.pkg will appear. If you have any problems beyond that, let me know. -bob From Chris.Barker at noaa.gov Wed Feb 2 01:28:59 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 2 01:27:11 2005 Subject: [Matplotlib-users] Re: [Pythonmac-SIG] Compiling matplotlib on OS-X without Fink In-Reply-To: <2554534e5e2df23c0ff873789bc6afe7@nasa.gov> References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> <420015DC.8070108@noaa.gov> <2554534e5e2df23c0ff873789bc6afe7@nasa.gov> Message-ID: <42001ECB.5080302@noaa.gov> Larry Meyn wrote: > An alternative way to get freetype, libpng and zlib for OS X is to use > the the i-Installer (http://ii2.sourceforge.net/) distribution > application. It is primarily for TeX on OS X, but it provides several > other useful binaries for OS X. Thanks larry. I've used that for TeX, which is probably where I got zlib. However, somehow I found it to be a real pain to use, I don't really remember why. It's too bad that Apple hasn't provided an officially sanctioned package manger for this kind of thing. It's really a mess with Fink, DarwinPorts, Portage, i-Installer, etc. Oh well, at least we can get this stuff working, I wouldn't have even tried with the old MacOS. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From brendansimons at yahoo.ca Wed Feb 2 01:39:00 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Wed Feb 2 01:39:39 2005 Subject: [Pythonmac-SIG] How do I make a binary matplotlib distribution on OS-X? Message-ID: > See my previous message about building matplotlib on OS-X. Now that > I've done that, I need to give it to some of my coworkers that don't > have the dev tools installed, and are aghast at the idea of typing > ./configure; make, make install. > > So, how do I make a binary distro? Wow, serendipity! I was just sitting down to the challenge of building matplotlib on os-x myself. Please keep the list(s) updated on your progress. I would certainly prefer running an install script or mpkg than trying to compile all the dependencies. *sending karma, Brendan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From bob at redivi.com Wed Feb 2 01:39:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 01:39:41 2005 Subject: [Matplotlib-users] Re: [Pythonmac-SIG] Compiling matplotlib on OS-X without Fink In-Reply-To: <42001ECB.5080302@noaa.gov> References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> <420015DC.8070108@noaa.gov> <2554534e5e2df23c0ff873789bc6afe7@nasa.gov> <42001ECB.5080302@noaa.gov> Message-ID: <11e4cfc03c6936f132216f5f4cc7a67a@redivi.com> On Feb 1, 2005, at 19:28, Chris Barker wrote: > Larry Meyn wrote: >> An alternative way to get freetype, libpng and zlib for OS X is to >> use the the i-Installer (http://ii2.sourceforge.net/) distribution >> application. It is primarily for TeX on OS X, but it provides >> several other useful binaries for OS X. > > Thanks larry. I've used that for TeX, which is probably where I got > zlib. However, somehow I found it to be a real pain to use, I don't > really remember why. > > It's too bad that Apple hasn't provided an officially sanctioned > package manger for this kind of thing. It's really a mess with Fink, > DarwinPorts, Portage, i-Installer, etc. Oh well, at least we can get > this stuff working, I wouldn't have even tried with the old MacOS. Well Apple does sponsor a bit of darwinports development one way or another, and it has the capability to build .pkg installers. Anyway, PJE and I are working on the Next Big Thing in Python packages that will make this problem go away at some point. Hopefully by March ;) -bob From hengist.podd at virgin.net Wed Feb 2 01:47:13 2005 From: hengist.podd at virgin.net (has) Date: Wed Feb 2 01:47:52 2005 Subject: [Pythonmac-SIG] algorithm wanted Message-ID: Henning Hraban Ramm wrote: >I'm looking for a better algorithm... This is probably as terse as it gets: def bool2cm0k(lst): """Converts a list of booleans to a CMYK color string, e.g. [True, False, False, True] to 'C00K' """ return ''.join([b and c or '0' for b, c in zip(lst, 'CMYK')]) def cm0k2bool(s): """Converts a CMYK color string to a list of booleans, e.g. 'CM0K' to [True, True, False, True] """ return [c1 == c2 for c1, c2 in zip(s, 'CMYK')] print bool2cm0k([True, False, False, True]) # --> C00K print cm0k2bool('CM0K') # --> [True, True, False, True] HTH has -- http://freespace.virgin.net/hamish.sanderson/ From Larry.A.Meyn at nasa.gov Wed Feb 2 01:55:43 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Feb 2 01:55:54 2005 Subject: [Matplotlib-users] Re: [Pythonmac-SIG] Compiling matplotlib on OS-X without Fink In-Reply-To: <42001ECB.5080302@noaa.gov> References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> <420015DC.8070108@noaa.gov> <2554534e5e2df23c0ff873789bc6afe7@nasa.gov> <42001ECB.5080302@noaa.gov> Message-ID: <4f0f0665ac1458ec077ad01400deb22f@nasa.gov> On Feb 1, 2005, at 4:28 PM, Chris Barker wrote: > Larry Meyn wrote: >> An alternative way to get freetype, libpng and zlib for OS X is to >> use the the i-Installer (http://ii2.sourceforge.net/) distribution >> application. It is primarily for TeX on OS X, but it provides >> several other useful binaries for OS X. > > Thanks larry. I've used that for TeX, which is probably where I got > zlib. However, somehow I found it to be a real pain to use, I don't > really remember why. > > It's too bad that Apple hasn't provided an officially sanctioned > package manger for this kind of thing. It's really a mess with Fink, > DarwinPorts, Portage, i-Installer, etc. Oh well, at least we can get > this stuff working, I wouldn't have even tried with the old MacOS. > > -Chris Chris, The first incarnation of i-Installer was a pain, but I've found the later versions to be extremely easy to use and trouble free. That being said, it would be much nicer to have self contained package installer or have a package in a Packman database. Thanks for your efforts along these lines. Larry Larry Meyn Aerospace Operations Modeling Office M/S 210-10 NASA Ames Research Center Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov Phone: (650) 604-5038 Fax: (650) 604-0222 E-Fax: (425) 944-5526 sent via e-mail From janssen at parc.com Wed Feb 2 02:12:06 2005 From: janssen at parc.com (Bill Janssen) Date: Wed Feb 2 02:12:36 2005 Subject: [Pythonmac-SIG] Reading the resource fork with Python? In-Reply-To: Your message of "Tue, 01 Feb 2005 04:32:05 PST." <2mbrb48nqy.fsf@starship.python.net> Message-ID: <05Feb1.171215pst."58617"@synergy1.parc.xerox.com> Thanks! Bill From Chris.Barker at noaa.gov Wed Feb 2 02:16:54 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 2 02:15:05 2005 Subject: [Pythonmac-SIG] How do I make a binary matplotlib distribution on OS-X? In-Reply-To: References: <41F17420.1020602@noaa.gov> <41F18981.7000609@noaa.gov> <9F4DF166-6C10-11D9-8818-00039383D318@cal.berkeley.edu> <420015DC.8070108@noaa.gov> <4200191F.1010101@noaa.gov> Message-ID: <42002A06.5080207@noaa.gov> Bob Ippolito wrote: >> 3) Statically link those libs into the matplotlib extensions > This is (3) > Make sure you don't have libpng.dylib or libfreetype.dylib sitting > around on your link paths... > > Build them like this: > ./configure --disable-shared --enable static That seemed to build and install both the *.a and the *.dylib > Make sure you only have libpng.a and libfreetype.a on your link paths. > It will link statically. So I'll remove the dylib... I'm going to go home before I finish, but I'll report back tomorrow. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From delza at livingcode.org Wed Feb 2 03:19:27 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Feb 2 03:19:44 2005 Subject: [Pythonmac-SIG] algorithm wanted In-Reply-To: References: Message-ID: <8c8506c19b17adebb4285bc2a42b92c0@livingcode.org> On 1-Feb-05, at 4:47 PM, has wrote: > Henning Hraban Ramm wrote: > >> I'm looking for a better algorithm... > > This is probably as terse as it gets: [snip] # zip() isn't needed in this direction def cm0k2bool(s): return [x != '0' for x in s] --Dethe "The law I sign today directs new funds and new focus to the task of collecting vital intelligence on terrorist threats and on weapons of mass production." -- George W. Bush -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050201/e156b17d/smime.bin From jerdonek at davischoicevoting.org Wed Feb 2 03:42:07 2005 From: jerdonek at davischoicevoting.org (Chris Jerdonek) Date: Wed Feb 2 03:42:08 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app Message-ID: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> Hi, I'm new to py2app (and also to python somewhat). I wasn't able to find any documentation, so I'm turning here. I'm trying to generate a setup.py file that I can use with py2app. I have the setup.py file that someone made tailored to py2exe. Is it straightforward to modify that? I haven't had success because I can't tell which commands are py2exe/Windows-specific, or even what the needed py2app commands/options are. I only saw the "minimal" setup.py for py2ap in the wiki. The application I'm using it for uses wxPython and html help files. Thanks for any help, and thanks for all the work everyone put into writing/designing py2app. CHRIS -- (530) 297-6947 http://DavisChoiceVoting.org From bob at redivi.com Wed Feb 2 03:53:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 03:54:05 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app In-Reply-To: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> References: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> Message-ID: <46aa402ed231158aa0701f7c722aa1fe@redivi.com> On Feb 1, 2005, at 21:42, Chris Jerdonek wrote: > I'm new to py2app (and also to python somewhat). > > I wasn't able to find any documentation, so I'm turning here. > > I'm trying to generate a setup.py file that I can use with py2app. I > have the setup.py file that someone made tailored to py2exe. > > Is it straightforward to modify that? I haven't had success because I > can't tell which commands are py2exe/Windows-specific, or even what > the needed py2app commands/options are. I only saw the "minimal" > setup.py for py2ap in the wiki. > > The application I'm using it for uses wxPython and html help files. > > Thanks for any help, and thanks for all the work everyone put into > writing/designing py2app. Without knowing what's in the setup.py that you're trying to convert, I can't give you any specific advice. py2app ships with several examples of varying complexity that are installed to: /Developer/Python/py2app/Examples The list of options py2app will accept is shown when you do "python setup.py py2app --help". These can be converted into setup.py speak by replacing the hyphens with underscores and passing them to setup() in an options dictionary (many of the examples do this). -bob From charles.hartman at conncoll.edu Wed Feb 2 04:48:51 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Feb 2 04:48:55 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app In-Reply-To: <46aa402ed231158aa0701f7c722aa1fe@redivi.com> References: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> <46aa402ed231158aa0701f7c722aa1fe@redivi.com> Message-ID: <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> On Feb 1, 2005, at 9:53 PM, Bob Ippolito wrote: > The list of options py2app will accept is shown when you do "python > setup.py py2app --help". These can be converted into setup.py speak > by replacing the hyphens with underscores and passing them to setup() > in an options dictionary (many of the examples do this). I'm in the same boat with C. Jerdonek, though I suspect I know less. So when I saw this passage, I hung, as always, on every word from py2app's own master. Aha! I said. And I do find that syntax in two places: the setup.py files for PyTestPlugin and wxGlade each have two *nested* dictionaries, which I understand *almost* well enough to use it. Two others (TinyTinyEdit and aliens) have a simple dict that maps a script to a plist. And the setup.py for superdoodle is one I really want to understand and can't quite: setup( name="superdoodle", **{buildstyle : ['superdoodle.py']} ) where buildstyle has been set according to platform. But I for one am still having trouble duplicating and extending this syntax for my own files. (Nothing in the Distutils docs on any of this, of course.) I think this is where some of us need a fill-in-the-gap tutorial. Any mercy welcome. Charles Hartman "The earth does not get fat." --Nguni proverb From bob at redivi.com Wed Feb 2 05:06:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 05:07:05 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app In-Reply-To: <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> References: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> <46aa402ed231158aa0701f7c722aa1fe@redivi.com> <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> Message-ID: On Feb 1, 2005, at 10:48 PM, Charles Hartman wrote: > > On Feb 1, 2005, at 9:53 PM, Bob Ippolito wrote: > >> The list of options py2app will accept is shown when you do "python >> setup.py py2app --help". These can be converted into setup.py speak >> by replacing the hyphens with underscores and passing them to setup() >> in an options dictionary (many of the examples do this). > > I'm in the same boat with C. Jerdonek, though I suspect I know less. > So when I saw this passage, I hung, as always, on every word from > py2app's own master. Aha! I said. > > And I do find that syntax in two places: the setup.py files for > PyTestPlugin and wxGlade each have two *nested* dictionaries, which I > understand *almost* well enough to use it. Two others (TinyTinyEdit > and aliens) have a simple dict that maps a script to a plist. And the > setup.py for superdoodle is one I really want to understand and can't > quite: > setup( > name="superdoodle", > **{buildstyle : ['superdoodle.py']} > ) > where buildstyle has been set according to platform. > > But I for one am still having trouble duplicating and extending this > syntax for my own files. (Nothing in the Distutils docs on any of > this, of course.) I think this is where some of us need a > fill-in-the-gap tutorial. Any mercy welcome. See http://docs.python.org/ref/calls.html -- it explains how this syntax works. -bob From richard at commonground.com.au Wed Feb 2 05:10:35 2005 From: richard at commonground.com.au (Richard Jones) Date: Wed Feb 2 05:10:38 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" Message-ID: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> I've just switched from running py2app with -A to not using it. After fleshing out the "includes" option so that my required modules were included, I finallly got the app to start up. It promptly quits, with the following message: Fatal Python error: PyThreadState_Get: no current thread Abort trap My app is a simple GUI thing which controls Zope through the zdaemon.zdctl module. It's attached. The Zope libs (and some supporting libs) are installed in the app's Resources folder in a "runtime" subdirectory (historical name, will eventually change to Zope ;) As I mentioned, this works OK when I invoke py2app with -A but it breaks when I run it for real. I'm not using threads in my app, but Zope does use threads when it's running. The invocation of the zdaemon.zdctl code should not create any threads that I'm aware of. I'm currently working through a process of elimination to see whether I can narrow down to a particular suspect. Does anyone have any ideas what might cause this? Richard From richard at commonground.com.au Wed Feb 2 05:15:30 2005 From: richard at commonground.com.au (Richard Jones) Date: Wed Feb 2 05:15:33 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> Message-ID: <61b5714b680b2ae8a9a3caca7bf74f7d@commonground.com.au> On 02/02/2005, at 3:10 PM, Richard Jones wrote: > Fatal Python error: PyThreadState_Get: no current thread > Abort trap Changing:: import objc to:: import objc objc.enableThreading() didn't help. Richard From bob at redivi.com Wed Feb 2 05:28:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 05:28:49 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> Message-ID: <42BDE0FC-D30E-47A5-A10E-356BE0ECA72C@redivi.com> On Feb 1, 2005, at 11:10 PM, Richard Jones wrote: > I've just switched from running py2app with -A to not using it. After > fleshing out the "includes" option so that my required modules were > included, I finallly got the app to start up. It promptly quits, with > the following message: > > Fatal Python error: PyThreadState_Get: no current thread > Abort trap > > My app is a simple GUI thing which controls Zope through the > zdaemon.zdctl module. It's attached. The Zope libs (and some > supporting libs) are installed in the app's Resources folder in a > "runtime" subdirectory (historical name, will eventually change to > Zope ;) > > As I mentioned, this works OK when I invoke py2app with -A but it > breaks when I run it for real. > > I'm not using threads in my app, but Zope does use threads when it's > running. The invocation of the zdaemon.zdctl code should not create > any threads that I'm aware of. I'm currently working through a process > of elimination to see whether I can narrow down to a particular > suspect. > > Does anyone have any ideas what might cause this? Could be a lot of things. I can't really start to guess unless I can see it. -bob From richard at commonground.com.au Wed Feb 2 06:14:31 2005 From: richard at commonground.com.au (Richard Jones) Date: Wed Feb 2 06:14:35 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <42BDE0FC-D30E-47A5-A10E-356BE0ECA72C@redivi.com> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <42BDE0FC-D30E-47A5-A10E-356BE0ECA72C@redivi.com> Message-ID: <3bd9bcddda3bebe89919ce3111f46fb0@commonground.com.au> On 02/02/2005, at 3:28 PM, Bob Ippolito wrote: > Could be a lot of things. I can't really start to guess unless I can > see it. Unfortunately: short:~/src/cg/Zope-OSX richard$ du -sk dist/ 80560 dist/ :( I've figured that it is Zope that's causing the problems. I guess there's maybe just another missing import or something. Richard From bob at redivi.com Wed Feb 2 06:24:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 06:24:16 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <3bd9bcddda3bebe89919ce3111f46fb0@commonground.com.au> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <42BDE0FC-D30E-47A5-A10E-356BE0ECA72C@redivi.com> <3bd9bcddda3bebe89919ce3111f46fb0@commonground.com.au> Message-ID: On Feb 2, 2005, at 12:14 AM, Richard Jones wrote: > On 02/02/2005, at 3:28 PM, Bob Ippolito wrote: >> Could be a lot of things. I can't really start to guess unless I can >> see it. > > Unfortunately: > > short:~/src/cg/Zope-OSX richard$ du -sk dist/ > 80560 dist/ > > :( > > I've figured that it is Zope that's causing the problems. I guess > there's maybe just another missing import or something. If you zip -r9 that I bet its 10 times smaller, at least. It could be some exception gone wrong, a bug in zope, a bug in PyObjC, etc. At the absolute least, I need to see a gdb backtrace. -bob From richard at commonground.com.au Wed Feb 2 06:56:08 2005 From: richard at commonground.com.au (Richard Jones) Date: Wed Feb 2 06:56:15 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <42BDE0FC-D30E-47A5-A10E-356BE0ECA72C@redivi.com> <3bd9bcddda3bebe89919ce3111f46fb0@commonground.com.au> Message-ID: On 02/02/2005, at 4:24 PM, Bob Ippolito wrote: > If you zip -r9 that I bet its 10 times smaller, at least. 23MB :) I could make that available if you're willing to look at it. > It could be some exception gone wrong, a bug in zope, a bug in PyObjC, > etc. At the absolute least, I need to see a gdb backtrace. Heh. It's been so long since I've debugged something like this I'd forgotten about gdb. Had to remember how to drive it. Unfortunately, it doesn't look like giving any useful information - after it PyRun_SimpleFileExFlags __boot__.py the stack trace doesn't have any useful information: #156 0x100a823c in run_node (n=0xbffff3fc, filename=0x0, globals=0x0, locals=0x1, flags=0x6c205079) at Python/pythonrun.c:1267 #157 0x100a79c0 in PyRun_SimpleFileExFlags (fp=0xa0009818, filename=0x1813800 "/Users/richard/src/cg/Zope-OSX/dist/CGPublisher-Zope.app/Contents/ Resources/__boot__.py", closeit=3318892, flags=0x30ed60) at Python/pythonrun.c:862 #158 0x00003df4 in ?? () #159 0x00003e94 in ?? () #160 0x00002708 in ?? () #161 0x0000257c in ?? () (gdb) As far as I can tell, it appears to be breaking somewhere in xml.sax.parser - I'm working on narrowing that down further. Richard From jerdonek at davischoicevoting.org Wed Feb 2 07:59:04 2005 From: jerdonek at davischoicevoting.org (Chris Jerdonek) Date: Wed Feb 2 07:58:58 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app In-Reply-To: <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> References: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> <46aa402ed231158aa0701f7c722aa1fe@redivi.com> <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> Message-ID: -- (530) 297-6947 http://DavisChoiceVoting.org On Feb 1, 2005, at 7:48 PM, Charles Hartman wrote: > I'm in the same boat with C. Jerdonek, though I suspect I know less. > So when I saw this passage, I hung, as always, on every word from > py2app's own master. Aha! I said. I think I know less, Charles. I tried the hello.py sample in the Developer directory. I copied hello & setup.py to a separate directory and ran -- python setup.py py2app This created an executable icon in the Finder called "hello" in a directory called "dist". Will this always be the stand-alone app? (From the command line hello.app is a directory, which I don't understand.) Anyways, I double-clicked the hello icon. It appeared on the dock and immediately collapsed without any output. Is this the desired behavior? CHRIS From richard at commonground.com.au Wed Feb 2 08:12:35 2005 From: richard at commonground.com.au (Richard Jones) Date: Wed Feb 2 08:12:46 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> Message-ID: <544b86a86d3c2348a59b7eb6f84d3ad8@commonground.com.au> On 02/02/2005, at 3:10 PM, Richard Jones wrote: > My app is a simple GUI thing which controls Zope through the > zdaemon.zdctl module. It's attached. The Zope libs (and some > supporting libs) are installed in the app's Resources folder in a > "runtime" subdirectory (historical name, will eventually change to > Zope ;) Bob has pointed out that the python libs shouldn't be in the runtime directory, they should be included through py2app's module management. Zope has ... interesting ideas about how modules and packages work though, so that's going to be fun to sort out :) I noticed that if I specify a packages option to py2app, it creates both a site-packages.zip *and* a site-packages directory. It then fails to find some stuff. Adding the packages as "includes" doesn't help, as the packages are then included in the zip file, and unfortunately, Zope stores data files in the packages alongside the Python source files, and assumes those files are in a regular directory structure. So now I work on figuring how to turn off the zip-ification of site-packages. Richard From bob at redivi.com Wed Feb 2 09:32:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 09:32:43 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app In-Reply-To: References: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> <46aa402ed231158aa0701f7c722aa1fe@redivi.com> <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> Message-ID: <7AC4E544-7CF6-4121-B36E-7185B3A499C8@redivi.com> On Feb 2, 2005, at 1:59 AM, Chris Jerdonek wrote: >> I'm in the same boat with C. Jerdonek, though I suspect I know less. >> So when I saw this passage, I hung, as always, on every word from >> py2app's own master. Aha! I said. > > I think I know less, Charles. > > I tried the hello.py sample in the Developer directory. > > I copied hello & setup.py to a separate directory and ran -- > python setup.py py2app > > This created an executable icon in the Finder called "hello" in a > directory called "dist". Will this always be the stand-alone app? > (From the command line hello.app is a directory, which I don't > understand.) Yes, See: http://developer.apple.com/documentation/MacOSX/Conceptual/ SystemOverview/AppPackaging/chapter_5_section_2.html > Anyways, I double-clicked the hello icon. It appeared on the dock and > immediately collapsed without any output. Is this the desired > behavior? Yes that is expected behavior, if you open up Console you will see a bunch of information about the environment that hello.py ran in. Examples that demonstrate GUI behavior depend on third party stuff. -bob From Henning.Ramm at mediapro-gmbh.de Wed Feb 2 09:35:59 2005 From: Henning.Ramm at mediapro-gmbh.de (Ramm, Henning) Date: Wed Feb 2 09:36:03 2005 Subject: [Pythonmac-SIG] algorithm wanted Message-ID: eichin@metacarta.com wrote: >>>> "".join(map(lambda x,y: {True:x, False:"0"}[y], _cmykMap, >[True, False, True, True])) >'C0YK' >but I'd break that down into a selector function (rather than a >lambda) or something to make it readable, since it's way too far on >the lisp side of things as far as expressiveness goes. But very interesting for someone like me who never learned to think "functional". ;-) >The code you have isn't actually unclear, so consider *why* you want >to make it compact. I like to have elegant code (hoping it will be faster, too) and I like to learn "how the pros do it". >What I don't see is why you have ProcessColors as a class, but I'm >assuming there's context for that The real class has some more methods, and the two converters are only private. But you're right - I use the class here merely for grouping everything that belongs together; I'm not really used to OO at all - I used to code in Perl and now try to learn Python and OO at once. ;-) > these converter functions are >just that, functions, though I could see having a color object that >also called them as methods, the idea of using a method of a color >object to convert another color word in a way that has nothing to do >with the color object itself seems an odd use of the object. I thought, my 'color info object' should 'know' how to present itself to different interfaces. Best regards, ----------------------- Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Abt. Systembetreuung From Henning.Ramm at mediapro-gmbh.de Wed Feb 2 09:44:26 2005 From: Henning.Ramm at mediapro-gmbh.de (Ramm, Henning) Date: Wed Feb 2 09:44:30 2005 Subject: [Pythonmac-SIG] algorithm wanted Message-ID: has and Dethe wrote: >def bool2cm0k(lst): > """Converts a list of booleans to a CMYK color string, > e.g. [True, False, False, True] to 'C00K' > """ > return ''.join([b and c or '0' for b, c in zip(lst, 'CMYK')]) > >def cm0k2bool(s): > """Converts a CMYK color string to a list of booleans, > e.g. 'CM0K' to [True, True, False, True] > """ > return [x != '0' for x in s] > >print bool2cm0k([True, False, False, True]) # --> C00K >print cm0k2bool('CM0K') # --> [True, True, False, True] Thank you all very much! This is what I imagined! :-) Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From bob at redivi.com Wed Feb 2 09:45:17 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 09:45:24 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <544b86a86d3c2348a59b7eb6f84d3ad8@commonground.com.au> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <544b86a86d3c2348a59b7eb6f84d3ad8@commonground.com.au> Message-ID: <9B506ECF-BE57-4971-B872-D7DEED2B5AE0@redivi.com> On Feb 2, 2005, at 2:12 AM, Richard Jones wrote: > On 02/02/2005, at 3:10 PM, Richard Jones wrote: >> My app is a simple GUI thing which controls Zope through the >> zdaemon.zdctl module. It's attached. The Zope libs (and some >> supporting libs) are installed in the app's Resources folder in a >> "runtime" subdirectory (historical name, will eventually change to >> Zope ;) > > Bob has pointed out that the python libs shouldn't be in the runtime > directory, they should be included through py2app's module management. > > Zope has ... interesting ideas about how modules and packages work > though, so that's going to be fun to sort out :) > > I noticed that if I specify a packages option to py2app, it creates > both a site-packages.zip *and* a site-packages directory. It then > fails to find some stuff. Adding the packages as "includes" doesn't > help, as the packages are then included in the zip file, and > unfortunately, Zope stores data files in the packages alongside the > Python source files, and assumes those files are in a regular > directory structure. So now I work on figuring how to turn off the > zip-ification of site-packages. Creating both a zip and a directory is perfectly normal and expected. "fails to find some stuff" is probably unrelated. Turning off zip-ification of site-packages wouldn't do you any good because py2app chooses which files it wants to put in there. Look at -- it's designed to be particularly annoying to package. -bob From richard at commonground.com.au Wed Feb 2 10:01:51 2005 From: richard at commonground.com.au (Richard Jones) Date: Wed Feb 2 10:01:59 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <9B506ECF-BE57-4971-B872-D7DEED2B5AE0@redivi.com> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <544b86a86d3c2348a59b7eb6f84d3ad8@commonground.com.au> <9B506ECF-BE57-4971-B872-D7DEED2B5AE0@redivi.com> Message-ID: <9c89e2237dcebe98ce8184646910f8b7@commonground.com.au> On 02/02/2005, at 7:45 PM, Bob Ippolito wrote: > Creating both a zip and a directory is perfectly normal and expected. > > "fails to find some stuff" is probably unrelated. More specifically, the "smart" xml.sax.saxexts module fails to find any parsers for parsing XML. I need to look more closely at what it's trying to do. I suppose I just need to keep bashing away at things until I've managed to get the correct combination of packages and includes args to setup() ;) > Turning off zip-ification of site-packages wouldn't do you any good > because py2app chooses which files it wants to put in there. Yeah. I did start down the road of implementing the -Z py2app switch, but that led to pain :) > Look at > -- it's designed to be particularly annoying to package. Ah, righto, I'll use that as inspiration. Thanks again for all your help! Richard From bob at redivi.com Wed Feb 2 10:04:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 10:04:47 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <9c89e2237dcebe98ce8184646910f8b7@commonground.com.au> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <544b86a86d3c2348a59b7eb6f84d3ad8@commonground.com.au> <9B506ECF-BE57-4971-B872-D7DEED2B5AE0@redivi.com> <9c89e2237dcebe98ce8184646910f8b7@commonground.com.au> Message-ID: <67C8901A-A886-4079-8FE3-E52307CB175D@redivi.com> On Feb 2, 2005, at 4:01 AM, Richard Jones wrote: > > On 02/02/2005, at 7:45 PM, Bob Ippolito wrote: >> Creating both a zip and a directory is perfectly normal and expected. >> >> "fails to find some stuff" is probably unrelated. > > More specifically, the "smart" xml.sax.saxexts module fails to find > any parsers for parsing XML. I need to look more closely at what it's > trying to do. I suppose I just need to keep bashing away at things > until I've managed to get the correct combination of packages and > includes args to setup() ;) Yup, you'll need to figure out what it wants, and you'll need to specify it explicitly. Let me know when you're done because some of this might make it into recipes so that it doesn't have to be done again. >> Turning off zip-ification of site-packages wouldn't do you any good >> because py2app chooses which files it wants to put in there. > > Yeah. I did start down the road of implementing the -Z py2app switch, > but that led to pain :) I'd have implemented it by now if it had any benefit whatsoever :) -bob From richard at commonground.com.au Wed Feb 2 10:14:01 2005 From: richard at commonground.com.au (Richard Jones) Date: Wed Feb 2 10:14:08 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <67C8901A-A886-4079-8FE3-E52307CB175D@redivi.com> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <544b86a86d3c2348a59b7eb6f84d3ad8@commonground.com.au> <9B506ECF-BE57-4971-B872-D7DEED2B5AE0@redivi.com> <9c89e2237dcebe98ce8184646910f8b7@commonground.com.au> <67C8901A-A886-4079-8FE3-E52307CB175D@redivi.com> Message-ID: <3d6ec40dc0319d71e7f5fbcfc3bddec4@commonground.com.au> On 02/02/2005, at 8:04 PM, Bob Ippolito wrote: > On Feb 2, 2005, at 4:01 AM, Richard Jones wrote: >> On 02/02/2005, at 7:45 PM, Bob Ippolito wrote: >>> Creating both a zip and a directory is perfectly normal and expected. >>> >>> "fails to find some stuff" is probably unrelated. >> >> More specifically, the "smart" xml.sax.saxexts module fails to find >> any parsers for parsing XML. I need to look more closely at what it's >> trying to do. I suppose I just need to keep bashing away at things >> until I've managed to get the correct combination of packages and >> includes args to setup() ;) > > Yup, you'll need to figure out what it wants, and you'll need to > specify it explicitly. I think it's going to take the rest of the evening to unravel this xml mess. Unfortunately, Zope does entirely too many sys.path fiddles (far less these days) and import hot-patching for my (and, apparently py2app's) liking :) I'll get there though - I *have* to ;) > Let me know when you're done because some of this might make it into > recipes so that it doesn't have to be done again. I've already run into one problem with a recipe - the PIL one assumes the presence of a PIL.pth, and I don't believe I can fiddle things so that's the case, so I'm currently manually editing __boot__.py every time I rebuild the app :) Richard From bob at redivi.com Wed Feb 2 10:21:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 10:21:29 2005 Subject: [Pythonmac-SIG] "Fatal Python error: PyThreadState_Get: no current thread" In-Reply-To: <3d6ec40dc0319d71e7f5fbcfc3bddec4@commonground.com.au> References: <3c08ff665640e4b19297c6d76f859512@commonground.com.au> <544b86a86d3c2348a59b7eb6f84d3ad8@commonground.com.au> <9B506ECF-BE57-4971-B872-D7DEED2B5AE0@redivi.com> <9c89e2237dcebe98ce8184646910f8b7@commonground.com.au> <67C8901A-A886-4079-8FE3-E52307CB175D@redivi.com> <3d6ec40dc0319d71e7f5fbcfc3bddec4@commonground.com.au> Message-ID: <91CE666C-4A25-4A2D-B79F-9FD44AABD4DF@redivi.com> On Feb 2, 2005, at 4:14 AM, Richard Jones wrote: > On 02/02/2005, at 8:04 PM, Bob Ippolito wrote: >> On Feb 2, 2005, at 4:01 AM, Richard Jones wrote: >>> On 02/02/2005, at 7:45 PM, Bob Ippolito wrote: >>>> Creating both a zip and a directory is perfectly normal and >>>> expected. >>>> >>>> "fails to find some stuff" is probably unrelated. >>> >>> More specifically, the "smart" xml.sax.saxexts module fails to find >>> any parsers for parsing XML. I need to look more closely at what >>> it's trying to do. I suppose I just need to keep bashing away at >>> things until I've managed to get the correct combination of packages >>> and includes args to setup() ;) >> >> Yup, you'll need to figure out what it wants, and you'll need to >> specify it explicitly. > > I think it's going to take the rest of the evening to unravel this xml > mess. Unfortunately, Zope does entirely too many sys.path fiddles (far > less these days) and import hot-patching for my (and, apparently > py2app's) liking :) > > I'll get there though - I *have* to ;) > > >> Let me know when you're done because some of this might make it into >> recipes so that it doesn't have to be done again. > > I've already run into one problem with a recipe - the PIL one assumes > the presence of a PIL.pth, and I don't believe I can fiddle things so > that's the case, so I'm currently manually editing __boot__.py every > time I rebuild the app :) modify your sys.path in setup.py and add the PIL directory to it, same thing as a pth. Never ever edit anything inside the bundle after build, that's bad. -bob From charles.hartman at conncoll.edu Wed Feb 2 14:35:46 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Feb 2 14:35:55 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app In-Reply-To: References: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> <46aa402ed231158aa0701f7c722aa1fe@redivi.com> <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> Message-ID: <34e530ecf03cad6310bea84b43978094@conncoll.edu> On Feb 2, 2005, at 1:59 AM, Chris Jerdonek wrote: > Anyways, I double-clicked the hello icon. It appeared on the dock and > immediately collapsed without any output. Is this the desired > behavior? Something the program expects isn't available in your Mac's system. (There are two different "hello.py" examples. One of them imports an Image module. I suppose that *might* be it.) The app gets built all right, because the build process has told it OK, you'll find xyz when you actually run. Apps built for Tcl act this way when Tcl isn't installed on the system. No error message or anything -- except in Console, an app most Mac users are not used to consulting. > This created an executable icon in the Finder called "hello" in a > directory called "dist". Will this always be the stand-alone app? > (From the command line hello.app is a directory, which I don't > understand.) I think you're making the same assumption I did until recently: that an app and a folder are as essentially different as the Mac OS pretends they are. (In Unix, a directory [=folder] is just a special kind of file.) But if you Ctrl-click on any app, the contextual menu will include an item called Show Package Contents. That will show a folder window just like any other Finder folder window, except that its title is the name of the app. It has a folder in it called Contents, and that in turn has several files inside it including one called Info.plist (if you double-click this a special Mac editor comes up; welcome to the wonderful world of XML preference lists, but don't ask *me* for directions). The Contents folder also contains folders called MacOS and Resources. A lot of things you do with py2app have the effect of stuffing one thing or another (an icon file, a data file) into one of these. So an app turns out to be a whole village. Fellow wanderer in benightedness, Charles Hartman From bob at redivi.com Wed Feb 2 14:43:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 14:43:35 2005 Subject: [Pythonmac-SIG] modifying setup.py: py2exe -> py2app In-Reply-To: <34e530ecf03cad6310bea84b43978094@conncoll.edu> References: <07E1FE94-74C4-11D9-9615-000D9335A3AA@davischoicevoting.org> <46aa402ed231158aa0701f7c722aa1fe@redivi.com> <71afa8a9fe957629f6fdb6ecfcc4f9ab@conncoll.edu> <34e530ecf03cad6310bea84b43978094@conncoll.edu> Message-ID: On Feb 2, 2005, at 8:35, Charles Hartman wrote: > > On Feb 2, 2005, at 1:59 AM, Chris Jerdonek wrote: > >> Anyways, I double-clicked the hello icon. It appeared on the dock >> and immediately collapsed without any output. Is this the desired >> behavior? > > Something the program expects isn't available in your Mac's system. > (There are two different "hello.py" examples. One of them imports an > Image module. I suppose that *might* be it.) The app gets built all > right, because the build process has told it OK, you'll find xyz when > you actually run. Apps built for Tcl act this way when Tcl isn't > installed on the system. No error message or anything -- except in > Console, an app most Mac users are not used to consulting. That's not true, py2app presents a GUI dialog for most errors. A missing Python module is certainly one of those errors. Neither of the examples named hello have a GUI dialog of their own, and report information only to the console. >> This created an executable icon in the Finder called "hello" in a >> directory called "dist". Will this always be the stand-alone app? >> (From the command line hello.app is a directory, which I don't >> understand.) > > I think you're making the same assumption I did until recently: that > an app and a folder are as essentially different as the Mac OS > pretends they are. (In Unix, a directory [=folder] is just a special > kind of file.) But if you Ctrl-click on any app, the contextual menu > will include an item called Show Package Contents. That will show a > folder window just like any other Finder folder window, except that > its title is the name of the app. It has a folder in it called > Contents, and that in turn has several files inside it including one > called Info.plist (if you double-click this a special Mac editor comes > up; welcome to the wonderful world of XML preference lists, but don't > ask *me* for directions). The Contents folder also contains folders > called MacOS and Resources. A lot of things you do with py2app have > the effect of stuffing one thing or another (an icon file, a data > file) into one of these. So an app turns out to be a whole village. See the Property List Key Reference: http://developer.apple.com/documentation/MacOSX/Conceptual/ BPRuntimeConfig/Concepts/PListKeys.html -bob From bob at redivi.com Wed Feb 2 19:17:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 2 19:17:42 2005 Subject: [Pythonmac-SIG] ANN: Python 2.3->2.4 "compatibility" package In-Reply-To: References: Message-ID: <3451e8e2117c8b236f91e4ff88be1624@redivi.com> On Nov 29, 2004, at 21:38, Bob Ippolito wrote: > I've put together a quick set of packages that brings a few > new/updated modules from Python 2.4 to Python 2.3: > > Cross-platform: > new subprocess module > new decimal module > > For Mac OS X: > new LaunchServices wrapper > new OSA wrapper > updated QuickTime package I put together a Mac OS X 10.2 version of this package, and gave them more persistent links.. you can find them at: http://bob.pythonmac.org/archives/2005/02/02/python23compat/ -bob From hengist.podd at virgin.net Wed Feb 2 19:48:56 2005 From: hengist.podd at virgin.net (has) Date: Wed Feb 2 19:49:02 2005 Subject: [Pythonmac-SIG] 'Hello World' the OSA Way Message-ID: Hey, Well, it works (with thanks to Jack and Bob for getting me this far;): #!/usr/local/bin/python from Carbon.Cm import OpenDefaultComponent from OSA.OSA import OSAComponentInstance from aem.types import Codecs c=Codecs() ascpt = ''' set s to "hello" & space & "world" say s using "Zarvox" return s ''' ascr = OpenDefaultComponent('osa ', 'ascr') osac = OSAComponentInstance(ascr) print `c.unpack(osac.OSADoScript(c.pack(ascpt), 0L, 'TEXT', 0))` # -> '"hello world"' Sweet. A couple immediate questions for Jack and anyone else who knows: - Do I need to close components manually after use, or is that all done automatically? - There's a bunch of OSAxxxx functions not currently implemented by OSA.so - what's the deal with those? There's a few I've not grokked yet, but I can see several that will be needed to build a comprehensively featured alternative to Cocoa's wimpy NSAppleScript. - Has anyone tested or used the OSA package, written any example scripts, etc. yet? Or am I the first? Ta, has -- http://freespace.virgin.net/hamish.sanderson/ From richard at commonground.com.au Thu Feb 3 01:08:16 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Feb 3 01:08:22 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress Message-ID: <86631c86a2db7b645c60738d88becd79@commonground.com.au> OK, starting at it again this morning, I've made some progress getting things configured correctly to start up Zope. I've hit another roadblock though -- Zope needs to fork/exec off new processes. I can't actually find a Python interpreter in the app generated by py2app, and I suspect one isn't copied in. Certainly, sys.executable is doesn't point to an actual executable. Is this correct? Richard From Chris.Barker at noaa.gov Thu Feb 3 02:10:40 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Feb 3 02:08:48 2005 Subject: [Pythonmac-SIG] Binary Matplotlib package Message-ID: <42017A10.7040505@noaa.gov> Hi all, I think I've successfully build a binary matplotlib package for use with Apple's Python on OS-X 10.3.* In theory the only other thing it requires is Numeric, and I have a package for that too (courtesy of Bob Ippolito). It's almost 5 MB, so I haven't included it here. I also don't have a web site to put it on at the moment, so: A) if you send me a note, I'll send it to you B) if you have a place to host it, please volunteer to do so. I'd like people to test it out, all I know now is that it works on my system. Once it's been better tested, perhaps we can get it put on the sourceforge download page. thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From jdhunter at ace.bsd.uchicago.edu Thu Feb 3 04:07:17 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu Feb 3 04:17:06 2005 Subject: [Pythonmac-SIG] Re: [Matplotlib-users] Binary Matplotlib package In-Reply-To: <42017A10.7040505@noaa.gov> ("Chris Barker"'s message of "Wed, 02 Feb 2005 17:10:40 -0800") References: <42017A10.7040505@noaa.gov> Message-ID: >>>>> "Chris" == Chris Barker writes: Chris> Hi all, I think I've successfully build a binary matplotlib Chris> package for use with Apple's Python on OS-X 10.3.* In Chris> theory the only other thing it requires is Numeric, and I Chris> have a package for that too (courtesy of Bob Ippolito). Chris> It's almost 5 MB, so I haven't included it here. I also Chris> don't have a web site to put it on at the moment, so: Chris> A) if you send me a note, I'll send it to you B) if you Chris> have a place to host it, please volunteer to do so. Chris> I'd like people to test it out, all I know now is that it Chris> works on my system. Chris> Once it's been better tested, perhaps we can get it put on Chris> the sourceforge download page. High Chris, Thanks for doing this. Are either the GTK or Tk GUI backends compiled in. If not, wx* will still work on boxes that have wxpython installed, but it would be a good idea to summarize what is available in the package. Thanks! JDH From bob at redivi.com Thu Feb 3 08:12:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 3 08:12:08 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <86631c86a2db7b645c60738d88becd79@commonground.com.au> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> Message-ID: <9819e9f8e4a1ece36ec8e047161d1364@redivi.com> On Feb 2, 2005, at 19:08, Richard Jones wrote: > OK, starting at it again this morning, I've made some progress getting > things configured correctly to start up Zope. > > I've hit another roadblock though -- Zope needs to fork/exec off new > processes. I can't actually find a Python interpreter in the app > generated by py2app, and I suspect one isn't copied in. Certainly, > sys.executable is doesn't point to an actual executable. Is this > correct? It points to an actual executable, but not what you want. -bob From richard at commonground.com.au Thu Feb 3 08:47:30 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Feb 3 08:47:40 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <9819e9f8e4a1ece36ec8e047161d1364@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <9819e9f8e4a1ece36ec8e047161d1364@redivi.com> Message-ID: <4f714fa546884d099d65acbd1eee2573@commonground.com.au> On 03/02/2005, at 6:12 PM, Bob Ippolito wrote: > On Feb 2, 2005, at 19:08, Richard Jones wrote: >> OK, starting at it again this morning, I've made some progress >> getting things configured correctly to start up Zope. >> >> I've hit another roadblock though -- Zope needs to fork/exec off new >> processes. I can't actually find a Python interpreter in the app >> generated by py2app, and I suspect one isn't copied in. Certainly, >> sys.executable is doesn't point to an actual executable. Is this >> correct? > > It points to an actual executable, but not what you want. Hrm. Printing sys.executable in my script I get "dist/CGPublisher-Zope.app/Contents/Frameworks/Python.framework/ Versions/2.3/bin/python" and that file does not exist on disk. I'm fully willing to accept I'm doing something wrong :) Richard From pecora at anvil.nrl.navy.mil Thu Feb 3 15:18:39 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu Feb 3 15:18:40 2005 Subject: [Pythonmac-SIG] Binary Matplotlib package In-Reply-To: <42017A10.7040505@noaa.gov> References: <42017A10.7040505@noaa.gov> Message-ID: <420232BF.9080705@anvil.nrl.navy.mil> Chris Barker wrote: > Hi all, > > I think I've successfully build a binary matplotlib package for use > with Apple's Python on OS-X 10.3.* In theory the only other thing it > requires is Numeric, and I have a package for that too (courtesy of > Bob Ippolito). > > It's almost 5 MB, so I haven't included it here. I also don't have a > web site to put it on at the moment, so: > > A) if you send me a note, I'll send it to you > B) if you have a place to host it, please volunteer to do so. > > I'd like people to test it out, all I know now is that it works on my > system. > > Once it's been better tested, perhaps we can get it put on the > sourceforge download page. > > thanks, > -Chris Chris, I'd be happy to test it out. I've been looking into installing matplotlib on my PowerBook (system 10.3), but it is daunting since there's so much that it seems to need all working together (this is one problem I have with the way Python is implemented as open source, but that's for a later venting :-) -- nothing against open source, certainly, and I Love Python ). You can send it to me. Even though I'm on travel my dialup should be able to handle it (at 5 MB it should take about 10 to 15 minutes -- maybe optimistic, but what the heck). I really want a plotting package to round out my Python numerical calculation code. If you have information on what you did to get it all to work together, please include that -- assuming you don't mind sharing that information. I would love to host it, but my employer (the US Government) won't let me do that. Thanks for doing this. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From bob at redivi.com Thu Feb 3 15:34:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 3 15:34:11 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <4f714fa546884d099d65acbd1eee2573@commonground.com.au> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <9819e9f8e4a1ece36ec8e047161d1364@redivi.com> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> Message-ID: <5cc801f2647e9f10d3bacc18892118d9@redivi.com> On Feb 3, 2005, at 2:47, Richard Jones wrote: > On 03/02/2005, at 6:12 PM, Bob Ippolito wrote: >> On Feb 2, 2005, at 19:08, Richard Jones wrote: >>> OK, starting at it again this morning, I've made some progress >>> getting things configured correctly to start up Zope. >>> >>> I've hit another roadblock though -- Zope needs to fork/exec off new >>> processes. I can't actually find a Python interpreter in the app >>> generated by py2app, and I suspect one isn't copied in. Certainly, >>> sys.executable is doesn't point to an actual executable. Is this >>> correct? >> >> It points to an actual executable, but not what you want. > > Hrm. Printing sys.executable in my script I get > "dist/CGPublisher-Zope.app/Contents/Frameworks/Python.framework/ > Versions/2.3/bin/python" and that file does not exist on disk. I'm > fully willing to accept I'm doing something wrong :) No, py2app just doesn't give you a regular Python interpreter.. so, that's a problem I guess. I'm not sure what to suggest. -bob From rroberts at adobe.com Thu Feb 3 18:58:21 2005 From: rroberts at adobe.com (Read Roberts) Date: Thu Feb 3 18:58:33 2005 Subject: [Pythonmac-SIG] Why does all threads block when doing I/O to unreachable network device on Mac OSX? Message-ID: In writing a replacement for tkDialog.askdirname() (needed because this is not Kanji -capable on Windows), I needed to work around a problem where os.listdir() will block indefinitely when a volume is not reachable. Looking for a cross-platform solution, I tried doing the os.lsitdir() within a thread, and then from the main thread, calling getdirThread.join(), so I can continue without waiting for the network time-out. On Windows this works fine, for both floppy drives and mapped network drives that are not reachable. However, on Mac OS X, if I mount a network volume, and then shut-down the network, the entire process seems to block: a print statement in the main thread never gets executed, that is right after getdirThread.run() and before getdirThread.join(). Thanks for any advice. From charles.hartman at conncoll.edu Thu Feb 3 20:21:36 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Feb 3 20:21:45 2005 Subject: [Pythonmac-SIG] simple setup.py-for-Windows question Message-ID: <997a861a19440af27a0a479f8b9b8e80@conncoll.edu> Sorry, simpleton time again! I've gotten the Mac app to build OK with py2app, but now I'm trying to get my newest project ready for first tests on Windows and running into a problem. My setup.py contains the line data_files = ['ScansionDictionary'], and one of my modules contains the line self.Dict = pickle.load(open('ScansionDictionary', 'rU')) On Mac, this combination puts the data file inside Resources (inside Contents inside my app's bundle). On Windows it puts the file in the same ('dist') directory as the executable. (Is there a better, more integrated way to do it on Windows?) And when I try to run the executabble the pickle.load line generates this: "LookupError: no codec search functions registered: can't find encoding". How do I fix this? Maybe a connnected question: what is the relation between the 'data_files' argument in a setup.py file (as ordained by distutils), and the 'resources' option to py2app? Charles Hartman From bob at redivi.com Thu Feb 3 20:33:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 3 20:33:11 2005 Subject: [Pythonmac-SIG] simple setup.py-for-Windows question In-Reply-To: <997a861a19440af27a0a479f8b9b8e80@conncoll.edu> References: <997a861a19440af27a0a479f8b9b8e80@conncoll.edu> Message-ID: On Feb 3, 2005, at 14:21, Charles Hartman wrote: > Sorry, simpleton time again! I've gotten the Mac app to build OK with > py2app, but now I'm trying to get my newest project ready for first > tests on Windows and running into a problem. My setup.py contains the > line > data_files = ['ScansionDictionary'], > and one of my modules contains the line > self.Dict = pickle.load(open('ScansionDictionary', 'rU')) > On Mac, this combination puts the data file inside Resources (inside > Contents inside my app's bundle). On Windows it puts the file in the > same ('dist') directory as the executable. (Is there a better, more > integrated way to do it on Windows?) And when I try to run the > executabble the pickle.load line generates this: "LookupError: no > codec search functions registered: can't find encoding". How do I fix > this? There is no more integrated way to do it on Windows. py2app always automatically includes unicode support (among other things that the python internals may want), py2exe does not make any such effort to reliably produce working applications on your behalf :) See: (found by googling for: "no codec search functions registered" py2exe) > Maybe a connnected question: what is the relation between the > 'data_files' argument in a setup.py file (as ordained by distutils), > and the 'resources' option to py2app? data_files is a distutils option, and resources is a py2app option. The latter is in there because it's necessary in order to specify resources on the command line. They do the same thing, though. It's somewhat questionable that data_files is used for that purpose at all... but py2exe does it, so py2app does it too. -bob From thomas at eforms.co.nz Thu Feb 3 20:08:01 2005 From: thomas at eforms.co.nz (Thomas) Date: Fri Feb 4 00:00:48 2005 Subject: [Pythonmac-SIG] menu bar missing mac+py2app Message-ID: <20050203190638.61C6D379B4@mail.tintz.co.nz> Hi All, I am using > Mac OS X 10.3 > Python 2.3 one shipped with panther > MacPython-Panther-2.3 > wxPythonOSX-2.4.2.4-py2.3-panther.dmg > py2app-0.1.7.mpkg When I run my app script using python my menu bar is missing. When I use pythonw it's working fine. Using py2app I created a standalone application, but menu bar is missing in it. I realize that macs menu bar has been an issue for quite a while. I had a chat with bob(who wrote py2app) and he points this as issue with the my code or wxPython code. As pythonw is a shell script that runs a Python interpreter inside of an application bundle; the py2app bootstrap *is* a python interpreter inside of an application bundle. Can anyone tell me what's going wrong here. Or how should I proceed to locate this bug. Thanks in advance Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050204/ad49c356/attachment.htm From bob at redivi.com Fri Feb 4 00:25:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 4 00:25:25 2005 Subject: [Pythonmac-SIG] menu bar missing mac+py2app In-Reply-To: <20050203190638.61C6D379B4@mail.tintz.co.nz> References: <20050203190638.61C6D379B4@mail.tintz.co.nz> Message-ID: On Feb 3, 2005, at 14:08, Thomas wrote: > When I run my app script using python my menu bar is missing. > > When I use pythonw it?s working fine. > > Using py2app I created a standalone application, but menu bar is > missing in it. > > I realize that macs menu bar has been an issue for quite a while. > > I had a chat with bob(who wrote py2app) and he points this as issue > with the my code or wxPython code. > As pythonw is a shell script that runs a Python interpreter inside of > an application bundle; the py2app bootstrap *is* a python interpreter > inside of an application bundle. > > Can anyone tell me what?s going wrong here. ?Or how should I proceed > to locate this bug. This is, without a doubt, a bug with wxPython 2.4 or the code that is using it. I *was* able to get his program to work as expected by changing some of the menu initialization code, and I sent it to him off-list, but apparently it doesn't work for him. Also, the example trivially ported to wxPython 2.5 also does not have this problem, but he can't or won't port to wxPython 2.5. -bob From Chris.Barker at noaa.gov Fri Feb 4 01:07:06 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Feb 4 01:07:10 2005 Subject: [Pythonmac-SIG] matplotlib OS-X binary problems. Message-ID: <4202BCAA.3010407@noaa.gov> Hi all, I posted a note here the other day about a matplotlib binary. I've discovered a problem with it. Apparently, it has linked against the libfreetype in /usr/X11. That means it will work fine on a system with Apple's X11 installed (like mine or the first system I tested it on). So, the question remains: How to I get distutils to statically link selected libs? Bob had suggested: """Make sure you don't have libpng.dylib or libfreetype.dylib sitting around on your link paths... Build them like this: ./configure --disable-shared --enable static Make sure you only have libpng.a and libfreetype.a on your link paths. It will link statically. """ However, that doesn't seem to work if I have libfreetype.dylib somewhere standard, and I certainly don't want to remove it! (Maybe I could temporarily, but that's hardly the robust solution I'm looking for) By the way, it would also be good to get this to work with TK and/or GTK. Has anyone done that successfully that would like to help out with this? Also, as far as PyGTK is concerned. Can you run it without running Fink? That's the only way I've seen it done. If it is a Fink only option, then this is moot, as I'm looking for a Fink free approach, and someone else has put together a fink matplotlib package. By the way the package, as it stands, can be found at: http://undefined.org/python/matplotlib-0.71-py2.3-macosx10.3.zip thanks to Bob Ippolito -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Fri Feb 4 01:27:14 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 4 01:27:19 2005 Subject: [Pythonmac-SIG] matplotlib OS-X binary problems. In-Reply-To: <4202BCAA.3010407@noaa.gov> References: <4202BCAA.3010407@noaa.gov> Message-ID: <16e8d6e55dcd576fae46843c030fea4e@redivi.com> On Feb 3, 2005, at 19:07, Chris Barker wrote: > I posted a note here the other day about a matplotlib binary. I've > discovered a problem with it. Apparently, it has linked against the > libfreetype in /usr/X11. That means it will work fine on a system with > Apple's X11 installed (like mine or the first system I tested it on). .. and the system that I tested it on :) > So, the question remains: How to I get distutils to statically link > selected libs? Bob had suggested: > > """Make sure you don't have libpng.dylib or libfreetype.dylib sitting > around on your link paths... > > Build them like this: > ./configure --disable-shared --enable static > > Make sure you only have libpng.a and libfreetype.a on your link paths. > It will link statically. > """ > > However, that doesn't seem to work if I have libfreetype.dylib > somewhere standard, and I certainly don't want to remove it! (Maybe I > could temporarily, but that's hardly the robust solution I'm looking > for) You have three options: - make sure the dylibs aren't sitting around in the same location as the .a, and make sure the .a's path is preferred (you could make a local dir, -L to it, symlink the archives in) - change the setup.py relatively significantly and specify them as object files with their full path (I can't tell you off the top of my head what the distutils incantation would be for this, but you definitely can not use it's "libraries" option, or whatever that is called) - don't link statically and install the dylibs too, somehow (possibly by building+installing them with --prefix=/Library/Python/2.3/matplotlib/lib-dynload/ and -L to that when linking.. note that this would require a bdist_mpkg subclass to make a .pkg out of it) -bob From richard at commonground.com.au Fri Feb 4 01:58:32 2005 From: richard at commonground.com.au (Richard Jones) Date: Fri Feb 4 01:58:44 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <5cc801f2647e9f10d3bacc18892118d9@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> Message-ID: <200502041158.32890.richard@commonground.com.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Feb 2005 01:34 am, Bob Ippolito wrote: > No, py2app just doesn't give you a regular Python interpreter.. so, > that's a problem I guess. I'm not sure what to suggest. Yep, looks like it's the killer for the py2app'ed Zope. I'm going to investigate another approach of using os.system() to control Zope, but that's not nearly as nice as it doesn't let me at the zdaemon control code directly (I'll have to parse shell command output instead) and bundle a second Python interpreter with the app. Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCAsi4rGisBEHG6TARAmYRAJ0ZytsiZadkqah9Cgv4/lwMQcKMxACfaweT zmP1r2Isnh5beU0DJwWNjk4= =Js6g -----END PGP SIGNATURE----- From bob at redivi.com Fri Feb 4 02:05:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 4 02:05:36 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <200502041158.32890.richard@commonground.com.au> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> Message-ID: On Feb 3, 2005, at 19:58, Richard Jones wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 4 Feb 2005 01:34 am, Bob Ippolito wrote: >> No, py2app just doesn't give you a regular Python interpreter.. so, >> that's a problem I guess. I'm not sure what to suggest. > > Yep, looks like it's the killer for the py2app'ed Zope. > > I'm going to investigate another approach of using os.system() to > control > Zope, but that's not nearly as nice as it doesn't let me at the zdaemon > control code directly (I'll have to parse shell command output > instead) and > bundle a second Python interpreter with the app. Well the problem with this is that the Python you bundle probably won't have its headers rewritten properly and will potentially link to a Python that is outside of the application bundle and just blow up. I'll see about adding an optional regular Python interpreter to the bundle, but that probably won't happen for a few weeks. -bob From Chris.Barker at noaa.gov Fri Feb 4 02:07:02 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Feb 4 02:07:06 2005 Subject: [Matplotlib-users] Re: [Pythonmac-SIG] matplotlib OS-X binary problems. In-Reply-To: <16e8d6e55dcd576fae46843c030fea4e@redivi.com> References: <4202BCAA.3010407@noaa.gov> <16e8d6e55dcd576fae46843c030fea4e@redivi.com> Message-ID: <4202CAB6.1030901@noaa.gov> Bob Ippolito wrote: > You have three options: > - make sure the dylibs aren't sitting around in the same location as the > .a, and make sure the .a's path is preferred (you could make a local > dir, -L to it, symlink the archives in) I'm going to give this a try. > - change the setup.py relatively significantly and specify them as > object files with their full path This strikes me as very non-portable. Ideally, I'd like to be able to easily re-do this whenever a new version comes out, and even have it be in the standard distro's setup.py > - don't link statically and install the dylibs too, somehow (possibly by > building+installing them with > --prefix=/Library/Python/2.3/matplotlib/lib-dynload/ and -L to that when > linking.. note that this would require a bdist_mpkg subclass to make a > .pkg out of it) This may be a good option, but then I'd need to figure out bdist_mpkg. I don't suppose you're volunteering? By the way, how can I tell what a given lib I've just built is expecting to link against? I can do this with ldd on linux. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Fri Feb 4 02:13:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 4 02:13:17 2005 Subject: [Matplotlib-users] Re: [Pythonmac-SIG] matplotlib OS-X binary problems. In-Reply-To: <4202CAB6.1030901@noaa.gov> References: <4202BCAA.3010407@noaa.gov> <16e8d6e55dcd576fae46843c030fea4e@redivi.com> <4202CAB6.1030901@noaa.gov> Message-ID: <20ba3ee93fb0f59ec44198313fa31de0@redivi.com> On Feb 3, 2005, at 20:07, Chris Barker wrote: > Bob Ippolito wrote: > >> You have three options: >> - make sure the dylibs aren't sitting around in the same location as >> the .a, and make sure the .a's path is preferred (you could make a >> local dir, -L to it, symlink the archives in) > > I'm going to give this a try. > >> - change the setup.py relatively significantly and specify them as >> object files with their full path > > This strikes me as very non-portable. Ideally, I'd like to be able to > easily re-do this whenever a new version comes out, and even have it > be in the standard distro's setup.py it works with any GCC on any platform... >> - don't link statically and install the dylibs too, somehow (possibly >> by building+installing them with >> --prefix=/Library/Python/2.3/matplotlib/lib-dynload/ and -L to that >> when linking.. note that this would require a bdist_mpkg subclass to >> make a .pkg out of it) > > This may be a good option, but then I'd need to figure out bdist_mpkg. > I don't suppose you're volunteering? Not for at least a week or two... it would be a Good Thing To Support in general, but I have other things on my plate. > By the way, how can I tell what a given lib I've just built is > expecting to link against? I can do this with ldd on linux. otool -L -bob From thomas at eforms.co.nz Fri Feb 4 03:07:58 2005 From: thomas at eforms.co.nz (Thomas) Date: Fri Feb 4 03:06:54 2005 Subject: [Pythonmac-SIG] menu bar missing mac+py2app Message-ID: <20050204020636.52FCE3790A@mail.tintz.co.nz> Hi Bob, I have simplified my script. from wxPython.wx import * ID_LOGIN=101 ID_OPEN=102 ID_ABOUT=109 ID_EXIT=110 class MainWindow(wxFrame): def __init__(self,parent,id,title): wxFrame.__init__(self,parent,wxID_ANY, title, size = ( 800,600), style=wxDEFAULT_FRAME_STYLE|wxNO_FULL_REPAINT_ON_RESIZE) # Setting up the menu. filemenu= wxMenu() filemenu.Append(ID_LOGIN, "&Login"," Please login to Upload files") filemenu.AppendSeparator() filemenu.Append(ID_OPEN, "&Open"," Browse directories/files") filemenu.AppendSeparator() filemenu.Append(ID_ABOUT, "&About"," Information about this program") filemenu.AppendSeparator() filemenu.Append(ID_EXIT,"E&xit"," Terminate the program") # Creating the menubar. menuBar = wxMenuBar() menuBar.Append(filemenu,"&File") # Adding the "filemenu" to the MenuBar self.SetMenuBar(menuBar) # Adding the MenuBar to the Frame content. self.Show(true) app = wxPySimpleApp() frame = MainWindow(None, -1, "Menu Client") app.MainLoop() This script works fine when I run it with pythonw.. Is the Python interpreter pointed by pythonw & /usr/bin/python one & the same. The menu is still missing when create an application using py2app.. Regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050204/811c512f/attachment.htm From bob at redivi.com Fri Feb 4 04:15:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 4 04:15:41 2005 Subject: [Pythonmac-SIG] menu bar missing mac+py2app In-Reply-To: <20050203190638.61C6D379B4@mail.tintz.co.nz> References: <20050203190638.61C6D379B4@mail.tintz.co.nz> Message-ID: On Feb 3, 2005, at 14:08, Thomas wrote: > I am using > > Mac OS X 10.3 > > Python? 2.3 one shipped with panther > > MacPython-Panther-2.3 > > wxPythonOSX-2.4.2.4-py2.3-panther.dmg > > py2app-0.1.7.mpkg > > When I run my app script using python my menu bar is missing. > > When I use pythonw it?s working fine. > > Using py2app I created a standalone application, but menu bar is > missing in it. After looking at a ktrace of the app, just to see if anything fishy was going on, I figured out that wxWidgets 2.4 expects a file to be present in a particular place and doesn't bother to tell you when it's not there. Awesome, good work guys ;) Try this: from distutils.core import setup import py2app setup( app=['test.py'], data_files=[('../Frameworks', [ '/usr/local/lib/libwx_mac-2.4.0.rsrc', ] )], ) -bob From thomas at eforms.co.nz Fri Feb 4 05:25:08 2005 From: thomas at eforms.co.nz (Thomas) Date: Fri Feb 4 05:41:46 2005 Subject: [Pythonmac-SIG] menu bar missing mac+py2app Message-ID: <20050204042347.357183790A@mail.tintz.co.nz> Yup that was it bob .. you got that right. now everything is in place -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050204/c3b5bfbf/attachment.html From rkern at ucsd.edu Fri Feb 4 06:17:42 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Feb 4 06:17:46 2005 Subject: [Pythonmac-SIG] Re: [Matplotlib-users] matplotlib OS-X binary problems. In-Reply-To: <4202BCAA.3010407@noaa.gov> References: <4202BCAA.3010407@noaa.gov> Message-ID: <42030576.9010701@ucsd.edu> Chris Barker wrote: > However, that doesn't seem to work if I have libfreetype.dylib somewhere > standard, and I certainly don't want to remove it! (Maybe I could > temporarily, but that's hardly the robust solution I'm looking for) Change the paths that distutils will add to the link line. They're at the top of setupext.py . Remove the ones you don't need. > By the way, it would also be good to get this to work with TK and/or > GTK. Has anyone done that successfully that would like to help out with > this? With TclTkAqua, it Just Works. > Also, as far as PyGTK is concerned. Can you run it without running Fink? > That's the only way I've seen it done. If it is a Fink only option, then > this is moot, as I'm looking for a Fink free approach, and someone else > has put together a fink matplotlib package. You could try Darwinports. Set Darwinports' prefix to /usr/local, and use port(1) to make Installer.app packages for GTK et al. Bundle them with your bdist_mpkg metapackage. My strategy for building matplotlib (and I've done it *a lot* in the past few weeks) is as follows: I have Darwinports with a prefix in a GNU Stow repository. What Stow does is it allows you to install stuff into it's own directory (/usr/local/stow/darwinports, which has bin/, lib/, share/ et al.) and then makes symlinks such that everything appears to be installed to /usr/local. So I have Darwinports install libpng and libfreetype. I have a script that will remove the symlinks to the dylibs for libpng, libfreetype, and libz (I could probably resolve this by changing the order of search). I build matplotlib and double-check the dylib dependencies with "otool -L". I do not bother with GTK at this time. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From richard at commonground.com.au Fri Feb 4 06:43:54 2005 From: richard at commonground.com.au (Richard Jones) Date: Fri Feb 4 06:44:01 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> Message-ID: On 04/02/2005, at 12:05 PM, Bob Ippolito wrote: > I'll see about adding an optional regular Python interpreter to the > bundle, but that probably won't happen for a few weeks. No sweat - I've just introduced our target users to running Zope from the command-line which will suffice for now :) Richard From rogerb at rogerbinns.com Fri Feb 4 08:09:12 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 4 08:09:09 2005 Subject: [Pythonmac-SIG] simple setup.py-for-Windows question References: <997a861a19440af27a0a479f8b9b8e80@conncoll.edu> Message-ID: <002001c50a88$7095c260$3501a8c0@rogersqyvr14d3> If anyone wants a reference, have a look at makedist.py in the BitPim source. It produces a py2app application on Mac, a RPM via cx-Freeze on Linux and setup.exe via InnoSetup and py2exe on Windows. http://cvs.sf.net/viewcvs.py/bitpim/bitpim/makedist.py?view=markup Auxiliary files such as help, images etc are in the resources subdirectory (nothing to do with Mac resources or bundles). It would be nice if cx-Freeze, py2exe and py2app were all unified and it does seem like small steps are happening in that direction. Roger From bob at redivi.com Fri Feb 4 08:40:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 4 08:40:53 2005 Subject: [Pythonmac-SIG] simple setup.py-for-Windows question In-Reply-To: <002001c50a88$7095c260$3501a8c0@rogersqyvr14d3> References: <997a861a19440af27a0a479f8b9b8e80@conncoll.edu> <002001c50a88$7095c260$3501a8c0@rogersqyvr14d3> Message-ID: <460afafd9a31f815084032f31a61cfb6@redivi.com> On Feb 4, 2005, at 2:09, Roger Binns wrote: > If anyone wants a reference, have a look at makedist.py in > the BitPim source. It produces a py2app application on Mac, > a RPM via cx-Freeze on Linux and setup.exe via InnoSetup and > py2exe on Windows. > > http://cvs.sf.net/viewcvs.py/bitpim/bitpim/makedist.py?view=markup > > Auxiliary files such as help, images etc are in the resources > subdirectory (nothing to do with Mac resources or bundles). > > It would be nice if cx-Freeze, py2exe and py2app were all > unified and it does seem like small steps are happening > in that direction. PJE and I are working on something called eggs , which would certainly advance the state of application bundling, among other things. py2app will probably be the first thing to use them. -bob From rowen at cesmail.net Fri Feb 4 18:57:12 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Feb 4 18:58:26 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? Message-ID: I've seen a lot of discussion lately about fink and darwinports and I'm wondering if folks who have experience with either can comment on their relative merits? I've been building everything from source and am getting a bit tired of it. Many of the packages have some painful gotcha that has to be worked out (and some I've never worked out, such as installing snack for my unix/x11 tcl/tk + python). I installed and deleted fink a few times years ago, each time giving up in frustration because the stuff in the "stable" area was so outdated. I now realize if I want to use fink I have to be prepared to use the "unstable" packages. DarwinPorts seems to have fewer packages (for example no scipy). On the other hand, it has more current released stuff. There are some advantages to doing it myself (despite the pain): - If a package I want isn't available any other way, I'm more likely to be able to build it myself if I've built everything else myself. Because I'll have a lot of the standard prerequisites already built and because I'll have some experience. - (Also, does using binaries means I'm less likely to get code optimized for my system?) I hope this doesn't start a flame war, but I would be very interested in any insights people have as to the relative merits of the various systems. Regards, -- Russell From Chris.Barker at noaa.gov Fri Feb 4 19:17:53 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Feb 4 19:17:57 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: References: Message-ID: <4203BC51.2070409@noaa.gov> Russell E. Owen wrote: > I've seen a lot of discussion lately about fink and darwinports and I'm > wondering if folks who have experience with either can comment on their > relative merits? While we're at it, let's add Gentoo/Portage to the mix. I have been very impressed with Gentoo Linux, but haven't tried portage for OS-X yet. By the way, my personal criteria is that I want it to "play well" with Apple's stuff. I do not want a system within a system, which is what finks seems to do. For example, I want it to use Apple's supplied Python and X11. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Fri Feb 4 23:19:25 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Feb 4 23:19:28 2005 Subject: [Pythonmac-SIG] Re: [Matplotlib-users] matplotlib OS-X binary problems. In-Reply-To: <42030576.9010701@ucsd.edu> References: <4202BCAA.3010407@noaa.gov> <42030576.9010701@ucsd.edu> Message-ID: <4203F4ED.1000302@noaa.gov> Robert Kern wrote: > Chris Barker wrote: >> However, that doesn't seem to work if I have libfreetype.dylib >> somewhere standard, and I certainly don't want to remove it! (Maybe I >> could temporarily, but that's hardly the robust solution I'm looking for) > > Change the paths that distutils will add to the link line. They're at > the top of setupext.py . Remove the ones you don't need. Except that the *.a and *.dylib are put in the same place. Darn. >> By the way, it would also be good to get this to work with TK and/or >> GTK. Has anyone done that successfully that would like to help out >> with this? > With TclTkAqua, it Just Works. Someone posted recently to the MacPython Mailing list with a series of questions that this was not the case, at least to for him. So I wasn't sure. >> Also, as far as PyGTK is concerned. Can you run it without running >> Fink? That's the only way I've seen it done. If it is a Fink only >> option, then this is moot, as I'm looking for a Fink free approach, >> and someone else has put together a fink matplotlib package. > You could try Darwinports. Set Darwinports' prefix to /usr/local, and > use port(1) to make Installer.app packages for GTK et al. Bundle them > with your bdist_mpkg metapackage. Hmm. That sounds promising. However... My immediate need to to get matplotlib installed on and OS-X Server box that someone else is administering. For this purpose, I only need the Agg back end. However, for my own purposes, I also want wx. The easiest way for me to accomplish my immediate goal is probably to just install all the libs needed on that server, but I'm trying to keep it simple for the admin, and I figured this could be a useful contribution to the MacPython community. However, here is the complication. As long as I am doing this, I'd like to make it as useful as possible. That means it would be nice if I could come up with a single binary that works with all the available back ends on OS-X (Agg, wx, PyGTK, Tkinter). I also want people to be able to install it on a stock box and have it work. This doesn't mean that I want it to include PyGTK and TK, but it would be nice if it worked with those, if they were present. The question is: Can I build a binary version that will work with all the back ends, if they are there, but also work on what is there if they aren't all. This comes down to when the linking happens, I guess. Experimentation will answer this for me, but I welcome and insight any of you may have. One issue that has come up is libfreetype. If you have GTK, you have X11, so you have libfreetype. Indeed, I don't have GTK, but I do have X11, and the X11 freetype got linked to my package. I can probably fix this by removing "/usr/X11R6" from the basedir list for darwin. Then I'll have libfreetype statically linked to matplotlib, but PyGTK, if the user has it, will have a different version dynamically linked. Is this going to cause problems? More as I make more 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@noaa.gov From jdhunter at ace.bsd.uchicago.edu Fri Feb 4 23:28:59 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri Feb 4 23:38:57 2005 Subject: [Pythonmac-SIG] Re: [Matplotlib-users] matplotlib OS-X binary problems. In-Reply-To: <4203F4ED.1000302@noaa.gov> ("Chris Barker"'s message of "Fri, 04 Feb 2005 14:19:25 -0800") References: <4202BCAA.3010407@noaa.gov> <42030576.9010701@ucsd.edu> <4203F4ED.1000302@noaa.gov> Message-ID: >>>>> "Chris" == Chris Barker writes: Chris> The question is: Can I build a binary version that will Chris> work with all the back ends, if they are there, but also Chris> work on what is there if they aren't all. This comes down Chris> to when the linking happens, I guess. Experimentation will Chris> answer this for me, but I welcome and insight any of you Chris> may have. Chris> One issue that has come up is libfreetype. If you have GTK, Chris> you have X11, so you have libfreetype. Indeed, I don't have Chris> GTK, but I do have X11, and the X11 freetype got linked to Chris> my package. I can probably fix this by removing Chris> "/usr/X11R6" from the basedir list for darwin. Then I'll Chris> have libfreetype statically linked to matplotlib, but Chris> PyGTK, if the user has it, will have a different version Chris> dynamically linked. Is this going to cause problems? Here is what I do for the win32 which has some related issues. matplotlib needs Tkinter and pygtk to be installed on your build system in order to build the matplotlib extension code for those modules. But you do not need to statically link in any gtk or tk library code. I do statically link png, freetype and zlib for win32 so that users don't have to install any of those prereqs. Then they get a package that has Agg, PS, SVG out of the box regardless of their system. If they have pygtk on their system, they also get GTK and GTKAgg. If they have Tkinter, they also get TkAgg. If they have wxpython, they also get WX, WXAgg. The key is, if you want your package to be maximally usable, you should have pygtk and tk (and the requisite devel stuff) and should probably statically link freetype, png and zlib. Of course there is now also a Cairo and GTKCairo backend, which may interest some OSX X11 users, but I haven't had to worry about this for win32 users. And FLTK and QT ..., but we can save that for another day. I think if you have the tkagg extension compiled in, most OSX people will be happy with either that or wxagg. JDH From Chris.Barker at noaa.gov Sat Feb 5 00:09:12 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Sat Feb 5 00:09:15 2005 Subject: [Pythonmac-SIG] Re: [Matplotlib-users] matplotlib OS-X binary problems. In-Reply-To: References: <4202BCAA.3010407@noaa.gov> <42030576.9010701@ucsd.edu> <4203F4ED.1000302@noaa.gov> Message-ID: <42040098.9010009@noaa.gov> John Hunter wrote: > I do statically link png, freetype and zlib for win32 so that users > don't have to install any of those prereqs. Thanks John, I have a plan now. I have a question, however. How do I get distutils to statically link a given lib? the only method I have now is to make sure that only the static lib is available. I can do that (for the moment) with libpng, but for freetype, I have a problem. In setupext.py, there is: basedir = { 'darwin' : ['/usr/local', '/usr', '/sw', '/usr/X11R6'], } There is a libfreetype in /usr/X11R6, but only if X11 is installed, so I don't want to use it. However, I imagine that /usr/X11R6 is required to the GTK build, so I can't take that out. Any ideas? I notice that for win32, you have only: basedir = { 'win32' : ['win32_static',], Should I do that for darwin, and put my static libs in there? I'm off to try some of 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@noaa.gov From jerdonek at davischoicevoting.org Sat Feb 5 03:16:59 2005 From: jerdonek at davischoicevoting.org (Chris Jerdonek) Date: Sat Feb 5 03:16:58 2005 Subject: [Pythonmac-SIG] py2app basics Message-ID: <0454600F-771C-11D9-B939-000D9335A3AA@davischoicevoting.org> Hi, I'm trying to use py2app on an open-source program that I basically understand the workings of, but didn't write. I've tried "python setup.py py2app" several times, but it doesn't work. I get error messages like the one below, when I click on the resulting app icon: An unexpected error has occurred during execution of the main script IOError: [Errno 2] No such file or directory: '-psn_0_42205185 Where do I start? I really don't know the principle behind the setup.py file, what it does, what py2app does, what needs to be in setup.py for things to work, etc. How can I tell? I've checked out a few of the sample files, but I don't see how they apply to my situation. The program uses wxPython if that matters. I'm using OSX 10.3.7 and Python 2.3. I'm not an experienced programmer, but I can learn fast. It's just hard without documentation. (Maybe py2app is intended for people that already know what they're doing) Anyways, I'm glad py2app is out there for people. Ok, thanks a lot for anything to help get me started. CHRIS From bob at redivi.com Sat Feb 5 07:59:21 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 5 07:59:31 2005 Subject: [Pythonmac-SIG] py2app basics In-Reply-To: <0454600F-771C-11D9-B939-000D9335A3AA@davischoicevoting.org> References: <0454600F-771C-11D9-B939-000D9335A3AA@davischoicevoting.org> Message-ID: <765F4435-7743-11D9-B40C-000A95C93D30@redivi.com> On Feb 4, 2005, at 9:16 PM, Chris Jerdonek wrote: > Hi, I'm trying to use py2app on an open-source program that I > basically understand the workings of, but didn't write. > > I've tried "python setup.py py2app" several times, but it doesn't > work. I get error messages like the one below, when I click on the > resulting app icon: > > An unexpected error has occurred during execution of the main script > IOError: [Errno 2] No such file or directory: '-psn_0_42205185 > > Where do I start? I really don't know the principle behind the > setup.py file, what it does, what py2app does, what needs to be in > setup.py for things to work, etc. How can I tell? I've checked out a > few of the sample files, but I don't see how they apply to my > situation. The program uses wxPython if that matters. I'm using OSX > 10.3.7 and Python 2.3. > > I'm not an experienced programmer, but I can learn fast. It's just > hard without documentation. (Maybe py2app is intended for people that > already know what they're doing) Anyways, I'm glad py2app is out > there for people. Ok, thanks a lot for anything to help get me > started. py2app doesn't have documentation yet[1] because I haven't had the time and interest to write it. I'm more interested in implementing the features on my TODO list right now. I released it because it's very useful and much better than the poorly documented and much more fragile and incorrect alternative(s). If someone else writes such documentation, I will gladly accept it. In your specific case you are trying to use a script that expects command-line arguments. Mac OS X's LaunchServices does not provide command line arguments useful to anything but the Carbon/Cocoa runtimes, so you have two choices: (a) don't use sys.argv (b) use py2app with --argv-emulation, which will hide the -psn argument from Python and will convert any dropped files into command-line arguments. [1] python setup.py py2app --help does yield some usage information, and there are quite a few examples between the py2app and PyObjC sources. -bob From bac at OCF.Berkeley.EDU Sat Feb 5 08:32:58 2005 From: bac at OCF.Berkeley.EDU (Brett C.) Date: Sat Feb 5 08:34:39 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: References: Message-ID: <420476AA.8070606@ocf.berkeley.edu> Russell E. Owen wrote: > I've seen a lot of discussion lately about fink and darwinports and I'm > wondering if folks who have experience with either can comment on their > relative merits? > I personally have run Fink in the past multiple times and always end up deleting it in the end. DarwinPorts, on the other hand, I have yet to uninstall. The package config files are easy to read by eye (it is basically Tcl code). I also just like how the system is set up using the command line; never liked how Fink works that way. And their idea of activation (can have multiple installs of the same thing with different configs; just activate to choose which one to use) is nice. Plus having Jordan Hubbard on the team is nice (former member of FreeBSD who now works at Apple for those who don't know). =) -Brett From piet at cs.uu.nl Sat Feb 5 11:57:01 2005 From: piet at cs.uu.nl (Piet van Oostrum) Date: Sat Feb 5 11:57:11 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <420476AA.8070606@ocf.berkeley.edu> (Brett C.'s message of "Fri, 04 Feb 2005 23:32:58 -0800") References: <420476AA.8070606@ocf.berkeley.edu> Message-ID: >>>>> "Brett C." (BC) wrote: >BC> Russell E. Owen wrote: >>> I've seen a lot of discussion lately about fink and darwinports and I'm >>> wondering if folks who have experience with either can comment on their >>> relative merits? >>> >BC> I personally have run Fink in the past multiple times and always end up >BC> deleting it in the end. DarwinPorts, on the other hand, I have yet to >BC> uninstall. The package config files are easy to read by eye (it is >BC> basically Tcl code). I also just like how the system is set up using the >BC> command line; never liked how Fink works that way. >BC> And their idea of activation (can have multiple installs of the same thing >BC> with different configs; just activate to choose which one to use) is nice. >BC> Plus having Jordan Hubbard on the team is nice (former member of FreeBSD >BC> who now works at Apple for those who don't know). =) I just removed fink from my system and am reinstalling the things that I need with darwinports (most of it, some things I still have manually installed). Fink invades your system and it wants to install all kinds of things that I don't want such as other python versions. Darwinports is less invading. However, darwinports doesn't always state all dependencies which means you might have to be a bit more careful. By the way, I install darwinports in /usr/local because I don't want yet another directory tree. There are still traces of /sw/lib in my installed software but once these are used they fail. I am working on finding all traces and removing them. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP] Private email: piet@vanoostrum.net From micktwomey at gmail.com Sat Feb 5 12:27:42 2005 From: micktwomey at gmail.com (Michael Twomey) Date: Sat Feb 5 12:27:45 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: References: <420476AA.8070606@ocf.berkeley.edu> Message-ID: <50a522ca05020503279dc26ca@mail.gmail.com> Funny, I generally prefer fink precisely because it uses /sw. It keeps itself neatly inside /sw (source, intermediate build, final installation). For a unix head like myself I couldn't ask any more. I generally dislike a packaging system using /usr/local instead of their own prefix, as it is almost gauranteed to tread on other self compiled apps (or downloaded apps). /usr/local is meant to be for sys admins local installs of apps, a strong packaging system should use another prefix. Another reason is that it is based on the debian apt packaging system, so you have a very controlled build environment. Their .info package descriptions are succint and it is easy to roll your own packages. I find the packages to be of very high quality (I sit on the unstable branch, don't let the name dissuade you, it's generally far more stable than many other distros' definition of stable), particularly the scientific computing packages (I'm biased, it has good python scientific stuff, which aligns neatly with my work). I haven't been too pleased with darwinports, it either gave me dud python packages when I tried it, or didn't have high enough quality on other packages I tried. It's definitely more bleeding edge than fink, but I it's easier to roll my own in fink when I need to. mick On Sat, 05 Feb 2005 11:57:01 +0100, Piet van Oostrum wrote: > >>>>> "Brett C." (BC) wrote: > > >BC> Russell E. Owen wrote: > >>> I've seen a lot of discussion lately about fink and darwinports and I'm > >>> wondering if folks who have experience with either can comment on their > >>> relative merits? > >>> > > >BC> I personally have run Fink in the past multiple times and always end up > >BC> deleting it in the end. DarwinPorts, on the other hand, I have yet to > >BC> uninstall. The package config files are easy to read by eye (it is > >BC> basically Tcl code). I also just like how the system is set up using the > >BC> command line; never liked how Fink works that way. > > >BC> And their idea of activation (can have multiple installs of the same thing > >BC> with different configs; just activate to choose which one to use) is nice. > >BC> Plus having Jordan Hubbard on the team is nice (former member of FreeBSD > >BC> who now works at Apple for those who don't know). =) > > I just removed fink from my system and am reinstalling the things that I > need with darwinports (most of it, some things I still have manually > installed). Fink invades your system and it wants to install all kinds of > things that I don't want such as other python versions. Darwinports is less > invading. However, darwinports doesn't always state all dependencies which > means you might have to be a bit more careful. By the way, I install > darwinports in /usr/local because I don't want yet another directory tree. > > There are still traces of /sw/lib in my installed software but once these > are used they fail. I am working on finding all traces and removing them. > -- > Piet van Oostrum > URL: http://www.cs.uu.nl/~piet [PGP] > Private email: piet@vanoostrum.net > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Sat Feb 5 15:21:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 5 15:21:25 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <50a522ca05020503279dc26ca@mail.gmail.com> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> Message-ID: <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> On Feb 5, 2005, at 6:27 AM, Michael Twomey wrote: > On Sat, 05 Feb 2005 11:57:01 +0100, Piet van Oostrum > wrote: >>>>>>> "Brett C." (BC) wrote: >> >>> BC> Russell E. Owen wrote: >>>>> I've seen a lot of discussion lately about fink and darwinports >>>>> and I'm >>>>> wondering if folks who have experience with either can comment on >>>>> their >>>>> relative merits? >>>>> >> >>> BC> I personally have run Fink in the past multiple times and always >>> end up >>> BC> deleting it in the end. DarwinPorts, on the other hand, I have >>> yet to >>> BC> uninstall. The package config files are easy to read by eye (it >>> is >>> BC> basically Tcl code). I also just like how the system is set up >>> using the >>> BC> command line; never liked how Fink works that way. >> >>> BC> And their idea of activation (can have multiple installs of the >>> same thing >>> BC> with different configs; just activate to choose which one to >>> use) is nice. >>> BC> Plus having Jordan Hubbard on the team is nice (former member of >>> FreeBSD >>> BC> who now works at Apple for those who don't know). =) >> >> I just removed fink from my system and am reinstalling the things >> that I >> need with darwinports (most of it, some things I still have manually >> installed). Fink invades your system and it wants to install all >> kinds of >> things that I don't want such as other python versions. Darwinports >> is less >> invading. However, darwinports doesn't always state all dependencies >> which >> means you might have to be a bit more careful. By the way, I install >> darwinports in /usr/local because I don't want yet another directory >> tree. >> >> There are still traces of /sw/lib in my installed software but once >> these >> are used they fail. I am working on finding all traces and removing >> them. > Funny, I generally prefer fink precisely because it uses /sw. It keeps > itself neatly inside /sw (source, intermediate build, final > installation). For a unix head like myself I couldn't ask any more. I > generally dislike a packaging system using /usr/local instead of their > own prefix, as it is almost gauranteed to tread on other self compiled > apps (or downloaded apps). /usr/local is meant to be for sys admins > local installs of apps, a strong packaging system should use another > prefix. Dawinports uses /opt/local, not /usr/local. It was Piet's *choice* to install to /usr/local (though, like you, I would never ever do that). The BIGGEST problem with fink is that it pollutes your environment if you want to use it. It expects you to have a whole script's worth of evil inside your shell at all times. > Another reason is that it is based on the debian apt packaging system, > so you have a very controlled build environment. Their .info package > descriptions are succint and it is easy to roll your own packages. Controlled?! By who? Certainly not the user. -bob From fonnesbeck at gmail.com Sat Feb 5 18:08:03 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Sat Feb 5 18:08:06 2005 Subject: [Pythonmac-SIG] pythonw Message-ID: <723eb6930502050908347eb7de@mail.gmail.com> Sorry in advance for what may, in fact, be a naive post, but I am trying to figure out the significance of pythonw on OSX. I know that you need to run pythonw if you intend to use python programs with certain graphical backends, otherwise the UI becomes unresponsive. Running idle from the command line, for example, starts an instance of idle that is unusable. My question is: why have both python and pythonw? When would you ever *not* want user interfaces not to work? This problem does not arise on other platforms, does it? Its a bit of a hassle, at the moment, to try and figure out when to use one or the other. Are there any plans to remove this apparently unnecessary dichotomy? Thanks for any information, Chris From bob at redivi.com Sat Feb 5 19:46:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 5 20:01:22 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <50a522ca050205071865a4d4cc@mail.gmail.com> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> Message-ID: <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> On Feb 5, 2005, at 10:18 AM, Michael Twomey wrote: > On Sat, 5 Feb 2005 09:21:15 -0500, Bob Ippolito wrote: > >>> Another reason is that it is based on the debian apt packaging >>> system, >>> so you have a very controlled build environment. Their .info package >>> descriptions are succint and it is easy to roll your own packages. >> >> Controlled?! By who? Certainly not the user. > > When I say controlled I am coming from a linux packaging point of > view. The builds are performed inside /sw/src and packages are > assembled from there. Unless you have an utterly insane program whose > source insists on dropping files all over the system during a build > this makes it easy to control what goes into the package. Besides, > writing .info files is fairly easy compared to deb info stuff or rpm > build descriptions, only gentoo gives a nicer build description > format. darwinports uses an image based system where each individual package is installed to its own place. When a particular port is activated, hard links are made to where they need to go so the rest of the system will see it. deactivating a port simply removes these links. Writing darwinports packages is easy too, so that's not a real point of difference. > This is all a point of view, I like fink, it packages what I want > neatly, it doesn't get in my way and I don't spend all my time > re-compiling packages due to arbitrary changes (unlike gentoo, this > strip pretty much summed up my experience, > http://comic.escomposlinux.org/ecol-161-e.png). The fact that fink > applies altivec patches to python numarray is another part of it which > endears itself to me. My problem with fink is basically their choice to use apt. As a point of reference, I really don't like Debian either (though it is better than most of the other Linux distributions in my experience, but that doesn't say a whole lot). Darwinports gives me the control I need with its flavors (essentially letting you build the package with custom flags, such as with or without X11 support for Vim). I can build several of these and activate/deactivate them whenever I want. If I don't want the entire world to be downloaded and installed when installing a simple utility or library. Fink really gets in the way of my efforts to develop redistributable software in that it's dependency resolution is very naive and effectively installs its own OS (minus kernel and a very very small subset of the libraries that OS X ships with). I don't want to distribute an OS with my applications, just the one or two libraries that are actually needed beyond what is included with the OS. I am fine with letting Apple upgrade zlib at their own schedule. I have no need to distribute applications with the absolute latest version of zlib, OpenSSL (and everything else) because I trust Apple (way more so than Fink) to upgrade the OS's version of zlib if there is an actual problem. Darwinports does have its fair share of disadvantages too, but it's certainly a heck of a lot less annoying for what I do. All that said, I don't trust either darwinports or fink do manage Python software. I will use darwinports to build the dependencies for some things, and build the Python packages myself. As far as Mac specific patches to Python software goes, I was the originator of them in many cases... so these "conveniences" don't really apply to me because I am building and hacking on these things myself anyway (and in these cases, both fink and darwinports would get in my way, which is another reason I don't use them for Python software). -bob From bob at redivi.com Sat Feb 5 19:35:10 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 5 20:03:05 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: <723eb6930502050908347eb7de@mail.gmail.com> References: <723eb6930502050908347eb7de@mail.gmail.com> Message-ID: On Feb 5, 2005, at 12:08 PM, Chris Fonnesbeck wrote: > Sorry in advance for what may, in fact, be a naive post, but I am > trying to figure out the significance of pythonw on OSX. I know that > you need to run pythonw if you intend to use python programs with > certain graphical backends, otherwise the UI becomes unresponsive. > Running idle from the command line, for example, starts an instance of > idle that is unusable. My question is: why have both python and > pythonw? When would you ever *not* want user interfaces not to work? > This problem does not arise on other platforms, does it? Its a bit of > a hassle, at the moment, to try and figure out when to use one or the > other. Are there any plans to remove this apparently unnecessary > dichotomy? It is not possible to solve this problem without changing the way Python gets installed (making /usr/bin/python a fork-exec stub or shell script) or using private Apple SPI (to trick the WindowServer into doing the right thing). As far as I know, other platforms do not have this problem. The details of why this is aren't public because we don't have the source, however, the basic idea is that in order for the default WindowServer connection to be created correctly argv[0] needs to point to the absolute path of the executable, and that executable needs to be inside of an application bundle. /usr/bin/python is obviously not in an application bundle, and running "python foo.py" will leave argv[0] as a relative-to-$PATH path due to the way that the shell works. This is essentially a bug in the way WindowServer works, which I and others have filed bugs against, but Apple has neither opened an API to fix this nor have they fixed the bug in WindowServer. The best fix that I can come up with is to make the GUI libraries for Python (Tkinter, wxPython, pygame, PyObjC, ...) hook into the private Apple SPI in a safe-ish way. In PyObjC proper, this isn't really an issue because it's not really useful to write PyObjC applications that aren't already in an application bundle. For the others, it is arguably useful. I have example code for doing this specific hack in PyObjC at . I may add this hack to the next release of pygame (which is especially easy because pygame requires PyObjC), but the authors of Tk/Tkinter and wxPython are going to have to do it themselves. I have heard that some future version of Tk (which would directly fix Tkinter) may include an equivalent hack, but obviously the version of Tk that does this (if such a version is mainline) isn't very common yet. For running your own scripts and playing around in the terminal, just use pythonw all the time. There is a very slight increase in start-up time, but nothing worth caring about. -bob From rogerb at rogerbinns.com Sat Feb 5 20:12:17 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Sat Feb 5 20:12:05 2005 Subject: [Pythonmac-SIG] pythonw References: <723eb6930502050908347eb7de@mail.gmail.com> Message-ID: <001e01c50bb6$9bdb2170$3501a8c0@rogersqyvr14d3> > As far as I know, other platforms do not have this problem. Windows does. Windows has the idea of subsystems (eg OS/2, Posix, Win32). Pretty much only win32 is used these days. Win32 apps can be marked as console or gui. However console apps can also do gui stuff. So PythonW is used to run gui apps, and not have a corresponding console. Roger From hengist.podd at virgin.net Sat Feb 5 20:26:25 2005 From: hengist.podd at virgin.net (has) Date: Sat Feb 5 21:03:38 2005 Subject: [Pythonmac-SIG] pythonw Message-ID: Bob Ippolito wrote: > > Are there any plans to remove this apparently unnecessary > > dichotomy? > >It is not possible to solve this problem without changing the way >Python gets installed (making /usr/bin/python a fork-exec stub or shell >script) Any reason for not doing that then? Eliminating this wart would be good. BTW, there's already a couple patches filed on this: http://sourceforge.net/tracker/index.php?func=detail&aid=1056561&group_id=5470&atid=305470 http://sourceforge.net/tracker/index.php?func=detail&aid=1038911&group_id=5470&atid=305470 Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From rkern at ucsd.edu Sat Feb 5 23:36:03 2005 From: rkern at ucsd.edu (Robert Kern) Date: Sat Feb 5 23:36:05 2005 Subject: [Pythonmac-SIG] Re: [Matplotlib-users] matplotlib OS-X binary problems. In-Reply-To: <4203F4ED.1000302@noaa.gov> References: <4202BCAA.3010407@noaa.gov> <42030576.9010701@ucsd.edu> <4203F4ED.1000302@noaa.gov> Message-ID: <42054A53.8060809@ucsd.edu> Chris Barker wrote: > Robert Kern wrote: >> Change the paths that distutils will add to the link line. They're at >> the top of setupext.py . Remove the ones you don't need. > > > Except that the *.a and *.dylib are put in the same place. Darn. Copy (and re-ranlib) the static library and headers to another place. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Sun Feb 6 02:48:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 6 02:48:42 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: References: Message-ID: <2F0D2585-77E1-11D9-B475-000A95C93D30@redivi.com> On Feb 5, 2005, at 2:26 PM, has wrote: > Bob Ippolito wrote: > >> > Are there any plans to remove this apparently unnecessary >> > dichotomy? >> >> It is not possible to solve this problem without changing the way >> Python gets installed (making /usr/bin/python a fork-exec stub or >> shell >> script) > > Any reason for not doing that then? Eliminating this wart would be > good. It would break bundlebuilder's --standalone option, probably other things. -bob From hengist.podd at virgin.net Sun Feb 6 03:17:29 2005 From: hengist.podd at virgin.net (has) Date: Sun Feb 6 03:17:33 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: <2F0D2585-77E1-11D9-B475-000A95C93D30@redivi.com> References: <2F0D2585-77E1-11D9-B475-000A95C93D30@redivi.com> Message-ID: Bob Ippolito wrote: >>>It is not possible to solve this problem without changing the way >>>Python gets installed (making /usr/bin/python a fork-exec stub or shell >>>script) >> >>Any reason for not doing that then? Eliminating this wart would be good. > >It would break bundlebuilder's --standalone option, probably other things. How so? The change should only add functionality to /usr/bin/python so that /usr/bin/pythonw is no longer required, allowing the latter to be deprecated and eventually removed. If changing /usr/bin/python itself affects BB, patch BB to reflect the change. (Or just deprecate BB too and tell folk not to use it to build new apps any more. This should be of relatively little inconvenience to users.) BTW, what about the sourceforge patches? Would one or both of those solve the problem any better? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Sun Feb 6 03:33:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 6 03:34:03 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: References: <2F0D2585-77E1-11D9-B475-000A95C93D30@redivi.com> Message-ID: <81FC035C-77E7-11D9-B475-000A95C93D30@redivi.com> On Feb 5, 2005, at 9:17 PM, has wrote: > Bob Ippolito wrote: > >>>> It is not possible to solve this problem without changing the way >>>> Python gets installed (making /usr/bin/python a fork-exec stub or >>>> shell >>>> script) >>> >>> Any reason for not doing that then? Eliminating this wart would be >>> good. >> >> It would break bundlebuilder's --standalone option, probably other >> things. > > How so? The change should only add functionality to /usr/bin/python so > that /usr/bin/pythonw is no longer required, allowing the latter to be > deprecated and eventually removed. If changing /usr/bin/python itself > affects BB, patch BB to reflect the change. (Or just deprecate BB too > and tell folk not to use it to build new apps any more. This should be > of relatively little inconvenience to users.) It makes /usr/bin/python depend on another executable at a specific location on the filesystem, bundlebuilder *needs* a local copy of a full Python interpreter, it would also need to be patched. > BTW, what about the sourceforge patches? Would one or both of those > solve the problem any better? No. Anyway, the best way to do it is to fix the GUI frameworks because that would solve other people's problems too (outside the Python world). Also, the proposed fixes only fix this issue with a framework Python, not a standard Python, so fixing the GUI frameworks will also make them work with fink and darwinports Python (if they were to build non-X11 GUI frameworks). -bob From hengist.podd at virgin.net Sun Feb 6 03:55:31 2005 From: hengist.podd at virgin.net (has) Date: Sun Feb 6 03:55:51 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: <81FC035C-77E7-11D9-B475-000A95C93D30@redivi.com> References: <2F0D2585-77E1-11D9-B475-000A95C93D30@redivi.com> <81FC035C-77E7-11D9-B475-000A95C93D30@redivi.com> Message-ID: Bob Ippolito wrote: >It makes /usr/bin/python depend on another executable at a specific >location on the filesystem, Would it be possible to keep /usr/bin/python as a full-fledged interpreter while adding to it the ability to automatically start a second interpreter at a known location when needed? That should avoid breaking anything that's dependent on there being an interpreter at /usr/bin/python. Or maybe stick the path info in a hidden config file that the interpreter can read when it wants to know its location. I'm not clear on why we need to replace it altogether just to achieve the desired effect. >bundlebuilder *needs* a local copy of a full Python interpreter, it >would also need to be patched. How big a job would that be? >>BTW, what about the sourceforge patches? Would one or both of those >>solve the problem any better? > >No. > >Anyway, the best way to do it is to fix the GUI frameworks because >that would solve other people's problems too (outside the Python >world). Obviously. Though I think even Jack might struggle at trying to fix Apple itself. :) has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Sun Feb 6 04:31:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 6 04:32:13 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: References: <2F0D2585-77E1-11D9-B475-000A95C93D30@redivi.com> <81FC035C-77E7-11D9-B475-000A95C93D30@redivi.com> Message-ID: <9AA39E7C-77EF-11D9-B475-000A95C93D30@redivi.com> On Feb 5, 2005, at 9:55 PM, has wrote: > Bob Ippolito wrote: > >> It makes /usr/bin/python depend on another executable at a specific >> location on the filesystem, > > Would it be possible to keep /usr/bin/python as a full-fledged > interpreter while adding to it the ability to automatically start a > second interpreter at a known location when needed? That should avoid > breaking anything that's dependent on there being an interpreter at > /usr/bin/python. Or maybe stick the path info in a hidden config file > that the interpreter can read when it wants to know its location. I'm > not clear on why we need to replace it altogether just to achieve the > desired effect. "when needed" is ambiguous. You don't know you need it until you're well into running Python code. If you knew you needed it in the first place, you'd have run the code with pythonw. > >> bundlebuilder *needs* a local copy of a full Python interpreter, it >> would also need to be patched. > > How big a job would that be? Not big, but I'm not going to care. >>> BTW, what about the sourceforge patches? Would one or both of those >>> solve the problem any better? >> >> No. >> >> Anyway, the best way to do it is to fix the GUI frameworks because >> that would solve other people's problems too (outside the Python >> world). > > Obviously. Though I think even Jack might struggle at trying to fix > Apple itself. :) It's unlikely that Apple will ever fix this problem for users. I bugged them about it in 2001, and they damn well know the workaround because it's in GLUT (AFTER I had reported it) and Java. We should instead use their private SPI and include the workaround in Tk, wx, SDL, etc. -bob From micktwomey at gmail.com Sun Feb 6 11:55:28 2005 From: micktwomey at gmail.com (Michael Twomey) Date: Sun Feb 6 11:55:30 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> Message-ID: <50a522ca050206025539ac362e@mail.gmail.com> On Sat, 5 Feb 2005 13:46:49 -0500, Bob Ippolito wrote: > > darwinports uses an image based system where each individual package is > installed to its own place. When a particular port is activated, hard > links are made to where they need to go so the rest of the system will > see it. deactivating a port simply removes these links. > Fair enough, I like using binary packages for this, as well as rolling back to older versions. > Writing darwinports packages is easy too, so that's not a real point of > difference. > Agreed, I've looked at the darwinports portinfo files and they look pretty simple. > > This is all a point of view, I like fink, it packages what I want > > neatly, it doesn't get in my way and I don't spend all my time > > re-compiling packages due to arbitrary changes (unlike gentoo, this > > strip pretty much summed up my experience, > > http://comic.escomposlinux.org/ecol-161-e.png). The fact that fink > > applies altivec patches to python numarray is another part of it which > > endears itself to me. > > My problem with fink is basically their choice to use apt. As a point > of reference, I really don't like Debian either (though it is better > than most of the other Linux distributions in my experience, but that > doesn't say a whole lot). > Ok, this is definitely the main source of our disagreement, I love apt and debian, whenever I've needed it debian has been there for me and worked perfectly, it's saved my behind so many times I've lost count. So when choosing a system on the mac I am instantly biased towards an apt based solution. > Darwinports gives me the control I need with its flavors (essentially > letting you build the package with custom flags, such as with or > without X11 support for Vim). I can build several of these and > activate/deactivate them whenever I want. > As a rule I dislike flavours (though fink does give you ssl vs non-ssl, and x11 vs non x11 packages), the combinational explosion of options you get means it gets very hard to debug issues with one machine vs another (this probably is another hint of my bias, my arguments stem from maintaining multiple machines, for my laptop this is all really moot :) ). > If I don't want the entire world to be downloaded and installed when > installing a simple utility or library. > This isn't really the fault of the system, more of the packager. Fink can handle useful deps just fine, it's a question of whether the packager uses them properly. It's pretty much the same on all systems, AFAIK. As a point of reference, building the suse python package is painful as it draws in a huge amount of deps so it can build all the variant packages. Besides, I thought the reason most people use a packaging system is to pull in a given app's required world of libs rather than download and compile each one? > Fink really gets in the way of my efforts to develop redistributable > software in that it's dependency resolution is very naive and > effectively installs its own OS (minus kernel and a very very small > subset of the libraries that OS X ships with). I don't want to > distribute an OS with my applications, just the one or two libraries > that are actually needed beyond what is included with the OS. I am > fine with letting Apple upgrade zlib at their own schedule. I have no > need to distribute applications with the absolute latest version of > zlib, OpenSSL (and everything else) because I trust Apple (way more so > than Fink) to upgrade the OS's version of zlib if there is an actual > problem. > I wouldn't use fink to distribute apps, or for that matter any of the packaging systems. In the case of OS X I would link against Apple's libraries, and bundle others I needed. By bundle others, I mean I would build them myself, ensuring they linked against Apple's stuff. As far as I know, none of the packaging systems touch Apple's libraries (any that went near /usr would be bad news, I'm looking in the direction of the initial release of portage here), they just link against their own versions. With ABI being what it is these days this is a prudent choice. Entire systems like openpkg make this their entire point, they statically link against their own libs so you are isolated from the core OS, a critical point when deploying against multiple OSs. > Darwinports does have its fair share of disadvantages too, but it's > certainly a heck of a lot less annoying for what I do. > Personal preference here, I think it's just a question of which system you like, and which system rubbed you the wrong way when you tried it (for me it was darwinports). > All that said, I don't trust either darwinports or fink do manage > Python software. I will use darwinports to build the dependencies for > some things, and build the Python packages myself. As far as Mac > specific patches to Python software goes, I was the originator of them > in many cases... so these "conveniences" don't really apply to me > because I am building and hacking on these things myself anyway (and in > these cases, both fink and darwinports would get in my way, which is > another reason I don't use them for Python software). > I completely agree here. I've adopted a multi-prong approach which works well for me: 1. Use Apple's python (and your sweet pyobjc) for mac apps 2. Use a packaging system (fink, darwinports, whatever) for an X11 or non-gui python. This is what I use from command line. Generally I need more deps for some of this stuff, so a packaging system helps a lot here. 3. 'python setup.py install --prefix=$HOME/unix' and add $HOME/unix/lib/python2.3 to my PYTHONPATH for other stuff which isn't packaged by anyone, generally pure python stuff. This way I keep the mucking about with my system as root to a minimum, and get reasonable value from pre-packaged stuff. Packaging systems should be the job of the OS vendor in this day an age. To be honest, I find it shocking that Apple's packaging system doesn't have a package remove, it would make it far more viable. Even better if they adopted a real packaging system like apt ;) mick From bob at redivi.com Sun Feb 6 15:49:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 6 15:51:35 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <50a522ca050206025539ac362e@mail.gmail.com> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> Message-ID: <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> On Feb 6, 2005, at 5:55 AM, Michael Twomey wrote: > On Sat, 5 Feb 2005 13:46:49 -0500, Bob Ippolito wrote: >> Darwinports gives me the control I need with its flavors (essentially >> letting you build the package with custom flags, such as with or >> without X11 support for Vim). I can build several of these and >> activate/deactivate them whenever I want. >> > > As a rule I dislike flavours (though fink does give you ssl vs > non-ssl, and x11 vs non x11 packages), the combinational explosion of > options you get means it gets very hard to debug issues with one > machine vs another (this probably is another hint of my bias, my > arguments stem from maintaining multiple machines, for my laptop this > is all really moot :) ). So then pretend you're using fink and install the same flavor (probably the flavor that depends on a third of the open source software ever written) on every machine. >> If I don't want the entire world to be downloaded and installed when >> installing a simple utility or library. >> > > This isn't really the fault of the system, more of the packager. Fink > can handle useful deps just fine, it's a question of whether the > packager uses them properly. It's pretty much the same on all systems, > AFAIK. As a point of reference, building the suse python package is > painful as it draws in a huge amount of deps so it can build all the > variant packages. More linux pain :) > Besides, I thought the reason most people use a packaging system is to > pull in a given app's required world of libs rather than download and > compile each one? Yes, but the "world of required libs" is usually mostly satisfied by what is already on the system, though Fink doesn't care because it would rather download and install its own version of everything. >> Fink really gets in the way of my efforts to develop redistributable >> software in that it's dependency resolution is very naive and >> effectively installs its own OS (minus kernel and a very very small >> subset of the libraries that OS X ships with). I don't want to >> distribute an OS with my applications, just the one or two libraries >> that are actually needed beyond what is included with the OS. I am >> fine with letting Apple upgrade zlib at their own schedule. I have no >> need to distribute applications with the absolute latest version of >> zlib, OpenSSL (and everything else) because I trust Apple (way more so >> than Fink) to upgrade the OS's version of zlib if there is an actual >> problem. >> > > I wouldn't use fink to distribute apps, or for that matter any of the > packaging systems. In the case of OS X I would link against Apple's > libraries, and bundle others I needed. By bundle others, I mean I > would build them myself, ensuring they linked against Apple's stuff. > > As far as I know, none of the packaging systems touch Apple's > libraries (any that went near /usr would be bad news, I'm looking in > the direction of the initial release of portage here), they just link > against their own versions. With ABI being what it is these days this > is a prudent choice. Entire systems like openpkg make this their > entire point, they statically link against their own libs so you are > isolated from the core OS, a critical point when deploying against > multiple OSs. Darwinports will use Apple's libraries whenever suitable. >> Darwinports does have its fair share of disadvantages too, but it's >> certainly a heck of a lot less annoying for what I do. >> > > Personal preference here, I think it's just a question of which system > you like, and which system rubbed you the wrong way when you tried it > (for me it was darwinports). I've been burned by apt on multiple platforms, so :) >> All that said, I don't trust either darwinports or fink do manage >> Python software. I will use darwinports to build the dependencies for >> some things, and build the Python packages myself. As far as Mac >> specific patches to Python software goes, I was the originator of them >> in many cases... so these "conveniences" don't really apply to me >> because I am building and hacking on these things myself anyway (and >> in >> these cases, both fink and darwinports would get in my way, which is >> another reason I don't use them for Python software). >> > > I completely agree here. I've adopted a multi-prong approach which > works well for me: > > 1. Use Apple's python (and your sweet pyobjc) for mac apps > 2. Use a packaging system (fink, darwinports, whatever) for an X11 or > non-gui python. This is what I use from command line. Generally I need > more deps for some of this stuff, so a packaging system helps a lot > here. > 3. 'python setup.py install --prefix=$HOME/unix' and add > $HOME/unix/lib/python2.3 to my PYTHONPATH for other stuff which isn't > packaged by anyone, generally pure python stuff. Since you use two different Pythons, how on earth can you use PYTHONPATH? I use pth files sitting in directories that are picked up by a particular Python. > This way I keep the mucking about with my system as root to a minimum, > and get reasonable value from pre-packaged stuff. > > Packaging systems should be the job of the OS vendor in this day an > age. To be honest, I find it shocking that Apple's packaging system > doesn't have a package remove, it would make it far more viable. Even > better if they adopted a real packaging system like apt ;) Well, even if apt didn't suck, its license does. Apple stays away from GPL software. I'm pretty sure that there is exactly zero GPL code in Mac OS X (not Server) until you install Developer Tools. -bob From micktwomey at gmail.com Mon Feb 7 02:20:55 2005 From: micktwomey at gmail.com (Michael Twomey) Date: Mon Feb 7 02:20:58 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <50a522ca0502061719700a8ef7@mail.gmail.com> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <50a522ca0502061719700a8ef7@mail.gmail.com> Message-ID: <50a522ca05020617205bf6151d@mail.gmail.com> (Damn gmail, why can't it reply to lists by default, this really steals my thunder) ---------- Forwarded message ---------- From: Michael Twomey Date: Mon, 7 Feb 2005 01:19:46 +0000 Subject: Re: [Pythonmac-SIG] fink vs DarwinPorts? To: Bob Ippolito On Sun, 6 Feb 2005 09:49:15 -0500, Bob Ippolito wrote: > > So then pretend you're using fink and install the same flavor (probably > the flavor that depends on a third of the open source software ever > written) on every machine. > 'Fraid I'm not getting you here. The flavour stuff that drives me nuts is the kind that turns on and off options without indicating in the package name, e.g. python-x11 and python-nox11 vs plain python + some hidden option. This turns a 2 minute "do you have that package?" to a forensic hunt through the system. Gentoo is very guilty of this (but I suppose that's the entire point of gentoo, a complete specific distro). If libraries and apps were properly orthogonal then variants wouldn't be needed in a lot of cases. > This isn't really the fault of the system, more of the packager. Fink > can handle useful deps just fine, it's a question of whether the > packager uses them properly. It's pretty much the same on all systems, > AFAIK. As a point of reference, building the suse python package is > painful as it draws in a huge amount of deps so it can build all the > variant packages. > > More linux pain :) > Dunno, depends on distro I suppose. Debian and Ubuntu usually do the right thing, gentoo can be a wild unpredictable ride depends on what emerge flags you've set. I've got bandwidth and disk space, I don't really care if fink pulls in more deps, I've got more important things to do than agonise over whether I'm optimally using installed libs or not. It would be nice if someone had access to a compile farm like debian's so I could just download packages instead of having to compile them, but that's just icing on the cake. > > Besides, I thought the reason most people use a packaging system is to > > pull in a given app's required world of libs rather than download and > > compile each one? > > Yes, but the "world of required libs" is usually mostly satisfied by > what is already on the system, though Fink doesn't care because it > would rather download and install its own version of everything. > Hrm, really depends on what you are doing. Apple doesn't bundle a lot of the libs I use so I need to get at them somehow. The ./configure && make && make install dance gets a bit tiring after a while. > > As far as I know, none of the packaging systems touch Apple's > > libraries (any that went near /usr would be bad news, I'm looking in > > the direction of the initial release of portage here), they just link > > against their own versions. With ABI being what it is these days this > > is a prudent choice. Entire systems like openpkg make this their > > entire point, they statically link against their own libs so you are > > isolated from the core OS, a critical point when deploying against > > multiple OSs. > > Darwinports will use Apple's libraries whenever suitable. > To be honest, I don't really care. After umpteen dvd projects and fink I still have wodges of disk space. > > Personal preference here, I think it's just a question of which system > > you like, and which system rubbed you the wrong way when you tried it > > (for me it was darwinports). > > I've been burned by apt on multiple platforms, so :) > So there ;) > > I completely agree here. I've adopted a multi-prong approach which > > works well for me: > > > > 1. Use Apple's python (and your sweet pyobjc) for mac apps > > 2. Use a packaging system (fink, darwinports, whatever) for an X11 or > > non-gui python. This is what I use from command line. Generally I need > > more deps for some of this stuff, so a packaging system helps a lot > > here. > > 3. 'python setup.py install --prefix=$HOME/unix' and add > > $HOME/unix/lib/python2.3 to my PYTHONPATH for other stuff which isn't > > packaged by anyone, generally pure python stuff. > > Since you use two different Pythons, how on earth can you use > PYTHONPATH? I use pth files sitting in directories that are picked up > by a particular Python. > Works for me, I'm still using python 2.3 major version, I haven't switched overt to 2.4 yet, so it doesn't cause me any problems. Besides it's something I can control with env variables, which I can switch at will to point at different combinations of work code and test libraries. Personal preference here. This is probably influenced by what I am doing. > > Packaging systems should be the job of the OS vendor in this day an > > age. To be honest, I find it shocking that Apple's packaging system > > doesn't have a package remove, it would make it far more viable. Even > > better if they adopted a real packaging system like apt ;) > > Well, even if apt didn't suck, its license does. Apple stays away from > GPL software. I'm pretty sure that there is exactly zero GPL code in > Mac OS X (not Server) until you install Developer Tools. > I'm pretty sure Apple uses cups, which in turn is LPGL/GPL. Not sure how that's relevant here though :) I'm not asking Apple to use apt, but extending their package utilities to encompass some of apt's (or indeed any other packaging system's) features would be nice. I haven't used OS X server, but I'm wondering how it can compete in the enterprise market without more basic packaging features. Well that's enough "my packaging system is better than yours" for me for one day, haven't seen any conclusive arguments to say one is dramatically better than another, so it pretty much boils down to whether a given packaging system gives you the packages you want. And that's simplifying the issue a great deal. 'Course more people on this list have spoke in favour of darwinports, so it wins by head count here. cheers, mick From jdgleeson at mac.com Mon Feb 7 05:20:55 2005 From: jdgleeson at mac.com (John Gleeson) Date: Mon Feb 7 05:21:01 2005 Subject: [Pythonmac-SIG] Tcl/Tk path problems with py2app Message-ID: OS X 10.3.7 w/Apple's python framework py2app 0.1.7 TclTkAquaBI-8.4.9.0.dmg I am trying to use py2app to build a standalone Leo application from the latest release of leo . When I execute leo from the command line, its Tcl/Tk gui works as expected, so I presume Tcl/Tk is installed correctly. I also have a Leo app created by Guenther Enthaler last summer that works fine; it is not standalone - the user must have Tcl/Tk installed. But when I launch the standalone Leo.app that I create with py2app, it fails with TclError: Can't find a usable init.tcl in the following directories: /usr/lib/tcl8.4 /System/Library/Frameworks/Python.framework/Versions/2.3/lib/tcl8.4 /System/Library/Frameworks/Python.framework/Versions/lib/tcl8.4 /System/Library/Frameworks/Python.framework/Versions/2.3/library /System/Library/Frameworks/Python.framework/Versions/library /System/Library/Frameworks/Python.framework/Versions/tcl8.4.9/library /System/Library/Frameworks/Python.framework/tcl8.4.9/library /usr/lib/tcl8.4 This probably means that Tcl wasn't installed properly. The Tcl and Tk frameworks are in the app bundle (and init.tcl is there too), but Tcl does not search there. I tried wrapping the Leo executable in a shell script so I could set the environment variables TCL_LIBRARY and TK_LIBRARY to point into the frameworks inside the app. That got me past the TclError above and a similar TkError. The Leo user ID input dialog even worked. But then Tk failed to draw widgets, again looking in the wrong places on the system. Does anyone have any ideas why Leo.app is not using the Tcl and Tk frameworks that py2app cop-ies into it (or the ones installed on my system)? The source I'm using can be downloaded from the following link if anyone would like to try it out. It also contains logs of all of my "python setup.py py2app" output and the console output from Leo.app. The console output includes a dump of my environment variables, sys.path, etc. (pirated from the Hello.py py2app example). Thanks, John -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2269 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050206/defb92e7/attachment.bin From bob at redivi.com Mon Feb 7 05:31:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 05:31:29 2005 Subject: [Pythonmac-SIG] Tcl/Tk path problems with py2app In-Reply-To: References: Message-ID: <1C76FD4C-78C1-11D9-A100-000A95C93D30@redivi.com> On Feb 6, 2005, at 11:20 PM, John Gleeson wrote: > OS X 10.3.7 w/Apple's python framework > py2app 0.1.7 > TclTkAquaBI-8.4.9.0.dmg > > > I am trying to use py2app to build a standalone Leo application from > the latest release of leo . > > When I execute leo from the command line, its Tcl/Tk gui works as > expected, so I presume Tcl/Tk is installed correctly. I also have a > Leo app created by Guenther Enthaler last summer > thread_id=1064013&forum_id=10226> that works fine; it is not > standalone - the user must have Tcl/Tk installed. Try using py2app from svn, I'm pretty sure I fixed this. -bob From moehl at akaflieg.extern.tu-berlin.de Mon Feb 7 13:53:25 2005 From: moehl at akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Mon Feb 7 13:53:27 2005 Subject: [Pythonmac-SIG] wxPython/vtk/OpenGL problem In-Reply-To: <1C76FD4C-78C1-11D9-A100-000A95C93D30@redivi.com> References: <1C76FD4C-78C1-11D9-A100-000A95C93D30@redivi.com> Message-ID: Hi, does anyone have an idea how to debug a (probably) OpenGL problem on Mac OSX? I have the latest wxPython with working PyOpenGL (which is probably not used) and VTK 4.4. When I try to run anything which would give me a 3D output, like pythonw wxVTKRenderWindow.py, I get nothing. I would suspect something with Apples triple buffering but where is the best point to start looking? Any hints are appreciated Torsten From bob at redivi.com Mon Feb 7 16:16:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 16:16:33 2005 Subject: [Pythonmac-SIG] wxPython/vtk/OpenGL problem In-Reply-To: References: <1C76FD4C-78C1-11D9-A100-000A95C93D30@redivi.com> Message-ID: <8b175619ef06862fc59db7c82fd856ec@redivi.com> On Feb 7, 2005, at 7:53, Torsten Sadowski wrote: > does anyone have an idea how to debug a (probably) OpenGL problem on > Mac > OSX? I have the latest wxPython with working PyOpenGL (which is > probably > not used) and VTK 4.4. When I try to run anything which would give me > a 3D > output, like pythonw wxVTKRenderWindow.py, I get nothing. I would > suspect > something with Apples triple buffering but where is the best point to > start looking? Most of the time OpenGL contexts are only double buffered. This sounds like a bug or incompatibility in VTK or wx. You could try calling glFinish() at the end of the render loop, but I don't have VTK installed here so I can't look to see what's wrong with it. -bob From jdgleeson at mac.com Mon Feb 7 16:26:42 2005 From: jdgleeson at mac.com (John Gleeson) Date: Mon Feb 7 16:26:47 2005 Subject: [Pythonmac-SIG] Tcl/Tk path problems with py2app In-Reply-To: <1C76FD4C-78C1-11D9-A100-000A95C93D30@redivi.com> References: <1C76FD4C-78C1-11D9-A100-000A95C93D30@redivi.com> Message-ID: <6574609611479209a600a41a346ee3f4@mac.com> On Feb 6, 2005, at 9:31 PM, Bob Ippolito wrote: > > On Feb 6, 2005, at 11:20 PM, John Gleeson wrote: > >> OS X 10.3.7 w/Apple's python framework >> py2app 0.1.7 >> TclTkAquaBI-8.4.9.0.dmg >> >> >> I am trying to use py2app to build a standalone Leo application from >> the latest release of leo . >> >> When I execute leo from the command line, its Tcl/Tk gui works as >> expected, so I presume Tcl/Tk is installed correctly. I also have a >> Leo app created by Guenther Enthaler last summer >> > thread_id=1064013&forum_id=10226> that works fine; it is not >> standalone - the user must have Tcl/Tk installed. > > Try using py2app from svn, I'm pretty sure I fixed this. > > -bob > Yes, the svn version of py2app fixes this. Thanks! -John From mwh at python.net Mon Feb 7 18:03:17 2005 From: mwh at python.net (Michael Hudson) Date: Mon Feb 7 18:03:19 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> (Bob Ippolito's message of "Sun, 6 Feb 2005 09:49:15 -0500") References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> Message-ID: <2m3bw87162.fsf@starship.python.net> Bob Ippolito writes: > Well, even if apt didn't suck, its license does. Apple stays away > from GPL software. I'm pretty sure that there is exactly zero GPL > code in Mac OS X (not Server) until you install Developer Tools. I think there's a fair bit actually -- gnutar, bash, gnumake... Cheers, mwh (who doesn't like fink much either) -- It's an especially annoying American buzzword for "business use, as opposed to consumer, research, or educational use". -- Tim Peters defines "enterprise" From bob at redivi.com Mon Feb 7 18:11:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 18:11:24 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <2m3bw87162.fsf@starship.python.net> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> Message-ID: <4c3f1cb3924dba42cb80557c46050d68@redivi.com> On Feb 7, 2005, at 12:03, Michael Hudson wrote: > Bob Ippolito writes: > >> Well, even if apt didn't suck, its license does. Apple stays away >> from GPL software. I'm pretty sure that there is exactly zero GPL >> code in Mac OS X (not Server) until you install Developer Tools. > > I think there's a fair bit actually -- gnutar, bash, gnumake... I could've sworn there wasn't.. maybe I'm thinking of Mac OS X past :) Anyway, they definitely seem to avoid it when possible. -bob From skip at pobox.com Mon Feb 7 18:14:38 2005 From: skip at pobox.com (Skip Montanaro) Date: Mon Feb 7 18:14:43 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <2m3bw87162.fsf@starship.python.net> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> Message-ID: <16903.41470.289860.440406@montanaro.dyndns.org> mwh> I think there's a fair bit actually -- gnutar, bash, gnumake... Not to mention gcc... Skip From bob at redivi.com Mon Feb 7 18:22:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 18:22:10 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <16903.41470.289860.440406@montanaro.dyndns.org> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> <16903.41470.289860.440406@montanaro.dyndns.org> Message-ID: On Feb 7, 2005, at 12:14, Skip Montanaro wrote: > > mwh> I think there's a fair bit actually -- gnutar, bash, > gnumake... > > Not to mention gcc... I said "... until you install Developer Tools". Mac OS X doesn't ship stock with gcc. -bob From mwh at python.net Mon Feb 7 18:24:13 2005 From: mwh at python.net (Michael Hudson) Date: Mon Feb 7 18:24:15 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <4c3f1cb3924dba42cb80557c46050d68@redivi.com> (Bob Ippolito's message of "Mon, 7 Feb 2005 12:11:18 -0500") References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> <4c3f1cb3924dba42cb80557c46050d68@redivi.com> Message-ID: <2my8e05lmq.fsf@starship.python.net> Bob Ippolito writes: > On Feb 7, 2005, at 12:03, Michael Hudson wrote: > >> Bob Ippolito writes: >> >>> Well, even if apt didn't suck, its license does. Apple stays away >>> from GPL software. I'm pretty sure that there is exactly zero GPL >>> code in Mac OS X (not Server) until you install Developer Tools. >> >> I think there's a fair bit actually -- gnutar, bash, gnumake... > > I could've sworn there wasn't.. maybe I'm thinking of Mac OS X past :) I think bash appeared with 10.3. Or maybe 10.2. Don't know about gnutar. gnumake probably doesn't appear unless you install the developer tools, my brain switched off thinking about your caveat there :) > Anyway, they definitely seem to avoid it when possible. Indeed. Cheers, mwh -- Its unmanageable complexity has spawned more fear-preventing tools than any other language, but the solution _should_ have been to create and use a language that does not overload the whole goddamn human brain with irrelevant details. -- Erik Naggum, comp.lang.lisp From fonnesbeck at gmail.com Mon Feb 7 18:34:39 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Mon Feb 7 18:34:43 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: References: <723eb6930502050908347eb7de@mail.gmail.com> Message-ID: <723eb69305020709346c1ae174@mail.gmail.com> On Sat, 5 Feb 2005 13:35:10 -0500, Bob Ippolito wrote: > For running your own scripts and playing around in the terminal, just > use pythonw all the time. There is a very slight increase in start-up > time, but nothing worth caring about. > OK, so if I replace the symbolic link from /usr/bin/python to /usr/bin/python2.3 with a link to /usr/bin/pythonw2.3, nothing bad will happen? I dont envision a scenario for me ever having to use python2.3 ever again, if this is true. Thanks, Chris From bob at redivi.com Mon Feb 7 18:37:06 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 18:37:12 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: <723eb69305020709346c1ae174@mail.gmail.com> References: <723eb6930502050908347eb7de@mail.gmail.com> <723eb69305020709346c1ae174@mail.gmail.com> Message-ID: <173ec8a71ff75e248be215ae95310284@redivi.com> On Feb 7, 2005, at 12:34, Chris Fonnesbeck wrote: > On Sat, 5 Feb 2005 13:35:10 -0500, Bob Ippolito wrote: > >> For running your own scripts and playing around in the terminal, just >> use pythonw all the time. There is a very slight increase in start-up >> time, but nothing worth caring about. >> > > OK, so if I replace the symbolic link from /usr/bin/python to > /usr/bin/python2.3 with a link to /usr/bin/pythonw2.3, nothing bad > will happen? I dont envision a scenario for me ever having to use > python2.3 ever again, if this is true. I think that will break #! scripts that don't use env, because pythonw is a shell script not an executable. -bob From bob at redivi.com Mon Feb 7 18:43:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 18:43:54 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: References: <2F0D2585-77E1-11D9-B475-000A95C93D30@redivi.com> <81FC035C-77E7-11D9-B475-000A95C93D30@redivi.com> <9AA39E7C-77EF-11D9-B475-000A95C93D30@redivi.com> Message-ID: <8c9f5325f250572870fedf52ab4bc9ac@redivi.com> On Feb 7, 2005, at 12:12, has wrote: > Bob Ippolito wrote: > >>> Would it be possible to keep /usr/bin/python as a full-fledged >>> interpreter while adding to it the ability to automatically start a >>> second interpreter at a known location when needed? >> >> "when needed" is ambiguous. You don't know you need it until you're >> well into running Python code. If you knew you needed it in the >> first place, you'd have run the code with pythonw. > > Fair point. So what's the process by which the interpreter's path > becomes needed, and who exactly is doing the asking? Whenever you end up attempting to make a WindowServer connection, which happens when you go through certain Carbon, Cocoa, and probably CoreGraphics code. >> It's unlikely that Apple will ever fix this problem for users. I >> bugged them about it in 2001, and they damn well know the workaround >> because it's in GLUT (AFTER I had reported it) and Java. We should >> instead use their private SPI and include the workaround in Tk, wx, >> SDL, etc. > > How much work, and how safe, would that be? Five or six lines of code per framework. It's safe enough as long as the symbol is looked up dynamically or weak linked in case it goes away. The code has worked since Mac OS X 10.1 and still works on 10.3 (I don't remember if I've tried it on anything newer..). -bob From skip at pobox.com Mon Feb 7 19:04:23 2005 From: skip at pobox.com (Skip Montanaro) Date: Mon Feb 7 19:04:27 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> <16903.41470.289860.440406@montanaro.dyndns.org> Message-ID: <16903.44455.417867.808534@montanaro.dyndns.org> >> Not to mention gcc... Bob> I said "... until you install Developer Tools". Mac OS X doesn't Bob> ship stock with gcc. Sorry, I missed that. In any case, even if gcc isn't distributed by default, it's certainly used to build everything, isn't it? Skip From skip at pobox.com Mon Feb 7 19:06:06 2005 From: skip at pobox.com (Skip Montanaro) Date: Mon Feb 7 19:06:10 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <2my8e05lmq.fsf@starship.python.net> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> <4c3f1cb3924dba42cb80557c46050d68@redivi.com> <2my8e05lmq.fsf@starship.python.net> Message-ID: <16903.44558.172302.93992@montanaro.dyndns.org> mwh> I think bash appeared with 10.3. Or maybe 10.2. It was clearly there in 10.2. That's my shell on my laptop. Skip From bob at redivi.com Mon Feb 7 19:12:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 19:12:20 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <16903.44558.172302.93992@montanaro.dyndns.org> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> <4c3f1cb3924dba42cb80557c46050d68@redivi.com> <2my8e05lmq.fsf@starship.python.net> <16903.44558.172302.93992@montanaro.dyndns.org> Message-ID: <83f91e3910081efa9a174f71dfc803d3@redivi.com> On Feb 7, 2005, at 13:06, Skip Montanaro wrote: > > mwh> I think bash appeared with 10.3. Or maybe 10.2. > > It was clearly there in 10.2. That's my shell on my laptop. It wasn't default until 10.3, it may or may not have been in 10.1 or earlier. -bob From bob at redivi.com Mon Feb 7 19:13:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 19:13:14 2005 Subject: [Pythonmac-SIG] fink vs DarwinPorts? In-Reply-To: <16903.44455.417867.808534@montanaro.dyndns.org> References: <420476AA.8070606@ocf.berkeley.edu> <50a522ca05020503279dc26ca@mail.gmail.com> <32033F7E-7781-11D9-B40C-000A95C93D30@redivi.com> <50a522ca050205071865a4d4cc@mail.gmail.com> <4B1CE07E-77A6-11D9-808C-000A95C93D30@redivi.com> <50a522ca050206025539ac362e@mail.gmail.com> <45B117B1-784E-11D9-876C-000A95C93D30@redivi.com> <2m3bw87162.fsf@starship.python.net> <16903.41470.289860.440406@montanaro.dyndns.org> <16903.44455.417867.808534@montanaro.dyndns.org> Message-ID: On Feb 7, 2005, at 13:04, Skip Montanaro wrote: > >>> Not to mention gcc... > > Bob> I said "... until you install Developer Tools". Mac OS X > doesn't > Bob> ship stock with gcc. > > Sorry, I missed that. In any case, even if gcc isn't distributed by > default, it's certainly used to build everything, isn't it? Yeah, but what does that have to do with anything? The GPL doesn't cover output of the application, only the application and its source code. -bob From loredo at astro.cornell.edu Mon Feb 7 19:41:40 2005 From: loredo at astro.cornell.edu (Tom Loredo) Date: Mon Feb 7 19:41:46 2005 Subject: {Spam?} Re: [Pythonmac-SIG] Compiling matplotlib on OS-X Message-ID: <200502071841.j17IfeG12742@laplace.astro.cornell.edu> Bob wrote: > Anyway, PJE and I are working on the Next Big Thing in Python packages > that will make > this problem go away at some point. Hopefully by March ;) This is good news (though for the PEAK uninitiated like myself the web page is rather cryptic). I hope that you'll keep in mind that half the web surfing world is still on low bandwidth connections, so that a simple way to "transfer" packages from one machine to another without being online will prove very useful. That is, I should be able to download a package onto a machine with a fast connection, and copy it over to another machine (e.g. via a flash drive) and be able to install it on that machine without having to do a large download over a dialup connection. The easier (i.e. more directly supported) this process is, the better! Thanks, Tom From fonnesbeck at gmail.com Mon Feb 7 21:39:50 2005 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Mon Feb 7 21:39:52 2005 Subject: [Pythonmac-SIG] building pkg installers with py2app Message-ID: <723eb69305020712396d04f636@mail.gmail.com> I am trying to make an installer for my MCMC software (PyMC) with py2app, however when I try running bdist_mpkg, I get the following errors: Traceback (most recent call last): File "/usr/local/bin/bdist_mpkg", line 2, in ? from bdist_mpkg.scripts.script_bdist_mpkg import main File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/__init__.py", line 2, in ? # The Python Imaging Library. File "/purelib/py2app/bdist_mpkg/install.py", line 4, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/__init__.py", line 1, in ? # File "/purelib/py2app/bdist_mpkg/cmd_bdist_mpkg.py", line 17, in ? File "/purelib/py2app/bdist_mpkg/pkg.py", line 5, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/__init__.py", line 33, in ? File "/purelib/py2app/py2app/install.py", line 15, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/__init__.py", line 1, in ? # File "/purelib/py2app/py2app/build_app.py", line 25, in ? ImportError: No module named MachOGraph I thought MachOGraph was included with py2app. Thanks for any help. C. From bob at redivi.com Mon Feb 7 21:45:01 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 7 21:45:17 2005 Subject: [Pythonmac-SIG] building pkg installers with py2app In-Reply-To: <723eb69305020712396d04f636@mail.gmail.com> References: <723eb69305020712396d04f636@mail.gmail.com> Message-ID: On Feb 7, 2005, at 15:39, Chris Fonnesbeck wrote: > I am trying to make an installer for my MCMC software (PyMC) with > py2app, however when I try running bdist_mpkg, I get the following > errors: --- > I thought MachOGraph was included with py2app. It is, but you have an older macholib and/or bdist_mpkg installed. Any top-level packages that are also in the "py2app" directory should be removed. -bob From brendansimons at yahoo.ca Tue Feb 8 15:51:34 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Tue Feb 8 15:51:37 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <20050208110007.BA1D41E4015@bag.python.org> Message-ID: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> The conversation about Fink & Darwinports has introduced me to linuxy package managers for the first time, and I have to say, this looks much easier than trying to compile libraries and manage dependencies myself. My question: can I use py2app to build a redistributable app that's statically linked to either package manager's libraries? Or do I have to install Fink/DarwinPorts on each of my clients' machines? (I would like to develop an app that uses numeric, scientific python, wxPython, and matplotlib, which are all somewhat difficult to install by hand, but are all readily available via Fink or DarwinPorts) ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From ronaldoussoren at mac.com Tue Feb 8 16:35:48 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue Feb 8 16:35:57 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> Message-ID: <6ab4c94a7004aec9209115836d4c7c1f@mac.com> On 8-feb-05, at 15:51, Brendan Simons wrote: > The conversation about Fink & Darwinports has > introduced me to linuxy package managers for the first > time, and I have to say, this looks much easier than > trying to compile libraries and manage dependencies > myself. > > My question: can I use py2app to build a > redistributable app that's statically linked to either > package manager's libraries? Or do I have to install > Fink/DarwinPorts on each of my clients' machines? > > (I would like to develop an app that uses numeric, > scientific python, wxPython, and matplotlib, which are > all somewhat difficult to install by hand, but are all > readily available via Fink or DarwinPorts) py2app copies all required shared libraries into your application bundle. System libraries are not copied. Ronald From bob at redivi.com Tue Feb 8 16:44:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 8 16:44:37 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <6ab4c94a7004aec9209115836d4c7c1f@mac.com> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> Message-ID: <87a996012fc9d151741b8da0abfda93b@redivi.com> On Feb 8, 2005, at 10:35, Ronald Oussoren wrote: > On 8-feb-05, at 15:51, Brendan Simons wrote: > >> The conversation about Fink & Darwinports has >> introduced me to linuxy package managers for the first >> time, and I have to say, this looks much easier than >> trying to compile libraries and manage dependencies >> myself. >> >> My question: can I use py2app to build a >> redistributable app that's statically linked to either >> package manager's libraries? Or do I have to install >> Fink/DarwinPorts on each of my clients' machines? >> >> (I would like to develop an app that uses numeric, >> scientific python, wxPython, and matplotlib, which are >> all somewhat difficult to install by hand, but are all >> readily available via Fink or DarwinPorts) > > py2app copies all required shared libraries into your application > bundle. System libraries are not copied. Yes, you can use py2app with Fink (linux-y) or Darwinports (bsd-y) dependencies, but your application may become gigantic in the FInk case due to duplication of libraries the system already has. Not so much of a problem with Darwinports. -bob From Chris.Barker at noaa.gov Tue Feb 8 18:57:05 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Feb 8 18:57:09 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <87a996012fc9d151741b8da0abfda93b@redivi.com> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> Message-ID: <4208FD71.1010509@noaa.gov> Bob Ippolito wrote: >> On 8-feb-05, at 15:51, Brendan Simons wrote: >> >>> My question: can I use py2app to build a >>> redistributable app that's statically linked to either >>> package manager's libraries? Or do I have to install >>> Fink/DarwinPorts on each of my clients' machines? If you are distributing a single substantial application, py2app is probably the way to go. However, if you are distributing a set of apps, you may not want each one to have a complete copy of everything, so... >>> (I would like to develop an app that uses numeric, >>> scientific python, wxPython, and matplotlib, which are >>> all somewhat difficult to install by hand, but are all >>> readily available via Fink or DarwinPorts) The Fink and Darwinports versions of these will give you X11 versions (particularly wxPython), which you may not want (Someone please correct me if I'm wrong). In fact, if you use fink, you may get it all working with the fink Python. Will py2app bundle a fink python app? And as Bob pointed out, fink, at least, will give you a bunch if libs that duplicate ones that are included with a stock OS-X As to the "difficult to install": Numeric is easy, with either setup.py build (once it's fixed...argg!), or even easier, with the mpgk that Bob put out. matplotlib is now easy, thanks to the mpkg that I just put together (only works with Agg and wxPython at the moment, though poorly tested with wxPython. I'm planning on making a GTK and TK compatible version soon, anyone want to help?). Bob, if you're reading this, could post the link? SciPy is probably a pain in the $^%^&. I haven't tried it recently. However, my goal is to make an nice OS-X package of this as well. I'm looking for folks to help with that. My impression of fink (and darwinports may be different, I'll be checking that out) is that it's kind of an all-or-nothing proposition. If you want a Linux-like system, running in parallel to OS-X, on the same kernel, you'll be quite happy. If you want it to feel like it's part of OS-X you won't. Being a Linux geek, you'd think I'd be happy with the former, but frankly, If I want Linux,. I'll run Linux (and I do). On OS-X I want OS-X, and, more importantly, folks I work with, that I give apps too, don't want to have anything to do with Linux, command lines, X11, or figuring out apt-get. I really think we can get a complete set of OS-X friendly packages out for all to use. it's really not all that hard, once you've got the tricks figured out. We'll have a MUCH easier time getting folks to use python on OS-X if we have nice friendly binaries for them to install. By the way, what is the status of Package Manger, and the two repositories (Jack's and Bob's) Are they being maintained? should I submit matplotlib to them? If anyone want to help with my SciPy on OS-X project, please let me know. There is some real momentum in the NumPy/SciPy crowd to make SciPy easier to install right now. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From altis at semi-retired.com Tue Feb 8 19:02:09 2005 From: altis at semi-retired.com (Kevin Altis) Date: Tue Feb 8 19:02:12 2005 Subject: [Pythonmac-SIG] REMINDER: OSCON / Python 13 submissions deadline is Feb. 13th Message-ID: <2f9c1ad8ede64d877b6316400facec69@semi-retired.com> Don't forget that the deadline for submitting a talk or tutorial for OSCON / Python 13 is Sunday, February 13th. ka --- Kevin Altis altis@semi-retired.com http://altis.pycs.net/ The Call for Proposals has just opened for the 7th Annual O'Reilly Open Source Convention http://conferences.oreillynet.com/os2005/ OSCON is headed back to friendly, economical Portland, Oregon during the week of August 1-5, 2005. If you've ever wanted to join the OSCON speaker firmament, now's your chance to submit a proposal (or two) by February 13, 2005. Complete details are available on the OSCON web site, but we're particularly interested in exploring how software development is moving to another level, and how developers and businesses are adjusting to new business models and architectures. We're looking for sessions, tutorials, and workshops proposals that appeal to developers, systems and network administrators, and their managers in the following areas: - All aspects of building applications, services, and systems that use the new capabilities of the open source platform - Burning issues for Java, Mozilla, web apps, and beyond - The commoditization of software: who and/or what can show us the money? - Network-enabled collaboration - Software customizability, including software as a service - Law, licensing, politics, and how best to navigate other troubled waters Specific topics and tracks at OSCON 2005 include: Linux and other open source operating systems, Java, PHP, Python, Perl, Databases (including MySQL and PostgreSQL), Apache, XML, Applications, Ruby, and Security. Attendees have a wide range of experience, so be sure to target a particular level of experience: beginner, intermediate, advanced. Talks and tutorials should be technical; strictly no marketing presentations. Session presentations are 45 or 90 minutes long, and tutorials are either a half-day (3 hours) or a full day (6 hours). Feel free to spread the word about the Call for Proposals to your friends, family, colleagues, and compatriots. We want everyone to submit, from American women hacking artificial life into the Linux kernel to Belgian men building a better mousetrap from PHP and recycled military hardware. We mean everyone! Even if you don't want to participate as a speaker, send us your suggestions--topics you'd like to see covered, groups we should bring into the OSCON fold, extra-curricular activities we should organize--to oscon-idea@oreilly.com . This year, we're moving to the wide open spaces of the Oregon Convention Center. We've arranged for the nearby Doubletree Hotel to be our headquarters hotel--it's a short, free Max light rail ride (or a lovely walk) from the Convention Center. Registration opens in April 2005; hotel information will be available shortly. Deadline to submit a proposal is Midnight (PST), February 13. For all the conference details, go to: http://conferences.oreillynet.com/os2005/ Press coverage, blogs, photos, and news from the 2004 O'Reilly Open Source Convention can be found at: http://www.oreillynet.com/oscon2004/ Would your company like to make a big impression on the open source community? If so, consider exhibiting or becoming a sponsor. Contact Andrew Calvo at (707) 827-7176, or andrewc@oreilly.com for more info. See you Portland next summer, The O'Reilly OSCON Team From altis at semi-retired.com Tue Feb 8 19:02:09 2005 From: altis at semi-retired.com (Kevin Altis) Date: Tue Feb 8 19:03:30 2005 Subject: [Pythonmac-SIG] [Jython-users] REMINDER: OSCON / Python 13 submissions deadline is Feb. 13th Message-ID: <23567469.1107885805329.JavaMail.SYSTEM@c1879626-a> Don't forget that the deadline for submitting a talk or tutorial for OSCON / Python 13 is Sunday, February 13th. ka --- Kevin Altis altis@semi-retired.com http://altis.pycs.net/ The Call for Proposals has just opened for the 7th Annual O'Reilly Open Source Convention http://conferences.oreillynet.com/os2005/ OSCON is headed back to friendly, economical Portland, Oregon during the week of August 1-5, 2005. If you've ever wanted to join the OSCON speaker firmament, now's your chance to submit a proposal (or two) by February 13, 2005. Complete details are available on the OSCON web site, but we're particularly interested in exploring how software development is moving to another level, and how developers and businesses are adjusting to new business models and architectures. We're looking for sessions, tutorials, and workshops proposals that appeal to developers, systems and network administrators, and their managers in the following areas: - All aspects of building applications, services, and systems that use the new capabilities of the open source platform - Burning issues for Java, Mozilla, web apps, and beyond - The commoditization of software: who and/or what can show us the money? - Network-enabled collaboration - Software customizability, including software as a service - Law, licensing, politics, and how best to navigate other troubled waters Specific topics and tracks at OSCON 2005 include: Linux and other open source operating systems, Java, PHP, Python, Perl, Databases (including MySQL and PostgreSQL), Apache, XML, Applications, Ruby, and Security. Attendees have a wide range of experience, so be sure to target a particular level of experience: beginner, intermediate, advanced. Talks and tutorials should be technical; strictly no marketing presentations. Session presentations are 45 or 90 minutes long, and tutorials are either a half-day (3 hours) or a full day (6 hours). Feel free to spread the word about the Call for Proposals to your friends, family, colleagues, and compatriots. We want everyone to submit, from American women hacking artificial life into the Linux kernel to Belgian men building a better mousetrap from PHP and recycled military hardware. We mean everyone! Even if you don't want to participate as a speaker, send us your suggestions--topics you'd like to see covered, groups we should bring into the OSCON fold, extra-curricular activities we should organize--to oscon-idea@oreilly.com . This year, we're moving to the wide open spaces of the Oregon Convention Center. We've arranged for the nearby Doubletree Hotel to be our headquarters hotel--it's a short, free Max light rail ride (or a lovely walk) from the Convention Center. Registration opens in April 2005; hotel information will be available shortly. Deadline to submit a proposal is Midnight (PST), February 13. For all the conference details, go to: http://conferences.oreillynet.com/os2005/ Press coverage, blogs, photos, and news from the 2004 O'Reilly Open Source Convention can be found at: http://www.oreillynet.com/oscon2004/ Would your company like to make a big impression on the open source community? If so, consider exhibiting or becoming a sponsor. Contact Andrew Calvo at (707) 827-7176, or andrewc@oreilly.com for more info. See you Portland next summer, The O'Reilly OSCON Team ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jython-users mailing list Jython-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jython-users From Chris.Barker at noaa.gov Tue Feb 8 20:14:28 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Feb 8 20:14:32 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. Message-ID: <42090F94.7010905@noaa.gov> Hi all, I'm not sure who maintain the pythonmac wiki, but it's been spammed. What a pain in the *&%*^! for example, see: http://pythonmac.org/wiki/TkAqua -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Tue Feb 8 20:46:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 8 20:46:35 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. In-Reply-To: <42090F94.7010905@noaa.gov> References: <42090F94.7010905@noaa.gov> Message-ID: On Feb 8, 2005, at 14:14, Chris Barker wrote: > I'm not sure who maintain the pythonmac wiki, but it's been spammed. > What a pain in the *&%*^! > > for example, see: > > http://pythonmac.org/wiki/TkAqua Unfortunately I do.. but I don't really have time to deal with the spam. It has a defense in that existing pages can't be edited with too many URLs, but creating new pages lets you use as many URLs as you want. I think I'd rather replace the installation with something else or a newer version of MoinMoin before I go hacking at it any more. -bob From bob at redivi.com Tue Feb 8 20:50:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 8 20:50:10 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <4208FD71.1010509@noaa.gov> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> Message-ID: <120e54f35d575f574a77df73cbb9ea25@redivi.com> On Feb 8, 2005, at 12:57, Chris Barker wrote: > Bob Ippolito wrote: >>> On 8-feb-05, at 15:51, Brendan Simons wrote: >>> >>>> My question: can I use py2app to build a >>>> redistributable app that's statically linked to either >>>> package manager's libraries? Or do I have to install >>>> Fink/DarwinPorts on each of my clients' machines? > > If you are distributing a single substantial application, py2app is > probably the way to go. However, if you are distributing a set of > apps, you may not want each one to have a complete copy of everything, > so... Eh, you probably want them to for everything but the most controlled environments. Bandwidth and disk space is cheaper than support hassles. >>>> (I would like to develop an app that uses numeric, >>>> scientific python, wxPython, and matplotlib, which are >>>> all somewhat difficult to install by hand, but are all >>>> readily available via Fink or DarwinPorts) > > The Fink and Darwinports versions of these will give you X11 versions > (particularly wxPython), which you may not want (Someone please > correct me if I'm wrong). In fact, if you use fink, you may get it all > working with the fink Python. Will py2app bundle a fink python app? > And as Bob pointed out, fink, at least, will give you a bunch if libs > that duplicate ones that are included with a stock OS-X py2app is compatible and tested with darwinports, which means that it should also work with Fink, unless they screwed something up :) > As to the "difficult to install": > > Numeric is easy, with either setup.py build (once it's fixed...argg!), > or even easier, with the mpgk that Bob put out. > > matplotlib is now easy, thanks to the mpkg that I just put together > (only works with Agg and wxPython at the moment, though poorly tested > with wxPython. I'm planning on making a GTK and TK compatible version > soon, anyone want to help?). Bob, if you're reading this, could post > the link? > > SciPy is probably a pain in the $^%^&. I haven't tried it recently. > However, my goal is to make an nice OS-X package of this as well. I'm > looking for folks to help with that. > > My impression of fink (and darwinports may be different, I'll be > checking that out) is that it's kind of an all-or-nothing proposition. > If you want a Linux-like system, running in parallel to OS-X, on the > same kernel, you'll be quite happy. If you want it to feel like it's > part of OS-X you won't. Being a Linux geek, you'd think I'd be happy > with the former, but frankly, If I want Linux,. I'll run Linux (and I > do). On OS-X I want OS-X, and, more importantly, folks I work with, > that I give apps too, don't want to have anything to do with Linux, > command lines, X11, or figuring out apt-get. Darwinports is a lot less all-or-nothing. I have very few things activated from darwinports at a given time and it works and interoperates with the rest of the stuff I have rather well. > I really think we can get a complete set of OS-X friendly packages out > for all to use. it's really not all that hard, once you've got the > tricks figured out. We'll have a MUCH easier time getting folks to use > python on OS-X if we have nice friendly binaries for them to install. I agree. > By the way, what is the status of Package Manger, and the two > repositories (Jack's and Bob's) Are they being maintained? should I > submit matplotlib to them? Mine is not. I'm going to toss it in favor of a mpkg and/or egg based solution when one is ready. > If anyone want to help with my SciPy on OS-X project, please let me > know. There is some real momentum in the NumPy/SciPy crowd to make > SciPy easier to install right now. Well, if it will build, bdist_mpkg will package it.. -bob From hengist.podd at virgin.net Tue Feb 8 21:20:59 2005 From: hengist.podd at virgin.net (has) Date: Tue Feb 8 21:21:11 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. In-Reply-To: References: <42090F94.7010905@noaa.gov> Message-ID: Bob wrote: >>I'm not sure who maintain the pythonmac wiki, but it's been >>spammed. What a pain in the *&%*^! > >Unfortunately I do.. but I don't really have time to deal with the >spam. It has a defense in that existing pages can't be edited with >too many URLs, but creating new pages lets you use as many URLs as >you want. I think I'd rather replace the installation with >something else or a newer version of MoinMoin before I go hacking at >it any more. How about merging it into the python.org wiki? Let someone else do all the hard work for a change. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From skip at pobox.com Tue Feb 8 21:22:39 2005 From: skip at pobox.com (Skip Montanaro) Date: Tue Feb 8 21:22:45 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. In-Reply-To: References: <42090F94.7010905@noaa.gov> Message-ID: <16905.8079.710520.743327@montanaro.dyndns.org> >> http://pythonmac.org/wiki/TkAqua Bob> Unfortunately I do.. but I don't really have time to deal with the Bob> spam. It has a defense in that existing pages can't be edited with Bob> too many URLs, but creating new pages lets you use as many URLs as Bob> you want. I think I'd rather replace the installation with Bob> something else or a newer version of MoinMoin before I go hacking Bob> at it any more. Bob, I assume you're using MoinMoin 1.2.something. There is a global Moin anti-spam facility you can enable without too much trouble. Take a look at how that's managed for the python.org wiki: http://www.python.org/moin/WikiSpam That also includes a link to the main wiki page for that facility. Skip From bob at redivi.com Tue Feb 8 21:43:31 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 8 21:43:41 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. In-Reply-To: <16905.8079.710520.743327@montanaro.dyndns.org> References: <42090F94.7010905@noaa.gov> <16905.8079.710520.743327@montanaro.dyndns.org> Message-ID: On Feb 8, 2005, at 15:22, Skip Montanaro wrote: > >>> http://pythonmac.org/wiki/TkAqua > > Bob> Unfortunately I do.. but I don't really have time to deal > with the > Bob> spam. It has a defense in that existing pages can't be > edited with > Bob> too many URLs, but creating new pages lets you use as many > URLs as > Bob> you want. I think I'd rather replace the installation with > Bob> something else or a newer version of MoinMoin before I go > hacking > Bob> at it any more. > > I assume you're using MoinMoin 1.2.something. There is a global Moin > anti-spam facility you can enable without too much trouble. Take a > look at > how that's managed for the python.org wiki: > > http://www.python.org/moin/WikiSpam > > That also includes a link to the main wiki page for that facility. I think that I implemented that a while ago.. Anyway, I don't really have time to screw with it for at least a few days. If someone else wants to baby it, I'd gladly hand over the keys. -bob From charles.hartman at conncoll.edu Tue Feb 8 22:16:40 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 8 22:16:47 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <120e54f35d575f574a77df73cbb9ea25@redivi.com> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <120e54f35d575f574a77df73cbb9ea25@redivi.com> Message-ID: <8131f596becb670479fbbc8a137475a5@conncoll.edu> On Feb 8, 2005, at 2:50 PM, Bob Ippolito wrote: >> My impression of fink (and darwinports may be different, I'll be >> checking that out) is that it's kind of an all-or-nothing >> proposition. If you want a Linux-like system, running in parallel to >> OS-X, on the same kernel, you'll be quite happy. If you want it to >> feel like it's part of OS-X you won't. Being a Linux geek, you'd >> think I'd be happy with the former, but frankly, If I want Linux,. >> I'll run Linux (and I do). On OS-X I want OS-X, and, more >> importantly, folks I work with, that I give apps too, don't want to >> have anything to do with Linux, command lines, X11, or figuring out >> apt-get. > > Darwinports is a lot less all-or-nothing. I have very few things > activated from darwinports at a given time and it works and > interoperates with the rest of the stuff I have rather well. > >> I really think we can get a complete set of OS-X friendly packages >> out for all to use. it's really not all that hard, once you've got >> the tricks figured out. We'll have a MUCH easier time getting folks >> to use python on OS-X if we have nice friendly binaries for them to >> install. > > I agree. You can hardly guess how good the above music sounds to the ears of the Terminal-ly challenged & similar Mac-hacking persons like myself. I write goofy linguistic-research apps, I don't do systems stuff. People like me love Python too. Charles Hartman From bob at redivi.com Tue Feb 8 22:17:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 8 22:17:43 2005 Subject: [Pythonmac-SIG] PIL 1.1.5b3 installer for Mac OS X 10.3 Message-ID: I've put together a Mac OS X 10.3 binary installer for PIL 1.1.5b3 available here: http://undefined.org/python/Imaging-1.1.5b3-py2.3-macosx10.3.zip Details are here: http://bob.pythonmac.org/archives/2005/02/08/pil-115b3-for-mac-os-x -103/ -bob From skip at pobox.com Tue Feb 8 22:41:34 2005 From: skip at pobox.com (Skip Montanaro) Date: Tue Feb 8 22:41:44 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. In-Reply-To: References: <42090F94.7010905@noaa.gov> Message-ID: <16905.12814.210275.10098@montanaro.dyndns.org> has> How about merging it into the python.org wiki? Let someone else do has> all the hard work for a change. That thought occurred to me right after I posted my earlier reply. There are several of us that keep a fairly close eye on the python.org wiki. If you want, I'm sure the option to move would be available. Skip From bob at redivi.com Tue Feb 8 22:46:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 8 22:47:06 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. In-Reply-To: <16905.12814.210275.10098@montanaro.dyndns.org> References: <42090F94.7010905@noaa.gov> <16905.12814.210275.10098@montanaro.dyndns.org> Message-ID: <5304d2507b3281f740443cd670a0de21@redivi.com> On Feb 8, 2005, at 16:41, Skip Montanaro wrote: > > has> How about merging it into the python.org wiki? Let someone > else do > has> all the hard work for a change. > > That thought occurred to me right after I posted my earlier reply. > There > are several of us that keep a fairly close eye on the python.org wiki. > If > you want, I'm sure the option to move would be available. That works fine for me.. what are the next steps? It would be nice to have our own "namespace" so that pythonmac.org/wiki/FAQ can still url rewrite to the right place. -bob From Chris.Barker at noaa.gov Tue Feb 8 23:01:09 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Feb 8 23:01:17 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <120e54f35d575f574a77df73cbb9ea25@redivi.com> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <120e54f35d575f574a77df73cbb9ea25@redivi.com> Message-ID: <420936A5.90502@noaa.gov> Bob Ippolito wrote: > Mine is not. I'm going to toss it in favor of a mpkg and/or egg based > solution when one is ready. Sounds good to me. I've always thought that you need to make it easy, but not too easy. Years ago, someone hosted a "python on Linux" site, that had nothing but a bunch of rpm of various python packages. If you had a version of Linux that they worked with, it was great, and extremely simple. Download what you want, and install it. For OS-X, it could be even easier, as there aren't as many flavors of OS-X out there in the wild. As we all start to create more mpkgs, it there someone that wants to host the collection? Bob? Another option is for each package to be hosted at it's home (i.e. matplotlib.mpkg hosted at the matplotlib site). I'm not sure which is best, but I tend to lean toward making one site for OS-X packages. For that matter, it could be the same site as people put packages for other systems, packaged up in their native format. I tried to get something like this going a few years ago, but got very little support. I think most python programmers find it far more interesting to discuss/developer a nifty packaging system, rather than just maintaining a collection. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From fredrik at pythonware.com Tue Feb 8 23:05:48 2005 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue Feb 8 23:22:17 2005 Subject: [Pythonmac-SIG] Re: PIL 1.1.5b3 installer for Mac OS X 10.3 References: Message-ID: Bob Ippolito wrote: > I've put together a Mac OS X 10.3 binary installer for PIL 1.1.5b3 available here: > http://undefined.org/python/Imaging-1.1.5b3-py2.3-macosx10.3.zip most excellent. thanks! I've included a pointer to your blog entry in the "official" announcement. From bob at redivi.com Tue Feb 8 23:26:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 8 23:27:19 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <420936A5.90502@noaa.gov> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <120e54f35d575f574a77df73cbb9ea25@redivi.com> <420936A5.90502@noaa.gov> Message-ID: <81E653E5-7A20-11D9-AB52-000A95C93D30@redivi.com> On Feb 8, 2005, at 5:01 PM, Chris Barker wrote: > Bob Ippolito wrote: > >> Mine is not. I'm going to toss it in favor of a mpkg and/or egg >> based solution when one is ready. > > Sounds good to me. I've always thought that you need to make it easy, > but not too easy. Years ago, someone hosted a "python on Linux" site, > that had nothing but a bunch of rpm of various python packages. If you > had a version of Linux that they worked with, it was great, and > extremely simple. Download what you want, and install it. > > For OS-X, it could be even easier, as there aren't as many flavors of > OS-X out there in the wild. > > As we all start to create more mpkgs, it there someone that wants to > host the collection? Bob? I'll host packages if other people build them :) > Another option is for each package to be hosted at it's home (i.e. > matplotlib.mpkg hosted at the matplotlib site). I'm not sure which is > best, but I tend to lean toward making one site for OS-X packages. For > that matter, it could be the same site as people put packages for > other systems, packaged up in their native format. I tried to get > something like this going a few years ago, but got very little > support. I think most python programmers find it far more interesting > to discuss/developer a nifty packaging system, rather than just > maintaining a collection. It's usually easier to have a platform-specific repository because you don't have to bug the author to update his page. It would be nice to have a central place to host everything (at least metadata), and that's what PyPI aims to be someday. Without the infrastructure, you can't really maintain a large collection unless you have a lot of free time, which most people don't. -bob From skip at pobox.com Tue Feb 8 23:38:27 2005 From: skip at pobox.com (Skip Montanaro) Date: Tue Feb 8 23:38:32 2005 Subject: [Pythonmac-SIG] pythonmac Wiki has been spammed. In-Reply-To: <5304d2507b3281f740443cd670a0de21@redivi.com> References: <42090F94.7010905@noaa.gov> <16905.12814.210275.10098@montanaro.dyndns.org> <5304d2507b3281f740443cd670a0de21@redivi.com> Message-ID: <16905.16227.176203.864220@montanaro.dyndns.org> >> There are several of us that keep a fairly close eye on the >> python.org wiki. If you want, I'm sure the option to move would be >> available. Bob> That works fine for me.. what are the next steps? It would be nice Bob> to have our own "namespace" so that pythonmac.org/wiki/FAQ can Bob> still url rewrite to the right place. Let me check on the python.org maintainers list and get back to you (off-list unless there are others that care about these minutiae). Skip From troy.rollins at gmail.com Tue Feb 8 23:46:34 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Tue Feb 8 23:46:36 2005 Subject: [Pythonmac-SIG] Mac User Python newbies Message-ID: <31ac537c05020814467a2dd808@mail.gmail.com> I'm a developer who primarily works with higher level languages, and integrated tools. Director, REALbasic, Revolution. I've done plenty of advanced scripting with those tools, and am trying to move into Python for the open-source benefits, among other things. I've just ordered several books which should help me with the scripting hurdles, and the methodologies... but no matter how many web sites I scan, and how many downloads I've done, I can't quite see how to build and maintain a cohesive toolset. There are thousands of individual parts and pieces, lots of semi-working IDEs and debuggers... I've looked through some of the archives for this list, but I've yet to find anything written for Mac users that is aimed at - Getting you, the Mac user who is familiar with scripting, up and running with - 1) Python 2) An IDE and debugger (Xcode?) 3) A GUI toolkit (wxWidgets?) >From my end, I think I have evrything running, but I don't know if I want to tackle this without the "security" of an environment which includes code colorization (if not completion), a debugger, and ideally a interactive interpreter tied in for command line testing. I've taken a look at several of them, but they all seem to have stability issues. Can Xcode behave like what a Python developer would like, with the above mentioned features? Is it easy to set up? If so, that would seem to be the way to go. Is there a better option? I apologize for the newbiness of the post, but Python is a natural location for a lot of different types of people to migrate to, and I've noted a running theme about that in some recent posts here. For those of us with limited command line experience, and no C++ or low-level programming experience, it is a bit bewildering. There is almost too much info available, and none of it is aimed at getting you set up with a development toolset which can really get you off the ground, and behaves anything like an integrated experience. To move from a commercial IDE with many bells and whistles (like Director) into a black and white text editor would seem a bit harsh. Thanks for any insights, suggestions, comments, or reference links. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From bob at redivi.com Tue Feb 8 23:59:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 00:00:10 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <31ac537c05020814467a2dd808@mail.gmail.com> References: <31ac537c05020814467a2dd808@mail.gmail.com> Message-ID: <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> On Feb 8, 2005, at 5:46 PM, Troy Rollins wrote: > I'm a developer who primarily works with higher level languages, and > integrated tools. Director, REALbasic, Revolution. I've done plenty of > advanced scripting with those tools, and am trying to move into Python > for the open-source benefits, among other things. I've just ordered > several books which should help me with the scripting hurdles, and the > methodologies... but no matter how many web sites I scan, and how many > downloads I've done, I can't quite see how to build and maintain a > cohesive toolset. There are thousands of individual parts and pieces, > lots of semi-working IDEs and debuggers... Welcome to free software? > I've looked through some of the archives for this list, but I've yet > to find anything written for Mac users that is aimed at - > Getting you, the Mac user who is familiar with scripting, up and > running with - > 1) Python > 2) An IDE and debugger (Xcode?) > 3) A GUI toolkit (wxWidgets?) I'd highly recommend PyObjC if cross-platform isn't an immediate goal. Other than that, wxPython seems to be the default, but you'll probably have to fight with it to do what you want. >> From my end, I think I have evrything running, but I don't know if I > want to tackle this without the "security" of an environment which > includes code colorization (if not completion), a debugger, and > ideally a interactive interpreter tied in for command line testing. > I've taken a look at several of them, but they all seem to have > stability issues. Can Xcode behave like what a Python developer would > like, with the above mentioned features? Is it easy to set up? If so, > that would seem to be the way to go. Is there a better option? No, Xcode can not provide you with any more than syntax highlighting. Debugging is not an option beyond interacting with pdb on a console (same as you would from Terminal). It's possible to write such a feature, but there is no public API for doing so, so nobody is likely to do it. PyOXIDE is out there, Mac OS X native, and open source, but it might be immature (I don't have real experience with it, so I can't say). All the rest are either ancient and featureless (the MacPython IDE), or based on cross-platform toolkits and aren't very Mac-like. I have heard good things about Wing, which is a commercial IDE for Python, but only runs under X11 for Mac OS X. > I apologize for the newbiness of the post, but Python is a natural > location for a lot of different types of people to migrate to, and > I've noted a running theme about that in some recent posts here. For > those of us with limited command line experience, and no C++ or > low-level programming experience, it is a bit bewildering. There is > almost too much info available, and none of it is aimed at getting you > set up with a development toolset which can really get you off the > ground, and behaves anything like an integrated experience. To move > from a commercial IDE with many bells and whistles (like Director) > into a black and white text editor would seem a bit harsh. Most text editors worth using have syntax coloring, SubEthaEdit, BBEdit, Xcode, etc. Even the ones you would use from a terminal (Emacs, Vim) are going to have syntax highlighting. -bob From janssen at parc.com Wed Feb 9 00:35:04 2005 From: janssen at parc.com (Bill Janssen) Date: Wed Feb 9 00:35:25 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: Your message of "Tue, 08 Feb 2005 14:46:34 PST." <31ac537c05020814467a2dd808@mail.gmail.com> Message-ID: <05Feb8.153513pst."58617"@synergy1.parc.xerox.com> > I don't know if I > want to tackle this without the "security" of an environment which > includes code colorization (if not completion), a debugger, and > ideally a interactive interpreter tied in for command line testing. I use Emacs for all of this. python-mode.el works well for colorization, and pdb works as both an interactive interpreter and a debugger. Bill From Chris.Barker at noaa.gov Wed Feb 9 01:09:05 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 9 01:09:08 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> Message-ID: <420954A1.6050005@noaa.gov> Bob Ippolito wrote: >> Getting you, the Mac user who is familiar with scripting, up and >> running with - >> 1) Python There are a number of good books out there. I recommend "Dive Into Python" (in print or on the web) and "Learning Python" >> 2) An IDE and debugger (Xcode?) Don't be too dismayed by the lack of a fully-integrated IDE. While very nice when getting started, I'm not the least bit convinced that they really i8increase productivity in the long term. Among other things, I edit a lot of other text than Python Code, and I can only make really good use of all my editors features if I use the same editor for everything. I find I can be very productive with a good editor and a terminal. Check out iPython as well, for a better interactive interpreter. Remarkably, with Python, I still find print statement more efficient to use than a debugger. >> 3) A GUI toolkit (wxWidgets?) > I'd highly recommend PyObjC if cross-platform isn't an immediate goal. Well, if it's a goal at all, consider other options. Otherwise, Bob is right, even though I've never used it. > Other than that, wxPython seems to be the default, but you'll probably > have to fight with it to do what you want. Bob, I know you don't think much of wxPython, but please don't bad-mouth it this way. Those of us that use it don't feel like we're fighting with it. The other cross-platform options are TkInter, which has been problematic on the Mac for years, but is now better? pyGTK, which uses X11 on OS-X, and PyQT, which has licensing issues. If you want all open-source and anything resembling a OS-X look, wxPython is the only real option, but you will end up with slightly less native feeling app than PyObjC. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Wed Feb 9 01:36:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 01:36:24 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <420954A1.6050005@noaa.gov> References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> <420954A1.6050005@noaa.gov> Message-ID: <9686EF5A-7A32-11D9-AB52-000A95C93D30@redivi.com> On Feb 8, 2005, at 7:09 PM, Chris Barker wrote: > Bob Ippolito wrote: > >>> 3) A GUI toolkit (wxWidgets?) >> I'd highly recommend PyObjC if cross-platform isn't an immediate goal. > > Well, if it's a goal at all, consider other options. Otherwise, Bob is > right, even though I've never used it. Well if it's not an immediate goal, you can get something out quickly with PyObjC, and then decide how to handle the other platforms. In some cases, the UI is going to be so much easier to do in PyObjC that it's worthwhile to maintain it separately from the other platforms. In some cases, you'll want to use so much native functionality (.Mac, AddressBook, Services, better pasteboard and drag+drop, whatever) that crufting it into a single "cross-platform" code base does more harm than good anyway. >> Other than that, wxPython seems to be the default, but you'll >> probably have to fight with it to do what you want. > > Bob, I know you don't think much of wxPython, but please don't > bad-mouth it this way. Those of us that use it don't feel like we're > fighting with it. The other cross-platform options are TkInter, which > has been problematic on the Mac for years, but is now better? pyGTK, > which uses X11 on OS-X, and PyQT, which has licensing issues. If you > want all open-source and anything resembling a OS-X look, wxPython is > the only real option, but you will end up with slightly less native > feeling app than PyObjC. Well, whenever I have to use wxPython, that's how it feels. I definitely recommend it over Tkinter, pyGTK, and PyQT, though. -bob From troy.rollins at gmail.com Wed Feb 9 01:40:01 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Feb 9 01:40:07 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> Message-ID: <31ac537c050208164047d9f1f8@mail.gmail.com> On Tue, 8 Feb 2005 17:59:46 -0500, Bob Ippolito wrote: > > On Feb 8, 2005, at 5:46 PM, Troy Rollins wrote: > > cohesive toolset. There are thousands of individual parts and pieces, > > lots of semi-working IDEs and debuggers... > > Welcome to free software? Ha. Fair enough. I guess my point is mostly that Python seems pretty mature, and yet still manages to be scattered. I realize that the best thing would be for me to take the task on myself, but I'm barely versed enough yet to run packageManager... and frankly don't even know if that is the best way to manage all the parts and pieces. > > 1) Python > > 2) An IDE and debugger (Xcode?) > > 3) A GUI toolkit (wxWidgets?) > > I'd highly recommend PyObjC if cross-platform isn't an immediate goal. > Other than that, wxPython seems to be the default, but you'll probably > have to fight with it to do what you want. I've looked at this, and it looks as though it will allow the use of Interface Builder for GUI, driven by Python. While that is only a Mac solution, it may be a great route to get started with. So, I take it that I don't have to use Xcode for the code writing...? > No, Xcode can not provide you with any more than syntax highlighting. > Debugging is not an option beyond interacting with pdb on a console > (same as you would from Terminal). It's possible to write such a > feature, but there is no public API for doing so, so nobody is likely > to do it. Fair enough, then Xcode is out, unless it is required for PyObjc. > > PyOXIDE is out there, Mac OS X native, and open source, but it might be > immature (I don't have real experience with it, so I can't say). All > the rest are either ancient and featureless (the MacPython IDE), or > based on cross-platform toolkits and aren't very Mac-like. I have > heard good things about Wing, which is a commercial IDE for Python, but > only runs under X11 for Mac OS X. I've tried PyOxide, which is very promising, but doesn't seem fully stable yet. Currently, Wing seems the best equipped, but its X11 approach feels a bit like a Java app. I guess it may be the best available right now, and it is certainly more stable than the others. > >> To move > > from a commercial IDE with many bells and whistles (like Director) > > into a black and white text editor would seem a bit harsh. > > Most text editors worth using have syntax coloring, SubEthaEdit, > BBEdit, Xcode, etc. Even the ones you would use from a terminal > (Emacs, Vim) are going to have syntax highlighting. Yes, SubEthaEdit does seem pretty good for Python (I actually use it for Lingo too.) > > -bob Thank you for the input! -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From sw at wordtech-software.com Wed Feb 9 01:52:04 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Feb 9 01:52:09 2005 Subject: [Pythonmac-SIG] IDE for wxPython Message-ID: <42095EB4.10201@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Troy, If wxPython is the toolkit you settle on, check out Stani's Python Editor (SPE): it's built with wxPython and is a nice overall package. The core IDE includes an editor and syntax checker, but it also includes ~ wxGlade (a GUI designer), Kiki (regular expressions), and some other goodies. I have just become the Mac maintainer for it and have a package available at http://www.wordtech-software.com/spe.html . There's a new version just out, which I haven't updated yet, but hope to in the next day or so. If you're interested in PyQt, I also have a binary installer of that, including the Eric3 IDE--it's very nice and somewhat more mature than SPE--at http://www.wordtech-software.com/pyqt-mac.html Welcome! Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCV6zJmdQs+6YVcoRAk6eAJ9FTqwSxcNCzjSdV8/PeCnzAATdPACfVqxs YIeH/XCyx/j+uZ7pQAD14Xg= =CgDs -----END PGP SIGNATURE----- From bob at redivi.com Wed Feb 9 01:58:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 01:58:46 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <31ac537c050208164047d9f1f8@mail.gmail.com> References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> <31ac537c050208164047d9f1f8@mail.gmail.com> Message-ID: On Feb 8, 2005, at 7:40 PM, Troy Rollins wrote: > On Tue, 8 Feb 2005 17:59:46 -0500, Bob Ippolito wrote: >> >> On Feb 8, 2005, at 5:46 PM, Troy Rollins wrote: > >>> cohesive toolset. There are thousands of individual parts and pieces, >>> lots of semi-working IDEs and debuggers... >> >> Welcome to free software? > > Ha. Fair enough. I guess my point is mostly that Python seems pretty > mature, and yet still manages to be scattered. I realize that the best > thing would be for me to take the task on myself, but I'm barely > versed enough yet to run packageManager... and frankly don't even know > if that is the best way to manage all the parts and pieces. Probably because most of the Python world isn't developing GUI applications (though seems to be a big swing in this direction). Also, Mac OS X has only been around a few years and there aren't many people working on making it better (though I'm sure there are lots of people using it), so you can't really expect a best of breed solution just yet. I wouldn't really recommend doing much with PackageManager, it's an OK way to get started, but it has a lot of problems and its packages aren't up to date (at least mine aren't, I no longer maintain my repository). Your best bet is to learn how to build packages from source (usually "python setup.py install"), and/or use the binary installers provided for several popular packages (wxPython, PyObjC, PIL, matplotlib). PyObjC (via py2app) ships with a little "PackageInstaller" application that will create Apple Installer packages out of most packages and install them.. simply drop a setup.py or a directory containing setup.py on top of it. PackageInstaller should be installed to /Developer/Python/py2app (or something close to that). If it fails to work, it probably won't provide any useful output, but most packages should work. >>> 1) Python >>> 2) An IDE and debugger (Xcode?) >>> 3) A GUI toolkit (wxWidgets?) >> >> I'd highly recommend PyObjC if cross-platform isn't an immediate goal. >> Other than that, wxPython seems to be the default, but you'll probably >> have to fight with it to do what you want. > > I've looked at this, and it looks as though it will allow the use of > Interface Builder for GUI, driven by Python. While that is only a Mac > solution, it may be a great route to get started with. So, I take it > that I don't have to use Xcode for the code writing...? > >> No, Xcode can not provide you with any more than syntax highlighting. >> Debugging is not an option beyond interacting with pdb on a console >> (same as you would from Terminal). It's possible to write such a >> feature, but there is no public API for doing so, so nobody is likely >> to do it. > > Fair enough, then Xcode is out, unless it is required for PyObjc. PyObjC has no dependency on Xcode. It ships with Xcode templates, but they are a little behind the times and are not the recommended way to deploy applications because they do not integrate with py2app. >> PyOXIDE is out there, Mac OS X native, and open source, but it might >> be >> immature (I don't have real experience with it, so I can't say). All >> the rest are either ancient and featureless (the MacPython IDE), or >> based on cross-platform toolkits and aren't very Mac-like. I have >> heard good things about Wing, which is a commercial IDE for Python, >> but >> only runs under X11 for Mac OS X. > > I've tried PyOxide, which is very promising, but doesn't seem fully > stable yet. Currently, Wing seems the best equipped, but its X11 > approach feels a bit like a Java app. I guess it may be the best > available right now, and it is certainly more stable than the others. Speaking of Java, there's also Eclipse, which has Python support. I've never done more than start the thing though. -bob From charles.hartman at conncoll.edu Wed Feb 9 02:09:28 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Feb 9 02:09:33 2005 Subject: [Pythonmac-SIG] IDE for wxPython In-Reply-To: <42095EB4.10201@wordtech-software.com> References: <42095EB4.10201@wordtech-software.com> Message-ID: <43fc52175825e14a68402d32529e4eaf@conncoll.edu> If you try SPE, I'd be very interested to hear your results. It's beautiful, and very extensive. But I have not been able to make it work. (The same has been true for me with wxGlade. It may be my fault, or the fault of my system.) Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Feb 8, 2005, at 7:52 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Troy, > > If wxPython is the toolkit you settle on, check out Stani's Python > Editor (SPE): it's built with wxPython and is a nice overall package. > The core IDE includes an editor and syntax checker, but it also > includes > ~ wxGlade (a GUI designer), Kiki (regular expressions), and some other > goodies. I have just become the Mac maintainer for it and have a > package > available at http://www.wordtech-software.com/spe.html . There's a new > version just out, which I haven't updated yet, but hope to in the next > day or so. > > If you're interested in PyQt, I also have a binary installer of that, > including the Eric3 IDE--it's very nice and somewhat more mature than > SPE--at http://www.wordtech-software.com/pyqt-mac.html > > Welcome! > > Cheers, > > Kevin Walzer, PhD > WordTech Software--Open Source Applications and Packages for OS X > http://www.wordtech-software.com > http://www.smallbizmac.com > http://www.kevin-walzer.com > mailto:sw@wordtech-software.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFCCV6zJmdQs+6YVcoRAk6eAJ9FTqwSxcNCzjSdV8/PeCnzAATdPACfVqxs > YIeH/XCyx/j+uZ7pQAD14Xg= > =CgDs > -----END PGP SIGNATURE----- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Chris.Barker at noaa.gov Wed Feb 9 02:15:55 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 9 02:16:27 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> <31ac537c050208164047d9f1f8@mail.gmail.com> Message-ID: <4209644B.3000206@noaa.gov> Bob Ippolito wrote: > Also, > Mac OS X has only been around a few years and there aren't many people > working on making it better (though I'm sure there are lots of people > using it), so you can't really expect a best of breed solution just yet. True, but frankly, the IDE situation is not that much better on Linux or Windows. > Speaking of Java, there's also Eclipse, which has Python support. Has anyone else tried this? I'm still looking for the holy grail of the same IDE on OS-X, Linux and Windows....Eclipse looks promising. Troy Rollins wrote: > Ha. Fair enough. I guess my point is mostly that Python seems pretty > mature, and yet still manages to be scattered. Well, C and C++ are pretty mature, but if want scattered pieces...Remember, Python is a language, not a development environment, and not a commercial product. And these are good things. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From rogerb at rogerbinns.com Wed Feb 9 04:12:54 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 9 04:12:52 2005 Subject: [Pythonmac-SIG] Mac User Python newbies References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> Message-ID: <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> > Probably because most of the Python world isn't developing GUI > applications (though seems to be a big swing in this direction). As a counterpoint, there are approximately 30,000 downloads of wxPython for each version. wxPython is typically used by developers and the packaged apps are used by the end users, with the latter not being reflected in the downloads. https://sourceforge.net/project/showfiles.php?group_id=10718 > Mac OS X has only been around a few years and there aren't many people > working on making it better (though I'm sure there are lots of people > using it), so you can't really expect a best of breed solution just > yet. There was, and still is to a certain degree a relative high cost barrier of entry for doing MacOS stuff, especially for developers who want to support multiple platforms. The Mac mini has helped, but the lack of virtualisation software still hinders. Apple also has around 5% market share of the desktop which means when people are deciding where to allocate their time, they have to think real hard about supporting Apple. Roger From troy.rollins at gmail.com Wed Feb 9 04:16:24 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Feb 9 04:16:27 2005 Subject: [Pythonmac-SIG] Re: IDE for wxPython In-Reply-To: <42095EB4.10201@wordtech-software.com> References: <42095EB4.10201@wordtech-software.com> Message-ID: <31ac537c0502081916462562a1@mail.gmail.com> > If wxPython is the toolkit you settle on, check out Stani's Python > Editor (SPE): it's built with wxPython and is a nice overall package. > The core IDE includes an editor and syntax checker, but it also includes > ~ wxGlade (a GUI designer), Kiki (regular expressions), and some other > goodies. I have just become the Mac maintainer for it and have a package > available at http://www.wordtech-software.com/spe.html . There's a new > version just out, which I haven't updated yet, but hope to in the next > day or so. Thanks, I've tried this tool, and even got the wordtech binary (at different times). It looks to be pretty close, but still has some problems, though I wasn't logging them, mostly just installing, running, quick feature evaluation, moving on... I'll be interested to see the update. > > If you're interested in PyQt, I also have a binary installer of that, > including the Eric3 IDE--it's very nice and somewhat more mature than > SPE--at http://www.wordtech-software.com/pyqt-mac.html Yes, I've seen that too, and it is an interesting idea, but IIRC Trolltech QT is quite expensive, no? Once Python takes its part in paying the bills, I'll be more able to look at that stuff. Currently, my company makes virtually ALL of our income off of Director and Flash, but I'm getting tired of having my wagon hitched quite so tightly to Macromedia. I need to know that I have open source options... > > Welcome! Thank you. I'll apologize in advance for being a pest, but eventually I hope to contribute something. Incidentally, I think wordtech is doing a good job of making binary installers availble. That is important to us Mac users who have been shielded from terminal syntax for most of our lives! While I love the fact that we have a unix terminal now, I still don't know my way around it very well yet. Now Lingo... that I know. ;-) -- Troy Rollins www.rpsystems.net From bob at redivi.com Wed Feb 9 04:44:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 04:45:01 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> Message-ID: <22258ca60eaed45585a961b01d226f08@redivi.com> On Feb 8, 2005, at 22:12, Roger Binns wrote: >> Mac OS X has only been around a few years and there aren't many >> people working on making it better (though I'm sure there are lots of >> people using it), so you can't really expect a best of breed solution >> just yet. > > There was, and still is to a certain degree a relative high cost > barrier of entry for doing MacOS stuff, especially for developers who > want > to support multiple platforms. The Mac mini has helped, but the > lack of virtualisation software still hinders. Apple also has around > 5% market share of the desktop which means when people are deciding > where to allocate their time, they have to think real hard about > supporting Apple. This is a very valid point, but since when has that really mattered to people writing open source software? Windows certainly doesn't seem to have more support from the open source community than anything else. As a counter-point, deploying software on Mac OS X is cheap and fast. You save god knows how much time and money in development and testing (especially testing), so you have much higher profit margins. Virtualization software is useful (and I'd love it to death if it was around), but I've found it to be rarely necessary for Mac OS X development. I only have to use 10.2 when testing, and rarely have to make any changes to accommodate it. MacOnLinux showed some promise a while ago, but it doesn't seem to be actively developed these days and it didn't work well last I tried it. -bob From janssen at parc.com Wed Feb 9 05:05:52 2005 From: janssen at parc.com (Bill Janssen) Date: Wed Feb 9 05:06:14 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: Your message of "Tue, 08 Feb 2005 16:36:07 PST." <9686EF5A-7A32-11D9-AB52-000A95C93D30@redivi.com> Message-ID: <05Feb8.200554pst."58617"@synergy1.parc.xerox.com> > Well, whenever I have to use wxPython, that's how it feels. I > definitely recommend it over Tkinter, pyGTK, and PyQT, though. Hmmm. I like portable applications, so am usually forced to write UIs in Java Swing. But when I do use Python, I prefer PyGTK; I think the toolkit is better designed, provides more modern UI concepts, and more flexible. But I agree it's a real pain to install -- too many independent sub-package dependencies. And as far as I can tell, the two projects aimed at porting GTK+ to Carbon or Cocoa have both died. Bill From rkern at ucsd.edu Wed Feb 9 05:26:48 2005 From: rkern at ucsd.edu (Robert Kern) Date: Wed Feb 9 05:26:51 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <4208FD71.1010509@noaa.gov> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> Message-ID: <42099108.5090708@ucsd.edu> Chris Barker wrote: > I really think we can get a complete set of OS-X friendly packages out > for all to use. it's really not all that hard, once you've got the > tricks figured out. We'll have a MUCH easier time getting folks to use > python on OS-X if we have nice friendly binaries for them to install. > > By the way, what is the status of Package Manger, and the two > repositories (Jack's and Bob's) Are they being maintained? should I > submit matplotlib to them? > > If anyone want to help with my SciPy on OS-X project, please let me > know. There is some real momentum in the NumPy/SciPy crowd to make SciPy > easier to install right now. Scipy is actually one of the easier packages for me to bdist_mpkg up. OTOH, I've been building scipy regularly for *years* now. http://www.scipy.org/wikis/featurerequests/MacEnthon I was hoping to have some beta packages out this week, but personal annoyances are probably going to push it out of the way right now. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From rogerb at rogerbinns.com Wed Feb 9 06:07:32 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 9 06:07:30 2005 Subject: [Pythonmac-SIG] Mac User Python newbies References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> Message-ID: <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> > This is a very valid point, but since when has that really mattered to > people writing open source software? Windows certainly doesn't seem to > have more support from the open source community than anything else. http://sourceforge.net/softwaremap/trove_list.php?form_cat=418 > As a counter-point, deploying software on Mac OS X is cheap and fast. > You save god knows how much time and money in development and testing > (especially testing), so you have much higher profit margins. It doesn't matter how cheap and fast it is for 5% of the market. If you look at open source graphical toolkits that support at least two platforms, you won't find any that started on the Mac. These are the ones I know of that can be used from Python and where they started. - QT (Unix) - GTK (Unix) - wxWidgets (Windows) - Tk (Unix) - Fltk (Unix) - Fox (Unix) Consequently the Mac versions of these (if supported at all) is often not as good as the original platform. That results in a bit of a chicken and egg problem. There is no/little Mac support by other developers because the toolkits are poor, and the toolkits don't improve because noone uses them. Fortunately it just takes some sustained efforts, even just bug reporting and things get better. wxWidgets has gotten a lot better although there are still holes. For the OP, one choice is to try and help improve a toolkit at the same time as doing their own project. It will end up improving things for many more developers and users. > Virtualization software is useful (and I'd love it to death if it was > around), but I've found it to be rarely necessary for Mac OS X > development. It solves many configuration management and testing issues. It also lets the developer use the machine. For example I can't use the Apple Addressbook or Calendar programs for my real data. I fill them with all sorts of test data. (Fast user switching sort of helps but brings other issues). And you really need virtualisation when you have to deal with versioning issues of core system components or the OS itself. For BitPim we have to do seperate 10.2 and 10.3 builds, and there are now all sorts of 10.2 issues that aren't addressed. When Tiger comes out things will get even worse as developers will have to decide which version to make their primary supported OS version. QEMU has some support for emulating a PPC system. Maybe that will work in the future. Roger From bob at redivi.com Wed Feb 9 06:36:45 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 06:36:57 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> Message-ID: <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> On Feb 9, 2005, at 12:07 AM, Roger Binns wrote: >> This is a very valid point, but since when has that really mattered >> to people writing open source software? Windows certainly doesn't >> seem to have more support from the open source community than >> anything else. > > http://sourceforge.net/softwaremap/trove_list.php?form_cat=418 Yeah, exactly. There's not even twice as many Windows projects as Mac OS X projects, and far more Linux projects that Windows projects. These numbers aren't very good anyway, NetBSD's pkgsrc has over 5300 packages, and there are 204 marked NetBSD on sourceforge! >> As a counter-point, deploying software on Mac OS X is cheap and fast. >> You save god knows how much time and money in development and >> testing (especially testing), so you have much higher profit margins. > > It doesn't matter how cheap and fast it is for 5% of the market. Sure it does, if you release OS X first it can fund Windows development and testing. Worked fine for us. > If you look at open source graphical toolkits that support at least > two platforms, you won't find any that started on the Mac. These > are the ones I know of that can be used from Python and where they > started. > > - QT (Unix) > - GTK (Unix) > - wxWidgets (Windows) > - Tk (Unix) > - Fltk (Unix) > - Fox (Unix) > > Consequently the Mac versions of these (if supported at all) is often > not as good as the original platform. That results in a bit of a > chicken and egg problem. There is no/little Mac support by other > developers because the toolkits are poor, and the toolkits don't > improve because noone uses them. I think we're probably going to have real GNUStep support for PyObjC sometime in the next few months.. though I'm not sure whether the NeXT roots count as Mac or not. > Fortunately it just takes some sustained efforts, even just bug > reporting > and things get better. wxWidgets has gotten a lot better although > there > are still holes. > > For the OP, one choice is to try and help improve a toolkit at the same > time as doing their own project. It will end up improving things for > many more developers and users. That's definitely an option with any open source dependency :) -bob From delza at livingcode.org Wed Feb 9 06:46:48 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Feb 9 06:47:03 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> Message-ID: <6aad4d0ea0ce7f6e5d64475c55a0f7a7@livingcode.org> On 8-Feb-05, at 9:07 PM, Roger Binns wrote: > - QT (Unix) > - GTK (Unix) > - wxWidgets (Windows) > - Tk (Unix) > - Fltk (Unix) > - Fox (Unix) Of course there are also: - Swing (Unix) - Mozilla/XUL Runner (???) - GnuStep (Unix) [This lets you use most of the OS X UI on Unix and Windows] - PyGame (Unix?) - OpenGL (and PyUI wrapper) - Whatever the Eclipse widget layer is called - etc. What you use depends largely on what your needs are. If you're windows developers who want to port to Mac, wx is your friend. If you develop in Smalltalk, Squeak brings it's own UI wherever you go. If you want to develop kick-ass Mac apps, PyObjC is the only game in town (in my opinion). If you want to be all things to all people, I'd suggest taking a good long hard look at Mozilla and XUL (one of their goals is to support Python as a first-class language for XUL-based applications). --Dethe Ninety percent of the technology hasn't even been developed yet. --Tim Armstrong, Google -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050208/dd2db34a/smime.bin From rogerb at rogerbinns.com Wed Feb 9 07:50:42 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 9 07:50:41 2005 Subject: [Pythonmac-SIG] Mac User Python newbies References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> Message-ID: <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> > Yeah, exactly. There's not even twice as many Windows projects as Mac > OS X projects, and far more Linux projects that Windows projects. Note that it didn't include Windows 98 or the generic Win32 category (trying to categorise a project on SourceForge is a real pain!) >> It doesn't matter how cheap and fast it is for 5% of the market. > > Sure it does, if you release OS X first it can fund Windows development > and testing. Worked fine for us. A counterpoint (see 1/3 of the way in) http://www.joelonsoftware.com/articles/fog0000000051.html wxPython certainly goes a decent amount of the way towards his underlying message. And MacOS is on a nice uptick since that was written. This is all just proof of the network effect and what it takes to overcome it (perseverence). Some other food for thought: http://www.joelonsoftware.com/articles/fog0000000017.html http://www.joelonsoftware.com/articles/Platforms.html http://www.joelonsoftware.com/articles/fog0000000020.html http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/fog0000000052.html It is all our interest to make Mac a better platform and to make it very easy to write code that just works on Mac and elsewhere. One of the things I am proud of in BitPim is the almost equal(*) seamless support of all platforms. As a developer, operating systems and APIs matter to me. But as a user, they are irrelevant. You want programs to just work on whatever is connected to your mouse, keyboard and screen. (*) The Mac is the least equal due to wxWidgets and me not being able to get a reasonably priced Mac. The Mac mini fixed the latter and OSAF paid for some of the former. > I think we're probably going to have real GNUStep support for PyObjC > sometime in the next few months.. though I'm not sure whether the NeXT > roots count as Mac or not. I did have it in my draft email, but couldn't find suitable Python bindings. I'd be happy to count it as Mac. Which incidentally is one of the annoying things come fresh to Mac as a developer. There is all this legacy NS crap! It is *nowhere* near as bad as the legacy in Windows though, or even the Linuxisms :-) Roger From bob at redivi.com Wed Feb 9 08:37:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 08:38:04 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> Message-ID: <83CA1BAB-7A6D-11D9-AB52-000A95C93D30@redivi.com> On Feb 9, 2005, at 1:50 AM, Roger Binns wrote: >> Yeah, exactly. There's not even twice as many Windows projects as >> Mac OS X projects, and far more Linux projects that Windows projects. > > Note that it didn't include Windows 98 or the generic Win32 category > (trying to categorise a project on SourceForge is a real pain!) Even still, given how wrong it is for NetBSD, I find it hard to assign any weight at all to what sourceforge's numbers are. >>> It doesn't matter how cheap and fast it is for 5% of the market. >> Sure it does, if you release OS X first it can fund Windows >> development and testing. Worked fine for us. > > A counterpoint (see 1/3 of the way in) > > http://www.joelonsoftware.com/articles/fog0000000051.html > > wxPython certainly goes a decent amount of the way towards his > underlying > message. And MacOS is on a nice uptick since that was written. This > is all just proof of the network effect and what it takes to overcome > it (perseverence). That article is four and a half years old, and it doesn't account for a lot of things. In our case, it was roughly 10x easier to hit the Mac platform first and it made a lot more sense given the startup capital and time we wanted to spend on launching the product. It's also a lot easier to get press for Mac software, for whatever reason, where we'd have to spend even more money marketing the Windows version to get it out there. The Mac version paid for the Windows version, threw free press in our direction, and got us a publishing deal. In hindsight, I'd have done it the same way. I can't really say whether we have more Windows users or Mac users now, because our software doesn't phone home and both versions ship together. There is a disproportionate amount of support requests on the Windows side, but that's because it more or less Just Works on the Mac, where there seems to be some weirdness on some obscure Windows configurations that we can't reproduce (unfortunately we're at the mercy of some other software and hardware for this product). > Some other food for thought: > > http://www.joelonsoftware.com/articles/fog0000000017.html > http://www.joelonsoftware.com/articles/Platforms.html > http://www.joelonsoftware.com/articles/fog0000000020.html > http://www.joelonsoftware.com/articles/APIWar.html > http://www.joelonsoftware.com/articles/fog0000000052.html > > It is all our interest to make Mac a better platform and to make > it very easy to write code that just works on Mac and elsewhere. > One of the things I am proud of in BitPim is the almost equal(*) > seamless support of all platforms. As a developer, operating > systems and APIs matter to me. But as a user, they are irrelevant. > You want programs to just work on whatever is connected to your mouse, > keyboard and screen. > > (*) The Mac is the least equal due to wxWidgets and me not being > able to get a reasonably priced Mac. The Mac mini fixed the latter > and OSAF paid for some of the former. The user also doesn't care if the UI code isn't shared between all platforms as long as they're maintained. The Tkinter GUI and the PyObjC GUI share a bunch of code (as much as is reasonable). The Tkinter GUI actually has code in it to emulate a bunch of Mac-isms and it reads resources directly out of its sibling Mac OS X bundle (metadata, localization, and the application's data). I'd have used wx, but Tkinter was easier for this and wasn't as big. >> I think we're probably going to have real GNUStep support for PyObjC >> sometime in the next few months.. though I'm not sure whether the >> NeXT roots count as Mac or not. > > I did have it in my draft email, but couldn't find suitable Python > bindings. I'd be happy to count it as Mac. Which incidentally is > one of the annoying things come fresh to Mac as a developer. There > is all this legacy NS crap! It is *nowhere* near as bad as the > legacy in Windows though, or even the Linuxisms :-) NS is just a namespace.. Not much of it *feels* legacy :) At least they're consistent. -bob From brian_l at mac.com Wed Feb 9 09:31:46 2005 From: brian_l at mac.com (Brian Lenihan) Date: Wed Feb 9 09:31:54 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> <31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> Message-ID: <923092d33ee13c08a293cf3229028694@mac.com> On Feb 8, 2005, at 10:50 PM, Roger Binns wrote: >> Yeah, exactly. There's not even twice as many Windows projects as >> Mac OS X projects, and far more Linux projects that Windows projects. > > Note that it didn't include Windows 98 or the generic Win32 category > (trying to categorise a project on SourceForge is a real pain!) > >>> It doesn't matter how cheap and fast it is for 5% of the market. >> Sure it does, if you release OS X first it can fund Windows >> development and testing. Worked fine for us. > > A counterpoint (see 1/3 of the way in) > > http://www.joelonsoftware.com/articles/fog0000000051.html > > wxPython certainly goes a decent amount of the way towards his > underlying > message. And MacOS is on a nice uptick since that was written. This > is all just proof of the network effect and what it takes to overcome > it (perseverence). > > Some other food for thought: > > http://www.joelonsoftware.com/articles/fog0000000017.html > http://www.joelonsoftware.com/articles/Platforms.html > http://www.joelonsoftware.com/articles/fog0000000020.html > http://www.joelonsoftware.com/articles/APIWar.html > http://www.joelonsoftware.com/articles/fog0000000052.html > > It is all our interest to make Mac a better platform and to make > it very easy to write code that just works on Mac and elsewhere. > One of the things I am proud of in BitPim is the almost equal(*) > seamless support of all platforms. As a developer, operating > systems and APIs matter to me. But as a user, they are irrelevant. > You want programs to just work on whatever is connected to your mouse, > keyboard and screen. > > (*) The Mac is the least equal due to wxWidgets and me not being > able to get a reasonably priced Mac. The Mac mini fixed the latter > and OSAF paid for some of the former. > >> I think we're probably going to have real GNUStep support for PyObjC >> sometime in the next few months.. though I'm not sure whether the >> NeXT roots count as Mac or not. > > I did have it in my draft email, but couldn't find suitable Python > bindings. I'd be happy to count it as Mac. Which incidentally is > one of the annoying things come fresh to Mac as a developer. There > is all this legacy NS crap! It is *nowhere* near as bad as the > legacy in Windows though, or even the Linuxisms :-) > > Roger > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig After all that, I'd like to say this: BitPim is pretty impressive, despite its dependency on DSV. I have a $5.00 a month ATT plan that precludes me from enjoying any of the benefits with my personal cell phone (hate), but that does not prevent me from enjoying the benefits with my jewel-encrusted corporate-supplied phone. If I was getting more than 4 hours, on average, of sleep, I'd consider helping, but I'm getting too old to live like this. Some things, no matter how beautiful, must be admired from afar. If life was fair, I'd have sold all of my stock at the perfect time and given half of the proceeds to Fredrik Lund[1] and the other half to Bob Ippolito, and the rest to Jack Jansen. I'd even have kicked a few bucks to Just. And Guido, well he will just have to wait until he gets to heaven, where I am sure he will get his just rewards. [1] I did manage to kick a few bucks Fredrik's way and got a really crappy yo-yo in return, but I will always cherish it. From bob at redivi.com Wed Feb 9 10:23:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 10:23:39 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <923092d33ee13c08a293cf3229028694@mac.com> References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> <31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> <923092d33ee13c08a293cf3229028694@mac.com> Message-ID: <3F28A2C4-7A7C-11D9-AB52-000A95C93D30@redivi.com> On Feb 9, 2005, at 3:31 AM, Brian Lenihan wrote: > After all that, I'd like to say this: BitPim is pretty impressive, > despite its dependency on DSV. I have a $5.00 a month ATT plan that > precludes me from enjoying any of the benefits with my personal cell > phone (hate), but that does not prevent me from enjoying the benefits > with my jewel-encrusted corporate-supplied phone. > > If I was getting more than 4 hours, on average, of sleep, I'd consider > helping, but I'm getting too old to live like this. Some things, no > matter how beautiful, must be admired from afar. > > If life was fair, I'd have sold all of my stock at the perfect time > and given half of the proceeds to Fredrik Lund[1] and the other half > to Bob Ippolito, and the rest to Jack Jansen. I'd even have kicked a > few bucks to Just. And Guido, well he will just have to wait until he > gets to heaven, where I am sure he will get his just rewards. > > [1] I did manage to kick a few bucks Fredrik's way and got a really > crappy yo-yo in return, but I will always cherish it. That must have been an impressive portfolio, if you would've had money left over for Jack and Just after giving away both both halves of the proceeds! :) -bob From ray.slakinski at gmail.com Wed Feb 9 13:40:49 2005 From: ray.slakinski at gmail.com (Ray Slakinski) Date: Wed Feb 9 13:40:38 2005 Subject: [Pythonmac-SIG] Threads and Saving Plists Message-ID: <14b848b9fcac970769511fac6286a1ae@gmail.com> Hey all, I got a bit of an issue, I am trying to multithread a script but as part of that thread it needs to save to a common plist file, what happens that every so often when running more that one thread at a time is that I get an error either reading or writing to said plist file and I can only assume that its because another thread has hold of the file. Does anyone here on this list know of a good way around this issue? Ray Slakinski From moehl at akaflieg.extern.tu-berlin.de Wed Feb 9 15:41:02 2005 From: moehl at akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Wed Feb 9 15:41:03 2005 Subject: [Pythonmac-SIG] wxPython/vtk/OpenGL problem In-Reply-To: <8b175619ef06862fc59db7c82fd856ec@redivi.com> References: <1C76FD4C-78C1-11D9-A100-000A95C93D30@redivi.com> <8b175619ef06862fc59db7c82fd856ec@redivi.com> Message-ID: Unluckily I have had no success so far. glFinish is in OpenGL.GL but the OpenGL module is not directly used. They use wx.glcanvas.GLCanvas and with it GLContext. Obviously everything works and nothing happens. Using the OpenGL Profiler I found that I get 2 GL Contexts. One with a bunch of actions and one empty. So maybe VTK fails to get the wxPython GL Context, creates its own and the empty wx context is displayed. Torsten On Mon, 7 Feb 2005, Bob Ippolito wrote: > > On Feb 7, 2005, at 7:53, Torsten Sadowski wrote: > > > does anyone have an idea how to debug a (probably) OpenGL problem on > > Mac > > OSX? I have the latest wxPython with working PyOpenGL (which is > > probably > > not used) and VTK 4.4. When I try to run anything which would give me > > a 3D > > output, like pythonw wxVTKRenderWindow.py, I get nothing. I would > > suspect > > something with Apples triple buffering but where is the best point to > > start looking? > > Most of the time OpenGL contexts are only double buffered. This sounds > like a bug or incompatibility in VTK or wx. You could try calling > glFinish() at the end of the render loop, but I don't have VTK > installed here so I can't look to see what's wrong with it. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From brendansimons at yahoo.ca Wed Feb 9 16:09:54 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Wed Feb 9 16:09:58 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <20050209073804.8E8461E400A@bag.python.org> Message-ID: <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> > It doesn't matter how cheap and fast it is for 5% of > the market. > > If you look at open source graphical toolkits that > support at least > two platforms, you won't find any that started on > the Mac. These > are the ones I know of that can be used from Python > and where they > started. > > - QT (Unix) > - GTK (Unix) > - wxWidgets (Windows) > - Tk (Unix) > - Fltk (Unix) > - Fox (Unix) > > Consequently the Mac versions of these (if supported > at all) is often > not as good as the original platform. I'd just like to point out an exception to your rule. REALBasic was originally developed for the mac, but now includes versions for windows and linux. Any one version can cross compile to the other two platforms, and their (proprietary) guikit produces native-looking & feeling apps on each. In fact, I found developing quick applications so easy I was happy to buy a license. This just goes to show that there IS money to be made catering to mac users. In fact, the only reason I've switched to Python is to future-proof my applications. (But I would -love- to have an IDE / gui builder as simple as the one that came with RB) -Brendan ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From troy.rollins at gmail.com Wed Feb 9 16:15:17 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Feb 9 16:15:25 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual Message-ID: <31ac537c05020907152044c458@mail.gmail.com> The next inevitable MacPython newbie question is regarding Apple's Python vs. a manual installation. It seems that Apple's is not in the same path location it would be if it were installed manually, and also that it is now at least a dot revision behind. I'm not really concerned about one or the other, however I have noticed the tools like PyOxide and some others act as though they are a bit lost on my drive (not being able to find files they need, which are there, etc.) This tends to make things look broken, when they probably actually aren't. Is there some Python Path variable that I have control over? If so, uhhh, recommendations on how that is done? (Amazon, hurry that shipment of knowledge please!!) Also, if Package Manager is not recommended, what is? How do you keep track of, and maintain your installation and modules? Fink? How do you browse your available modules, fo instance to determine function calls and syntax? Frankly, the language itself looks a lot simpler than maintaining the installation and keeping track of what you have to work with. ;-) -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From troy.rollins at gmail.com Wed Feb 9 16:24:09 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Feb 9 16:24:23 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> References: <20050209073804.8E8461E400A@bag.python.org> <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> Message-ID: <31ac537c05020907245873ea3a@mail.gmail.com> > I'd just like to point out an exception to your rule. > REALBasic was originally developed for the mac, but > now includes versions for windows and linux. Any one > version can cross compile to the other two platforms, > and their (proprietary) guikit produces native-looking > & feeling apps on each. In fact, I found developing > quick applications so easy I was happy to buy a > license. > > This just goes to show that there IS money to be made > catering to mac users. In fact, the only reason I've > switched to Python is to future-proof my applications. > (But I would -love- to have an IDE / gui builder as > simple as the one that came with RB) Totally agree! And I'm moving to Python for the same reasons as well. Personally, I thing all of the current GUI builders look like Windows ports (since they mostly are), and do not reflect the way a Mac user would develop anything, never mind a GUI designer. For the most part, I think it is going to take a tool which originates on the Mac to be one which actually looks and behaves like Mac users would expect.... which I suppose is what PyObjC is all about... -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From charles.hartman at conncoll.edu Wed Feb 9 17:22:31 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Feb 9 17:22:36 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual In-Reply-To: <31ac537c05020907152044c458@mail.gmail.com> References: <31ac537c05020907152044c458@mail.gmail.com> Message-ID: On Feb 9, 2005, at 10:15 AM, Troy Rollins wrote: > (Amazon, hurry that shipment of knowledge please!!) Speaking of which, I'd really like to hear people's judgment about what is currently Essential Reading on Python, I mean in print rather than online. (I always feel better if I have something to *study*!) Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com From troy.rollins at gmail.com Wed Feb 9 17:34:30 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Feb 9 17:34:38 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual In-Reply-To: <13156980-7AB5-11D9-88DB-000A95ACCDAA@gearyweb.com> References: <31ac537c05020907152044c458@mail.gmail.com> <13156980-7AB5-11D9-88DB-000A95ACCDAA@gearyweb.com> Message-ID: <31ac537c05020908345e288773@mail.gmail.com> On Wed, 9 Feb 2005 09:10:11 -0700, michael geary wrote: > Hey Troy, I didn't realize you were on this list too. Hah. Mac > Director/Python users unite! > Yep. Personally, I see Python as a natural movement for a Director developer to make. Now if I just had an IDE ! I know, it isn't required, but I LIKE them. Especially for apps which have a GUI. I plan to have a look at Eclipse next. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From bob at redivi.com Wed Feb 9 18:01:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 18:01:46 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual In-Reply-To: <31ac537c05020907152044c458@mail.gmail.com> References: <31ac537c05020907152044c458@mail.gmail.com> Message-ID: <55a97b10e9043d6abc5895c1218e557d@redivi.com> On Feb 9, 2005, at 10:15, Troy Rollins wrote: > The next inevitable MacPython newbie question is regarding Apple's > Python vs. a manual installation. It seems that Apple's is not in the > same path location it would be if it were installed manually, and also > that it is now at least a dot revision behind. It's in a different location because it's a system component that should be upgraded by the vendor not by the user. It's five dot revisions behind, but for the most part this is a non-issue. > I'm not really concerned about one or the other, however I have > noticed the tools like PyOxide and some others act as though they are > a bit lost on my drive (not being able to find files they need, which > are there, etc.) This tends to make things look broken, when they > probably actually aren't. Is there some Python Path variable that I > have control over? If so, uhhh, recommendations on how that is done? > (Amazon, hurry that shipment of knowledge please!!) The particular installation of Python that your IDE chooses is more or less IDE specific. From the Terminal, it checks your PATH variable to find an installation of Python. > Also, if Package Manager is not recommended, what is? How do you keep > track of, and maintain your installation and modules? Fink? How do you > browse your available modules, fo instance to determine function calls > and syntax? I don't recommend Darwinports or Fink for Python modules unless you're developing X11 applications. See yesterday's "Fink, Darwinports vs py2app" thread. Browsing available modules is IDE specific. pydoc is good for looking at a particular module, but if it's PyObjC you should be consulting Apple's Objective-C documentation. There's a straightforward translation between Objective-C and Python in that case. > Frankly, the language itself looks a lot simpler than maintaining the > installation and keeping track of what you have to work with. ;-) Usually you don't use too much stuff, the standard library comes with most of the functionality you need. In an extreme case, I might need four of five "third party" packages. -bob From rogerb at rogerbinns.com Wed Feb 9 18:06:30 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 9 18:06:27 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits References: <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> Message-ID: <006e01c50ec9$b3196b10$3501a8c0@rogersqyvr14d3> > I'd just like to point out an exception to your rule. > REALBasic was originally developed for the mac, REALBasic is not open source, nor does it have Python bindings. > This just goes to show that there IS money to be made > catering to mac users. And? The original point was that people doing applications are best served by picking where they'll get the most paying customers for their initial effort. Once they have done that, supporting other platforms involves ensuring the extra revenue is in line with the costs to move to that platform. (And "supporting" other platforms means that the application works, looks and feels like a native application). Market conditions, VC financing, publicity, competition, risk/reward tradeoffs, company size etc all tweak what is best done. One of the things that Python does, exactly as you pointed out, is significantly reduce the costs of supporting other platforms. Unfortunately the various Python graphical toolkits that also support Mac still have rough edges, and some don't support it at all. That leaves Mac Python developers with two choices. You can either use the native APIs which will give a better application but make it harder to port to other platforms, or use one of the toolkits and help improve it. That will take more effort, but will benefit the platform because it will reduce the time and monetary costs of other applications also moving to Mac. Roger From rogerb at rogerbinns.com Wed Feb 9 18:14:07 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 9 18:14:03 2005 Subject: [Pythonmac-SIG] Mac User Python newbies References: <31ac537c05020814467a2dd808@mail.gmail.com> <20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com> <31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> <923092d33ee13c08a293cf3229028694@mac.com> Message-ID: <008201c50eca$c376e9a0$3501a8c0@rogersqyvr14d3> > After all that, I'd like to say this: BitPim is pretty impressive, > despite its dependency on DSV. Eh? DSV is one file, available as open source and is used to parse comma seperated values files (or Delimiter Seperated Values to be more generic). I can't see how that is remotely relevant. Roger From janssen at parc.com Wed Feb 9 18:33:43 2005 From: janssen at parc.com (Bill Janssen) Date: Wed Feb 9 18:34:05 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: Your message of "Tue, 08 Feb 2005 20:05:52 PST." <05Feb8.200554pst."58617"@synergy1.parc.xerox.com> Message-ID: <05Feb9.093350pst."58617"@synergy1.parc.xerox.com> > I like portable applications, so am usually forced to write UIs > in Java Swing. But when I do use Python, I prefer PyGTK Of course, perhaps the right thing to do is use Jython with Swing. That way you get to use Python with an Apple-supported binding to Cocoa. Or perhaps IronPython on Mono with GTK#, if Jim H. hasn't been swallowed by the beast. I guess we'll know in March if IronPython lives. Bill From rogerb at rogerbinns.com Wed Feb 9 18:37:23 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 9 18:37:19 2005 Subject: [Pythonmac-SIG] Mac User Python newbies References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> <83CA1BAB-7A6D-11D9-AB52-000A95C93D30@redivi.com> Message-ID: <008901c50ece$03b8ed30$3501a8c0@rogersqyvr14d3> > Even still, given how wrong it is for NetBSD, I find it hard to assign > any weight at all to what sourceforge's numbers are. http://freshmeat.net/browse/199/ Quite simply my experience has been that there is a large amount of open source for Windows, despite Microsoft's general disdain for it. I believe a lot of this is because there is such a large user base. > That article is four and a half years old, and it doesn't account for a > lot of things. None of his points have been invalidated. The market share numbers are roughly the same. Yes there will be different cases such as yours. There used to be a belief, especially from the UNIX community that the right thing to do is support all platforms equally and at the same time for a first release. Noone believes that any more. > together. There is a disproportionate amount of support requests on > the Windows side, but that's because it more or less Just Works on the > Mac, where there seems to be some weirdness on some obscure Windows > configurations that we can't reproduce (unfortunately we're at the > mercy of some other software and hardware for this product). Handling support is one of the biggest difficulties for general consumer software these days. Most companies try to do it by hiding the costs (include the price into the software), treating all customers equally and treating support as a loss centre and try to minimise its costs. That typically ends up frustrating the users and the company. I think the next generation of successful companies will be those that figure out better solutions to the support side. It may involve telling some customers to go away. One trend is definitely to improve the amount of diagnostics available to track down issues. Python is really cool for this. You can get traces including information down to the variable level. Here is an example: http://article.gmane.org/gmane.comp.mobile.bitpim.user/2218 The holy grail would a diagnostics dump that can be fed into virtualisation software that then sets up everything in the same way :-) > The user also doesn't care if the UI code isn't shared between all > platforms as long as they're maintained. The Tkinter GUI and the > PyObjC GUI share a bunch of code (as much as is reasonable). The > Tkinter GUI actually has code in it to emulate a bunch of Mac-isms and > it reads resources directly out of its sibling Mac OS X bundle > (metadata, localization, and the application's data). I'd have used > wx, but Tkinter was easier for this and wasn't as big. I originally did my first Python guis using Tkinter. In the end I was very annoyed that I had to write my own combobox widget, and moved to wxPython and have been very happy there ever since. It looks like Tkinter still doesn't address things like printing, drag and drop and various other things needed by full featured applications. When choosing a Python gui toolkit for BitPim, these were the main points: Tkinter Lowest common denominator Draws widgets itself Unpleasant prior experience Stagnant Qt High common functionality Not open source on Windows Draws widgets itself GTK Linuxy Draws widgets itself wxWidgets/wxPython High common functionality Uses native widgets where possible Very active community Pleasant prior experience More detail is at http://bitpim.org/papers/baypiggies/ Roger From speno at isc.upenn.edu Wed Feb 9 18:47:57 2005 From: speno at isc.upenn.edu (John P Speno) Date: Wed Feb 9 18:47:58 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual In-Reply-To: <31ac537c05020908345e288773@mail.gmail.com> References: <31ac537c05020907152044c458@mail.gmail.com> <13156980-7AB5-11D9-88DB-000A95ACCDAA@gearyweb.com> <31ac537c05020908345e288773@mail.gmail.com> Message-ID: <20050209174757.GA1466@isc.upenn.edu> On Wed, Feb 09, 2005 at 11:34:30AM -0500, Troy Rollins wrote: > developer to make. Now if I just had an IDE ! I know, it isn't > required, but I LIKE them. Especially for apps which have a GUI. I > plan to have a look at Eclipse next. As another python programmer who doesn't use an IDE, allow me to add... Here's something based off Eclipse that supports python, supposedly. It's also available for free in a "foundation" version vs. the "professional edition" http://www.xored.com/trustudio/ From Chris.Barker at noaa.gov Wed Feb 9 19:14:30 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 9 19:15:10 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <83CA1BAB-7A6D-11D9-AB52-000A95C93D30@redivi.com> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> <83CA1BAB-7A6D-11D9-AB52-000A95C93D30@redivi.com> Message-ID: <420A5306.9030408@noaa.gov> Bob Ippolito wrote: > In our case, it was roughly 10x easier to hit the Mac > platform first. Wow! That is a BIG ratio...really? > The Tkinter GUI and the PyObjC > GUI share a bunch of code (as much as is reasonable). Ah, that explains it. > The Tkinter GUI > actually has code in it to emulate a bunch of Mac-isms and it reads > resources directly out of its sibling Mac OS X bundle (metadata, > localization, and the application's data). And that explains it more. You ended up writing your own X-platform toolkit. > I'd have used wx, but Tkinter was easier for this It doesn't sound like it to me. Anyway, I think it is much harder to make a version on one platform, and then port it to another, than it is to make it cross-platform from the beginning. This was Joel's point: once you have a Windows version, making a Mac version is unlikely to be cheap enough to do. In your case, it worked, because the Windows market is about 10X as big as the Mac market, so it was worth spending 10X the effort. If you had used wx from the beginning, I suspect the whole process would have been cheaper, you could have improved wx, rather than writing a Cocoa emulation layer for Tk. Of course, wx would have to have been at least as good as it is now for OS-X, which it has only been recently. Perhaps you couldn't have gotten the full Mac experience right either, but it sounds like at the moment, you don't have the full Windows experience, which may matter less, Windows users being what they are. By the way, I say this from the perspective of a house that has been developing Mac + Windows software for a while. Most of it is written in C++, with the Mac as the primary platform, and Windows as the second. We have an in-house cross-platform layer, that is essentially a Mac emulation layer for Windows. The result is a lot of work, and applications that don't really look right on Windows. More recently, we developed an app with CodeWarrior PowerPlant on the Mac, and MFC on Windows. We ended up with an app that is very native on both platforms, but it took a heck of a lot of work. The Model is shared, but the GUIs are completely independent, and took almost twice as long as a result. We've now started using wxWidgets with C++ (I'm still working on getting folks to use Python for "real apps"). Our last App took maybe 10% longer to do for both platforms that it would have for one, and I did a Linux port in about a week total (two programmer-years for the whole app). It looks and feels pretty darn native on all three platforms. We are very happy. There is no way we're ever going to get a linux port of any of our other apps. In fact, we don't yet even have an OS-X port of any of our apps other than the wxWidgets one. If anyone's interested, here are a couple of our apps: GNOME (home grown Mac + Windows toolkit) http://response.restoration.noaa.gov/software/gnome/gnome.html ADIOS2 (PowerPlant and MFC) http://response.restoration.noaa.gov/software/adios/adios.html The wxWidgets one is not available to the public (I'm working on that!) -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Wed Feb 9 19:27:53 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 9 19:28:27 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <31ac537c05020907245873ea3a@mail.gmail.com> References: <20050209073804.8E8461E400A@bag.python.org> <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> <31ac537c05020907245873ea3a@mail.gmail.com> Message-ID: <420A5629.70104@noaa.gov> Troy Rollins wrote: > Personally, I thing all of the current GUI builders look like Windows > ports (since they mostly are), and do not reflect the way a Mac user > would develop anything, never mind a GUI designer. For the most part, > I think it is going to take a tool which originates on the Mac to be > one which actually looks and behaves like Mac users would expect.... This is a very good point, but it's really not about the GUI toolkit, it's about choices that the designer makes. I've made it a personal mission to try to keep people from using MDI with wxPython, but it's a hard one with Windows developers...(SPE was one of these) wx uses the native widgets for the most part, so how Mac-like and app is is really a function of how it's designed. Not that every Mac-ism is supported, but it's pretty close. > which I suppose is what PyObjC is all about... I'm sure you could write an app with Cocoa that didn't look or feel like a Mac app either, but it would be harder. That being said, I think there is a convergent of styles between Windows, Mac, and Unix. It's just not that different anymore. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Wed Feb 9 19:42:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 19:42:20 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <420A5306.9030408@noaa.gov> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <95CF9714-7A5C-11D9-AB52-000A95C93D30@redivi.com> <021901c50e73$acb5f140$3501a8c0@rogersqyvr14d3> <83CA1BAB-7A6D-11D9-AB52-000A95C93D30@redivi.com> <420A5306.9030408@noaa.gov> Message-ID: <3ad55aff1fa7f1a5646bd479fdb97e48@redivi.com> On Feb 9, 2005, at 13:14, Chris Barker wrote: > Bob Ippolito wrote: > >> In our case, it was roughly 10x easier to hit the Mac platform first. > > Wow! That is a BIG ratio...really? Yeah, Cocoa already did all the view stuff and it took no time at all to lay it out in Interface Builder. The domain specific stuff was easier too, but not by as much. >> The Tkinter GUI and the PyObjC GUI share a bunch of code (as much as >> is reasonable). > > Ah, that explains it. > >> The Tkinter GUI actually has code in it to emulate a bunch of >> Mac-isms and it reads resources directly out of its sibling Mac OS X >> bundle (metadata, localization, and the application's data). > > And that explains it more. You ended up writing your own X-platform > toolkit. Sharing the localization support was just common sense and was trivial to write. It was all coming from excel spreadsheets originally anyway, and it was trivial to use Apple's ".strings" format. The way you said it sounds way more complicated than it actually was. None of the view code is shared, if that's what you're thinking. Sharing the data was going to be an application specific problem any which way, so I don't think that's relevant. >> I'd have used wx, but Tkinter was easier for this > > It doesn't sound like it to me. > > Anyway, I think it is much harder to make a version on one platform, > and then port it to another, than it is to make it cross-platform from > the beginning. This was Joel's point: once you have a Windows version, > making a Mac version is unlikely to be cheap enough to do. In your > case, it worked, because the Windows market is about 10X as big as the > Mac market, so it was worth spending 10X the effort. > > If you had used wx from the beginning, I suspect the whole process > would have been cheaper, you could have improved wx, rather than > writing a Cocoa emulation layer for Tk. Of course, wx would have to > have been at least as good as it is now for OS-X, which it has only > been recently. Perhaps you couldn't have gotten the full Mac > experience right either, but it sounds like at the moment, you don't > have the full Windows experience, which may matter less, Windows users > being what they are. For this application, the Windows problems are entirely in the application domain and have nothing at all to do with the windowing toolkit. The only thing "non-windows-like" is that it doesn't have an installer, it's just an exe file that sits next to the Mac .app folder and requires no installation. In this case, I had no interest in improving wx for Mac, I knew I could get it done properly and very quickly going straight to Cocoa. I didn't want to waste any time, as it was important to get it out there quickly. Also, using wxWindows would've added at least another 2 megs to the compressed download size of our application on the Mac side, which would've been marginally acceptable, but certainly not desirable. > By the way, I say this from the perspective of a house that has been > developing Mac + Windows software for a while. Most of it is written > in C++, with the Mac as the primary platform, and Windows as the > second. We have an in-house cross-platform layer, that is essentially > a Mac emulation layer for Windows. The result is a lot of work, and > applications that don't really look right on Windows. More recently, > we developed an app with CodeWarrior PowerPlant on the Mac, and MFC on > Windows. We ended up with an app that is very native on both > platforms, but it took a heck of a lot of work. The Model is shared, > but the GUIs are completely independent, and took almost twice as long > as a result. Cocoa is a LOT easier to use than PowerPlant is.. -bob From kevino at tulane.edu Wed Feb 9 19:40:46 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed Feb 9 19:42:53 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> References: <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> Message-ID: <6f01331c915983ed6d5adfb8fd4ccb24@tulane.edu> Hi Brendan, On Feb 9, 2005, at 7:09 AM, Brendan Simons wrote: >> It doesn't matter how cheap and fast it is for 5% of >> the market. >> >> If you look at open source graphical toolkits that >> support at least >> two platforms, you won't find any that started on >> the Mac. These >> are the ones I know of that can be used from Python >> and where they >> started. >> >> - QT (Unix) >> - GTK (Unix) >> - wxWidgets (Windows) >> - Tk (Unix) >> - Fltk (Unix) >> - Fox (Unix) >> >> Consequently the Mac versions of these (if supported >> at all) is often >> not as good as the original platform. (Sorry, I don't see the original message in my inbox, so am responding to both posts at once.) Well, depending on what is meant by "as good as" you can give any answer to this question. ;-) If you mean 100% optimized for that platform, well, it's doubtful any toolkit except for the native ones will reach that lofty goal, just as no program but Microsoft Word will ever reach 100% Word compatibility. (Actually, even IT doesn't achieve that goal, but anyways...) But the reason all of this is basically silly to discuss is that in the end it's about needs. For example: 1) Are there Mac-specific features your app needs that the cross-platform toolkit doesn't have? 2) How important is cross-platform support for your app? 3) What's your budget/resources for development, or for a Mac port? Depending on your needs, wxWidgets (or Real Basic, etc.) may very well support everything you're looking for. If you have other needs, then maybe Mac only is the way to go. (i.e. wxPython does have an emulated list control, an issue we hopefully will have resolved for 2.8, along with CoreGraphics drawing!) Emulated toolkits don't support native LNF in any real sense so unless you want emulated they're plain out. But "as good as" discussions are largely academic. You can always use it to make the point you want by just messing with the criteria you use. Depending on the criteria (i.e. site compatibility), one can 'prove' that Safari and Mozilla both are clearly inferior to IE. Once you add another criteria, though (i.e. security or on Mac lack of updates), the whole equation changes. But the only real use of said discussions is trying to "scare" someone into using another product or taking a certain approach. So, my advice to anyone doing GUI development - try what's out there and see what suits you, then use it. Period. While I can certainly see the merit in discussing specific shortcomings of a toolkit (and hopefully discussing solutions, too!) I don't see much merit at all in these simple "this toolkit is inferior because it's not made on Mac" type of discussions that keep popping up. [snip] > This just goes to show that there IS money to be made > catering to mac users. In fact, the only reason I've > switched to Python is to future-proof my applications. > (But I would -love- to have an IDE / gui builder as > simple as the one that came with RB) Yes, the IDE department is an area that cross-platform development could really use some improvement in! The trick is getting it right, because you have to abstract layout to some degree in order to support the HIGs of the various platforms but also make everything 'drag and drop' GUI. Thanks, Kevin From mwh at python.net Wed Feb 9 20:00:39 2005 From: mwh at python.net (Michael Hudson) Date: Wed Feb 9 20:00:42 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual In-Reply-To: (Charles Hartman's message of "Wed, 9 Feb 2005 11:22:31 -0500") References: <31ac537c05020907152044c458@mail.gmail.com> Message-ID: <2macqd5zjc.fsf@starship.python.net> Charles Hartman writes: > On Feb 9, 2005, at 10:15 AM, Troy Rollins wrote: > >> (Amazon, hurry that shipment of knowledge please!!) > > Speaking of which, I'd really like to hear people's judgment about > what is currently Essential Reading on Python, I mean in print rather > than online. (I always feel better if I have something to *study*!) Of course, "it depends". Dive into Python looks pretty good. Python in a Nutshell contains a vast amount of information. I've heard OK reports of Learning Python. On the other hand, I've managed to avoid owning any books on Python at all apart from the one I tech reviewed 9which sucked). YMMV. Cheers, mwh -- Not only does the English Language borrow words from other languages, it sometimes chases them down dark alleys, hits them over the head, and goes through their pockets. -- Eddy Peters From troy.rollins at gmail.com Wed Feb 9 20:32:53 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Feb 9 20:33:07 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <420A5629.70104@noaa.gov> References: <20050209073804.8E8461E400A@bag.python.org> <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> <31ac537c05020907245873ea3a@mail.gmail.com> <420A5629.70104@noaa.gov> Message-ID: <31ac537c05020911327ac5b211@mail.gmail.com> > > which I suppose is what PyObjC is all about... > > I'm sure you could write an app with Cocoa that didn't look or feel like > a Mac app either, but it would be harder. > > That being said, I think there is a convergent of styles between > Windows, Mac, and Unix. It's just not that different anymore. In theory that is certainly true, in practice... well, for some odd reason there is a LOT of bad GUI in the windows world, and VERY little good. Mac users pay more attention to GUI, and that exists to this day, even though the toolsets are similar if the exactly the same. Mac programs look and feel better on the whole than Windows programs do. I used iTunes on Windows the other day and said "you know, if all windows apps worked like this, it might be ok..." (And yes, I know that iTunes breaks almost every HIG rule, but what I'm talking about is simply the careful layout and consideration of design, not the "by the book GUI".) The concept of an environment like REALbasic, Mac-like GUI designer, editor, debugger, but which uses Python as the language sounds just wonderful to me. That is an environment I could work in every day ? like I do Director now. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From bob at redivi.com Wed Feb 9 20:45:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 9 20:45:36 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <31ac537c05020911327ac5b211@mail.gmail.com> References: <20050209073804.8E8461E400A@bag.python.org> <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> <31ac537c05020907245873ea3a@mail.gmail.com> <420A5629.70104@noaa.gov> <31ac537c05020911327ac5b211@mail.gmail.com> Message-ID: <26668FF0-7AD3-11D9-A9DF-000A95C93D30@redivi.com> On Feb 9, 2005, at 2:32 PM, Troy Rollins wrote: >>> which I suppose is what PyObjC is all about... >> >> I'm sure you could write an app with Cocoa that didn't look or feel >> like >> a Mac app either, but it would be harder. >> >> That being said, I think there is a convergent of styles between >> Windows, Mac, and Unix. It's just not that different anymore. > > In theory that is certainly true, in practice... well, for some odd > reason there is a LOT of bad GUI in the windows world, and VERY little > good. Mac users pay more attention to GUI, and that exists to this > day, even though the toolsets are similar if the exactly the same. Mac > programs look and feel better on the whole than Windows programs do. I > used iTunes on Windows the other day and said "you know, if all > windows apps worked like this, it might be ok..." (And yes, I know > that iTunes breaks almost every HIG rule, but what I'm talking about > is simply the careful layout and consideration of design, not the "by > the book GUI".) Uh.. yeah :) > The concept of an environment like REALbasic, Mac-like GUI designer, > editor, debugger, but which uses Python as the language sounds just > wonderful to me. That is an environment I could work in every day ? > like I do Director now. I believe that PythonCard is attempting to become such an environment, and it is based on wxPython so it will be cross-platform like the other platforms you have significant experience with. It sounds like it is coming along well, but I haven't played with it significantly. -bob From troy.rollins at gmail.com Wed Feb 9 21:00:35 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Wed Feb 9 21:07:19 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <26668FF0-7AD3-11D9-A9DF-000A95C93D30@redivi.com> References: <20050209073804.8E8461E400A@bag.python.org> <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> <31ac537c05020907245873ea3a@mail.gmail.com> <420A5629.70104@noaa.gov> <31ac537c05020911327ac5b211@mail.gmail.com> <26668FF0-7AD3-11D9-A9DF-000A95C93D30@redivi.com> Message-ID: <31ac537c050209120085f39f1@mail.gmail.com> > > I believe that PythonCard is attempting to become such an environment, > and it is based on wxPython so it will be cross-platform like the other > platforms you have significant experience with. It sounds like it is > coming along well, but I haven't played with it significantly. > I did take a look at PythonCard, and it does seem to be heading in a good direction. FWIW, I made another run at PyOxide, and had a good experience. It seems that it is hard-coded to wanting to live in your applications folder. Once placed there it seemed to run fine, including debugger, module browsers, etc. Doesn't help particularly with GUI issues, but it does seem a quite nice editor and project manager with good interactive features. I'll probably use it, and PythonCard as my initial tools, until I have a better overall sense of what I really need (which will probably turn out to be a text editor!!) -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From shannyk at mac.com Wed Feb 9 23:11:34 2005 From: shannyk at mac.com (- drive - drift - dream -) Date: Wed Feb 9 23:11:38 2005 Subject: [Pythonmac-SIG] Panther and Pydance... Message-ID: <8F9991B1-7AE7-11D9-A329-0050E4A06312@mac.com> I was just sent over here from a different group, I'm unable to run Pydance since I upgraded to Panther. At first I was unable to run any of the MacPython things without them immediately crashing after a dock bounce, but I was able to mess around with permissions and stuff enough that I could get PackageManager to run, and downloaded the Pygame stuff from there. Pydance will still not run, though, immediately crashes when you start it. I can't downgrade to Jaguar, as the machine it needs to run on is a new iBook, which Jaguar won't run on. I don't know anything about programming in Python. The Pydance people say they've never found a fix for it, or even found out what's wrong. Can anyone help? Thanks! From jhrsn at pitt.edu Wed Feb 9 23:27:58 2005 From: jhrsn at pitt.edu (Jim Harrison) Date: Wed Feb 9 23:25:35 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <26668FF0-7AD3-11D9-A9DF-000A95C93D30@redivi.com> Message-ID: on 2/9/05 2:45 PM, Bob Ippolito at bob@redivi.com wrote: >> The concept of an environment like REALbasic, Mac-like GUI designer, >> editor, debugger, but which uses Python as the language sounds just >> wonderful to me. Perhaps in the vein of historical trivia, there have been previous ties between REALbasic and python. Some years back there was an abortive attempt to create a REALbasic-like development environment for python, written in REALbasic. Though not related to that effort, Joe Strout is one of the senior engineers at REALbasic and he had a background in python before going to RB. Perhaps coincidentally, pythonic concepts like variants (dynamically-typed variables) and "for each x in y" started showing up in RB after his arrival. No help with the current issue, sorry--this just tweaked some memories. Jim Harrison From Chris.Barker at noaa.gov Thu Feb 10 00:28:08 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Feb 10 00:28:43 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> Message-ID: <420A9C88.3080901@noaa.gov> Just a slight clarification: Roger Binns wrote: > If you look at open source graphical toolkits that support at least > two platforms, you won't find any that started on the Mac. These > are the ones I know of that can be used from Python and where they started. > > - QT (Unix) > - wxWidgets (Windows) > - Fox (Unix) Actually, I know wxWidgets was designed, from the beginning, to be cross platform, specifically targeting Windows and Unix (X, originally Motif). I think that's where the "w" and "x" comes from. I think QT and Fox were designed that way from the start as well. You're certainly correct that none of them had the Mac as a target at the beginning. If only Apple would port Cocoa to Unix and Windows. Bob Ippolito wrote: > I think we're probably going to have real GNUStep support for PyObjC > sometime in the next few months. Cool. How usable is GnuStep on Windows now? and how compatible are GnuStep and Cocoa? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Thu Feb 10 00:35:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 00:35:39 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <200502041158.32890.richard@commonground.com.au> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> Message-ID: <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> On Feb 3, 2005, at 7:58 PM, Richard Jones wrote: > On Fri, 4 Feb 2005 01:34 am, Bob Ippolito wrote: >> No, py2app just doesn't give you a regular Python interpreter.. so, >> that's a problem I guess. I'm not sure what to suggest. > > Yep, looks like it's the killer for the py2app'ed Zope. > > I'm going to investigate another approach of using os.system() to > control > Zope, but that's not nearly as nice as it doesn't let me at the zdaemon > control code directly (I'll have to parse shell command output > instead) and > bundle a second Python interpreter with the app. The current svn trunk of py2app is probably suitable for this. It now: - Strips by default. -S and --strip are still there for compatibility, but they are a no-op (does anyone care if I remove this compatibility?) - Scans the bundle for any Mach-O file and rewrites it - Now you don't have to care about making py2app aware of every extension if you setup the sys.path property.. but you will still need to make sure everything used from the stdlib ends up in there because it special cases this and makes a "minimal" Python.framework, so it's still a good idea to do this. - Adds a Python interpreter to the bundle to where sys.executable is (only supported for framework builds right now) In order to run this sub-interpreter, you will probably need to be careful about setting up sys.path via PYTHONPATH, PYTHONHOME, etc. I have yet to develop a full example to test the functionality, but will probably have one soon. If you want to make sure the right libraries/extensions get loaded, I suggest running the app with the DYLD_PRINT_LIBRARIES environment variable set to make sure it doesn't pull anything out of /Library/Frameworks/Python.framework -bob From bob at redivi.com Thu Feb 10 00:53:05 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 00:53:10 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <420A9C88.3080901@noaa.gov> References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com> <01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <420A9C88.3080901@noaa.gov> Message-ID: On Feb 9, 2005, at 6:28 PM, Chris Barker wrote: > Just a slight clarification: > > Roger Binns wrote: >> If you look at open source graphical toolkits that support at least >> two platforms, you won't find any that started on the Mac. These >> are the ones I know of that can be used from Python and where they >> started. >> - QT (Unix) >> - wxWidgets (Windows) > > - Fox (Unix) > > Actually, I know wxWidgets was designed, from the beginning, to be > cross platform, specifically targeting Windows and Unix (X, originally > Motif). I think that's where the "w" and "x" comes from. > > I think QT and Fox were designed that way from the start as well. > > You're certainly correct that none of them had the Mac as a target at > the beginning. If only Apple would port Cocoa to Unix and Windows. They did when they were called NeXT -- but sadly, it was pulled when WebObjects moved to Java. With access to an old enough version of WebObjects, you can actually install Project Builder, Interface Builder, the runtime, etc. on Windows, but the license doesn't allow you to redistribute. > Bob Ippolito wrote: >> I think we're probably going to have real GNUStep support for PyObjC >> sometime in the next few months. > > Cool. How usable is GnuStep on Windows now? and how compatible are > GnuStep and Cocoa? Foundation (gnustep-base) is supposed to be fine on Windows, AppKit still needs a lot of work (they accept donations now ). GNUStep and Cocoa seem mostly API compatible as long as you're not using anything new. Interface Builder nibs are not platform agnostic, but GNUStep Renaissance is available on both platforms, and GNUStep has tools to convert nibs to gmodel (not Renaissance, and the translation isn't perfect). So, when we have GNUStep support, it will only really be a solution for X11. Decent Windows support will happen, eventually. -bob From richard at commonground.com.au Thu Feb 10 01:35:01 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Feb 10 01:35:13 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> Message-ID: <77ac5045473c834b12be384bd5af1291@commonground.com.au> On 10/02/2005, at 10:35 AM, Bob Ippolito wrote: > - Adds a Python interpreter to the bundle to where sys.executable is > (only supported for framework builds right now) Thanks Bob! I'll have a play straight away :) Richard From richard at commonground.com.au Thu Feb 10 02:00:35 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Feb 10 02:00:44 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> Message-ID: On 10/02/2005, at 10:35 AM, Bob Ippolito wrote: > The current svn trunk of py2app is probably suitable for this. It now: > - Strips by default. -S and --strip are still there for > compatibility, but they are a no-op (does anyone care if I remove this > compatibility?) I get the following error during py2app invocation: /usr/bin/strip: object: /Users/richard/src/cg/CGPublisher-Zope/dist/CGPublisher-Zope.app/ Contents/Frameworks/Python.framework/Versions/2.3/Python truncated or malformed object (LC_SEGMENT command 2 fileoff field plus filesize field extends past the end of the file) and then this when I try to run the app: 2005-02-10 11:54:41.210 CGPublisher-Zope[5269] dyld: ./dist/CGPublisher-Zope.app/Contents/MacOS/CGPublisher-Zope truncated or malformed library: /Users/richard/src/cg/CGPublisher-Zope/dist/CGPublisher-Zope.app/ Contents/Frameworks/Python.framework/Versions/2.3/Python (load command 2 fileoff plus filesize extends past end of the library) The file in question is: -rwxr-xr-x 1 richard richard 1239416 10 Feb 11:54 Python if that's any help (probably not). Also, the output at the end of stripping says "stripping saved 0 bytes (7077472 / 7077472)". Full log of output (stdout) from py2app invocation is attached. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: log.txt.bz2 Type: application/octet-stream Size: 5054 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050210/12961023/log.txt.obj From bob at redivi.com Thu Feb 10 02:06:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 02:06:54 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> Message-ID: <5d640cd8da2f11645004d8adda3136a1@redivi.com> On Feb 9, 2005, at 20:00, Richard Jones wrote: > On 10/02/2005, at 10:35 AM, Bob Ippolito wrote: >> The current svn trunk of py2app is probably suitable for this. It >> now: >> - Strips by default. -S and --strip are still there for >> compatibility, but they are a no-op (does anyone care if I remove >> this compatibility?) > > I get the following error during py2app invocation: > > /usr/bin/strip: object: > /Users/richard/src/cg/CGPublisher-Zope/dist/CGPublisher-Zope.app/ > Contents/Frameworks/Python.framework/Versions/2.3/Python truncated or > malformed object (LC_SEGMENT command 2 fileoff field plus filesize > field extends past the end of the file) > > and then this when I try to run the app: > > 2005-02-10 11:54:41.210 CGPublisher-Zope[5269] dyld: > ./dist/CGPublisher-Zope.app/Contents/MacOS/CGPublisher-Zope truncated > or malformed library: > /Users/richard/src/cg/CGPublisher-Zope/dist/CGPublisher-Zope.app/ > Contents/Frameworks/Python.framework/Versions/2.3/Python (load command > 2 fileoff plus filesize extends past end of the library) > > The file in question is: > > -rwxr-xr-x 1 richard richard 1239416 10 Feb 11:54 Python > > if that's any help (probably not). Also, the output at the end of > stripping says "stripping saved 0 bytes (7077472 / 7077472)". Full log > of output (stdout) from py2app invocation is attached. Sounds like something bad happened trying to rewrite the Mach-O headers of the dylib, I haven't seen this sort of issue in a long time. Send me /Library/Frameworks/Python/2.3/Python and /Users/richard/src/cg/CGPublisher-Zope/dist/CGPublisher-Zope.app/ Contents/Frameworks/Python.framework/Versions/2.3/Python and I'll take a look to see what the difference is. -bob From richard at commonground.com.au Thu Feb 10 02:55:58 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Feb 10 02:56:04 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> <5d640cd8da2f11645004d8adda3136a1@redivi.com> <260f344d3a2fd80f6529184f2a636e2e@commonground.com.au> <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> Message-ID: <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> On 10/02/2005, at 12:38 PM, Bob Ippolito wrote: > I tried to reproduce this problem by dropping your Python dylib into > my framework, and it worked fine.. what version of Mac OS X are you > using and have you tried it a second time after killing build and > dist? That was it - I needed to clean out the old cruft (I had deleted dist, but not build). All better now. Well, almost. Now I have an ominuous "socket.error: AF_UNIX path too long" to deal with :) The man page for bind() says that I'll get this if the name is longer than NAME_MAX. Grep'ing /usr/include (the only place I know to look ;) gets me a value of 255 for NAME_MAX in (there's some others, but I think that's the appropriate one. The path is "/Users/richard/src/cg/CGPublisher-Zope/dist/CGPublisher-Zope.app/ Contents/Resources/runtime/zope-8000/zopectlsock.5345" which is clearly 118 chars long. So I'm a little confused. I need to go get some lunch, then I'll have another go at the problem :) Richard From bob at redivi.com Thu Feb 10 03:04:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 03:04:41 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> <5d640cd8da2f11645004d8adda3136a1@redivi.com> <260f344d3a2fd80f6529184f2a636e2e@commonground.com.au> <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> Message-ID: <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> On Feb 9, 2005, at 20:55, Richard Jones wrote: > On 10/02/2005, at 12:38 PM, Bob Ippolito wrote: >> I tried to reproduce this problem by dropping your Python dylib into >> my framework, and it worked fine.. what version of Mac OS X are you >> using and have you tried it a second time after killing build and >> dist? > > That was it - I needed to clean out the old cruft (I had deleted dist, > but not build). All better now. > > Well, almost. Now I have an ominuous "socket.error: AF_UNIX path too > long" to deal with :) > > The man page for bind() says that I'll get this if the name is longer > than NAME_MAX. Grep'ing /usr/include (the only place I know to look ;) > gets me a value of 255 for NAME_MAX in (there's some > others, but I think that's the appropriate one. > > The path is > "/Users/richard/src/cg/CGPublisher-Zope/dist/CGPublisher-Zope.app/ > Contents/Resources/runtime/zope-8000/zopectlsock.5345" which is > clearly 118 chars long. So I'm a little confused. I need to go get > some lunch, then I'll have another go at the problem :) You should never, ever, ever, ever, ever write inside of a bundle anyway. You should make this runtime directory in /tmp, /Library/Application Support/, etc. In fact, I was thinking that I should chmod -R g-w the contents of the app bundle a couple hours ago :) See "Where To Put Application Files" in http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFileSystem/index.html See From janssen at parc.com Thu Feb 10 03:36:45 2005 From: janssen at parc.com (Bill Janssen) Date: Thu Feb 10 03:36:57 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: Your message of "Wed, 09 Feb 2005 15:28:08 PST." <420A9C88.3080901@noaa.gov> Message-ID: <05Feb9.183646pst."58617"@synergy1.parc.xerox.com> > You're certainly correct that none of them had the Mac as a target at > the beginning. If only Apple would port Cocoa to Unix... Isn't that what they've done? Sure seems like it to me. Bill From bob at redivi.com Thu Feb 10 03:40:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 03:40:18 2005 Subject: [Pythonmac-SIG] Mac User Python newbies In-Reply-To: <05Feb9.183646pst."58617"@synergy1.parc.xerox.com> References: <05Feb9.183646pst."58617"@synergy1.parc.xerox.com> Message-ID: <7dbe48d55ad5c7746e99b61f0eea88fe@redivi.com> On Feb 9, 2005, at 9:36 PM, Bill Janssen wrote: >> You're certainly correct that none of them had the Mac as a target at >> the beginning. If only Apple would port Cocoa to Unix... > > Isn't that what they've done? Sure seems like it to me. Speaking in those terms, hasn't it *always* run on Unix? :) -bob From eichin at metacarta.com Thu Feb 10 03:56:53 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: Thu Feb 10 03:56:57 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual In-Reply-To: <2macqd5zjc.fsf@starship.python.net> References: <31ac537c05020907152044c458@mail.gmail.com> <2macqd5zjc.fsf@starship.python.net> Message-ID: <7g4qgli0lm.fsf@pikespeak.metacarta.com> > what is currently Essential Reading on Python, I mean in print rather > Of course, "it depends". Dive into Python looks pretty good. Python I've been beating on people with, err, recommending Dive Into Python, for two reasons - you can read it online to see if it suits you, *and* it's *very* different in style from most language teaching books, none of that 'useless hello world nonsense', it really does start out with hairy code - because you can *read* it and learn interesting points in a context which makes it clear that they're not just pedantic points, but that they apply to real problems. (I've found it useful for porting perl programmers, too :-) I also suggest (especially if you like working from Real Paper Books) the Python Standard Libraries book - not to read through, but to pick up, thumb through and random, and say "oh, that's a cool thing"... getting familiar with "batteries" that are in reach, along a different path from the usual (google :-) path... From richard at commonground.com.au Thu Feb 10 04:00:13 2005 From: richard at commonground.com.au (Richard Jones) Date: Thu Feb 10 04:00:21 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> <5d640cd8da2f11645004d8adda3136a1@redivi.com> <260f344d3a2fd80f6529184f2a636e2e@commonground.com.au> <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> Message-ID: <75c87692e5c0b58d67fc2463d13cd7a1@commonground.com.au> On 10/02/2005, at 1:04 PM, Bob Ippolito wrote: > You should never, ever, ever, ever, ever write inside of a bundle > anyway. You should make this runtime directory in /tmp, > /Library/Application Support/, etc. Oh, OK :) I readily admit that I was being slack (actually, mostly I'm in a hurry) in using the bundle. I really need to implement a proper Zope instance find / create dialog rather than having it hard-coded ;) In terms of exactly where the Zope databases go (there could be more than one), I think they they should go in /Library/CGPublisher-Zope/. Richard From brendansimons at yahoo.ca Thu Feb 10 04:00:08 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu Feb 10 04:00:23 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <20050209040616.65CF71E400C@bag.python.org> References: <20050209040616.65CF71E400C@bag.python.org> Message-ID: <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> The IDE thread is a recurring one. Here's my experience as another Python newbie. I tried SPE, PythonCard, PyOxice, PyPE, eclipse and wing (under x11). All work, but I found that each one had enough quirks (mostly UI inconsistencies, but some are downright unstable) that I was less productive than without. Not to sell any short, I'm sure they will get better given time. FWIW, the winning formula for me right now is: 1) Editor: TextWrangler (http://www.barebones.com/index.shtml). -Free, "Made For Mac", Code Colouring, Method Indexing, The ability to run scripts from the editor, More text manipulation options than I can count. 2) GuiEditor: XRCed.py (comes with the wxPython install package). (Or code the wxPython by hand, which takes longer, but gives you a little more control over the result). 3) And an instance of terminal running python interactive mode. Actually, this is the most valuable Python tool I've found so far - it's like a scratch pad where I can quickly check assumptions, or test out ideas. The only thing I'm missing now is a debugger with breakpoints, call stack, and variable watches. I'll have to settle for random print statements for now. -Brendan On 8-Feb-05, at 11:06 PM, pythonmac-sig-request@python.org wrote: > > If you try SPE, I'd be very interested to hear your results. It's > beautiful, and very extensive. But I have not been able to make it > work. (The same has been true for me with wxGlade. It may be my fault, > or the fault of my system.) From bob at redivi.com Thu Feb 10 04:00:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 04:00:51 2005 Subject: [Pythonmac-SIG] Apple installed vs. Manual In-Reply-To: <7g4qgli0lm.fsf@pikespeak.metacarta.com> References: <31ac537c05020907152044c458@mail.gmail.com> <2macqd5zjc.fsf@starship.python.net> <7g4qgli0lm.fsf@pikespeak.metacarta.com> Message-ID: <68bef8cb74dde96f924b555ef06385da@redivi.com> On Feb 9, 2005, at 9:56 PM, eichin@metacarta.com wrote: >> what is currently Essential Reading on Python, I mean in print rather > >> Of course, "it depends". Dive into Python looks pretty good. Python > > I've been beating on people with, err, recommending Dive Into Python, > for two reasons - you can read it online to see if it suits you, *and* > it's *very* different in style from most language teaching books, none > of that 'useless hello world nonsense', it really does start out with > hairy code - because you can *read* it and learn interesting points > in a context which makes it clear that they're not just pedantic > points, but that they apply to real problems. (I've found it useful > for porting perl programmers, too :-) > > I also suggest (especially if you like working from Real Paper Books) > the Python Standard Libraries book - not to read through, but to pick > up, thumb through and random, and say "oh, that's a cool > thing"... getting familiar with "batteries" that are in reach, along > a different path from the usual (google :-) path... I find myself typing "foo site:docs.python.org" into the Safari search bar when I want to find something in the stdlib or C API, but usually I already know more or less what I'm looking for. I do the same thing looking up Cocoa docs at developer.apple.com. -bob From rogerb at rogerbinns.com Thu Feb 10 04:01:22 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 04:01:18 2005 Subject: [Pythonmac-SIG] Mac User Python newbies References: <31ac537c05020814467a2dd808@mail.gmail.com><20D8EED4-7A25-11D9-AB52-000A95C93D30@redivi.com><31ac537c050208164047d9f1f8@mail.gmail.com> <017401c50e55$3f3b3120$3501a8c0@rogersqyvr14d3> <22258ca60eaed45585a961b01d226f08@redivi.com><01e001c50e65$43064fa0$3501a8c0@rogersqyvr14d3> <420A9C88.3080901@noaa.gov> Message-ID: <004301c50f1c$cd162a50$3501a8c0@rogersqyvr14d3> > Actually, I know wxWidgets was designed, from the beginning, to be cross > platform, specifically targeting Windows and Unix (X, originally Motif). > I think that's where the "w" and "x" comes from. Yes, it was intended to be cross platform from the begining. But it was started on Windows and a lot of the api and mechanisms are directly drawn from MFC. Roger From rogerb at rogerbinns.com Thu Feb 10 04:13:36 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 04:13:31 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits References: <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> <6f01331c915983ed6d5adfb8fd4ccb24@tulane.edu> Message-ID: <006e01c50f1e$82a1bb40$3501a8c0@rogersqyvr14d3> > I don't see much merit at all in > these simple "this toolkit is inferior because it's not made on Mac" > type of discussions that keep popping up. You are missing the point. The various cross platform Python gui toolkits are all due to history, developer attention, market share etc inferior when compared to their support on other platforms. The OP was talking about starting a new gui app. He can just ignore all the other platforms, use the native Mac apis and have a good looking app. Or he can pick one of those toolkits and may encounter some shortcomings. Helping to address those shortcomings will improve the toolkit. Using the toolkit will reduce the costs for making the app available to other (and in the case of Windows significantly larger) markets. But it also reduces the costs for people on those other platforms to move their applications to the Mac. That continues to improve the software ecosystem on Mac, improves things for users, and ultimately increases absolute numbers of users and market share. The latter two then give you a bigger market for your original app and any followups. Python is an excellent language for keeping porting costs down. Out of the various Python gui toolkits, I personally think wxPython does the best job and merits attention. And yes I am putting my money and time where my mouth is. Roger From charles.hartman at conncoll.edu Thu Feb 10 04:13:49 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Feb 10 04:13:55 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> <5d640cd8da2f11645004d8adda3136a1@redivi.com> <260f344d3a2fd80f6529184f2a636e2e@commonground.com.au> <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> Message-ID: <1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> I've got this gospel, but I wonder how it relates to your message, a little while back, saying -- if I understood you right! -- that there's nowhere in a Windows application to put a data file that's comparable to putting it inside the bundle (as Apple wants). Am I terminally confused, or only somewhat? Charles Hartman On Feb 9, 2005, at 9:04 PM, Bob Ippolito wrote: > > You should never, ever, ever, ever, ever write inside of a bundle > anyway. You should make this runtime directory in /tmp, > /Library/Application Support/, etc. > > In fact, I was thinking that I should chmod -R g-w the contents of the > app bundle a couple hours ago :) > > See "Where To Put Application Files" in > http://developer.apple.com/documentation/MacOSX/Conceptual/ > BPFileSystem/index.html From charles.hartman at conncoll.edu Thu Feb 10 04:19:11 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Feb 10 04:19:16 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> Message-ID: On Feb 9, 2005, at 10:00 PM, Brendan Simons wrote: > > The only thing I'm missing now is a debugger with breakpoints, call > stack, and variable watches. I'll have to settle for random print > statements for now. Right -- which is exactly to say, for somebody like me -- and there seem to be quite a few of us -- who is not essentially a systems programmer and comes to all this from (old) Macs rather than from Unix & its little Terminal children, that there is still no very good & comfortable way to program in Python. I can learn, we can all learn. But it's a real problem, I have to keep saying. Charles Hartman From bob at redivi.com Thu Feb 10 04:29:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 04:30:01 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> <5d640cd8da2f11645004d8adda3136a1@redivi.com> <260f344d3a2fd80f6529184f2a636e2e@commonground.com.au> <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> <1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> Message-ID: On Feb 9, 2005, at 10:13 PM, Charles Hartman wrote: > On Feb 9, 2005, at 9:04 PM, Bob Ippolito wrote: >> >> You should never, ever, ever, ever, ever write inside of a bundle >> anyway. You should make this runtime directory in /tmp, >> /Library/Application Support/, etc. >> >> In fact, I was thinking that I should chmod -R g-w the contents of >> the app bundle a couple hours ago :) >> >> See "Where To Put Application Files" in >> http://developer.apple.com/documentation/MacOSX/Conceptual/ >> BPFileSystem/index.html > > I've got this gospel, but I wonder how it relates to your message, a > little while back, saying -- if I understood you right! -- that > there's nowhere in a Windows application to put a data file that's > comparable to putting it inside the bundle (as Apple wants). Am I > terminally confused, or only somewhat? On Windows, you either put the data files in some arbitrary fixed place (may be relative to the executable), or you compile them into the executable as resources (bleh). On Mac OS X, there are standards and the standards say that all data files required for the application to operate should be read-only and should be placed in the Resources tree of the application bundle. -bob From charles.hartman at conncoll.edu Thu Feb 10 04:34:39 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Feb 10 04:34:45 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> <5d640cd8da2f11645004d8adda3136a1@redivi.com> <260f344d3a2fd80f6529184f2a636e2e@commonground.com.au> <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> <1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> Message-ID: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> On Feb 9, 2005, at 10:29 PM, Bob Ippolito wrote: > On Windows, you either put the data files in some arbitrary fixed > place (may be relative to the executable), or you compile them into > the executable as resources (bleh). > I'm not sure whether to ask if you could explain "compile them into the executable" (I don't know how to do that; I have to give my app to Windows people, but actually (*knowing* anything about Windows . . .) or if you could explain "(bleh)" -- but maybe the one question answers the other. Oh well . . . Charles Hartman From bob at redivi.com Thu Feb 10 04:36:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 04:36:42 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au> <4f714fa546884d099d65acbd1eee2573@commonground.com.au> <5cc801f2647e9f10d3bacc18892118d9@redivi.com> <200502041158.32890.richard@commonground.com.au> <7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com> <5d640cd8da2f11645004d8adda3136a1@redivi.com> <260f344d3a2fd80f6529184f2a636e2e@commonground.com.au> <72d9c8e3c63f57701fb25da94ec2de38@redivi.com> <02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au> <3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com> <1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> Message-ID: <1dc841b8a8e0acb73a2e480fc70437ba@redivi.com> On Feb 9, 2005, at 22:34, Charles Hartman wrote: > > On Feb 9, 2005, at 10:29 PM, Bob Ippolito wrote: > >> On Windows, you either put the data files in some arbitrary fixed >> place (may be relative to the executable), or you compile them into >> the executable as resources (bleh). >> > > I'm not sure whether to ask if you could explain "compile them into > the executable" (I don't know how to do that; I have to give my app to > Windows people, but actually (*knowing* anything about Windows . . .) > or if you could explain "(bleh)" -- but maybe the one question answers > the other. Oh well . . . Not relevant to Python development. -bob From brendansimons at yahoo.ca Thu Feb 10 04:35:29 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu Feb 10 04:39:07 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <20050209235311.23CB91E4009@bag.python.org> References: <20050209235311.23CB91E4009@bag.python.org> Message-ID: <150e35de54f00143489775ff205f1667@yahoo.ca> Neat, thanks Jim! On 9-Feb-05, at 6:53 PM, pythonmac-sig-request@python.org wrote: > Perhaps in the vein of historical trivia, there have been previous ties > between REALbasic and python. Some years back there was an abortive > attempt > to create a REALbasic-like development environment for python, written > in > REALbasic. Though not related to that effort, Joe Strout is one of the > senior engineers at REALbasic and he had a background in python before > going > to RB. Perhaps coincidentally, pythonic concepts like variants > (dynamically-typed variables) and "for each x in y" started showing up > in RB > after his arrival. From rogerb at rogerbinns.com Thu Feb 10 05:47:44 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 05:47:42 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> Message-ID: <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> > I'm not sure whether to ask if you could explain "compile them into the > executable" (I don't know how to do that; I have to give my app to > Windows people, but actually (*knowing* anything about Windows . . .) > or if you could explain "(bleh)" -- but maybe the one question answers > the other. Oh well . . . On Windows it is possible to make a single file executable and include all resources within that executable. However most people expect there to be a single setup executable, and that setup will add the program to the list of Add/Remove programs in the Control Panel. And if you are going to use to a single setup, there is no benefit to trying to make a single file - it doesn't matter how many files there are. There are also some resources you won't be able to make part of the single file such as help content as it needs them to be in seperate files. You can make a single app appear be in the native installer format for each platform. We did it for BitPim. Go ahead, download and try it. You don't actually need a cell phone for the program to run. This is the Python code used to do the installer work: http://cvs.sf.net/viewcvs.py/bitpim/bitpim/makedist.py?view=markup Slides 18 through 22 of this talk explain how it is done. Note however that we now use py2app on Mac. http://bitpim.org/papers/baypiggies/ Roger From troy.rollins at gmail.com Thu Feb 10 06:16:59 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Thu Feb 10 06:17:01 2005 Subject: [Pythonmac-SIG] Re: Mac Guikits In-Reply-To: <006e01c50f1e$82a1bb40$3501a8c0@rogersqyvr14d3> References: <20050209150954.86719.qmail@web30202.mail.mud.yahoo.com> <6f01331c915983ed6d5adfb8fd4ccb24@tulane.edu> <006e01c50f1e$82a1bb40$3501a8c0@rogersqyvr14d3> Message-ID: <31ac537c0502092116773e9ecd@mail.gmail.com> > > Python is an excellent language for keeping porting costs > down. Out of the various Python gui toolkits, I personally > think wxPython does the best job and merits attention. > On the topic of wxPython, I had an extremely rewarding session tonight with PythonCard. So far, for all the graphical layout tools for GUI, it would seem to be the most mature and stable of any of them... on OSX at least. Its handling of wx widgets seems the most intuitive currently, and because it just creates a resource file it's results should be nicely usable with any of the code editors, and allow even those of us who are new to Python to manage the layout of a basic x-plat GUI. Still would like to compare it to boa constructor, but it certainly beats the others I've tried (wxGlade, XRCed) in terms of usability and interface design. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From bob at redivi.com Thu Feb 10 06:18:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 06:18:13 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> Message-ID: <0e39cb3ea8cdd226362563c9104642a2@redivi.com> On Feb 9, 2005, at 23:47, Roger Binns wrote: >> I'm not sure whether to ask if you could explain "compile them into >> the executable" (I don't know how to do that; I have to give my app >> to Windows people, but actually (*knowing* anything about Windows . . >> .) or if you could explain "(bleh)" -- but maybe the one question >> answers the other. Oh well . . . > > On Windows it is possible to make a single file executable and include > all resources within that executable. However most people expect there > to be a single setup executable, and that setup will add the program > to the list of Add/Remove programs in the Control Panel. > > And if you are going to use to a single setup, there is no benefit to > trying to make a single file - it doesn't matter how many files there > are. > > There are also some resources you won't be able to make part of the > single file such as help content as it needs them to be in seperate > files. > > You can make a single app appear be in the native installer format > for each platform. We did it for BitPim. Go ahead, download and > try it. You don't actually need a cell phone for the program to > run. > > This is the Python code used to do the installer work: > > http://cvs.sf.net/viewcvs.py/bitpim/bitpim/makedist.py?view=markup > > Slides 18 through 22 of this talk explain how it is done. Note > however that we now use py2app on Mac. > > http://bitpim.org/papers/baypiggies/ I'd like to see that pie slice for the Mac OS X build to shrink even further.. I took at a look at your setup.py, and it looks a fair amount of it doesn't need to be specified: - no need to import string - no need to make a "dist" dir (py2app will do it) - specifying CFBundleIconFile is redundant if you use iconfile= - specifying CFBundleExecutable is redundant - compressed is redundant, it's always on - this can be rewritten: app = [ dict( script="bp.py", ),] as just: app = ['bp.py'] There's currently no reason to specify an application as a dictionary, it just gives you another place to specify a plist and having multiple applications or plugins built from one setup(...) isn't supported yet as there is too much global state (inherited that problem from looking too hard at py2exe). - this might be useful to you to determine the OS version (rather than using the uname): from distutils.version import LooseVersion from bdist_mpkg.tools import sw_vers if LooseVersion(sw_vers()) < LooseVersion('10.3'): # jaguar ... else: # not jaguar ... Things that I need to address: If you specify version= to setup() then you shouldn't need CFBundleShortVersionString or CFBundleGetInfoString The DMG building stuff should be abstracted as an option for bdist_mpkg and py2app (PyObjC currently has its own bdist_dmg command, but it doesn't support that for 10.2 yet) Other than removing whitespace, I think that's about all I can do to make your setup shorter :) -bob From bob at redivi.com Thu Feb 10 06:41:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 06:41:40 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> Message-ID: <0f07d77d65f8bed935c48ff96438d976@redivi.com> On Feb 9, 2005, at 23:47, Roger Binns wrote: > You can make a single app appear be in the native installer format > for each platform. We did it for BitPim. Go ahead, download and > try it. You don't actually need a cell phone for the program to > run. > > This is the Python code used to do the installer work: > > http://cvs.sf.net/viewcvs.py/bitpim/bitpim/makedist.py?view=markup > > Slides 18 through 22 of this talk explain how it is done. Note > however that we now use py2app on Mac. > > http://bitpim.org/papers/baypiggies/ In your presentation you say that serial devices on the Mac are in /dev with "no other information". That is totally not true, unless you say "no other information available from POSIX" ;) You can get at any metadata you want to know about any hardware device in the system (and plug/unplug notifications) from IOKit. The code to do the serial port enumeration is rather trivial (as trivial as refcounted C goes, anyway): http://developer.apple.com/samplecode/SerialPortSample/ SerialPortSample.html I don't think anyone has wrapped IOKit, but it wouldn't be that hard to wrap the useful parts. Maybe I'll look into it, since I do use IOKit for FireWire and USB notifications in one of my apps. My current implementation does this with an Objective-C class compiled as a Python extension, so from PyObjC I can just objc.lookUpClass and talk to it without writing any additional ugly wrapper code. -bob From bob at redivi.com Thu Feb 10 07:27:10 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 07:27:14 2005 Subject: [Pythonmac-SIG] Numeric 23.7 w/ vecLib (Apple's optimized implementation of BLAS) Message-ID: <7bc3e10b96effd3f0bd7455b0912f42b@redivi.com> Here's a Numeric 23.7 for Mac OS X 10.3 (using the stock Python 2.3 interpreter), built with py2app 0.1.8 (svn trunk)'s bdist_mpkg command: http://undefined.org/python/Numeric-23.7-py2.3-macosx10.3.zip Numeric 23.7's setup.py *almost* gets vecLib right. Trivial patch is here: https://sourceforge.net/tracker/? func=detail&atid=301369&aid=996268&group_id=1369 -bob From rogerb at rogerbinns.com Thu Feb 10 07:36:00 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 07:35:56 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> Message-ID: <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> > In your presentation BTW I only got a Mac (mini) a few weeks ago, so all my information was based on what other people contributed. > you say that serial devices on the Mac are in /dev > with "no other information". That is totally not true, unless you say > "no other information available from POSIX" ;) You can get at any > metadata you want to know about any hardware device in the system (and > plug/unplug notifications) from IOKit. The specific information I need is USB vendor and product ids and interface number on the USB device that correspond to a particular /dev entry. (These are all cell phones exposed by direct USB connections or USB to serial convertors). The actual devices will show up as serial ports or as modems depending on the interface protocol class. Depending on the phone model, the access may be via serial/modem port access or via libusb. I can see what is present via libusb, and I can see what /dev nodes let me open them, but I don't see a way of mapping in either direction. > I don't think anyone has wrapped IOKit, but it wouldn't be that hard to > wrap the useful parts. Maybe I'll look into it, since I do use IOKit > for FireWire and USB notifications in one of my apps. My current > implementation does this with an Objective-C class compiled as a Python > extension, so from PyObjC I can just objc.lookUpClass and talk to it > without writing any additional ugly wrapper code. I'd be happy to use whatever you can provide :-) Roger From bob at redivi.com Thu Feb 10 08:00:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 08:00:18 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 10, 2005, at 1:36 AM, Roger Binns wrote: >> In your presentation > > BTW I only got a Mac (mini) a few weeks ago, so all my information > was based on what other people contributed. Obviously not people familiar with http://developer.apple.com/ :) >> you say that serial devices on the Mac are in /dev with "no other >> information". That is totally not true, unless you say "no other >> information available from POSIX" ;) You can get at any metadata >> you want to know about any hardware device in the system (and >> plug/unplug notifications) from IOKit. > > The specific information I need is USB vendor and product ids and > interface > number on the USB device that correspond to a particular /dev entry. > (These are all cell phones exposed by direct USB connections or USB to > serial convertors). The actual devices will show up as serial ports > or as modems depending on the interface protocol class. Depending on > the phone model, the access may be via serial/modem port access or via > libusb. > > I can see what is present via libusb, and I can see what /dev nodes > let me open them, but I don't see a way of mapping in either direction. That's what IOKit does. It's a registry of everything you could ever possibly want to know w.r.t. hardware. Open up /Developer/Utilities/IORegistryExplorer and poke around (there are other tools like USB Prober and some stuff in /Developer/Examples/IOKit). >> I don't think anyone has wrapped IOKit, but it wouldn't be that hard >> to wrap the useful parts. Maybe I'll look into it, since I do use >> IOKit for FireWire and USB notifications in one of my apps. My >> current implementation does this with an Objective-C class compiled >> as a Python extension, so from PyObjC I can just objc.lookUpClass >> and talk to it without writing any additional ugly wrapper code. > > I'd be happy to use whatever you can provide :-) Well, if you take a look at the example, it's really straight-forward and you can come up with something specific to your app in just an hour or two. It will be quite some time before I get around to making a useful IOKit wrapper. Unfortunately (or maybe fortunately) neither of my phones are compatible with BitPim. I'd really like to see BlackBerry 7100 support, but it doesn't even show up as a serial device over USB and I don't really know where to start with reverse engineering it to give a useful bluetooth profile or to make it do something with USB. PocketMac sells a product that I can use to sync contacts/calendar stuff, but it doesn't do anything with bluebooth and it doesn't allow me to use it as a GPRS modem. -bob From rogerb at rogerbinns.com Thu Feb 10 08:25:05 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 08:25:00 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> Message-ID: <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> > I'd like to see that pie slice for the Mac OS X build to shrink even > further.. You aren't satisfied with being the smallest amount of code already ?-) > I took at a look at your setup.py, and it looks a fair amount > of it doesn't need to be specified: More accurately you are looking at code that has evolved over two years and for the Mac bits used to support BundleBuilder and has to build the 10.2 and 10.3 packages differently. > Other than removing whitespace, I think that's about all I can do to > make your setup shorter :) I'm not particularly concerned with how long it is. The point of the original slides was how little work it is to take a full featured Python graphical application and distribute it as a native app without the user knowing or caring that it is in Python or having to install any pre-requisites. Incidentally a number of people over time have taken copies of that script for their own projects. The biggest problem on Mac at the moment is having to distribute two versions (one for 10.2 and one for 10.3). Second to that is the sheer size of the download. Platform DownloadSize InstalledSize Windows 7.4MB 27MB Linux 10.5MB 30MB Panther 14.9MB 40MB The good news is I found the cause and fix. A whole bunch of the wxPython/wxWidgets libraries don't respond to strip or have been stripped. However running "strip -x" does remove a whole bunch more gunk that plain "strip" doesn't. (IIRC cx-Freeze runs strip on executable files/libraries automatically.) Adding another Mac specific line (:-) to makedist.py to automatically run the strip reduces the download to 10.4MB and the installed size to 20.6MB. Note also that both Windows and Linux don't compress the contents of the zip file containing all the .pyo files. py2app also looks like it does a way better job of excluding unneeded .pyo files. Incidentally I did find a gross hack to work around the py2app bug of not handling the optimise option. Stripping out the doc strings saves over 3MB of compressed size, and aren't useful in the binary end user distribution anyway. Roger From bob at redivi.com Thu Feb 10 08:38:33 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 08:38:42 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> Message-ID: <74c876d58307809a377143241bdf88a0@redivi.com> On Feb 10, 2005, at 2:25 AM, Roger Binns wrote: >> I'd like to see that pie slice for the Mac OS X build to shrink even >> further.. > > You aren't satisfied with being the smallest amount of code already ?-) I don't really care what the other platforms look like, but I want py2app setup files to be as compact as possible so that the barrier to entry is very low, and so that it's easy enough to shrug off distutils when that makes sense (i.e. py2applet). >> I took at a look at your setup.py, and it looks a fair amount of it >> doesn't need to be specified: > > More accurately you are looking at code that has evolved over two years > and for the Mac bits used to support BundleBuilder and has to build > the 10.2 and 10.3 packages differently. > >> Other than removing whitespace, I think that's about all I can do to >> make your setup shorter :) > > I'm not particularly concerned with how long it is. The point of > the original slides was how little work it is to take a full featured > Python graphical application and distribute it as a native app without > the user knowing or caring that it is in Python or having to install > any pre-requisites. Which is rather impressive, considering how stupid the tools are -- but it doesn't really need to take much code at all. For applications organized in a sane manner, py2app can do it with just a drag+drop of your main script and any data files you use. I'll probably add code to be able to pull a __version__ out of your main script, since I have that written for something else anyway. > Incidentally a number of people over time have taken copies of that > script for their own projects. > > The biggest problem on Mac at the moment is having to distribute > two versions (one for 10.2 and one for 10.3). Second to that is > the sheer size of the download. So don't bother building a 10.3 version. The 10.2 version should work fine. > Platform DownloadSize InstalledSize > > Windows 7.4MB 27MB > Linux 10.5MB 30MB > Panther 14.9MB 40MB > > The good news is I found the cause and fix. A whole bunch of the > wxPython/wxWidgets libraries don't respond to strip or have been > stripped. However running "strip -x" does remove a whole bunch > more gunk that plain "strip" doesn't. (IIRC cx-Freeze runs strip on > executable files/libraries automatically.) > > Adding another Mac specific line (:-) to makedist.py to automatically > run the strip reduces the download to 10.4MB and the installed size > to 20.6MB. Did you know py2app had a --strip option, which does strip -x -S? It's had this as long as I can remember, but it's gone now :) I think even bundlebuilder had it, but it may have had more naive strip options. 0.1.8 (svn trunk) has --strip as default, so --strip is a no-op and there's now a --no-strip to turn it off. > Note also that both Windows and Linux don't compress the contents > of the zip file containing all the .pyo files. py2app also looks > like it does a way better job of excluding unneeded .pyo files. I decided to compress always and by default because CPU is cheap and IO is not.. I couldn't find a compelling reason to use an uncompressed zip, just like I decided not to bother stripping. If you want to run your app under gdb, you should probably be using an alias bundle... > Incidentally I did find a gross hack to work around the py2app > bug of not handling the optimise option. Stripping out the doc > strings saves over 3MB of compressed size, and aren't useful > in the binary end user distribution anyway. It's close(r) to working in svn trunk, but I don't think it actually works just yet. -bob From bob at redivi.com Thu Feb 10 08:43:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 08:43:51 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <74c876d58307809a377143241bdf88a0@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> <74c876d58307809a377143241bdf88a0@redivi.com> Message-ID: On Feb 10, 2005, at 2:38 AM, Bob Ippolito wrote: > > On Feb 10, 2005, at 2:25 AM, Roger Binns wrote: > >>> I'd like to see that pie slice for the Mac OS X build to shrink even >>> further.. >> >> You aren't satisfied with being the smallest amount of code already >> ?-) > > I don't really care what the other platforms look like, but I want > py2app setup files to be as compact as possible so that the barrier to > entry is very low, and so that it's easy enough to shrug off distutils > when that makes sense (i.e. py2applet). > >>> I took at a look at your setup.py, and it looks a fair amount of it >>> doesn't need to be specified: >> >> More accurately you are looking at code that has evolved over two >> years >> and for the Mac bits used to support BundleBuilder and has to build >> the 10.2 and 10.3 packages differently. >> >>> Other than removing whitespace, I think that's about all I can do to >>> make your setup shorter :) >> >> I'm not particularly concerned with how long it is. The point of >> the original slides was how little work it is to take a full featured >> Python graphical application and distribute it as a native app without >> the user knowing or caring that it is in Python or having to install >> any pre-requisites. > > Which is rather impressive, considering how stupid the tools are -- > but it doesn't really need to take much code at all. For applications > organized in a sane manner, py2app can do it with just a drag+drop of > your main script and any data files you use. I'll probably add code > to be able to pull a __version__ out of your main script, since I have > that written for something else anyway. > >> Incidentally a number of people over time have taken copies of that >> script for their own projects. >> >> The biggest problem on Mac at the moment is having to distribute >> two versions (one for 10.2 and one for 10.3). Second to that is >> the sheer size of the download. > > So don't bother building a 10.3 version. The 10.2 version should work > fine. > >> Platform DownloadSize InstalledSize >> >> Windows 7.4MB 27MB >> Linux 10.5MB 30MB >> Panther 14.9MB 40MB >> >> The good news is I found the cause and fix. A whole bunch of the >> wxPython/wxWidgets libraries don't respond to strip or have been >> stripped. However running "strip -x" does remove a whole bunch >> more gunk that plain "strip" doesn't. (IIRC cx-Freeze runs strip on >> executable files/libraries automatically.) >> >> Adding another Mac specific line (:-) to makedist.py to automatically >> run the strip reduces the download to 10.4MB and the installed size >> to 20.6MB. > > Did you know py2app had a --strip option, which does strip -x -S? > It's had this as long as I can remember, but it's gone now :) I think > even bundlebuilder had it, but it may have had more naive strip > options. > > 0.1.8 (svn trunk) has --strip as default, so --strip is a no-op and > there's now a --no-strip to turn it off. > >> Note also that both Windows and Linux don't compress the contents >> of the zip file containing all the .pyo files. py2app also looks >> like it does a way better job of excluding unneeded .pyo files. > > I decided to compress always and by default because CPU is cheap and > IO is not.. I couldn't find a compelling reason to use an uncompressed > zip, just like I decided not to bother stripping. If you want to run > your app under gdb, you should probably be using an alias bundle... Er, just like I decided to strip by default... It's late. -bob From rogerb at rogerbinns.com Thu Feb 10 08:51:44 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 08:51:39 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> Message-ID: <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> > Obviously not people familiar with http://developer.apple.com/ :) Actually Steven Palm who did most of the original got some changes I still don't understand into libusb to make it work correctly on Mac. There is deep voodoo involved since some of the phones are actually composite devices and MacOS only binds drivers to some of the interfaces while BitPim needed to access the other interfaces. > Well, if you take a look at the example, it's really straight-forward > and you can come up with something specific to your app in just an hour > or two. I have looked through the API and I have looked in the Explorer. I can find serial/modem ports and I can find USB devices. I still don't see where they are linked. For example the device with USB vendorid 0x1004, productid 0x6000, interface 1 is /dev/cu.usbmodem5B231. I don't see where to get the USB details starting with the /dev name or the /dev name starting with the USB details. I have no problem getting the details seperately. It is linking them that matters. > compatible with BitPim. I'd really like to see BlackBerry 7100 > support, but it doesn't even show up as a serial device over USB That is why BitPim uses libusb for some phones and just talks straight at them. In fact that is even easier than serial style access. > don't really know where to start with reverse engineering it Generally you need to record what some existing working program does and go from there. That or make wild guesses. Roger From rogerb at rogerbinns.com Thu Feb 10 09:00:54 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 09:00:49 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> <74c876d58307809a377143241bdf88a0@redivi.com> Message-ID: <003401c50f46$a5514020$3501a8c0@rogersqyvr14d3> >> So don't bother building a 10.3 version. The 10.2 version should work >> fine. That is what was tried first - we don't want the extra work! I don't know what the issue was, but there was some incompatibility. >> Did you know py2app had a --strip option, which does strip -x -S? Nope. The way this works is that the example is copied, names changed and tweaks done until it works. What isn't well documented doesn't get used. >> I couldn't find a compelling reason to use an uncompressed zip The only reason I could think of is if the Python internals memory map the file and use the objects as is. If they were compressed then they would have to be decompressed to other memory. But I doubt Python does memory map the file. BTW I hate that drag and dropping stuff. It is fine for experiments but not appropriate for repeatable reliable controlled builds. What is even more annoying is tools like Apple's Help indexer that can *only* be run using drag and drop. Not that it matters since I can't get Apple's help working anyway. Roger From bob at redivi.com Thu Feb 10 09:16:02 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 09:16:09 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <003401c50f46$a5514020$3501a8c0@rogersqyvr14d3> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> <74c876d58307809a377143241bdf88a0@redivi.com> <003401c50f46$a5514020$3501a8c0@rogersqyvr14d3> Message-ID: <441d6f45aa18de66df942dcead60420b@redivi.com> On Feb 10, 2005, at 3:00 AM, Roger Binns wrote: >>> So don't bother building a 10.3 version. The 10.2 version should >>> work fine. > > That is what was tried first - we don't want the extra work! I don't > know what the issue was, but there was some incompatibility. There shouldn't be. If there is, it's probably libusb's fault, nothing in Python or wxPython should have this problem. There are issues with using a 10.3 machine to produce 10.2 compatible software, but vice versa should work fine. >>> Did you know py2app had a --strip option, which does strip -x -S? > > Nope. The way this works is that the example is copied, names > changed and tweaks done until it works. What isn't well documented > doesn't get used. Every option py2app takes is documented: python setup.py py2app --help >>> I couldn't find a compelling reason to use an uncompressed zip > > The only reason I could think of is if the Python internals memory > map the file and use the objects as is. If they were compressed > then they would have to be decompressed to other memory. > > But I doubt Python does memory map the file. Without even looking, I can pretty much say for sure that it does not :) Python strings can't be mmap backed, anyway. > BTW I hate that drag and dropping stuff. It is fine for experiments > but not appropriate for repeatable reliable controlled builds. What > is even more annoying is tools like Apple's Help indexer that can > *only* be run using drag and drop. Not that it matters since I can't > get Apple's help working anyway. open -a "Application" document Anyway, I was using drag + drop as an example (I don't use it much for this sort of thing). Given references to a few files, py2app can fill in almost all of the blanks. If there are no data dependencies, py2app should be able to fill in all the blanks (except for version). It will use the name of the main script as the name of the application, and it will look for an icon with the same name and .icns extension. You're probably not setting the right plist keys or something for Apple's help. -bob From bob at redivi.com Thu Feb 10 09:22:34 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 09:22:41 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 10, 2005, at 2:51 AM, Roger Binns wrote: >> Obviously not people familiar with http://developer.apple.com/ :) > > Actually Steven Palm who did most of the original got some changes > I still don't understand into libusb to make it work correctly on > Mac. There is deep voodoo involved since some of the phones are > actually composite devices and MacOS only binds drivers to some > of the interfaces while BitPim needed to access the other interfaces. Probably because it doesn't have drivers for them. If there's no matching driver, it won't pull up a useful nub to stick on it. >> Well, if you take a look at the example, it's really straight-forward >> and you can come up with something specific to your app in just an >> hour or two. > > I have looked through the API and I have looked in the Explorer. I > can find serial/modem ports and I can find USB devices. I still > don't see where they are linked. > > For example the device with USB vendorid 0x1004, productid 0x6000, > interface 1 is /dev/cu.usbmodem5B231. I don't see where to get > the USB details starting with the /dev name or the /dev name starting > with the USB details. > > I have no problem getting the details seperately. It is linking > them that matters. Given a USB device, you look for an IOSerialBSDClient down the tree. Given a BSD device, you look for a USB device up the tree. The information is not in the same place because the data is in a tree. The IOSerialBSDClient nub has no business knowing about USB crap. It's all very elegant. A good way to look at this tree is the Mr. Registry app that is one of the targets in /Developer/IOKit/firewire/FWOffice -- despite its name, it lets you look at the whole tree, not just IOFireWire. >> compatible with BitPim. I'd really like to see BlackBerry 7100 >> support, but it doesn't even show up as a serial device over USB > > That is why BitPim uses libusb for some phones and just talks > straight at them. In fact that is even easier than serial style > access. > >> don't really know where to start with reverse engineering it > > Generally you need to record what some existing working program > does and go from there. That or make wild guesses. I'd have to do a lot of reading up on that to see how to get dumps of USB traffic. I could run the BlackBerry Desktop via VirtualPC (or on a real PC) to figure out how the modem stuff works, the rest I could probably get by reverse engineering PocketMac. -bob From rogerb at rogerbinns.com Thu Feb 10 09:26:19 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 09:26:15 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> <74c876d58307809a377143241bdf88a0@redivi.com> <003401c50f46$a5514020$3501a8c0@rogersqyvr14d3> <441d6f45aa18de66df942dcead60420b@redivi.com> Message-ID: <006301c50f4a$32582080$3501a8c0@rogersqyvr14d3> > Every option py2app takes is documented: > > python setup.py py2app --help I started at http://pythonmac.org/wiki/py2app It would probably be helpful to add the above output to that page. > You're probably not setting the right plist keys or something for > Apple's help. The documentation doesn't make it clear what should be set. Additionally I have no idea how to make them from Python so I can automate all this. Roger From bob at redivi.com Thu Feb 10 09:40:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 09:41:01 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <006301c50f4a$32582080$3501a8c0@rogersqyvr14d3> References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> <74c876d58307809a377143241bdf88a0@redivi.com> <003401c50f46$a5514020$3501a8c0@rogersqyvr14d3> <441d6f45aa18de66df942dcead60420b@redivi.com> <006301c50f4a$32582080$3501a8c0@rogersqyvr14d3> Message-ID: <51fb44e4723aa768fbe3de1b911246a7@redivi.com> On Feb 10, 2005, at 3:26 AM, Roger Binns wrote: >> Every option py2app takes is documented: >> python setup.py py2app --help > > I started at http://pythonmac.org/wiki/py2app > > It would probably be helpful to add the above output to that page. Uh.. yeah, it would be useful to have some web documentation. I wish someone would sit down and write some. Anyone? :) I changed it slightly to reference the --help option.. but I'm kinda hesitant to put the whole output in there because mine looks different than 0.1.7 and it may change some more by the time 0.1.8 is released. >> You're probably not setting the right plist keys or something for >> Apple's help. > > The documentation doesn't make it clear what should be set. > Additionally I have no idea how to make them from Python so > I can automate all this. Python does it, see: python/dist/src/Mac/OSX/Doc -bob From rogerb at rogerbinns.com Thu Feb 10 09:57:00 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 10 09:56:55 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> Message-ID: <006c01c50f4e$7b738080$3501a8c0@rogersqyvr14d3> > Probably because it doesn't have drivers for them. If there's no > matching driver, it won't pull up a useful nub to stick on it. The right thing happens in the end. There is no need for drivers on some interfaces, and they must be used on others (eg ones that implement the USB modem protocol or the various USB to serial chips). > A good way to look at this tree is the Mr. Registry app that is one of > the targets in /Developer/IOKit/firewire/FWOffice -- despite its name, > it lets you look at the whole tree, not just IOFireWire. That makes it clearer. It is still not remotely like two hours work. (It may be for you however). I'm not going to implement all this but will point anyone else who does want at it. (The return on having to learn all this IOKit stuff, Objective C and how to map Objective C into Python is way too low.) > I'd have to do a lot of reading up on that to see how to get dumps of > USB traffic. There is a USB Prober under /Developer/Applications/Utilities (BTW I have found everything you mentioned under a different path than you said so I don't know if you were typing them from memory or have a different dev kit). > I could run the BlackBerry Desktop via VirtualPC (or on a > real PC) to figure out how the modem stuff works, the rest I could > probably get by reverse engineering PocketMac. Email me the device dump of the device from the USB Prober. You'll probably want to do that on the bitpim-devel list. Full Speed device @ 3 (0x5B230000): ..... Communication device: "Qualcomm CDMA Technologies MSM" Device Descriptor Descriptor Version Number: 0x0101 Device Class: 2 (Communication) Device Subclass: 0 Device Protocol: 0 Device MaxPacketSize: 16 Device VendorID/ProductID: 0x1004/0x6000 (LG Electronics Inc.) Device Version Number: 0x0000 Number of Configurations: 1 Manufacturer String: 1 "LG CDMA USB Modem\000\000\000\000\000" Product String: 2 "Qualcomm CDMA Technologies MSM" Serial Number String: 0 (none) Configuration Descriptor Total Length of Descriptor: 90 Number of Interfaces: 3 Configuration Value: 1 Attributes: 0xE0 (self-powered, remote wakeup) MaxPower: 100 ma Interface #0 - Communications-Control Alternate Setting 0 Number of Endpoints 1 Interface Class: 2 (Communications-Control) Interface Subclass; 2 Interface Protocol 1 Comm Class Header Functional Descriptor Raw Descriptor (hex) 0000: 05 24 00 09 01 Comm Class Call Management Functional Descriptor Raw Descriptor (hex) 0000: 05 24 01 03 01 Comm Class Abstract Control Management Functional Descriptor Raw Descriptor (hex) 0000: 04 24 02 0F Comm Class Union Functional Descriptor Raw Descriptor (hex) 0000: 05 24 06 00 01 Endpoint 0x81 - Interrupt Input Attributes: 0x81 (IN) Attributes: 0x03 (Interrupt) Max Packet Size: 16 Polling Interval: 32 ms Interface #1 - Communications-Data/Unknown Comm Class Model Alternate Setting 0 Number of Endpoints 2 Interface Class: 10 (Communications-Data) Interface Subclass; 0 (Unknown Comm Class Model) Interface Protocol 0 Endpoint 0x8A - Bulk Input Attributes: 0x8A (IN) Attributes: 0x02 (Bulk) Max Packet Size: 64 Polling Interval: 0 ms Endpoint 0x0B - Bulk Output Attributes: 0x0B (OUT) Attributes: 0x02 (Bulk) Max Packet Size: 64 Polling Interval: 0 ms Interface #2 - Vendor-specific Alternate Setting 0 Number of Endpoints 2 Interface Class: 255 (Vendor-specific) Interface Subclass; 255 (Vendor-specific) Interface Protocol 0 Endpoint 0x83 - Bulk Input Attributes: 0x83 (IN) Attributes: 0x02 (Bulk) Max Packet Size: 64 Polling Interval: 0 ms Endpoint 0x06 - Bulk Output Attributes: 0x06 (OUT) Attributes: 0x02 (Bulk) Max Packet Size: 64 Polling Interval: 0 ms Roger From bob at redivi.com Thu Feb 10 10:12:10 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 10:12:16 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <006c01c50f4e$7b738080$3501a8c0@rogersqyvr14d3> References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> <006c01c50f4e$7b738080$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 10, 2005, at 3:57, Roger Binns wrote: >> Probably because it doesn't have drivers for them. If there's no >> matching driver, it won't pull up a useful nub to stick on it. > > The right thing happens in the end. There is no need for drivers > on some interfaces, and they must be used on others (eg ones that > implement the USB modem protocol or the various USB to serial chips). > >> A good way to look at this tree is the Mr. Registry app that is one >> of the targets in /Developer/IOKit/firewire/FWOffice -- despite its >> name, it lets you look at the whole tree, not just IOFireWire. > > That makes it clearer. It is still not remotely like two hours work. > (It may be for you however). I'm not going to implement all this > but will point anyone else who does want at it. (The return on > having to learn all this IOKit stuff, Objective C and how to map > Objective C into Python is way too low.) You don't need to touch Objective-C at all! IOKit is plain old C. *I* used Objective-C because it was easier than writing a bare Python extension because you don't have to deal with all the argument packing and unpacking and the CFDictionaryRef, CFStringRef, etc. are transparently bridged into Objective-C types, which are then transparently bridged to Python types. When I'm writing Python extensions by hand, I have to look at docs or use another extension as a template. When I'm writing Objective-C code I just write the code and link it in and use it. The same more or less goes with Pyrex. >> I'd have to do a lot of reading up on that to see how to get dumps of >> USB traffic. > > There is a USB Prober under /Developer/Applications/Utilities > (BTW I have found everything you mentioned under a different path > than you said so I don't know if you were typing them from memory > or have a different dev kit). Probably because it was from memory, or maybe because I might have the FireWire SDK installed? I don't know. I don't think the USB Prober gave me any data when I was using PocketMac, maybe they have disabled it somehow in their drivers to maintain their monopoly on BlackBerry software for Mac OS X? >> I could run the BlackBerry Desktop via VirtualPC (or on a real PC) to >> figure out how the modem stuff works, the rest I could probably get >> by reverse engineering PocketMac. > > Email me the device dump of the device from the USB Prober. You'll > probably want to do that on the bitpim-devel list. I'll do that tomorrow. The BlackBerry has a much less interesting dump, it only has one thing under it and it's of the "vendor specific" type (from memory). -bob From riko at anubics.org Thu Feb 10 12:19:10 2005 From: riko at anubics.org (Enrico Franchi) Date: Thu Feb 10 12:36:30 2005 Subject: [Pythonmac-SIG] Discovering file type Message-ID: <22b2f69977810e79802bef8e64364309@anubics.org> I need to write a function that gets a filepath and gives back what kind of file is that in a consistent way. I thought i could use my beloved old TYPE and CREATOR, then I realized that in MacOS X not every file has got them. So i can check both the extension and the HFSFileType. Still i need a consistent way to express the file type. I need something that given an HFSFileType returns the 'most used' extension, or something that from an extension determines a file type. Is there anything like that? Thanks in advance. -enrico From ray.slakinski at gmail.com Thu Feb 10 12:54:43 2005 From: ray.slakinski at gmail.com (Ray Slakinski) Date: Thu Feb 10 12:54:38 2005 Subject: [Pythonmac-SIG] Discovering file type In-Reply-To: <22b2f69977810e79802bef8e64364309@anubics.org> References: <22b2f69977810e79802bef8e64364309@anubics.org> Message-ID: <9e5ac54ad545e180012379b8cac2f485@gmail.com> I found a type script that mimics the file command in unix. It uses 'magic' to figure out the type -- where magic is a code in most files that identify what it is. So I would google for those pieces of info and your bound to come up with it. Mine is heavily hacked up for my purposes so mine wont be al that useful to you. Ray Slakinski On 10-Feb-05, at 6:19 AM, Enrico Franchi wrote: > I need to write a function that gets a filepath and gives back what > kind of file is that in a consistent way. > > I thought i could use my beloved old TYPE and CREATOR, then I realized > that in MacOS X not every file has got them. > So i can check both the extension and the HFSFileType. > > Still i need a consistent way to express the file type. I need > something that given an HFSFileType returns the 'most used' extension, > or something that from an extension determines a file type. > Is there anything like that? > > Thanks in advance. > > -enrico > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From charles.hartman at conncoll.edu Thu Feb 10 14:05:30 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Feb 10 14:05:40 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> Message-ID: <8916c77d3bae7b4f21cbf22c626cdfc8@conncoll.edu> That's extremely helpful. I'd downloaded the setup script before and planned to study it -- now I'll go back to it. (Wish it did the py2app stuff, for self-pedagogical reasons -- but py2app does make things easier rather than harder.) And for me at least, the slide-show gives quite useful overviews of the cross-platform issues. Thank you. Charles Hartman On Feb 9, 2005, at 11:47 PM, Roger Binns wrote: >> I'm not sure whether to ask if you could explain "compile them into >> the executable" (I don't know how to do that; I have to give my app >> to Windows people, but actually (*knowing* anything about Windows . . >> .) or if you could explain "(bleh)" -- but maybe the one question >> answers the other. Oh well . . . > > On Windows it is possible to make a single file executable and include > all resources within that executable. However most people expect there > to be a single setup executable, and that setup will add the program > to the list of Add/Remove programs in the Control Panel. > > And if you are going to use to a single setup, there is no benefit to > trying to make a single file - it doesn't matter how many files there > are. > > There are also some resources you won't be able to make part of the > single file such as help content as it needs them to be in seperate > files. > > You can make a single app appear be in the native installer format > for each platform. We did it for BitPim. Go ahead, download and > try it. You don't actually need a cell phone for the program to > run. > > This is the Python code used to do the installer work: > > http://cvs.sf.net/viewcvs.py/bitpim/bitpim/makedist.py?view=markup > > Slides 18 through 22 of this talk explain how it is done. Note > however that we now use py2app on Mac. > > http://bitpim.org/papers/baypiggies/ > > Roger > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From Henning.Ramm at mediapro-gmbh.de Thu Feb 10 15:54:56 2005 From: Henning.Ramm at mediapro-gmbh.de (Ramm, Henning) Date: Thu Feb 10 15:54:59 2005 Subject: [Pythonmac-SIG] Discovering file type Message-ID: >I thought i could use my beloved old TYPE and CREATOR, then I realized >that in MacOS X not every file has got them. >So i can check both the extension and the HFSFileType. > >Still i need a consistent way to express the file type. I need >something that given an HFSFileType returns the 'most used' extension, >or something that from an extension determines a file type. >Is there anything like that? Don't think so, I looked for something similar myself and ended adding Type and Creator to every file that I recognize. Because I couldn't find a free extensive list of Type and Creator codes, I collected my own. Perhaps they are of use for anyone: # this type should get that extension type_ext_map = { \ '..CT' : 'ct', \ '8BIM' : 'psd', '8BPS' : 'psd', \ 'AB65' : 'p65', \ 'AGD3' : 'fh8', 'AGD4' : 'fh9', 'AGD5' : 'fh10', 'AGD6' : 'fhmx', \ 'ALB3' : 'pm3', 'ALB4' : 'pm4', 'ALB5' : 'pm5', 'ALB6' : 'pm6', \ 'APPL' : 'app', \ 'aust' : 'sea', \ 'BMP' : 'bmp', '.BMP' : 'bmp', 'BMP_' : 'bmp', 'BMPf' : 'bmp', \ 'CDIC' : 'dic', \ 'CDR6' : 'cdr', 'CDRW' : 'cdr', \ 'CDT' : 'cdt', '.CDT' : 'cdt', 'CDT_' : 'cdt', 'CDT6' : 'cdt', \ 'DWG' : 'dwg', \ 'DXF' : 'dxf', '.DXF' : 'dxf', 'DXF_' : 'dxf', \ 'EPSF' : 'eps', 'EPSP' : 'eps', \ 'FH10' : 'fh10', 'FH40' : 'fh4', 'FH50' : 'fh5', 'FH60' : 'fh6', 'FH70' : 'fh7', \ 'FH80' : 'fh8', 'FH90' : 'fh9', 'FHD3' : 'fh3', \ 'GIF' : 'gif', '.GIF' : 'gif', 'GIF_' : 'gif', 'GIFf' : 'gif', \ 'GZIP' : 'gz', \ 'ICO' : 'ico', \ 'inDd' : 'indd', \ 'JPEG' : 'jpg', \ 'MooV' : 'mov', \ 'MSWD' : 'doc', \ 'PCX' : 'pcx', \ 'PDF' : 'pdf', 'PDF ' : 'pdf', 'PDF_' : 'pdf', '.PDF' : 'pdf', \ 'PICT' : 'pict', \ 'PM3F' : 'pm3', 'PM4F' : 'pm4', 'PM5F' : 'pm5', \ 'PNG' : 'png', \ 'PPT3' : 'ppt', 'PPTV' : 'ppt', \ 'PUBF' : 'pm2', \ 'QTIF' : 'tif', \ 'RTF' : 'rtf', 'RTF ' : 'rtf', 'RTF_' : 'rtf', \ 'SLD8' : 'ppt', \ 'SWFL' : 'swf', \ 'SIT5' : 'sit', \ 'TGA' : 'tga', \ 'TIF' : 'tif', 'TIFF' : 'tif', \ 'TPIC' : 'tga', \ 'ttro' : 'txt', \ 'W6BN' : 'doc', 'W8BN' : 'doc', 'WDBN' : 'doc', \ 'WMF' : 'wmf', 'WMF ' : 'wmf', 'WMF_' : 'wmf', \ 'WP4' : 'wpd', 'WP5' : 'wpd', 'WP6' : 'wpd', 'WPD0' : 'wpd', \ 'WPRD' : 'prd', \ 'XDOC' : 'qxd', \ 'XLS8' : 'xls', \ 'ZIP' : 'zip', 'ZIP ' : 'zip', 'ZIP_' : 'zip' \ } # this extension should have that type ext_type_map = { \ 'anz' : 'TEXT', \ 'app' : 'APPL', \ 'bmp' : 'BMPf', \ 'cdr' : 'CDRW', \ 'css' : 'TEXT', \ 'dmg' : 'devi', \ 'doc' : 'WDBN', \ 'eps' : 'EPSF', \ 'fhmx' : 'AGD6', 'fh10' : 'AGD5', 'fh9' : 'AGD4', \ 'fh8' : 'AGD3', 'fh7' : 'AGD2', \ 'gif' : 'GIFf', \ 'gz' : 'GZIP', \ 'htm' : 'TEXT', 'html' : 'TEXT', \ 'idd' : 'InDd', 'indd' : 'InDd', \ 'jpg' : 'JPEG', 'jpeg' : 'JPEG', \ 'p65' : 'AB65', \ 'pdf' : 'PDF ', \ 'ps' : 'EPSF', \ 'psd' : '8BPS', \ 'qxd' : 'XDOC', \ 'rtf' : 'RTF ', \ 'sit' : 'SIT5', 'sea' : 'SIT5', \ 'tif' : 'TIFF', 'tiff' : 'TIFF', \ 'tga' : 'TPIC', \ 'txt' : 'TEXT' \ } # this extension should use that creator ext_creator_map = { \ 'anz' : 'ttxt', \ 'ai' : 'ART5', \ 'bmp' : '8BIM', \ 'css' : 'sfri', \ 'dmg' : 'ddsk', \ 'doc' : 'MSWD', \ 'fhmx' : 'FH11', 'fh10' : 'FH11', 'fh9' : 'FH11', \ 'fh8' : 'FH11', 'fh7' : 'FH11', 'fh6' : 'FH11', \ 'fh5' : 'FH11', \ 'gif' : '8BIM', \ 'html' : 'sfri', 'htm' : 'sfri', \ 'idd' : 'InDn', 'indd' : 'InDn', \ 'inc' : 'sfri', \ 'jpg' : '8BIM', \ 'pdf' : 'CARO', \ 'ppt' : 'PPT3', \ 'qxb' : 'XPR3', 'qxd' : 'XPR3', 'qxl' : 'XPR3', 'qxt' : 'XPR3', \ 'rtf' : 'MSWD', \ 'sit' : 'SITx', 'sea' : 'SITx', 'sitx' : 'SITx', \ 'tif' : '8BIM', \ 'tga' : '8BIM', \ 'xml' : 'MSIE', \ 'xsl' : 'XCEL', \ 'xtg' : 'XPR3', \ 'zip' : 'SITx' \ } # this type should use that creator type_creator_map = { \ '^FSF' : 'CARO', \ 'AGD2' : 'FH11', 'AGD3' : 'FH11', 'AGD4' : 'FH11', 'AGD5' : 'FH11', 'AGD6' : 'FH11', \ 'FDF' : 'CARO', 'FDF ' : 'CARO', 'FDF_' : 'CARO', \ 'GIFf' : '8BIM', \ 'JPEG' : '8BIM', \ 'PDF' : 'CARO', 'PDF ' : 'CARO', 'PDF_' : 'CARO', \ 'PICT' : '8BIM', \ 'TIFF' : '8BIM', \ 'WDBN' : 'MSWD' \ } # this creator should better be that creator_creator_map = { \ '' : '????', \ #'AGD1' : 'AGD6', 'AGD2' : 'AGD6', 'AGD3' : 'AGD6', 'AGD4' : 'AGD6', 'AGD5' : 'AGD6', \ 'ALD4' : 'AD65', 'ALD5' : 'AD65', 'ALD6' : 'AD65', \ 'ARTY' : 'ART5', 'ART2' : 'ART5', 'ART3' : 'ART5', \ 'ART4' : 'ART5', \ 'BNHQ' : 'SITx', \ 'FHA3' : 'FH11', 'FHA4' : 'FH11', 'FH04' : 'FH11', 'FH50' : 'FH11', 'FH60' : 'FH11', 'FH70' : 'FH11', 'FH80' : 'FH11', 'FH90' : 'FH11', \ 'GKON' : '8BIM', \ 'MOSS' : 'sfri', 'MOZZ' : 'sfri', 'MSIE' : 'sfri', \ 'MSWK' : 'MSWD', \ 'PACT' : 'SITx', \ 'R*ch' : 'ttxt', \ 'SIT!' : 'SITx' \ } # this creator means that application creator_name_map = { \ '' : 'Unknown', ' ' : 'Unknown', \ '????' : 'Unknown', \ '42ap' : 'GrandCentralPro', \ '8BIM' : 'Photoshop', \ 'ACAD' : 'AutoCAD', \ 'ALD4' : 'PageMaker 4', 'ALD5' : 'PageMaker 5', 'ALD6' : 'PageMaker 6.0', 'AD65' : 'PageMaker 6.5', \ 'ARTY' : 'Illustrator', 'ARTZ' : 'Illustrator', 'ART2' : 'Illustrator', 'ART3' : 'Illustrator', 'ART4' : 'Illustrator', 'ART5' : 'Illustrator', \ 'BNHQ' : 'BinHex', \ 'BOBO' : 'AppleWorks', \ 'CARO' : 'Acrobat', \ 'CDRW' : 'CorelDraw', \ 'drag' : 'MacOS X', \ 'EDIT' : 'TextEdit', \ 'ETF0' : 'etf-Jobticket', \ 'F#+A' : 'RagTime', \ 'FH70' : 'Freehand 7', 'FH80' : 'Freehand 8', 'FH90' : 'Freehand 9', 'FH10' : 'Freehand 10', 'FH11' : 'Freehand MX', \ 'GKON' : 'GraphicConverter', \ 'hscd' : 'Unknown (CD)', \ 'InDn' : 'InDesign', \ 'JVWR' : 'Preview', \ 'LMAN' : 'Unknown (Windows)', \ 'MOSS' : 'Netscape Navigator', \ 'MOZZ' : 'Mozilla', \ 'MPS ' : 'Cicero', \ 'MSIE' : 'Internet Explorer', \ 'MSWD' : 'MS Word', \ 'MSWK' : 'MS Works', \ 'PACT' : 'Compactor', \ 'PPT3' : 'PowerPoint', \ 'prvw' : 'Preview', \ 'R*ch' : 'BBEdit', \ 'RSED' : 'ResEdit', \ 'SIT!' : 'StuffIt Classic', \ 'SITx' : 'StuffIt (Expander)', \ 'sfri' : 'Safari', \ 'ttxt' : 'SimpleText', \ 'UNIX' : 'Unknown (UNIX)', \ 'vgrd' : 'Corel Draw SE', \ 'XCEL' : 'Excel', \ 'XPR3' : 'QuarkXPress' \ } # this type means that file type type_name_map = { \ '' : 'unknown file', ' ' : 'unknown file', \ '????' : 'unknown file', \ '42dl' : 'running Download', \ 'AGD3' : 'Freehand 8 Document', 'AGD4' : 'Freehand 9 Document', \ 'clpt' : 'Text-Clip', \ 'APPL' : 'Program', \ 'BINA' : 'Binary', \ 'EPSF' : 'EPS', \ 'EPSP' : 'EPS', \ 'etff' : 'Jobticket', \ 'FFIL' : 'Font Suitcase', \ 'InDd' : 'InDesign Document', \ 'LWFN' : 'PostScript Font', \ 'PDF ' : 'PDF', \ 'SIT5' : 'StuffIt Archive', 'SITD' : 'StuffIt Archive', \ 'TEXT' : 'Text File', \ 'WDBN' : 'Word Document', \ 'XDOC' : 'XPress Document' \ } Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From just at letterror.com Thu Feb 10 16:06:47 2005 From: just at letterror.com (Just van Rossum) Date: Thu Feb 10 16:06:49 2005 Subject: [Pythonmac-SIG] Discovering file type In-Reply-To: Message-ID: Ramm, Henning wrote: > 'WDBN' : 'Word Document', \ > 'XDOC' : 'XPress Document' \ > } (btw, you can leave out all those backslashes...) Just From bob at redivi.com Thu Feb 10 17:02:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 17:02:58 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <8916c77d3bae7b4f21cbf22c626cdfc8@conncoll.edu> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <8916c77d3bae7b4f21cbf22c626cdfc8@conncoll.edu> Message-ID: On Feb 10, 2005, at 8:05, Charles Hartman wrote: > On Feb 9, 2005, at 11:47 PM, Roger Binns wrote: > >>> I'm not sure whether to ask if you could explain "compile them into >>> the executable" (I don't know how to do that; I have to give my app >>> to Windows people, but actually (*knowing* anything about Windows . >>> . .) or if you could explain "(bleh)" -- but maybe the one question >>> answers the other. Oh well . . . >> >> On Windows it is possible to make a single file executable and include >> all resources within that executable. However most people expect >> there >> to be a single setup executable, and that setup will add the program >> to the list of Add/Remove programs in the Control Panel. >> >> And if you are going to use to a single setup, there is no benefit to >> trying to make a single file - it doesn't matter how many files there >> are. >> >> There are also some resources you won't be able to make part of the >> single file such as help content as it needs them to be in seperate >> files. >> >> You can make a single app appear be in the native installer format >> for each platform. We did it for BitPim. Go ahead, download and >> try it. You don't actually need a cell phone for the program to >> run. >> >> This is the Python code used to do the installer work: >> >> http://cvs.sf.net/viewcvs.py/bitpim/bitpim/makedist.py?view=markup >> >> Slides 18 through 22 of this talk explain how it is done. Note >> however that we now use py2app on Mac. >> >> http://bitpim.org/papers/baypiggies/ >> > That's extremely helpful. I'd downloaded the setup script before and > planned to study it -- now I'll go back to it. (Wish it did the py2app > stuff, for self-pedagogical reasons -- but py2app does make things > easier rather than harder.) And for me at least, the slide-show gives > quite useful overviews of the cross-platform issues. Thank you. The referenced makedist.py *does* do the py2app stuff. It's the slides that have not been updated accordingly. -bob From bob at redivi.com Thu Feb 10 17:08:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 17:09:04 2005 Subject: [Pythonmac-SIG] Discovering file type In-Reply-To: <22b2f69977810e79802bef8e64364309@anubics.org> References: <22b2f69977810e79802bef8e64364309@anubics.org> Message-ID: <1ad8b14b8024f1cd335baa94f84ca599@redivi.com> On Feb 10, 2005, at 6:19, Enrico Franchi wrote: > I need to write a function that gets a filepath and gives back what > kind of file is that in a consistent way. > > I thought i could use my beloved old TYPE and CREATOR, then I realized > that in MacOS X not every file has got them. > So i can check both the extension and the HFSFileType. > > Still i need a consistent way to express the file type. I need > something that given an HFSFileType returns the 'most used' extension, > or something that from an extension determines a file type. > Is there anything like that? Since 10.3, LaunchServices's UTType functions should be able to do this, but I don't think they're wrapped in Python (wouldn't be hard to loadBundleFunctions them into PyObjC, though). I've also never tried them, so I don't know how complete the database is. -bob From mike at maibaum.org Thu Feb 10 18:07:34 2005 From: mike at maibaum.org (Michael Maibaum) Date: Thu Feb 10 18:07:38 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <4208FD71.1010509@noaa.gov> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> Message-ID: <20050210170734.GC50333@remote.gene-hacker.net> On Tue, Feb 08, 2005 at 09:57:05AM -0800, Chris Barker wrote: >Bob Ippolito wrote: >>>On 8-feb-05, at 15:51, Brendan Simons wrote: >>> >>>>My question: can I use py2app to build a >>>>redistributable app that's statically linked to either >>>>package manager's libraries? Or do I have to install >>>>Fink/DarwinPorts on each of my clients' machines? > >If you are distributing a single substantial application, py2app is >probably the way to go. However, if you are distributing a set of apps, >you may not want each one to have a complete copy of everything, so... > >>>>(I would like to develop an app that uses numeric, >>>>scientific python, wxPython, and matplotlib, which are >>>>all somewhat difficult to install by hand, but are all >>>>readily available via Fink or DarwinPorts) > >The Fink and Darwinports versions of these will give you X11 versions >(particularly wxPython), which you may not want (Someone please correct >me if I'm wrong). In fact, if you use fink, you may get it all working FWIW, DarwinPorts has 'aqua' variants of many packages, and if you want them for something that doesn't have one, either add the variant and send off the patch, or make a request. As for Python. As soon as there is a framework version of Python that can be installed via a destroot for packaging, I'll add it to DarwinPorts. Or if someone can figure out how to hack the current version to do it... similarly I have an Portfile for an X11 version of SciPy, and an adapted one for aqua - but the inability to install Python Framework via a destroot is a blocker for that. DarwinPorts aims to integrate where practical - so we depend on our own version of Python because the OS version is broken (as the fix packages available show) and because we don't want to slap cruft into the main part of the filesystem. + we want to use python2.4 for the most part, and Panther has 2.3. cheers Michael From bob at redivi.com Thu Feb 10 18:13:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 18:14:01 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <74c876d58307809a377143241bdf88a0@redivi.com> References: <86631c86a2db7b645c60738d88becd79@commonground.com.au><4f714fa546884d099d65acbd1eee2573@commonground.com.au><5cc801f2647e9f10d3bacc18892118d9@redivi.com><200502041158.32890.richard@commonground.com.au><7f94c3cdad3569c54eabdb85fa4ac4a4@redivi.com><5d640cd8da2f11645004d8adda3136a1@redivi.com><260f344d3a2fd80f6529184f2a636e2e@commonground.com.au><72d9c8e3c63f57701fb25da94ec2de38@redivi.com><02526d76d1f5578effbcbf4a98d1e8be@commonground.com.au><3cdfe08cdba5d3f9d425e1a2822598c4@redivi.com><1ba58a6f9075f95648c8df9040f0e079@conncoll.edu> <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> <74c876d58307809a377143241bdf88a0@redivi.com> Message-ID: On Feb 10, 2005, at 2:38 AM, Bob Ippolito wrote: > > On Feb 10, 2005, at 2:25 AM, Roger Binns wrote: > >> Incidentally I did find a gross hack to work around the py2app >> bug of not handling the optimise option. Stripping out the doc >> strings saves over 3MB of compressed size, and aren't useful >> in the binary end user distribution anyway. > > It's close(r) to working in svn trunk, but I don't think it actually > works just yet. It seems that it actually does work in svn trunk, let me know if it doesn't. -bob From Chris.Barker at noaa.gov Thu Feb 10 18:37:01 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Feb 10 18:37:38 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <20050210170734.GC50333@remote.gene-hacker.net> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <20050210170734.GC50333@remote.gene-hacker.net> Message-ID: <420B9BBD.6010500@noaa.gov> Michael Maibaum wrote: > FWIW, DarwinPorts has 'aqua' variants of many packages, cool. I'll have to look into which ones, thought I'll start with a question: wxPython? > and if you want > them for something that doesn't have one, either add the variant and > send off the patch, or make a request. > As for Python. As soon as there is a framework version of Python that > can be installed via a destroot for packaging, I'll add it to > DarwinPorts. Or if someone can figure out how to hack the current > version to do it... > > similarly I have an Portfile for an X11 version of SciPy, and an adapted > one for aqua - but the inability to install Python Framework via a > destroot is a blocker for that. > DarwinPorts aims to integrate where practical - so we depend on our own > version of Python because the OS version is broken (as the fix packages > available show) and because we don't want to slap cruft into the main > part of the filesystem. Well, I didn't follow all that, but it sounds like the gist is what I suspected: 1) The DarwinPorts python packages don't use Apple's Python 2) The DarwinPorts python doesn't play well with Aqua. 3) This may be fixed in the future, if someone can figure out how and put in the time. 4) I can use DarwinPorts to install libs needed by python packages, and use them with Apple's python. Have I got that right? Note also that I'm optimistic that Tiger will provide a Python that plays better with other pythons. So we can't use DarwinPorts to get fully functional versions of wxPython, SciPy and matplotlib (to name a few I need) that are aqua based. I'd love to contribute, but all this Framework/destroot stuff is well beyond me! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From mike at maibaum.org Thu Feb 10 19:02:09 2005 From: mike at maibaum.org (Michael Maibaum) Date: Thu Feb 10 19:41:51 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <420B9BBD.6010500@noaa.gov> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <20050210170734.GC50333@remote.gene-hacker.net> <420B9BBD.6010500@noaa.gov> Message-ID: <20050210180209.GD50333@remote.gene-hacker.net> On Thu, Feb 10, 2005 at 09:37:01AM -0800, Chris Barker wrote: >Michael Maibaum wrote: >>FWIW, DarwinPorts has 'aqua' variants of many packages, > >cool. I'll have to look into which ones, thought I'll start with a >question: wxPython? X11 - wxWidgets and wxWindows in dports build aqua by default, but python doesn't. > > > and if you want >>them for something that doesn't have one, either add the variant and >>send off the patch, or make a request. > >>As for Python. As soon as there is a framework version of Python that >>can be installed via a destroot for packaging, I'll add it to >>DarwinPorts. Or if someone can figure out how to hack the current >>version to do it... >> >>similarly I have an Portfile for an X11 version of SciPy, and an adapted >>one for aqua - but the inability to install Python Framework via a >>destroot is a blocker for that. >>DarwinPorts aims to integrate where practical - so we depend on our own >>version of Python because the OS version is broken (as the fix packages >>available show) and because we don't want to slap cruft into the main >>part of the filesystem. > >Well, I didn't follow all that, but it sounds like the gist is what I >suspected: > >1) The DarwinPorts python packages don't use Apple's Python >2) The DarwinPorts python doesn't play well with Aqua. >3) This may be fixed in the future, if someone can figure out how and >put in the time. >4) I can use DarwinPorts to install libs needed by python packages, and >use them with Apple's python. > >Have I got that right? Yep. Michael From mwh at python.net Thu Feb 10 20:56:49 2005 From: mwh at python.net (Michael Hudson) Date: Thu Feb 10 20:56:50 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <20050210170734.GC50333@remote.gene-hacker.net> (Michael Maibaum's message of "Thu, 10 Feb 2005 09:07:34 -0800") References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <20050210170734.GC50333@remote.gene-hacker.net> Message-ID: <2mis50429q.fsf@starship.python.net> Michael Maibaum writes: > As for Python. As soon as there is a framework version of Python > that can be installed via a destroot for packaging, I'll add it to > DarwinPorts. Or if someone can figure out how to hack the current > version to do it... Is there a bug report for this? The python build process on OS X has been pretty stable of late, I'd been lulled into thinking it was working :) Cheers, mwh -- The meaning of "brunch" is as yet undefined. -- Simon Booth, ucam.chat From bob at redivi.com Thu Feb 10 21:16:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 21:17:01 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <2mis50429q.fsf@starship.python.net> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <20050210170734.GC50333@remote.gene-hacker.net> <2mis50429q.fsf@starship.python.net> Message-ID: <62840dfe5353b37826938108dc8e555a@redivi.com> On Feb 10, 2005, at 2:56 PM, Michael Hudson wrote: > Michael Maibaum writes: > >> As for Python. As soon as there is a framework version of Python >> that can be installed via a destroot for packaging, I'll add it to >> DarwinPorts. Or if someone can figure out how to hack the current >> version to do it... > > Is there a bug report for this? > > The python build process on OS X has been pretty stable of late, I'd > been lulled into thinking it was working :) It does work, it just won't destroot due to problems in bundlebuilder and friends.. This thread was the last I remember it being discussed: http://mail.python.org/pipermail/pythonmac-sig/2004-December/ 012320.html -bob From Jack.Jansen at cwi.nl Thu Feb 10 23:03:09 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Feb 10 23:03:15 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5 for 10.2 Release Candidate available Message-ID: <8CE336C2-7BAF-11D9-8E7F-000D934FF6B4@cwi.nl> Folks, a MacPython 2.3.5 release for MacOSX 10.2 (also works on 10.3) is available for testing. Please download it from and send feedback (preferably to the mailing list) telling me whether it works. I'm quite convinced this is going to be the final installer, but before I publicly announce it I'd like a couple of positive replies. Also, the PackMan database for 10.2 isn't as complete as I'd like yet, that'll be done in the next few days. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Thu Feb 10 23:12:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 23:12:14 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5 for 10.2 Release Candidate available In-Reply-To: <8CE336C2-7BAF-11D9-8E7F-000D934FF6B4@cwi.nl> References: <8CE336C2-7BAF-11D9-8E7F-000D934FF6B4@cwi.nl> Message-ID: <5256fd6e5b409f55d20db7b262db7617@redivi.com> On Feb 10, 2005, at 5:03 PM, Jack Jansen wrote: > Folks, > a MacPython 2.3.5 release for MacOSX 10.2 (also works on 10.3) is > available for testing. Please download it from > and send feedback > (preferably to the mailing list) telling me whether it works. > > I'm quite convinced this is going to be the final installer, but > before I publicly announce it I'd like a couple of positive replies. > Also, the PackMan database for 10.2 isn't as complete as I'd like yet, > that'll be done in the next few days. Why not ship it with the fix for 10.3? Maybe in a folder called "INSTALL THIS FIRST IF USING MAC OS X 10.3"? :) -bob From bob at redivi.com Thu Feb 10 23:31:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 10 23:31:59 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5 for 10.2 Release Candidate available In-Reply-To: <5256fd6e5b409f55d20db7b262db7617@redivi.com> References: <8CE336C2-7BAF-11D9-8E7F-000D934FF6B4@cwi.nl> <5256fd6e5b409f55d20db7b262db7617@redivi.com> Message-ID: <40ca9682b5ae434dd60bbd70dd2108d5@redivi.com> On Feb 10, 2005, at 5:12 PM, Bob Ippolito wrote: > > On Feb 10, 2005, at 5:03 PM, Jack Jansen wrote: > >> Folks, >> a MacPython 2.3.5 release for MacOSX 10.2 (also works on 10.3) is >> available for testing. Please download it from >> and send feedback >> (preferably to the mailing list) telling me whether it works. >> >> I'm quite convinced this is going to be the final installer, but >> before I publicly announce it I'd like a couple of positive replies. >> Also, the PackMan database for 10.2 isn't as complete as I'd like >> yet, that'll be done in the next few days. > > Why not ship it with the fix for 10.3? Maybe in a folder called > "INSTALL THIS FIRST IF USING MAC OS X 10.3"? :) I tried it out on 10.3 and it works great (at runtime). It will import extensions I've built for the 10.3 Python (since I built them with the fix), and py2app embeds this Python quite happily. I have not tried it yet on 10.2, nor have I tried it with a 2.4 framework also installed. When building extensions, it won't let me use MACOSX_DEPLOYMENT_TARGET at all: % env MACOSX_DEPLOYMENT_TARGET=10.3 /usr/local/bin/python setup.py build .... error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but "" during configure % env MACOSX_DEPLOYMENT_TARGET=10.2 /usr/local/bin/python setup.py build .... error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.2" but "" during configure % env MACOSX_DEPLOYMENT_TARGET="" /usr/local/bin/python setup.py build (succeeds) This isn't the biggest deal in the world, but it forces the compiler and linker to default to 10.1 semantics -- when in reality anything I build will be compatible with 10.2 at best. -bob From bob at redivi.com Fri Feb 11 00:27:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 00:27:41 2005 Subject: [Pythonmac-SIG] Numeric 23.7 w/ vecLib (Apple's optimized implementation of BLAS) In-Reply-To: <7bc3e10b96effd3f0bd7455b0912f42b@redivi.com> References: <7bc3e10b96effd3f0bd7455b0912f42b@redivi.com> Message-ID: <36ba136af02db14383b039d8d229b2c8@redivi.com> On Feb 10, 2005, at 1:27 AM, Bob Ippolito wrote: > Here's a Numeric 23.7 for Mac OS X 10.3 (using the stock Python 2.3 > interpreter), built with py2app 0.1.8 (svn trunk)'s bdist_mpkg > command: > http://undefined.org/python/Numeric-23.7-py2.3-macosx10.3.zip > > Numeric 23.7's setup.py *almost* gets vecLib right. Trivial patch is > here: > https://sourceforge.net/tracker/? > func=detail&atid=301369&aid=996268&group_id=1369 I goofed slightly in my first patch, it missed the extra_linker_options for _dotblas, which makes it unimportable unless lapack_lite was imported first. I've updated the patch and the installer, the URLs are the same. 1ae5354ebf898143decb1c708bf03502 Numeric-23.7-py2.3-macosx10.3.zip Note also that bdist_mpkg in svn trunk now has a -z or --zipdist option that creates a zip from the pkg automatically.. so with trunk, creating packages such as this is as easy as bdist_mpkg -z from the source dir. -bob From rogerb at rogerbinns.com Fri Feb 11 05:51:54 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 05:51:48 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? Message-ID: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> The standard Python on Mac appears to be the original 2.3.0 release. Is there any reason this never gets updated by Apple? There appear to be several other packages out there that are more recent, but it is never clear what they do. Are they replacements for the Apple python? Do they install alongside it so you have two versions? Why is there nothing on python.org about what should or should not be installed and updated? The only Python I care about is the main system one, and would prefer it to contain bug fixes. Roger From bob at redivi.com Fri Feb 11 06:14:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 06:15:08 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> Message-ID: <64ca14354760ade01938e9fc851db1ec@redivi.com> On Feb 10, 2005, at 11:51 PM, Roger Binns wrote: > The standard Python on Mac appears to be the original 2.3.0 release. The system one that shipped with Mac OS X 10.2 (2.2.0) is pretty much unusable, 10.3 does have the original 2.3.0 release. > Is there any reason this never gets updated by Apple? Apple's upgrade policy seems to be one of urgency rather than convenience. If there were gnarly security issues in Python, I'm sure we'd have seen an upgrade. There's an upgrade around the corner called Tiger (10.4), which will ship with a more recent version of Python. Which version this is, I can't say, but the public WWDC 2004 sources had 2.3.3 if I'm not mistaken. > There appear to be several other packages out there that are more > recent, but it is never clear what they do. Are they replacements > for the Apple python? Do they install alongside it so you have > two versions? Why is there nothing on python.org about what > should or should not be installed and updated? Only Apple should ever fix Apple's software (`PantherPythonFix`_ being the only exception I'd recommend). Therefore, anything else goes somewhere else. Jack's `MacPython 2.3.5`_ build goes into /Library/Frameworks/Python.framework, puts some applications in /Applications/MacPython-2.3 and some symlinks in /usr/local/bin. If you want to "replace" the Apple python, then you simply need to change your PATH. As far as documentation goes, we could sure use some. However, for 10.3 users, 2.3.0 is usually more than adequate. The only time I've ever needed something newer is for Zope. > The only Python I care about is the main system one, and would > prefer it to contain bug fixes. Well I have slopped together the `Python23Compat`_ package that brings in some of the new stuff from Python 2.4, and Jack has a package `PantherPythonFix`_ that fixes some distutils nits. There are some bugfixes that would be nice, but it's dangerous to do that because you end up with some people that have a fast datetime module and some people with a slow datetime module, or some people with a plistlib that works with dates, and other people without. If you want an application that is 10.2 compatible, then you need to build it with a non-system Python (where it, and all of the extensions used, were also built on 10.2) If you want an application that will work, unchanged, far into the future, then you should build it with a non-system Python. There's a good chance system-python-dependent applications built on 10.3 will work on 10.4, but there's probably not a good chance that such applications will work on later versions of Mac OS X (if, for example, Python 2.4 becomes the default and 2.3 goes away). .. _`MacPython 2.3.5`: http://homepages.cwi.nl/~jack/macpython/beta.html .. _`Python23Compat`: http://bob.pythonmac.org/archives/2005/02/02/python23compat/ .. _`PantherPythonFix`: http://bob.pythonmac.org/archives/2005/02/04/fix-mac-os-x-103s-python -230/ -bob From rogerb at rogerbinns.com Fri Feb 11 09:10:17 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 09:10:12 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0e39cb3ea8cdd226362563c9104642a2@redivi.com> <002001c50f41$a4545bd0$3501a8c0@rogersqyvr14d3> <74c876d58307809a377143241bdf88a0@redivi.com> <003401c50f46$a5514020$3501a8c0@rogersqyvr14d3> <441d6f45aa18de66df942dcead60420b@redivi.com> <006301c50f4a$32582080$3501a8c0@rogersqyvr14d3> <51fb44e4723aa768fbe3de1b911246a7@redivi.com> Message-ID: <000a01c51011$1f9a46e0$3501a8c0@rogersqyvr14d3> >>> You're probably not setting the right plist keys or something for >>> Apple's help. >> >> The documentation doesn't make it clear what should be set. >> Additionally I have no idea how to make them from Python so >> I can automate all this. > > Python does it, see: > python/dist/src/Mac/OSX/Doc There is a heroic amount of code there, a lot of it because Apple pathologically want you to run the help indexer by dragging and dropping and not in any automated manner. Anyway I wasted yet another hour following what that does and it still doesn't work without any indication why. I really don't care any more. If anyone wants BitPim to use the Apple help mechanisms, then they can spend hours of their time working it out and contributing whatever needs to be done. The way Apple does it also makes it impossible to use the help while doing development since a bundle doesn't exist at that point. Roger From rogerb at rogerbinns.com Fri Feb 11 09:15:03 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 09:14:56 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> <006c01c50f4e$7b738080$3501a8c0@rogersqyvr14d3> Message-ID: <001101c51011$c991a120$3501a8c0@rogersqyvr14d3> > You don't need to touch Objective-C at all! IOKit is plain old C. All the example code is in Objective C. Quite simply there is far too steep a learning curve to get through these layers be it Objective C or pseudo objects in C plus mapping into Python land. It really is orders of magnitude easier working with win32all on Windows than trying to do the equivalent stuff on Mac. Linux doesn't even enter since there is no way of doing things like help or some of the device stuff. >> There is a USB Prober under /Developer/Applications/Utilities >> (BTW I have found everything you mentioned under a different path >> than you said so I don't know if you were typing them from memory >> or have a different dev kit). > > Probably because it was from memory, or maybe because I might have the > FireWire SDK installed? I don't know. I had all the tools and examples you mentioned and I just have the standard reinstall that came with the Mac mini. I couldn't get the USB Prober to see libusb traffic so it may require the device drivers to cooperate. It looks like it installs an alternative driver for the controller. Roger From rogerb at rogerbinns.com Fri Feb 11 09:25:51 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 09:25:45 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> Message-ID: <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> > Apple's upgrade policy seems to be one of urgency rather than > convenience. If there were gnarly security issues in Python, I'm sure > we'd have seen an upgrade. There's an upgrade around the corner called > Tiger (10.4), which will ship with a more recent version of Python. > Which version this is, I can't say, but the public WWDC 2004 sources > had 2.3.3 if I'm not mistaken. The issue is that I am not doing stuff for just myself. Any other Mac BitPim developers have to use the same version of Python and the same extensions. I also try as much as possible to use binary installations that are in as wide a usage as possible. That helps ensure that any bugs are found. Anything you build yourself or is used by a small number of people can have issues. For example when I built wxPython on a Redhat box it used SDL because it happened to be installed. When I then redistributed BitPim binaries, things failed to run on some people's machines. > There are some bugfixes that would be nice, but it's dangerous to do > that because you end up with some people that have a fast datetime > module and some people with a slow datetime module, or some people with > a plistlib that works with dates, and other people without. That is why I stay "mainstream". The problem now is that BitPim on Mac is using 2.3.0, yet 2.3.4 on Windows and Linux. I presume the various bug fixes in 2.3.[1-5] were serious enough to warrant new releases, otherwise why did they bother making them. > If you want an application that is 10.2 compatible, The way I deal with OS version compatibility is to just build on whatever the version is. I never try and build on a newer version and hope it will work on older versions. That mythical virtualisation software would be very handy for this. > There's a good chance system-python-dependent applications built on 10.3 will > work on 10.4, but there's probably not a good chance that such > applications will work on later versions of Mac OS X (if, for example, > Python 2.4 becomes the default and 2.3 goes away). And that is how we end up building for different MacOS versions. When we switch to Python 2.4, it will be required for all supported operating systems and their versions. Presumably we'll still be supporting 10.3 then so I'll have to figure out how to deal with that. Roger From riko at anubics.org Fri Feb 11 13:00:21 2005 From: riko at anubics.org (Enrico Franchi) Date: Fri Feb 11 13:00:32 2005 Subject: [Pythonmac-SIG] Discovering file type In-Reply-To: References: Message-ID: <456b43297bc677c1a073e17f5b601cd0@anubics.org> On 10/feb/05, at 15:54, Ramm, Henning wrote: > Don't think so, I looked for something similar myself and ended adding > Type and Creator to every file that I recognize. > Because I couldn't find a free extensive list of Type and Creator > codes, I collected my own. Perhaps they are of use for anyone: Well, it is (almost) what I was looking for, even if it is not included in system. I just found out that LaunchServices solve another of my problems, but not this one. Probably I have to give'em a closer look, maybe searching more approfonditely ACDC... -enrico From moehl at akaflieg.extern.tu-berlin.de Fri Feb 11 13:57:58 2005 From: moehl at akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Fri Feb 11 13:58:00 2005 Subject: [Pythonmac-SIG] pythonw, site-packages, .pth problem Message-ID: Hi, I ran into a namespace conflict between wx2.5.3 and vtk4.4 on Panther with the Macpython additions. Analyzing the problem I stumbled across a strange behaviour. It seems that *.pth files are simply ignored. If that is so, where does pythonw keep its pathes as I did not set a PYTHONPATH? Torsten From moehl at akaflieg.extern.tu-berlin.de Fri Feb 11 15:02:47 2005 From: moehl at akaflieg.extern.tu-berlin.de (Torsten Sadowski) Date: Fri Feb 11 15:02:48 2005 Subject: [Pythonmac-SIG] pythonw, site-packages, .pth problem In-Reply-To: References: Message-ID: Sorry, the.pth files are evaluated. I was simply too stupid to copy the vtk stuff to the right place. Torsten On Fri, 11 Feb 2005, Torsten Sadowski wrote: > Hi, > > I ran into a namespace conflict between wx2.5.3 and vtk4.4 on Panther > with the Macpython additions. > Analyzing the problem I stumbled across a strange behaviour. It seems that > *.pth files are simply ignored. If that is so, where does pythonw keep its > pathes as I did not set a PYTHONPATH? > > Torsten > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From bob at redivi.com Fri Feb 11 16:02:27 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 16:02:41 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <001101c51011$c991a120$3501a8c0@rogersqyvr14d3> References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> <006c01c50f4e$7b738080$3501a8c0@rogersqyvr14d3> <001101c51011$c991a120$3501a8c0@rogersqyvr14d3> Message-ID: <4ed6c9fa0e27f2c9a67d8f8d0222b060@redivi.com> On Feb 11, 2005, at 3:15, Roger Binns wrote: >> You don't need to touch Objective-C at all! IOKit is plain old C. > > All the example code is in Objective C. Quite simply there is > far too steep a learning curve to get through these layers be > it Objective C or pseudo objects in C plus mapping into Python > land. Uh, no it isn't. A fair share of the IOKit examples are pure C or C++. > It really is orders of magnitude easier working with win32all > on Windows than trying to do the equivalent stuff on Mac. Linux > doesn't even enter since there is no way of doing things like > help or some of the device stuff. Yes, the help stuff is a pain in the ass, querying IOKit really isn't. -bob From bob at redivi.com Fri Feb 11 16:08:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 16:08:24 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 11, 2005, at 3:25, Roger Binns wrote: >> There are some bugfixes that would be nice, but it's dangerous to do >> that because you end up with some people that have a fast datetime >> module and some people with a slow datetime module, or some people >> with a plistlib that works with dates, and other people without. > > That is why I stay "mainstream". The problem now is that BitPim > on Mac is using 2.3.0, yet 2.3.4 on Windows and Linux. I presume > the various bug fixes in 2.3.[1-5] were serious enough to warrant > new releases, otherwise why did they bother making them. The standard library is large, it's entirely possible that five bugfix releases go by and don't touch anything you use. If you want to build with a newer version of Python, go ahead, there's nothing stopping you and py2app will do the right thing. Simply invoke setup.py with the python you want included in the application bundle. The system Python is a special case in that it *refuses* to copy it into the bundle for various reasons. >> If you want an application that is 10.2 compatible, > > The way I deal with OS version compatibility is to just build on > whatever the version is. I never try and build on a newer version > and hope it will work on older versions. That mythical virtualisation > software would be very handy for this. > >> There's a good chance system-python-dependent applications built on >> 10.3 will work on 10.4, but there's probably not a good chance that >> such applications will work on later versions of Mac OS X (if, for >> example, Python 2.4 becomes the default and 2.3 goes away). > > And that is how we end up building for different MacOS versions. > > When we switch to Python 2.4, it will be required for all supported > operating systems and their versions. Presumably we'll still be > supporting 10.3 then so I'll have to figure out how to deal with > that. But my point was that you only need to build on the lowest common denominator and it will work everywhere else. -bob From rogerb at rogerbinns.com Fri Feb 11 17:59:51 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 17:59:44 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> Message-ID: <006401c5105b$1a42f030$3501a8c0@rogersqyvr14d3> > The standard library is large, it's entirely possible that five bugfix > releases go by and don't touch anything you use. I think some of the weakref bugfixes (ie in the C core) may be relevant although it I may also have accidentally the usage in such a way that it works around the problems. > If you want to build with a newer version of Python, go ahead, there's > nothing stopping you and py2app will do the right thing. Simply invoke > setup.py with the python you want included in the application bundle. > The system Python is a special case in that it *refuses* to copy it > into the bundle for various reasons. On Linux the pydotorg Python does install into a different directory structure and all works fine (the base Python on Redhat 9 is 2.2). I'm sure py2app works fine, but it is trivial compared to my other dependencies, especially wxPython. The wxPython page says: wxPythonOSX needs a "Framework" build of Python 2.3, also known as MacPython-OSX. If you have OSX 10.3 (Panther) then you already have what you need ... > But my point was that you only need to build on the lowest common > denominator and it will work everywhere else. No, your point was that it *should* work everywhere else. A failure to work everywhere else has already happened to us once and who knows what will actually happen when Tiger comes out. (I am definitely intending to drop 10.2 support at that point). Roger From bob at redivi.com Fri Feb 11 18:20:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 18:20:39 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: <006401c5105b$1a42f030$3501a8c0@rogersqyvr14d3> References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> <006401c5105b$1a42f030$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 11, 2005, at 11:59 AM, Roger Binns wrote: >> The standard library is large, it's entirely possible that five >> bugfix releases go by and don't touch anything you use. > > I think some of the weakref bugfixes (ie in the C core) may be relevant > although it I may also have accidentally the usage in such a way that > it works around the problems. To my knowledge, the weakref stuff fixes some edge cases that you probably don't have. Those bugs have been in weakref for a long time. >> If you want to build with a newer version of Python, go ahead, >> there's nothing stopping you and py2app will do the right thing. >> Simply invoke setup.py with the python you want included in the >> application bundle. The system Python is a special case in that it >> *refuses* to copy it into the bundle for various reasons. > > On Linux the pydotorg Python does install into a different directory > structure and all works fine (the base Python on Redhat 9 is 2.2). > I'm sure py2app works fine, but it is trivial compared to my other > dependencies, especially wxPython. The wxPython page says: > > wxPythonOSX needs a "Framework" build of Python 2.3, also known as > MacPython-OSX. If you have OSX 10.3 (Panther) then you already have > what you need ... Yeah, if you want to use a non-system Python with an extension built with the system Python there are some potential issues. Specifically, if the extensions were built without PantherPythonFix, then they will crash on import unless they have been run through py2app (but not with the alias bundle option, it does not touch extensions). Otherwise, if they were built with the fix, then they do not directly reference any Python so it is simply ok to just copy them somewhere on the sys.path of your non-system Python. I could write a script (similar to macho_standalone) that sanitizes Python extensions so that they may be used with a different Python of the same major version, but except for 10.2, the real solution is just to use PantherPythonFix and recompile (relink really). >> But my point was that you only need to build on the lowest common >> denominator and it will work everywhere else. > > No, your point was that it *should* work everywhere else. A failure > to work everywhere else has already happened to us once and who knows > what will actually happen when Tiger comes out. (I am definitely > intending to drop 10.2 support at that point). This failure was probably due to the fact that you were not using py2app at the time. I bet it was a Version Mismatch issue because the extensions that went into the bundle directly referenced /Library/Frameworks/Python.framework and the user had a Python installed there. The application would then have two Python interpreters in-process and when that happens it goes BOOM. If you are embedding a non-system Python with py2app, then you will not have this issue. (dropping 10.2 support is going to be a dream come true). -bob From rogerb at rogerbinns.com Fri Feb 11 18:26:17 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 18:26:09 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> <006c01c50f4e$7b738080$3501a8c0@rogersqyvr14d3> <001101c51011$c991a120$3501a8c0@rogersqyvr14d3> <4ed6c9fa0e27f2c9a67d8f8d0222b060@redivi.com> Message-ID: <008101c5105e$cbc6f0b0$3501a8c0@rogersqyvr14d3> >> All the example code is in Objective C. Quite simply there is >> far too steep a learning curve to get through these layers be >> it Objective C or pseudo objects in C plus mapping into Python >> land. > > Uh, no it isn't. A fair share of the IOKit examples are pure C or C++. Ok, more accurately the examples that were looking at hierarchies are in Objective C. And I'm sure that working with IOKit, in C or Objective C, once you have done it a few times is quick and easy. If you haven't then a time investment is needed to understand the docs, the examples, the types, actually write code that works, map it into Python etc. Roger From rogerb at rogerbinns.com Fri Feb 11 18:34:04 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 18:33:56 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> <006401c5105b$1a42f030$3501a8c0@rogersqyvr14d3> Message-ID: <008801c5105f$e2076480$3501a8c0@rogersqyvr14d3> > To my knowledge, the weakref stuff fixes some edge cases that you > probably don't have. Those bugs have been in weakref for a long time. BitPim also isn't a long running process so leaks wouldn't be that big a deal. > Yeah, if you want to use a non-system Python with an extension built > with the system Python there are some potential issues. Is there a page somewhere that actually explains what all this terminology is about (eg Framework, alias bundles and similar). I am used to the Python files and libraries just existing in a conventional filesystem. Nothing complicated. All very trivial. Multiple versions can be installed. A simple --prefix can move where it is in ./configure. Each one is an island with no possibility of sharing extensions or modifications between them. (That is a very good thing - keeps it simple.) wxPython does have some dynamic linking issues on Unix (it hard codes the path to the wxWidgets directory at the ELF level, but chrpath fixes that.) > This failure was probably due to the fact that you were not using > py2app at the time. We used to use bundlebuilder. So it sounds like there is 99.999% chance we won't have to do seperate 10.4 builds. Unless we do things like hook into SpotLight .... Roger From pecora at anvil.nrl.navy.mil Fri Feb 11 18:36:27 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Fri Feb 11 18:36:29 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> Message-ID: <420CED1B.4030401@anvil.nrl.navy.mil> Brendan Simons wrote: > The IDE thread is a recurring one. Here's my experience as another > Python newbie. I tried SPE, PythonCard, PyOxice, PyPE, eclipse and > wing (under x11). All work, but I found that each one had enough > quirks (mostly UI inconsistencies, but some are downright unstable) > that I was less productive than without. Not to sell any short, I'm > sure they will get better given time. > > FWIW, the winning formula for me right now is: > > 1) Editor: TextWrangler (http://www.barebones.com/index.shtml). > -Free, "Made For Mac", Code Colouring, Method Indexing, The ability > to run scripts from the editor, More text manipulation options than I > can count. > > 2) GuiEditor: XRCed.py (comes with the wxPython install package). > (Or code the wxPython by hand, which takes longer, but gives you a > little more control over the result). > > 3) And an instance of terminal running python interactive mode. > Actually, this is the most valuable Python tool I've found so far - > it's like a scratch pad where I can quickly check assumptions, or test > out ideas. > > The only thing I'm missing now is a debugger with breakpoints, call > stack, and variable watches. I'll have to settle for random print > statements for now. > > -Brendan You didn't mention the regular Mac Python IDE (maybe you did and I don't know it by the names you used). But it is pretty nice (no syntax coloring is the most negative) on the other hand it has a debugger that's very nice and easy to use. But does it work with wxPython? I know some things (Tkinter, I think) doesn't play nice with MacPython. I really like the ability to edit and just hit cmd-R to run the script. The IDE could use some updating and wart removal. Syntax coloring, better scrolling (that's damaged right now), use of scroll wheel (if present), a few other interface changes. In the end it's my tool. I don't really understand how your are doing the development. You have to jump to a term window to run the script? -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From rogerb at rogerbinns.com Fri Feb 11 18:51:07 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 11 18:50:59 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies References: <20050209040616.65CF71E400C@bag.python.org><7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> Message-ID: <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> > I don't really understand how your are doing the development. You have > to jump to a term window to run the script? I use xemacs as my editor. The main functionality used is the syntax colouring. It also has a menu bar plugin (IM-Python) that lists the classes and methods in the current file and lets you jump to them. And a seperate terminal window to run things in. I use this same setup on Windows, Linux and Mac. For a debugger I just place this wherever I need to have a deeper look at what is going on: import pdb ; pdb.set_trace() My wxPython code is hand coded. I haven't found any of the design tools to be much good for non-trivial projects. For example try doing something like the wxPython demo with one of them. They also don't work well if you have custom widgets, which is a lot of my UI. The single biggest factor for productivity I have found is how much screen space you have, preferably across two (or more) monitors. The more you can see and the more context you can have at once, the quicker you work and the less errors you make. It is really nice to have one place where you are writing code, one where you are looking at what you are calling, one for documentation and one for where the output of your program is. (I guess that is 4 monitors :-) Roger From bob at redivi.com Fri Feb 11 20:22:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 20:22:57 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: <008801c5105f$e2076480$3501a8c0@rogersqyvr14d3> References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> <006401c5105b$1a42f030$3501a8c0@rogersqyvr14d3> <008801c5105f$e2076480$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 11, 2005, at 12:34, Roger Binns wrote: >> Yeah, if you want to use a non-system Python with an extension built >> with the system Python there are some potential issues. > > Is there a page somewhere that actually explains what all this > terminology is about (eg Framework, alias bundles and similar). Framework, Application Bundle, etc. is all described at developer.apple.com. Alias bundle is py2app terminology, the only documentation I've written for it beyond what made it to this list and what's in --help is in the PyObjC tutorial: http://pyobjc.sourceforge.net/doc/tutorial.php Basically, an alias bundle is for development only, and is roughly similar in purpose to Xcode's ZeroLink feature. Instead of scanning your applications for dependencies, rewriting Mach-O headers, etc. it rigs an application bundle such that it runs directly out of your source directory and your development environment, making symlinks and aliases where necessary, so you can have a really quick edit/run cycle. You only have to build the alias bundle once, unless you add additional data files that need to be symlinked into the bundle. > I am used to the Python files and libraries just existing in a > conventional filesystem. Nothing complicated. All very trivial. > Multiple versions can be installed. A simple --prefix can move > where it is in ./configure. Each one is an island with no possibility > of sharing extensions or modifications between them. (That is a very > good thing - keeps it simple.) wxPython does have some dynamic > linking issues on Unix (it hard codes the path to the wxWidgets > directory at the ELF level, but chrpath fixes that.) Frameworks and application bundles are an extension to this concept. py2app operates at the Mach-O level (roughly equivalent to ELF) and automatically locates all link-time dependencies and does the equivalent of chrpath so that they work in the application bundle. >> This failure was probably due to the fact that you were not using >> py2app at the time. > > We used to use bundlebuilder. So it sounds like there is 99.999% > chance > we won't have to do seperate 10.4 builds. Unless we do things like > hook into SpotLight .... It's totally possible to build your software such that it detects the version of Mac OS X at runtime and enables/disables functionality. This is common practice. If you are using a Mac OS X 10.2 compiled version of PyObjC and you run it on Mac OS X 10.3, you will simply see more classes and new functionality on existing classes. The correct way to determine if the functionality exists is to simply see if the class is there or the class responds to new methods. -bob From bob at redivi.com Fri Feb 11 20:29:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 20:29:56 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> References: <20050209040616.65CF71E400C@bag.python.org><7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 11, 2005, at 12:51, Roger Binns wrote: >> I don't really understand how your are doing the development. You >> have to jump to a term window to run the script? > > I use xemacs as my editor. The main functionality used is the syntax > colouring. It also has a menu bar plugin (IM-Python) that lists the > classes and methods in the current file and lets you jump to them. > > And a seperate terminal window to run things in. I use this same > setup on Windows, Linux and Mac. For a debugger I just place this > wherever I need to have a deeper look at what is going on: > > import pdb ; pdb.set_trace() Use this instead: import pdb; pdb.Pdb().set_trace() It is more convenient in that you end up at the stack level you actually want to be at, rather than inside py2app. > The single biggest factor for productivity I have found is how > much screen space you have, preferably across two (or more) monitors. > The more you can see and the more context you can have > at once, the quicker you work and the less errors you make. It is > really nice to have one place where you are writing code, one > where you are looking at what you are calling, one for documentation > and one for where the output of your program is. (I guess that is > 4 monitors :-) Yeah, I use two 1600x1024 LCDs most of the time. I can also be pretty productive on my 15" laptop, where I just use 80 char wide terminal windows. I have been playing around with Desktop Manager (GPL) on the laptop in order to keep coding on one desktop and email/etc. on another. It seems to work pretty well, but I haven't used it enough to "get the hang of it" yet. -bob From bob at redivi.com Fri Feb 11 20:33:51 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 20:33:58 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <420CED1B.4030401@anvil.nrl.navy.mil> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> Message-ID: <50aea4c5c43cc563163eaf4085d500be@redivi.com> On Feb 11, 2005, at 12:36, Louis Pecora wrote: > Brendan Simons wrote: > >> The IDE thread is a recurring one. Here's my experience as another >> Python newbie. I tried SPE, PythonCard, PyOxice, PyPE, eclipse and >> wing (under x11). All work, but I found that each one had enough >> quirks (mostly UI inconsistencies, but some are downright unstable) >> that I was less productive than without. Not to sell any short, I'm >> sure they will get better given time. >> >> FWIW, the winning formula for me right now is: >> >> 1) Editor: TextWrangler (http://www.barebones.com/index.shtml). >> -Free, "Made For Mac", Code Colouring, Method Indexing, The ability >> to run scripts from the editor, More text manipulation options than I >> can count. >> >> 2) GuiEditor: XRCed.py (comes with the wxPython install package). >> (Or code the wxPython by hand, which takes longer, but gives you a >> little more control over the result). >> >> 3) And an instance of terminal running python interactive mode. >> Actually, this is the most valuable Python tool I've found so far - >> it's like a scratch pad where I can quickly check assumptions, or >> test out ideas. >> >> The only thing I'm missing now is a debugger with breakpoints, call >> stack, and variable watches. I'll have to settle for random print >> statements for now. > > > You didn't mention the regular Mac Python IDE (maybe you did and I > don't know it by the names you used). But it is pretty nice (no > syntax coloring is the most negative) on the other hand it has a > debugger that's very nice and easy to use. > But does it work with wxPython? I know some things (Tkinter, I think) > doesn't play nice with MacPython. The MacPython IDE runs all Python interpreters in-process and therefore can't run *any* GUI scripts/applications correctly using that feature. > I really like the ability to edit and just hit cmd-R to run the script. > The IDE could use some updating and wart removal. Syntax coloring, > better scrolling (that's damaged right now), use of scroll wheel (if > present), a few other interface changes. > > In the end it's my tool. > I don't really understand how your are doing the development. You > have to jump to a term window to run the script? The source code for the old MacPython IDE is extremely ancient and nobody has expressed interest in updating it... -bob From bob at redivi.com Fri Feb 11 21:26:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 11 21:26:49 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050209040616.65CF71E400C@bag.python.org><7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> Message-ID: <1b4c6a96ea5bdb0a7e3f28cd2865fda8@redivi.com> On Feb 11, 2005, at 14:29, Bob Ippolito wrote: > > On Feb 11, 2005, at 12:51, Roger Binns wrote: > >>> I don't really understand how your are doing the development. You >>> have to jump to a term window to run the script? >> >> I use xemacs as my editor. The main functionality used is the syntax >> colouring. It also has a menu bar plugin (IM-Python) that lists the >> classes and methods in the current file and lets you jump to them. >> >> And a seperate terminal window to run things in. I use this same >> setup on Windows, Linux and Mac. For a debugger I just place this >> wherever I need to have a deeper look at what is going on: >> >> import pdb ; pdb.set_trace() > > Use this instead: > > import pdb; pdb.Pdb().set_trace() > > It is more convenient in that you end up at the stack level you > actually want to be at, rather than inside py2app. Er.. rather than inside pdb.. ugh. -bob From Jack.Jansen at cwi.nl Fri Feb 11 23:24:32 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Feb 11 23:24:42 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5 for OS9 Release Candidate available Message-ID: Hot on the heels of 2.3.5 for 10.2 another installer is available for testing: MacPython 2.3.5 for MacOS9. Again, download it via As it is likely that this is the very last release of Python for classic MacOS, marking the end of Python on the platform on which it was originally implemented initially many years ago, I suggest that if you think you may ever again need Python on MacOS9 (or Python in the Classic environment on MacOSX) you want to give this installer a quick test. Also, there is some time pressure on getting the MacOS9 release right: the license for Installer Vise will expire within a month, and it would be silly to shell out another $1000 for another year. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Sat Feb 12 00:32:31 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Feb 12 00:32:45 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: <250f0482dc8e7e6e61d57b0724dd1c75@redivi.com> References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> <11784ef9dee718e4216b74f0213f1151@redivi.com> <250f0482dc8e7e6e61d57b0724dd1c75@redivi.com> Message-ID: <332369E6-7C85-11D9-8E7F-000D934FF6B4@cwi.nl> On 1-feb-05, at 2:09, Bob Ippolito wrote: >>> Unfortunately these patches need to be rewritten such that they >>> change the gensuitemodule scripts >> >> I think you mean bgen, yes?:) > > Yeah I mean bgen... I'm confusing the evil code generators Bob, I hope you realise that these "evil code generators" were written by Guido Himself (Our Beloved Leader, He Who Coded What No Man Coded Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-) My main tasks in the MacPython world have been: a) Keep those two working with new releases of Python b) Keep those two working with whatever new stuff Steve (Our Beloved Leader, He Who Designed What No Man Designed Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-) came up with. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Sat Feb 12 00:56:21 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 12 00:56:28 2005 Subject: bgen and gensuitemodule (was: [Pythonmac-SIG] How do you find the app that matches a creator type) In-Reply-To: <332369E6-7C85-11D9-8E7F-000D934FF6B4@cwi.nl> References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> <11784ef9dee718e4216b74f0213f1151@redivi.com> <250f0482dc8e7e6e61d57b0724dd1c75@redivi.com> <332369E6-7C85-11D9-8E7F-000D934FF6B4@cwi.nl> Message-ID: <529472706fdae3fa0e2658e922f39307@redivi.com> On Feb 11, 2005, at 18:32, Jack Jansen wrote: > On 1-feb-05, at 2:09, Bob Ippolito wrote: > >>>> Unfortunately these patches need to be rewritten such that they >>>> change the gensuitemodule scripts >>> >>> I think you mean bgen, yes?:) >> >> Yeah I mean bgen... I'm confusing the evil code generators > > Bob, I hope you realise that these "evil code generators" were written > by Guido Himself (Our Beloved Leader, He Who Coded What No Man Coded > Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-) > > My main tasks in the MacPython world have been: > a) Keep those two working with new releases of Python > b) Keep those two working with whatever new stuff Steve (Our Beloved > Leader, He Who Designed What No Man Designed Before, He Who Forever > Enlightens Our Path, etc etc etc etc etc:-) came up with. Just because they have holy origins doesn't make them any less evil :) Other than the difficultly in setting bgen up and getting used to the workflow, my main problem with it is that it is hard to make it understand callbacks, which are used a lot these days. I would like to see something like bgen end up generating ctypes and/or PyObjC's FFI support instead of C code, which would make callbacks much easier (if not automatic), and the edit/run cycle is faster. There's also a lot of metadata that could be stored about constants and functions that isn't (i.e. parsing comments and shoving them into doc strings or at least comments in the generated code). I think that some of bgen's parsing capabilities are going to fall apart when/if Universal Headers go away, because the new style headers use integer constants rather than four character codes in the cases where it is necessary to keep the source files as ASCII. Thomas Heller has been working on some interesting stuff with gcc-xml (argh) that automatically generates wrappers given C headers, and I've got some stuff in the PyObjC sandbox that does (will do) the same for Objective-C and a subset of C frameworks (I intend to wrap CoreFoundation and SystemPreferences with it, at least). Right now it mostly just tokenizes, but support is there to deal with #defines and externs, so I have been able to use it to wrap a lot of the "newer" Objective-C frameworks that don't have really tricky selectors or global functions. gensuitemodule has some pretty severe limitations, but I think that appscript is a suitable replacement... though I still use aeve in my product because I understand it, my requirements are simple, and it can do asynchronous events with PyObjC. -bob From hengist.podd at virgin.net Sat Feb 12 00:58:03 2005 From: hengist.podd at virgin.net (has) Date: Sat Feb 12 00:58:12 2005 Subject: [Pythonmac-SIG] How do you find the app that matches a creator type In-Reply-To: <332369E6-7C85-11D9-8E7F-000D934FF6B4@cwi.nl> References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> <11784ef9dee718e4216b74f0213f1151@redivi.com> <250f0482dc8e7e6e61d57b0724dd1c75@redivi.com> <332369E6-7C85-11D9-8E7F-000D934FF6B4@cwi.nl> Message-ID: Jack wrote: >>Yeah I mean bgen... I'm confusing the evil code generators > >Bob, I hope you realise that these "evil code generators" were >written by Guido Himself (Our Beloved Leader, He Who Coded What No >Man Coded Before, He Who Forever Enlightens Our Path, etc etc etc >etc etc:-) ... He Who Just Recently Proclaimed: "We Don' Need No Steenkin' Macros!!!!!" ;p >My main tasks in the MacPython world have been: >a) Keep those two working with new releases of Python >b) Keep those two working with whatever new stuff Steve (Our Beloved >Leader, He Who Designed What No Man Designed Before, He Who Forever >Enlightens Our Path, etc etc etc etc etc:-) came up with. Presumably though you're deprecating gensuitemodule and all its scruffy unwashed little friends as of MacPython 2.4? So if some tragic accident were to mysteriously befall them in 2.5 (something involving chainsaws might be nice) then perhaps you'll not be too sorry to see them go... >;) has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Sat Feb 12 01:30:51 2005 From: hengist.podd at virgin.net (has) Date: Sat Feb 12 01:31:12 2005 Subject: bgen and gensuitemodule (was: [Pythonmac-SIG] How do you find the app that matches a creator type) In-Reply-To: <529472706fdae3fa0e2658e922f39307@redivi.com> References: <0c8624e81eff2b995a7b3f0dff9c7eb2@redivi.com> <11784ef9dee718e4216b74f0213f1151@redivi.com> <250f0482dc8e7e6e61d57b0724dd1c75@redivi.com> <332369E6-7C85-11D9-8E7F-000D934FF6B4@cwi.nl> <529472706fdae3fa0e2658e922f39307@redivi.com> Message-ID: Bob wrote: >I think that some of bgen's parsing capabilities are going to fall >apart when/if Universal Headers go away, because the new style >headers use integer constants rather than four character codes in >the cases where it is necessary to keep the source files as ASCII. This wouldn't be why OSA.so is missing about half the OSA API, would it? (I've also found 2 broken functions so far.) I'd fill in the gaps by hand and submit a full patch, only there doesn't seem much point if it then needs rewritten again to bgenify it. >gensuitemodule has some pretty severe limitations, but I think that >appscript is a suitable replacement... Not a backwards-compatible replacement so while gsm, aetools, etc. are certainly ripe for a sound deprecating in 2.4 I don't think they could be banished outright just yet. Although I doubt there's very many legacy scripts that use gsm, aetools, etc., so if they do break any time thereafter then I don't think there'd be too much tears shed. >though I still use aeve in my product because I understand it, my >requirements are simple, and it can do asynchronous events with >PyObjC. I'm wide open to feature requests, criticisms, code reviews, etc. on aem. Especially aem.receive, which hasn't had much attention and is due for revision, though aem.send also needs assessed on more advanced features like asynchronous messaging, which is stuff you're a lot more familiar with than me. I would _really_ like to get its API and implementation locked down now, partly cos it's been dragging on for over a year now but also because I'd like to start flogging it to other language camps as a template to follow in bringing their own AE support up to scratch. (So far I've had a mention of interest from the Io camp and just run into a Lisper who might also be sellable on it. Plus I'd really like to approach Ruby, ObjC and Java folk as it could make some excellent killings there.) So any input at this point would be a serious help for me, and will be to everyone's benefit in the long run. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From brendansimons at yahoo.ca Sat Feb 12 05:01:07 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sat Feb 12 05:01:10 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <20050211233244.EA5841E400C@bag.python.org> References: <20050211233244.EA5841E400C@bag.python.org> Message-ID: <1a2e0eeb996c9ed442e0161643a4b443@yahoo.ca> On 11-Feb-05, at 6:32 PM, Lou Pecora wrote: > I don't really understand how your are doing the development. You > have to jump to a term window to run the script? > That was a big obstacle against many of the text editors I tried to use. TextWrangler, however, has good Python support, including cmd-r to run the present script. They've even written a parser for traceback, so when I get a runtime error, TW drops me right where I made the mistake. Handy. I used the Pythonmac IDE (forgot to list that), but as someone mentioned, it's incompatible with wx. From rogerb at rogerbinns.com Sat Feb 12 05:12:20 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Sat Feb 12 05:20:36 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <1b4c6a96ea5bdb0a7e3f28cd2865fda8@redivi.com> References: <20050209040616.65CF71E400C@bag.python.org><7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> <1b4c6a96ea5bdb0a7e3f28cd2865fda8@redivi.com> Message-ID: >>> import pdb ; pdb.set_trace() >> >> Use this instead: >> >> import pdb; pdb.Pdb().set_trace() >> >> It is more convenient in that you end up at the stack level you >> actually want to be at, rather than inside [pdb] Yes, but it is 4 more characters to type extra Pdb(). versus 'n' and return :-) Roger From bob at redivi.com Sat Feb 12 05:38:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 12 05:38:10 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050209040616.65CF71E400C@bag.python.org><7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> <1b4c6a96ea5bdb0a7e3f28cd2865fda8@redivi.com> Message-ID: <1e300f0a73670cb517ecbb11e6b21828@redivi.com> On Feb 11, 2005, at 11:12 PM, Roger Binns wrote: >>>> import pdb ; pdb.set_trace() >>> >>> Use this instead: >>> >>> import pdb; pdb.Pdb().set_trace() >>> >>> It is more convenient in that you end up at the stack level you >>> actually want to be at, rather than inside [pdb] > > Yes, but it is 4 more characters to type extra Pdb(). versus 'n' and > return :-) True, but if it's in application code, not at the interpreter, then you can easily make up for it in consecutive runs. try: do stuff except: import pdb pdb.post_mortem(sys.exc_info()[2]) is also useful.. Or, if you're running with python -i, there's pdb.pm() (which should really be a shortcut for the former in the general case) -bob From bob at redivi.com Sat Feb 12 07:12:40 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 12 07:12:53 2005 Subject: [Pythonmac-SIG] numarray 1.1.1 w/ vecLib (Apple's optimized implementation of BLAS) In-Reply-To: <36ba136af02db14383b039d8d229b2c8@redivi.com> References: <7bc3e10b96effd3f0bd7455b0912f42b@redivi.com> <36ba136af02db14383b039d8d229b2c8@redivi.com> Message-ID: <12f83e1f18a741b1e78e7cb9808d507e@redivi.com> Here's a numarray 1.1.1 installer for Mac OS X 10.3 (using the stock Python 2.3 interpreter), built with py2app 0.1.8 (svn trunk)'s bdist_mpkg command: http://undefined.org/python/numarray-1.1.1-py2.3-macosx10.3.zip (MD5: 6b4556e90adb813c7d7d369bfdaa037b) Patch to support vecLib in numarray is here: http://sourceforge.net/tracker/index.php? func=detail&aid=1121235&group_id=1369&atid=301369 More packages are here: http://undefined.org/python/packages.html -bob From michael.terry at mac.com Sat Feb 12 18:02:08 2005 From: michael.terry at mac.com (Michael Terry) Date: Sat Feb 12 18:02:01 2005 Subject: [Pythonmac-SIG] appscript Message-ID: Hi, I installed the appscript module. Can someone explain to me why the following script: #!/usr/bin/pythonw from appscript import * peopleRef = app('Address Book.app').people.filter(its.emails != []) print zip(peopleRef.name.get(), peopleRef.emails.value.get()) ... errors with: from: can't read /var/mail/appscript ... when one from the command line? Thanks, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 448 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050212/d3977fe6/attachment.bin From bob at redivi.com Sat Feb 12 19:00:00 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 12 19:00:05 2005 Subject: [Pythonmac-SIG] Zope py2app, some progress In-Reply-To: <008101c5105e$cbc6f0b0$3501a8c0@rogersqyvr14d3> References: <585c2de2c04088b613f69dcc90d66f71@conncoll.edu> <009f01c50f2b$a9771050$3501a8c0@rogersqyvr14d3> <0f07d77d65f8bed935c48ff96438d976@redivi.com> <000f01c50f3a$c91a7000$3501a8c0@rogersqyvr14d3> <002f01c50f45$5d7b7820$3501a8c0@rogersqyvr14d3> <006c01c50f4e$7b738080$3501a8c0@rogersqyvr14d3> <001101c51011$c991a120$3501a8c0@rogersqyvr14d3> <4ed6c9fa0e27f2c9a67d8f8d0222b060@redivi.com> <008101c5105e$cbc6f0b0$3501a8c0@rogersqyvr14d3> Message-ID: <3ec2966fecdb20b50e2c7adf94bb9cd3@redivi.com> On Feb 11, 2005, at 12:26 PM, Roger Binns wrote: >>> All the example code is in Objective C. Quite simply there is >>> far too steep a learning curve to get through these layers be >>> it Objective C or pseudo objects in C plus mapping into Python >>> land. >> Uh, no it isn't. A fair share of the IOKit examples are pure C or >> C++. > > Ok, more accurately the examples that were looking at hierarchies > are in Objective C. And I'm sure that working with IOKit, in C or > Objective C, once you have done it a few times is quick and easy. If > you haven't then a time investment is needed to understand the docs, > the examples, the types, actually write code that works, map it into > Python etc. There's a command-line application called ioreg that prints the hierarchy. It is written in C, so it's only using IOKit, CoreFoundation, and POSIX: http://www.opensource.apple.com/darwinsource/10.3.8/IOKitTools-38/ ioreg.tproj/ -bob From bob at redivi.com Sun Feb 13 01:04:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 13 01:04:13 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <420E904D.7090901@anvil.nrl.navy.mil> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <50aea4c5c43cc563163eaf4085d500be@redivi.com> <420E904D.7090901@anvil.nrl.navy.mil> Message-ID: <39c736da525cf1bfa4202fa52f271f39@redivi.com> On Feb 12, 2005, at 6:25 PM, Louis Pecora wrote: > Bob Ippolito wrote: > >>> I really like the ability to edit and just hit cmd-R to run the >>> script. >>> The IDE could use some updating and wart removal. Syntax coloring, >>> better scrolling (that's damaged right now), use of scroll wheel (if >>> present), a few other interface changes. >>> >>> In the end it's my tool. >>> I don't really understand how your are doing the development. You >>> have to jump to a term window to run the script? >> >> >> The source code for the old MacPython IDE is extremely ancient and >> nobody has expressed interest in updating it... > > Bob, Yeah I can see that, although for us non-guru python types who > just want a nice language to use it still is very nice. Sad that no > one will update it, but I realize all this stuff is on a volunteer > basis. In this particular case, fixing the MacPython IDE to use the newer Carbon conventions and facilities would more or less be a rewrite anyway, so people have expressed interest in writing an equivalent using Cocoa. One such effort is PyOXIDE, though it would be nice if more of it was written in Python. I've personally been working on software that would be extremely useful in the context of an IDE, such as an out-of-process GUI Python interpreter, loading code into remote processes, creating applications and plugins (py2app), determining dependencies (macholib/modulegraph), PyObjC, etc. but I'm not currently working on creating or directly improving any IDE because frankly, I'm generally more interested in the low level stuff and an IDE wouldn't really be all that useful to me most of the time. > Having said that I will lament what someone else on this list recently > said about python (he's new to the lingo and wants to use python > stuff), namely, everything seems scattered and now more so that the > IDE is decaying. What to replace it with? It'll be replaced when a suitable replacement exists. It's not yet clear what that replacement is, or when this will happen. > I know there are "solutions" since plenty of you are getting stuff > done in Python. However, for people like me the need to separately > install several packages just to get another one going is daunting, > especially since the dependencies are hard to decipher. I am not > complaining that the developers don't try to enlighten us, but since > the development is only loosely coordinated a sense of fragility > exists (at least for me) for any group of installed packages that have > to work together. It's absolutely true that it can currently be difficult to get a suite of packages installed if you don't already know what you're doing. That's part of the reason why I wrote bdist_mpkg. All it takes is one person to build a package and package it up, and then anyone else can just install it with a download and a few clicks. The process of creating a package with bdist_mpkg is as easy as the usual "sudo python setup.py install". Honestly, all you have to do (py2app svn) is type "bdist_mpkg --zipdist --open" in the same directory as setup.py and it will build the package, create a zip file of the package for redistribution, and open up the package with the Installer GUI. If you just want to install it, you can just type "bdist_mpkg" which will do the same, minus the creation of the zip file. Detection of or downloading dependencies for packages are not solved by this, largely because there IS NO STANDARD for declaring them (not even a de-facto one, though there is ongoing work in this area), so it is the "maintainers" job to do it by hand. However, it would be entirely possible to build an "Enthought Python" type distribution for Mac OS X using these facilities as-is. At least one person is interested in creating such a distribution , but it's not ready yet as far as I know. I am hosting several packages built using this system and that list will grow whenever I have the need or when someone else packages something and contributes it. I do, of course, reserve the right to stop maintaining this whenever I no longer have the time or interest to do so. Eventually a better system will exist, whether that's some combination of PackageManger and bdist_mpkg, or something else like Python Eggs . Unfortunately, for the most part, the people that are currently working on these systems don't really have an immediate need for them, so it's not an area of rapid development. > Where I'm going with this is that I am torn between my love for the > Python language (the best I've ever used) and my needs to get work > done (I do numerical work in my scientific research) without spending > a lot of time and energy maintaining the software environment. > I'm not sure how to cure this. If there is a cure. It may be endemic > to open source. I sense that for developers its just part of the job > and maybe even enjoyable while for potential users like me it is a sad > frustration. > > Just a view from the users' side. Thanks for letting me vent. Open source developers work on whatever they want or need to work on, so the particular problems you have will get solved when someone with the time, skill, and motivation to do so decides to scratch that itch. If you want to speed this process along, you have a few options: - Persuade a suitable developer to work on the problem areas you have (usually with money or a job) - Fix the problems you have yourself (hey, at least you CAN) - Deal with it as-is .. beggars can't be choosers :) -bob From jacob at jacobian.org Sun Feb 13 01:04:52 2005 From: jacob at jacobian.org (Jacob Kaplan-Moss) Date: Sun Feb 13 01:04:57 2005 Subject: [Pythonmac-SIG] appscript In-Reply-To: References: Message-ID: <6f64dd9f3402943a66c0eaeb6b70e68b@jacobian.org> On Feb 12, 2005, at 11:02 AM, Michael Terry wrote: > I installed the appscript module. Can someone explain to me why the > following script: > > #!/usr/bin/pythonw Michael -- It's because pythonw is a script itself; bash doesn't like #! lines to use other scripts. It's easily enough fixed, though; just use: #!/usr/bin/env pythonw and you should be fine. Jacob From rkern at ucsd.edu Sun Feb 13 11:30:58 2005 From: rkern at ucsd.edu (Robert Kern) Date: Sun Feb 13 11:31:06 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <39c736da525cf1bfa4202fa52f271f39@redivi.com> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <50aea4c5c43cc563163eaf4085d500be@redivi.com> <420E904D.7090901@anvil.nrl.navy.mil> <39c736da525cf1bfa4202fa52f271f39@redivi.com> Message-ID: <420F2C62.5030805@ucsd.edu> Bob Ippolito wrote: > However, it would be entirely > possible to build an "Enthought Python" type distribution for Mac OS X > using these facilities as-is. At least one person is interested in > creating such a distribution > , but it's not > ready yet as far as I know. All the packages in the main list build and install cleanly. Now I'm working on packaging up the documentation for each package, and unfortunately, Real Life annoyances are taking up too much time. Maybe next week there will be a beta release. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jschull at digitalgoods.com Sun Feb 13 15:23:30 2005 From: jschull at digitalgoods.com (Jon Schull) Date: Sun Feb 13 15:23:37 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <20050213110004.D88841E400B@bag.python.org> References: <20050213110004.D88841E400B@bag.python.org> Message-ID: <56614e190843db689537582fe99e63bd@digitalgoods.com> > Open source developers work on whatever they want or need to work on, > so the particular problems you have will get solved when someone with > the time, skill, and motivation to do so decides to scratch that itch. > If you want to speed this process along, you have a few options: > > - Persuade a suitable developer to work on the problem areas you have > (usually with money or a job) > - Fix the problems you have yourself (hey, at least you CAN) > - Deal with it as-is > > .. beggars can't be choosers :) > > -bob [ comment in the context of distribution packages but it applies > to the discussion of IDE chaos as well]. My comment: (1) In this business, beggars do choose, and they vote with their feet. If a beginner-friendly IDE is not an interesting problem for cognoscenti, the python foundation (or some such) should step in, or the python community should consider the possibility that the demographics of the development community is in danger of ceding the next generation... On Feb 13, 2005, at 6:00 AM, pythonmac-sig-request@python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request@python.org > > You can reach the person managing the list at > pythonmac-sig-owner@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > Today's Topics: > > 1. appscript (Michael Terry) > 2. Re: Zope py2app, some progress (Bob Ippolito) > 3. Re: Mac User Python Newbies (Bob Ippolito) > 4. Re: appscript (Jacob Kaplan-Moss) > 5. Re: Mac User Python Newbies (Robert Kern) > > From: Michael Terry > Date: February 12, 2005 12:02:08 PM EST > To: pythonmac-sig@python.org > Subject: [Pythonmac-SIG] appscript > > > Hi, > > I installed the appscript module. Can someone explain to me why the > following script: > > #!/usr/bin/pythonw > > from appscript import * > > peopleRef = app('Address Book.app').people.filter(its.emails != []) > print zip(peopleRef.name.get(), peopleRef.emails.value.get()) > > ... errors with: > > from: can't read /var/mail/appscript > > ... when one from the command line? > > Thanks, > Mike > > > From: Bob Ippolito > Date: February 12, 2005 1:00:00 PM EST > To: "Roger Binns" > Cc: Pythonmac-SIG@python.org > Subject: Re: [Pythonmac-SIG] Zope py2app, some progress > > > > On Feb 11, 2005, at 12:26 PM, Roger Binns wrote: > >>>> All the example code is in Objective C. Quite simply there is >>>> far too steep a learning curve to get through these layers be >>>> it Objective C or pseudo objects in C plus mapping into Python >>>> land. >>> Uh, no it isn't. A fair share of the IOKit examples are pure C or >>> C++. >> >> Ok, more accurately the examples that were looking at hierarchies >> are in Objective C. And I'm sure that working with IOKit, in C or >> Objective C, once you have done it a few times is quick and easy. If >> you haven't then a time investment is needed to understand the docs, >> the examples, the types, actually write code that works, map it into >> Python etc. > > There's a command-line application called ioreg that prints the > hierarchy. It is written in C, so it's only using IOKit, > CoreFoundation, and POSIX: > > http://www.opensource.apple.com/darwinsource/10.3.8/IOKitTools-38/ > ioreg.tproj/ > > -bob > > > > > > From: Bob Ippolito > Date: February 12, 2005 7:04:03 PM EST > To: Louis Pecora > Cc: PythonMac > Subject: Re: [Pythonmac-SIG] Mac User Python Newbies > > > > On Feb 12, 2005, at 6:25 PM, Louis Pecora wrote: > >> Bob Ippolito wrote: >> >>>> I really like the ability to edit and just hit cmd-R to run the >>>> script. >>>> The IDE could use some updating and wart removal. Syntax coloring, >>>> better scrolling (that's damaged right now), use of scroll wheel >>>> (if present), a few other interface changes. >>>> >>>> In the end it's my tool. >>>> I don't really understand how your are doing the development. You >>>> have to jump to a term window to run the script? >>> >>> >>> The source code for the old MacPython IDE is extremely ancient and >>> nobody has expressed interest in updating it... >> >> Bob, Yeah I can see that, although for us non-guru python types who >> just want a nice language to use it still is very nice. Sad that no >> one will update it, but I realize all this stuff is on a volunteer >> basis. > > In this particular case, fixing the MacPython IDE to use the newer > Carbon conventions and facilities would more or less be a rewrite > anyway, so people have expressed interest in writing an equivalent > using Cocoa. One such effort is PyOXIDE, though it would be nice if > more of it was written in Python. > > I've personally been working on software that would be extremely > useful in the context of an IDE, such as an out-of-process GUI Python > interpreter, loading code into remote processes, creating applications > and plugins (py2app), determining dependencies (macholib/modulegraph), > PyObjC, etc. but I'm not currently working on creating or directly > improving any IDE because frankly, I'm generally more interested in > the low level stuff and an IDE wouldn't really be all that useful to > me most of the time. > >> Having said that I will lament what someone else on this list >> recently said about python (he's new to the lingo and wants to use >> python stuff), namely, everything seems scattered and now more so >> that the IDE is decaying. What to replace it with? > > It'll be replaced when a suitable replacement exists. It's not yet > clear what that replacement is, or when this will happen. > >> I know there are "solutions" since plenty of you are getting stuff >> done in Python. However, for people like me the need to separately >> install several packages just to get another one going is daunting, >> especially since the dependencies are hard to decipher. I am not >> complaining that the developers don't try to enlighten us, but since >> the development is only loosely coordinated a sense of fragility >> exists (at least for me) for any group of installed packages that >> have to work together. > > It's absolutely true that it can currently be difficult to get a suite > of packages installed if you don't already know what you're doing. > > That's part of the reason why I wrote bdist_mpkg. All it takes is one > person to build a package and package it up, and then anyone else can > just install it with a download and a few clicks. The process of > creating a package with bdist_mpkg is as easy as the usual "sudo > python setup.py install". Honestly, all you have to do (py2app svn) > is type "bdist_mpkg --zipdist --open" in the same directory as > setup.py and it will build the package, create a zip file of the > package for redistribution, and open up the package with the Installer > GUI. If you just want to install it, you can just type "bdist_mpkg" > which will do the same, minus the creation of the zip file. > > Detection of or downloading dependencies for packages are not solved > by this, largely because there IS NO STANDARD for declaring them (not > even a de-facto one, though there is ongoing work in this area), so it > is the "maintainers" job to do it by hand. However, it would be > entirely possible to build an "Enthought Python" type distribution for > Mac OS X using these facilities as-is. At least one person is > interested in creating such a distribution > , but it's not > ready yet as far as I know. I am hosting several packages built using > this system and that list > will grow whenever I have the need or when someone else packages > something and contributes it. I do, of course, reserve the right to > stop maintaining this whenever I no longer have the time or interest > to do so. > > Eventually a better system will exist, whether that's some combination > of PackageManger and bdist_mpkg, or something else like Python Eggs > . Unfortunately, > for the most part, the people that are currently working on these > systems don't really have an immediate need for them, so it's not an > area of rapid development. > >> Where I'm going with this is that I am torn between my love for the >> Python language (the best I've ever used) and my needs to get work >> done (I do numerical work in my scientific research) without spending >> a lot of time and energy maintaining the software environment. >> I'm not sure how to cure this. If there is a cure. It may be >> endemic to open source. I sense that for developers its just part of >> the job and maybe even enjoyable while for potential users like me it >> is a sad frustration. >> >> Just a view from the users' side. Thanks for letting me vent. > > Open source developers work on whatever they want or need to work on, > so the particular problems you have will get solved when someone with > the time, skill, and motivation to do so decides to scratch that itch. > If you want to speed this process along, you have a few options: > > - Persuade a suitable developer to work on the problem areas you have > (usually with money or a job) > - Fix the problems you have yourself (hey, at least you CAN) > - Deal with it as-is > > .. beggars can't be choosers :) > > -bob > > > > > > From: Jacob Kaplan-Moss > Date: February 12, 2005 7:04:52 PM EST > To: pythonmac-sig@python.org > Cc: Subject: Re: [Pythonmac-SIG] appscript > > > On Feb 12, 2005, at 11:02 AM, Michael Terry wrote: >> I installed the appscript module. Can someone explain to me why the >> following script: >> >> #!/usr/bin/pythonw > > Michael -- > > It's because pythonw is a script itself; bash doesn't like #! lines to > use other scripts. It's easily enough fixed, though; just use: > > #!/usr/bin/env pythonw > > and you should be fine. > > Jacob > > > > > > From: Robert Kern > Date: February 13, 2005 5:30:58 AM EST > To: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] Mac User Python Newbies > > > Bob Ippolito wrote: >> However, it would be entirely possible to build an "Enthought Python" >> type distribution for Mac OS X using these facilities as-is. At >> least one person is interested in creating such a distribution >> , but it's not >> ready yet as far as I know. > > All the packages in the main list build and install cleanly. Now I'm > working on packaging up the documentation for each package, and > unfortunately, Real Life annoyances are taking up too much time. Maybe > next week there will be a beta release. > > -- > Robert Kern > rkern@ucsd.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull@digitalgoods.com 585-738-6696 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 12595 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050213/5802a461/attachment.bin From troy.rollins at gmail.com Sun Feb 13 16:59:10 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Sun Feb 13 16:59:14 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <56614e190843db689537582fe99e63bd@digitalgoods.com> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> Message-ID: <31ac537c050213075917334f61@mail.gmail.com> > > .. beggars can't be choosers :) > > > > -bob [ comment in the context of distribution packages but it applies > > to the discussion of IDE chaos as well]. > > My comment: > > (1) In this business, beggars do choose, and they vote with their > feet. If a beginner-friendly IDE is not an interesting problem for > cognoscenti, the python foundation (or some such) should step in, or > the python community should consider the possibility that the > demographics of the development community is in danger of ceding the > next generation... I for one, don't care to think of myself in the context of "begger", but more so in the context of uninitiated contributor. If developers, new to python, have a barrier to entry, they may well walk of to Ruby, or Lua... etc. At some point, I'd like to be contributing to the effort, but just getting off the ground is a bit daunting. Obviously, it is doable, since lots of folks work in it every day, but how many have peaked in and turned and left without saying a word? Out of that number, how many may have evolved into providing some contribution? It isn't up to the members of this list to fix, or at least isn't a "responsibility", but it is an issue which also shouldn't simply be dismissed, I think. I think if there is some governing body for Python, it should very much be paying attention to this issue, and recognizing that it is perhaps one of the most important aspects of maintaining and furthering the language... new developers. Many of which would prefer to get started (at least) within the relative controlled environment of an IDE. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From mwh at python.net Sun Feb 13 17:12:13 2005 From: mwh at python.net (Michael Hudson) Date: Sun Feb 13 17:12:14 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <31ac537c050213075917334f61@mail.gmail.com> (Troy Rollins's message of "Sun, 13 Feb 2005 10:59:10 -0500") References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> Message-ID: <2msm4030de.fsf@starship.python.net> Troy Rollins writes: > I for one, don't care to think of myself in the context of "begger", > but more so in the context of uninitiated contributor. If developers, > new to python, have a barrier to entry, they may well walk of to Ruby, > or Lua... etc. At some point, I'd like to be contributing to the > effort, but just getting off the ground is a bit daunting. I may be missing details from earlier posts, but what is currently daunting you? Have you looked at the Python tutorial or the PyObjC tutorial, to pick two simple examples? > Obviously, it is doable, since lots of folks work in it every day, > but how many have peaked in and turned and left without saying a > word? Out of that number, how many may have evolved into providing > some contribution? It isn't up to the members of this list to fix, > or at least isn't a "responsibility", but it is an issue which also > shouldn't simply be dismissed, I think. I hope you don't get the idea that this is being dismissed. > I think if there is some governing body for Python, it should very > much be paying attention to this issue, and recognizing that it is > perhaps one of the most important aspects of maintaining and > furthering the language... new developers. Many of which would > prefer to get started (at least) within the relative controlled > environment of an IDE. However, it probably is a good deal less effort to explain to newcomers how to get going without an IDE thatn to write one. Especially writing an IDE that would be noticeably more correct than my current Emacs/Terminal/interactive Python setup. Cheers, mwh -- Lisp nearing the age of 50 is the most modern language out there. GC, dynamic, reflective, the best OO model extant including GFs, procedural macros, and the only thing old-fashioned about it is that it is compiled and fast. -- Kenny Tilton, comp.lang.python From meitnik at bellsouth.net Sun Feb 13 17:34:03 2005 From: meitnik at bellsouth.net (Andrew Meit) Date: Sun Feb 13 17:37:03 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <20050213155914.884351E400D@bag.python.org> References: <20050213155914.884351E400D@bag.python.org> Message-ID: On Feb 13, 2005, at 10:59 AM, Troy wrote: > I for one, don't care to think of myself in the context of "begger", > but more so in the context of uninitiated contributor. If developers, > new to python, have a barrier to entry, they may well walk of to Ruby, > or Lua... etc. At some point, I'd like to be contributing to the > effort, but just getting off the ground is a bit daunting. Obviously, > it is doable, since lots of folks work in it every day, but how many > have peaked in and turned and left without saying a word? Out of that > number, how many may have evolved into providing some contribution? It > isn't up to the members of this list to fix, or at least isn't a > "responsibility", but it is an issue which also shouldn't simply be > dismissed, I think. I think if there is some governing body for > Python, it should very much be paying attention to this issue, and > recognizing that it is perhaps one of the most important aspects of > maintaining and furthering the language... new developers. Many of > which would prefer to get started (at least) within the relative > controlled environment of an IDE. -- Amen. I am tried of being told how great a language is when the IDE tools for it is not finished or stable, or welcomes a newbie well. Over the many years in computer industry, I have seen this subtle approach of forcing newbies into a rite of passage to master a tool. Its childish and doesn't serve well growing the installed base. Andrew -{Choose Life, Create hope, Nurture Love...}- From mwh at python.net Sun Feb 13 17:44:03 2005 From: mwh at python.net (Michael Hudson) Date: Sun Feb 13 17:44:05 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: (Andrew Meit's message of "Sun, 13 Feb 2005 11:34:03 -0500") References: <20050213155914.884351E400D@bag.python.org> Message-ID: <2moeeo2ywc.fsf@starship.python.net> Andrew Meit writes: > On Feb 13, 2005, at 10:59 AM, Troy wrote: > >> I for one, don't care to think of myself in the context of "begger", >> but more so in the context of uninitiated contributor. If developers, >> new to python, have a barrier to entry, they may well walk of to Ruby, >> or Lua... etc. At some point, I'd like to be contributing to the >> effort, but just getting off the ground is a bit daunting. Obviously, >> it is doable, since lots of folks work in it every day, but how many >> have peaked in and turned and left without saying a word? Out of that >> number, how many may have evolved into providing some contribution? It >> isn't up to the members of this list to fix, or at least isn't a >> "responsibility", but it is an issue which also shouldn't simply be >> dismissed, I think. I think if there is some governing body for >> Python, it should very much be paying attention to this issue, and >> recognizing that it is perhaps one of the most important aspects of >> maintaining and furthering the language... new developers. Many of >> which would prefer to get started (at least) within the relative >> controlled environment of an IDE. > > -- Amen. I am tried of being told how great a language is when the IDE > tools for it is not finished or stable, My claim would rather be that "the IDE" is not *necessary*... Cheers, mwh -- Gevalia is undrinkable low-octane see-through only slightly roasted bilge water. Compared to .us coffee it is quite drinkable. -- M?ns Nilsson, asr From troy.rollins at gmail.com Sun Feb 13 18:01:52 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Sun Feb 13 18:01:57 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <2msm4030de.fsf@starship.python.net> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> Message-ID: <31ac537c05021309011afe2087@mail.gmail.com> On Sun, 13 Feb 2005 16:12:13 +0000, Michael Hudson wrote: > Troy Rollins writes: > > > I for one, don't care to think of myself in the context of "begger", > > but more so in the context of uninitiated contributor. If developers, > > new to python, have a barrier to entry, they may well walk of to Ruby, > > or Lua... etc. At some point, I'd like to be contributing to the > > effort, but just getting off the ground is a bit daunting. > > I may be missing details from earlier posts, but what is currently > daunting you? Have you looked at the Python tutorial or the PyObjC > tutorial, to pick two simple examples? > Well, I've transitioned between tools like Director, REALbasic, and Revolution, and extremely quickly moved into creating non-trivial applications. With Python, it is far less condusive to "playing" and therefore seems to hold me somewhere around the print "hello world" stage. Yes, I've look at the cited examples... perhaps they simply didn't connect with me on the right level. Python stuff always seems to be written from the perspective of "ok, you are starting from a lower level language", but many of us are probably coming from the other direction ? a higher level language... Lingo, REALbasic, etc. It would seem to me that the transition to Python should be easy, but perhaps I just haven't yet encountered the right materials. I just received 3 books on Python from Amazon. Every one of them starts with the line "this book does not teach you to program in Python, and assumes you already know how to do that." Perhaps it is just my own dumb luck, but that is the angle most web materials take as well in my experience. OR, it is print "hello world". I'm pretty committed to learning this, but I'm somewhat surprised at how much productivity I have to throw away in order to do it. Many would say "well, that's free software for you." But, I'm not interested in the "free" part. Free is not what is important to me. Frankly, I'd rather pay for something productive. My time is worth WAY more than whatever a decent tool would cost. The part that interests me is open source, and "future-proofing." To me, "free" translates to "loss of productivity." I'm not a hobbyist, and I'm not looking to Python as something to use "outside of my day job." I make my living with tools like this, and have a staff that does as well. Please don't interpret any of my comments as saying anything bad about list members, contributors, or Python. That isn't the intent at all. I do realize that these things take time, that Python is free and open-source, and that only I am responsible for my ability to use it, and choice to do so. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From sw at wordtech-software.com Sun Feb 13 18:10:47 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Feb 13 18:10:50 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: <20050213155914.A151F1E400E@bag.python.org> References: <20050213155914.A151F1E400E@bag.python.org> Message-ID: <420F8A17.90407@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | | ------------------------------------------------------------------------ | | Subject: | Re: [Pythonmac-SIG] Mac User Python Newbies | From: | Troy Rollins | Date: | Sun, 13 Feb 2005 10:59:10 -0500 | To: | pythonmac-sig@python.org | | To: | pythonmac-sig@python.org | | |>>.. beggars can't be choosers :) |>> |>>-bob [ comment in the context of distribution packages but it applies |>>to the discussion of IDE chaos as well]. |> |>My comment: |> |>(1) In this business, beggars do choose, and they vote with their |>feet. If a beginner-friendly IDE is not an interesting problem for |>cognoscenti, the python foundation (or some such) should step in, or |>the python community should consider the possibility that the |>demographics of the development community is in danger of ceding the |>next generation... | | | I for one, don't care to think of myself in the context of "begger", | but more so in the context of uninitiated contributor. If developers, | new to python, have a barrier to entry, they may well walk of to Ruby, | or Lua... etc. At some point, I'd like to be contributing to the | effort, but just getting off the ground is a bit daunting. Obviously, | it is doable, since lots of folks work in it every day, but how many | have peaked in and turned and left without saying a word? Out of that | number, how many may have evolved into providing some contribution? It | isn't up to the members of this list to fix, or at least isn't a | "responsibility", but it is an issue which also shouldn't simply be | dismissed, I think. I think if there is some governing body for | Python, it should very much be paying attention to this issue, and | recognizing that it is perhaps one of the most important aspects of | maintaining and furthering the language... new developers. Many of | which would prefer to get started (at least) within the relative | controlled environment of an IDE. | One of the things I've observed with Python is that there's an almost overwhelming embarassment of riches when it comes to free and/or open-source IDE's, developer tools, etc. I maintain two such environments myself on the Mac--SPE (Stani's Python Editor), which is built on wxPython, and Eric3, which is built on PyQt. Both have editors, debuggers, etc. integrated, and also ship with GUI builders (wxGlade for SPE, and Qt Designer for PyQt). Some users still find SPE a bit buggy: I haven't found it unreasonably so, but I do try to investigate, respond to, and help resolve such issues when I'm able. Eric3 is a different issue: it's very polished and powerful. And there's no issue with stablity or polish with Qt Designer, as it's a (highly expensive) commercial tool released freely for open-source development. The main drawback to PyQt, of course, is the license if you dislike the GPL. Yet another polished developer environment is PyObjC. I haven't done any work with this in Python, but having used a lot of these tools with AppleScript Studio, they are first-rate: again very powerful commercial tools that ship free with the Mac. Even IDLE, which is a bit ugly on the Mac, is very usable, and much simpler to get started with than a full-blown IDE. I have found it very good for editing scripts, testing things out, and learning. IDLE *is* maintained by the Python Foundation itself. So, I think they are meeting the obligation that you say they have. (I wish that the Tcl core team had something similar to IDLE.) And PyOxide also seems to be a very polished and Mac-friendly Python editor, though I haven't used it extensively. The extent of developer tools and environments in Python, is, in fact, a considerable obstacle to the newbie. After getting my feet wet in programming with AppleScript, I was choosing between Tcl and Python as my next language to try. I chose Tcl to start with because, although it has an almost *complete* lack of polished tools (no usable GUI builders, no decent IDE's available on the Mac), it is a smaller language with a relatively straightforward path to competence. Want to build GUI's? Learn Tk. Which tool to write code with? Since there are no standard editors, pick the one you like (Emacs + terminal is what I use). I've got two open-source Tcl/Tk apps under development right now, after studying the language for about six months. I wouldn't be this productive had I started with Python, and that's no criticism of Python, merely an observation on the size of the langauge environment: the langauge itself may not be too hard to learn, but navigating the various ~ GUI toolkit options certainly is. I decided to get involved with Python on the packaging side because I thought it might provide a way to sample the different GUI toolkits without getting lost: plus, I was also interested in some of the IDE's that seemed to be popular on other platforms that could also run on the Mac but weren't available. After working with both PyQt and wxPython, I feel a little more comfortable with wx, and have actually contributed some Mac-specific patches to SPE and wxGlade. (I find wxPython's model to be reasonably close to Tk-style callbacks, and easier to understand: I can't get my head around Qt signals and slots.) After my Tk applications get to a certain point (i.e., released), I will probably delve into a wxPython project of my own along with trying to help improve SPE and/or wxGlade. I have to agree with Bob: open-source development is rarely going to be as polished, coherent and steady as commercial development. For the most part, it's developer-driven, not market-driven. If you're used to slick commercial tools like those from Macromedia or Revolution Runtime, you won't find a lot of that in any open-source language. (Footnote one: In fact, Python is exceptional in this regard: PyObjC, PyQt, etc. leverage commercial tools in a brilliant way. Qt Designer and Interface Builder are very slick drag-and-drop GUI builders. ) (Footnote two: ActiveState makes a commercial IDE for open-source languages, including Python, called Komodo: it's available for Windows and various Nixes, but not for the Mac. The only reason I can think of for this is market strategy, as Komodo is built on top of Mozilla; there's no reason that it shouldn't run on the Mac. So perhaps you should also lobby ActiveState to bring out Komodo-Mac.) I say all this as someone who is *not* a professional programmer, and still should be counted as a Python newbie. So I can definitely sympathize with your perspective. Let me conclude with a question: what *should* be in a newbie-friendly Python IDE? If you were writing one, what would you like to see in it? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCD4oXJmdQs+6YVcoRArylAJ9gyRHtxqjhEMv4HIygKUyWV9QngwCfUDMd YNvdXdRDOgDOqvM/FZsGMBo= =kJ+g -----END PGP SIGNATURE----- From troy.rollins at gmail.com Sun Feb 13 18:30:43 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Sun Feb 13 18:30:46 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: <420F8A17.90407@wordtech-software.com> References: <20050213155914.A151F1E400E@bag.python.org> <420F8A17.90407@wordtech-software.com> Message-ID: <31ac537c05021309309146b71@mail.gmail.com> > > Let me conclude with a question: what *should* be in a newbie-friendly > Python IDE? If you were writing one, what would you like to see in it? Well, that is a good point. I suppose everyone will have a differing opinion on that, particularly in terms of goals. For me, I'd like to see a single package, which includes a GUI designer, script editor with colorizing, debugger, interactive console, some sort of module browser for functions and syntax, resource viewer, something similar to package manager... and a basic set of modules for x-plat development work. Then, some tool which helps to output the whole thing as a runtime package. I realize that is asking a lot. I really do. I also think that there is money to be made by the company or person who delivers something like that... providing it is pretty tight and cohesive. I've tried the ones that have been mentioned. They all work pretty buggy in my experience. (Not PyObjC or PyQt... those I have not tried.) -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From mwh at python.net Sun Feb 13 18:47:48 2005 From: mwh at python.net (Michael Hudson) Date: Sun Feb 13 18:47:50 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <31ac537c05021309011afe2087@mail.gmail.com> (Troy Rollins's message of "Sun, 13 Feb 2005 12:01:52 -0500") References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> Message-ID: <2mk6pc2vy3.fsf@starship.python.net> Troy Rollins writes: > On Sun, 13 Feb 2005 16:12:13 +0000, Michael Hudson wrote: >> Troy Rollins writes: >> >> > I for one, don't care to think of myself in the context of "begger", >> > but more so in the context of uninitiated contributor. If developers, >> > new to python, have a barrier to entry, they may well walk of to Ruby, >> > or Lua... etc. At some point, I'd like to be contributing to the >> > effort, but just getting off the ground is a bit daunting. >> >> I may be missing details from earlier posts, but what is currently >> daunting you? Have you looked at the Python tutorial or the PyObjC >> tutorial, to pick two simple examples? >> > > Well, I've transitioned between tools like Director, REALbasic, and > Revolution, Well, I've used exactly none of those, but let's see what I can do... :-) > and extremely quickly moved into creating non-trivial > applications. With Python, it is far less condusive to "playing" Well, I think this is a subjective judgement -- a matter of familiarity. I "play" with Python all the time. A good start is to enhance your interactive experience somewhat. Three options spring to mind: 1) Get readline support working. If you're still using Apple's Python, get bbum's readline.so from http://homepage.mac.com/bbum/BumFiles/FileSharing27.html (is this still the right link?), then add lines like try: import rlcompleter, readline readline.parse_and_bind("tab: complete") except ImportError: pass to a file called something link ~/.pythonrc and point the PYTHONSTARTUP environment variable to it (yikes, this is a bit involved...). Then if you want to see what functions a module supports you can do: >>> import urllib2 >>> urllib2.url urllib2.url2pathname urllib2.urlopen urllib2.urlparse and so on: >>> data = urllib2.urlopen('http://www.google.com').read() >>> data[:10] ' and therefore seems to hold me somewhere around the print "hello > world" stage. Well, what would you like to do? :) It's often hard to know what to do with a funky new toy as flexible as Python... > Yes, I've look at the cited examples... perhaps they simply didn't > connect with me on the right level. Well, for some not-exactly-instant-but-quick gratification, I'd consider playing with PyObjC -- maybe writing a simple image viewer or something -- though this would involve more time learning about Coca that Python in all likelyhood. > Python stuff always seems to be written from the perspective of "ok, > you are starting from a lower level language", This is probably a fair comment. It's certainly the direction I arrived at Python from... > but many of us are probably coming from the other direction ? a > higher level language... Lingo, REALbasic, etc. It would seem to me > that the transition to Python should be easy, but perhaps I just > haven't yet encountered the right materials. I would also offer the advice to stop worrying about materials, probably. Pick a (possibly toy) problem and have at it :) > I just received 3 books on Python from Amazon. Every one of them > starts with the line "this book does not teach you to program in > Python, and assumes you already know how to do that." Perhaps it is > just my own dumb luck, but that is the angle most web materials take > as well in my experience. OR, it is print "hello world". Uh, really? Certainly a lot of books assume you know how to program. If you don't know that, there's "How to Think Like a Computer Scientist", urm, hmm... have you read this page: http://www.python.org/moin/BeginnersGuide I was going to copy and paste various stuff from there but I'm not sure there's a lot of point -- but this section Next, you're going to want to read a tutorial and try some simple experiments with your new Python interpreter. If you've never programmed before, see BeginnersGuide/NonProgrammers. If you have previous programming experience, consult BeginnersGuide/Programmers, which lists more advanced tutorials. seems appropriate. > I'm pretty committed to learning this, but I'm somewhat surprised at > how much productivity I have to throw away in order to do it. Many > would say "well, that's free software for you." But, I'm not > interested in the "free" part. Free is not what is important to me. > Frankly, I'd rather pay for something productive. If you're prepared to sling money around there are people and companies who do Python training, although I don't know much more than that. Googling for 'python training' looks optimistic :) > My time is worth WAY more than whatever a decent tool would > cost. The part that interests me is open source, and > "future-proofing." To me, "free" translates to "loss of > productivity." I'm not a hobbyist, and I'm not looking to Python as > something to use "outside of my day job." I make my living with > tools like this, and have a staff that does as well. I have to admit that I am still a little unclear what you are looking to do with Python (other than make money :). If it's like the little apps that I get on mostly-audio CDs that play videos at me, then such is almost certainly possible in Python, though it would take much longer to write your first few in Python that in Director -- one assumes macromedia have actually been doing something will all the dollars you've been heaving at them over the last few years. But I'd also be confident that with a bit of experience at it, you could make a framework that would make it just as easy. > Please don't interpret any of my comments as saying anything bad about > list members, contributors, or Python. That isn't the intent at all. I > do realize that these things take time, that Python is free and > open-source, and that only I am responsible for my ability to use it, > and choice to do so. Conversely, please don't take my response as being too defensive -- it would be disingenuous to suggest that all is perfect over here in Python land. In particular, I'm not aware of any materials for people arriving at Python from Director/REALbasic, etc. But there are a lot of people willing to answer questions, and some pretty damn good stuff to use already. Cheers, mwh -- Exam invigilation - it doesn't come much harder than that, esp if the book you're reading turns out to be worse than expected. -- Dirk Bruere, sci.physics.research From sw at wordtech-software.com Sun Feb 13 19:14:16 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Feb 13 19:14:18 2005 Subject: [Pythonmac-SIG] Re: Mac newbie Message-ID: <420F98F8.5040906@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |Let me conclude with a question: what *should* be in a newbie-friendly |> Python IDE? If you were writing one, what would you like to see in it? |>Well, that is a good point. I suppose everyone will have a differing |>opinion on that, particularly in terms of goals. For me, I'd like to |>see a single package, which includes a GUI designer, script editor |>with colorizing, debugger, interactive console, some sort of module |>browser for functions and syntax, resource viewer, something similar |>to package manager... and a basic set of modules for x-plat |>development work. Then, some tool which helps to output the whole |>thing as a runtime package. |>I realize that is asking a lot. I really do. I also think that there |>is money to be made by the company or person who delivers something |>like that... providing it is pretty tight and cohesive. This sounds like "PyRev" to me. :-) Seriously, Revolution is the only environment that I'm aware of that provides all of this stuff in a cross-platform context. Packaging solutions are usually platform specific (i.e. py2exe vs. py2app). Also, which GUI toolkit would such an IDE use? Komodo provides nearly all of the functionality you've described, even a GUI builder--though it's Tk, which may or may not be to your taste. But still, ActiveState has not yet seen fit to bring it to the Mac. I hereby renew my suggestion to lobby them. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCD5j3JmdQs+6YVcoRAprnAJ9EzKEXO2jCukJt6NkTUXuWeArFoACgh9z3 mTWxT9AYY9AhYy6pnfNUqGk= =ntZF -----END PGP SIGNATURE----- From arthur at iaaa.nl Sun Feb 13 19:19:09 2005 From: arthur at iaaa.nl (Arthur Elsenaar) Date: Sun Feb 13 19:19:16 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <31ac537c05021309011afe2087@mail.gmail.com> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> Message-ID: <37c5dd2a71b212c192f5ea4af8db2915@iaaa.nl> On Feb 13, 2005, at 17:01, Troy Rollins wrote: > Well, I've transitioned between tools like Director, REALbasic, and > Revolution, and extremely quickly moved into creating non-trivial > applications. With Python, it is far less condusive to "playing" and > therefore seems to hold me somewhere around the print "hello world" > stage. I didn't follow this thread from the beginning, but did anyone bring up PythonCard? I also previously used REALbasic and also have some Proce55ing experience. I did struggle to get started with Python, but PythonCard that is based on wxPython got me going. The PythonCard folks have the intention to make Python as easy to use as REALbasic. They aren't there yet, that's for sure, but it is useable. Another fun project is DrawBot by Just, it's a Proce55ing like program to learn about graphics. One of the drawbacks of using wxPython in my experience, was the threading support, something I really had to fight with; message queues? My next try will be PyObjC as it builds on a good application framework, but unfortunately it's not very cross platform friendly. (Does anyone know if Mono will have a Python binding?) My 2 euro cents. Arthur From bob at redivi.com Sun Feb 13 19:36:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 13 19:36:59 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: <31ac537c05021309309146b71@mail.gmail.com> References: <20050213155914.A151F1E400E@bag.python.org> <420F8A17.90407@wordtech-software.com> <31ac537c05021309309146b71@mail.gmail.com> Message-ID: On Feb 13, 2005, at 12:30, Troy Rollins wrote: >> >> Let me conclude with a question: what *should* be in a newbie-friendly >> Python IDE? If you were writing one, what would you like to see in it? > > Well, that is a good point. I suppose everyone will have a differing > opinion on that, particularly in terms of goals. For me, I'd like to > see a single package, which includes a GUI designer, script editor > with colorizing, debugger, interactive console, some sort of module > browser for functions and syntax, resource viewer, something similar > to package manager... and a basic set of modules for x-plat > development work. Then, some tool which helps to output the whole > thing as a runtime package. > > I realize that is asking a lot. I really do. I also think that there > is money to be made by the company or person who delivers something > like that... providing it is pretty tight and cohesive. > > I've tried the ones that have been mentioned. They all work pretty > buggy in my experience. (Not PyObjC or PyQt... those I have not > tried.) Neither PyObjC or PyQt are IDEs. PyObjC is a runtime bridge between Python and Objective-C, and PyQt is a wrapper for the Qt GUI framework. PyQt is cross-platform, but it not currently available in any way free of cost on Windows. Trolltech has announced that they're looking to relicense the Windows version so it is hybrid GPL like it is for X11 and Mac OS X -- however, that doesn't do anything for PyQt until RiverBank also changes their license. Though, if you're writing software that isn't or can't be GPL, then you have to pay for it anyway. PyObjC currently has zero support for cross-platform development at this time, but will potentially have GNUStep support soon. However, GNUStep isn't really a contender on Windows yet. -bob From bob at redivi.com Sun Feb 13 19:44:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 13 19:44:29 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <37c5dd2a71b212c192f5ea4af8db2915@iaaa.nl> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> <37c5dd2a71b212c192f5ea4af8db2915@iaaa.nl> Message-ID: <5a0a2081917fa28730aeeecc7e3d9439@redivi.com> On Feb 13, 2005, at 13:19, Arthur Elsenaar wrote: > > On Feb 13, 2005, at 17:01, Troy Rollins wrote: > >> Well, I've transitioned between tools like Director, REALbasic, and >> Revolution, and extremely quickly moved into creating non-trivial >> applications. With Python, it is far less condusive to "playing" and >> therefore seems to hold me somewhere around the print "hello world" >> stage. > > I didn't follow this thread from the beginning, but did anyone bring > up PythonCard? I also previously used REALbasic and also have some > Proce55ing experience. I did struggle to get started with Python, but > PythonCard that is based on wxPython got me going. The PythonCard > folks have the intention to make Python as easy to use as REALbasic. > They aren't there yet, that's for sure, but it is useable. > > Another fun project is DrawBot by Just, it's a Proce55ing like program > to learn about graphics. Yeah, DrawBot is really cool. It has syntax highlighting and a very quick edit/run cycle :) However, it doesn't "scale up" to writing anything but little DrawBot scripts. It's a fun learning tool though. > One of the drawbacks of using wxPython in my experience, was the > threading support, something I really had to fight with; message > queues? My next try will be PyObjC as it builds on a good application > framework, but unfortunately it's not very cross platform friendly. > (Does anyone know if Mono will have a Python binding?) Cocoa is similar to most other things with regard to threading: your GUI code should in a single thread (in particular, the main thread). You will still need to use message queues (directly or indirectly) for communicating between threads. IronPython runs on Mono, though Boo is probably a better choice because it's farther along than IronPython is -- though Boo isn't Python, it's probably close enough. I'm really not sure that Mono's GUI support is better than wx or anything else at this point... -bob From bob at redivi.com Sun Feb 13 20:04:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 13 20:04:52 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <56614e190843db689537582fe99e63bd@digitalgoods.com> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> Message-ID: On Feb 13, 2005, at 9:23, Jon Schull wrote: >> Open source developers work on whatever they want or need to work on, >> so the particular problems you have will get solved when someone with >> the time, skill, and motivation to do so decides to scratch that >> itch. If you want to speed this process along, you have a few >> options: >> >> - Persuade a suitable developer to work on the problem areas you have >> (usually with money or a job) >> - Fix the problems you have yourself (hey, at least you CAN) >> - Deal with it as-is >> >> .. beggars can't be choosers :) >> >> -bob [ comment in the context of distribution packages but it applies >> to the discussion of IDE chaos as well]. > > My comment: > > (1) In this business, beggars do choose, and they vote with their > feet. If a beginner-friendly IDE is not an interesting problem for > cognoscenti, the python foundation (or some such) should step in, or > the python community should consider the possibility that the > demographics of the development community is in danger of ceding the > next generation... > Well, either the current state if Python tools is good enough or it isn't. Perhaps the threat of a new user not sticking with Python is suitable motivation for some developers, but obviously not all of them, because then Python would do everything for everyone already :) Python has been getting better tools and easier to pick up over the years. How could this possibly put it in "danger of ceding the next generation"? So what if the Director or Revolution equivalent doesn't spring from the ashes tomorrow? When it does, it will be great, but there's years worth of programmer years that go into such a product. I'm not aware of such an effort, so it's probably not going to happen very soon. Python does already ship with an IDE, IDLE, which is probably pretty new user friendly and it does have the one feature that most of the other IDEs don't have. It runs sub-interpreters out of process by default, so running GUI applications works. -bob From pecora at anvil.nrl.navy.mil Sun Feb 13 20:10:42 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Sun Feb 13 20:10:41 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <1a2e0eeb996c9ed442e0161643a4b443@yahoo.ca> References: <20050211233244.EA5841E400C@bag.python.org> <1a2e0eeb996c9ed442e0161643a4b443@yahoo.ca> Message-ID: <420FA632.30403@anvil.nrl.navy.mil> Brendan Simons wrote: > That was a big obstacle against many of the text editors I tried to > use. TextWrangler, however, has good Python support, including cmd-r > to run the present script. They've even written a parser for > traceback, so when I get a runtime error, TW drops me right where I > made the mistake. Handy. Nice. I own BBEdit (TextWrangler's big brother, I think) and never looked into that ability. Sounds like time to do that. BBEdit is a great editor. Thanks for the info. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From pecora at anvil.nrl.navy.mil Sun Feb 13 20:26:30 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Sun Feb 13 20:26:29 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <56614e190843db689537582fe99e63bd@digitalgoods.com> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> Message-ID: <420FA9E6.8080101@anvil.nrl.navy.mil> Jon Schull wrote: > Bob Ippolito wrote: > > Open source developers work on whatever they want or need to work > on, so the particular problems you have will get solved when > someone with the time, skill, and motivation to do so decides to > scratch that itch. If you want to speed this process along, you > have a few options: > > - Persuade a suitable developer to work on the problem areas you > have (usually with money or a job) > - Fix the problems you have yourself (hey, at least you CAN) > - Deal with it as-is > > .. beggars can't be choosers :) > > -bob [ comment in the context of distribution packages but it > applies to the discussion of IDE chaos as well]. > > > My comment: > > (1) In this business, beggars do choose, and they vote with their > feet. If a beginner-friendly IDE is not an interesting problem for > cognoscenti, the python foundation (or some such) should step in, or > the python community should consider the possibility that the > demographics of the development community is in danger of ceding the > next generation... Interesting comment. I do know that there is a lot of interest in Python in the scientific community. Some SIAM (Society for Industrial and Applied Mathematics -- BIG coverage there) conferences have had special minisymposia on using Python for numerical coding. But most people just have no idea where to start or are put off by all the packages out there and the need to find one's way through the forest. I suspect a simple "all-in-one" package of Python for Scientists, Mathematicians, and Engineers (a la MATLAB) would be a hit. Given the existence of Matplotlib in Python that might be a reasonable target. Even if it were just a "poor man's MATLAB" that would be fine. Just so long as it installed in one shot and was reasonable easy to use. But maybe that's asking a lot. I don't know. That all-in-one need is what propelled MATLAB to become a standard in some areas of Engineering and Science. Of course, you have to be able to afford several thousand US$ to get up and running. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From just at letterror.com Sun Feb 13 20:29:30 2005 From: just at letterror.com (Just van Rossum) Date: Sun Feb 13 20:29:36 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <5a0a2081917fa28730aeeecc7e3d9439@redivi.com> Message-ID: Bob Ippolito wrote: > > Another fun project is DrawBot by Just, it's a Proce55ing like > > program to learn about graphics. > > Yeah, DrawBot is really cool. Note that this is an unofficial fork that is NOT endorsed by me. In fact I have told the guy last week he has to stop calling that DrawBot. I'll be releasing a new version soon. Here's a alpha-ish version: http://just.letterror.com/~just/DrawBot2.0a1.app.sit Erik van Blokland has been working on a new DrawBot site: http://drawbot.com/ It's not finished, but you'll get an idea of where we're heading. > It has syntax highlighting and a very quick edit/run cycle :) As does the original DrawBot. > However, it doesn't "scale up" to writing anything but little DrawBot > scripts. It's a fun learning tool though. Yup. That's all it's meant to be. Just From bob at redivi.com Sun Feb 13 21:00:18 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 13 21:00:23 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: Message-ID: <4da2045c7bead0059ef2d0bbc603d737@redivi.com> On Feb 13, 2005, at 14:29, Just van Rossum wrote: > Bob Ippolito wrote: > >>> Another fun project is DrawBot by Just, it's a Proce55ing like >>> program to learn about graphics. >> >> Yeah, DrawBot is really cool. > > Note that this is an unofficial fork that is NOT endorsed by me. In > fact > I have told the guy last week he has to stop calling that DrawBot. I'll > be releasing a new version soon. Here's a alpha-ish version: > > http://just.letterror.com/~just/DrawBot2.0a1.app.sit > > Erik van Blokland has been working on a new DrawBot site: > > http://drawbot.com/ > > It's not finished, but you'll get an idea of where we're heading. Oops! I had no idea that was a fork. It has been around a long time, and is the top hit on google. -bob From thorthor at altern.org Sun Feb 13 22:06:44 2005 From: thorthor at altern.org (thor) Date: Sun Feb 13 22:06:57 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: <31ac537c05021309309146b71@mail.gmail.com> References: <20050213155914.A151F1E400E@bag.python.org> <420F8A17.90407@wordtech-software.com> <31ac537c05021309309146b71@mail.gmail.com> Message-ID: Hi Troy, list! > Well, that is a good point. I suppose everyone will have a differing > opinion on that, particularly in terms of goals. For me, I'd like to > see a single package, which includes a GUI designer, script editor > with colorizing, debugger, interactive console, some sort of module > browser for functions and syntax, resource viewer, something similar > to package manager... and a basic set of modules for x-plat > development work. Then, some tool which helps to output the whole > thing as a runtime package. I wholly agree that this would be a utopian environment! As a Director user myself, I have gone through some of the same problems as you have. I wanted to make a cross platform software that used pyGame for drawing and wxPython for Menus and GUI buttons, etc. This is not possible as wxPython does not support the pyGame thread. This is a big problem. No way of drawing 2D in python and use wxPython. Solutions: - Do 2D stuff in OpenGL (quite awkward) as pyOpenGL works with wxPython - Don't use wxPython but native libraries on each of the 3 platforms I want to write for. For this reason I am now using Java and I draw on a Canvas inside the Swing GUI elements and this is easily done and cross platform. I might be missing some solutions, but I tried for months and gave up. Python rocks and is extremely nice, the user community as well, but as you say, a lot of the time (for me) has been wasted by trying to figure out a workable environment for what I wanted to do without luck. Multimedia in Python is problematic but possible (as the list will assure you). good luck and thanks for bringing up those issues, it is by discussion that things progress. thor From bob at redivi.com Sun Feb 13 22:51:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 13 22:51:43 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: References: <20050213155914.A151F1E400E@bag.python.org> <420F8A17.90407@wordtech-software.com> <31ac537c05021309309146b71@mail.gmail.com> Message-ID: <8c7d691e669e1917c07b844e380ba020@redivi.com> On Feb 13, 2005, at 16:06, thor wrote: >> Well, that is a good point. I suppose everyone will have a differing >> opinion on that, particularly in terms of goals. For me, I'd like to >> see a single package, which includes a GUI designer, script editor >> with colorizing, debugger, interactive console, some sort of module >> browser for functions and syntax, resource viewer, something similar >> to package manager... and a basic set of modules for x-plat >> development work. Then, some tool which helps to output the whole >> thing as a runtime package. > > I wholly agree that this would be a utopian environment! > > As a Director user myself, I have gone through some of the same > problems as you have. > > I wanted to make a cross platform software that used pyGame for drawing > and wxPython for Menus and GUI buttons, etc. This is not possible as > wxPython > does not support the pyGame thread. This is a big problem. No way of > drawing > 2D in python and use wxPython. wxWidgets and SDL are definitely not compatible on OS X, I think it might be possible (but probably problematic) to integrate them on other platforms. pygame isn't really what you want for modern multimedia stuff. It's kinda slow (especially on OS X), limited to simple pixel processing (blits mostly, no vector stuff, no real pixel effects, etc.), and it's painfully low level. On the other hand, the stuff it *does* do, it does fairly well, and it does it everywhere in the same way. w.r.t the slow comment, someone on the SDL mailing list is working on Altivec acceleration for SDL.. which is one of the reasons I have been putting off a new pygame build. It will make worlds of difference in performance. Unfortunately, the first patch he posted is incomplete, and it is not conditionally enabled (read: disables G3 support). Hopefully he finds the time to finish it soon! > Solutions: > - Do 2D stuff in OpenGL (quite awkward) as pyOpenGL works with wxPython > - Don't use wxPython but native libraries on each of the 3 platforms I > want to write for. OpenGL (and/or DirectX), directly or indirectly, is definitely the right way to do multimedia. Cairo is an interesting project that might make doing accelerated 2D programming much easier, and there are Python bindings . Personally I never had much of a problem abstracting OpenGL to do 2D stuff, but I didn't have a problem with the 3D stuff either. It would definitely be useful if someone were to create a high-level library for multimedia using PyOpenGL. I remember seeing a couple nascent projects in this arena, but I don't remember the names -- except for slithy , which is really something altogether different, but it may have all the bits you need. > For this reason I am now using Java and I draw on a Canvas inside the > Swing GUI elements and this is easily done and cross platform. > > I might be missing some solutions, but I tried for months and gave up. > > Python rocks and is extremely nice, the user community as well, but as > you > say, a lot of the time (for me) has been wasted by trying to figure > out a workable > environment for what I wanted to do without luck. Unfortunately you picked a subject area that there isn't a lot of high level support for. Most of the nuts and bolts are there, though. > Multimedia in Python is problematic but possible (as the list will > assure you). I would say raw, not problematic. There are no real problems with it that I'm aware of, you're just not that much better off from an integration perspective than you would be in one of the C languages. > good luck and thanks for bringing up those issues, it is by discussion > that things progress. It takes a lot more than just talk! -bob From hengist.podd at virgin.net Sun Feb 13 23:00:01 2005 From: hengist.podd at virgin.net (has) Date: Sun Feb 13 23:00:34 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <2msm4030de.fsf@starship.python.net> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> Message-ID: Michael Hudson wrote: > > [Many new developers] would > > prefer to get started (at least) within the relative controlled >> environment of an IDE. > >However, it probably is a good deal less effort to explain to >newcomers how to get going without an IDE thatn to write one. There's a paradox at work here. What newbies need from an IDE is _very different_ to what experienced users expect from one. On the one hand, newbies want something that is very quick and simple to learn - so the editor needs to be pretty narrow and minimal in its featureset. On the other, they also want it to provide some very powerful features - e.g. GUI editor, executable generator - that are non-trivial to develop so generally only appear in big, complex, bells-n-whistles environments. One option is to take an existing bells-n-whistles IDE and strip it right down to just the features that newbies will immediately need, minimizing and rearranging the remaining UI and adding/rewriting additional built-in help facilities. That'll let newbies get started without running smack into the immediate information overload that comes from being faced with an 'old-pro' oriented environment. Once they outgrow the newbie-oriented IDE they'll need to make the jump to the full-blown one which'l no doubt require some relearning, but at least by then they should be able to cope with the jump. Another would be to architect the IDE from the ground-up as completely component-oriented (e.g. a-la OpenDoc) where every feature is pluggable and replaceable, right down to the editor and interpreter windows themselves. That would allow the IDE to be distributed in its newbie-friendly form with all the 'old-pro' features left out, and once users become familiar with the basics they can start to add new components and replace existing ones so that the editor grows with them. This would be the better approach from the users' POV, though it also requires even better design and implementation to pull off. Obviously, either option requires a significant amount of work to be done by exactly the sort of old pros who have the least to gain directly from it. Which is always the problem with 'free as in beer' software, as it requires some other form of motivation, e.g. ego, evangelism, foundation grants or whatever. >Especially writing an IDE that would be noticeably more correct than >my current Emacs/Terminal/interactive Python setup. While that combination may well suit Python newcomers who are already experienced Emacs/Terminal users, it's a complete non-starter for anyone who isn't, because the last thing a newbie wants is to have to learn two or three different things all at the same time just to get started. For example, when I started learning Python I took a look at various IDEs, but learning one of those on top of learning Python was just going to be too much, so I ended up using a zero-feature syntax-coloured shell script editor instead. Might not do anything, but since it only took 2 minutes to learn I was able to get right on with the more important task of learning Python, so that I could actually get on with what I _really_ wanted to do, which was write cool software to do useful stuff. (BTW, I'm still using that editor despite it being really limited because I still can't be arsed sinking time and effort into one of these big, fat, complex IDEs when I can be writing code instead.) And that's the whole crux of the matter: Most people who come to Python aren't interested in learning IDEs, or Python, or anything else. The only thing they're interested in doing is creating cool software to do useful stuff, and every second they're having to sit and learn some tedious crap before they can do that is a second they're being kept from achieving that goal. Sure, there'll be some who enjoy all that "learning for learning's sake", but most are primarily task-oriented so you either directly help them reach that goal - e.g. by providing a completely intuitive drag-n-drop GUI builder so they can whip up that 2-minute UI when they need it - or you keep the hell out their way so you don't hack them off. Because if you do hack them off, or they think they can get better help by moving to another platform, then another platform is just where they're gonna go. And that's what the [Mac]Python community has to deal with if they want to attract new users better'n all their competition can. Me, I'm off to hack up a Script Editor clone now, so you can guess which particular audience I'm gonna be pitching to in the next few months. ;) HTH has -- http://freespace.virgin.net/hamish.sanderson/ From eichin at metacarta.com Sun Feb 13 23:45:51 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: Sun Feb 13 23:45:55 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> Message-ID: <7g7jlckrj4.fsf@pikespeak.metacarta.com> > software to do useful stuff, and every second they're having to sit > and learn some tedious crap before they can do that is a second > they're being kept from achieving that goal. On the other hand, I recently did a quick in-office tutorial of "order some pizza, throw one of our legacy perl scripts up on the video projector[1], port it to python over lunch" - and while it had the usual python-related positive impact (look at these long-hidden bugs we've exposed and fixed, look at how easy to read the new code is even for the people who've only been doing python for a month) what startled me was the number of people who concluded "wow, I *need* to learn emacs" who previously thought of it as "just another editor" just from watching me do the kind of stuff I take for granted. So maybe it gets in the way - or maybe, if you actually expect to do this for more than a week or a month, it's a useful productivity tool/life skill - even if you don't stick with python... > Me, I'm off to hack up a Script Editor clone now, so you can guess which Good luck! [1] the projector hooked to a powerbook, if that brings it at least vaguely back on topic, but I'm mostly a mac-as-unix type, not a mac-as-platform type. From jschull at digitalgoods.com Sun Feb 13 23:53:23 2005 From: jschull at digitalgoods.com (Jon Schull) Date: Sun Feb 13 23:53:35 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <20050213200037.B2E861E4012@bag.python.org> References: <20050213200037.B2E861E4012@bag.python.org> Message-ID: <6be9955f0f433c95747950135401a8cb@digitalgoods.com> > |Let me conclude with a question: what *should* be in a newbie-friendly > |> Python IDE? If you were writing one, what would you like to see in > it? > > > |>Well, that is a good point. I suppose everyone will have a differing > |>opinion on that, particularly in terms of goals. For me, I'd like to > |>see a single package, which includes a GUI designer, script editor > |>with colorizing, debugger, interactive console, some sort of module > |>browser for functions and syntax, resource viewer, something similar > |>to package manager... and a basic set of modules for x-plat > |>development work. Then, some tool which helps to output the whole > |>thing as a runtime package. > > |>I realize that is asking a lot. I really do. I agree its a good question, and I agree its asking a lot. So let's start from the bottom, sticking with the bare essentials required by a newbie (who may not want an overly-ornate macromedia-like environment anyway.). (Preface: * On windows I was very happy with Scite. On the mac, Scite was sluggish, and crashed. * On windows I there was only one flavor of python, and VPython (which is to my mind the purest expression of pythonic newbie-friendly simplicity) just worked. On the mac there are (too) many flavors of python and they can trounce each other. Even the "looks and feels" (e.g, X11 idle vs "OSX" vs command line) vary. It is sad and ironic that within-python, windows offers the python programmer a more consistent mac-like user experience than the mac does. This is even sadder because I think there is are natural esthetic and community affinities between the mac mac and python communities.) So in prioritized order (numbers are prioritized; letter ordering is not) 1a. A peppy native aqua, crash-free text editor with optional syntax highlighting 1b. A single easy and obvious configuring of the python memory environment. (.pth? sys.path? site module? gimme a break!) 2a. an under-the-hood solution to, or hiding of, the dueling pythons. (Maybe that means installing modules in two locations?) 2b. The text editor should support code folding (to best exploit python's most distinctive and valuable feature) via keystrokes. 3a. Command R runs the current script. 3b. Keys can be rebound simply, e.g. by editing a text file 3c. Errors take you to the offending line. 4. An easy to use, pythonic gui system that will carry cross platform. 5a. Easy variable tracing 5b. A full stepping debugger. 5c. Some kind of simple versioning (such as saving automatic incrementally numbered backups) 6. What he said. But, as noted, that's asking a lot. I'd be happy with 1+... Notes: Today, Smultron gives me #1 1b bites me periodically but I'm brain-damaged already so I don't feel the pain very often 2a is a scandal (even if no one in particular is to blame) 3a Command R can wait for the third tier because I have a trick: I run a script "onchange.py python somefile.py" which runs somefile.py whenever I save the file. But a newbie wouldn't know how to create this script. 4. AnyGui seemed like a really good idea to me. 5a and 5b: the point of mentioning these is to show how LOW a priority they are relative to the prior basic usability issues. I'm not complaining here, so much as trying to raise consciousness about lost opportunities and newbie frustrations to which afficionados in the mature python community are, almost by definition, blinded. Also, I'm speculating but not presuming that this is the right prioritization. Your comments? From mmellor1 at yahoo.com Sun Feb 13 21:05:29 2005 From: mmellor1 at yahoo.com (Mike Mellor) Date: Mon Feb 14 00:11:06 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <20050213174753.BC0811E400E@bag.python.org> References: <20050213174753.BC0811E400E@bag.python.org> Message-ID: <5a01315ac35bbb038cf4e0f34f4a3c78@yahoo.com> On Feb 13, 2005, at 12:47 PM, pythonmac-sig-request@python.org wrote: > On Feb 13, 2005, at 10:59 AM, Troy wrote: > >> I for one, don't care to think of myself in the context of "begger", >> but more so in the context of uninitiated contributor. If developers, >> new to python, have a barrier to entry, they may well walk of to Ruby, >> or Lua... etc. Maybe I'm missing something, but what IDE is out there for either of these languages? Last time I checked they were both text editor/command line languages. As far as Python editors on the Mac, XCode works well enough for me for PyObjC apps, and TextWrangler is great for "plain" scripts. Mike From mmellor1 at yahoo.com Sun Feb 13 21:00:18 2005 From: mmellor1 at yahoo.com (Mike Mellor) Date: Mon Feb 14 00:11:07 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <20050213174753.BC0811E400E@bag.python.org> References: <20050213174753.BC0811E400E@bag.python.org> Message-ID: <2da4742d7f095e7192bc9d8323700bd6@yahoo.com> On Feb 13, 2005, at 12:47 PM, pythonmac-sig-request@python.org wrote: > I just received 3 books on Python from Amazon. Every one of them > starts with the line "this book does not teach you to program in > Python, and assumes you already know how to do that." Perhaps it is > just my own dumb luck, but that is the angle most web materials take > as well in my experience. OR, it is print "hello world". Without knowing which books they are it is hard to say if they'll be useful. The "best" beginner's level book on Python that I have used is "Teach Yourself Python in 24 Hours." Most of the titles in this series are horrible, but this one id very good - well organized and an easy read. It is also several years old, but it is a great intro. Mike From rkern at ucsd.edu Mon Feb 14 00:17:55 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Feb 14 00:18:03 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <420FA9E6.8080101@anvil.nrl.navy.mil> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <420FA9E6.8080101@anvil.nrl.navy.mil> Message-ID: <420FE023.8050301@ucsd.edu> Louis Pecora wrote: > Interesting comment. I do know that there is a lot of interest in > Python in the scientific community. Some SIAM (Society for Industrial > and Applied Mathematics -- BIG coverage there) conferences have had > special minisymposia on using Python for numerical coding. But most > people just have no idea where to start or are put off by all the > packages out there and the need to find one's way through the forest. I > suspect a simple "all-in-one" package of Python for Scientists, > Mathematicians, and Engineers (a la MATLAB) would be a hit. Given the > existence of Matplotlib in Python that might be a reasonable target. > Even if it were just a "poor man's MATLAB" that would be fine. Just so > long as it installed in one shot and was reasonable easy to use. But > maybe that's asking a lot. I don't know. It's called "Enthon." There will be a new release (for Windows and Linux) with more stuff, like matplotlib, Soon(TM). http://www.enthought.com/downloads/downloads.htm There will be a Mac release A Little Later Than Soon(TM). http://www.scipy.org/wikis/featurerequests/MacEnthon -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Mon Feb 14 00:19:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 00:19:19 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <5a01315ac35bbb038cf4e0f34f4a3c78@yahoo.com> References: <20050213174753.BC0811E400E@bag.python.org> <5a01315ac35bbb038cf4e0f34f4a3c78@yahoo.com> Message-ID: <69dc4b86260741823449161d4b96777c@redivi.com> On Feb 13, 2005, at 15:05, Mike Mellor wrote: > > On Feb 13, 2005, at 12:47 PM, pythonmac-sig-request@python.org wrote: > >> On Feb 13, 2005, at 10:59 AM, Troy wrote: >> >>> I for one, don't care to think of myself in the context of "begger", >>> but more so in the context of uninitiated contributor. If developers, >>> new to python, have a barrier to entry, they may well walk of to >>> Ruby, >>> or Lua... etc. > > Maybe I'm missing something, but what IDE is out there for either of > these languages? Last time I checked they were both text > editor/command line languages. Maybe that's a benefit! Since they have no IDEs (that I know of), a souped up text editor is the obvious choice. No room to get confused or frustrated with the plethora of almost-there IDEs. -bob From bob at redivi.com Mon Feb 14 00:23:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 00:23:23 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <6be9955f0f433c95747950135401a8cb@digitalgoods.com> References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> Message-ID: <524fb7f6d8137074a6030e621061a4a0@redivi.com> On Feb 13, 2005, at 17:53, Jon Schull wrote: >> |Let me conclude with a question: what *should* be in a >> newbie-friendly >> |> Python IDE? If you were writing one, what would you like to see in >> it? >> >> >> |>Well, that is a good point. I suppose everyone will have a differing >> |>opinion on that, particularly in terms of goals. For me, I'd like to >> |>see a single package, which includes a GUI designer, script editor >> |>with colorizing, debugger, interactive console, some sort of module >> |>browser for functions and syntax, resource viewer, something similar >> |>to package manager... and a basic set of modules for x-plat >> |>development work. Then, some tool which helps to output the whole >> |>thing as a runtime package. >> >> |>I realize that is asking a lot. I really do. > > I agree its a good question, and I agree its asking a lot. > > So let's start from the bottom, sticking with the bare essentials > required by a newbie (who may not want an overly-ornate > macromedia-like environment anyway.). > > (Preface: * On windows I was very happy with Scite. On the mac, > Scite was sluggish, and crashed. > * On windows I there was only one flavor of python, and VPython (which > is to my mind the purest expression of pythonic newbie-friendly > simplicity) just worked. On the mac there are (too) many flavors of > python and they can trounce each other. Even the "looks and feels" > (e.g, X11 idle vs "OSX" vs command line) vary. It is sad and ironic > that within-python, windows offers the python programmer a more > consistent mac-like user experience than the mac does. This is even > sadder because I think there is are natural esthetic and community > affinities between the mac mac and python communities.) > > So in prioritized order (numbers are prioritized; letter ordering is > not) > 1a. A peppy native aqua, crash-free text editor with optional syntax > highlighting There are plenty of these, including but not limited to Xcode, BBEdit, SubEthaEdit, Smultron, etc. > 1b. A single easy and obvious configuring of the python memory > environment. (.pth? sys.path? site module? gimme a break!) Put stuff in /Library/Python/2.3 -- is it that hard? You don't have to know about the underlying mechanisms. > 2a. an under-the-hood solution to, or hiding of, the dueling pythons. > (Maybe that means installing modules in two locations?) Don't install multiple Pythons. Problem solved! The under-the-hood solution is implemented anyway - PantherPythonFix. You simply need to make sure all of your extensions were built after installing it, and that the "dueling" python is 2.3.5 or 2.4.x or later. We can't go back in time and relink any extensions that you had managed to download or build on your own before this fix was developed, unfortunately. > 2b. The text editor should support code folding (to best exploit > python's most distinctive and valuable feature) via keystrokes. PyOXIDE does this, I think.. I'm not sure what else does. > 3a. Command R runs the current script. I think a lot of the aforementioned text editors can do this. In the context of a PyObjC app, the Xcode templates give you this. > 3b. Keys can be rebound simply, e.g. by editing a text file I think this is over-prioritized. > 3c. Errors take you to the offending line. Not sure what supports this... I would imagine that PyOXIDE does? > 4. An easy to use, pythonic gui system that will carry cross platform. PythonCard is probably the farthest along with this, I think? > 5a. Easy variable tracing Do people really use variable tracing that often? I don't find myself using it much even in languages that support it. I find myself inspecting state only when I'm sitting at a break point. Perhaps I'm just not effectively using the debugger, I do it in my head, or the code I write in these languages doesn't make variable tracing that useful. > 5b. A full stepping debugger. pdb gives you this, without the GUI... I don't really find myself stepping around a lot though, I simply set the code up to dump me at a post mortem or at a specific place and then I inspect what's going on. I rarely try and continue execution after inspecting the state, because usually I want to change something. > 5c. Some kind of simple versioning (such as saving automatic > incrementally numbered backups) Subversion integration? Numbered backups sounds really obnoxious. > 6. What he said. But, as noted, that's asking a lot. I'd be happy > with 1+... > > Notes: > Today, Smultron gives me #1 > 1b bites me periodically but I'm brain-damaged already so I don't > feel the pain very often > 2a is a scandal (even if no one in particular is to blame) > 3a Command R can wait for the third tier because I have a trick: I > run a script "onchange.py python somefile.py" which runs somefile.py > whenever I save the file. But a newbie wouldn't know how to create > this script. > 4. AnyGui seemed like a really good idea to me. Lots of good ideas never get the attention and effort they deserve. > 5a and 5b: the point of mentioning these is to show how LOW a > priority they are relative to the prior basic usability issues. > > I'm not complaining here, so much as trying to raise consciousness > about lost opportunities and newbie frustrations to which afficionados > in the mature python community are, almost by definition, blinded. > > Also, I'm speculating but not presuming that this is the right > prioritization. Your comments? An out-of-process Python interpreter/debugger combo would be really high on my list. What good is cmd-R if it only works for command line scripts? For IDEs written in Python, in-process interpreters and debuggers can cause the IDE to crash, halt, or behave strangely. Unfortunately this is common practice. -bob From meitnik at bellsouth.net Mon Feb 14 00:49:50 2005 From: meitnik at bellsouth.net (Andrew Meit) Date: Mon Feb 14 00:52:50 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <20050213231123.9140E1E400E@bag.python.org> References: <20050213231123.9140E1E400E@bag.python.org> Message-ID: <808b5007e005de8aefb384d0c95c3add@bellsouth.net> On Feb 13, 2005, at 6:11 PM, Hudson wrote: > And that's the whole crux of the matter: Most people who come to > Python aren't interested in learning IDEs, or Python, or anything > else. The only thing they're interested in doing is creating cool > software to do useful stuff, and every second they're having to sit > and learn some tedious crap before they can do that is a second > they're being kept from achieving that goal. -- This is me. I am also fighting with my body. With my disabilities, I have to work smart than just work hard. Tools that allow me to type less, think more; design gui more, and redoing less. > > Sure, there'll be some who enjoy all that "learning for learning's > sake", but most are primarily task-oriented so you either directly > help them reach that goal - e.g. by providing a completely intuitive > drag-n-drop GUI builder so they can whip up that 2-minute UI when they > need it - or you keep the hell out their way so you don't hack them > off. Because if you do hack them off, or they think they can get > better help by moving to another platform, then another platform is > just where they're gonna go. -- Yup. that too is me. I am at a turning point in my programming life. I am tried of paying for upgrades to a company that doesn't understand testing and good documentation. I want to embrace open source but will open source embrace the newbie?? Let me know when you have that editor, with auto completion too ;-) And for the record, when I can get my brain around Python, I will give back, I promise! Andrew -{Choose Life, Create hope, Nurture Love...}- From bob at redivi.com Mon Feb 14 00:56:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 00:57:03 2005 Subject: [Pythonmac-SIG] py2app documentation Message-ID: <12b65b528ad536f42499874034fddbcc@redivi.com> I've started on some py2app documentation here: http://undefined.org/python/py2app.html Suggestions and contributions accepted. The documentation reflects the current svn trunk version of py2app and some if it may not correspond with whatever version you happen to be using. Despite what the documentation says, py2app 0.1.8 is not released, so the links to download it do not work. -bob From delza at livingcode.org Mon Feb 14 03:18:26 2005 From: delza at livingcode.org (Dethe Elza) Date: Mon Feb 14 03:18:30 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: <420F8A17.90407@wordtech-software.com> References: <20050213155914.A151F1E400E@bag.python.org> <420F8A17.90407@wordtech-software.com> Message-ID: <5f05441840ce0c08f11113f91b70d5d9@livingcode.org> Kevin Walzer wrote: > (Footnote two: ActiveState makes a commercial IDE for open-source > languages, including Python, called Komodo: it's available for Windows > and various Nixes, but not for the Mac. The only reason I can think of > for this is market strategy, as Komodo is built on top of Mozilla; > there's no reason that it shouldn't run on the Mac. So perhaps you > should also lobby ActiveState to bring out Komodo-Mac.) I know some of the ActiveState folks and have talked to them about this. There are a few issues: Komodo was started with some very early release of Mozilla (I'm thinking 0.7, but it might even have been earlier), and the Mac support wasn't as good then. Also, it uses Scintilla as it's text-editing component (as does wx), and that has only been ported to the Mac recently. Finally, they haven't had enough demand from (potentially) paying customers. Post-finally, they don't have much knowledge of OS X among their development staff. So just because Komodo is built on top of Mozilla doesn't mean they get a Mac port for free, unfortunately. --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 "All spiritual paths have four steps: show up, pay attention, tell the truth, and don't be attached to the results." Angeles Arien -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050213/e3ce0d22/smime.bin From jschull at digitalgoods.com Mon Feb 14 04:17:21 2005 From: jschull at digitalgoods.com (Jon Schull) Date: Mon Feb 14 04:17:28 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <524fb7f6d8137074a6030e621061a4a0@redivi.com> References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> <524fb7f6d8137074a6030e621061a4a0@redivi.com> Message-ID: <62335dc349f7172d0ef97756d1c673f3@digitalgoods.com> On Feb 13, 2005, at 6:23 PM, Bob Ippolito wrote: > On Feb 13, 2005, at 17:53, Jon Schull wrote: >> So in prioritized order (numbers are prioritized; letter ordering is >> not) >> 1a. A peppy native aqua, crash-free text editor with optional >> syntax highlighting > > There are plenty of these, including but not limited to Xcode, BBEdit, > SubEthaEdit, Smultron, etc. right >> 1b. A single easy and obvious configuring of the python memory >> environment. (.pth? sys.path? site module? gimme a break!) > > Put stuff in /Library/Python/2.3 -- is it that hard? You don't have > to know about the underlying mechanisms. good to be reminded, although that will force me to reinstall modules extensions, etc. when I upgrade python, won't it? >> 2a. an under-the-hood solution to, or hiding of, the dueling >> pythons. (Maybe that means installing modules in two locations?) > > Don't install multiple Pythons. Problem solved! Well that's where the dilemmas begin. If I want aqua apps and Vpython apps, I need two pythons. (I think. See below.) > The under-the-hood solution is implemented anyway - PantherPythonFix. > You simply need to make sure all of your extensions were built after > installing it, and that the "dueling" python is 2.3.5 or 2.4.x or > later. We can't go back in time and relink any extensions that you > had managed to download or build on your own before this fix was > developed, unfortunately. This is a newsflash! I read Daily Python-URL religiously. And there's no mention of this at python.org, nor at Jack's page to which we are referred http://homepages.cwi.nl/~jack/macpython/ >> 2b. The text editor should support code folding (to best exploit >> python's most distinctive and valuable feature) via keystrokes. > > PyOXIDE does this, I think.. I'm not sure what else does. It does indeed. I think PyOXIDE is very promising, although it crashes on me pretty frequently. > >> 3a. Command R runs the current script. > > I think a lot of the aforementioned text editors can do this. In the > context of a PyObjC app, the Xcode templates give you this. Someday I'll understand what that really implies and entails. But today I'm simulating a newbie (with great success, it seems) > >> 3b. Keys can be rebound simply, e.g. by editing a text file > > I think this is over-prioritized. You're probably right. To me, though, being able to fold and unfold code, and to run the program without breaking my flow is a huge help in keeping track of forest and trees. >> 3c. Errors take you to the offending line. > > Not sure what supports this... I would imagine that PyOXIDE does? It does > >> 4. An easy to use, pythonic gui system that will carry cross >> platform. > > PythonCard is probably the farthest along with this, I think? I'd be interested in hearing what people think. If I recall, my tests involved customizing the pythoncard editor itself. With large source files the editor just got too sluggish. >> 5a. Easy variable tracing > > Do people really use variable tracing that often? I don't find myself > using it much even in languages that support it. I find myself > inspecting state only when I'm sitting at a break point. Perhaps I'm > just not effectively using the debugger, I do it in my head, or the > code I write in these languages doesn't make variable tracing that > useful. > >> 5b. A full stepping debugger. > > pdb gives you this, without the GUI... I don't really find myself > stepping around a lot though, I simply set the code up to dump me at a > post mortem or at a specific place and then I inspect what's going on. > I rarely try and continue execution after inspecting the state, > because usually I want to change something. PyOxide, with > >> 5c. Some kind of simple versioning (such as saving automatic >> incrementally numbered backups) > > Subversion integration? Numbered backups sounds really obnoxious. Subversion clearly better if its newbie-friendly. I was focusing for easiest to implement and easiest to use. > >> 6. What he said. But, as noted, that's asking a lot. I'd be happy >> with 1+... >> >> Notes: >> Today, Smultron gives me #1 >> 1b bites me periodically but I'm brain-damaged already so I don't >> feel the pain very often >> 2a is a scandal (even if no one in particular is to blame) >> 3a Command R can wait for the third tier because I have a trick: I >> run a script "onchange.py python somefile.py" which runs somefile.py >> whenever I save the file. But a newbie wouldn't know how to create >> this script. >> 4. AnyGui seemed like a really good idea to me. > > Lots of good ideas never get the attention and effort they deserve. > >> 5a and 5b: the point of mentioning these is to show how LOW a >> priority they are relative to the prior basic usability issues. >> >> I'm not complaining here, so much as trying to raise consciousness >> about lost opportunities and newbie frustrations to which >> afficionados in the mature python community are, almost by >> definition, blinded. >> >> Also, I'm speculating but not presuming that this is the right >> prioritization. Your comments? > > An out-of-process Python interpreter/debugger combo would be really > high on my list. What good is cmd-R if it only works for command line > scripts? For IDEs written in Python, in-process interpreters and > debuggers can cause the IDE to crash, halt, or behave strangely. > Unfortunately this is common practice. I agree. I've been bitten by that. This discussion leads me to believe that if I were to upgrade my python to 2.35+, run pantherpython fix, I could install modules without worrying about "crosstalk", use PyOXIDE, and have virtually everything I want (with the possible exception of running VPython programs from within PyOxide. Even that SHOULD be possible if I run as an external process using /sw/bin/python, but I get an error.) > Gtk-WARNING **: cannot open display: > Visual-2003-10-05 > (exit status: 1) Perhaps that's just one of those pesky newbie-opaque configuration issues....? Anyway, this has been very useful to me, thanks! Maybe the pieces are actually all available and what's needed is newbie's guide for those new to python, or python on the mac. Then it wouldn't just be useful to *me*. From charles.hartman at conncoll.edu Mon Feb 14 04:18:07 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon Feb 14 04:18:12 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> Message-ID: <257d98d396aaa6eb8f581e92bbae1dc0@conncoll.edu> On Feb 13, 2005, at 5:00 PM, has wrote: > There's a paradox at work here. What newbies need from an IDE is _very > different_ to what experienced users expect from one. I don't think I agree with this. Or rather, I don't really see why it should be true. I don't think the issue is the lack of a toddler chair for absolute beginners. I'll go out on a limb and declare myself Typical of a certain kind of newbie. I come to Python on the Mac as somebody used to the Mac interface (I never trusted myself to *open* Terminal until a few months ago), who had programmed in C and other languages, mostly under DOS years ago. The gap for a lot of us isn't at the *very* beginning; the Mac Python IDE is great for learning syntax and some main modules. But very early on, most of us want to write something with a windows-and-buttons interface. So you settle -- in ignorance! -- on a package (wx, tk, whatever), and an editor (TextWrangler is excellent, and free); and then what? To run the code you write, and to figure out why it won't run, you have to go out of the editor into . . . what? The Terminal, and Unix, and pdb . . . This is a lot to learn. It feels as though your next step after "name = cardString[0:15]" and "import string" (or rather, no, that was an old tutorial, we don't do that any more . . .) is to learn Unix. OK, I *know* that's a wild exaggeration -- I'm talking about the perception. (Sudo, is he that anime director? Why can't my module find my other module?) Having worked on this for a while, I know that there's not all that much you have to know just to move forward -- but there's not much around to help you figure what you need right away and what can wait. For the beginner, the Terminal is a place of maximum entropy: a wonderful variety of ways to do things right, and ten thousand ways to do them wrong, sometimes with very messy results. Oh and by the way, somebody who comes at it like this very probably has "cross-platform" as a firm wish -- that's one of the reasons for turning to Python. So an environment (in the vernacular, not the Unix sense) is what the beginner needs -- an IDE from within which everything you need to do can be done, and not dangerously much else. But if the IDE is complete enough for this beginner to work in, isn't it likely to be a reasonable place for someone to work who knows more, too? Sorry, I'm rambling. Charles Hartman From bob at redivi.com Mon Feb 14 04:43:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 04:43:31 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <62335dc349f7172d0ef97756d1c673f3@digitalgoods.com> References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> <524fb7f6d8137074a6030e621061a4a0@redivi.com> <62335dc349f7172d0ef97756d1c673f3@digitalgoods.com> Message-ID: On Feb 13, 2005, at 10:17 PM, Jon Schull wrote: > > On Feb 13, 2005, at 6:23 PM, Bob Ippolito wrote: >> On Feb 13, 2005, at 17:53, Jon Schull wrote: >>> So in prioritized order (numbers are prioritized; letter ordering is >>> not) >>> 1a. A peppy native aqua, crash-free text editor with optional >>> syntax highlighting >> >> There are plenty of these, including but not limited to Xcode, >> BBEdit, SubEthaEdit, Smultron, etc. > right > >>> 1b. A single easy and obvious configuring of the python memory >>> environment. (.pth? sys.path? site module? gimme a break!) >> >> Put stuff in /Library/Python/2.3 -- is it that hard? You don't have >> to know about the underlying mechanisms. > good to be reminded, although that will force me to reinstall modules > extensions, etc. when I upgrade python, won't it? YES, but you have to do that anyway. Upgrading your development environment from Python 2.3 to 2.4 requires rebuilding and reinstalling EVERYTHING. You probably shouldn't bother with installing 2.3.5 because the multiple python scenario is a pain in the ass and it often doesn't really buy you that much. You should install PantherPythonFix immediatley, because even installing Python 2.4 will break extension building for your current Python. On the subject of Python 2.4, I would wait for Python 2.4.1... 2.4.0 is better than 2.3.0 at building extensions and whatnot, but there are improvements in 2.4.1 that are worth waiting for. >>> 2a. an under-the-hood solution to, or hiding of, the dueling >>> pythons. (Maybe that means installing modules in two locations?) >> >> Don't install multiple Pythons. Problem solved! > Well that's where the dilemmas begin. If I want aqua apps and Vpython > apps, I need two pythons. (I think. See below.) > >> The under-the-hood solution is implemented anyway - PantherPythonFix. >> You simply need to make sure all of your extensions were built after >> installing it, and that the "dueling" python is 2.3.5 or 2.4.x or >> later. We can't go back in time and relink any extensions that you >> had managed to download or build on your own before this fix was >> developed, unfortunately. > > This is a newsflash! I read Daily Python-URL religiously. And > there's no mention of this at python.org, nor at Jack's page to which > we are referred http://homepages.cwi.nl/~jack/macpython/ Interim fixes for this issue have been discussed on and off on this list for god knows how long. PantherPythonFix was mentioned on this list fairly recently and is technically still in beta. It's in the beta html page for the Python 2.3.5 release on Jack's page. It was mentioned on my blog last week which presumably made the Daily Python-URL (most of them do.. I'd have to double-check). >>> 2b. The text editor should support code folding (to best exploit >>> python's most distinctive and valuable feature) via keystrokes. >> >> PyOXIDE does this, I think.. I'm not sure what else does. > It does indeed. I think PyOXIDE is very promising, although it > crashes on me pretty frequently. > >> >>> 3a. Command R runs the current script. >> >> I think a lot of the aforementioned text editors can do this. In the >> context of a PyObjC app, the Xcode templates give you this. > Someday I'll understand what that really implies and entails. But > today I'm simulating a newbie (with great success, it seems) Xcode builds and runs your current project when you press cmd-R. PyObjC ships with templates that are hybrid Objective-C/PyObjC that are compatible with this feature. These templates are only useful for Cocoa development. That explain it any better? If not, read the PyObjC documentation. >>> 3b. Keys can be rebound simply, e.g. by editing a text file >> >> I think this is over-prioritized. > You're probably right. To me, though, being able to fold and unfold > code, and to run the program without breaking my flow is a huge help > in keeping track of forest and trees. What does that have to do with changing key bindings? >>> 3c. Errors take you to the offending line. >> >> Not sure what supports this... I would imagine that PyOXIDE does? > It does > >> >>> 4. An easy to use, pythonic gui system that will carry cross >>> platform. >> >> PythonCard is probably the farthest along with this, I think? > > I'd be interested in hearing what people think. If I recall, my tests > involved customizing the pythoncard editor itself. With large source > files the editor just got too sluggish. That's probably because current wxPython generally seems to be sluggish on OS X. If not, then maybe pythoncard's editor just needs some optimizations. I don't know, I don't use either that much, especially on the Mac. >>> 5a. Easy variable tracing >> >> Do people really use variable tracing that often? I don't find >> myself using it much even in languages that support it. I find >> myself inspecting state only when I'm sitting at a break point. >> Perhaps I'm just not effectively using the debugger, I do it in my >> head, or the code I write in these languages doesn't make variable >> tracing that useful. >> >>> 5b. A full stepping debugger. >> >> pdb gives you this, without the GUI... I don't really find myself >> stepping around a lot though, I simply set the code up to dump me at >> a post mortem or at a specific place and then I inspect what's going >> on. I rarely try and continue execution after inspecting the state, >> because usually I want to change something. > PyOxide, with Huh? >>> 5c. Some kind of simple versioning (such as saving automatic >>> incrementally numbered backups) >> >> Subversion integration? Numbered backups sounds really obnoxious. > Subversion clearly better if its newbie-friendly. I was focusing for > easiest to implement and easiest to use. Subversion has Python bindings and it wouldn't be that hard to integrate it with a local repository.. >>> 6. What he said. But, as noted, that's asking a lot. I'd be happy >>> with 1+... >>> >>> Notes: >>> Today, Smultron gives me #1 >>> 1b bites me periodically but I'm brain-damaged already so I don't >>> feel the pain very often >>> 2a is a scandal (even if no one in particular is to blame) >>> 3a Command R can wait for the third tier because I have a trick: I >>> run a script "onchange.py python somefile.py" which runs >>> somefile.py whenever I save the file. But a newbie wouldn't know >>> how to create this script. >>> 4. AnyGui seemed like a really good idea to me. >> >> Lots of good ideas never get the attention and effort they deserve. >> >>> 5a and 5b: the point of mentioning these is to show how LOW a >>> priority they are relative to the prior basic usability issues. >>> >>> I'm not complaining here, so much as trying to raise consciousness >>> about lost opportunities and newbie frustrations to which >>> afficionados in the mature python community are, almost by >>> definition, blinded. >>> >>> Also, I'm speculating but not presuming that this is the right >>> prioritization. Your comments? >> >> An out-of-process Python interpreter/debugger combo would be really >> high on my list. What good is cmd-R if it only works for command >> line scripts? For IDEs written in Python, in-process interpreters >> and debuggers can cause the IDE to crash, halt, or behave strangely. >> Unfortunately this is common practice. > > I agree. I've been bitten by that. > > This discussion leads me to believe that if I were to upgrade my > python to 2.35+, run pantherpython fix, I could install modules > without worrying about "crosstalk", use PyOXIDE, and have virtually > everything I want (with the possible exception of running VPython > programs from within PyOxide. Even that SHOULD be possible if I run > as an external process using /sw/bin/python, but I get an error.) >> Gtk-WARNING **: cannot open display: >> Visual-2003-10-05 >> (exit status: 1) > Perhaps that's just one of those pesky newbie-opaque configuration > issues....? This is because you don't have a DISPLAY variable set, so it doesn't know which X11 server to talk to. Off the top of my head, a quick and dirty fix for this would be to set the "DISPLAY" environment variable to "0:0" in your ~/.MacOSX/environment.plist. You should be able to easily edit this with the RCEnvironment preference pane . Or, if you're feeling particularly pythonic, you could use the Plugins/EnvironmentPrefs example that is in PyObjC 1.2. > Anyway, this has been very useful to me, thanks! > > Maybe the pieces are actually all available and what's needed is > newbie's guide for those new to python, or python on the mac. > Then it wouldn't just be useful to *me*. I think part of the problem is that most of the cognoscenti (as you put it) are set on using crazy tools like Emacs and Vim, so they are more or less just as aware of the "easy" way as the new users are :) -bob From brendansimons at yahoo.ca Mon Feb 14 06:34:25 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Mon Feb 14 06:34:41 2005 Subject: [Pythonmac-SIG] Newbies need IDEs (was Mac User Python Newbie) In-Reply-To: <20050214031730.259061E400D@bag.python.org> References: <20050214031730.259061E400D@bag.python.org> Message-ID: <57f1ab2cac4886e5dfa134b098af0a34@yahoo.ca> > > Maybe that's a benefit! Since they have no IDEs (that I know of), a > souped up text editor is the obvious choice. No room to get confused > or frustrated with the plethora of almost-there IDEs. > > -bob I agree that that is probably the best approach to advocate until new tools are ready. As soon as my skills are sufficiently developed, I would like to address this problem. For inspiration, ActiveState's python distribution on windows comes with a very tidy little IDE called PythonWin, which is very clean and easy to use. Also, the PythonCard people put their IDE together in a weekend, so I'm told, because all the necessary parts had already been ported to wxWidgets. (I made an attempt to bundle this using py2app, but gave up before I could get it to launch). I think Bob is on the right track getting the necessary components built first. After that, a new-user-friendly IDE should be a simple matter of putting the parts together ;) From bob at redivi.com Mon Feb 14 07:19:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 07:19:55 2005 Subject: [Pythonmac-SIG] Newbies need IDEs (was Mac User Python Newbie) In-Reply-To: <57f1ab2cac4886e5dfa134b098af0a34@yahoo.ca> References: <20050214031730.259061E400D@bag.python.org> <57f1ab2cac4886e5dfa134b098af0a34@yahoo.ca> Message-ID: <249e66d25ac068d81cd7aa630688ee45@redivi.com> On Feb 14, 2005, at 12:34 AM, Brendan Simons wrote: >> >> Maybe that's a benefit! Since they have no IDEs (that I know of), a >> souped up text editor is the obvious choice. No room to get confused >> or frustrated with the plethora of almost-there IDEs. > > I agree that that is probably the best approach to advocate until new > tools are ready. As soon as my skills are sufficiently developed, I > would like to address this problem. > > For inspiration, ActiveState's python distribution on windows comes > with a very tidy little IDE called PythonWin, which is very clean and > easy to use. Also, the PythonCard people put their IDE together in > a weekend, so I'm told, because all the necessary parts had already > been ported to wxWidgets. (I made an attempt to bundle this using > py2app, but gave up before I could get it to launch). I think Bob > is on the right track getting the necessary components built first. > After that, a new-user-friendly IDE should be a simple matter of > putting the parts together ;) The problem with bundling PythonCard with py2app is that it makes no sense! PythonCard is not an application, it's a framework. It does have a whole bunch of little applications (the tools and samples -- or at least the "meta-sample") that deserve py2app-ing. Basically the way I would approach PythonCard is the following: - Create setup.py scripts for each of the useful applications, these should be built with options like "--semi-standalone --site-packages --excludes=wx,wxPython,PythonCard" because the users must already have these things in order to use them, it makes no sense to bloat the apps. Alternatively this can just be one setup script that calls setup(..) a bunch of times with very similar options. - Subclass bdist_mpkg and create a custom bdist_mpkg command for PythonCard that calls into each of these setup scripts to build the tools and install them to a particular place, it will also add a documentation scheme to put the docs where they're supposed to go (if they're supposed to go somewhere outside the package). py2app's setup script does this, so I would use that as an example. - Write some documentation for PythonCard users that tells them how to use py2app.. possibly just tell them to use the py2applet droplet or script, and then refer them to the py2app documentation if they have more complicated requirements. A user of the PythonCard, assuming stock Mac OS X, would be instructed to do the following (1) Install Xcode / Developer tools (optional but recommended) (2) Install PyObjC 1.2 (from .pkg -- mostly to get py2app. In the future, py2app will ship with tools that require PyObjC to be installed.) (3) Install wxPython (from .pkg) (4) Install PythonCard (from .pkg) (5) Play with the tools, hopefully poke at the docs. It would be possible to make 2-4 a single step by creating a big fat mpkg that simply contained the three if it was deemed that most PythonCard users would not already have these things and if it would make their lives that much easier. Perhaps PythonCard could be shoehorned into the MacEnthon project so you just get that (at the expense of 100 megs or whatever it is) and then you have an environment capable of just about anything. -bob From brendansimons at yahoo.ca Mon Feb 14 14:18:36 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Mon Feb 14 14:18:42 2005 Subject: [Pythonmac-SIG] Newbies need IDEs (was Mac User Python Newbie) In-Reply-To: <249e66d25ac068d81cd7aa630688ee45@redivi.com> References: <20050214031730.259061E400D@bag.python.org> <57f1ab2cac4886e5dfa134b098af0a34@yahoo.ca> <249e66d25ac068d81cd7aa630688ee45@redivi.com> Message-ID: Sorry, I actually meant I tried to bundle the PythonCard Editor, in its tools directory. Your instructions are still helpful though, and I might give it another shot - Brendan On 14-Feb-05, at 1:19 AM, Bob Ippolito wrote: > The problem with bundling PythonCard with py2app is that it makes no > sense! PythonCard is not an application, it's a framework. It does > have a whole bunch of little applications (the tools and samples -- or > at least the "meta-sample") that deserve py2app-ing. From jimsize at insightbb.com Sat Feb 12 16:22:32 2005 From: jimsize at insightbb.com (Jim Sizelove) Date: Mon Feb 14 14:22:38 2005 Subject: [Pythonmac-SIG] Re: MacPython 2.3.5 for 10.2 Release Candidate available In-Reply-To: <420CDC27.30406@insightbb.com> Message-ID: > Folks, > a MacPython 2.3.5 release for MacOSX 10.2 (also works on 10.3) is > available for testing. Please download it from > and send feedback > (preferably to the mailing list) telling me whether it works. > > I'm quite convinced this is going to be the final installer, but > before I publicly announce it I'd like a couple of positive replies. > Also, the PackMan database for 10.2 isn't as complete as I'd like yet, > that'll be done in the next few days. > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > Everything works here. I just upgraded from MacPython 2.3.3 to MacPython 2.3.5 on my iMac running OSX 10.2. Thanks, Jack. Jim Sizelove From meitnik at bellsouth.net Mon Feb 14 15:19:27 2005 From: meitnik at bellsouth.net (Andrew Meit) Date: Mon Feb 14 15:22:30 2005 Subject: [Pythonmac-SIG] Re: Mac Newbie IDE help... In-Reply-To: <20050214110154.B937E1E400A@bag.python.org> References: <20050214110154.B937E1E400A@bag.python.org> Message-ID: <093ce1b49844591f4df6d1a536a5b920@bellsouth.net> On Feb 14, 2005, at 6:01 AM, Hartman wrote: > So an environment (in the vernacular, not the Unix sense) is what the > beginner needs -- an IDE from within which everything you need to do > can be done, and not dangerously much else. But if the IDE is complete > enough for this beginner to work in, isn't it likely to be a > reasonable place for someone to work who knows more, too? -- YES. Thank you for stating it so well. Give me a lever which I can transform into a pencil ;-) Andrew -{Choose Life, Create hope, Nurture Love...}- From hengist.podd at virgin.net Mon Feb 14 18:09:17 2005 From: hengist.podd at virgin.net (has) Date: Mon Feb 14 18:11:49 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <257d98d396aaa6eb8f581e92bbae1dc0@conncoll.edu> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <257d98d396aaa6eb8f581e92bbae1dc0@conncoll.edu> Message-ID: Charles Hartman wrote: >So an environment (in the vernacular, not the Unix sense) is what >the beginner needs -- an IDE from within which everything you need >to do can be done, and not dangerously much else. But if the IDE is >complete enough for this beginner to work in, isn't it likely to be >a reasonable place for someone to work who knows more, too? I think Joel Spolsky hits on the broader problem when talking about bloat vs features : "80% of the people use 20% of the features. Unfortunately, it's never the same 20%." Thus we end up with big, extremely complex programs like MS Word, and the first thing new users have to do is to determine all the bits that they can simply ignore so they can concentrate on learning the bits they actually do need. Uber-geeks may enjoy the feeling of absolute control that comes from having more buttons and knobs at hand than they can count, but us ordinary schmoes just drown in that crap. MS builds software that way cos they like to get their users locked into a perpetual upgrade cycle from which they can make money, but what's OSS's excuse? My preferred IDE architecture would be built on a completely component-oriented architecture. That way it can ship with the minimal components required to get started, and users can add, upgrade and remove components as and when they need them. For example, a new user needs everything visible so they can see what's available; an experience one may prefer everything driven by memorised keyboard combinations so they can devote screen estate to more important things like their code instead of floating palettes, on-screen help, etc. Furthermore, those users aren't locked into a single fixed solution for, say, building GUIs: as long as wxPython, PythonCard, etc. provide compatible components they can plug in whichever one they want. And it allows individual features to develop at their own rate, so you're not stuck with the perpetually 'almost-there-but-not-quite' situation that somebody else mentioned. Python's myriad web frameworks are in exactly the same situation, btw: they should be building smaller and simpler for greater flexibility and custom assembly, but instead seem only to build bigger and more complex with major lock-in and the result is systems that only their existing long-time users want to use because the cost of mastering one of these monsters has grown so high as to deter newcomers. Who then turn to simpler, less powerful systems, master those, and then complain about the lack of features until they too evolve into the same monolithic giants that they'd rejected in the first place. I've never understood what the obsession with building every conceivable feature into the application core, least of all when it's coming from unix folks who really should know better. The central tenet of Unix design philosophy is to build small, interchangeable, single-purpose components that can be easily assembled into whatever form the user needs. So I see this as just sensible design, and the fact that it happens to scale well to fit lots of different user requirements is an added plus. And I despair when I see all these other unix-raised OSS folk rushing in the exact opposite direction, and am at a loss to understand what they're thinking. HTH has -- "Oh, cut the bleeding heart crap, will ya? We've all got our switches, lights, and knobs to deal with, Striker. I mean, down here there are literally hundreds and thousands of blinking, beeping, and flashing lights, blinking and beeping and flashing - they're *flashing* and they're *beeping*. I can't stand it anymore! They're *blinking* and *beeping* and *flashing*! Why doesn't somebody pull the plug!" From pecora at anvil.nrl.navy.mil Mon Feb 14 18:29:07 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon Feb 14 18:29:05 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies Message-ID: <4210DFE3.2000700@anvil.nrl.navy.mil> Troy Rollins wrote: > Well, I've transitioned between tools like Director, REALbasic, and > Revolution, and extremely quickly moved into creating non-trivial > applications. With Python, it is far less condusive to "playing" and > therefore seems to hold me somewhere around the print "hello world" > stage. > > Yes, I've look at the cited examples... perhaps they simply didn't > connect with me on the right level. Python stuff always seems to be > written from the perspective of "ok, you are starting from a lower > level language", but many of us are probably coming from the other > direction ? a higher level language... Lingo, REALbasic, etc. It would > seem to me that the transition to Python should be easy, but perhaps I > just haven't yet encountered the right materials. > > I just received 3 books on Python from Amazon. Every one of them > starts with the line "this book does not teach you to program in > Python, and assumes you already know how to do that." Perhaps it is > just my own dumb luck, but that is the angle most web materials take > as well in my experience. OR, it is print "hello world". > > I'm pretty committed to learning this, but I'm somewhat surprised at > how much productivity I have to throw away in order to do it. Many > would say "well, that's free software for you." But, I'm not > interested in the "free" part. Free is not what is important to me. > Frankly, I'd rather pay for something productive. My time is worth WAY > more than whatever a decent tool would cost. The part that interests > me is open source, and "future-proofing." To me, "free" translates to > "loss of productivity." I'm not a hobbyist, and I'm not looking to > Python as something to use "outside of my day job." I make my living > with tools like this, and have a staff that does as well. > > Please don't interpret any of my comments as saying anything bad about > list members, contributors, or Python. That isn't the intent at all. I > do realize that these things take time, that Python is free and > open-source, and that only I am responsible for my ability to use it, > and choice to do so. > > > Likewise my own previous comments were not intended to be criticisms of the members or the developers who put so much time and energy into the open source that is Python, but I can see how we might be rubbing some the wrong way. I do look at your comments above and mine before as descriptions of what a newbie faces when coming aboard. That's just the way it looks from our vantage point. I've been using Python for several years, but I still feel like a newbie (and probably still am) as there is a myriad of packages that I have no clue about (although I see the names flash by online or my emails). I still feel that my code is fragile and hard to maintain. For example system upgrades to OS X killed off some plotting software I had learned to use. It appears that it is up to me to fix that. I've been looking around, but like Troy I am trying to use Python in my job, but I don't have time to become a guru nor the desire. So where does that leave me or, rather, us? As someone else said in this thread, this is a good issue for the Python community to consider since it will affect who will be included in your world in the future and what that future will look like. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 P.S. I have not yet had time to try out Chris Barker's packaging of matplotlib. I hope to do that later this month, but BIG KUDOS to him for trying to make the code available to more people. From bob at redivi.com Mon Feb 14 18:34:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 18:34:41 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <257d98d396aaa6eb8f581e92bbae1dc0@conncoll.edu> Message-ID: On Feb 14, 2005, at 12:09 PM, has wrote: > Charles Hartman wrote: > >> So an environment (in the vernacular, not the Unix sense) is what the >> beginner needs -- an IDE from within which everything you need to do >> can be done, and not dangerously much else. But if the IDE is >> complete enough for this beginner to work in, isn't it likely to be a >> reasonable place for someone to work who knows more, too? > > I think Joel Spolsky hits on the broader problem when talking about > bloat vs features > : > > "80% of the people use 20% of the features. Unfortunately, it's never > the same 20%." > > Thus we end up with big, extremely complex programs like MS Word, and > the first thing new users have to do is to determine all the bits that > they can simply ignore so they can concentrate on learning the bits > they actually do need. Uber-geeks may enjoy the feeling of absolute > control that comes from having more buttons and knobs at hand than > they can count, but us ordinary schmoes just drown in that crap. MS > builds software that way cos they like to get their users locked into > a perpetual upgrade cycle from which they can make money, but what's > OSS's excuse? Maybe because in many cases, the users are the developers and adding those 20%s together makes for some big ugly mess. > My preferred IDE architecture would be built on a completely > component-oriented architecture. That way it can ship with the minimal > components required to get started, and users can add, upgrade and > remove components as and when they need them. For example, a new user > needs everything visible so they can see what's available; an > experience one may prefer everything driven by memorised keyboard > combinations so they can devote screen estate to more important things > like their code instead of floating palettes, on-screen help, etc. I think Eclipse is intended to be like this -- though I can't say I have real experience using it. > Furthermore, those users aren't locked into a single fixed solution > for, say, building GUIs: as long as wxPython, PythonCard, etc. provide > compatible components they can plug in whichever one they want. And it > allows individual features to develop at their own rate, so you're not > stuck with the perpetually 'almost-there-but-not-quite' situation that > somebody else mentioned. Personally, I hope that developers See The Light and do interface building in a separate but integrated application like Xcode and Interface Builder. If for no other reason than it's simply not possible to integrate a Tkinter GUI builder inside of a wxPython IDE or vice versa. Without this separation, all of the features of the IDE *are* locked into a particular event loop. > Python's myriad web frameworks are in exactly the same situation, btw: > they should be building smaller and simpler for greater flexibility > and custom assembly, but instead seem only to build bigger and more > complex with major lock-in and the result is systems that only their > existing long-time users want to use because the cost of mastering one > of these monsters has grown so high as to deter newcomers. Who then > turn to simpler, less powerful systems, master those, and then > complain about the lack of features until they too evolve into the > same monolithic giants that they'd rejected in the first place. I think WSGI (pep 333) is a good step to fixing this problem. If you target WSGI, at least you can shoehorn your app into a giant framework when you need one. > I've never understood what the obsession with building every > conceivable feature into the application core, least of all when it's > coming from unix folks who really should know better. The central > tenet of Unix design philosophy is to build small, interchangeable, > single-purpose components that can be easily assembled into whatever > form the user needs. So I see this as just sensible design, and the > fact that it happens to scale well to fit lots of different user > requirements is an added plus. And I despair when I see all these > other unix-raised OSS folk rushing in the exact opposite direction, > and am at a loss to understand what they're thinking. I think this is largely caused by complexity of the alternative and the convenience of doing it in this way. The problem with the Unix model is that processes only know how to exchange raw data (sockets, pipes, files). In lots of cases you want to exchange a higher level representation of information, and there aren't a whole lot of easy ways to do that. I'm pretty sure that these large frameworks suffer from the same problem. It's much easier to exchange high level representations of data with yourself than it is to exchange them with someone else.. that, and it's much easier to design something ad-hoc if you don't concern yourself with keeping things modular. The design of py2app definitely exhibits the "large core" issue as part of its development cycle. In order to add a particular feature I'll add whatever code is necessary to make that happen. After I've used it a while I'll figure out how to pare it down and modularize it into something more generally useful and distinct from everything else going on. The alternative is to do more design up front (try to guess what you'll want to use it for and how) which means spending all your time thinking instead of writing usable code. -bob From pecora at anvil.nrl.navy.mil Mon Feb 14 18:37:15 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon Feb 14 18:37:14 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <2mk6pc2vy3.fsf@starship.python.net> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> <2mk6pc2vy3.fsf@starship.python.net> Message-ID: <4210E1CB.1070502@anvil.nrl.navy.mil> Michael Hudson wrote: >Well, I think this is a subjective judgement -- a matter of >familiarity. I "play" with Python all the time. A good start is to >enhance your interactive experience somewhat. Three options spring to >mind: > > 1) Get readline support working. If you're still using Apple's > Python, get bbum's readline.so from > > http://homepage.mac.com/bbum/BumFiles/FileSharing27.html > > (is this still the right link?), then add lines like > > try: > import rlcompleter, readline > readline.parse_and_bind("tab: complete") > except ImportError: > pass > > to a file called something link ~/.pythonrc and point the > PYTHONSTARTUP environment variable to it (yikes, this is a bit > involved...). Then if you want to see what functions a module > supports you can do: > > >>> import urllib2 > >>> urllib2.url > urllib2.url2pathname urllib2.urlopen urllib2.urlparse > > and so on: > > >>> data = urllib2.urlopen('http://www.google.com').read() > >>> data[:10] > ' > 2) Install IPython (http://ipython.scipy.org/). This is a massive > extension of the above and requires you have readline working. > I've not used it much, but people like it. I imagine it has docs > :) > > 3) Install (my) PyRepl package (http://codespeak.net/pyrpl/), which > is a different implementation of the same kind of thing. > >There are less terminal oriented interactive environments too -- I >think wxPython includes one and PyObjC has a 'PyInterpreter' example. >But to me they don't hold much advantage over the in-Terminal.app >solutions. > Well, I can just see Troy sitting at his computer reading the above and saying, "I rest my case." :-) You did somewhat admit that in (1) above and in the remainder of your message so you are honest about the state of affairs. And I thank you for all the information. Now, where to start? Where to start? -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From Chris.Barker at noaa.gov Mon Feb 14 18:39:38 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 18:40:29 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <1a2e0eeb996c9ed442e0161643a4b443@yahoo.ca> References: <20050211233244.EA5841E400C@bag.python.org> <1a2e0eeb996c9ed442e0161643a4b443@yahoo.ca> Message-ID: <4210E25A.5080104@noaa.gov> Brendan Simons wrote: > TextWrangler, however, has good Python support, including cmd-r > to run the present script. They've even written a parser for > traceback, so when I get a runtime error, TW drops me right where I made > the mistake. Handy. But does it do Python indenting correctly? This is my only really obstacle with BBedit (a couple versions old). You can make it put in spaces instead of tabs, but once they're in they are treated only as spaces, rather than levels of indentation, so when you want to remove a level you have to hit delete four times. Not horrible, but annoying. By they way, does anyone know what the heck is up with Pepper? It looked so promising, particularly for those of that want to use the same editor on all three major platforms. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From pecora at anvil.nrl.navy.mil Mon Feb 14 18:45:12 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon Feb 14 18:45:13 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> Message-ID: <4210E3A8.7030005@anvil.nrl.navy.mil> Bob Ippolito wrote: > Well, either the current state if Python tools is good enough or it > isn't. Perhaps the threat of a new user not sticking with Python is > suitable motivation for some developers, but obviously not all of > them, because then Python would do everything for everyone already :) > > Python has been getting better tools and easier to pick up over the > years. How could this possibly put it in "danger of ceding the next > generation"? So what if the Director or Revolution equivalent doesn't > spring from the ashes tomorrow? When it does, it will be great, but > there's years worth of programmer years that go into such a product. > I'm not aware of such an effort, so it's probably not going to happen > very soon. > > Python does already ship with an IDE, IDLE, which is probably pretty > new user friendly and it does have the one feature that most of the > other IDEs don't have. It runs sub-interpreters out of process by > default, so running GUI applications works. > > -bob You know a thought just hit me upon reading this and other emails about the Python environment. I have a friend who has a Russian wife. They went to buy a rug at Home Depot. Lots of variety, thick pile, thin pile, patterns and weaves, colors, etc. etc. etc. The whole situation which at first sounds wonderful was totally upsetting to her. "Too many choices!" she screamed and left the store. Well, in Russia you had the choice of colors as long as it was grey or brown. I'm not suggesting that the Python community should go to that extreme :-) , but for newbies and even old-newbies like me, "Too many choices!" -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From meitnik at bellsouth.net Mon Feb 14 18:49:35 2005 From: meitnik at bellsouth.net (Andrew Meit) Date: Mon Feb 14 18:52:38 2005 Subject: [Pythonmac-SIG] Re: another point..porting... In-Reply-To: <20050214173713.4AAF81E400D@bag.python.org> References: <20050214173713.4AAF81E400D@bag.python.org> Message-ID: <1d1957564877d52ca2785fbf59466bcd@bellsouth.net> On Feb 14, 2005, at 12:37 PM, pythonmac-sig-request@python.org wrote: > Well, I can just see Troy sitting at his computer reading the above > and saying, "I rest my case." :-) -- and for me too... :-( Here is another bone to chew on: porting stuff to Python...I don't find anything to help make the transition of a Gui/data from let say Revolution/RB or anything else to Python... Having to start from scratch does not appeal to a newbie ;-) andrew -{Choose Life, Create hope, Nurture Love...}- From pecora at anvil.nrl.navy.mil Mon Feb 14 18:53:57 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon Feb 14 18:53:55 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <420FE023.8050301@ucsd.edu> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <420FA9E6.8080101@anvil.nrl.navy.mil> <420FE023.8050301@ucsd.edu> Message-ID: <4210E5B5.4070107@anvil.nrl.navy.mil> Robert Kern wrote: > It's called "Enthon." There will be a new release (for Windows and > Linux) with more stuff, like matplotlib, Soon(TM). > > http://www.enthought.com/downloads/downloads.htm > > There will be a Mac release A Little Later Than Soon(TM). > > http://www.scipy.org/wikis/featurerequests/MacEnthon Yeow! Right on the money! Just checked it out, it says: Goal To make a unifying distribution of Python packages useful to scientific developers on the Mac OS X platform in the way that the Enthought Edition of Python ("Enthon") does for Windows and (soon) Linux. This is something I'd pay for. I'll be following that development. Best of luck and may the Python force be with you. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From bob at redivi.com Mon Feb 14 19:00:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 19:00:07 2005 Subject: [Pythonmac-SIG] Re: another point..porting... In-Reply-To: <1d1957564877d52ca2785fbf59466bcd@bellsouth.net> References: <20050214173713.4AAF81E400D@bag.python.org> <1d1957564877d52ca2785fbf59466bcd@bellsouth.net> Message-ID: <7182479683027bd778a55fb685e08581@redivi.com> On Feb 14, 2005, at 12:49 PM, Andrew Meit wrote: > > On Feb 14, 2005, at 12:37 PM, pythonmac-sig-request@python.org wrote: > >> Well, I can just see Troy sitting at his computer reading the above >> and saying, "I rest my case." :-) > -- and for me too... :-( > > Here is another bone to chew on: porting stuff to Python...I don't > find anything to help make the transition of a Gui/data from let say > Revolution/RB or anything else to Python... > Having to start from scratch does not appeal to a newbie ;-) And having to reverse engineer proprietary formats doesn't normally appeal to an open source developer ;) -bob From Chris.Barker at noaa.gov Mon Feb 14 19:02:31 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 19:03:22 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> References: <20050209040616.65CF71E400C@bag.python.org><7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> Message-ID: <4210E7B7.7080106@noaa.gov> Roger Binns wrote: > My wxPython code is hand coded. I haven't found any of the design > tools to be much good for non-trivial projects. For example try > doing something like the wxPython demo with one of them. They > also don't work well if you have custom widgets, which is a lot of my UI. This brings up a really good point about GUI GUI Builders: They tend to discourage the use of custom widgets, which is a really a bad thing. That's why I don't use them. Maybe someone will developer one that works really well with custom widgets some day... I'm guessing that would be a tool specifically developed for, and written in, python. That way you could easily add your custom widget to the "pallet" of available widgets, and it could be a first class citizen. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Mon Feb 14 19:16:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 19:16:43 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <4210E7B7.7080106@noaa.gov> References: <20050209040616.65CF71E400C@bag.python.org><7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <420CED1B.4030401@anvil.nrl.navy.mil> <001601c51062$43d243e0$3501a8c0@rogersqyvr14d3> <4210E7B7.7080106@noaa.gov> Message-ID: On Feb 14, 2005, at 1:02 PM, Chris Barker wrote: > Roger Binns wrote: >> My wxPython code is hand coded. I haven't found any of the design >> tools to be much good for non-trivial projects. For example try >> doing something like the wxPython demo with one of them. They >> also don't work well if you have custom widgets, which is a lot of my >> UI. > > This brings up a really good point about GUI GUI Builders: They tend > to discourage the use of custom widgets, which is a really a bad > thing. That's why I don't use them. Maybe someone will developer one > that works really well with custom widgets some day... I'm guessing > that would be a tool specifically developed for, and written in, > python. That way you could easily add your custom widget to the > "pallet" of available widgets, and it could be a first class citizen. Cocoa and Interface Builder get this right. In IB, there's a "Custom Class" tab in the info window when you're inspecting an instance of something, and you can choose any subclass. If you want to expose additional configuration features or a nice display for this widget, you can implement that in an Interface Builder palette. Of course, this is only really useful for Mac OS X specific development, but I would definitely recommend that developers of tools for other frameworks look to Cocoa for inspiration. It's extremely mature and flexible. -bob From wolfgang.keller.nospam at gmx.de Mon Feb 14 19:46:50 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Mon Feb 14 19:46:56 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <6be9955f0f433c95747950135401a8cb@digitalgoods.com> References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> Message-ID: > 3a Command R can wait for the third tier because I have a trick: I > run a script "onchange.py python somefile.py" which runs somefile.py > whenever I save the file. But a newbie wouldn't know how to create > this script. Stakeout? Best regards Wolfgang Keller From bob at redivi.com Mon Feb 14 19:50:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 19:50:58 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> Message-ID: <1c39cc340401d7355073ff682c3bd54e@redivi.com> On Feb 14, 2005, at 1:46 PM, Wolfgang Keller wrote: >> 3a Command R can wait for the third tier because I have a trick: I >> run a script "onchange.py python somefile.py" which runs somefile.py >> whenever I save the file. But a newbie wouldn't know how to create >> this script. > > Stakeout? For reference: http://michael-mccracken.net/blog/blosxom.pl/computers/mac/programming/ meetWatch.html -bob From Chris.Barker at noaa.gov Mon Feb 14 19:55:54 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 19:56:45 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <4210DFE3.2000700@anvil.nrl.navy.mil> References: <4210DFE3.2000700@anvil.nrl.navy.mil> Message-ID: <4210F43A.6050108@noaa.gov> Louis Pecora wrote: > P.S. I have not yet had time to try out Chris Barker's packaging of > matplotlib. I hope to do that later this month, but BIG KUDOS to him > for trying to make the code available to more people. Gee thanks! As it turns out, Robert Kern is working on MacEnthon, which will supersede anything I've done, and hopefully will be out soon. In the meantime, you can get my package from Bob's web site: http://undefined.org/python/packages.html -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Mon Feb 14 20:02:13 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 20:03:03 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: References: <20050213155914.A151F1E400E@bag.python.org> <420F8A17.90407@wordtech-software.com> <31ac537c05021309309146b71@mail.gmail.com> Message-ID: <4210F5B5.2080502@noaa.gov> thor wrote: >> Well, that is a good point. I suppose everyone will have a differing >> opinion on that, particularly in terms of goals. For me, I'd like to >> see a single package, which includes a GUI designer, script editor >> with colorizing, debugger, interactive console, some sort of module >> browser for functions and syntax, resource viewer, something similar >> to package manager... and a basic set of modules for x-plat >> development work. Then, some tool which helps to output the whole >> thing as a runtime package. > > I wholly agree that this would be a utopian environment! I actually don't think this would be utopia for me, which is think is quite relevant because it's people like me that develop these things. It's not that I wouldn't like things nicely integrated, it's that I want a choice of tools. In the above imagined environment, you've just selected the following: Editor GUI toolkit console packaging tool Many of us like to mix and match these. the editor and GUI toolkit being the biggest ones. While a really nice Python friendly editor would be great, it wouldn't be great for me unless it was also a really nice editor for all the other text I need to edit. That's why I use Xemacs. I don't' even like it much, but I like that it has a powerful mode available for EVERYTHING I ever need to edit. Same for GUI toolkit, Whatever toolkit this fabulous IDE uses, there are going to be a lot of us that want a different one. Also, I've never seen a GUI builder that was as productive for me as writing the code by hand (at least if I have something like wxPython's sizers to do layout for me) I think that's why the editor+terminal+GUI-toolkit-of-choice has ended up being the de-facto environment for Python development One more note: I've found that there is a big difference between "Productivity Usability": how productive one is with a give tool over the long term and "Learn to Usability": how easy it is to learn, and get something done quickly. The former is what really matters for a tool you use a lot. The later is what really matters when you trying to sell something new. While the two types of usability are not mutually exclusive, I think they are orthogonal. That is you can have any amount of either couples with any amount of the other. Obviously lots of both is the ideal. However, I've found that commercial products often have lots of Learn-to-Usability, because you need that to sell a product, while open source products tend to have a lot of Productivity-Usability, because the people developing them need that, and don't need to learn it. One example I've seen a lot in the open source world is people writing to a mailing list, looking for a good tutorial. If it doesn't exist, many folks offer to write one as they learn, so that others will have it in the future. This is the true spirit of open source. However, most of them only get half-finished, because by the time the would-be author has learned enough to finish it, they don't' need it any more, and the motivation is gone. > No way of > drawing > 2D in python and use wxPython. While you can't currently use PyGame, there are plenty of ways of drawing on a 2-d canvas. Also, I know there are some folks that have looked at integrating PyGame and wxPython. I don't know how far they got, but it's certainly possible. > Solutions: > - Do 2D stuff in OpenGL (quite awkward) as pyOpenGL works with wxPython > - Don't use wxPython but native libraries on each of the 3 platforms I > want to write for. > > For this reason I am now using Java and I draw on a Canvas What kind of Canvas do you use with Java? I've seen people looking for a Java2d like Canvas for wxPython, is that what you're using? I've written the FloatCanvas class for wxPython, which provides much (but certainly not all) the functionality you might be looking for. At the moment, it is very vector graphics oriented, but adding bitmap graphics would be pretty trivial, depending on your needs. > A workable > environment for what I wanted to do without luck. I'm curious what you mean by "environment" in this case. Environment: as in IDE, or Environment as it collection of libraries like GUI toolkit, fast bitmap graphics, 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@noaa.gov From Chris.Barker at noaa.gov Mon Feb 14 20:05:25 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 20:06:15 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <524fb7f6d8137074a6030e621061a4a0@redivi.com> References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> <524fb7f6d8137074a6030e621061a4a0@redivi.com> Message-ID: <4210F675.6060904@noaa.gov> Bob Ippolito wrote: >> 4. AnyGui seemed like a really good idea to me. > > > Lots of good ideas never get the attention and effort they deserve. Except that AnyGui was never a good idea. A wrapper around a wrapper around a wrapper around a ..... just too much! As far as I can tell, there are two good ideas: 1) a toolkit written from scratch that draws it's own stuff on all platforms. To get performance, much of needs to be written in a lower level language: al la QT, GTK, Fox, etc.... 2) a toolkit that wraps the native widgets on all platforms, also needs to be written largely in a lower level language: al la wxWidgets. What would be nicer than any of the existing alternatives is one written specifically for Python. The problem with that is that it has a smaller audience, so may never get done. PyGui has promise, but has a long way to go. http://nz.cosc.canterbury.ac.nz/~greg/python_gui/ > For IDEs written in Python, in-process interpreters and > debuggers can cause the IDE to crash, halt, or behave strangely. > Unfortunately this is common practice. Very good point. This locks you into using the same GUI toolkit that the IDE uses, severely limiting the market. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From hengist.podd at virgin.net Mon Feb 14 20:29:15 2005 From: hengist.podd at virgin.net (has) Date: Mon Feb 14 20:29:29 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies Message-ID: Bob Ippolito wrote: > > MS builds software that way cos they like to get their users locked into > > a perpetual upgrade cycle from which they can make money, but what's > > OSS's excuse? > >Maybe because in many cases, the users are the developers and adding >those 20%s together makes for some big ugly mess. I'm not sure that qualifies as an excuse; more making their bed and lying in it. :) > > Furthermore, those users aren't locked into a single fixed solution > > for, say, building GUIs: as long as wxPython, PythonCard, etc. provide > > compatible components they can plug in whichever one they want. > >Personally, I hope that developers See The Light and do interface >building in a separate but integrated application like Xcode and >Interface Builder. Exactly. Or separate, integrateable components that plug into a common base framework. That was the idea behind OpenDoc, for example: the user's work is more important than the tools, so make it the center of attention by using a document-oriented model instead of an application-oriented one. Either way though the technical goal is exactly the same: keep the coupling between components as loose as possible. That's the _key_ to getting the design right: decoupling each functional area from the others. The rest is just finding the slickest, most convenient presentation. Unfortunately, I think most folk are only thinking about the presentation when they 'design' their system, and so they miss this. They get the form looking almost right superficially, but they don't get the substance. And then they wonder why they can't get the form any better, and why it starts falling apart when they try to take it any further. > > Python's myriad web frameworks are in exactly the same situation, btw > >I think WSGI (pep 333) is a good step to fixing this problem. If you >target WSGI, at least you can shoehorn your app into a giant framework >when you need one. If I understand it correctly, WSGI decouples the app framework from the web server, which is a good thing in itself. It doesn't do anything to address the pathological kitchen sink-ism within the rest of the web-app framework, however. I think you'd need a chainsaw for that. > > I've never understood what the obsession with building every > > conceivable feature into the application core, > >I think this is largely caused by complexity of the alternative and the >convenience of doing it in this way. Developer convenience up to a point, yes. It requires less up-front planning and major direction changes: just jump in and write some code. Yet the same could be said for procedural vs OO construction, so why are developers seeing the advantages of modular design in the small but still missing it so often in the large? >The problem with the Unix model is that processes only know how to >exchange raw data (sockets, pipes, files). In lots of cases you want >to exchange a higher level representation of information, and there >aren't a whole lot of easy ways to do that. But there are ways. OpenDoc was built upon Apple events, for example. And assuming you only have Python talking to Python then you don't even need something that complex. It's not like there isn't prior art to study and take ideas from. >I'm pretty sure that these >large frameworks suffer from the same problem. It's much easier to >exchange high level representations of data with yourself than it is to >exchange them with someone else.. It's interesting that even MS are now moving away from the DCOM approach and towards an Apple event/Apple Event Object Model approach. I think Apple were definitely onto something with these: it's all about where you make the split, and finding the right point makes the difference between moving Mohammed or moving the mountain. >that, and it's much easier to design >something ad-hoc if you don't concern yourself with keeping things >modular. Of course. I often start out that way myself; it's hard to know what kind of high-level structure you're going to need if it's your first time exploring this particular problem. The trouble sets in when an initially ad-hoc design doesn't bother to improve its internal organisation as it grows; if you don't keep that burgeoning complexity under control then sooner or later the whole thing degenerates into a big ball of mud. It's a great very-short-term strategy, but an ultimately counter-productive stinker if you're planning to be in for the long haul and fail to replace it ASAP. And it seems that very often programmers never do get around to that 'rebuild and replace' stage, because as soon as they've reached working code it's considered 'done', and to then throw that code away and start all over again is anathema. Coming from a fine art background, I _know_ that if you've a day to draw a life picture, then the best way to spend that time is 'wasting' the first half on throwaway sketches and only sitting down to the final version in the final few remaining hours, not spend all day hammering away at this one single drawing from 9 till 5. You mention py2app, but must realise yourself that py2app's potential for growth and improvement is itself ultimately constrained by the framework you've built it in, i.e. distutils. And, conversely, distutils' room for improvement is severely constrained by the need not to rock the boat for those that have already built upon it. The longer code is left to harden, the harder it will be to do anything to change it later, so best spend as much energy as you can as early on as possible to ensure that when it does set, it's not in a form you're going to regret years from now. (Unless you're the perverse sort that actively enjoys doing heroic total rewrites for the rest of your life...:p) IDEs are exactly the sort of problem that's crying out for exactly this sort of hard, hard tearing down and rebuilding approach because right throughout their lives there's going to be this strong requirement to add new features, specialist tools, remove obsoleted tools, replace, extend, rebuild, etc. One really good, extensible IDE application framework and we might not be in this foolish situation where there's a dozen all "nearly done" IDEs, all with a huge amount of overlapping functionality, which means duplication of effort; i.e. a waste of time and energy. Folk seem to acknowledge there's a constant underlying problem at work, so why don't they spend more time trying to put that right instead of reinventing the same old mistakes as before? It should be a wonderfully rich and tasty problem for those that fancy the exercise, and I'm sure there's folk that would; maybe not as instantly glamorous as "oh look I just made a yet-another-editor", but no passing flash in the pan either if/when they manage to pull it off. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Feb 14 20:32:49 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 20:33:39 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <4210F675.6060904@noaa.gov> References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> <524fb7f6d8137074a6030e621061a4a0@redivi.com> <4210F675.6060904@noaa.gov> Message-ID: On Feb 14, 2005, at 2:05 PM, Chris Barker wrote: > Bob Ippolito wrote: > >>> 4. AnyGui seemed like a really good idea to me. >> Lots of good ideas never get the attention and effort they deserve. > > Except that AnyGui was never a good idea. A wrapper around a wrapper > around a wrapper around a ..... just too much! As far as I can tell, > there are two good ideas: > > 1) a toolkit written from scratch that draws it's own stuff on all > platforms. To get performance, much of needs to be written in a lower > level language: al la QT, GTK, Fox, etc.... > > 2) a toolkit that wraps the native widgets on all platforms, also > needs to be written largely in a lower level language: al la > wxWidgets. > > What would be nicer than any of the existing alternatives is one > written specifically for Python. The problem with that is that it has > a smaller audience, so may never get done. PyGui has promise, but has > a long way to go. > > http://nz.cosc.canterbury.ac.nz/~greg/python_gui/ While I agree with the assertion that a large part needs to be written in a lower level language, I don't agree that wrapping a wrapper is going to be a performance problem. All the tight loops are already in the lower level and anything on top of that is going to be insignificant unless it's done horribly wrong. Especially when using native widgets. Ideally I'd propose a design like this: 1. Low level C/ObjC/C++ implementation (probably the native platform's toolkit, but could be wxWidgets, Qt, etc.) 2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate flexibility, minimal non-Python code) 2.5. Mid-level Python layer if necessary for a sane implementation of the high-level (might be overkill for PyObjC given how similar Objective-C and Python are) 3. High level Python layer (exposes a nice interface for Python developers) The benefit of an approach such as ctypes or PyObjC is that there's essentially nothing you can't do from Python. The price you pay is that the interpreter can crash if you do the wrong thing (this happens in platform code, anyway), and due to the nature of FFI such things can be confusing to track down from the platform debugger if you don't know what you're looking for. Appropriate safeguards would be installed in the high level layer, rather than in C/C++ code. Wrappers generated with tools such as SWIG, sip, bgen, and Boost Python could also fit in for layer 2 -- but I think that a runtime solution is going to be better in the long run. > > For IDEs written in Python, in-process interpreters and >> debuggers can cause the IDE to crash, halt, or behave strangely. >> Unfortunately this is common practice. > > Very good point. This locks you into using the same GUI toolkit that > the IDE uses, severely limiting the market. Not only does it lock you into a GUI toolkit, but the crashes, halting, and strange behavior is definitely a very big problem. On Mac OS X especially, where each process can have exactly one or zero menus. -bob From kevino at tulane.edu Mon Feb 14 20:56:52 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Mon Feb 14 20:57:15 2005 Subject: [Pythonmac-SIG] Re: Mac Python User Newbies In-Reply-To: <4210F5B5.2080502@noaa.gov> References: <20050213155914.A151F1E400E@bag.python.org> <420F8A17.90407@wordtech-software.com> <31ac537c05021309309146b71@mail.gmail.com> <4210F5B5.2080502@noaa.gov> Message-ID: Hi Chris, I promised myself I'd stay out of this discussion, but I think you hit on a good point and wanted to expand on it. On Feb 14, 2005, at 11:02 AM, Chris Barker wrote: [snip] > Same for GUI toolkit, Whatever toolkit this fabulous IDE uses, there > are going to be a lot of us that want a different one. Also, I've > never seen a GUI builder that was as productive for me as writing the > code by hand (at least if I have something like wxPython's sizers to > do layout for me) > > I think that's why the editor+terminal+GUI-toolkit-of-choice has ended > up being the de-facto environment for Python development Ah, but in the world of Interface Builder, or VB, or RealBasic, people mostly use what's given to them. How would you explain those trends then? I think your choice was made predicated on the available tools, not because there isn't any one tool that would/could meet your needs. (It just doesn't exist yet. ;-) The point being that in Python, AFAICT, editor+terminal+GUI-toolkit-of-choice is the only environment available for most, thus it is the de-facto standard. But you make a very good point below which ties into this... > One more note: I've found that there is a big difference between > "Productivity Usability": how productive one is with a give tool over > the long term > and > "Learn to Usability": how easy it is to learn, and get something done > quickly. > > The former is what really matters for a tool you use a lot. The later > is what really matters when you trying to sell something new. While > the two types of usability are not mutually exclusive, I think they > are orthogonal. That is you can have any amount of either couples with > any amount of the other. Obviously lots of both is the ideal. However, > I've found that commercial products often have lots of > Learn-to-Usability, because you need that to sell a product, while > open source products tend to have a lot of Productivity-Usability, > because the people developing them need that, and don't need to learn > it. Bingo! :-) This is a very good point which many people overlook, and which leads to many, many confused usability discussions, because one group is arguing the need for Learn-To Usability and the other is arguing the need for Productivity Usability. (As is mostly the case in this thread, too.) But I would argue both are needed, because you do want to actually "sell" Python to people. (At least I do!) I think of it like riding a bike. When you *start* riding a bike, "Learn to Usability" is key, so you have training wheels. The wheels basically just show you that, hey, this isn't impossible. Now, eventually you get good at riding a bike and training wheels are a hinderance, so you take them off, because "Productivity-Usability" becomes key to you. Now, I don't think it's a perfect analogy because I think software can be easy to use without being crippling, as training wheels are. I think software can tackle Learn-To-Usability through a combination of intelligent defaults (i.e. you have choices, but it makes the most likely choice for you at first by default) and excellent ease-of-use, including usable interfaces, documentation and training resources. It will never be for everyone (maximizing efficiency usually means choosing a tool for exactly that) but I think there can be one tool that meets the needs of most people. > One example I've seen a lot in the open source world is people writing > to a mailing list, looking for a good tutorial. If it doesn't exist, > many folks offer to write one as they learn, so that others will have > it in the future. This is the true spirit of open source. However, > most of them only get half-finished, because by the time the would-be > author has learned enough to finish it, they don't' need it any more, > and the motivation is gone. Right, because there's no real reward to speak of, aside from maybe a thank you. So the question is: how do you encourage people to actively participate in the community, especially in the sense of a major project like an IDE? And here, despite the many, many messages in this thread, is where IMHO this discussion gets stuck - because we don't have the answer to that. Is the PSF going to offer some incentive for a polished, well-documented, cross-platform, "Learn-To Usable" RAD tool that incorporates GUI design? If so, I think someone will step up and make this happen. (Heck, I'd be happy to work on such a tool, in fact, I've already got some ideas for it.) If not, we're just adding more choice to the equation (which isn't good for Learn-To) and we're just going back and forth about which is more important, Learn-To-Usability or Productivity-Usability, which is one of those Coke or Pepsi discussions. ;-) In any case, to me the key issue is that there are tools out there for the advanced developers, but the people who need the tools most but don't have them are the Learn-To folks. Thanks, Kevin From bob at redivi.com Mon Feb 14 21:03:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 21:04:14 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: Message-ID: <02a33b62a8d8793e4de626d8e36bdb80@redivi.com> On Feb 14, 2005, at 2:29 PM, has wrote: > Bob Ippolito wrote: > >> > MS builds software that way cos they like to get their users >> locked into >> > a perpetual upgrade cycle from which they can make money, but >> what's >> > OSS's excuse? >> >> Maybe because in many cases, the users are the developers and adding >> those 20%s together makes for some big ugly mess. > > I'm not sure that qualifies as an excuse; more making their bed and > lying in it. :) Well the people writing these things obviously write it such that it suits them, so perhaps they find this bed to be comfortable? >> > Furthermore, those users aren't locked into a single fixed solution >> > for, say, building GUIs: as long as wxPython, PythonCard, etc. >> provide >> > compatible components they can plug in whichever one they want. >> >> Personally, I hope that developers See The Light and do interface >> building in a separate but integrated application like Xcode and >> Interface Builder. > > Exactly. Or separate, integrateable components that plug into a common > base framework. That was the idea behind OpenDoc, for example: the > user's work is more important than the tools, so make it the center of > attention by using a document-oriented model instead of an > application-oriented one. Either way though the technical goal is > exactly the same: keep the coupling between components as loose as > possible. That's the _key_ to getting the design right: decoupling > each functional area from the others. The rest is just finding the > slickest, most convenient presentation. Unfortunately, I think most > folk are only thinking about the presentation when they 'design' their > system, and so they miss this. They get the form looking almost right > superficially, but they don't get the substance. And then they wonder > why they can't get the form any better, and why it starts falling > apart when they try to take it any further. Well, separate processes is necessary.. a component based model can't work, because certain components just can't live in the same process with one another. >> > I've never understood what the obsession with building every >> > conceivable feature into the application core, >> >> I think this is largely caused by complexity of the alternative and >> the >> convenience of doing it in this way. > > Developer convenience up to a point, yes. It requires less up-front > planning and major direction changes: just jump in and write some > code. Yet the same could be said for procedural vs OO construction, so > why are developers seeing the advantages of modular design in the > small but still missing it so often in the large? I think in a lot of cases this may be somewhat incorrect. A lot of times you have a really modular framework, but it's not easy to rip apart into its constituent components and install just what you want (Twisted 1.x is an example of this). So what? Although Twisted 2.x is moving away from this model, it's to accommodate a more flexible release schedule, not to split it up for the sake of splitting it up. In some cases, such as your own appscript/aem/etc., this kind of external componentization is more of a hassle than anything else. You're releasing them on basically the same schedule, but you make the user worry about dealing with them separately. I decided to go the other way with py2app. It has four distinct components, but it makes little sense to distribute them separately, so I don't. altgraph/modulegraph will eventually be available separately for the sake of other platforms, but macholib, py2app, and bdist_mpkg will forever be distributed in a single unit (unless of course some of it ends up in the standard library -- which hopefully at least altgraph/modulegraph will someday). >> The problem with the Unix model is that processes only know how to >> exchange raw data (sockets, pipes, files). In lots of cases you want >> to exchange a higher level representation of information, and there >> aren't a whole lot of easy ways to do that. > > But there are ways. OpenDoc was built upon Apple events, for example. > And assuming you only have Python talking to Python then you don't > even need something that complex. It's not like there isn't prior art > to study and take ideas from. I've never seen it done in Python really easily. It's like programming with threads, people think it's easy, but then a piano falls on their head a couple hundred lines of code later cause they didn't truly understand what they were getting into. There is certainly no standard library support for such a feature, other than marshal and pickle, but those are only formats for data exchange, they do nothing to help you exchange the data. >> I'm pretty sure that these >> large frameworks suffer from the same problem. It's much easier to >> exchange high level representations of data with yourself than it is >> to >> exchange them with someone else.. > > It's interesting that even MS are now moving away from the DCOM > approach and towards an Apple event/Apple Event Object Model approach. > I think Apple were definitely onto something with these: it's all > about where you make the split, and finding the right point makes the > difference between moving Mohammed or moving the mountain. And we all know how well Apple has been implementing Apple Events in its more recent applications. It's simply Not That Easy to do so, so it's simply not done well or not done at all. >> that, and it's much easier to design >> something ad-hoc if you don't concern yourself with keeping things >> modular. > > Of course. I often start out that way myself; it's hard to know what > kind of high-level structure you're going to need if it's your first > time exploring this particular problem. The trouble sets in when an > initially ad-hoc design doesn't bother to improve its internal > organisation as it grows; if you don't keep that burgeoning complexity > under control then sooner or later the whole thing degenerates into a > big ball of mud. It's a great very-short-term strategy, but an > ultimately counter-productive stinker if you're planning to be in for > the long haul and fail to replace it ASAP. Well yeah, you do have to clean up your mess every so often. > And it seems that very often programmers never do get around to that > 'rebuild and replace' stage, because as soon as they've reached > working code it's considered 'done', and to then throw that code away > and start all over again is anathema. Coming from a fine art > background, I _know_ that if you've a day to draw a life picture, then > the best way to spend that time is 'wasting' the first half on > throwaway sketches and only sitting down to the final version in the > final few remaining hours, not spend all day hammering away at this > one single drawing from 9 till 5. Lots of people think that throwing away an application and starting over is a real mistake. Joel Spolsky has an article on this that everyone likes to quote. > You mention py2app, but must realise yourself that py2app's potential > for growth and improvement is itself ultimately constrained by the > framework you've built it in, i.e. distutils. And, conversely, > distutils' room for improvement is severely constrained by the need > not to rock the boat for those that have already built upon it. The > longer code is left to harden, the harder it will be to do anything to > change it later, so best spend as much energy as you can as early on > as possible to ensure that when it does set, it's not in a form you're > going to regret years from now. (Unless you're the perverse sort that > actively enjoys doing heroic total rewrites for the rest of your > life...:p) Obviously you've not really looked much at the source of py2app. The only part of it that is really bound to distutils is the "user interface". It's done this way because it's a familiar interface (lower learning curve for developers with relevant experience) and it provides features that I don't have to implement on my own. Command line parsing, extension building, etc. Everything it does could be done by plugging all of its constituent components together without distutils, but there's no real good reason to do that. I hope people don't start doing it this way though, because I am only willing to support the distutils interface. I reserve the right to refactor the other layers without caring about compatibility with anything but itself. -bob From Chris.Barker at noaa.gov Mon Feb 14 21:06:54 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 21:07:45 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> <524fb7f6d8137074a6030e621061a4a0@redivi.com> <4210F675.6060904@noaa.gov> Message-ID: <421104DE.7070005@noaa.gov> Bob Ippolito wrote: > On Feb 14, 2005, at 2:05 PM, Chris Barker wrote: >> Except that AnyGui was never a good idea. A wrapper around a wrapper >> around a wrapper around a ..... just too much! > While I agree with the assertion that a large part needs to be written > in a lower level language, I don't agree that wrapping a wrapper is > going to be a performance problem. It's not so much performance as complexity and the lowest-common-denominator problem. I"m pretty sure AnyGui is dead now anyway, and I've written a couple longer rants about this, but consider this: AnyGuiTK is a Python wrapper around a Python wrapper around another scripting language, around and extension written in C, which is wrapped about the X11 API, which is emulated on other platforms. AnyGuiWx is a Python wrapper around a SWIG wrapper around a C++ toolkit that is a wrapper around a native GUI toolkit. When there's a bug, you've got a lot of layers that may be responsible! It comes down to why? AnyGui has a flawed reason for being. NO one should care what toolkit is underlying their app at the bottom. What they should care about is; The API The Look and Feel The Features The Platform support AnyGUI had some potential to improve the API of the underlying toolkits but that's it. It makes much more sense to just write a better API wrapper around a toolkit that meets your other needs. > Ideally I'd propose a design like this: > > 1. Low level C/ObjC/C++ implementation (probably the native platform's > toolkit, but could be wxWidgets, Qt, etc.) wouldn't it have to be it it were X-platform? > 2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate flexibility, > minimal non-Python code) What's FFI ? > 2.5. Mid-level Python layer if necessary for a sane implementation of > the high-level (might be overkill for PyObjC given how similar > Objective-C and Python are) Good point. The better the API you're wrapping, the less need for this. > 3. High level Python layer (exposes a nice interface for Python developers) This sounds a lot like PythonCard, actually. 1) wxWidgets 2) SWIG--wxPython 2.5) Some of the stuff wxPython adds: better dynamic binding syntax, OGL, FloatCanvas, other high level widgets. 3) That's what PythonCard itself is. > Wrappers generated with tools such as SWIG, sip, bgen, and Boost Python > could also fit in for layer 2 -- but I think that a runtime solution is > going to be better in the long run. hmm. Is it possible to have a run-time solution for the more static languages like C++? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From wolfgang.keller.nospam at gmx.de Mon Feb 14 21:08:40 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Mon Feb 14 21:08:46 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> Message-ID: <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> > I tried SPE, PythonCard, PyOxice, PyPE, eclipse and > wing (under x11). Supposed to run on MacOS X: Eric3, Boa Constructor, DrPython (?), Leo (not exactly a conventional IDE) Maybe someday as well: BlackAdder It doesn't seem to me that there are no IDEs available for Python on MacOS X (or any other common system), but rather the opposite is true imho: There are so many different ones that in fact the development ressources get scattered instead of concentrated and in the end none gets the effort that would be required to make it "rock-solid" and "newbie-proof". And (from my outsider perspective as a "constant newbie") this seems to be somehow symptomatic for the Python "community" altogether: Usually for each "problem" to solve, there are several implementations competing with each other. Other examples besides IDEs: DB modules, web frameworks, ORMs... If for each given problem one implementation was chosen as "the official one" and efforts would be concentrated on "hardening" this one and merging in good features/concepts from the others as far as possible, newbies would maybe get less confused and could maybe also get more productive more quickly due to "better quality" of the "batteries included" in python... Best regards Wolfgang Keller From Chris.Barker at noaa.gov Mon Feb 14 21:27:18 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 21:28:09 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> Message-ID: <421109A6.8050300@noaa.gov> Wolfgang Keller wrote: > If for each given problem one implementation was chosen as "the official > one" To some extent, while Guido could endorse something (which is more or less the case with IDLE), there is no way to name something the "official one", and even if there were, there's nothing to stop folks from going out on their own anyway. Thus is the nature of open-source. How many Linux distros are there? Remember that most of this stuff is written by folks who are "scratching an itch". The scratching itself is as much the point as getting rid of the itch, and many people find it much more satisfying to do something in just their own way than adapting to other's ideas and style. Very little becomes standard by declaration: If someone makes something really good, it could evolve into a standard. By the way, I've often thought of forming a company that would produce just what we've been talking about here, but with a bit of a twist: A set of Python environments for doing specialized development. Some ideas are: --A database app environment, as easy to use as FileMaker, but with a real language at it's core. --A scientific programming environment, everything that MATLAB gives you, but again, with a real language at the core. --Maybe a web framework. --And you'd probably need to do a general purpose IDE as well. Anyone have any venture capital? I know that there are open-source versions of all of these: SciPy, Dabo, Pythoncard, Zope, etc., but they don't have the polish that you'd need to attract the type of newbies that are at the core of this thread. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Mon Feb 14 21:46:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 21:47:16 2005 Subject: [Pythonmac-SIG] Re: Mac newbie In-Reply-To: <421104DE.7070005@noaa.gov> References: <20050213200037.B2E861E4012@bag.python.org> <6be9955f0f433c95747950135401a8cb@digitalgoods.com> <524fb7f6d8137074a6030e621061a4a0@redivi.com> <4210F675.6060904@noaa.gov> <421104DE.7070005@noaa.gov> Message-ID: On Feb 14, 2005, at 3:06 PM, Chris Barker wrote: > Bob Ippolito wrote: >> On Feb 14, 2005, at 2:05 PM, Chris Barker wrote: >>> Except that AnyGui was never a good idea. A wrapper around a wrapper >>> around a wrapper around a ..... just too much! > >> While I agree with the assertion that a large part needs to be >> written in a lower level language, I don't agree that wrapping a >> wrapper is going to be a performance problem. > > It's not so much performance as complexity and the > lowest-common-denominator problem. I"m pretty sure AnyGui is dead now > anyway, and I've written a couple longer rants about this, but > consider this: > > AnyGuiTK is a Python wrapper around a Python wrapper around another > scripting language, around and extension written in C, which is > wrapped about the X11 API, which is emulated on other platforms. > > AnyGuiWx is a Python wrapper around a SWIG wrapper around a C++ > toolkit that is a wrapper around a native GUI toolkit. > > When there's a bug, you've got a lot of layers that may be responsible! That happens anyway :) Only the AnyGui developers need to care about this. A typical user of wxPython isn't going to be able to track a bug down to Carbon any better than a hypothetical AnyGui user is going to be able to. > It comes down to why? AnyGui has a flawed reason for being. NO one > should care what toolkit is underlying their app at the bottom. What > they should care about is; > > The API > The Look and Feel > The Features > The Platform support > > AnyGUI had some potential to improve the API of the underlying > toolkits but that's it. It makes much more sense to just write a > better API wrapper around a toolkit that meets your other needs. And the API is the only one of those things that the underlying toolkit DOESN'T ultimately control! Though it of course can have a big influence w.r.t. thread safety and what should be asynchronous. The only fundamental difference between AnyGui and wxPython is that wxPython has a lot of C++ code (re: wxWidgets) where AnyGui would have a lot of Python code and relatively little platform code. >> Ideally I'd propose a design like this: >> 1. Low level C/ObjC/C++ implementation (probably the native >> platform's toolkit, but could be wxWidgets, Qt, etc.) > > wouldn't it have to be it it were X-platform? Well the difference is that a "native platform" could be either the actual platform toolkit, or something on top of said toolkit. For example, there's the Win32 API, and then anything on top of that (MFC, wxWidgets, etc.). >> 2. Thin Python FFI layer (i.e. ctypes or PyObjC -- ultimate >> flexibility, minimal non-Python code) > > What's FFI ? Foreign Function Interface >> 2.5. Mid-level Python layer if necessary for a sane implementation of >> the high-level (might be overkill for PyObjC given how similar >> Objective-C and Python are) > > Good point. The better the API you're wrapping, the less need for this. > >> 3. High level Python layer (exposes a nice interface for Python >> developers) > > This sounds a lot like PythonCard, actually. > 1) wxWidgets > 2) SWIG--wxPython > 2.5) Some of the stuff wxPython adds: better dynamic binding syntax, > OGL, FloatCanvas, other high level widgets. > 3) That's what PythonCard itself is. Yeah, I think PythonCard has the right approach for the layers that they control (2.5-3). wxPython/wxWidgets is something that I'd have approached differently, though at the time the projects were started the methods they used were most certainly the best or near-best ways to do it. >> Wrappers generated with tools such as SWIG, sip, bgen, and Boost >> Python could also fit in for layer 2 -- but I think that a runtime >> solution is going to be better in the long run. > > hmm. Is it possible to have a run-time solution for the more static > languages like C++? If you can do it for C you can do it for C++. The problem is that C has very few calling convention standards where C++ is much less standardized (though this is settling a bit). At worst, you would have a "cpptypes" that could only do magic for code generated by a particular compiler (e.g. gcc 3.3). The largest difference between Objective-C and C is that Objective-C compiles lots of RTTI (runtime type information) and makes it available to the objects themselves. C doesn't do this at all, all you have is the symbols in the symbol table, you don't even know if they're functions or globals. C++ is a hybrid, where a lot of this type information is actually in the symbol table, but not so easily available at runtime. The approach that you take with ctypes for C is to convert a lot of information from the headers into Python syntax, C++ you would take *some* information from the headers and translate into Python syntax (I haven't studied C++ compilation enough to be able to say what the scope of "some" is), and in Objective-C you need extremely little information from the headers (just constants, global variables, and functions -- basically cruft from the subset of Objective-C that is C -- which is fortunately not that popular in Objective-C code). =========== Objective-C =========== % class-dump Foundation.framework/Foundation // all the structure and union names and fields are tracked.. struct AEDesc { unsigned int descriptorType; struct OpaqueAEDataStorageType **dataHandle; }; // the protocols too @protocol NSCoding - (void)encodeWithCoder:(id)fp8; - (id)initWithCoder:(id)fp8; @end // and the classes @interface NSPlaceholderArray : NSArray { } - (id)initWithObjects:(id *)fp8 count:(unsigned int)fp12; - (id)init; - (id)initWithContentsOfFile:(id)fp8; - (id)initWithContentsOfURL:(id)fp8; - (unsigned int)count; - (id)objectAtIndex:(unsigned int)fp8; @end = C = % nm nm /usr/lib/libSystem.dylib /usr/lib/libSystem.dylib(dylib1.o): # this is the name of the compilation unit from which it came 90057ca0 t ___initialize_Cplusplus # lots of symbols and addresses.. no metadata about them beyond their name === C++ === % nm libstdc++.a libstdc++.a(bitset.o): 00000000 A _ZNKSt12_Base_bitsetILm1EE15_M_do_find_nextEmm.eh # really ugly names.. hmm! 00000000 A _ZNKSt12_Base_bitsetILm1EE16_M_do_find_firstEm.eh 0000005c T __ZNKSt12_Base_bitsetILm1EE15_M_do_find_nextEmm % nm libstdc++.a | c++filt3 libstdc++.a(bitset.o): 00000000 A _ZNKSt12_Base_bitsetILm1EE15_M_do_find_nextEmm.eh # presumably these are just "private" symbols 00000000 A _ZNKSt12_Base_bitsetILm1EE16_M_do_find_firstEm.eh 0000005c T std::_Base_bitset<1ul>::_M_do_find_next(unsigned long, unsigned long) # now this looks useful! const -bob From bob at redivi.com Mon Feb 14 21:52:25 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 21:52:32 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> Message-ID: <6f4b25918418391549855ee35f085977@redivi.com> On Feb 14, 2005, at 3:08 PM, Wolfgang Keller wrote: >> I tried SPE, PythonCard, PyOxice, PyPE, eclipse and >> wing (under x11). > > Supposed to run on MacOS X: > Eric3, Boa Constructor, DrPython (?), Leo (not exactly a conventional > IDE) Speaking of DrPython, I have an example of having it packaged in the py2app svn trunk.. but as it uses wxScintilla, it isn't really very fun to play with. > Maybe someday as well: > BlackAdder > > It doesn't seem to me that there are no IDEs available for Python on > MacOS > X (or any other common system), but rather the opposite is true imho: > There > are so many different ones that in fact the development ressources get > scattered instead of concentrated and in the end none gets the effort > that > would be required to make it "rock-solid" and "newbie-proof". > > And (from my outsider perspective as a "constant newbie") this seems > to be > somehow symptomatic for the Python "community" altogether: Usually for > each > "problem" to solve, there are several implementations competing with > each > other. Other examples besides IDEs: DB modules, web frameworks, ORMs... > > If for each given problem one implementation was chosen as "the > official > one" and efforts would be concentrated on "hardening" this one and > merging > in good features/concepts from the others as far as possible, newbies > would > maybe get less confused and could maybe also get more productive more > quickly due to "better quality" of the "batteries included" in > python... This generally happens eventually, it just takes time for one approach to be obviously better and good enough to become the official one. Or at least some standard way of doing things (DB-API, WSGI, importer protocol, etc.) -bob From meitnik at bellsouth.net Mon Feb 14 22:11:02 2005 From: meitnik at bellsouth.net (Andrew Meit) Date: Mon Feb 14 22:14:07 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 22, Issue 46 In-Reply-To: <20050214200415.D634D1E400D@bag.python.org> References: <20050214200415.D634D1E400D@bag.python.org> Message-ID: <46388a5f5e6db9fb90d7195abd78075a@bellsouth.net> On Feb 14, 2005, at 3:04 PM, pythonmac-sig-request@python.org wrote: > And it seems that very often programmers never do get around to that > 'rebuild and replace' stage, because as soon as they've reached > working code it's considered 'done', and to then throw that code away > and start all over again is anathema. Coming from a fine art > background, I _know_ that if you've a day to draw a life picture, then > the best way to spend that time is 'wasting' the first half on > throwaway sketches and only sitting down to the final version in the > final few remaining hours, not spend all day hammering away at this > one single drawing from 9 till 5. -- YES, I once, when much younger, did Type (known for my Gutenberg font work) and graphic design; and so "write and burn" method was carried over to my coding as second nature. However, I found out in programming world rarely was that method valued or wanted: "gotta ship, now". Which brings up another point: testing. Does python support robust testing tools or methods?? I code towards quality and so an IDE needs to support that goal. :-) Andrew -{Choose Life, Create hope, Nurture Love...}- From bob at redivi.com Mon Feb 14 22:14:45 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 22:15:31 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <421109A6.8050300@noaa.gov> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> Message-ID: <24847cd3cc77843b3c7ef329632d66a5@redivi.com> On Feb 14, 2005, at 3:27 PM, Chris Barker wrote: > Wolfgang Keller wrote: >> If for each given problem one implementation was chosen as "the >> official >> one" > > To some extent, while Guido could endorse something (which is more or > less the case with IDLE), there is no way to name something the > "official one", and even if there were, there's nothing to stop folks > from going out on their own anyway. Thus is the nature of open-source. > How many Linux distros are there? > > Remember that most of this stuff is written by folks who are > "scratching an itch". The scratching itself is as much the point as > getting rid of the itch, and many people find it much more satisfying > to do something in just their own way than adapting to other's ideas > and style. > > Very little becomes standard by declaration: If someone makes > something really good, it could evolve into a standard. > > By the way, I've often thought of forming a company that would produce > just what we've been talking about here, but with a bit of a twist: > > A set of Python environments for doing specialized development. Some > ideas are: > > --A database app environment, as easy to use as FileMaker, but with a > real language at it's core. > > --A scientific programming environment, everything that MATLAB gives > you, but again, with a real language at the core. > > --Maybe a web framework. > > --And you'd probably need to do a general purpose IDE as well. > > Anyone have any venture capital? > > I know that there are open-source versions of all of these: SciPy, > Dabo, Pythoncard, Zope, etc., but they don't have the polish that > you'd need to attract the type of newbies that are at the core of this > thread. I'm definitely interested in these things (more some than others), but I'm currently professionally committed to some other stuff. The real problem I'd have with this sort of business venture is doing it in a way that's compatible with open source, but still making enough money to keep doing it without spending too much time doing consulting. I'd definitely want to give these things away as liberally licensed open source, which might mean that it has to be done in the context of a non-profit foundation (like Chandler via OSAF). However, it might be possible to get away on a smaller scale by simply having a set of robust open source tools as the "lite" version, and a "pro" version with a couple nice extra features that isn't free (like the difference between OmniGraffle and OmniGraffle Pro). I've never seen the donation model work at the smaller scale. -bob From wolfgang.keller.nospam at gmx.de Mon Feb 14 22:29:09 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Mon Feb 14 22:29:17 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <421109A6.8050300@noaa.gov> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> Message-ID: > To some extent, while Guido could endorse something (which is more or > less the case with IDLE), there is no way to name something the > "official one", and even if there were, there's nothing to stop folks > from going out on their own anyway. Sure, but... > Thus is the nature of open-source. > How many Linux distros are there? ...how many FreeBSD distributions are there? And what is the consequence for the users, developers, administrators of systems running on FreeBSD compared to Linux? *duck* >:-> Best regards Wolfgang Keller From troy.rollins at gmail.com Mon Feb 14 22:29:26 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Mon Feb 14 22:29:29 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <421109A6.8050300@noaa.gov> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> Message-ID: <31ac537c050214132963f694b6@mail.gmail.com> > > I know that there are open-source versions of all of these: SciPy, Dabo, > Pythoncard, Zope, etc., but they don't have the polish that you'd need > to attract the type of newbies that are at the core of this thread. > True enough. There have been no shortage of excellent thoughts and suggestions, but I think that what the new user really want, more than "free", is something which provides a "raodmap to being productive." I am not an inexperienced developer. I develop non-trivial applications with high-level languages... one example ... I've actually written that same application, or large portions of it in several different programming languages, and have multiple custom versions of it running in some extremely high-end systems of its kind. I wouldn't have a clue how to write that application in Python. The bits and pieces of logic I can imagine without difficulty... bits an pieces of scripts, no problem... but the whole project? It is just too big, with too many lines of code for me to manage with a text editor and the terminal. Many of the (very generous) free tools that have been written by community members are fabulous examples of the possible... but are not really a working environment which can be trusted for large projects. And perhaps, (as I think Bob mentioned) therein lies the problem. If all those options didn't exist, people like me would spend the first several months trying to find something which works like the (payware) tools we are accustomed to. What I *want* in an environment like Flash, Director, REALbasic, etc. which is python-based. I've seen a lot of great tools so far, but none of them match the capabilities of these tools in terms of refinement, as well as being supportive of users of all levels. Director, as an example, is pretty friendly to newbies, but it is also used by gurus on a level of any Python guru. There is nothing to say that an IDE must be restrictive, either. For instance, I love the Director IDE, but I often use SubEthaEdit to edit my Lingo scripts... Director does not demand that it be my only script editor. So far, Eclipse, and things like Xored TruStudio are very robust and look like they are heading in the right direction, for those of us who don't need to be spoonfed, but also like a productive tool to help keep our thoughts together while we build our products. I plan to research some of the latest great suggestions, and I appreciate all the comments. I do hope that these long threads are useful to others as well, and hopefully that the community gains insight into extending itself out to other potential "markets" beyond the "pioneer crowd" it currently enjoys. Cheers. -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From wolfgang.keller.nospam at gmx.de Mon Feb 14 22:32:27 2005 From: wolfgang.keller.nospam at gmx.de (Wolfgang Keller) Date: Mon Feb 14 22:32:34 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <6f4b25918418391549855ee35f085977@redivi.com> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <6f4b25918418391549855ee35f085977@redivi.com> Message-ID: <5gbg7gooc4lr$.veypcrab1an8$.dlg@40tude.net> > Speaking of DrPython, I have an example of having it packaged in the > py2app svn trunk.. but as it uses wxScintilla, it isn't really very fun > to play with. Dumb question: What's wrong with wxScintilla? Doesn't SPE use it as well? What's Boa using? Best regards, Wolfgang Keller From bob at redivi.com Mon Feb 14 22:39:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 22:39:48 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 22, Issue 46 In-Reply-To: <46388a5f5e6db9fb90d7195abd78075a@bellsouth.net> References: <20050214200415.D634D1E400D@bag.python.org> <46388a5f5e6db9fb90d7195abd78075a@bellsouth.net> Message-ID: <18eac145f076ff3f24971dbb5763712c@redivi.com> On Feb 14, 2005, at 4:11 PM, Andrew Meit wrote: > > On Feb 14, 2005, at 3:04 PM, pythonmac-sig-request@python.org wrote: > >> And it seems that very often programmers never do get around to that >> 'rebuild and replace' stage, because as soon as they've reached >> working code it's considered 'done', and to then throw that code away >> and start all over again is anathema. Coming from a fine art >> background, I _know_ that if you've a day to draw a life picture, >> then the best way to spend that time is 'wasting' the first half on >> throwaway sketches and only sitting down to the final version in the >> final few remaining hours, not spend all day hammering away at this >> one single drawing from 9 till 5. > > -- YES, I once, when much younger, did Type (known for my Gutenberg > font work) and graphic design; and so "write and burn" method was > carried over to my coding as second nature. However, I found out in > programming world rarely was that method valued or wanted: "gotta > ship, now". Which brings up another point: testing. Does python > support robust testing tools or methods?? I code towards quality and > so an IDE needs to support that goal. :-) There is plenty of Python software out there to facilitate testing: pychecker, the standard library unittest, py.test, ComfyChair, etc. I'm really not sure of any IDE that also has test runners, but that really isn't such a big deal. It's Just Another Script. -bob From bob at redivi.com Mon Feb 14 22:41:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 14 22:41:40 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <5gbg7gooc4lr$.veypcrab1an8$.dlg@40tude.net> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <6f4b25918418391549855ee35f085977@redivi.com> <5gbg7gooc4lr$.veypcrab1an8$.dlg@40tude.net> Message-ID: On Feb 14, 2005, at 4:32 PM, Wolfgang Keller wrote: >> Speaking of DrPython, I have an example of having it packaged in the >> py2app svn trunk.. but as it uses wxScintilla, it isn't really very >> fun >> to play with. > > Dumb question: What's wrong with wxScintilla? Doesn't SPE use it as > well? > What's Boa using? It's currently really slow on Mac OS X, as mentioned before. I don't like environments where I can type faster than the redraw. No idea about Boa. -bob From Chris.Barker at noaa.gov Mon Feb 14 23:08:01 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 23:08:53 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <6f4b25918418391549855ee35f085977@redivi.com> <5gbg7gooc4lr$.veypcrab1an8$.dlg@40tude.net> Message-ID: <42112141.4010100@noaa.gov> Bob Ippolito wrote: >> Dumb question: What's wrong with wxScintilla? Doesn't SPE use it as well? >> What's Boa using? > > It's currently really slow on Mac OS X, as mentioned before. I don't > like environments where I can type faster than the redraw. No idea > about Boa. Boa uses wxScintilla (AKA wxSTC) also. It is also only currently working with wxPython2.4.2, so not a good option on the Mac for that reason anyway. I do think the performance of wxSTC has been improved in more recent versions of wx, but I'm not the one to tell you for sure. I'm still not sure anyone has figured out how to use ATSUI in a truly efficient way yet. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Mon Feb 14 23:16:53 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Feb 14 23:17:44 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <31ac537c050214132963f694b6@mail.gmail.com> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> <31ac537c050214132963f694b6@mail.gmail.com> Message-ID: <42112355.4020608@noaa.gov> Troy Rollins wrote: > I think that what the new user really want, more than > "free", is something which provides a "raodmap to being productive." I've lost track, have you tried any of the proprietary tools? (Wing, etc.). I know I haven't. > but the whole project? It is just too big, with too many lines of code > for me to manage with a text editor and the terminal. I'm confused here. People have been managing big coding projects with an editor and a command line for ages. More to the point, many folks still do it, even when they have the option of a nifty GUI IDE. In fact, one thing I realized when working with Windows and the old MacOS, was that one reason that you needed an IDE so badly on those systems, and not so much on Unix, was that in a way, Unix IS an IDE. I still find grep easier to use than any "find in files" feature in an editor or IDE, for example. > If > all those options didn't exist, people like me would spend the first > several months trying to find something which works like the (payware) > tools we are accustomed to. Did you mean "would NOT spend the ...."? Off to get some real work done..... -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From charles.hartman at conncoll.edu Mon Feb 14 23:20:36 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon Feb 14 23:20:42 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <42112141.4010100@noaa.gov> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <6f4b25918418391549855ee35f085977@redivi.com> <5gbg7gooc4lr$.veypcrab1an8$.dlg@40tude.net> <42112141.4010100@noaa.gov> Message-ID: <7d99f8bbdae1d4dc5a4115643303ba6b@conncoll.edu> I don't know if this answers the question, but I've been using wxSTCs in my apps (there's no other way to display or edit text over 32k), and they seem to work just fine. One app uses an STC to load, for example, a 4.5 meg text file and do some searches on it. It's all very quick and painless. The only annoyance is the almost-but-not-quite-the-same commands for STCs versus wx's TextCtrls. Charles Hartman On Feb 14, 2005, at 5:08 PM, Chris Barker wrote: > > Boa uses wxScintilla (AKA wxSTC) also. It is also only currently > working with wxPython2.4.2, so not a good option on the Mac for that > reason anyway. > > I do think the performance of wxSTC has been improved in more recent > versions of wx, but I'm not the one to tell you for sure. I'm still > not sure anyone has figured out how to use ATSUI in a truly efficient > way yet. From just at letterror.com Mon Feb 14 23:32:41 2005 From: just at letterror.com (Just van Rossum) Date: Mon Feb 14 23:32:47 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 22, Issue 46 In-Reply-To: <46388a5f5e6db9fb90d7195abd78075a@bellsouth.net> Message-ID: Andrew Meit wrote: > -- YES, I once, when much younger, did Type (known for my Gutenberg > font work) and graphic design; I must be getting old, too: I thought I knew everyone who did type AND Python... Welcome to the club. Just From hengist.podd at virgin.net Tue Feb 15 00:29:09 2005 From: hengist.podd at virgin.net (has) Date: Tue Feb 15 00:40:24 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <02a33b62a8d8793e4de626d8e36bdb80@redivi.com> References: <02a33b62a8d8793e4de626d8e36bdb80@redivi.com> Message-ID: Bob Ippolito wrote: >>>Maybe because in many cases, the users are the developers and adding >>>those 20%s together makes for some big ugly mess. >> >>I'm not sure that qualifies as an excuse; more making their bed and >>lying in it. :) > >Well the people writing these things obviously write it such that it >suits them, so perhaps they find this bed to be comfortable? People are generally lazy. They'll do less work now even if it means more work later. (Perl's definition of 'lazy', while charming, is seriously optimistic.) >>>Personally, I hope that developers See The Light and do interface >>>building in a separate but integrated application like Xcode and >>>Interface Builder. >> >>Exactly. Or separate, integrateable components that plug into a >>common base framework. > >Well, separate processes is necessary.. a component based model >can't work, because certain components just can't live in the same >process with one another. Why not? And even where multiple processes are needed, why shouldn't we still hide the distinction from the user? (e.g. Erlang is virtually nothing _but_ processes.) Application-centric metaphors are nothing special. Hierarchical file/folder metaphors are nothing special. They're not inviolable holy of holies. >>> > I've never understood what the obsession with building every >>> > conceivable feature into the application core, >>> >>>I think this is largely caused by complexity of the alternative and the >>>convenience of doing it in this way. >> >>Developer convenience up to a point, yes. It requires less up-front >>planning and major direction changes: just jump in and write some >>code. Yet the same could be said for procedural vs OO construction, >>so why are developers seeing the advantages of modular design in >>the small but still missing it so often in the large? > >I think in a lot of cases this may be somewhat incorrect. A lot of >times you have a really modular framework, but it's not easy to rip >apart into its constituent components and install just what you want >(Twisted 1.x is an example of this). There's no excuse for coupling, say, persistence mechanisms and templating mechanisms into the framework. Argue the point again when they've at least managed to split those off. >So what? Although Twisted 2.x is moving away from this model, it's >to accommodate a more flexible release schedule, not to split it up >for the sake of splitting it up. IOW, there are benefits to modular, componentized architecture. I'm certainly not arguing doing it simply for its own sake. >In some cases, such as your own appscript/aem/etc., this kind of >external componentization is more of a hassle than anything else. Bad example. Appscript/aem's heavily componentized architecture is not the problem. The problem with appscript is that 1. Python's own module management mechanism is mediocre, and 2. I haven't bothered compensating for this weakness by providing an easy 'all-in-one' installer. >>But there are ways. OpenDoc was built upon Apple events, for example. > >I've never seen it done in Python really easily. Which is not to say it can't be done. It just means than in order for it to be done, some poor sap will have to have to step up and do all the hard work themselves. Which means lots of exploration and experimentation and lots of throwing out and starting over until the answers start emerging. >>It's interesting that even MS are now moving away from the DCOM >>approach and towards an Apple event/Apple Event Object Model >>approach. I think Apple were definitely onto something with these: >>it's all about where you make the split, and finding the right >>point makes the difference between moving Mohammed or moving the >>mountain. > >And we all know how well Apple has been implementing Apple Events in >its more recent applications. It's simply Not That Easy to do so, >so it's simply not done well or not done at all. Apple can't even come up with a half decent explanation of what Apple events are. Wanna take bets on the total amount of resources they bother to invest in them internally? Is it any surprise they so often don't get supported properly? It's hardly like this is the first time Apple have come up with a great technology and consistently fumbled its deployment. Only Xerox seems able to consistently make an even bigger arse of things. I think you're much to quick in throwing up your hands; there's a big difference between a bolloxed execution and a bolloxed concept, and failure of one doesn't automatically imply failure of the other. >>>that, and it's much easier to design something ad-hoc if you don't >>>concern yourself with keeping things modular. >> >>Of course. I often start out that way myself; it's hard to know >>what kind of high-level structure you're going to need if it's your >>first time exploring this particular problem. The trouble sets in >>when an initially ad-hoc design doesn't bother to improve its >>internal organisation as it grows; > >Well yeah, you do have to clean up your mess every so often. Or constantly, if you're like me. I don't have much choice: I have such poor ability to cope with complexity, I either keep constantly on top of it or I'm screwed. Mind you, in some ways I think this actually leaves me at an advantage compared to folks with a much higher tolerance for complexity since it leaves me much less able to dig myself into a really deep hole. I can't help but write modularised code. :) >>And it seems that very often programmers never do get around to >>that 'rebuild and replace' stage, because as soon as they've >>reached working code it's considered 'done', > >Lots of people think that throwing away an application and starting >over is a real mistake. Joel Spolsky has an article on this that >everyone likes to quote. Throwing away an _application_ is a sign that you've massively fubared, and anyone who does that _should_ indeed be bloody ashamed of themselves. Whereas generating and chucking away lots of fast working sketches is an indication that you're already planning and anticipating well ahead, because you're throwing out at a time when the cost of doing so is still extremely low and more than amply compensated for by the faster, deeper, greater learning you do along the way. The whole point is to learn enough so that when you do finally start on the deployment version you _won't need_ to throw it away when it's done because you'll get it pretty much right first time round. Fine art and Buddhist philosophy are the two things they should teach every CS undergrad from as soon as they step through the door. The moment you get precious, you're screwed. Learning how to humph hours, weeks, even months of work into the skip _is_ hard (I've been there), but once you do you'll be a better artist/developer for it. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From kranki at mac.com Tue Feb 15 00:46:45 2005 From: kranki at mac.com (Robert White) Date: Tue Feb 15 00:46:55 2005 Subject: [Pythonmac-SIG] New wiki entry Message-ID: I just added a new wiki entry, "Describe Apple's Framework implementation of Python and how that affects me adding new Python implementations". Please review it. If it does not answer your questions about Apple's Framework installation, please send those questions to this list or me personally and I will try to adjust the entry to answer the question. Thanks, Bob White -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 481 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050214/47e3f83b/attachment.bin From brendansimons at yahoo.ca Tue Feb 15 01:23:13 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Tue Feb 15 01:23:33 2005 Subject: [Pythonmac-SIG] Re: Macu User Python Newbiew In-Reply-To: <20050214190306.2EBC61E400C@bag.python.org> References: <20050214190306.2EBC61E400C@bag.python.org> Message-ID: <081a84e394de9c42a8d538e8b068a0b4@yahoo.ca> " cmd [ " moves a block of selected text one tab level back (4 spaces if you've set "auto-expand tabs"). and " cmd ] " moves a block of text one level forward. Is this what you're looking for? TextWrangler is no IDE, but as a code editor it's very good. -Brendan On 14-Feb-05, at 2:03 PM, pythonmac-sig-request@python.org wrote: > But does it do Python indenting correctly? This is my only really > obstacle with BBedit (a couple versions old). You can make it put in > spaces instead of tabs, but once they're in they are treated only as > spaces, rather than levels of indentation, so when you want to remove > a level you have to hit delete four times. Not horrible, but annoying. From Chris.Barker at noaa.gov Tue Feb 15 01:47:04 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Feb 15 01:47:55 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <24847cd3cc77843b3c7ef329632d66a5@redivi.com> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> <24847cd3cc77843b3c7ef329632d66a5@redivi.com> Message-ID: <42114688.5080205@noaa.gov> Bob Ippolito wrote: > I'm definitely interested in these things (more some than others), but > I'm currently professionally committed to some other stuff. The real > problem I'd have with this sort of business venture is doing it in a way > that's compatible with open source, but still making enough money to > keep doing it without spending too much time doing consulting. Well, aside form the fact hat I'm no businessman, that's one of my show stoppers too. I'm not sure how to balance open source and trying to make a profit. > I'd definitely want to give these things away as liberally licensed open > source, I would too, but I'm not sure there's a business plan there. Another idea was to open source what has always worked well as open source: the core libraries, like whatever GUI toolkit was used, be it improvements to an existing one, or something done just for this. The nifty, easy-for-newbies IDEs are kind of more of a natural for proprietary projects, as has been discussed here. > which might mean that it has to be done in the context of a > non-profit foundation (like Chandler via OSAF). That would be nice, but I have even less of an idea how to get money for hat than I do getting venture capital to start a business. However, perhaps this is just what one poster proposed: the PSF could fund a good cross-platform IDE. > However, it might be > possible to get away on a smaller scale by simply having a set of robust > open source tools as the "lite" version, and a "pro" version with a > couple nice extra features that isn't free (like the difference between > OmniGraffle and OmniGraffle Pro). Another good idea, but we'd still need the start-up money! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Tue Feb 15 01:52:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 15 01:53:56 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <02a33b62a8d8793e4de626d8e36bdb80@redivi.com> Message-ID: On Feb 14, 2005, at 18:29, has wrote: > Bob Ippolito wrote: > >>>> Personally, I hope that developers See The Light and do interface >>>> building in a separate but integrated application like Xcode and >>>> Interface Builder. >>> >>> Exactly. Or separate, integrateable components that plug into a >>> common base framework. >> >> Well, separate processes is necessary.. a component based model can't >> work, because certain components just can't live in the same process >> with one another. > > Why not? And even where multiple processes are needed, why shouldn't > we still hide the distinction from the user? (e.g. Erlang is virtually > nothing _but_ processes.) Application-centric metaphors are nothing > special. Hierarchical file/folder metaphors are nothing special. > They're not inviolable holy of holies. It's simply, without a doubt, no way around it, not technically possible to hide the separation from the user if you want to support components written using different GUI frameworks -- and that is an explicit requirement. On Mac OS X, each process may have zero or one GUI event loops, and each event loop may have zero or one Mac OS X menu bars. You simply can not design it any other way without being shackled to a particular GUI framework. Why the heck should a text editor share a menu and accelerator keys with an interface builder anyway? >>>> > I've never understood what the obsession with building every >>>> > conceivable feature into the application core, >>>> >>>> I think this is largely caused by complexity of the alternative and >>>> the >>>> convenience of doing it in this way. >>> >>> Developer convenience up to a point, yes. It requires less up-front >>> planning and major direction changes: just jump in and write some >>> code. Yet the same could be said for procedural vs OO construction, >>> so why are developers seeing the advantages of modular design in the >>> small but still missing it so often in the large? >> >> I think in a lot of cases this may be somewhat incorrect. A lot of >> times you have a really modular framework, but it's not easy to rip >> apart into its constituent components and install just what you want >> (Twisted 1.x is an example of this). > > There's no excuse for coupling, say, persistence mechanisms and > templating mechanisms into the framework. Argue the point again when > they've at least managed to split those off. So what if having Twisted installed gets you both persistence and templating functionality? They are not tightly coupled to anything else in Twisted that don't absolutely require them to function, and you don't have to use them. >> So what? Although Twisted 2.x is moving away from this model, it's >> to accommodate a more flexible release schedule, not to split it up >> for the sake of splitting it up. > > IOW, there are benefits to modular, componentized architecture. I'm > certainly not arguing doing it simply for its own sake. The *architecture* has been componentized since the start (or at least for the past few years, pre-1.0). The release packages were not. >> In some cases, such as your own appscript/aem/etc., this kind of >> external componentization is more of a hassle than anything else. > > Bad example. Appscript/aem's heavily componentized architecture is not > the problem. The problem with appscript is that 1. Python's own module > management mechanism is mediocre, and 2. I haven't bothered > compensating for this weakness by providing an easy 'all-in-one' > installer. I don't think you understood my point. Twisted 1.x is fully modular and componentized, but is distributed as a single unit Twisted 2.x is fully modular and componentized, and will be distributed as multiple units (or one "sumo" installer that has them all) There's no technical advantage whatsoever to Twisted 2's organization, but it makes sense given the need to have distinct release cycles -- which is simply a matter of scale. appscript takes this to the extreme by separating several related things into different packages when they follow in lock-step anyway. Distutils is perfectly suitable for installing several packages at the same time in the same setup(...) invocation, there is *no good reason* for the appscript suite to be distributed in several units. It's just a hassle for everyone, probably including yourself, because you have to upload and manage several different packages. >>> And it seems that very often programmers never do get around to that >>> 'rebuild and replace' stage, because as soon as they've reached >>> working code it's considered 'done', >> >> Lots of people think that throwing away an application and starting >> over is a real mistake. Joel Spolsky has an article on this that >> everyone likes to quote. > > Throwing away an _application_ is a sign that you've massively > fubared, and anyone who does that _should_ indeed be bloody ashamed of > themselves. Whereas generating and chucking away lots of fast working > sketches is an indication that you're already planning and > anticipating well ahead, because you're throwing out at a time when > the cost of doing so is still extremely low and more than amply > compensated for by the faster, deeper, greater learning you do along > the way. The whole point is to learn enough so that when you do > finally start on the deployment version you _won't need_ to throw it > away when it's done because you'll get it pretty much right first time > round. > > Fine art and Buddhist philosophy are the two things they should teach > every CS undergrad from as soon as they step through the door. The > moment you get precious, you're screwed. Learning how to humph hours, > weeks, even months of work into the skip _is_ hard (I've been there), > but once you do you'll be a better artist/developer for it. Sure, I throw away code all the time -- probably a lot more than is necessary. If it takes more than a day or two to get to the 'build and replace' stage you're probably at the "throwing away an application" state that some people say you should never do. Instead, they say you should more or less just beat on it until it works right, because at least you'll have something resembling usable along the way. -bob From charles.hartman at conncoll.edu Tue Feb 15 02:01:50 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 15 02:01:55 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <31ac537c050214132963f694b6@mail.gmail.com> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> <31ac537c050214132963f694b6@mail.gmail.com> Message-ID: <834e82f067eb83f5d68f648609dd3574@conncoll.edu> I don't want to beat this dead horse any farther into the ground, but: I'm working on a small but not toy app, one or two thousand lines in eight modules. To build and debug a module with "if __name__ == '__main__'", I can use TextWrangler's Run, or Run-with-debug if I want to get down into pdb. This works even if the module imports other program modules, as long as they're pretty well finished and debugged. But to put together more than that -- to trace bugs and design flaws having to do with the interaction among modules -- I need to turn to the WingIDE (the only one whose debugger I've been able to get working), which will let me step through and into my code, moving seamlessly from module to module. I'm not suggesting I couldn't do all this with an editor and Terminal; I'm saying this is the easy way for me, at my stage -- beginner but not complete beginner -- and that without the IDE I'd get lost in the larger integrative steps. And those are the parts where a sort-of-beginner is most likely to need help for (I'm guessing) quite a while. Charles Hartman From bob at redivi.com Tue Feb 15 02:06:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 15 02:07:11 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <42114688.5080205@noaa.gov> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> <24847cd3cc77843b3c7ef329632d66a5@redivi.com> <42114688.5080205@noaa.gov> Message-ID: On Feb 14, 2005, at 19:47, Chris Barker wrote: > > > Bob Ippolito wrote: >> I'm definitely interested in these things (more some than others), >> but I'm currently professionally committed to some other stuff. The >> real problem I'd have with this sort of business venture is doing it >> in a way that's compatible with open source, but still making enough >> money to keep doing it without spending too much time doing >> consulting. > > Well, aside form the fact hat I'm no businessman, that's one of my > show stoppers too. I'm not sure how to balance open source and trying > to make a profit. > >> I'd definitely want to give these things away as liberally licensed >> open source, > > I would too, but I'm not sure there's a business plan there. Another > idea was to open source what has always worked well as open source: > the core libraries, like whatever GUI toolkit was used, be it > improvements to an existing one, or something done just for this. The > nifty, easy-for-newbies IDEs are kind of more of a natural for > proprietary projects, as has been discussed here. I'm not sure I'd really want to do it if it wasn't almost entirely open source. If I'm going to be developing closed stuff, I might as well target a larger market than current and future Python developers :) >> which might mean that it has to be done in the context of a >> non-profit foundation (like Chandler via OSAF). > > That would be nice, but I have even less of an idea how to get money > for hat than I do getting venture capital to start a business. > However, perhaps this is just what one poster proposed: the PSF could > fund a good cross-platform IDE. It'd probably be easier to try and get grant(s) than to try and start a new non-profit organization expressly for the purpose -- but I wouldn't really know. >> However, it might be possible to get away on a smaller scale by >> simply having a set of robust open source tools as the "lite" >> version, and a "pro" version with a couple nice extra features that >> isn't free (like the difference between OmniGraffle and OmniGraffle >> Pro). > > Another good idea, but we'd still need the start-up money! The way some small software developers have gone is to segue a consulting business (which takes almost no startup capital) into a product business.. -bob From janssen at parc.com Tue Feb 15 03:21:48 2005 From: janssen at parc.com (Bill Janssen) Date: Tue Feb 15 03:22:13 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: Your message of "Mon, 14 Feb 2005 17:06:46 PST." Message-ID: <05Feb14.182154pst."58617"@synergy1.parc.xerox.com> > If I'm going to be developing closed stuff, I might as well > target a larger market than current and future Python developers :) Well, that's good. My projects are typically a mix of Python, Java, and Jython, often with a bit of C, C++, HTML, CSS and Javascript, all mixed together. An IDE that won't let me mix them up (WingIDE, Eclipse) does me no good. Emacs to the rescue! Bill From bob at redivi.com Tue Feb 15 03:37:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 15 03:38:42 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <05Feb14.182154pst."58617"@synergy1.parc.xerox.com> References: <05Feb14.182154pst."58617"@synergy1.parc.xerox.com> Message-ID: On Feb 14, 2005, at 9:21 PM, Bill Janssen wrote: >> If I'm going to be developing closed stuff, I might as well >> target a larger market than current and future Python developers :) > > Well, that's good. My projects are typically a mix of Python, Java, > and Jython, often with a bit of C, C++, HTML, CSS and Javascript, all > mixed together. An IDE that won't let me mix them up (WingIDE, > Eclipse) does me no good. Emacs to the rescue! Well, what I meant, is that I'm not sure I'd want to be in the development tools business at all if I was going to be writing closed software. I'm sorry you have to deal with HTML/CSS/Javascript mixed projects :) -bob From mwh at python.net Tue Feb 15 11:48:24 2005 From: mwh at python.net (Michael Hudson) Date: Tue Feb 15 11:48:26 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <4210E1CB.1070502@anvil.nrl.navy.mil> (Louis Pecora's message of "Mon, 14 Feb 2005 12:37:15 -0500") References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> <2mk6pc2vy3.fsf@starship.python.net> <4210E1CB.1070502@anvil.nrl.navy.mil> Message-ID: <2mzmy614lj.fsf@starship.python.net> Louis Pecora writes: > Michael Hudson wrote: > >>Well, I think this is a subjective judgement -- a matter of >>familiarity. I "play" with Python all the time. A good start is to >>enhance your interactive experience somewhat. Three options spring to >>mind: >> >> 1) Get readline support working. If you're still using Apple's [...] >> 2) Install IPython (http://ipython.scipy.org/). This is a massive [...] >> 3) Install (my) PyRepl package (http://codespeak.net/pyrpl/), which >> is a different implementation of the same kind of thing. >> >>There are less terminal oriented interactive environments too -- I >>think wxPython includes one and PyObjC has a 'PyInterpreter' example. >>But to me they don't hold much advantage over the in-Terminal.app >>solutions. >> > > Well, I can just see Troy sitting at his computer reading the above > and saying, "I rest my case." :-) It's all a bit unixy, yes. OTOH, it's not exactly hard and you only have to do it once... > You did somewhat admit that in (1) above and in the remainder of your > message so you are honest about the state of affairs. And I thank you > for all the information. Now, where to start? Where to start? I don't know. If I did know, I'd probably have done it. It would help if Apple shipped Python with readline support enabled, for starters. Cheers, mwh -- I think my standards have lowered enough that now I think ``good design'' is when the page doesn't irritate the living fuck out of me. -- http://www.jwz.org/gruntle/design.html From mwh at python.net Tue Feb 15 11:56:33 2005 From: mwh at python.net (Michael Hudson) Date: Tue Feb 15 11:56:34 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <42114688.5080205@noaa.gov> (Chris Barker's message of "Mon, 14 Feb 2005 16:47:04 -0800") References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> <24847cd3cc77843b3c7ef329632d66a5@redivi.com> <42114688.5080205@noaa.gov> Message-ID: <2mvf8u147y.fsf@starship.python.net> "Chris Barker" writes: > That would be nice, but I have even less of an idea how to get money > for hat than I do getting venture capital to start a > business. However, perhaps this is just what one poster proposed: the > PSF could fund a good cross-platform IDE. I don't think the PSF has the resources to do this currently. Also, it doesn't intuitively strike me as the sort of thing the PSF is currently looking to fund. But I could be wrong! Gather some people and make a proposal for the next round of grants, if you want to show me up. Cheers, mwh -- INEFFICIENT CAPITALIST YOUR OPULENT TOILET WILL BE YOUR UNDOING -- from Twisted.Quotes From bob at redivi.com Tue Feb 15 11:56:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 15 11:57:22 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <2mzmy614lj.fsf@starship.python.net> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> <2mk6pc2vy3.fsf@starship.python.net> <4210E1CB.1070502@anvil.nrl.navy.mil> <2mzmy614lj.fsf@starship.python.net> Message-ID: <18b2888c75d2d83975e7a983344ddd65@redivi.com> On Feb 15, 2005, at 5:48, Michael Hudson wrote: > Louis Pecora writes: > >> Michael Hudson wrote: >> >>> Well, I think this is a subjective judgement -- a matter of >>> familiarity. I "play" with Python all the time. A good start is to >>> enhance your interactive experience somewhat. Three options spring >>> to >>> mind: >>> >>> 1) Get readline support working. If you're still using Apple's > > [...] > >>> 2) Install IPython (http://ipython.scipy.org/). This is a massive > > [...] > >>> 3) Install (my) PyRepl package (http://codespeak.net/pyrpl/), which >>> is a different implementation of the same kind of thing. >>> >>> There are less terminal oriented interactive environments too -- I >>> think wxPython includes one and PyObjC has a 'PyInterpreter' example. >>> But to me they don't hold much advantage over the in-Terminal.app >>> solutions. >>> >> >> Well, I can just see Troy sitting at his computer reading the above >> and saying, "I rest my case." :-) > > It's all a bit unixy, yes. OTOH, it's not exactly hard and you only > have to do it once... > >> You did somewhat admit that in (1) above and in the remainder of your >> message so you are honest about the state of affairs. And I thank you >> for all the information. Now, where to start? Where to start? > > I don't know. If I did know, I'd probably have done it. It would > help if Apple shipped Python with readline support enabled, for > starters. I think it's a licensing issue, Apple is probably trying to save people (themselves?) from linking against GPL stuff without realizing the implications. If Python could use BSD libedit instead of GNU readline, of if it just included PyRepl, it would not be a problem. -bob From mwh at python.net Tue Feb 15 12:00:40 2005 From: mwh at python.net (Michael Hudson) Date: Tue Feb 15 12:00:42 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <18b2888c75d2d83975e7a983344ddd65@redivi.com> (Bob Ippolito's message of "Tue, 15 Feb 2005 05:56:35 -0500") References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> <2mk6pc2vy3.fsf@starship.python.net> <4210E1CB.1070502@anvil.nrl.navy.mil> <2mzmy614lj.fsf@starship.python.net> <18b2888c75d2d83975e7a983344ddd65@redivi.com> Message-ID: <2mr7ji1413.fsf@starship.python.net> Bob Ippolito writes: > On Feb 15, 2005, at 5:48, Michael Hudson wrote: > >> I don't know. If I did know, I'd probably have done it. It would >> help if Apple shipped Python with readline support enabled, for >> starters. > > I think it's a licensing issue, Apple is probably trying to save > people (themselves?) from linking against GPL stuff without realizing > the implications. Probably yes. But they ship bash with readline enabled... oh well, I'm not masochistic enough to flog that particular horse. > If Python could use BSD libedit instead of GNU readline, I *think* there was a patch to do this, back in the mists of time. > of if it just included PyRepl, it would not be a problem. If PyRepl was fit for inclusion (sigh) that would indeed be nice :) Cheers, mwh -- Just point your web browser at http://www.python.org/search/ and look for "program", "doesn't", "work", or "my". Whenever you find someone else whose program didn't work, don't do what they did. Repeat as needed. -- Tim Peters, on python-help, 16 Jun 1998 From bob at redivi.com Tue Feb 15 12:20:14 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 15 12:20:29 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <2mr7ji1413.fsf@starship.python.net> References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <31ac537c05021309011afe2087@mail.gmail.com> <2mk6pc2vy3.fsf@starship.python.net> <4210E1CB.1070502@anvil.nrl.navy.mil> <2mzmy614lj.fsf@starship.python.net> <18b2888c75d2d83975e7a983344ddd65@redivi.com> <2mr7ji1413.fsf@starship.python.net> Message-ID: <49bb26d3f414d9cc21fc75fbef0591c5@redivi.com> On Feb 15, 2005, at 6:00, Michael Hudson wrote: > Bob Ippolito writes: > >> On Feb 15, 2005, at 5:48, Michael Hudson wrote: >> >>> I don't know. If I did know, I'd probably have done it. It would >>> help if Apple shipped Python with readline support enabled, for >>> starters. >> >> I think it's a licensing issue, Apple is probably trying to save >> people (themselves?) from linking against GPL stuff without realizing >> the implications. > > Probably yes. But they ship bash with readline enabled... oh well, > I'm not masochistic enough to flog that particular horse. It would be pretty hard to unintentionally violate the GPL by accident with a readline-enabled bash executable considering that you can't link to an MH_EXECUTABLE -- and even if you could, it's stripped so the symbols aren't there anymore anyway. -bob From kid at kendermedia.com Tue Feb 15 13:18:57 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Tue Feb 15 13:19:03 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: References: <20050213110004.D88841E400B@bag.python.org> <56614e190843db689537582fe99e63bd@digitalgoods.com> <31ac537c050213075917334f61@mail.gmail.com> <2msm4030de.fsf@starship.python.net> <257d98d396aaa6eb8f581e92bbae1dc0@conncoll.edu> Message-ID: <4211E8B1.1070006@kendermedia.com> Bob Ippolito wrote: > > On Feb 14, 2005, at 12:09 PM, has wrote: > >> My preferred IDE architecture would be built on a completely >> component-oriented architecture. That way it can ship with the >> minimal components required to get started, and users can add, >> upgrade and remove components as and when they need them. For >> example, a new user needs everything visible so they can see what's >> available; an experience one may prefer everything driven by >> memorised keyboard combinations so they can devote screen estate to >> more important things like their code instead of floating palettes, >> on-screen help, etc. > > > I think Eclipse is intended to be like this -- though I can't say I > have real experience using it. Yes indeed. Since I just arrived back on planet python from javaland a couple of months back, I used Eclipse quite extensively. Eclipse has a tiny core and everything else is a plugin. IBM's WebSphere Application Developer package, I've gathered, consists of more than 500 plugins. Of course, the drawback to Eclipse is that it's Java. Whenever I would do some of my development on my Mac, I always found it to be a bit sluggish. I don't know if it's sluggish because of the plugins, or if it's sluggish because of the SWT gui toolkit. Lately, I've been using JEdit (which is also Java, but I haven't found it to be sluggish). Kevin From greenery at ntlworld.com Tue Feb 15 13:35:46 2005 From: greenery at ntlworld.com (Thomas Green) Date: Tue Feb 15 13:35:49 2005 Subject: [Pythonmac-SIG] Can I use tktable with MacPython? Message-ID: Hi, can anyone give me advice about how to import and use tktable in Python? I've used it successfully in tcl but when I tried "import tktable" in Python I got "ImportError: No module named tktable" (and likewise for other combinations of upper and lowercase). A small working example would be ace! (BTW I'm not really competent enough to start recompiling the source or anything like that) Thanks, Thomas Green 27 Allerton Park, Leeds LS7 4ND +44-(0)-113-226-6687 http://homepage.ntlworld.com/greenery/ From bob at redivi.com Tue Feb 15 13:41:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 15 13:42:23 2005 Subject: [Pythonmac-SIG] Can I use tktable with MacPython? In-Reply-To: References: Message-ID: <098a428d5a779fed0bf9a876a23dce19@redivi.com> On Feb 15, 2005, at 7:35, Thomas Green wrote: > Hi, can anyone give me advice about how to import and use tktable in > Python? I've used it successfully in tcl but when I tried "import > tktable" in Python I got "ImportError: No module named tktable" (and > likewise for other combinations of upper and lowercase). > > A small working example would be ace! > > (BTW I'm not really competent enough to start recompiling the source > or anything like that) Googling for "tktable tkinter" I found this: http://tkinter.unpythonic.net/wiki/TkTable Apparently TkTable comes with a Tkinter wrapper. -bob From jason at blueboutique.com Mon Feb 14 16:20:30 2005 From: jason at blueboutique.com (Jason Vance) Date: Wed Feb 16 11:45:40 2005 Subject: [Pythonmac-SIG] MySQL-Python Help In-Reply-To: <20050214110154.DC75C1E4010@bag.python.org> References: <20050214110154.DC75C1E4010@bag.python.org> Message-ID: <9e0a3525b2d70966f9f7b75020577974@blueboutique.com> I'm pretty new to python development on the Mac. I'm not sure that if this is the appropriate place to place this question, but I'm having problems getting the MySQL-python v1.2.0 working on my mac. When I try and set it up, as per the instructions I get the following errors: jasonvance$ python setup.py build running build running build_py running build_ext building '_mysql' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/sw/include/mysql -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c _mysql.c -o build/temp.darwin-7.8.0-Power_Macintosh-2.3/_mysql.o -I/sw/include/mysql -O3 -fomit-frame-pointer In file included from _mysql.c:31: pymemcompat.h:10:20: Python.h: No such file or directory _mysql.c:40:26: structmember.h: No such file or directory _mysql.c:59: error: parse error before '*' token _mysql.c:59: warning: type defaults to `int' in declaration of `_mysql_MySQLError' _mysql.c:59: warning: data definition has no type or storage class _mysql.c:60: error: parse error before '*' token _mysql.c:60: warning: type defaults to `int' in declaration of `_mysql_Warning' _mysql.c:60: warning: data definition has no type or storage class _mysql.c:61: error: parse error before '*' token _mysql.c:61: warning: type defaults to `int' in declaration of `_mysql_Error' _mysql.c:61: warning: data definition has no type or storage class _mysql.c:62: error: parse error before '*' token _mysql.c:62: warning: type defaults to `int' in declaration of `_mysql_DatabaseError' _mysql.c:62: warning: data definition has no type or storage class _mysql.c:63: error: parse error before '*' token *** Shortened for Brevity **** _mysql.c:2685: warning: implicit declaration of function `PyImport_ImportModule' _mysql.c:2722: warning: assignment makes pointer from integer without a cast _mysql.c:2726: warning: implicit declaration of function `PyErr_Occurred' _mysql.c:2727: error: `PyExc_ImportError' undeclared (first use in this function) _mysql.c:2729: warning: `return' with no value, in function returning non-void _mysql.c: At top level: _mysql.c:1882: warning: `_mysql_ConnectionObject_dealloc' defined but not used _mysql.c:1957: warning: `_mysql_ResultObject_dealloc' defined but not used _mysql.c:2334: warning: `_mysql_ConnectionObject_setattr' defined but not used _mysql.c:2359: warning: `_mysql_ResultObject_setattr' defined but not used error: command 'gcc' failed with exit status 1 Since I'm pretty new to python and I'm not a C programmer, I was thinking that I'm missing some sort of header files either with Python or with MySQL Thanks, Jason Vance Jason S. Vance Blue Boutique Online, Llc 1715 W. Wendover Blvd. West Wendover, NV 89883 775-664-2771 801-381-4673 - Cell -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2930 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050214/9ee6286b/attachment.bin From bob at redivi.com Wed Feb 16 14:55:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 16 14:55:37 2005 Subject: [Pythonmac-SIG] MySQL-Python Help In-Reply-To: <9e0a3525b2d70966f9f7b75020577974@blueboutique.com> References: <20050214110154.DC75C1E4010@bag.python.org> <9e0a3525b2d70966f9f7b75020577974@blueboutique.com> Message-ID: On Feb 14, 2005, at 10:20, Jason Vance wrote: > I'm pretty new to python development on the Mac. I'm not sure that if > this is the appropriate place to place this question, but I'm having > problems getting the MySQL-python v1.2.0 working on my mac. When I try > and set it up, as per the instructions I get the following errors: > > jasonvance$ python setup.py build > running build > running build_py > running build_ext > building '_mysql' extension > gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes -I/sw/include/mysql > -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ > python2.3 -c _mysql.c -o > build/temp.darwin-7.8.0-Power_Macintosh-2.3/_mysql.o > -I/sw/include/mysql -O3 -fomit-frame-pointer > In file included from _mysql.c:31: > pymemcompat.h:10:20: Python.h: No such file or directory > _mysql.c:40:26: structmember.h: No such file or directory Those are the lines that matter -- any errors after a missing header file aren't really even worth tracking down. I bet MySQL-python has lines that look like: #include When it *should* have lines that look like: #include "Python.h" ... either that, or you don't have Xcode installed, and you're missing the headers for Python. -bob From charles.hartman at conncoll.edu Wed Feb 16 19:04:13 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed Feb 16 19:04:17 2005 Subject: [Pythonmac-SIG] another query about IDE Message-ID: In that long discussion, someone mentioned jEdit, so I went and looked it up. It looks very promising and robust. But am I right in thinking that the only path toward GUI apps that it would support would be Java (JPython) based? Rather than wx, and so on? Charles Hartman From hengist.podd at virgin.net Wed Feb 16 19:19:49 2005 From: hengist.podd at virgin.net (has) Date: Wed Feb 16 19:21:50 2005 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.0 Message-ID: Hi all, Announcing the first release of the all-in-one Appscript Installer package for Mac OS X 10.3. Appscript brings AppleScript-quality application scripting support to MacPython on Mac OS X. This package installs everything you need to control "Applescriptable" applications using the Python 2.3 runtime included as standard in Mac OS X 10.3. In addition to a clean, easy-to-use, object oriented-like syntax for scripting applications, appscript also includes powerful built-in help facilities for exploring applications' terminology and object model - features normally found only in high-end commercial AppleScript editors. To download Appscript Installer, please visit the appscript webpage: http://freespace.virgin.net/hamish.sanderson/appscript.html To see some examples of use: http://freespace.virgin.net/hamish.sanderson/appscript_examples/index.html If you have any questions or comments, please don't hesitate to get in touch. We're still working to polish appscript and finish its documentation, so all feedback is greatly appreciated. Enjoy! has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Wed Feb 16 19:54:25 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 16 19:54:30 2005 Subject: [Pythonmac-SIG] another query about IDE In-Reply-To: References: Message-ID: <2dd6af78b160be7b3d34ecaa0012663c@redivi.com> On Feb 16, 2005, at 13:04, Charles Hartman wrote: > In that long discussion, someone mentioned jEdit, so I went and looked > it up. It looks very promising and robust. But am I right in thinking > that the only path toward GUI apps that it would support would be Java > (JPython) based? Rather than wx, and so on? Presumably jEdit does the right thing and runs Python out of process, so you have no such limitations. I don't think it forces you to use Jython at all. Text editors tend not to run code in-process unless you ask them very nicely. IDEs written mostly or entirely in Python tend to run Python code and GUI interpreters in process though, presumably because it's (significantly) easier to do so, despite the (severe and crippling) limitations. -bob From ronaldoussoren at mac.com Wed Feb 16 20:07:02 2005 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed Feb 16 20:07:53 2005 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.0 In-Reply-To: References: Message-ID: <0cb6b79235e0333f78452da353fc8685@mac.com> On 16-feb-05, at 19:19, has wrote: > Hi all, > > Announcing the first release of the all-in-one Appscript Installer > package for Mac OS X 10.3. That's nice, having a self-contained installer makes it a lot easier to install appscript. I have one minor nit though, the readme mentions that the installer will also install a patched version of Carbon._AE. Would it be possible to move your additions to Carbon._AE to a seperate module? That module could be dropped again when Carbon._AE contains the required functions (hopefully in Python 2.5). Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050216/57641de0/smime.bin From bob at redivi.com Wed Feb 16 20:09:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 16 20:09:25 2005 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.0 In-Reply-To: References: Message-ID: <5d9c6903d3bc8a63bdd0fc677ee1798c@redivi.com> On Feb 16, 2005, at 13:19, has wrote: > Hi all, > > Announcing the first release of the all-in-one Appscript Installer > package for Mac OS X 10.3. Finally! :) > Appscript brings AppleScript-quality application scripting support to > MacPython on Mac OS X. This package installs everything you need to > control "Applescriptable" applications using the Python 2.3 runtime > included as standard in Mac OS X 10.3. > > In addition to a clean, easy-to-use, object oriented-like syntax for > scripting applications, appscript also includes powerful built-in help > facilities for exploring applications' terminology and object model - > features normally found only in high-end commercial AppleScript > editors. > > To download Appscript Installer, please visit the appscript webpage: > > http://freespace.virgin.net/hamish.sanderson/appscript.html > > To see some examples of use: > > > http://freespace.virgin.net/hamish.sanderson/appscript_examples/ > index.html > > If you have any questions or comments, please don't hesitate to get in > touch. We're still working to polish appscript and finish its > documentation, so all feedback is greatly appreciated. It's of note that this installer patches your Mac OS X 10.3 installation of Python 2.3.0: ./System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/_AE.so 100755 7096/7096 64348 3155963929 It's probably better to have its own local copy of this module instead, perhaps used conditionally when/if you're using a version of Python that adds the new features required. Also, the extensions in this appscript installer weren't built with PantherPythonFix, so they are tightly bound to the Python 2.3.0 installation. If they were built with a PantherPythonFix'ed installation, then they would be compatible across all Python 2.3.x on Mac OS X 10.3+. % otool -Lv ./Library/Python/2.3/aem/send/PSN.so ./Library/Python/2.3/aem/send/PSN.so: /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) -bob From Chris.Barker at noaa.gov Wed Feb 16 20:09:27 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 16 20:10:25 2005 Subject: [Pythonmac-SIG] another query about IDE In-Reply-To: References: Message-ID: <42139A67.40108@noaa.gov> Charles Hartman wrote: > In that long discussion, someone mentioned jEdit, so I went and looked > it up. It looks very promising and robust. But am I right in thinking > that the only path toward GUI apps that it would support would be Java > (JPython) based? Rather than wx, and so on? It's an editor, not a GUI-builder. You can use any GUI toolkit you like. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From Chris.Barker at noaa.gov Wed Feb 16 20:23:26 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 16 20:24:25 2005 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.0 In-Reply-To: <5d9c6903d3bc8a63bdd0fc677ee1798c@redivi.com> References: <5d9c6903d3bc8a63bdd0fc677ee1798c@redivi.com> Message-ID: <42139DAE.3010402@noaa.gov> Bob Ippolito wrote: > Also, the extensions in this appscript installer weren't built with > PantherPythonFix, so they are tightly bound to the Python 2.3.0 > installation. If they were built with a PantherPythonFix'ed > installation, then they would be compatible across all Python 2.3.x on > Mac OS X 10.3+. Bob, does this mean that I should make sure to PantherPythonFix my installation before building packages like matplotlib? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Wed Feb 16 20:35:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 16 20:36:03 2005 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.0 In-Reply-To: <42139DAE.3010402@noaa.gov> References: <5d9c6903d3bc8a63bdd0fc677ee1798c@redivi.com> <42139DAE.3010402@noaa.gov> Message-ID: On Feb 16, 2005, at 14:23, Chris Barker wrote: > Bob Ippolito wrote: >> Also, the extensions in this appscript installer weren't built with >> PantherPythonFix, so they are tightly bound to the Python 2.3.0 >> installation. If they were built with a PantherPythonFix'ed >> installation, then they would be compatible across all Python 2.3.x >> on Mac OS X 10.3+. > > Bob, does this mean that I should make sure to PantherPythonFix my > installation before building packages like matplotlib? Yes. Everyone who uses distutils to build extensions on Mac OS X 10.3 should run PantherPythonFix. -bob From hengist.podd at virgin.net Wed Feb 16 21:55:50 2005 From: hengist.podd at virgin.net (has) Date: Wed Feb 16 21:56:08 2005 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.0 In-Reply-To: <5d9c6903d3bc8a63bdd0fc677ee1798c@redivi.com> References: <5d9c6903d3bc8a63bdd0fc677ee1798c@redivi.com> Message-ID: Bob wrote: >>Announcing the first release of the all-in-one Appscript Installer >>package for Mac OS X 10.3. > >Finally! :) You can thank Nick, not me - the installer is his work. :) has -- http://freespace.virgin.net/hamish.sanderson/ From n8gray at gmail.com Thu Feb 17 02:18:54 2005 From: n8gray at gmail.com (Nathaniel Gray) Date: Thu Feb 17 02:18:57 2005 Subject: [Pythonmac-SIG] pythonw In-Reply-To: <173ec8a71ff75e248be215ae95310284@redivi.com> References: <723eb6930502050908347eb7de@mail.gmail.com> <723eb69305020709346c1ae174@mail.gmail.com> <173ec8a71ff75e248be215ae95310284@redivi.com> Message-ID: On Mon, 7 Feb 2005 12:37:06 -0500, Bob Ippolito wrote: > > On Feb 7, 2005, at 12:34, Chris Fonnesbeck wrote: > > > > OK, so if I replace the symbolic link from /usr/bin/python to > > /usr/bin/python2.3 with a link to /usr/bin/pythonw2.3, nothing bad > > will happen? I dont envision a scenario for me ever having to use > > python2.3 ever again, if this is true. > > I think that will break #! scripts that don't use env, because pythonw > is a shell script not an executable. Hey Jack, how about fixing that? I've already supplied the patch, including build system support. http://sourceforge.net/tracker/index.php?func=detail&aid=1038911&group_id=5470&atid=305470 Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> From pecora at anvil.nrl.navy.mil Thu Feb 17 15:47:23 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu Feb 17 15:47:19 2005 Subject: [Pythonmac-SIG] Mac User Python Newbies In-Reply-To: <421109A6.8050300@noaa.gov> References: <20050209040616.65CF71E400C@bag.python.org> <7c4947356812a6945ecd5f5fc3378dee@yahoo.ca> <1vp8p3f7p4yg9.1717g6vc4vn4l$.dlg@40tude.net> <421109A6.8050300@noaa.gov> Message-ID: <4214AE7B.3090200@anvil.nrl.navy.mil> Chris Barker wrote: > By the way, I've often thought of forming a company that would produce > just what we've been talking about here, but with a bit of a twist: > > A set of Python environments for doing specialized development. Some > ideas are: > > --A database app environment, as easy to use as FileMaker, but with a > real language at it's core. > > --A scientific programming environment, everything that MATLAB gives > you, but again, with a real language at the core. > > --Maybe a web framework. > > --And you'd probably need to do a general purpose IDE as well. > > Anyone have any venture capital? > > I know that there are open-source versions of all of these: SciPy, > Dabo, Pythoncard, Zope, etc., but they don't have the polish that > you'd need to attract the type of newbies that are at the core of this > thread. > > -Chris Well I'd certainly like two or three of those and be willing to pay. I agree with your final statement re: current open-source versions. Just wish I had the venture capital for you. You have the right idea. Good luck. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From Jack.Jansen at cwi.nl Thu Feb 17 23:38:16 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Feb 17 23:38:16 2005 Subject: [Pythonmac-SIG] Fink, DarwinPorts vs py2app In-Reply-To: <2mis50429q.fsf@starship.python.net> References: <20050208145134.16992.qmail@web30203.mail.mud.yahoo.com> <6ab4c94a7004aec9209115836d4c7c1f@mac.com> <87a996012fc9d151741b8da0abfda93b@redivi.com> <4208FD71.1010509@noaa.gov> <20050210170734.GC50333@remote.gene-hacker.net> <2mis50429q.fsf@starship.python.net> Message-ID: <9D7145FE-8134-11D9-962A-000D934FF6B4@cwi.nl> On 10-feb-05, at 20:56, Michael Hudson wrote: > Michael Maibaum writes: > >> As for Python. As soon as there is a framework version of Python >> that can be installed via a destroot for packaging, I'll add it to >> DarwinPorts. Or if someone can figure out how to hack the current >> version to do it... > > Is there a bug report for this? It has been fixed, see . The fix is in 2.3.5 and will be in the forthcoming 2.4.1. I don't think I've ever done fixes that needed so many things changed in so many places, for the benefit of so few users. But then, I myself am one of those few:-) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Feb 18 00:15:41 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Feb 18 00:15:37 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> Message-ID: This thread touches on something I've been wanting to do for some time now: add a "Which Python do I need" page to the website. I'd like to organise this by MacOS version, so people can quickly determine what they need. Here's a quick start for such a list, you can all help me by filling in the blanks, missing bits, etc. MacOSX 10.3, no special requirements: Use Apple-supplied Python with the MacPython Additions MacOSX 10.3, need Python 2.4: MacPython 2.4.1 (forthcoming) Make sure to install PythonPantherFix MacOSX 10.3, need bugfixes from Python 2.3.1-2.3.5: MacPython 2.3.5 for 10.2 and 10.3 Make sure to install PythonPantherFix MacOSX 10.3, want to distribute turnkey apps with py2app: MacPython 2.3.5 for 10.2 and 10.3 (or, when it's done, MacPython 2.4.1) Make sure to install PythonPantherFix MacOSX 10.3, need to run Zope/whatever other package: Gee... I have no idea... MacOSX 10.3, need Python 2.2 or earlier: You need to build this yourself, from source Make sure to install PythonPantherFix MacOSX 10.3 or 10.2, need Classic Python: MacPython-OS9 2.3.5 MacOSX 10.2, no special requirements: MacPython 2.4.1 (forthcoming) MacOSX 10.2, need Python 2.3: MacPython 2.3.5 MacOSX 10.2, need Python 2.2: Use Apple-supplied Python MacOSX 10.1 or earlier: Either build from source yourself, or make do with MacPython-OS9 2.3.5 MacOS 9.2: MacPython-OS9 2.3.5 MacOS 9 or 9.1: MacPython-OS9 2.3.5 Also install CarbonLib 1.3 from Apple MacOS 8.1 or later: MacPython-OS9 2.2.3 You may need to install Appearance Manager 1.1 on 8.1 Older MacOS releases, including all 68K Macintoshes: MacPython 1.5.2 -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Fri Feb 18 00:33:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 18 00:33:28 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 17, 2005, at 18:15, Jack Jansen wrote: > This thread touches on something I've been wanting to do for some time > now: add a "Which Python do I need" page to the website. I'd like to > organise this by MacOS version, so people can quickly determine what > they need. > > Here's a quick start for such a list, you can all help me by filling > in the blanks, missing bits, etc. > > MacOSX 10.3, no special requirements: > Use Apple-supplied Python with the MacPython Additions Tell them to install PantherPythonFix anyway -- or make it a forced component of MacPython Additions. > MacOSX 10.3, need Python 2.4: > MacPython 2.4.1 (forthcoming) > Make sure to install PythonPantherFix > MacOSX 10.3, need bugfixes from Python 2.3.1-2.3.5: > MacPython 2.3.5 for 10.2 and 10.3 > Make sure to install PythonPantherFix > MacOSX 10.3, want to distribute turnkey apps with py2app: > MacPython 2.3.5 for 10.2 and 10.3 > (or, when it's done, MacPython 2.4.1) > Make sure to install PythonPantherFix Make sure they build all of their extensions on 10.2 if they intend to support it! > MacOSX 10.3, need to run Zope/whatever other package: > Gee... I have no idea... > MacOSX 10.3, need Python 2.2 or earlier: > You need to build this yourself, from source > Make sure to install PythonPantherFix Probably make sure to tell them not to use --enable-framework on 2.2, since the fixes weren't backported. > MacOSX 10.3 or 10.2, need Classic Python: > MacPython-OS9 2.3.5 > > MacOSX 10.2, no special requirements: > MacPython 2.4.1 (forthcoming) > MacOSX 10.2, need Python 2.3: > MacPython 2.3.5 > MacOSX 10.2, need Python 2.2: > Use Apple-supplied Python Don't tell them to use that 2.2.0! It's so horribly broken. Not available as shared lib, flat_namespace, if two extensions have the same basename then only one will get loaded (i.e. the time module, and pygame.time, etc.), Python bugs were pretty deadly in 2.2.0 (gc bugs, weakref bugs, etc.) > MacOSX 10.1 or earlier: > Either build from source yourself, or make do with MacPython-OS9 2.3.5 Has anyone tried building on 10.1? -bob From matsakis at mit.edu Fri Feb 18 06:14:48 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Fri Feb 18 06:14:51 2005 Subject: [Pythonmac-SIG] Re: Main Python on Mac version? Message-ID: Jack wrote: > This thread touches on something I've been wanting to do for some time > now: add a "Which Python do I need" page to the website. I'd like to > organise this by MacOS version, so people can quickly determine what > they need. So, is there any word on what version of Python will be shipping with 10.4? Has a line of communication been worked out to ensure it is the latest and greatest? Apple's internal schedule is shrouded in mystery, but there's a good chance that the ability to make changes at that level has either passed or will pass in very short order. Nick From bob at redivi.com Fri Feb 18 06:40:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 18 06:40:59 2005 Subject: [Pythonmac-SIG] Re: Main Python on Mac version? In-Reply-To: References: Message-ID: <09d340e18ee1430c33dbb3a415266ca0@redivi.com> On Feb 18, 2005, at 12:14 AM, Nick Matsakis wrote: > Jack wrote: > >> This thread touches on something I've been wanting to do for some time >> now: add a "Which Python do I need" page to the website. I'd like to >> organise this by MacOS version, so people can quickly determine what >> they need. > > So, is there any word on what version of Python will be shipping with > 10.4? Has a line of communication been worked out to ensure it is the > latest and greatest? Apple's internal schedule is shrouded in mystery, > but there's a good chance that the ability to make changes at that > level > has either passed or will pass in very short order. The only public information w.r.t. Mac OS X 10.4 and Python is that the WWDC sources had Python 2.3.3 with some patches. Right now, Python 2.3.5 is the only stable released version that I would recommend for inclusion into Mac OS X. Python 2.4.0 would currently be a mistake, but certainly not as bad as 2.2.0 (Mac OS X 10.2) or 2.3.0 (Mac OS X 10.3). Python 2.4.1 may be good, but it certainly hasn't had enough eyes on it yet on OS X. This might've been different if there were an installer available, but right now it must be built from source. The version of Python that is packaged with Mac OS X 10.4 is a double-edged sword. If it ships with 2.3.5, then semi-standalone packages built on Mac OS X 10.3 should continue to work (and to a large extent, vice versa). If Python 2.4.x is chosen, it is likely that all semi-standalone applications will break. If it ships with 2.3.5, then Zope should work. If it ships with 2.4.1, it might, but it's not currently a supported configuration AFAIK. Given the history, it's reasonable to assume that we'll be stuck with the shipped version of Python until the next major revision to Mac OS X. If the decision had to be made today, I would hope that they choose 2.3.5. We'll have to see about 2.4.1 when it's released, but 2.3.5 is currently the safest choice and probably the most likely. -bob From pecora at anvil.nrl.navy.mil Fri Feb 18 13:19:49 2005 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Fri Feb 18 13:19:45 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> Message-ID: <4215DD65.2020707@anvil.nrl.navy.mil> Bob Ippolito wrote: > > On Feb 17, 2005, at 18:15, Jack Jansen wrote: > >> MacOSX 10.3, no special requirements: >> Use Apple-supplied Python with the MacPython Additions > > > Tell them to install anyway -- or make it a forced component of > MacPython Additions. As long as it doesn't hurt. And maybe a simple explanation on what PantherPythonFix does and why it's needed. Might help people decide (hopefully, not confuse them -- I'd like to know more). Thanks. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora@anvil.nrl.navy.mil From bob at redivi.com Fri Feb 18 18:23:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 18 18:24:00 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: <4215DD65.2020707@anvil.nrl.navy.mil> References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> <4215DD65.2020707@anvil.nrl.navy.mil> Message-ID: <6aff443fbd721d8823e498012ded0268@redivi.com> On Feb 18, 2005, at 7:19, Louis Pecora wrote: > Bob Ippolito wrote: > >> >> On Feb 17, 2005, at 18:15, Jack Jansen wrote: >> >>> MacOSX 10.3, no special requirements: >>> Use Apple-supplied Python with the MacPython Additions >> >> >> Tell them to install anyway -- or make it a forced component of >> MacPython Additions. > > > As long as it doesn't hurt. And maybe a simple explanation on what > PantherPythonFix does and why it's needed. Might help people decide > (hopefully, not confuse them -- I'd like to know more). It's a bugfix to distutils, so that when you compile stuff it has a higher probability of doing the right thing. It's just a .pkg that you double-click on to install, nothing scary. -bob From rogerb at rogerbinns.com Fri Feb 18 18:54:33 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Feb 18 18:54:25 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> <4215DD65.2020707@anvil.nrl.navy.mil> <6aff443fbd721d8823e498012ded0268@redivi.com> Message-ID: <021201c515e2$e73a7f90$3501a8c0@rogersqyvr14d3> >> As long as it doesn't hurt. And maybe a simple explanation on what >> PantherPythonFix does and why it's needed. Might help people decide >> (hopefully, not confuse them -- I'd like to know more). > > It's a bugfix to distutils, so that when you compile stuff it has a > higher probability of doing the right thing. That doesn't actually answer the question. What is the random operation in distutils whose operation can have its probability changed? Roger From bob at redivi.com Fri Feb 18 19:03:20 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 18 19:03:35 2005 Subject: [Pythonmac-SIG] Main Python on Mac version? In-Reply-To: <021201c515e2$e73a7f90$3501a8c0@rogersqyvr14d3> References: <002701c50ff5$68df0e60$3501a8c0@rogersqyvr14d3> <64ca14354760ade01938e9fc851db1ec@redivi.com> <002c01c51013$4be418f0$3501a8c0@rogersqyvr14d3> <4215DD65.2020707@anvil.nrl.navy.mil> <6aff443fbd721d8823e498012ded0268@redivi.com> <021201c515e2$e73a7f90$3501a8c0@rogersqyvr14d3> Message-ID: <56ac68bdd49796088a63e4fbcbacf6fd@redivi.com> On Feb 18, 2005, at 12:54, Roger Binns wrote: >>> As long as it doesn't hurt. And maybe a simple explanation on what >>> PantherPythonFix does and why it's needed. Might help people decide >>> (hopefully, not confuse them -- I'd like to know more). >> It's a bugfix to distutils, so that when you compile stuff it has a >> higher probability of doing the right thing. > > That doesn't actually answer the question. What is the random > operation > in distutils whose operation can have its probability changed? It's all stuff about how the linker runs. http://bob.pythonmac.org/archives/2005/02/04/fix-mac-os-x-103s-python -230/ -bob From rbthomas55 at pobox.com Fri Feb 18 22:24:23 2005 From: rbthomas55 at pobox.com (Rick Thomas) Date: Fri Feb 18 22:24:35 2005 Subject: [Pythonmac-SIG] broken web link on Mac Python webpage Message-ID: <75CDF104-81F3-11D9-9072-000393DED12E@pobox.com> A (hopefully) minor nit: On the web page there is a link to a "fix for Apple Python". Unfortunately, clicking the link tries to go to , which doesn't exist. Is it still true that "If you install this on 10.3 it is strongly suggested you also install the fix for Apple Python."? I googled the PythonMac SIG mailing list archives, and could find no mention of this problem. Thanks! Rick From bob at redivi.com Fri Feb 18 22:34:45 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Feb 18 22:34:55 2005 Subject: [Pythonmac-SIG] broken web link on Mac Python webpage In-Reply-To: <75CDF104-81F3-11D9-9072-000393DED12E@pobox.com> References: <75CDF104-81F3-11D9-9072-000393DED12E@pobox.com> Message-ID: <57428319cac510d5b507cb96e13cc928@redivi.com> On Feb 18, 2005, at 4:24 PM, Rick Thomas wrote: > A (hopefully) minor nit: > > On the web page > there is a link to a "fix for Apple Python". Unfortunately, clicking > the link tries to go to > , which doesn't > exist. > > Is it still true that "If you install this on 10.3 it is strongly > suggested you also install the fix for Apple Python."? Yes! > I googled the PythonMac SIG mailing list archives, and could find no > mention of this problem. There's a working link to the download at http://bob.pythonmac.org/archives/2005/02/04/fix-mac-os-x-103s-python -230/ -- along with plenty of references to this problem. -bob From jerdonek at davischoicevoting.org Sat Feb 19 18:49:19 2005 From: jerdonek at davischoicevoting.org (Chris Jerdonek) Date: Sat Feb 19 18:49:27 2005 Subject: [Pythonmac-SIG] mac python gui: Framework vs. wxPython Message-ID: <94BD4C26-829E-11D9-B7AB-000D9335A3AA@davischoicevoting.org> Newcomer question: For making a GUI python application for Mac, what're the differences and pros/cons between (1) using wxPython and (2) using the MacPython modules described in the official python documentation (EasyDialogs, Framework, etc.)? And what's the relationship between these two approaches? Thanks in advance for any help, CHRIS -- (530) 297-6947 http://DavisChoiceVoting.org From kid at kendermedia.com Sat Feb 19 21:12:46 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Sat Feb 19 21:12:57 2005 Subject: [Pythonmac-SIG] mac python gui: Framework vs. wxPython In-Reply-To: <94BD4C26-829E-11D9-B7AB-000D9335A3AA@davischoicevoting.org> References: <94BD4C26-829E-11D9-B7AB-000D9335A3AA@davischoicevoting.org> Message-ID: <42179DBE.9050109@kendermedia.com> This question seems to come up a lot. Here's my quick summary: 1) EasyDialogs is nice but can only do really, really simple things. 2) If you're strictly doing Mac work, pyobjc is your best bet, because you can do basically anything that can be done in Objective-C. You can really use the Mac GUI to its fullest. 3) wxPython's goal is to allow cross-platform programming using native widgets. Though it uses native widgets, you don't get the same level of control that you do with pyobjc. If you're not specifically setting out to do cross-platform deployment, use pyobjc. There have been long threads on GUI toolkits within just the past couple of weeks... check out the mailing list archives for the full scoop. Kevin Chris Jerdonek wrote: > Newcomer question: > > For making a GUI python application for Mac, what're the differences > and pros/cons between (1) using wxPython and (2) using the MacPython > modules described in the official python documentation (EasyDialogs, > Framework, etc.)? > > And what's the relationship between these two approaches? > > Thanks in advance for any help, > CHRIS From sw at wordtech-software.com Sun Feb 20 05:56:32 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Feb 20 05:56:37 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5: some basic questions Message-ID: <42181880.6090301@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK, I installed MacPython 2.3.5. Everything seems OK, but I'm not clear on a few things: 1. I moved my old MacPython-2.3 folder (the Panther MacPython extensions) to MacPython-2.3-bak. Any reason to save any of this stuff? 2. Is 2.3.5 a drop-in replacement for the Apple bits, or does it install beside it? 3. Any issues with PATH that I need to be aware of? "which python" points to /usr/bin/python, and running command-line Python brings up the Apple-installed version. Do I need to add the new Python to my path? If so, where is it? 4. wxPython applications run fine--but which Python are they running against? 5. If I need to uninstall 2.3.5, is it easy, or do I need to reinstall my OS? 6. A lot of the apps I package were done so using the older PythonIDE's "build applet" function. I require users to install the MacPython extensions for Panther as a dependency. Will anything I bundle using the newer stuff require the entire installation of Python 2.3.5 as a dependency, or should things be OK? - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCGBh/JmdQs+6YVcoRApndAJwO/Mqxs4KtmINAfOMhSgf1FwSAzACaAn7H uwtBQIOhWa/rR5IPpAiukvk= =a+ew -----END PGP SIGNATURE----- From bob at redivi.com Sun Feb 20 06:19:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 20 06:19:23 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5: some basic questions In-Reply-To: <42181880.6090301@wordtech-software.com> References: <42181880.6090301@wordtech-software.com> Message-ID: <282a4df0b4a30bda179854362fa3a4bc@redivi.com> On Feb 19, 2005, at 11:56 PM, Kevin Walzer wrote: > OK, I installed MacPython 2.3.5. Everything seems OK, but I'm not clear > on a few things: > > 1. I moved my old MacPython-2.3 folder (the Panther MacPython > extensions) to MacPython-2.3-bak. Any reason to save any of this stuff? If you have a reason to run those tools with the system Python you should keep it. > 2. Is 2.3.5 a drop-in replacement for the Apple bits, or does it > install > beside it? Nothing should ever replace any Apple bits, except for PantherPythonFix which makes some slight but necessary modifications. > 3. Any issues with PATH that I need to be aware of? "which python" > points to /usr/bin/python, and running command-line Python brings up > the > Apple-installed version. Do I need to add the new Python to my path? If > so, where is it? You don't "need" to do anything.. but it's in /usr/local/bin and /Library/Frameworks/Python.framework/Versions/2.3/bin. The former might have other stuff in it installed by other applications, but the latter ONLY has Python (and perhaps some tools installed by distutils). > 4. wxPython applications run fine--but which Python are they running > against? Everything you install from a .pkg is built for the Apple Python 2.3.0, so it is using the original Python. You'll have to compile and install wxPython yourself with and for this Python 2.3.5. > 5. If I need to uninstall 2.3.5, is it easy, or do I need to reinstall > my OS? # note that this will wipe out a Python 2.4 framework if you have that installed too. sudo rm -rf /Library/Frameworks/Python.framework sudo rm -rf /usr/local/bin/python{,w,2.3,2.4} > 6. A lot of the apps I package were done so using the older PythonIDE's > "build applet" function. I require users to install the MacPython > extensions for Panther as a dependency. Will anything I bundle using > the > newer stuff require the entire installation of Python 2.3.5 as a > dependency, or should things be OK? Everything you build with "build applet" will most likely require a full installation of Python 2.3.5 if it works at all. bundlebuilder can break down pretty quickly once you have multiple Pythons around. I wouldn't recommend that you bother with this Python unless you know you *NEED* it (i.e. Zope), or you are using OS X 10.2. -bob From Jack.Jansen at cwi.nl Mon Feb 21 00:20:25 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Feb 21 00:20:14 2005 Subject: [Pythonmac-SIG] broken web link on Mac Python webpage In-Reply-To: <75CDF104-81F3-11D9-9072-000393DED12E@pobox.com> References: <75CDF104-81F3-11D9-9072-000393DED12E@pobox.com> Message-ID: On 18-feb-05, at 22:24, Rick Thomas wrote: > A (hopefully) minor nit: > > On the web page > there is a link to a "fix for Apple Python". Unfortunately, clicking > the link tries to go to > , which doesn't > exist. The link works for me... So, either (a) I fixed it inadvertantly, (b) it only works for me, or (c) we're talking about different links? Can you check whether it works now, and if it doesn't give some details? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Larry.A.Meyn at nasa.gov Mon Feb 21 02:52:53 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Mon Feb 21 02:53:01 2005 Subject: [Pythonmac-SIG] broken web link on Mac Python webpage In-Reply-To: References: <75CDF104-81F3-11D9-9072-000393DED12E@pobox.com> Message-ID: <6620b6f6b93204fef38988fcdebbd9f6@nasa.gov> Jack, You must have fixed it. The link is now Larry On Feb 20, 2005, at 3:20 PM, Jack Jansen wrote: > > On 18-feb-05, at 22:24, Rick Thomas wrote: > >> A (hopefully) minor nit: >> >> On the web page >> there is a link to a "fix for Apple Python". Unfortunately, clicking >> the link tries to go to >> , which doesn't >> exist. > > The link works for me... So, either (a) I fixed it inadvertantly, (b) > it only works for me, or (c) we're talking about different links? > > Can you check whether it works now, and if it doesn't give some > details? > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From kranki at mac.com Mon Feb 21 04:38:48 2005 From: kranki at mac.com (Robert White) Date: Mon Feb 21 04:38:53 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? Message-ID: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> If you are uncertain as to why you need the PanterPythonFix, you might want to review http://mail.python.org/pipermail/python-dev/2004-December/050324.html. If that or its references do not make sense to you, then you need to review the PythonMac wiki about how python is installed in Mac OS X 10.3. If none of these references answer those questions, please let me know and I will try to add additional info to the wiki so that it is more clear. Bob White From troy.rollins at gmail.com Mon Feb 21 05:26:37 2005 From: troy.rollins at gmail.com (Troy Rollins) Date: Mon Feb 21 05:26:40 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5: some basic questions In-Reply-To: <282a4df0b4a30bda179854362fa3a4bc@redivi.com> References: <42181880.6090301@wordtech-software.com> <282a4df0b4a30bda179854362fa3a4bc@redivi.com> Message-ID: <31ac537c05022020263a789e2f@mail.gmail.com> Bob, I had some of the same questions, and really appreciate the concise breakdown you supplied (and Kevin for asking the right questions.) > I wouldn't recommend that you bother with this Python unless you know > you *NEED* it (i.e. Zope), or you are using OS X 10.2. You are referiing to 2.3.5? Keep using Apple's install otherwise is the recommendation? -- Troy Rollins RPSystems, Ltd. www.rpsystems.net From rogerb at rogerbinns.com Mon Feb 21 05:52:18 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Mon Feb 21 05:52:05 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> Message-ID: <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> > 10.3. If none of these references answer those questions, please let > me know and I will try to add additional info to the wiki so that it is > more clear. I am still baffled by all this stuff. Apparently Apple came up with this mechanism (Frameworks) that allows for easy self containment of an environment, as well as allowing for multiple concurrent versions. Then they demonstrate the power of this system by only having one version and never updating it per OS version, as well as hard coding various things. Seperately from that there appears to be some issue with dynamic linking. Apple have their own format (Macho) instead of ELF and the issues are akin to LD_LIBRARY_PATH and rpaths hard coded in libraries. So if all this Apple invented stuff actually has merit, why isn't it used? And if doesn't have merit, or Apple don't bother using it, why not just ignore them and replace it with something that does work, has concurrent versions and is updated? Roger From bob at redivi.com Mon Feb 21 08:47:12 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 21 08:47:11 2005 Subject: [Pythonmac-SIG] MacPython 2.3.5: some basic questions In-Reply-To: <31ac537c05022020263a789e2f@mail.gmail.com> References: <42181880.6090301@wordtech-software.com> <282a4df0b4a30bda179854362fa3a4bc@redivi.com> <31ac537c05022020263a789e2f@mail.gmail.com> Message-ID: <6158ae54f675d0c81d091d047d254b47@redivi.com> On Feb 20, 2005, at 11:26 PM, Troy Rollins wrote: > Bob, I had some of the same questions, and really appreciate the > concise breakdown you supplied (and Kevin for asking the right > questions.) > >> I wouldn't recommend that you bother with this Python unless you know >> you *NEED* it (i.e. Zope), or you are using OS X 10.2. > > You are referiing to 2.3.5? Keep using Apple's install otherwise is > the recommendation? Correct. I would not recommend using 2.3.5 unless you know you *need* it. It's much simpler to just deal with the stock 2.3.0 installation. -bob From bob at redivi.com Mon Feb 21 08:54:39 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 21 08:54:41 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> Message-ID: <652e813a268832179bfd55ee41a1217d@redivi.com> On Feb 20, 2005, at 11:52 PM, Roger Binns wrote: >> 10.3. If none of these references answer those questions, please let >> me know and I will try to add additional info to the wiki so that it >> is more clear. > > I am still baffled by all this stuff. Apparently Apple came up with > this > mechanism (Frameworks) that allows for easy self containment of an > environment, as well as allowing for multiple concurrent versions. > Then they demonstrate the power of this system by only having one > version and never updating it per OS version, as well as hard coding > various things. They're designed to have multiple concurrent versions installed for binary compatibility purposes, and they work fine for that. They are NOT AT ALL designed to be able to facilitate writing software that links against a previous version. However, it's common to have Python 2.3 and Python 2.4 installed and want to be able to link new software against 2.3, so the default framework mechanisms are not suitable for this. http://bob.pythonmac.org/archives/2005/01/05/versioned-frameworks- considered-harmful/ > Seperately from that there appears to be some issue with dynamic > linking. Apple have their own format (Macho) instead of ELF and the > issues are akin to LD_LIBRARY_PATH and rpaths hard coded in libraries. No, not really. Any issues Python had with Mach-O were because we screwed up. > So if all this Apple invented stuff actually has merit, why isn't > it used? And if doesn't have merit, or Apple don't bother using > it, why not just ignore them and replace it with something that > does work, has concurrent versions and is updated? The Mach-O/dyld features are used all over the place. Versioned frameworks are not, because they aren't really that useful and the tool support for them is nonexistent. -bob From rogerb at rogerbinns.com Mon Feb 21 10:16:14 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Mon Feb 21 10:16:18 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> Message-ID: <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> > They are NOT AT ALL designed to be able to facilitate writing software that > links against a previous version. With BitPim on Windows and Linux, the Python interpretter is distributed as part of the binary package. There is absolutely no dependencies on what the user's system has, except base C and X libraries. The build machine uses the standard Python and wxPython binary distributions for the relevant platform, which means that the same binaries as are used by thousands of other users are used. Consequently there is a very high confidence in the binary distributed app. I can also have multiple versions of Python installed on developer machines. Extensions have to be compiled against each version and are installed in the corresponding site-packages directory. I've never tried moving the Pythons after installation and have no idea if it would work or not, and don't care if it doesn't. > However, it's common to have Python > 2.3 and Python 2.4 installed and want to be able to link new software > against 2.3, so the default framework mechanisms are not suitable for > this. If you use distutils on other platforms, it uses the directory it corresponds to. For hand built stuff, you can do something similar: INCLUDEDIR=`python -c "import distutils.sysconfig; print distutils.sysconfig.get_python_inc()"` I am still baffled as to what problem is being solved. Are you trying to allow extensions built against Python 2.3 to magically work on 2.4. (That isn't even possible under Windows and unlikely on Linux). It also looks like py2app doesn't include the Python interpretter. Is that the case? Is that the cause of all these issues? Is there any reason not to include the Python interpretter? From a software quality standpoint, I definitely want the exact Python interpretter from the build machine to be redistributed along with the binary app. Roger From Henning.Ramm at mediapro-gmbh.de Mon Feb 21 10:29:02 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Mon Feb 21 10:29:04 2005 Subject: [Pythonmac-SIG] magic file info Message-ID: I'm looking for a way to retrieve a file's type - not (only) Mac type/creator, but like what the shell command 'file' returns. Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From bob at redivi.com Mon Feb 21 17:02:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 21 17:02:56 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> Message-ID: <112f76df5871309035b870bd1f2742a3@redivi.com> On Feb 21, 2005, at 4:16 AM, Roger Binns wrote: >> They are NOT AT ALL designed to be able to facilitate writing >> software that links against a previous version. > > With BitPim on Windows and Linux, the Python interpretter is > distributed > as part of the binary package. There is absolutely no dependencies on > what the user's system has, except base C and X libraries. > > The build machine uses the standard Python and wxPython binary > distributions > for the relevant platform, which means that the same binaries as are > used > by thousands of other users are used. > > Consequently there is a very high confidence in the binary distributed > app. > > I can also have multiple versions of Python installed on developer > machines. > Extensions have to be compiled against each version and are installed > in > the corresponding site-packages directory. I've never tried moving > the Pythons after installation and have no idea if it would work or > not, > and don't care if it doesn't. Did you read and understand the versioned frameworks blog entry I linked to? What you're saying has basically no relevance to what I said. >> However, it's common to have Python 2.3 and Python 2.4 installed and >> want to be able to link new software against 2.3, so the default >> framework mechanisms are not suitable for this. > > If you use distutils on other platforms, it uses the directory it > corresponds to. For hand built stuff, you can do something similar: > > INCLUDEDIR=`python -c "import distutils.sysconfig; print > distutils.sysconfig.get_python_inc()"` > > I am still baffled as to what problem is being solved. Are you > trying to allow extensions built against Python 2.3 to magically > work on 2.4. (That isn't even possible under Windows and unlikely > on Linux). The includes directory has never been the problem. This issue is only related to the linker, not the compiler. Under certain circumstances, prior to Python 2.3.5/2.4.1, then extensions built on 2.3 would magically work for neither Python 2.3 or 2.4 because they were linked against the 2.4 dylib with 2.3 headers, so you'd get an API mismatch (which is a warning not a hard error, but still..). No. The "-framework Python" link command was originally being used. It had the following problems: (a) in Python 2.3.0-ish times, it was used without "-F". That meant the newest version Python in ~/Library/Frameworks or /Library/Frameworks would be preferred regardless of which Python you were using. (b) in Python 2.3.1-ish times(?) it was used with "-F". That means that you were guaranteed to get the right Frameworks directory in play, but it would still link to the newest version of Python regardless of which one you are using. (c) in Python 2.3.5 it links to the Python dylib directly, not utilizing any of GCC's search algorithms, and now does the right thing all the time. Even with this, due to the way Mach-O works, it breaks an invariant that you have on other platforms: It's possible to share extensions between Pythons of the same major version (e.g. 2.3.x), regardless of where these Pythons are installed. When Python is built to target Mac OS X 10.3 or later using the "-undefined dynamic_lookup" linker flag, when using PantherPythonFix on 2.3.0, Python 2.3.5, or Python 2.4.x, then extensions are not even linked to the Python interpreter so this problem goes away and the invariant is preserved. I understand your frustration in trying to understand the issues at hand here, but please know that they are tricky but solved. This topic comes up a lot and I'm pretty tired of talking about it. > It also looks like py2app doesn't include the Python interpretter. > Is that the case? Is that the cause of all these issues? Is > there any reason not to include the Python interpretter? From > a software quality standpoint, I definitely want the exact Python > interpretter from the build machine to be redistributed along > with the binary app. from - Make the application bundle standalone - Since a typical Python application may have C library dependencies, such as the Python interpreter itself, wxWidgets, etc. a second dependency resolution pass occurs on the application bundle. - Scan the application bundle for all Mach-O files (executables, shared libraries, plugins, extensions, etc.). - Read the load commands from every Mach-O file (using **macholib**) and build a dependency graph. - Copy in every dependent dylib (shared library) and framework that is not already in the application bundle. Note that dylibs and frameworks in vendor locations (``/System`` and ``/usr`` - except for ``/usr/local``) are NOT included in your application bundle. This can include the Python interpreter, if you are using a Python interpreter shipped with Mac OS X. Thus your application may be "tightly bound" to a particular major version of Mac OS X if you are using the vendor Python. - Rewrite the Mach-O load commands such that the libraries know that they have moved inside of an application bundle (i.e. using ``@executable_path`` relative ids). - Strip every Mach-O file of extraneous information (debugging symbols, etc.) to save space. This may be disabled with ``--no-strip``. -bob From bob at redivi.com Mon Feb 21 17:08:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 21 17:08:10 2005 Subject: [Pythonmac-SIG] magic file info In-Reply-To: References: Message-ID: <4251a92019224f331e3e37a45ea4435a@redivi.com> On Feb 21, 2005, at 4:29 AM, wrote: > I'm looking for a way to retrieve a file's type - not (only) Mac > type/creator, but like what the shell command 'file' returns. /usr/bin/magic determines the file type heuristically by parsing /usr/share/file/magic and then reading a couple bytes out of the given file. This appears to be a direct Python translation of the file command, with an embedded copy of a magic table: http://www.demonseed.net/~jp/code/magic.py -bob From rogerb at rogerbinns.com Mon Feb 21 20:53:41 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Mon Feb 21 20:53:43 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> Message-ID: <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> > Did you read and understand the versioned frameworks blog entry I > linked to? What you're saying has basically no relevance to what I > said. I read it all. I see the layout. The section about Mach-O, MH_DYLIB and dyld tie directly in to what I was asking about ELF, LD_LIBRARY_PATH and rpath which you said wasn't relevant. > Under certain circumstances, prior to Python 2.3.5/2.4.1, then > extensions built on 2.3 would magically work for neither Python 2.3 or > 2.4 because they were linked against the 2.4 dylib with 2.3 headers, so > you'd get an API mismatch (which is a warning not a hard error, but > still..). Ok, now we are getting closer. How would one make a failed extension like this? On the other platforms extensions end up below the relevant site-packages directory and distutils ensures the correct header and library directories are supplied. On Windows the Python interpretter shared library has a version number as part of the filename - eg python23.dll. Consequently, once built you cannot force an extension to use any other version of Python. On Linux(ELF) the extensions aren't linked to Python in any way. The symbols are unresolved in the extension. When the extension is loaded into a process, they are resolved at that point against the symbols that exist in the running process. Consequently you could try to build an extension against 2.3 and load it into a process with a 2.4 interpretter. But this never happens in practise because the extensions are stored in a Python version specific site-packages directory. > When Python is built to target Mac > OS X 10.3 or later using the "-undefined dynamic_lookup" linker flag, > when using PantherPythonFix on 2.3.0, Python 2.3.5, or Python 2.4.x, > then extensions are not even linked to the Python interpreter so this > problem goes away and the invariant is preserved. Ok, so that gets the same behaviour as ELF. And presumably if someone tried hard enough they could end up with an extension for 2.3.x running in a process with 2.4.x Python. On other platforms the extensions always end up in a site-packages directory below the relevant Python version. If you have 3 different Pythons installed, you build your extensions 3 times. Is there some goal to avoid having to do that on Mac? > I understand your frustration in trying to understand the issues at > hand here, but please know that they are tricky but solved. This topic > comes up a lot and I'm pretty tired of talking about it. I guess the issue is that things are done differently, there appear to be some breakages, and then some unstated goals, and finally lots of information about fixes for all this, mixed in with various version numbers. The initial thing that came to my mind was "then why do things differently". The unstated goals is probably the hardest bit to understand. Is there some attempt to make extensions work with multiple versions, or did that happen anyway and was a bug? Is there an attempt to make extensions compiled on one machine work with the same version of Python but installed in a different location on another machine? Jack's list from Friday is a good start since it doesn't require understanding. Being in the form of "if your goal is X, then install Y" helps a lot. It will also need some idea of what environment variables (eg PATH) should be set. > This can include the Python interpreter, if you are using > a Python interpreter shipped with Mac OS X. Thus your application > may be "tightly bound" to a particular major version of Mac OS X if you > are using the vendor Python. What is a major version in this context? (ie is it tightly bound to version 10 or 10.3.x?) If the former I don't understand why it is even mentioned. If the latter then it appears to be another Mac-ism. The Windows Python works on Win95 onwards. The Linux one will work on that version of Linux and most other ones released after that version. Roger From bob at redivi.com Mon Feb 21 21:40:39 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 21 21:40:46 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> Message-ID: <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> On Feb 21, 2005, at 2:53 PM, Roger Binns wrote: >> Did you read and understand the versioned frameworks blog entry I >> linked to? What you're saying has basically no relevance to what I >> said. > > I read it all. I see the layout. The section about Mach-O, MH_DYLIB > and dyld tie directly in to what I was asking about ELF, > LD_LIBRARY_PATH > and rpath which you said wasn't relevant. You quoted something about link-time linker support for frameworks and then talk about runtime linker support.. >> Under certain circumstances, prior to Python 2.3.5/2.4.1, then >> extensions built on 2.3 would magically work for neither Python 2.3 >> or 2.4 because they were linked against the 2.4 dylib with 2.3 >> headers, so you'd get an API mismatch (which is a warning not a hard >> error, but still..). > > Ok, now we are getting closer. How would one make a failed extension > like this? On the other platforms extensions end up below the relevant > site-packages directory and distutils ensures the correct header > and library directories are supplied. If you have Python 2.X and Python 2.Y both installed, as frameworks, in the same location, then "-framework Python" will pick the version marked as Current by way of symlink, which is the one that is installed last. The headers are picked up by way of -I, which points to the correct headers. If there is a mismatch, then you will have the API of Python 2.X due to correct headers but you will be using the symbols from Python 2.Y because GCC will have linked to the wrong Python. Extensions linked in this way are stillborn, if loaded into a Python 2.X process then they will end up loading two Pythons in-process and will get "Fatal Python error: Interpreter not initialized (version mismatch?)". If loaded into a Python 2.Y process (which would take some serious effort, since they will be installed to the 2.X site-packages) then they will get "warning: Python C API version mismatch for module". The fix was to not use "-framework Python" and instead point directly to the correct dylib. These fixes are fixing clearly broken behavior, not adding features or functionality. > On Windows the Python interpretter shared library has a version number > as part of the filename - eg python23.dll. Consequently, once built > you cannot force an extension to use any other version of Python. This is true on Mac OS X if NOT using "-undefined dynamic_lookup" (10.2 compatible). > On Linux(ELF) the extensions aren't linked to Python in any way. The > symbols are unresolved in the extension. When the extension is loaded > into a process, they are resolved at that point against the symbols > that exist in the running process. Consequently you could try to > build an extension against 2.3 and load it into a process with a > 2.4 interpretter. But this never happens in practise because the > extensions are stored in a Python version specific site-packages > directory. This is true on Mac OS X if using "-undefined dynamic_lookup" (not 10.2 compatible). >> When Python is built to target Mac OS X 10.3 or later using the >> "-undefined dynamic_lookup" linker flag, when using PantherPythonFix >> on 2.3.0, Python 2.3.5, or Python 2.4.x, then extensions are not even >> linked to the Python interpreter so this problem goes away and the >> invariant is preserved. > > Ok, so that gets the same behaviour as ELF. And presumably if > someone tried hard enough they could end up with an extension > for 2.3.x running in a process with 2.4.x Python. You don't have to try *that* hard, but yes. > On other platforms the extensions always end up in a site-packages > directory below the relevant Python version. If you have 3 different > Pythons installed, you build your extensions 3 times. > > Is there some goal to avoid having to do that on Mac? No. >> I understand your frustration in trying to understand the issues at >> hand here, but please know that they are tricky but solved. This >> topic comes up a lot and I'm pretty tired of talking about it. > > I guess the issue is that things are done differently, there appear to > be some breakages, and then some unstated goals, and finally lots of > information about fixes for all this, mixed in with various version > numbers. The initial thing that came to my mind was "then why do > things differently". The unstated goals is probably the hardest bit > to understand. Things aren't done differently.. > Is there some attempt to make extensions work with multiple versions, > or did that happen anyway and was a bug? Is there an attempt to make > extensions compiled on one machine work with the same version of Python > but installed in a different location on another machine? There is no attempt to make extensions work on multiple versions of Python. Extensions built without the fix may have had a mismatch between Pythons but they didn't actually work in either Python. Yes it was clearly a bug. Having extensions that can migrate between Python interpreters installed in different locations (such as inside of an application bundle) is definitely a goal, and was achieved with "-undefined dynamic_lookup" -- but is incompatible with Mac OS X 10.2 and earlier -- so both behaviors have to be supported. py2app of course prefers relocatable extensions, but it can solve the issue the hard way by rewriting the extension's Mach-O load commands to relocate it at build time, but there are some edge cases where it won't work (if there isn't enough room in the header to accommodate the new load commands, which has a very, very, very low chance of occurring -- I have never seen it nor heard any reports of it). > Jack's list from Friday is a good start since it doesn't require > understanding. Being in the form of "if your goal is X, then > install Y" helps a lot. It will also need some idea of what > environment variables (eg PATH) should be set. What's hard to understand about "Install this fix if you use Python at all on Mac OS X 10.3"? If you don't do it, you will probably run across a problem eventually. I'd like to add the following goal to the list: If your goal is to use any version of Python at all on Mac OS X 10.3, then install PantherPythonFix as soon as possible. Yes, a tutorial about how to manipulate your PATH and environment plist is certainly useful information. >> This can include the Python interpreter, if you are using >> a Python interpreter shipped with Mac OS X. Thus your application >> may be "tightly bound" to a particular major version of Mac OS X if >> you are using the vendor Python. > > What is a major version in this context? (ie is it tightly bound to > version 10 or 10.3.x?) If the former I don't understand why it is even > mentioned. If the latter then it appears to be another Mac-ism. The > Windows Python works on Win95 onwards. The Linux one will work on > that version of Linux and most other ones released after that version. Like Python, a major version of OS X is the combination of the first *two* numbers in the version. So yes, Mac OS X 10.3 is a major version. You didn't really include enough context here. What py2app says is that it will never, under any circumstance, include ANY vendor files. In other words, it will not (probably illegally) redistribute any files that Apple dropped on your computer if they are in their original locations. Therefore, if you build an application with a Python interpreter that was distributed by Apple, then your application *will not embed Python*. So, it will *only* work on machines that have the *same* version of Python installed to the *same location*. Therefore, if Mac OS X 10.4 does not include Python 2.3, then applications built using the standard Mac OS X 10.3 interpreter will no longer work. If it does include Python 2.3, and it is installed in the same location, then it is going to work. This is *not* a Mac-ism. -bob From charles.hartman at conncoll.edu Tue Feb 22 01:49:51 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 22 01:49:57 2005 Subject: [Pythonmac-SIG] cross-platform puzzle Message-ID: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> This may be the wrong list for this question. Send me away if so, but I thought I'd try here first. I'm building Mac and Windows versions of an application with a dictionary as one main data structure. A dialog box lets the user type a string which is then used to change the value associated with one of the keys, or to generate a new key-value pair. At least if the pair is new, on Windows the test if word in self.Dict: newvalue = self.Dict[word] fails even though, in the debugger, the string I see for 'word' is identical to one of the keys now visible in self.Dict. This is in Windows only; the Mac version works fine. The dialog box is making the proper return on both platforms, and the new key-value pair is being inserted into the dictionary. I haven't yet checked what happens if the key was an existing one and only the value is changed, and I suppose that might turn out to be the crucial question. But either way, I'm very puzzled to find a cross-platform disparity in this area. What am I missing? Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com From bob at redivi.com Tue Feb 22 02:03:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 22 02:03:32 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> Message-ID: <1f7e154a29b91e03617337bbbd680272@redivi.com> On Feb 21, 2005, at 7:49 PM, Charles Hartman wrote: > This may be the wrong list for this question. Send me away if so, but > I thought I'd try here first. > > I'm building Mac and Windows versions of an application with a > dictionary as one main data structure. A dialog box lets the user type > a string which is then used to change the value associated with one of > the keys, or to generate a new key-value pair. At least if the pair is > new, on Windows the test > if word in self.Dict: > newvalue = self.Dict[word] > fails even though, in the debugger, the string I see for 'word' is > identical to one of the keys now visible in self.Dict. This is in > Windows only; the Mac version works fine. > > The dialog box is making the proper return on both platforms, and the > new key-value pair is being inserted into the dictionary. I haven't > yet checked what happens if the key was an existing one and only the > value is changed, and I suppose that might turn out to be the crucial > question. But either way, I'm very puzzled to find a cross-platform > disparity in this area. What am I missing? I don't think you've provided enough detail to provide a useful guess. You don't even specify what "fails" means, let alone which toolkit you're using to collect the input from the user, etc. Those two lines of code are going to do the same thing regardless of platform and should never raise an exception (if that's what "fail" means) -- assuming that Dict is a dict and word is a str or unicode (which is what you implied). -bob From charles.hartman at conncoll.edu Tue Feb 22 02:58:09 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 22 02:58:19 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: <1f7e154a29b91e03617337bbbd680272@redivi.com> References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <1f7e154a29b91e03617337bbbd680272@redivi.com> Message-ID: <8cb51083ff0b5dbe35c61c653c669515@conncoll.edu> Sorry, I'll try to be more specific. I'm using wxPython 2.5.3.1, developing under Mac 10.3 with the factory-issue Framework Python 2.3. I'm trying to run also under Win XP (when I get time on a Windows machine every other day). I'm using the WingIDE on both platforms. The app contains a dictionary whose keys are strings (English words) and whose values are lists of strings (one string per syllable, stress encoded as all caps). The program can figure out the syllabification and stress of about 5/6 of the words it encounters, so the dictionary contains the exceptions. If the user thinks the program is giving a word the wrong number of syllables or the wrong stress, s/he can double-click on the word, which brings up a wx.Dialog. The dialog has two fields (plus OK and Cancel buttons) The first field shows how the program thinks the word should be treated -- either the value associated with it in the dictionary or the value returned by routines that figure out syllabification and stress. (The user sees no difference between these cases.) The second field is a text field that allows the user to type in a new encoding for the word (syllables delimited by spaces, the stressed syllable in all caps). The string which the user types in is converted to a list of strings, like the other values in the dictionary. If the word was already a key in the dictionary, its value is replaced by the new one. If not, the word is added to the dictionary as a new key, with a value which is the list made from the string typed by the user. On both Mac and Windows, the modal wx.Dialog comes up fine. When it's closed the return value (the string typed by the user) is as expected. If the word was not a key in the dictionary, it shows up as a new key whose value is the string the user typed in. All correct on both platforms. After that, the program goes back and looks up all the words (in the line of words being processed) in the dictionary. Again, if it doesn't find a word it calculates how to syllabify-and-stress it. The method that does this begins by testing whether the word is in the dictionary: if word in self.SD.Dict: return self.SD.Dict[word][:] else . . . ('word' is the string which may be a dictionary key. 'self' is the class containing most of the metrical-scansion routines. 'SD' is a class, of which 'self' owns the unique instance, that's mostly a wrapper around a data item called 'Dict', which is the dictionary in question.) So if 'word' is one of the keys in the dictionary, the second line should return the value -- a syllable-and-stress-encoded string -- or rather a copy of it so that we don't mess up the dictionary when we later fiddle with the syllable strings. That's how it works on Mac. On Windows, with a word that's been added to the dictionary as a new key, when it gets to the line 'if word in self.SD.Dict:' it does NOT go to the next line ('return self.SD.Dict[word][:]'), but skips to the 'else' (which contains code that calls functions that figure out syllables and stress). By "fails" I mean the test for 'word' as a key in 'self.SD.Dict' apparently returns false, even though it has been successfully added. At least this is true when the process involves adding a new key. I haven't yet tested whether the problem turns up when the key already existed. But in a way it doesn't matter -- what I don't understand is why what I think is a very simple dictionary lookup should find the key on the Mac and not find it on Windows. In the debugger I can look at both values -- 'word' and an entry in self.SD.Dict -- and see the same string. Is that any clearer? I know I could easily have made a dumb mistake that would keep the whole thing from working. But it works perfectly on Mac and does not work on Windows. That's what has me baffled. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Feb 21, 2005, at 8:03 PM, Bob Ippolito wrote: > > On Feb 21, 2005, at 7:49 PM, Charles Hartman wrote: > >> This may be the wrong list for this question. Send me away if so, but >> I thought I'd try here first. >> >> I'm building Mac and Windows versions of an application with a >> dictionary as one main data structure. A dialog box lets the user >> type a string which is then used to change the value associated with >> one of the keys, or to generate a new key-value pair. At least if the >> pair is new, on Windows the test >> if word in self.Dict: >> newvalue = self.Dict[word] >> fails even though, in the debugger, the string I see for 'word' is >> identical to one of the keys now visible in self.Dict. This is in >> Windows only; the Mac version works fine. >> >> The dialog box is making the proper return on both platforms, and the >> new key-value pair is being inserted into the dictionary. I haven't >> yet checked what happens if the key was an existing one and only the >> value is changed, and I suppose that might turn out to be the crucial >> question. But either way, I'm very puzzled to find a cross-platform >> disparity in this area. What am I missing? > > I don't think you've provided enough detail to provide a useful guess. > You don't even specify what "fails" means, let alone which toolkit > you're using to collect the input from the user, etc. > > Those two lines of code are going to do the same thing regardless of > platform and should never raise an exception (if that's what "fail" > means) -- assuming that Dict is a dict and word is a str or unicode > (which is what you implied). > > -bob > From kevino at tulane.edu Tue Feb 22 03:12:02 2005 From: kevino at tulane.edu (Kevin Ollivier) Date: Tue Feb 22 03:12:12 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> Message-ID: <6befa2d41fba4a18b0d822e5a79e2dab@tulane.edu> Hi Charles, On Feb 21, 2005, at 4:49 PM, Charles Hartman wrote: > This may be the wrong list for this question. Send me away if so, but > I thought I'd try here first. > > I'm building Mac and Windows versions of an application with a > dictionary as one main data structure. A dialog box lets the user type > a string which is then used to change the value associated with one of > the keys, or to generate a new key-value pair. At least if the pair is > new, on Windows the test > if word in self.Dict: > newvalue = self.Dict[word] Out of curiosity, have you tried the has_key() dictionary method, like "if self.Dict.has_key(word):"? Thanks, Kevin From bob at redivi.com Tue Feb 22 03:15:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 22 03:16:07 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: <8cb51083ff0b5dbe35c61c653c669515@conncoll.edu> References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <1f7e154a29b91e03617337bbbd680272@redivi.com> <8cb51083ff0b5dbe35c61c653c669515@conncoll.edu> Message-ID: On Feb 21, 2005, at 8:58 PM, Charles Hartman wrote: > On Feb 21, 2005, at 8:03 PM, Bob Ippolito wrote: > >> >> On Feb 21, 2005, at 7:49 PM, Charles Hartman wrote: >> >>> This may be the wrong list for this question. Send me away if so, >>> but I thought I'd try here first. >>> >>> I'm building Mac and Windows versions of an application with a >>> dictionary as one main data structure. A dialog box lets the user >>> type a string which is then used to change the value associated with >>> one of the keys, or to generate a new key-value pair. At least if >>> the pair is new, on Windows the test >>> if word in self.Dict: >>> newvalue = self.Dict[word] >>> fails even though, in the debugger, the string I see for 'word' is >>> identical to one of the keys now visible in self.Dict. This is in >>> Windows only; the Mac version works fine. >>> >>> The dialog box is making the proper return on both platforms, and >>> the new key-value pair is being inserted into the dictionary. I >>> haven't yet checked what happens if the key was an existing one and >>> only the value is changed, and I suppose that might turn out to be >>> the crucial question. But either way, I'm very puzzled to find a >>> cross-platform disparity in this area. What am I missing? >> >> I don't think you've provided enough detail to provide a useful >> guess. You don't even specify what "fails" means, let alone which >> toolkit you're using to collect the input from the user, etc. >> >> Those two lines of code are going to do the same thing regardless of >> platform and should never raise an exception (if that's what "fail" >> means) -- assuming that Dict is a dict and word is a str or unicode >> (which is what you implied). >> > Sorry, I'll try to be more specific. I'm using wxPython 2.5.3.1, > developing under Mac 10.3 with the factory-issue Framework Python 2.3. > I'm trying to run also under Win XP (when I get time on a Windows > machine every other day). I'm using the WingIDE on both platforms. And on Windows XP you are also using wxPython 2.5.3.1 with Python 2.3? > The app contains a dictionary whose keys are strings (English words) > and whose values are lists of strings (one string per syllable, stress > encoded as all caps). The program can figure out the syllabification > and stress of about 5/6 of the words it encounters, so the dictionary > contains the exceptions. If the user thinks the program is giving a > word the wrong number of syllables or the wrong stress, s/he can > double-click on the word, which brings up a wx.Dialog. The dialog has > two fields (plus OK and Cancel buttons) The first field shows how the > program thinks the word should be treated -- either the value > associated with it in the dictionary or the value returned by routines > that figure out syllabification and stress. (The user sees no > difference between these cases.) The second field is a text field that > allows the user to type in a new encoding for the word (syllables > delimited by spaces, the stressed syllable in all caps). The string > which the user types in is converted to a list of strings, like the > other values in the dictionary. If the word was already a key in the > dictionary, its value is replaced by the new one. If not, the word is > added to the dictionary as a new key, with a value which is the list > made from the string typed by the user. > > On both Mac and Windows, the modal wx.Dialog comes up fine. When it's > closed the return value (the string typed by the user) is as expected. > If the word was not a key in the dictionary, it shows up as a new key > whose value is the string the user typed in. All correct on both > platforms. > > After that, the program goes back and looks up all the words (in the > line of words being processed) in the dictionary. Again, if it doesn't > find a word it calculates how to syllabify-and-stress it. The method > that does this begins by testing whether the word is in the > dictionary: > if word in self.SD.Dict: > return self.SD.Dict[word][:] > else . . . > ('word' is the string which may be a dictionary key. 'self' is the > class containing most of the metrical-scansion routines. 'SD' is a > class, of which 'self' owns the unique instance, that's mostly a > wrapper around a data item called 'Dict', which is the dictionary in > question.) So if 'word' is one of the keys in the dictionary, the > second line should return the value -- a syllable-and-stress-encoded > string -- or rather a copy of it so that we don't mess up the > dictionary when we later fiddle with the syllable strings. Are you sure that 'word' and the return value of wx.Dialog are precisely str or unicode? Check type(word) to see. Are you sure that there isn't any extraneous whitespace? Especially line endings? On Windows you might see '\r\n' for line endings, where you'll see either just '\r' or just '\n' on Mac OS X (depending on where the string is coming from). The best way to split lines in Python is the ".splitlines()" method of str or unicode, as it deals with all three flavors (including the obscene mixed line endings case). You should look at the repr() of word to make sure it has exactly what you expect it to have (probably just the word, with no whitespace or anything). Note that strings are immutable in Python, and if "Dict" has strings for values then the copy-by-slice is extraneous. There's no reason to make a copy of an object that can't possibly be changed. I'm pretty sure that slicing a string like that is going to return the same object anyway. > That's how it works on Mac. On Windows, with a word that's been added > to the dictionary as a new key, when it gets to the line 'if word in > self.SD.Dict:' it does NOT go to the next line ('return > self.SD.Dict[word][:]'), but skips to the 'else' (which contains code > that calls functions that figure out syllables and stress). By "fails" > I mean the test for 'word' as a key in 'self.SD.Dict' apparently > returns false, even though it has been successfully added. > > At least this is true when the process involves adding a new key. I > haven't yet tested whether the problem turns up when the key already > existed. But in a way it doesn't matter -- what I don't understand is > why what I think is a very simple dictionary lookup should find the > key on the Mac and not find it on Windows. In the debugger I can look > at both values -- 'word' and an entry in self.SD.Dict -- and see the > same string. > > Is that any clearer? I know I could easily have made a dumb mistake > that would keep the whole thing from working. But it works perfectly > on Mac and does not work on Windows. That's what has me baffled. My best guess is whitespace given what you've said.. -bob From bob at redivi.com Tue Feb 22 03:17:58 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 22 03:18:04 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: <6befa2d41fba4a18b0d822e5a79e2dab@tulane.edu> References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <6befa2d41fba4a18b0d822e5a79e2dab@tulane.edu> Message-ID: <8ad0e1d4152e27b4c4f7d5b8bc639dc7@redivi.com> On Feb 21, 2005, at 9:12 PM, Kevin Ollivier wrote: > On Feb 21, 2005, at 4:49 PM, Charles Hartman wrote: > >> This may be the wrong list for this question. Send me away if so, but >> I thought I'd try here first. >> >> I'm building Mac and Windows versions of an application with a >> dictionary as one main data structure. A dialog box lets the user >> type a string which is then used to change the value associated with >> one of the keys, or to generate a new key-value pair. At least if the >> pair is new, on Windows the test >> if word in self.Dict: >> newvalue = self.Dict[word] > > Out of curiosity, have you tried the has_key() dictionary method, like > "if self.Dict.has_key(word):"? I wouldn't go down that road, I'm pretty confident that this isn't a bug in Python :) -bob From charles.hartman at conncoll.edu Tue Feb 22 04:29:54 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 22 04:30:01 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <1f7e154a29b91e03617337bbbd680272@redivi.com> <8cb51083ff0b5dbe35c61c653c669515@conncoll.edu> Message-ID: On Feb 21, 2005, at 9:15 PM, Bob Ippolito wrote: > Note that strings are immutable in Python, and if "Dict" has strings > for values then the copy-by-slice is extraneous. There's no reason to > make a copy of an object that can't possibly be changed. I'm pretty > sure that slicing a string like that is going to return the same > object anyway. The value (not the key) is a list of strings. The strings are immutable, but (if I understand rightly) the list is not. Without the slice-copy, when I later replace one of the strings *in* the list, the dictionary's own list gets changed. Your suggestion about whitespace sounds entirely plausible. I thought of something along that line, and looked for it with some care. But obviously I must have missed something -- and strings-with-whitespace are the only plausible Win/Mac distinction in the vicinity. If I can get at the Windows machine tomorrow I'll try to check this again. Charles Hartman From charles.hartman at conncoll.edu Tue Feb 22 04:30:49 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 22 04:30:54 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: <8ad0e1d4152e27b4c4f7d5b8bc639dc7@redivi.com> References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <6befa2d41fba4a18b0d822e5a79e2dab@tulane.edu> <8ad0e1d4152e27b4c4f7d5b8bc639dc7@redivi.com> Message-ID: <76865072f46682b66f334d7b8d3a6902@conncoll.edu> On Feb 21, 2005, at 9:17 PM, Bob Ippolito wrote: > > On Feb 21, 2005, at 9:12 PM, Kevin Ollivier wrote: > >> On Feb 21, 2005, at 4:49 PM, Charles Hartman wrote: >> >>> This may be the wrong list for this question. Send me away if so, >>> but I thought I'd try here first. >>> >>> I'm building Mac and Windows versions of an application with a >>> dictionary as one main data structure. A dialog box lets the user >>> type a string which is then used to change the value associated with >>> one of the keys, or to generate a new key-value pair. At least if >>> the pair is new, on Windows the test >>> if word in self.Dict: >>> newvalue = self.Dict[word] >> >> Out of curiosity, have you tried the has_key() dictionary method, >> like "if self.Dict.has_key(word):"? > > I wouldn't go down that road, I'm pretty confident that this isn't a > bug in Python :) > > -bob -- but I'll check it anyway for my own peace of mind. Charles Hartman From bob at redivi.com Tue Feb 22 05:25:14 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 22 05:25:20 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <1f7e154a29b91e03617337bbbd680272@redivi.com> <8cb51083ff0b5dbe35c61c653c669515@conncoll.edu> Message-ID: <4d809b30b759c1ce231fba1bab46e542@redivi.com> On Feb 21, 2005, at 10:29 PM, Charles Hartman wrote: > On Feb 21, 2005, at 9:15 PM, Bob Ippolito wrote: > >> Note that strings are immutable in Python, and if "Dict" has strings >> for values then the copy-by-slice is extraneous. There's no reason >> to make a copy of an object that can't possibly be changed. I'm >> pretty sure that slicing a string like that is going to return the >> same object anyway. > > The value (not the key) is a list of strings. The strings are > immutable, but (if I understand rightly) the list is not. Without the > slice-copy, when I later replace one of the strings *in* the list, the > dictionary's own list gets changed. Yeah, that's correct. I had misread the part of your post that said the values were lists. -bob From rogerb at rogerbinns.com Tue Feb 22 07:25:38 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Feb 22 07:26:06 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> Message-ID: <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> [BTW I apologise for not updating the subject. My questions are in the bigger picture context of Python on Mac, not the need for PantherPythonFix] > You quoted something about link-time linker support for frameworks and > then talk about runtime linker support.. On other platforms they are related. On Windows the contents of a .lib file at link time determines what .dll is linked to at runtime. On Linux/ ELF, rpath information (if used) is embedded at link time and affects runtime. > If you have Python 2.X and Python 2.Y both installed, as frameworks, But earlier messages said that only Apple does the frameworks, and they don't even bother updating the one they did install let alone install other concurrent versions. > ... (10.2 compatible) ... >From this statement and various others it would appear that there were significant changes in the underlying mechanisms for deploying Python between 10.2 and 10.3. I am quite happy to ignore the existence of 10.2 :-) > Things aren't done differently.. Frameworks don't exist on the other platforms, nor did changing symbol resolution, the Mach-O format, just putting all Python stuff in /usr/lib/python-version or c:\python-version. There are many similarities, but it is different. (If it wasn't I wouldn't be asking all these questions :-) > Having extensions that can migrate between Python interpreters > installed in different locations (such as inside of an application > bundle) is definitely a goal, and was achieved with "-undefined > dynamic_lookup" -- but is incompatible with Mac OS X 10.2 and earlier > -- so both behaviors have to be supported. Ok, that all makes sense now. > py2app of course prefers relocatable extensions, but it can solve the > issue the hard way by rewriting the extension's Mach-O load commands to > relocate it at build time, but there are some edge cases where it won't > work (if there isn't enough room in the header to accommodate the new > load commands, which has a very, very, very low chance of occurring -- > I have never seen it nor heard any reports of it). I have to do something similar with wxPython on Linux. It uses rpath to hard code the location of the wxgtk libraries in the C interface modules. That means things just work for users without having to set their LD_LIBRARY_PATH. However it is really bad news for distributing binary apps. I use a program named chrpath to strip out the rpath's. The cx-Freeze initialisation code modifies the LD_LIBRARY_PATH to point to the applications directory first, and so everything works. > What's hard to understand about "Install this fix if you use Python at > all on Mac OS X 10.3"? If you don't do it, you will probably run > across a problem eventually. The PantherPythonFix is obvious. The other cases are more interesting, especially once OS X 10.4 comes out. At that point I will want to build on 10.3 using a Python 2.3 interpretter and extensions, and include that interpretter and extensions in the app bundle so that 10.4 users will use the exact same Python as everyone else. Since you won't make py2app redistribute the system Python, it means I have to use some other one and then deal with PATH and whatever else so that the correct one is picked up by default. And then when we start using Python 2.4, OS X 10.3 will probably still be the base OS so more interesting version issues will arise. > This is *not* a Mac-ism. It is certainly a Mac-ism that the system Python is not redistributable :-) Roger From rogerb at rogerbinns.com Tue Feb 22 08:24:53 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Feb 22 08:24:55 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec Message-ID: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> Can anyone give me hints on how to access the Qualcomm Purevoice codec that is part of Quicktime from Python? In BitPim we convert between wav and Purevoice using the convertor that Qualcomm provides: http://www.cdmatech.com/solutions/products/purevoice_download.jsp Note that they don't supply it for MacOS X. There is however a codec inside Quicktime. Ideally I want as close functionality as possible as their Windows and Linux binaries. In those cases the command line tool is named pvconv and takes one parameter. If given a wav file (mono, 8000Hz sampling rate) then it is converted to a corresponding Purevoice file with a .qcp extension. If given a qcp file then it is converted to wav. I'd also be happy with C code that accomplishes the same thing since I can package that up as a binary or Python module. The format is also known sometimes as QCELP. I couldn't find anything relevant using Google. There is a Carbon.QT module but none of the methods appear to do any form of conversion. Carbon.Snd only appears to do recording and playback from the audio device and doesn't know about codecs. Roger From bob at redivi.com Tue Feb 22 10:32:14 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 22 10:32:31 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> Message-ID: <8f14b5b6ef71e86203576d1340e980e4@redivi.com> On Feb 22, 2005, at 1:25, Roger Binns wrote: > [BTW I apologise for not updating the subject. My questions are > in the bigger picture context of Python on Mac, not the need for > PantherPythonFix] > >> You quoted something about link-time linker support for frameworks >> and then talk about runtime linker support.. > > On other platforms they are related. On Windows the contents of a .lib > file at link time determines what .dll is linked to at runtime. On > Linux/ > ELF, rpath information (if used) is embedded at link time and affects > runtime. Yes, of course, they're related but not in the context you quoted. From the perspective of the runtime linker (dyld), there is really no difference between dylibs in a framework or outside of one except under exceptional conditions. They're both MH_DYLIB Mach-O files with no difference in link commands or anything else. Frameworks are about 98% link time and 2% runtime (the runtime handling for frameworks only kicks into effect upon certain environment variables or to handle frameworks). It's been a couple months since I've read the source to dyld, but I'm pretty sure that *versioned* frameworks have zero runtime support, they're entirely a link time "feature". The deficiencies of versioned frameworks are in the tools, not the implementation. >> If you have Python 2.X and Python 2.Y both installed, as frameworks, > > But earlier messages said that only Apple does the frameworks, and > they don't even bother updating the one they did install let alone > install other concurrent versions. Earlier message says that Apple only does the frameworks, not only Apple does the frameworks. MacPython 2.3.5 is a framework build, for example. >> ... (10.2 compatible) ... > >> From this statement and various others it would appear that there > were significant changes in the underlying mechanisms for deploying > Python between 10.2 and 10.3. I am quite happy to ignore the existence > of 10.2 :-) I would love to ignore the existence of 10.2, but that's not really even an option until the release of 10.4 at the earliest. >> Things aren't done differently.. > > Frameworks don't exist on the other platforms, nor did changing symbol > resolution, the Mach-O format, just putting all Python stuff in > /usr/lib/python-version or c:\python-version. There are many > similarities, but it is different. (If it wasn't I wouldn't be > asking all these questions :-) From the perspective of a Python developer, when you are using a version of Python without distutils bugs, then things are not done differently. The implementation details are not the same, of course. >> py2app of course prefers relocatable extensions, but it can solve the >> issue the hard way by rewriting the extension's Mach-O load commands >> to relocate it at build time, but there are some edge cases where it >> won't work (if there isn't enough room in the header to accommodate >> the new load commands, which has a very, very, very low chance of >> occurring -- I have never seen it nor heard any reports of it). > > I have to do something similar with wxPython on Linux. It uses rpath > to hard code the location of the wxgtk libraries in the C interface > modules. That means things just work for users without having to set > their LD_LIBRARY_PATH. However it is really bad news for distributing > binary apps. I use a program named chrpath to strip out the rpath's. > The cx-Freeze initialisation code modifies the LD_LIBRARY_PATH to > point to the applications directory first, and so everything works. Yeah, py2app does all of this automatically, including building a dependency graph of everything you use, etc. >> What's hard to understand about "Install this fix if you use Python >> at all on Mac OS X 10.3"? If you don't do it, you will probably run >> across a problem eventually. > > The PantherPythonFix is obvious. The other cases are more interesting, > especially once OS X 10.4 comes out. At that point I will want to > build > on 10.3 using a Python 2.3 interpretter and extensions, and include > that interpretter and extensions in the app bundle so that 10.4 users > will use the exact same Python as everyone else. > > Since you won't make py2app redistribute the system Python, it means > I have to use some other one and then deal with PATH and whatever > else so that the correct one is picked up by default. Well as I said in the py2app documentation, if you want maximum future compatibility you're going to have to use your own installation of Python and let py2app embed it into your application bundles. Yes, you will have to set your PATH if you want this one to be default. For my commercial application, I have a Python framework built for OS X 10.2 with a set of extensions built for OS X 10.2, and my build scripts make sure to invoke this particular Python (because it's not for general use) when doing the build with py2app. py2app doesn't introduce any versioning issues, so if you build all of your extensions on a 10.2 environment and successfully distribute it to another machine then you can use it to assemble it with py2app at a later date on any version of Mac OS X and it will remain 10.2 compatible. It is not yet public knowledge as to whether applications built with the vendor Python 2.3.0 on Mac OS X 10.3 will work on Mac OS X 10.4. Given that Python 2.3.x was in the WWDC sources and setup to build as a framework in the same place, then signs point to yes. However, if Apple changes their minds and go with 2.4, then the answer will probably be no. > And then when we start using Python 2.4, OS X 10.3 will probably still > be the base OS so more interesting version issues will arise. Assuming you are all patched up (PantherPythonFix'ed Python 2.3.0, MacPython 2.3.5+, MacPython 2.4.1+ when it exists) then all three flavors of framework Python will live together just fine with no issues at all. You will not be able to reliably share extensions between interpreters because: - You are likely to have extensions compiled prior to PantherPythonFix, which are tightly bound to the location of that interpreter and can not be shared - MacPython 2.3.5 as built by Jack is 10.2 compatible, so its distutils will build extensions that can not be shared as they are tightly bound to that interpreter - Python 2.4 and Python 2.3 are not API compatible In other words for a maximally redistributable application: - Install PantherPythonFix immediately, on any Mac OS X 10.3 machine that you will use distutils on, without hesitation - Build your application and all extensions on the lowest common denominator version of Mac OS X *not* using the vendor Python. - Run py2app on your application with this environment (though it may be on another machine on a newer version of Mac OS X if you can figure out how to copy the environment to another machine). >> This is *not* a Mac-ism. > > It is certainly a Mac-ism that the system Python is not > redistributable :-) On Windows there is no vendor Python. I don't really care about Linux -- I'm sure it's possible to bundle the vendor Python with your application, but I'm not sure why you would do such a thing. Is that default behavior for cx_Freeze? Anyway, there is no technical reason that py2app can't bundle the vendor Python, it is my decision, and I'm not going to change my mind. I'm not going to make py2app build applications that are illegal to redistribute by default. Additionally, until the release of Mac OS X 10.4, there is absolutely no reason whatsoever to bundle the vendor Python, because the resultant application bundle will simply be larger. It won't work on Mac OS X 10.2 or earlier. As py2app is liberally licensed, if you'd like to fork it to allow you to redistribute Apple files, you can do it. Who knows, it might be a good way to meet some of the folks at Apple's legal department ;) -bob From Henning.Ramm at mediapro-gmbh.de Tue Feb 22 10:38:14 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Tue Feb 22 10:38:16 2005 Subject: [Pythonmac-SIG] magic file info Message-ID: >/usr/bin/magic determines the file type heuristically by parsing >/usr/share/file/magic and then reading a couple bytes out of the given >file. > >This appears to be a direct Python translation of the file command, >with an embedded copy of a magic table: >http://www.demonseed.net/~jp/code/magic.py Thank you! I could have written a "magic" parser myself, but it's better if I don't need to. ;-) I only thought there would be a standard module that I overlooked. Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From charles.hartman at conncoll.edu Tue Feb 22 18:11:17 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Feb 22 18:14:11 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <1f7e154a29b91e03617337bbbd680272@redivi.com> <8cb51083ff0b5dbe35c61c653c669515@conncoll.edu> Message-ID: You were (Bob was) more or less right -- which is no surprise. The problem turned out to stem from the fact that when the dialog-processing code adds a new word as a dictionary key, what it adds is a string that wx.TextCtrl returns when a word is double-clicked. On Windows, this included a trailling space, on Mac it didn't. So when the word-without-trailing-space was looked up, the program could find it on Mac but not on Windows. So why did my wx.TextCtrl show different double-click behavior on the two platforms? Though I'm using Python 2.3 on both, my wxPython on Mac is 2.5.3.1 and on Win it was 2.5.2.8 (dumb!) so I thought that might be the problem. But no: I upgraded on Win, and I get the same behavior. I'll report this on the wxPython list. Easily fixed, of course -- in the dialog-return code, instead of word = selstring.lower() I just make it word = selstring.lower().strip() Many thanks! It was driving me crazy, and you steered me right. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com On Feb 21, 2005, at 9:15 PM, Bob Ippolito wrote: > > On Feb 21, 2005, at 8:58 PM, Charles Hartman wrote: > >> On Feb 21, 2005, at 8:03 PM, Bob Ippolito wrote: >> >>> >>> On Feb 21, 2005, at 7:49 PM, Charles Hartman wrote: >>> >>>> This may be the wrong list for this question. Send me away if so, >>>> but I thought I'd try here first. >>>> >>>> I'm building Mac and Windows versions of an application with a >>>> dictionary as one main data structure. A dialog box lets the user >>>> type a string which is then used to change the value associated >>>> with one of the keys, or to generate a new key-value pair. At least >>>> if the pair is new, on Windows the test >>>> if word in self.Dict: >>>> newvalue = self.Dict[word] >>>> fails even though, in the debugger, the string I see for 'word' is >>>> identical to one of the keys now visible in self.Dict. This is in >>>> Windows only; the Mac version works fine. >>>> >>>> The dialog box is making the proper return on both platforms, and >>>> the new key-value pair is being inserted into the dictionary. I >>>> haven't yet checked what happens if the key was an existing one and >>>> only the value is changed, and I suppose that might turn out to be >>>> the crucial question. But either way, I'm very puzzled to find a >>>> cross-platform disparity in this area. What am I missing? >>> >>> I don't think you've provided enough detail to provide a useful >>> guess. You don't even specify what "fails" means, let alone which >>> toolkit you're using to collect the input from the user, etc. >>> >>> Those two lines of code are going to do the same thing regardless of >>> platform and should never raise an exception (if that's what "fail" >>> means) -- assuming that Dict is a dict and word is a str or unicode >>> (which is what you implied). >>> >> Sorry, I'll try to be more specific. I'm using wxPython 2.5.3.1, >> developing under Mac 10.3 with the factory-issue Framework Python >> 2.3. I'm trying to run also under Win XP (when I get time on a >> Windows machine every other day). I'm using the WingIDE on both >> platforms. > > And on Windows XP you are also using wxPython 2.5.3.1 with Python 2.3? > >> The app contains a dictionary whose keys are strings (English words) >> and whose values are lists of strings (one string per syllable, >> stress encoded as all caps). The program can figure out the >> syllabification and stress of about 5/6 of the words it encounters, >> so the dictionary contains the exceptions. If the user thinks the >> program is giving a word the wrong number of syllables or the wrong >> stress, s/he can double-click on the word, which brings up a >> wx.Dialog. The dialog has two fields (plus OK and Cancel buttons) The >> first field shows how the program thinks the word should be treated >> -- either the value associated with it in the dictionary or the value >> returned by routines that figure out syllabification and stress. (The >> user sees no difference between these cases.) The second field is a >> text field that allows the user to type in a new encoding for the >> word (syllables delimited by spaces, the stressed syllable in all >> caps). The string which the user types in is converted to a list of >> strings, like the other values in the dictionary. If the word was >> already a key in the dictionary, its value is replaced by the new >> one. If not, the word is added to the dictionary as a new key, with a >> value which is the list made from the string typed by the user. >> >> On both Mac and Windows, the modal wx.Dialog comes up fine. When it's >> closed the return value (the string typed by the user) is as >> expected. If the word was not a key in the dictionary, it shows up as >> a new key whose value is the string the user typed in. All correct on >> both platforms. >> >> After that, the program goes back and looks up all the words (in the >> line of words being processed) in the dictionary. Again, if it >> doesn't find a word it calculates how to syllabify-and-stress it. The >> method that does this begins by testing whether the word is in the >> dictionary: >> if word in self.SD.Dict: >> return self.SD.Dict[word][:] >> else . . . >> ('word' is the string which may be a dictionary key. 'self' is the >> class containing most of the metrical-scansion routines. 'SD' is a >> class, of which 'self' owns the unique instance, that's mostly a >> wrapper around a data item called 'Dict', which is the dictionary in >> question.) So if 'word' is one of the keys in the dictionary, the >> second line should return the value -- a syllable-and-stress-encoded >> string -- or rather a copy of it so that we don't mess up the >> dictionary when we later fiddle with the syllable strings. > > Are you sure that 'word' and the return value of wx.Dialog are > precisely str or unicode? Check type(word) to see. Are you sure that > there isn't any extraneous whitespace? Especially line endings? On > Windows you might see '\r\n' for line endings, where you'll see either > just '\r' or just '\n' on Mac OS X (depending on where the string is > coming from). The best way to split lines in Python is the > ".splitlines()" method of str or unicode, as it deals with all three > flavors (including the obscene mixed line endings case). You should > look at the repr() of word to make sure it has exactly what you expect > it to have (probably just the word, with no whitespace or anything). > > Note that strings are immutable in Python, and if "Dict" has strings > for values then the copy-by-slice is extraneous. There's no reason to > make a copy of an object that can't possibly be changed. I'm pretty > sure that slicing a string like that is going to return the same > object anyway. > >> That's how it works on Mac. On Windows, with a word that's been added >> to the dictionary as a new key, when it gets to the line 'if word in >> self.SD.Dict:' it does NOT go to the next line ('return >> self.SD.Dict[word][:]'), but skips to the 'else' (which contains code >> that calls functions that figure out syllables and stress). By >> "fails" I mean the test for 'word' as a key in 'self.SD.Dict' >> apparently returns false, even though it has been successfully added. >> >> At least this is true when the process involves adding a new key. I >> haven't yet tested whether the problem turns up when the key already >> existed. But in a way it doesn't matter -- what I don't understand is >> why what I think is a very simple dictionary lookup should find the >> key on the Mac and not find it on Windows. In the debugger I can look >> at both values -- 'word' and an entry in self.SD.Dict -- and see the >> same string. >> >> Is that any clearer? I know I could easily have made a dumb mistake >> that would keep the whole thing from working. But it works perfectly >> on Mac and does not work on Windows. That's what has me baffled. > > My best guess is whitespace given what you've said.. > > -bob > From rogerb at rogerbinns.com Tue Feb 22 18:18:19 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Feb 22 18:18:20 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> Message-ID: <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> > so if you build all of your extensions on a 10.2 environment BTW I don't actually have a 10.2 environment. The Mac Mini comes with 10.3. > In other words for a maximally redistributable application: > - Install PantherPythonFix immediately, on any Mac OS X 10.3 machine > that you will use distutils on, without hesitation My biggest 3rd party dependency is wxPython. Is there any way of telling if it was built on a machine with the fix applied? > - Build your application and all extensions on the lowest common > denominator version of Mac OS X *not* using the vendor Python. I don't see a MacPython for 10.3. > I don't really care about Linux > -- I'm sure it's possible to bundle the vendor Python with your > application, but I'm not sure why you would do such a thing. Is that > default behavior for cx_Freeze? It is the default behaviour of both py2exe and cx-Freeze to bundle the Python interpretter with your app. No distinction is made between vendor and non-vendor. I believe they can also both be made to not include an interpretter, but that is *very* rare. The simple reason for always including the interpretter is because you know things work. Otherwise you are at the mercy of whatever can be on other machines which will generally various incompatible versions. (On Linux Python is randomly compiled as two bytes per unicode char on some machines and four bytes on others.) For non-trivial apps, there isn't much in the way of binary compatibility. For example, look at the most popular app on SourceForge, and how they have different downloads for each Linux distro and version: http://gaim.sourceforge.net/downloads.php Roger From bob at redivi.com Tue Feb 22 19:16:11 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 22 19:16:17 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 22, 2005, at 12:18, Roger Binns wrote: >> so if you build all of your extensions on a 10.2 environment > > BTW I don't actually have a 10.2 environment. The Mac Mini comes > with 10.3. Then you can't build 10.2 compatible software.. no big deal. >> In other words for a maximally redistributable application: >> - Install PantherPythonFix immediately, on any Mac OS X 10.3 machine >> that you will use distutils on, without hesitation > > My biggest 3rd party dependency is wxPython. Is there any way of > telling if it was built on a machine with the fix applied? It wasn't. >> - Build your application and all extensions on the lowest common >> denominator version of Mac OS X *not* using the vendor Python. > > I don't see a MacPython for 10.3. MacPython for 10.2 works with 10.3. >> I don't really care about Linux -- I'm sure it's possible to bundle >> the vendor Python with your application, but I'm not sure why you >> would do such a thing. Is that default behavior for cx_Freeze? > > It is the default behaviour of both py2exe and cx-Freeze to bundle the > Python interpretter with your app. No distinction is made between > vendor and non-vendor. I believe they can also both be made to not > include an interpretter, but that is *very* rare. There is no vendor Python on Windows, so py2exe can make no such distinction. > The simple reason for always including the interpretter is because > you know things work. Otherwise you are at the mercy of whatever > can be on other machines which will generally various incompatible > versions. (On Linux Python is randomly compiled as two bytes per > unicode char on some machines and four bytes on others.) For > non-trivial apps, there isn't much in the way of binary compatibility. > For example, look at the most popular app on SourceForge, and how > they have different downloads for each Linux distro and version: > http://gaim.sourceforge.net/downloads.php It's the default behavior of py2app to bundle the interpreter too, except in the vendor case. -bob From mwh at python.net Tue Feb 22 20:45:14 2005 From: mwh at python.net (Michael Hudson) Date: Tue Feb 22 20:45:17 2005 Subject: [Pythonmac-SIG] cross-platform puzzle In-Reply-To: (Charles Hartman's message of "Tue, 22 Feb 2005 12:11:17 -0500") References: <49b6dedc6a107187c3013bf812836eab@conncoll.edu> <1f7e154a29b91e03617337bbbd680272@redivi.com> <8cb51083ff0b5dbe35c61c653c669515@conncoll.edu> Message-ID: <2m8y5gv0ol.fsf@starship.python.net> Charles Hartman writes: > So why did my wx.TextCtrl show different double-click behavior on the > two platforms? Though I'm using Python 2.3 on both, my wxPython on Mac > is 2.5.3.1 and on Win it was 2.5.2.8 (dumb!) so I thought that might > be the problem. But no: I upgraded on Win, and I get the same > behavior. I'll report this on the wxPython list. I think it might be the underlying controls behaving differently. Certainly on Mac double-clicking gets you just the word selected (but if you then press delete, a preceding space will be deleted). It's too long since I used windows to be sure how it behaves, but it wouldn't surprise me if it was different. Cheers, mwh -- > Emacs is a fashion statement. No, Gnus is a fashion statement. Emacs is clothing. Everyone else is running around naked. -- Karl Kleinpaste & Jonadab the Unsightly One, gnu.emacs.gnus From Chris.Barker at noaa.gov Tue Feb 22 23:23:13 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Feb 22 23:24:30 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> Message-ID: <421BB0D1.80609@noaa.gov> Bob Ippolito wrote: > It is not yet public knowledge as to whether applications built with > the vendor Python 2.3.0 on Mac OS X 10.3 will work on Mac OS X 10.4. > Given that Python 2.3.x was in the WWDC sources and setup to build as > a framework in the same place, then signs point to yes. However, if > Apple changes their minds and go with 2.4, then the answer will > probably be no. Is there any way to us to lobby Apple to include whatever bits of python 2.3 are needed to keep Py2App bundled apps running on new systems, when they upgrade to 2.4? > Yes, you will have to set your PATH if you want this one to be > default. I never do this. Whenever I've run multiple version of python, with any given python code, I know what version I want to use, so I put something like: #!/usr/bin/env python2.3.4 at the top of the __main__ file and the setup.py, and I'm done. It's more reliable that messing with PATH, and hoping it stays in the right order. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Tue Feb 22 23:37:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Feb 22 23:37:42 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: <421BB0D1.80609@noaa.gov> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <421BB0D1.80609@noaa.gov> Message-ID: On Feb 22, 2005, at 17:23, Chris Barker wrote: > Bob Ippolito wrote: > >> It is not yet public knowledge as to whether applications built with >> the vendor Python 2.3.0 on Mac OS X 10.3 will work on Mac OS X 10.4. >> Given that Python 2.3.x was in the WWDC sources and setup to build as >> a framework in the same place, then signs point to yes. However, if >> Apple changes their minds and go with 2.4, then the answer will >> probably be no. > > Is there any way to us to lobby Apple to include whatever bits of > python > 2.3 are needed to keep Py2App bundled apps running on new systems, > when they upgrade to 2.4? http://bugreport.apple.com/ >> Yes, you will have to set your PATH if you want this one to be >> default. > > I never do this. Whenever I've run multiple version of python, with any > given python code, I know what version I want to use, so I put > something > like: > > #!/usr/bin/env python2.3.4 > > at the top of the __main__ file and the setup.py, and I'm done. It's > more reliable that messing with PATH, and hoping it stays in the right > order. I also rarely screw with PATH. Using /usr/bin/env is saying "let PATH decide". I use explicit paths like: # MacPython 2.3.5 /usr/local/bin/python2.3 # DarwinPorts Python 2.3.5 /opt/local/bin/python2.3 etc.. -bob From kim.branson at gmail.com Wed Feb 23 00:05:17 2005 From: kim.branson at gmail.com (Kim Branson) Date: Wed Feb 23 00:05:28 2005 Subject: [Pythonmac-SIG] package manager. In-Reply-To: <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> Message-ID: <2d46d3cb799c2e57a32cdd86f068e169@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > HI all, this is probably a question that has been answered on the wiki, but i can't seem to find it. I decided to try and upgrade my version of Numeric (currently 23.1) (building the latest Biopython was causing errors) but the packagmanager gives me a 404 errror opening http://www.python.org/packman/version-0.3/darwin-7.80- Power_Macintosh.plist. I've tried the official unofficial database, but when i attempt to upgrade numeric I get told that there is no package for apple installed python 2.3 download manually. I thought all macpython used apples python now? ealier in the night i tried to install a few packages, like reportlab, and the packager appeared to die half way through. I was letting me download packages, but have i corrupted its database? Can i repair this, or should I attempt to build all these packages by hand. If so can anyone resolve the errors in building i have below? cheers Kim Building numeric 23.7 from the source dies, building 'lapack_lite' extension gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.8.0-Power_Macintosh-2.3/Src/lapack_litemodule.o - -L/usr/lib/atlas -llapack -lcblas -lf77blas -latlas -lg2c -o build/lib.darwin-7.8.0-Power_Macintosh-2.3/lapack_lite.so -framework vecLib ld: warning -L: directory name (/usr/lib/atlas) does not exist ld: can't locate file for: -llapack error: command 'gcc' failed with exit status 1 Building Biopython1.40b fails with Bio/Cluster/clustermodule.c:2:33: Numeric/arrayobject.h: No such file or directory Bio/Cluster/clustermodule.c:20: error: parse error before "PyArrayObject" Bio/Cluster/clustermodule.c:2:33: Numeric/arrayobject.h: No such file or directory Bio/Cluster/clustermodule.c:20: error: parse error before "PyArrayObject" Dr Kim Branson Peter Doherty Fellow Protein Structure and Function St Vincents Institute for Medical Research 41 Victoria Parade, Fitzroy Victoria 3065, Australia. Phone: +613 9288 2480 Fax: +613 94162 676 Ph +613 9662 7136 kbranson@svi.edu.au kim.branson@gmail.com www.svi.edu.au -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCG7qter2hmGbHcokRAnuQAJ4uXdKQRdl7QbE4Q9MhjqdQ9XPUnACgpk7Q iTG4ghKd1x3jBERpACax8DI= =j37O -----END PGP SIGNATURE----- From Chris.Barker at noaa.gov Wed Feb 23 00:06:09 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Wed Feb 23 00:07:27 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <421BB0D1.80609@noaa.gov> Message-ID: <421BBAE1.9010103@noaa.gov> Bob Ippolito wrote: > I also rarely screw with PATH. Using /usr/bin/env is saying "let PATH > decide". right. I am always working across platforms, so I want to specify which python to use, but not specify where to find it. > I use explicit paths like: > # MacPython 2.3.5 > /usr/local/bin/python2.3 > # DarwinPorts Python 2.3.5 > /opt/local/bin/python2.3 which are not going to work on my Linux box. I guess if you want to have two different python2.3.4s, you need to do this, however. -CHB -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From rkern at ucsd.edu Wed Feb 23 00:15:07 2005 From: rkern at ucsd.edu (Robert Kern) Date: Wed Feb 23 00:15:18 2005 Subject: [Pythonmac-SIG] package manager. In-Reply-To: <2d46d3cb799c2e57a32cdd86f068e169@gmail.com> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> <2d46d3cb799c2e57a32cdd86f068e169@gmail.com> Message-ID: <421BBCFB.6000208@ucsd.edu> Kim Branson wrote: > HI all, > > this is probably a question that has been answered on the wiki, but i > can't seem to find it. > I decided to try and upgrade my version of Numeric (currently 23.1) > (building the latest Biopython was causing errors) but the > packagmanager gives me a 404 errror opening > http://www.python.org/packman/version-0.3/darwin-7.80- > Power_Macintosh.plist. These package repositories are pretty much unmaintained now. An up-to-date Installer.app-type package is available thanks to Bob Ippolito. http://undefined.org/python/packages.html -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Wed Feb 23 00:30:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 00:31:02 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: <421BBAE1.9010103@noaa.gov> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <421BB0D1.80609@noaa.gov> <421BBAE1.9010103@noaa.gov> Message-ID: <05d3958442a3e2d02b0564422d8e9653@redivi.com> On Feb 22, 2005, at 18:06, Chris Barker wrote: > > > Bob Ippolito wrote: >> I also rarely screw with PATH. Using /usr/bin/env is saying "let >> PATH decide". > > right. I am always working across platforms, so I want to specify > which python to use, but not specify where to find it. > >> I use explicit paths like: # MacPython 2.3.5 >> /usr/local/bin/python2.3 >> # DarwinPorts Python 2.3.5 >> /opt/local/bin/python2.3 > > which are not going to work on my Linux box. I guess if you want to > have two different python2.3.4s, you need to do this, however. /usr/bin/env python2.3.5 is only going to work if Python 2.3.5 is already on your PATH. If you do not explicitly change your path, it will never be there, since /usr/local/bin, /opt/local/bin, etc. are not on the PATH by default. -bob From rogerb at rogerbinns.com Wed Feb 23 08:39:17 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 23 08:39:16 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> Message-ID: <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> >> My biggest 3rd party dependency is wxPython. Is there any way of >> telling if it was built on a machine with the fix applied? > > It wasn't. Thank you for checking. I have passed on the request to Robin to run PantherPythonFix on his 10.3 build machine. > There is no vendor Python on Windows, so py2exe can make no such > distinction. Technically there is on many HP/Compaq machines :-) And in the thread on setting PATH, that is exactly what I need to do since the code is cross platform. I actually can't see *any* benefit to me at all of Apple's Python. Are there any instructions anywhere on how to remove Apple's version, and put on an official Python.org blessed version and ensure the latter resides somewhere on my path? The various web pages are all pretty confusing and appear contradictory: http://www.python.org/download/ http://www.python.org/download/download_mac.html http://homepages.cwi.nl/~jack/macpython/ http://homepages.cwi.nl/~jack/macpython/beta.html Roger From bob at redivi.com Wed Feb 23 09:06:14 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 09:06:23 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> Message-ID: <39e061a352d4a0086bac2489a8e6dc7a@redivi.com> On Feb 23, 2005, at 2:39 AM, Roger Binns wrote: >> There is no vendor Python on Windows, so py2exe can make no such >> distinction. > > Technically there is on many HP/Compaq machines :-) But is that runtime actually "accessible", or is it stashed away in a dark corner? > And in the thread on setting PATH, that is exactly what I need to > do since the code is cross platform. Not really, the only point that matters is when you run "python setup.py py2app". It doesn't matter what the #! line is in your main script or setup.py -- unless of course your setup.py is +x and you start it as an executable, but I don't think that's very common. > I actually can't see *any* benefit to me at all of Apple's Python. The largest benefit is that you can get binary packages of stuff that work with it. With a user framework install of 2.3.5, you'll basically have to find packages designated for Jaguar, since the people that package stuff only support the vendor Python on Panther. These packages generally are compiled with only Jaguar features. For example, there is no unicode version of wxPython available for Jaguar (since libiconv didn't ship on Jaguar, and they don't compile it into wxPython I guess). PyObjC's Jaguar installer is missing some of the support for Mac OS X 10.3 features, etc. In most other cases, Jaguar packages simply are not available. However, if the packages were built with PantherPythonFix, then they can be trivially migrated from the vendor Python to your installation simply by copying from /Library/Python/2.3 to the appropriate site-packages folder. Unfortunately, very few packages have been built with such an environment (though at least most, but probably all, of the ones that I provide probably are). As another note, if you are using the MacPython 2.3.5 from Jack's site, it will use Jaguar style linking since it was built for 10.2. So anything built with that Python will not be portable back to the vendor Python. > Are there any instructions anywhere on how to remove Apple's > version, and put on an official Python.org blessed version and > ensure the latter resides somewhere on my path? Do not, under any circumstance, remove anything Apple put on your machine. Unless you REALLY know what you're doing. If you don't want to use Apple's Python, then don't use it, but don't try and get rid of it. Generally, other Python installations cause problems with Apple's (unless it has been PantherPythonFixed), but not vice versa. -bob From mwh at python.net Wed Feb 23 13:19:47 2005 From: mwh at python.net (Michael Hudson) Date: Wed Feb 23 13:19:49 2005 Subject: [Pythonmac-SIG] Why do I need PantherPythonFix? In-Reply-To: <421BBAE1.9010103@noaa.gov> (Chris Barker's message of "Tue, 22 Feb 2005 15:06:09 -0800") References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <421BB0D1.80609@noaa.gov> <421BBAE1.9010103@noaa.gov> Message-ID: <2mekf7tqn0.fsf@starship.python.net> "Chris Barker" writes: > Bob Ippolito wrote: >> I also rarely screw with PATH. Using /usr/bin/env is saying "let >> PATH decide". > > right. I am always working across platforms, so I want to specify > which python to use, but not specify where to find it. If you use distutils, the script header should be rewritten correctly on installation. If it's just a script though, distutils is overkill. Cheers, mwh (who generally is in the situation that typing a bare "python" into a shell gets you something you don't want) -- I think if we have the choice, I'd rather we didn't explicitly put flaws in the reST syntax for the sole purpose of not insulting the almighty. -- /will on the doc-sig From mww at opendarwin.org Wed Feb 23 14:13:14 2005 From: mww at opendarwin.org (Markus Weissmann) Date: Wed Feb 23 14:13:22 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> Message-ID: <4dd0768cfccec278dec5e3462c15fd5d@opendarwin.org> On 23. Feb 2005, at 8:39 Uhr, Roger Binns wrote: > I actually can't see *any* benefit to me at all of Apple's Python. > > Are there any instructions anywhere on how to remove Apple's > version, and put on an official Python.org blessed version and > ensure the latter resides somewhere on my path? > If you don't see any benefit in a Framework installation of Python, then there probably aren't any for you... =) You could then install python from DarwinPorts [1] or fink [2] and they will happily live beside Apple's version - just let the newly installed python precede Apple's python in your $PATH and you'll be done. -Markus [1] http://darwinports.opendarwin.org/ [2] http://fink.sourceforge.net/ --- Markus W. Weissmann http://www.mweissmann.de/ http://www.opendarwin.org/~mww/ From sw at wordtech-software.com Wed Feb 23 14:15:21 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Wed Feb 23 14:15:22 2005 Subject: [Pythonmac-SIG] Tkinter package? Message-ID: <421C81E9.1090301@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If the older package repositories are now unmaintained, how would one install the Tkinter module? - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHIHoJmdQs+6YVcoRAqxqAJ9BFWNVkDyMgZRLMBMP9RecajjcVgCeKVEu HimQDTgdfRfy+6B98P1koyI= =u5dI -----END PGP SIGNATURE----- From bob at redivi.com Wed Feb 23 14:49:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 14:49:44 2005 Subject: [Pythonmac-SIG] Tkinter package? In-Reply-To: <421C81E9.1090301@wordtech-software.com> References: <421C81E9.1090301@wordtech-software.com> Message-ID: On Feb 23, 2005, at 8:15, Kevin Walzer wrote: > If the older package repositories are now unmaintained, how would one > install the Tkinter module? The one that's up there should still work, it's not something that's really going to be updated anyway. -bob From bob at redivi.com Wed Feb 23 14:54:01 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 14:54:06 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <4dd0768cfccec278dec5e3462c15fd5d@opendarwin.org> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> <4dd0768cfccec278dec5e3462c15fd5d@opendarwin.org> Message-ID: <259587b89fc0270aa6624615fabb3782@redivi.com> On Feb 23, 2005, at 8:13, Markus Weissmann wrote: > > On 23. Feb 2005, at 8:39 Uhr, Roger Binns wrote: > >> I actually can't see *any* benefit to me at all of Apple's Python. >> >> Are there any instructions anywhere on how to remove Apple's >> version, and put on an official Python.org blessed version and >> ensure the latter resides somewhere on my path? >> > > If you don't see any benefit in a Framework installation of Python, > then there probably aren't any for you... =) > > You could then install python from DarwinPorts [1] or fink [2] and they > will happily live beside Apple's version - just let the newly installed > python precede Apple's python in your $PATH and you'll be done. Non-framework builds of Python don't ship with a Python interpreter in an application bundle, so there is no 'pythonw' script. That makes it impossible to run a Carbon or Cocoa based GUI app before going through py2app or bundlebuilder (you should do that anyway, but...). His problem with Apple's Python has nothing to do with the fact that it's a framework build, anyway. -bob From kid at kendermedia.com Wed Feb 23 15:08:08 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Wed Feb 23 15:08:10 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 Message-ID: <421C8E48.7040808@kendermedia.com> For a few reasons, I am moving my app to Python 2.4. It runs fine when I use py2app -A, but it doesn't work when I try to build a full standalone application. At first, "doesn't work" meant that Twisted's cfreactor couldn't find _CarbonEvt. If I specifically ask to include _CarbonEvt, I get a bus error. I ran it through gdb and this is what I got: Program received signal EXC_BAD_ACCESS, Could not access memory. 0x007615e4 in PyObjCFFI_BuildResult (methinfo=0xbdcae0, argOffset=2, pRetval=0x77e088, byref=0xbcf130, byref_out_count=0, self=0x1f690b0, flags=0) at Modules/objc/libffi_support.m:929 929 if (self != NULL && objc_result != self I wanted to start with my basic setup and make sure that all is well: When I built Python, I did it as a framework build. I also enabled toolkit glue, but I'm really not sure what that means and haven't seen any docs that tell me. Those were the only two configure options I used. I also just tried rebuilding Python without enable-toolkit-glue to see if it made a difference, and it didn't seem to. I installed PyObjC 1.2 with python setup.py bdist_mpkg --open (this was after making sure that python 2.4 was what I was picking up from my path). I've also tried using py2app 0.1.7 and py2app's svn head. I have an automated build setup that rebuilds all of my third party modules, so running that was easy and I know I have everything there. As I mentioned at the beginning, it runs fine using py2app -A. I wanted to start with making sure the basic steps I've taken so far were okay and then troubleshoot more from there. Anyone see something wrong from there? Suggestions for next steps? Thanks, Kevin From bob at redivi.com Wed Feb 23 15:18:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 15:18:19 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <421C8E48.7040808@kendermedia.com> References: <421C8E48.7040808@kendermedia.com> Message-ID: <492f9b6dfa74841cd327931a2c54634d@redivi.com> On Feb 23, 2005, at 9:08, Kevin Dangoor wrote: > For a few reasons, I am moving my app to Python 2.4. It runs fine when > I use py2app -A, but it doesn't work when I try to build a full > standalone application. At first, "doesn't work" meant that Twisted's > cfreactor couldn't find _CarbonEvt. If I specifically ask to include > _CarbonEvt, I get a bus error. You didn't mention what version of Twisted this was. Twisted 1.3.0 has a broken cfreactor that assumes broken PyObjC 1.0 behavior, so you will need to use Twisted from SVN (or at least the cfsupport module) too. Are you sure it's not that WebKit namespace collision again? :) What was the rest of that backtrace? -bob From kid at kendermedia.com Wed Feb 23 15:50:40 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Wed Feb 23 15:50:45 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <492f9b6dfa74841cd327931a2c54634d@redivi.com> References: <421C8E48.7040808@kendermedia.com> <492f9b6dfa74841cd327931a2c54634d@redivi.com> Message-ID: <421C9840.8080800@kendermedia.com> Bob Ippolito wrote: > > On Feb 23, 2005, at 9:08, Kevin Dangoor wrote: > >> For a few reasons, I am moving my app to Python 2.4. It runs fine >> when I use py2app -A, but it doesn't work when I try to build a full >> standalone application. At first, "doesn't work" meant that Twisted's >> cfreactor couldn't find _CarbonEvt. If I specifically ask to include >> _CarbonEvt, I get a bus error. > > > You didn't mention what version of Twisted this was. Twisted 1.3.0 > has a broken cfreactor that assumes broken PyObjC 1.0 behavior, so you > will need to use Twisted from SVN (or at least the cfsupport module) too. I'm using the Twisted 2.0 pre-alpha that was sort of released a few days back (as in the tarballs were stuck up on radix's page). > > Are you sure it's not that WebKit namespace collision again? :) What > was the rest of that backtrace? Pretty sure about that one. Near the top of my main .py file, before Cheetah has a chance to get at anything, I have an "import WebKit" to make sure that WebKit is installed safely. I added some more logging statements in Python to narrow the problem down to reactor.listenTCP(....). So, this is after the cfreactor has been installed, but before reactor.run() was called. Here is the full backtrace from gdb. It doesn't tell me anything, but maybe it will say something to you: #0 0x007615e4 in PyObjCFFI_BuildResult (methinfo=0xbd3940, argOffset=2, pRetval=0x77e088, byref=0xbd4950, byref_out_count=0, self=0x1f820f0, flags=0) at Modules/objc/libffi_support.m:929 #1 0x00761ef8 in PyObjCFFI_Caller (aMeth=0x1f89188, self=0x1f820f0, args=0x0) at Modules/objc/libffi_support.m:1241 #2 0x00772a24 in objcsel_call (self=0x1f89188, args=0x2c5030) at Modules/objc/selector.m:502 #3 0x1000c798 in PyObject_Call (func=0x1, arg=0x77e088, kw=0x57fb) at Objects/abstract.c:1746 #4 0x1007cd2c in do_call (func=0x1f89188, pp_stack=0xbfffda5c, na=0, nk=7869788) at Python/ceval.c:3755 #5 0x1007ca24 in call_function (pp_stack=0x0, oparg=7856264) at Python/ceval.c:3570 #6 0x1007a488 in PyEval_EvalFrame (f=0x0) at Python/ceval.c:2163 #7 0x1007b5cc in PyEval_EvalCodeEx (co=0x0, globals=0x77e088, locals=0x1, args=0x0, argcount=1227680, kws=0x1007a478, kwcount=1, defs=0x1392ac, defcount=1, closure=0x0) at Python/ceval.c:2730 #8 0x1007cc14 in fast_function (func=0x1, pp_stack=0xbfffda5c, n=0, na=268756608, nk=2) at Python/ceval.c:3640 #9 0x1007ca0c in call_function (pp_stack=0xbfffdcac, oparg=7856264) at Python/ceval.c:3568 #10 0x1007a488 in PyEval_EvalFrame (f=0xbfffdcac) at Python/ceval.c:2163 #11 0x1007b5cc in PyEval_EvalCodeEx (co=0x1, globals=0x77e088, locals=0x1, args=0x1, argcount=1227680, kws=0x1007a478, kwcount=1, defs=0x1392ac, defcount=0, closure=0x0) at Python/ceval.c:2730 #12 0x10026738 in function_call (func=0x1f89188, arg=0x12bba0, kw=0xbfffdcac) at Objects/funcobject.c:550 #13 0x1000c798 in PyObject_Call (func=0x1, arg=0x77e088, kw=0x57fb) at Objects/abstract.c:1746 #14 0x10015ed8 in instancemethod_call (func=0x1952d70, arg=0x1f68210, kw=0x0) at Objects/classobject.c:2431 #15 0x1000c798 in PyObject_Call (func=0x1, arg=0x77e088, kw=0x57fb) at Objects/abstract.c:1746 #16 0x10059fac in slot_tp_init (self=0x6850f0, args=0x1f54c60, kwds=0x0) at Objects/typeobject.c:4752 #17 0x100531e8 in type_call (type=0x1a621e8, args=0x6850f0, kwds=0x1f54c60) at Objects/typeobject.c:435 #18 0x1000c798 in PyObject_Call (func=0x1, arg=0x77e088, kw=0x57fb) at Objects/abstract.c:1746 #19 0x1007cd2c in do_call (func=0xb40b00, pp_stack=0xbfffe38c, na=0, nk=7869788) at Python/ceval.c:3755 #20 0x1007ca24 in call_function (pp_stack=0x0, oparg=7856264) at Python/ceval.c:3570 #21 0x1007a488 in PyEval_EvalFrame (f=0x0) at Python/ceval.c:2163 #22 0x1007cb84 in fast_function (func=0x1, pp_stack=0xbfffe38c, n=0, na=268756608, nk=2) at Python/ceval.c:3629 #23 0x1007ca0c in call_function (pp_stack=0xbfffe53c, oparg=7856264) at Python/ceval.c:3568 #24 0x1007a488 in PyEval_EvalFrame (f=0xbfffe53c) at Python/ceval.c:2163 #25 0x1007cb84 in fast_function (func=0x1, pp_stack=0x0, n=3, na=268756608, nk=2) at Python/ceval.c:3629 #26 0x1007ca0c in call_function (pp_stack=0xbfffe6ec, oparg=7856264) at Python/ceval.c:3568 #27 0x1007a488 in PyEval_EvalFrame (f=0xbfffe6ec) at Python/ceval.c:2163 #28 0x1007cb84 in fast_function (func=0x1, pp_stack=0x0, n=2, na=268756608, nk=2) at Python/ceval.c:3629 #29 0x1007ca0c in call_function (pp_stack=0xbfffe89c, oparg=7856264) at Python/ceval.c:3568 #30 0x1007a488 in PyEval_EvalFrame (f=0xbfffe89c) at Python/ceval.c:2163 #31 0x1007cb84 in fast_function (func=0x1, pp_stack=0x0, n=1, na=268756608, nk=2) at Python/ceval.c:3629 #32 0x1007ca0c in call_function (pp_stack=0xbfffea4c, oparg=7856264) at Python/ceval.c:3568 #33 0x1007a488 in PyEval_EvalFrame (f=0xbfffea4c) at Python/ceval.c:2163 #34 0x1007b5cc in PyEval_EvalCodeEx (co=0x1, globals=0x77e088, locals=0x1, args=0x1, argcount=1227680, kws=0x1007a478, kwcount=1, defs=0x1392ac, defcount=2, closure=0x0) at Python/ceval.c:2730 #35 0x1007cc14 in fast_function (func=0x1, pp_stack=0x0, n=1, na=268756608, nk=2) at Python/ceval.c:3640 #36 0x1007ca0c in call_function (pp_stack=0xbfffec9c, oparg=7856264) at Python/ceval.c:3568 #37 0x1007a488 in PyEval_EvalFrame (f=0xbfffec9c) at Python/ceval.c:2163 #38 0x1007cb84 in fast_function (func=0x1, pp_stack=0x0, n=3, na=268756608, nk=2) at Python/ceval.c:3629 #39 0x1007ca0c in call_function (pp_stack=0xbfffee4c, oparg=7856264) at Python/ceval.c:3568 #40 0x1007a488 in PyEval_EvalFrame (f=0xbfffee4c) at Python/ceval.c:2163 #41 0x1007b5cc in PyEval_EvalCodeEx (co=0x0, globals=0x77e088, locals=0x1, args=0x0, argcount=1227680, kws=0x1007a478, kwcount=1, defs=0x1392ac, defcount=0, closure=0x0) at Python/ceval.c:2730 #42 0x1007e9c0 in PyEval_EvalCode (co=0x1, globals=0x77e088, locals=0x57fb) at Python/ceval.c:484 #43 0x100b31f8 in run_node (n=0x0, filename=0x77e088 "", globals=0x0, locals=0x0, flags=0x1f4b000) at Python/pythonrun.c:1264 #44 0x10070e44 in builtin_execfile (self=0x1, args=0x77e088) at Python/bltinmodule.c:620 #45 0x1007c934 in call_function (pp_stack=0xbfffee4c, oparg=7856264) at Python/ceval.c:3547 #46 0x1007a488 in PyEval_EvalFrame (f=0xbfffee4c) at Python/ceval.c:2163 #47 0x1007b5cc in PyEval_EvalCodeEx (co=0x33bf30, globals=0x77e088, locals=0x1, args=0x12bba0, argcount=1227680, kws=0x1007a478, kwcount=1, defs=0x1392ac, defcount=0, closure=0x0) at Python/ceval.c:2730 #48 0x1007cc14 in fast_function (func=0x1, pp_stack=0x12bba0, n=1227680, na=268756608, nk=2) at Python/ceval.c:3640 #49 0x1007ca0c in call_function (pp_stack=0xbffff3fc, oparg=7856264) at Python/ceval.c:3568 #50 0x1007a488 in PyEval_EvalFrame (f=0xbffff3fc) at Python/ceval.c:2163 #51 0x1007b5cc in PyEval_EvalCodeEx (co=0x1, globals=0x77e088, locals=0x1, args=0x1, argcount=1227680, kws=0x1007a478, kwcount=1, defs=0x1392ac, defcount=0, closure=0x0) at Python/ceval.c:2730 #52 0x1007e9c0 in PyEval_EvalCode (co=0x1, globals=0x77e088, locals=0x57fb) at Python/ceval.c:484 #53 0x100b31f8 in run_node (n=0x1, filename=0x77e088 "", globals=0x1, locals=0x0, flags=0x1f4b000) at Python/pythonrun.c:1264 #54 0x100b2984 in PyRun_SimpleFileExFlags (fp=0xa0009818, filename=0x201c000 "/Users/tazzzzz/projects/news/dist/myapp.app/Contents/Resources/__boot__.py", closeit=-1073744900, flags=0xb40b00) at Python/pythonrun.c:859 From kid at kendermedia.com Wed Feb 23 16:18:52 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Wed Feb 23 16:18:55 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <492f9b6dfa74841cd327931a2c54634d@redivi.com> References: <421C8E48.7040808@kendermedia.com> <492f9b6dfa74841cd327931a2c54634d@redivi.com> Message-ID: <421C9EDC.9000602@kendermedia.com> Bob Ippolito wrote: > > On Feb 23, 2005, at 9:08, Kevin Dangoor wrote: > >> For a few reasons, I am moving my app to Python 2.4. It runs fine >> when I use py2app -A, but it doesn't work when I try to build a full >> standalone application. At first, "doesn't work" meant that Twisted's >> cfreactor couldn't find _CarbonEvt. If I specifically ask to include >> _CarbonEvt, I get a bus error. > > > You didn't mention what version of Twisted this was. Twisted 1.3.0 > has a broken cfreactor that assumes broken PyObjC 1.0 behavior, so you > will need to use Twisted from SVN (or at least the cfsupport module) too. > > Are you sure it's not that WebKit namespace collision again? :) What > was the rest of that backtrace? In Python, I have narrowed this down to here: cfreactor.CFReactor.getRunLoop runLoop = nsRunLoop.getCFRunLoop() From bob at redivi.com Wed Feb 23 16:27:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 16:28:02 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <421C9EDC.9000602@kendermedia.com> References: <421C8E48.7040808@kendermedia.com> <492f9b6dfa74841cd327931a2c54634d@redivi.com> <421C9EDC.9000602@kendermedia.com> Message-ID: <5c00a06f36bd9134184ca3d2401ffd7b@redivi.com> On Feb 23, 2005, at 10:18, Kevin Dangoor wrote: > Bob Ippolito wrote: > >> >> On Feb 23, 2005, at 9:08, Kevin Dangoor wrote: >> >>> For a few reasons, I am moving my app to Python 2.4. It runs fine >>> when I use py2app -A, but it doesn't work when I try to build a full >>> standalone application. At first, "doesn't work" meant that >>> Twisted's cfreactor couldn't find _CarbonEvt. If I specifically ask >>> to include _CarbonEvt, I get a bus error. >> >> >> You didn't mention what version of Twisted this was. Twisted 1.3.0 >> has a broken cfreactor that assumes broken PyObjC 1.0 behavior, so >> you will need to use Twisted from SVN (or at least the cfsupport >> module) too. >> >> Are you sure it's not that WebKit namespace collision again? :) What >> was the rest of that backtrace? > > In Python, I have narrowed this down to here: > > cfreactor.CFReactor.getRunLoop > > runLoop = nsRunLoop.getCFRunLoop() Do the PyObjC Examples/Twisted examples work in your environment? -bob From dave.opstad at monotypeimaging.com Wed Feb 23 16:32:40 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Wed Feb 23 16:32:44 2005 Subject: [Pythonmac-SIG] Tkinter package? In-Reply-To: Message-ID: >> If the older package repositories are now unmaintained, how would one >> install the Tkinter module? > > The one that's up there should still work, it's not something that's > really going to be updated anyway. It still doesn't work, sorta. There was traffic on this list back on November 23 relevant to this. As it just bit me again a couple of days ago when I was setting up my new Mac Mini, I'll briefly recap: When you try to run PackageManager you may get an error like: "Cannot open http://www.python.org/packman/version-0.3/darwin-7.7.1-Power_Macintosh.plist : HTTP Error 404: Not Found" To fix this, choose "Open URL..." from the File menu in PackageManager and specify this URL: http://www.python.org/packman/version-0.3/darwin-7.5.0- Power_Macintosh.plist PM will then open up and you can install _tkinter (or whatever) as usual. Dave Opstad Monotype Imaging From jdgleeson at mac.com Wed Feb 23 16:42:34 2005 From: jdgleeson at mac.com (John Gleeson) Date: Wed Feb 23 16:42:39 2005 Subject: [Pythonmac-SIG] traceback from build_app.py in py2app 0.1.8 Message-ID: <1cd1e10ca0ca9ef1de0094ba80befe51@mac.com> The current svn version of py2app gives the following traceback. My Feb 7 copy of py2app invoked self.copy_versioned_framework(info, dst) instead of copy_versioned_framework(info, dst) : copying build/bdist.darwin-7.8.0-Power_Macintosh/python2.3-semi_standalone/app/ site-packages.zip -> /Users/jgleeson/Projects/Environments/LEO/Leo/dist/Leo.app/Contents/ Resources/Python copying leo/src/leo.py -> /Users/jgleeson/Projects/Environments/LEO/Leo/dist/Leo.app/Contents/ Resources/Python creating /Users/jgleeson/Projects/Environments/LEO/Leo/dist/Leo.app/Contents/ Resources/Python/lib-dynload creating /Users/jgleeson/Projects/Environments/LEO/Leo/dist/Leo.app/Contents/ Frameworks copying /Library/Python/2.3/PIL/_imaging.so -> /Users/jgleeson/Projects/Environments/LEO/Leo/dist/Leo.app/Contents/ Resources/Python/lib-dynload copying /Library/Python/2.3/_tkinter.so -> /Users/jgleeson/Projects/Environments/LEO/Leo/dist/Leo.app/Contents/ Resources/Python/lib-dynload Traceback (most recent call last): File "/Library/Python/2.3/py2app/py2app/build_app.py", line 434, in _run self.run_normal() File "/Library/Python/2.3/py2app/py2app/build_app.py", line 491, in run_normal self.create_binaries(py_files, pkgdirs, extensions) File "/Library/Python/2.3/py2app/py2app/build_app.py", line 583, in create_binaries platfiles = mm.run() File "/Library/Python/2.3/py2app/macholib/MachOStandalone.py", line 90, in run mm.run_file(fn) File "/Library/Python/2.3/py2app/macholib/MachOGraph.py", line 61, in run_file self.scan_node(m) File "/Library/Python/2.3/py2app/macholib/MachOGraph.py", line 84, in scan_node m = self.load_file(filename, caller=node) File "/Library/Python/2.3/py2app/macholib/MachOGraph.py", line 67, in load_file m = self.findNode(name) File "/Library/Python/2.3/py2app/macholib/MachOGraph.py", line 48, in findNode newname = self.locate(name) File "/Library/Python/2.3/py2app/macholib/MachOStandalone.py", line 22, in locate return self.delegate.locate(newname) File "/Library/Python/2.3/py2app/macholib/MachOStandalone.py", line 57, in locate res = self.copy_framework(info) File "/Library/Python/2.3/py2app/py2app/build_app.py", line 42, in copy_framework destfn = self.appbuilder.copy_framework(info, self.dest) File "/Library/Python/2.3/py2app/py2app/build_app.py", line 637, in copy_framework copy_versioned_framework(info, dst) NameError: global name 'copy_versioned_framework' is not defined > /Library/Python/2.3/py2app/py2app/build_app.py(637)copy_framework() -> copy_versioned_framework(info, dst) (Pdb) interrupted From kid at kendermedia.com Wed Feb 23 16:51:40 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Wed Feb 23 16:51:44 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <5c00a06f36bd9134184ca3d2401ffd7b@redivi.com> References: <421C8E48.7040808@kendermedia.com> <492f9b6dfa74841cd327931a2c54634d@redivi.com> <421C9EDC.9000602@kendermedia.com> <5c00a06f36bd9134184ca3d2401ffd7b@redivi.com> Message-ID: <421CA68C.40501@kendermedia.com> Bob Ippolito wrote: > > On Feb 23, 2005, at 10:18, Kevin Dangoor wrote: > >> In Python, I have narrowed this down to here: >> >> cfreactor.CFReactor.getRunLoop >> >> runLoop = nsRunLoop.getCFRunLoop() > > > Do the PyObjC Examples/Twisted examples work in your environment? I tried WebServicesTool and had much the same experience. py2app -A worked fine. Without -A, the app couldn't find _CarbonEvt. I added -i _CarbonEvt and ran into a bus error (in what looks like the same place) Kevin From bob at redivi.com Wed Feb 23 16:57:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 16:57:31 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <421CA68C.40501@kendermedia.com> References: <421C8E48.7040808@kendermedia.com> <492f9b6dfa74841cd327931a2c54634d@redivi.com> <421C9EDC.9000602@kendermedia.com> <5c00a06f36bd9134184ca3d2401ffd7b@redivi.com> <421CA68C.40501@kendermedia.com> Message-ID: <362fb26ad1aef5953bae04ef9283c920@redivi.com> On Feb 23, 2005, at 10:51 AM, Kevin Dangoor wrote: > Bob Ippolito wrote: > >> >> On Feb 23, 2005, at 10:18, Kevin Dangoor wrote: >> >>> In Python, I have narrowed this down to here: >>> >>> cfreactor.CFReactor.getRunLoop >>> >>> runLoop = nsRunLoop.getCFRunLoop() >> >> >> Do the PyObjC Examples/Twisted examples work in your environment? > > I tried WebServicesTool and had much the same experience. py2app -A > worked fine. Without -A, the app couldn't find _CarbonEvt. I added -i > _CarbonEvt and ran into a bus error (in what looks like the same > place) I probably won't be able to look at this until tomorrow, but try comparing sys.modules.keys() between your environment with py2app -A and py2app. -bob From kid at kendermedia.com Wed Feb 23 17:30:24 2005 From: kid at kendermedia.com (Kevin Dangoor) Date: Wed Feb 23 17:30:28 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <362fb26ad1aef5953bae04ef9283c920@redivi.com> References: <421C8E48.7040808@kendermedia.com> <492f9b6dfa74841cd327931a2c54634d@redivi.com> <421C9EDC.9000602@kendermedia.com> <5c00a06f36bd9134184ca3d2401ffd7b@redivi.com> <421CA68C.40501@kendermedia.com> <362fb26ad1aef5953bae04ef9283c920@redivi.com> Message-ID: <421CAFA0.6000306@kendermedia.com> Bob Ippolito wrote: > I probably won't be able to look at this until tomorrow, but try > comparing sys.modules.keys() between your environment with py2app -A > and py2app. in getRunLoop, I added print sys.modules.keys() and then ran the Web Services Tool with and without -A. Without -A (normal standalone app), the following had been imported. They were not imported with -A: 'AppKit.imp', 'AppKit.os', 'AppKit.sys', 'Foundation.imp', 'objc.imp', 'objc.sys', 'twisted.internet.imp', 'twisted.protocols.cStringIO', 'twisted.protocols.imp', 'twisted.protocols.os', 'zlib', 'zope.interface.imp', 'zope.interface.os', I'm guessing that the "imp"s here are probably something special and automatic that py2app does. Probably more relevant is the list of things that were imported with -A, but not without: 'Carbon.CF', 'Carbon._CF', '_CF', Seeing this, I added an explicit import for these in one of my modules. And it worked! Your intuition about the WebKit problem may have been on track. Just as with that case, these imports were ultimately getting called from within a block. Putting them at the module level fixed it. Thanks for the suggestion of looking at sys.modules! I don't think that I was an avenue I would have gone down. Kevin From rogerb at rogerbinns.com Wed Feb 23 17:53:34 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Wed Feb 23 17:53:33 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> <39e061a352d4a0086bac2489a8e6dc7a@redivi.com> Message-ID: <064c01c519c8$36a14760$3501a8c0@rogersqyvr14d3> >> Technically there is on many HP/Compaq machines :-) > > But is that runtime actually "accessible", or is it stashed away in a > dark corner? Very acessible. It definitely starts out as a standard install from python.org and is in the Add/Remove programs in the same way. >> And in the thread on setting PATH, that is exactly what I need to >> do since the code is cross platform. > > Not really, the only point that matters is when you run "python > setup.py py2app". It doesn't matter what the #! line is in your main > script or setup.py -- unless of course your setup.py is +x and you > start it as an executable, but I don't think that's very common. It matters all the rest of the time as well since I also do development! I run the main program as well as many other files (if __name__=='__main__') and having to type the correct path each time would be a pain. >> I actually can't see *any* benefit to me at all of Apple's Python. > > The largest benefit is that you can get binary packages of stuff that > work with it. There are exactly two binary packages I care about. One is readline and the other is wxPython which you discuss. On Windows the installers for binary packages read the locations of installed Pythons from the registry and everything works so smoothly. >> Are there any instructions anywhere on how to remove Apple's >> version, and put on an official Python.org blessed version and >> ensure the latter resides somewhere on my path? > > Do not, under any circumstance, remove anything Apple put on your > machine. Unless you REALLY know what you're doing. One of the web pages said it was an optional install, keyed of selecting some other package. So I take it by your comment that they don't use some sort of packaging system that allows removing packages for Python. Taking a step back, am I the only person who thinks the Python situation on Mac is absolutely ridiculous, although 10.2 looks better than 10.3. All I want is one up to date version of Python on my system, and have binary and source extensions just work. This is what it is like on Windows and Linux. Roger From bob at redivi.com Wed Feb 23 18:07:36 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 18:07:44 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <064c01c519c8$36a14760$3501a8c0@rogersqyvr14d3> References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> <39e061a352d4a0086bac2489a8e6dc7a@redivi.com> <064c01c519c8$36a14760$3501a8c0@rogersqyvr14d3> Message-ID: On Feb 23, 2005, at 11:53 AM, Roger Binns wrote: >>> And in the thread on setting PATH, that is exactly what I need to >>> do since the code is cross platform. >> Not really, the only point that matters is when you run "python >> setup.py py2app". It doesn't matter what the #! line is in your main >> script or setup.py -- unless of course your setup.py is +x and you >> start it as an executable, but I don't think that's very common. > > It matters all the rest of the time as well since I also do > development! > I run the main program as well as many other files (if > __name__=='__main__') > and having to type the correct path each time would be a pain. > >>> I actually can't see *any* benefit to me at all of Apple's Python. >> The largest benefit is that you can get binary packages of stuff that >> work with it. > > There are exactly two binary packages I care about. One is readline > and the other is wxPython which you discuss. On Windows the installers > for binary packages read the locations of installed Pythons from > the registry and everything works so smoothly. It can't do that with a Python linked for 10.2 or extensions compiled without PythonPantherFix unless there is a post-process that rewrites the Mach-O load commands. The py2app machinery is capable of this, but I don't really have the need to support alternate installation locations so I'm not going to write that code. >>> Are there any instructions anywhere on how to remove Apple's >>> version, and put on an official Python.org blessed version and >>> ensure the latter resides somewhere on my path? >> Do not, under any circumstance, remove anything Apple put on your >> machine. Unless you REALLY know what you're doing. > > One of the web pages said it was an optional install, keyed of > selecting > some other package. So I take it by your comment that they don't > use some sort of packaging system that allows removing packages > for Python. The "optional" package that Python comes in is the BSD package. Not installation that package is bad news. Python being optional is a bug, since they use it in their own stuff. It probably won't be optional in future versions of Mac OS X. > Taking a step back, am I the only person who thinks the Python > situation > on Mac is absolutely ridiculous, although 10.2 looks better than 10.3. > All I want is one up to date version of Python on my system, and have > binary and source extensions just work. This is what it is like on > Windows and Linux. As I've said before, the 10.2 stuff works just fine in 10.3. You obviously have no idea how bad the vendor Python was in 10.2 -- believe it or not, 10.3 was a major improvement :) -bob From bob at redivi.com Wed Feb 23 18:15:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 18:15:29 2005 Subject: [Pythonmac-SIG] trouble making a standalone app with Python 2.4 In-Reply-To: <421CAFA0.6000306@kendermedia.com> References: <421C8E48.7040808@kendermedia.com> <492f9b6dfa74841cd327931a2c54634d@redivi.com> <421C9EDC.9000602@kendermedia.com> <5c00a06f36bd9134184ca3d2401ffd7b@redivi.com> <421CA68C.40501@kendermedia.com> <362fb26ad1aef5953bae04ef9283c920@redivi.com> <421CAFA0.6000306@kendermedia.com> Message-ID: On Feb 23, 2005, at 11:30 AM, Kevin Dangoor wrote: > Bob Ippolito wrote: > >> I probably won't be able to look at this until tomorrow, but try >> comparing sys.modules.keys() between your environment with py2app -A >> and py2app. > > in getRunLoop, I added print sys.modules.keys() and then ran the Web > Services Tool with and without -A. > > Without -A (normal standalone app), the following had been imported. > They were not imported with -A: > 'AppKit.imp', > 'AppKit.os', > 'AppKit.sys', > 'Foundation.imp', > 'objc.imp', > 'objc.sys', > 'twisted.internet.imp', > 'twisted.protocols.cStringIO', > 'twisted.protocols.imp', > 'twisted.protocols.os', > 'zlib', > 'zope.interface.imp', > 'zope.interface.os', > > I'm guessing that the "imp"s here are probably something special and > automatic that py2app does. Looks more like a "special and automatic" bug to me ;) It's probably something I inherited from looking at py2exe's source. I plan on rewriting the way that the module system works as soon as the Python Egg runtime is farther along. > Probably more relevant is the list of things that were imported with > -A, but not without: > 'Carbon.CF', > 'Carbon._CF', > '_CF', > > Seeing this, I added an explicit import for these in one of my > modules. And it worked! Your intuition about the WebKit problem may > have been on track. Just as with that case, these imports were > ultimately getting called from within a block. Putting them at the > module level fixed it. > > Thanks for the suggestion of looking at sys.modules! I don't think > that I was an avenue I would have gone down. I'll try and remember to patch Twisted so that this won't happen when I get the chance.. -bob From mwh at python.net Wed Feb 23 20:04:50 2005 From: mwh at python.net (Michael Hudson) Date: Wed Feb 23 20:04:52 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <064c01c519c8$36a14760$3501a8c0@rogersqyvr14d3> (Roger Binns's message of "Wed, 23 Feb 2005 08:53:34 -0800") References: <848a16ae4ac25ae2c44bfe523ca1543d@mac.com> <011701c517d1$1edc3980$3501a8c0@rogersqyvr14d3> <652e813a268832179bfd55ee41a1217d@redivi.com> <020001c517f5$fe5cd410$3501a8c0@rogersqyvr14d3> <112f76df5871309035b870bd1f2742a3@redivi.com> <00d401c5184f$0ad966f0$3501a8c0@rogersqyvr14d3> <9cf11909c7afa675e1bda0f0f4afa4d2@redivi.com> <02fd01c518a7$634134f0$3501a8c0@rogersqyvr14d3> <8f14b5b6ef71e86203576d1340e980e4@redivi.com> <03bf01c51902$812ff540$3501a8c0@rogersqyvr14d3> <051501c5197a$c78a6ed0$3501a8c0@rogersqyvr14d3> <39e061a352d4a0086bac2489a8e6dc7a@redivi.com> <064c01c519c8$36a14760$3501a8c0@rogersqyvr14d3> Message-ID: <2macpvt7vx.fsf@starship.python.net> "Roger Binns" writes: > Taking a step back, am I the only person who thinks the Python situation > on Mac is absolutely ridiculous, although 10.2 looks better than 10.3. As Bob says, you obviously haven't used 10.2... > All I want is one up to date version of Python on my system, and have > binary and source extensions just work. This is what it is like on > Windows and Linux. Don't you remember the days where Redhat came with Python 1.5.2 and if you upgraded that you broke redhat's tools? Plus ca change, plus c'est la meme chose. If you want your Python app to work in perpetuity, you'd better bundle a version of Python with it because one day OS X will presumably come with 2.4 or 2.5. This strikes me as being the same as any other platform. Cheers, mwh -- Every day I send overnight packages filled with rabid weasels to people who use frames for no good reason. -- The Usenet Oracle, Oracularity #1017-1 From just at letterror.com Wed Feb 23 21:28:53 2005 From: just at letterror.com (Just van Rossum) Date: Wed Feb 23 21:28:58 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <2macpvt7vx.fsf@starship.python.net> Message-ID: Michael Hudson wrote: > If you want your Python app to work in perpetuity, you'd better bundle > a version of Python with it because one day OS X will presumably come > with 2.4 or 2.5. This strikes me as being the same as any other > platform. I would _hope_ they'd still keep 2.3(.X) in there for b/w compatibility. That's why there are versioned frameworks to begin with, no? Just From bob at redivi.com Wed Feb 23 23:30:53 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Feb 23 23:31:02 2005 Subject: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: References: Message-ID: <378d04a1bec177e47311c82d8f10fb67@redivi.com> On Feb 23, 2005, at 3:28 PM, Just van Rossum wrote: > Michael Hudson wrote: > >> If you want your Python app to work in perpetuity, you'd better bundle >> a version of Python with it because one day OS X will presumably come >> with 2.4 or 2.5. This strikes me as being the same as any other >> platform. > > I would _hope_ they'd still keep 2.3(.X) in there for b/w > compatibility. > That's why there are versioned frameworks to begin with, no? Well you don't see Python 2.2 or Perl 5.6 on Mac OS X 10.3. I think there's a good chance it will be around for 10.4, but beyond that I'm really not sure. -bob From charles.hartman at conncoll.edu Thu Feb 24 04:43:42 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Feb 24 04:43:48 2005 Subject: [Pythonmac-SIG] presenting . . . Message-ID: <29e0036d5dd039c0cc3128be6f1dba47@conncoll.edu> If anybody has a crying need for a program that scans iambic pentameters, see the site below (the Programs page). wxPython on Mac/Win. Ta-da, and all that. It mostly seems to work. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar From rogerb at rogerbinns.com Thu Feb 24 08:36:46 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Thu Feb 24 08:36:43 2005 Subject: Fw: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix Message-ID: <078901c51a43$984e0c70$3501a8c0@rogersqyvr14d3> >> Taking a step back, am I the only person who thinks the Python situation >> on Mac is absolutely ridiculous, although 10.2 looks better than 10.3. > > As Bob says, you obviously haven't used 10.2... Correct. I don't want to disparage the improvements that have been made, but the situation as it stands right now on Mac still seems really bad to me. Compare to Windows: http://www.python.org/2.3.5/ On Windows you just run the installer and all is fine. You can run the installer for as many versions as you want. Most extensions are distributed as installers as well. You just run them, they give you a list of installed compatible versions and where they are installed. You choose and all is fine. Uninstall can be done from the Control Panel Add/Remove Programs menu. The instructions on that page also cover all the other UNIXen which work fine with the tar/configure/make/make install and correctly deal with with having multiple concurrent versions. Mac isn't even mentioned on that page. The tar/configure/make/make install stuff does work. (I can't tell if it enables frameworks by default or not - wxPython requires a framework build, so I enabled it). But when installing extensions such as wxPython that come with a graphical installer (yay!), they don't list the known Pythons on the system. It is so close to being simple and friendly :-) > Don't you remember the days where Redhat came with Python 1.5.2 and if > you upgraded that you broke redhat's tools? Plus ca change, plus > c'est la meme chose. Yup. That hasn't been broken in years. For example on Redhat 9 the relevant Redhat tools use #!/usr/bin/python2.2 If you installed your own Python 2.2 it would end up under /usr/local so this wouldn't clash nor would others unless you installed over the main system one, in which case things will still be fine unless you use different options (eg differently sized unicode characters). > If you want your Python app to work in perpetuity, you'd better bundle > a version of Python with it because one day OS X will presumably come > with 2.4 or 2.5. This strikes me as being the same as any other > platform. I already do bundle the interpretter on Windows and Linux. For Mac the system interpretter isn't bundled (for good reason) by py2app. Others can be, but then there stems issues like getting other packages to install into them (eg wxPython). Roger From mwh at python.net Thu Feb 24 10:19:08 2005 From: mwh at python.net (Michael Hudson) Date: Thu Feb 24 10:19:10 2005 Subject: Fw: [Pythonmac-SIG] Versions, Frameworks, Linking, PantherPythonFix In-Reply-To: <078901c51a43$984e0c70$3501a8c0@rogersqyvr14d3> (Roger Binns's message of "Wed, 23 Feb 2005 23:36:46 -0800") References: <078901c51a43$984e0c70$3501a8c0@rogersqyvr14d3> Message-ID: <2m650itiwj.fsf@starship.python.net> "Roger Binns" writes: >>> Taking a step back, am I the only person who thinks the Python situation >>> on Mac is absolutely ridiculous, although 10.2 looks better than 10.3. >> As Bob says, you obviously haven't used 10.2... > Correct. I don't want to disparage the improvements that have been > made, > but the situation as it stands right now on Mac still seems really > bad to me. You obviously have a different "really bad" threshold than me. > Compare to Windows: > > http://www.python.org/2.3.5/ > > On Windows you just run the installer and all is fine. You can > run the installer for as many versions as you want. Most extensions > are distributed as installers as well. You just run them, they > give you a list of installed compatible versions and where they > are installed. You choose and all is fine. Uninstall can be > done from the Control Panel Add/Remove Programs menu. We are getting to this position on the mac. We ain't there yet. (Or more precisely, Bob is getting use there.) > The instructions on that page also cover all the other UNIXen > which work fine with the tar/configure/make/make install and > correctly deal with with having multiple concurrent versions. Um, it seems to me that barring a small (but oh so annoying) bug in 2.3.0, this isn't different on OS X. Sadly, we can't go back in time and sort this out, all we can do is "do better next time", and we (think we) have. > Mac isn't even mentioned on that page. The tar/configure/make/make > install stuff does work. (I can't tell if it enables frameworks > by default or not It doesn't. > - wxPython requires a framework build, so I enabled it). > > But when installing extensions such as wxPython that come with > a graphical installer (yay!), they don't list the known Pythons > on the system. Hmm. This is something that hadn't occurred to me. I guess the unusuality of OS X is somewhat that you might have two copies of 2.3 installed... Cheers, mwh -- CLiki pages can be edited by anybody at any time. Imagine the most fearsomely comprehensive legal disclaimer you have ever seen, and double it -- http://ww.telent.net/cliki/index From gavhall at mac.com Thu Feb 24 17:31:35 2005 From: gavhall at mac.com (Gavin Hall) Date: Thu Feb 24 17:31:47 2005 Subject: [Pythonmac-SIG] PIL - image.show() problem on 10.2.8 in X11 Message-ID: <8CF9926C-8681-11D9-9994-000393103086@mac.com> Hi guys, Haven't been on this long at all so I can't gauge the standard. Hope I'm not being too much of a newbie. I just wanted to no if anyone has got show() from PIL Image to work assuming that python and PIL and xv have been installed via fink and the script is being run in an X11 terminal window: Traceback (most recent call last): File "proto.py", line 27, in ? img.show() File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 749, in show _showxv(self, title, command) File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 1042, in _showxv file = self._dump(format=format) File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 333, in _dump self.load() File "/sw/lib/python2.2/site-packages/PIL/ImageFile.py", line 117, in load self.map = Image.core.map(self.filename) File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 37, in __getattr__ raise ImportError, "The _imaging C module is not installed" ImportError: The _imaging C module is not installed Haven't a clue what's going on and any help would be appreciated. Thanks, Gav. From bob at redivi.com Thu Feb 24 20:07:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Feb 24 20:08:03 2005 Subject: [Pythonmac-SIG] PIL - image.show() problem on 10.2.8 in X11 In-Reply-To: <8CF9926C-8681-11D9-9994-000393103086@mac.com> References: <8CF9926C-8681-11D9-9994-000393103086@mac.com> Message-ID: <8f7ccda313a068aada57dfae71c7be08@redivi.com> On Feb 24, 2005, at 11:31 AM, Gavin Hall wrote: > Haven't been on this long at all so I can't gauge the standard. Hope > I'm not being too much of a newbie. I just wanted to no if anyone has > got show() from PIL Image to work assuming that python and PIL and xv > have been installed via fink and the script is being run in an X11 > terminal window: > > Traceback (most recent call last): > File "proto.py", line 27, in ? > img.show() > File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 749, in > show > _showxv(self, title, command) > File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 1042, in > _showxv > file = self._dump(format=format) > File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 333, in > _dump > self.load() > File "/sw/lib/python2.2/site-packages/PIL/ImageFile.py", line 117, > in load > self.map = Image.core.map(self.filename) > File "/sw/lib/python2.2/site-packages/PIL/Image.py", line 37, in > __getattr__ > raise ImportError, "The _imaging C module is not installed" > ImportError: The _imaging C module is not installed > > Haven't a clue what's going on and any help would be appreciated. If the _imaging module isn't installed, then Fink didn't actually install PIL correctly. Are you sure Python 2.2 is the right interpreter to be using? Python 2.4 is current.. You'll probably want to take this up with the maintainer for PIL in Fink if you are using the correct interpreter. -bob From cmeesters at ucdavis.edu Fri Feb 25 08:31:35 2005 From: cmeesters at ucdavis.edu (Christian Meesters) Date: Fri Feb 25 08:31:48 2005 Subject: [Pythonmac-SIG] PIL - image.show() problem on 10.2.8 in X11 Message-ID: <200502250731.j1P7VZHW025047@phaenicia.ucdavis.edu> Hi In addition to what Bob said my $.02: show() will call _showxv() if you can't import Tk - which, as I suppose, is the case on most Macs. _showxv() on the other hand will try to open Preview. But for this you'll need to install the 'JPEG dependencies' as well. Then it will go for xv. You can try to fix Image.py yourself, so that show() will ultimately open Preview with your preferred image type. I was busy writing a patch, but didn't finish it, for I'll have, well, other priorities these days. Sorry. Good luck. Cheers, Christian From matsakis at mit.edu Sat Feb 26 20:09:56 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Sat Feb 26 20:09:58 2005 Subject: [Pythonmac-SIG] Banishing MacPython Dock Icon Message-ID: One of the negatives of running appscripts to script apps is that MacPython icon appearing in the dock. Not only is it useless, since you can't interact with the app skeleton with the GUI, but it also slows the launch of scripts. I've managed to banish that icon by editing the Info.plist file of the Resources/Python.app/Contents folder of the Python framework. All I did was add the key LSUIElement with integer value 1, and the icon has been banished and appscript still works. This is great, but am I doing myself any disservice by doing that? What is that app used for, besides appscript? By the way, what is the history of that icon? Why is it a 16 ton weight? Is there a chance it could look less ... classic ... in a future version of Mac Python? Nick Matsakis From bob at redivi.com Sat Feb 26 20:25:28 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 26 20:25:34 2005 Subject: [Pythonmac-SIG] Banishing MacPython Dock Icon In-Reply-To: References: Message-ID: On Feb 26, 2005, at 2:09 PM, Nick Matsakis wrote: > One of the negatives of running appscripts to script apps is that > MacPython icon appearing in the dock. Not only is it useless, since > you > can't interact with the app skeleton with the GUI, but it also slows > the > launch of scripts. It's only useless if the script you're running doesn't use it.. > I've managed to banish that icon by editing the Info.plist file of the > Resources/Python.app/Contents folder of the Python framework. All I > did > was add the key LSUIElement with integer value 1, and the icon has been > banished and appscript still works. This is great, but am I doing > myself > any disservice by doing that? What is that app used for, besides > appscript? It's definitely a disservice. It is used any time that pythonw is used. If you set LSUIElement to 1, then you can't run applications with a menu bar from pythonw. wxPython, pygame, Tkinter, Carbon, etc. scripts should all have a problem with this. If you want a faceless background application, run py2app over the script and set the LSUIElement key to 1 in that. > By the way, what is the history of that icon? Why is it a 16 ton > weight? > Is there a chance it could look less ... classic ... in a future > version > of Mac Python? The weight as a reference to Monty Python. I had a friend of mine do a more modern icon, but it was too snake-like for some people on the list: (I have a higher resolution version, but I'd have to dig it up). -bob From just at letterror.com Sat Feb 26 21:47:08 2005 From: just at letterror.com (Just van Rossum) Date: Sat Feb 26 21:47:17 2005 Subject: [Pythonmac-SIG] SciPy installer for Panther Python, anyone? Message-ID: I'd like to quickly evaluate SciPy for a project, but I can't seem to find a binary distribution for 10.3's Python anywhere. Am I not looking hard enough? Tried to build from the source but the amount of dependencies for building it makes this not a viable option right now. Just From bob at redivi.com Sat Feb 26 21:59:54 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Feb 26 22:00:35 2005 Subject: [Pythonmac-SIG] SciPy installer for Panther Python, anyone? In-Reply-To: References: Message-ID: On Feb 26, 2005, at 3:47 PM, Just van Rossum wrote: > I'd like to quickly evaluate SciPy for a project, but I can't seem to > find a binary distribution for 10.3's Python anywhere. Am I not looking > hard enough? Tried to build from the source but the amount of > dependencies for building it makes this not a viable option right now. Not available. I think you can play with it from darwinports or fink, otherwise, you'll have to build it yourself or wait for MacEnthon to be released . -bob From matsakis at mit.edu Sun Feb 27 01:40:46 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Sun Feb 27 01:40:49 2005 Subject: [Pythonmac-SIG] Banishing MacPython Dock Icon In-Reply-To: References: Message-ID: On Sat, 26 Feb 2005, Bob Ippolito wrote: > It's definitely a disservice. It is used any time that pythonw is > used. If you set LSUIElement to 1, then you can't run applications > with a menu bar from pythonw. wxPython, pygame, Tkinter, Carbon, etc. > scripts should all have a problem with this. Well, I don't run any such scripts. Maybe there be a pythonfl, that runs as a faceless app. > If you want a faceless background application, run py2app over the > script and set the LSUIElement key to 1 in that. It seems to me that it should be the opposite. If you want a script that behaves like an app, you should bundle it as an app. If you just want a script that runs in the background, then it shouldn't need to be bundled up at all (this is generally how mac applications and unix processes work). Ultimately, I think Apple should provide an API for a faceless app to request a "face" when it wants to interact with the user. As it is, all this is fixed at the point the process is started. > The weight as a reference to Monty Python. I had a friend of mine do a > more modern icon, but it was too snake-like for some people on the > list Apple may also have a problem with someone using their logo. Why not just use the generic application icon? Branding? Nick From timothy.grant at gmail.com Sun Feb 27 08:18:23 2005 From: timothy.grant at gmail.com (Timothy Grant) Date: Sun Feb 27 08:18:29 2005 Subject: [Pythonmac-SIG] bus error using PyQt Message-ID: I"m using PyQt on OSX 10.3.8. and everytime my app exits I get a bus error. I've noticed several people have seen the error, but have not yet run into a solution I understood. Can anyone explain how to resolve the issue to an OSX newbie? Thank you. -- Stand Fast, tjg. From sw at wordtech-software.com Sun Feb 27 14:03:35 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Feb 27 14:03:39 2005 Subject: [Pythonmac-SIG] Re: PyQt bus error In-Reply-To: <20050227110005.23B6A1E400F@bag.python.org> References: <20050227110005.23B6A1E400F@bag.python.org> Message-ID: <4221C527.4010403@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can you be more specific? Is this a problem in that your application crashes and you lose data, or just that it's not a very graceful shutdown? PyQt on the Mac is a bit buuggy, even with my binary distribution. Because it's such a monster to build, I haven't kept up with more recent updates to PyQt either: I'm waiting for the release of Qt 4 to put together another version. Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCIcUmJmdQs+6YVcoRArj9AJ4z9PEnLodFu7/9x/6f+JgH+NdpqgCePrWm RDffgD6QvoODJnoVo+y/k14= =za4T -----END PGP SIGNATURE----- From jim.correia at gmail.com Sun Feb 27 19:06:25 2005 From: jim.correia at gmail.com (Jim Correia) Date: Sun Feb 27 19:06:27 2005 Subject: [Pythonmac-SIG] Python 2.4 test_locale fails? Message-ID: <1a4ecae20502271006c52c5c1@mail.gmail.com> (New to the list, couldn't find the answer in the archives...) I'm just getting around to building and installing Python 2.4 on 10.3.8. After building and running the tests, test_locale fails. (If I tweak the test to not abort after the first failure I see that it fails for the decimal_point and thousands_sep for most locales.) Is the test faulty? Is here a bug in Python 2.4? In the 10.3.8 locale support? The output from the test is below. Thanks, Jim ./python.exe ./Lib/test/test__locale.py test_lc_numeric (__main__._LocaleTests) ... FAIL ====================================================================== FAIL: test_lc_numeric (__main__._LocaleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/test/test__locale.py", line 45, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR ---------------------------------------------------------------------- Ran 1 test in 0.015s From matsakis at mit.edu Sun Feb 27 20:21:56 2005 From: matsakis at mit.edu (Nick Matsakis) Date: Sun Feb 27 20:21:58 2005 Subject: [Pythonmac-SIG] Address Book Bindings? Message-ID: Does anyone know if anyone has written python bindings for the Mac Addressbook API? I would expect it wouldn't be too difficult for anyone who knows how to do this, since they provide a simple C API. (I've never written anything but pure Python). http://developer.apple.com/documentation/UserExperience/Reference/AddressBook-date.html Nick From bac at OCF.Berkeley.EDU Sun Feb 27 21:30:19 2005 From: bac at OCF.Berkeley.EDU (Brett C.) Date: Sun Feb 27 21:30:28 2005 Subject: [Pythonmac-SIG] Python 2.4 test_locale fails? In-Reply-To: <1a4ecae20502271006c52c5c1@mail.gmail.com> References: <1a4ecae20502271006c52c5c1@mail.gmail.com> Message-ID: <42222DDB.3090504@ocf.berkeley.edu> Jim Correia wrote: > (New to the list, couldn't find the answer in the archives...) > > I'm just getting around to building and installing Python 2.4 on > 10.3.8. After building and running the tests, test_locale fails. (If I > tweak the test to not abort after the first failure I see that it > fails for the decimal_point and thousands_sep for most locales.) > > Is the test faulty? Is here a bug in Python 2.4? In the 10.3.8 locale support? > The bug is in Panther. If you link anything against CoreFoundation it locks out changing the locale through locale.h in C which is what Python uses. While this could be partially fixed by putting a bunch of CF code to use the locale API through that, it was generally agreed that with Tiger about to come out it would be best to wait to see what the situation is then and fix accordingly. -Brett From bob at redivi.com Sun Feb 27 21:58:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Feb 27 21:59:02 2005 Subject: [Pythonmac-SIG] Address Book Bindings? In-Reply-To: References: Message-ID: <1104efd4833580f54d315cedbc95a5c0@redivi.com> On Feb 27, 2005, at 14:21, Nick Matsakis wrote: > > Does anyone know if anyone has written python bindings for the Mac > Addressbook API? I would expect it wouldn't be too difficult for > anyone > who knows how to do this, since they provide a simple C API. (I've > never > written anything but pure Python). > > http://developer.apple.com/documentation/UserExperience/Reference/ > AddressBook-date.html PyObjC has them. -bob From peter.maxwell at anu.edu.au Mon Feb 28 05:22:51 2005 From: peter.maxwell at anu.edu.au (Peter Maxwell) Date: Mon Feb 28 10:47:45 2005 Subject: [Pythonmac-SIG] SciPy installer for Panther Python, anyone? Message-ID: <3ffe82d70ed822b6fef50c4b8eb27faa@anu.edu.au> No guarantees, but my latest attempt to compile SciPy seems to have worked: http://cbis.anu.edu.au/misc/SciPy_complete-0.3.2.mpkg.zip -- Peter Maxwell From just at letterror.com Mon Feb 28 10:56:48 2005 From: just at letterror.com (Just van Rossum) Date: Mon Feb 28 10:57:03 2005 Subject: [Pythonmac-SIG] SciPy installer for Panther Python, anyone? In-Reply-To: <3ffe82d70ed822b6fef50c4b8eb27faa@anu.edu.au> Message-ID: Peter Maxwell wrote: > No guarantees, but my latest attempt to compile SciPy seems to have > worked: > > http://cbis.anu.edu.au/misc/SciPy_complete-0.3.2.mpkg.zip Thanks. In the meantime, it turned out my problem was trivially solvable through Numeric, so I can skip SciPy for now. But it's great you made this available, I'm sure there are many others who like to work with / play with SciPy but simply couldn't, before. Just (additional hints for google: OSX, 10.3, MacOSX, binary installer, distribution) From Jack.Jansen at cwi.nl Mon Feb 28 11:53:44 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Feb 28 11:54:40 2005 Subject: [Pythonmac-SIG] Qualcomm Purevoice codec In-Reply-To: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> References: <031601c518af$9aa7d180$3501a8c0@rogersqyvr14d3> Message-ID: <43420c810c20ebbfd65369f2bda69027@cwi.nl> On 22 Feb 2005, at 08:24, Roger Binns wrote: > Can anyone give me hints on how to access the Qualcomm Purevoice codec > that is part of Quicktime from Python? > > In BitPim we convert between wav and Purevoice using the convertor > that Qualcomm provides: > > http://www.cdmatech.com/solutions/products/purevoice_download.jsp > > Note that they don't supply it for MacOS X. There is however a > codec inside Quicktime. Ideally I want as close functionality > as possible as their Windows and Linux binaries. > [...] > I couldn't find anything relevant using Google. There is a > Carbon.QT module but none of the methods appear to do any form of > conversion. The quicktime module for Python 2.4 has a lot of new functionality (and it's also available as an addon for Python 2.3, through my experimental database for Package Manager). Access to codecs is one of the things that has been added. But, of course, I've only tested it very lightly and it's very possible I forgot some essential things. Could you please check whether Python 2.4 (or its Carbon.Qt module used in 2.3) allows you to access the codec you need? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From hengist.podd at virgin.net Mon Feb 28 19:41:47 2005 From: hengist.podd at virgin.net (has) Date: Mon Feb 28 19:42:00 2005 Subject: [Pythonmac-SIG] CFURL Pain Message-ID: Hi folks, I'm not really up on these APIs nor their Python wrappers, but I suspect this stuff is broke: First try: import Carbon.CF as CF f = CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/has/', True) print f # print `f.CFURLGetString().toPython()` # u'./file://localhost/Users/has' (Where did './' come from?) print f.toPython() # MacOS.Error: (-192, 'Resource not found') print f.CFURLGetFSRef() # crashes print f.CFURLGetFSRef()[1].as_pathname() # MacOS.Error: (-35, 'no such volume') Second try: import Carbon.CF as CF f = CF.toCF('file://localhost/Users/has/').CFURLCreateWithString(None) print f # print `f.CFURLGetString().toPython()` # u'file://localhost/Users/has/' print f.toPython() # MacOS.Error: (-192, 'Resource not found') print f.CFURLGetFSRef() # crashes print f.CFURLGetFSRef()[1].as_pathname() # crashes Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3) has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Feb 28 19:56:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 28 19:56:22 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: Message-ID: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> On Feb 28, 2005, at 1:41 PM, has wrote: > I'm not really up on these APIs nor their Python wrappers, but I > suspect this stuff is broke: > > First try: > > import Carbon.CF as CF > f = > CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/ > has/', True) > print f # > print `f.CFURLGetString().toPython()` # > u'./file://localhost/Users/has' (Where did './' come from?) > print f.toPython() # MacOS.Error: (-192, 'Resource not found') > print f.CFURLGetFSRef() # crashes > print f.CFURLGetFSRef()[1].as_pathname() # MacOS.Error: (-35, 'no such > volume') > > Second try: > > import Carbon.CF as CF > f = CF.toCF('file://localhost/Users/has/').CFURLCreateWithString(None) > print f # > print `f.CFURLGetString().toPython()` # u'file://localhost/Users/has/' > print f.toPython() # MacOS.Error: (-192, 'Resource not found') > print f.CFURLGetFSRef() # crashes > print f.CFURLGetFSRef()[1].as_pathname() # crashes > > > Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3) I wouldn't be surprised if it's broken, use PyObjC and NSURL instead, those work. Why haven't you upgraded to 2.3.5 (not that I think it would help)? -bob From hengist.podd at virgin.net Mon Feb 28 21:41:09 2005 From: hengist.podd at virgin.net (has) Date: Mon Feb 28 21:41:25 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> Message-ID: Bob wrote: >>I'm not really up on these APIs nor their Python wrappers, but I >>suspect this stuff is broke: >>[...] >>Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3) > >I wouldn't be surprised if it's broken, Mmmm... encouraging. (Hey: if bgen is so great, why won't it generate some damn test suites to prove it?;p) >use PyObjC and NSURL instead, those work. Introduces a big fat third-party dependency though, something I'm trying to avoid here. >Why haven't you upgraded to 2.3.5 (not that I think it would help)? I'm sure it's on my ToDo list somewhere . has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Feb 28 21:46:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Feb 28 21:46:56 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: <2d51fb5efb9c7a3c0c85a3e375a50d34@redivi.com> Message-ID: On Feb 28, 2005, at 3:41 PM, has wrote: > Bob wrote: > >>> I'm not really up on these APIs nor their Python wrappers, but I >>> suspect this stuff is broke: >>> [...] >>> Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3) >> >> I wouldn't be surprised if it's broken, > > Mmmm... encouraging. > > (Hey: if bgen is so great, why won't it generate some damn test suites > to prove it?;p) Well I can verify that there definitely are serious problems with CFURL after screwing around with it a bit. I don't have time to chase bugs, though. >> use PyObjC and NSURL instead, those work. > > Introduces a big fat third-party dependency though, something I'm > trying to avoid here. Too bad :) If you're writing Mac OS X specific code you **really** should have PyObjC anyway. -bob From njriley at uiuc.edu Mon Feb 28 22:40:42 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon Feb 28 22:40:45 2005 Subject: [Pythonmac-SIG] CFURL Pain In-Reply-To: References: Message-ID: <20050228214042.GA54158@uiuc.edu> On Mon, Feb 28, 2005 at 06:41:47PM +0000, has wrote: > import Carbon.CF as CF > f = > CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/has/', > True) That's not a filesystem representation (code for "UTF-8 encoded path"). > u'./file://localhost/Users/has' (Where did './' come from?) > print f.toPython() # MacOS.Error: (-192, 'Resource not found') > print f.CFURLGetFSRef() # crashes > print f.CFURLGetFSRef()[1].as_pathname() # MacOS.Error: (-35, 'no such > volume') When CF stuff crashes, you can often get more information by using the debug version of frameworks: % DYLD_IMAGE_SUFFIX="_debug" ipython 2005-02-28 15:34:18.928 python[16198] CFLog (0): Assertions enabled In [1]: import Carbon.CF as CF In [2]: f = CF.CFURLCreateFromFileSystemRepresentation('/Users/nicholas', True) In [3]: f.CFURLGetString().toPython() 2005-02-28 15:34:29.168 python[16198] CFLog (15): CFStringGetCharacters(): string range 0,32 out of bounds (length 31) Out[3]: u'file://localhost/Users/nicholas' In [4]: f.CFURLGetFSRef() zsh: 16198 bus error DYLD_IMAGE_SUFFIX="_debug" ipython [...] In [3]: f.CFURLGetFSRef()[1].as_pathname() DebugAssert: Third Party Client: err == 0 [-43] FSPathMakeRef_GetObjectInfoFailed [line 1670, file Files/HighLevelCalls.c] DebugAssert: Third Party Client: volume != NULL FSMakePath_VolNotFound [line 848, file Files/FilePathUtils.c] DebugAssert: Third Party Client: (tempMapOffset <= (fileLength - kNullMapLength)) exit CheckMapHeaderCommon(), Resource Manager: EOF truncates resource map.[line 195, file Resources/Source/ResourceUtils.c] --------------------------------------------------------------------------- Error Traceback (most recent call last) /Users/nicholas/ Error: (-35, 'no such volume') In [4]: f.CFURLGetFSRef()[1] DebugAssert: Third Party Client: err == 0 [-43] FSPathMakeRef_GetObjectInfoFailed [line 1670, file Files/HighLevelCalls.c] Out[4]: In [5]: f = CF.CFURLCreateFromFileSystemRepresentation('/Users/nicholas/', True) In [6]: f.CFURLGetFSRef()[1].as_pathname() Out[6]: '/Users/nicholas' It's hard to say if the crash is Python's fault or CF's fault, but there's definitely a wrapper bug in there. And it looks like you need the trailing slash; didn't bother to check if that is by design or not. -- Nicholas Riley | From jim.correia at gmail.com Mon Feb 28 23:32:57 2005 From: jim.correia at gmail.com (Jim Correia) Date: Mon Feb 28 23:33:01 2005 Subject: [Pythonmac-SIG] Python 2.4 test_locale fails? In-Reply-To: <42222DDB.3090504@ocf.berkeley.edu> References: <1a4ecae20502271006c52c5c1@mail.gmail.com> <42222DDB.3090504@ocf.berkeley.edu> Message-ID: <1a4ecae205022814326052c18e@mail.gmail.com> On Sun, 27 Feb 2005 12:30:19 -0800, Brett C. wrote: > The bug is in Panther. If you link anything against CoreFoundation it locks > out changing the locale through locale.h in C which is what Python uses. That's odd, but I can reproduce it with a short C program as you describe. Thanks for the explanation. I'll sit tight and see what Tiger brings to the table. Meanwhile this is hardly a showstopper for me putting 2.4 into use for my purposes. Thanks, Jim