From hengist.podd at virgin.net Fri Apr 1 02:37:41 2005 From: hengist.podd at virgin.net (has) Date: Fri Apr 1 02:37:50 2005 Subject: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning? Message-ID: Paul Berkowitz wrote: > > Personally I don't think the language difference should be too much > > of an issue when asking application-related questions, > >I think it might be an issue. Didn't say there wouldn't be any issue at all; of course there'll be a degree of mismatch any time someone posts an appscript/AppleScript code sample. I assume there will be sufficiently enlightened folk around who won't let the unfamiliar accent get in the way of trying to be helpful to one another. And some questions will go to the wrong forum: application-specific questions to here, appscript-related questions to there. One of the reasons I recommend MacScrpt is that there's at least one person reading it daily who can pick up any of the latter. >Python users who know appscript but not >AppleScript will tend to ask questions about application scripting in a way >that AppleScripters who don't know Python won't understand. The fact that most ASers don't know Python isn't an issue. The fact that most are borderline computer literate at best is a bit of a pest, since it means they won't be very good at recognising the common underlying concepts. Appscript users will need to take a degree of care in how they phrase application-specific questions. But what's new? As an example, the OP's question breaks down into two parts: how does appscript work, and how does Quark work. Assume that an appscript expert will answer the former, and rephrase bits of the latter so that Quark experts will be more able to take a shot at it. Better appscript documentation should ensure appscript users understand how the bridging technology works, allowing them to better separate application-specific questions from appscript-related ones before asking them. Learning how to ask questions clearly and precisely is something everyone has to learn. It's not like there's any shortage of vague, confused and downright undecipherable questions already being asked on AS lists. >(Somehow I don't see Shane Stanley answering too many appscript questions >about Quark.) Who knows? Hopefully he'll answer Quark questions about Quark. Hopefully if someone asks a Quark question that's all muddled with an appscript question he'll ask for the question to be rephrased so it's easier to understand. And maybe someday he'll decide that knowing a bit about Python+appscript will be useful in its own right, and will then be able to answer appscript-specific questions too (when he feels like it). Python's a much better development tool than AppleScript, after all, and as a shrewd professional workflow developer he ought to recognise the commercial benefits of it. >That will keep you quite busy. If I, or other AppleScripters, >ever manage to get around to learning Python properly and then appscript, we >might be able to pitch in. You don't need to be an expert in Python to answer questions about application scripting. Understanding the fundamental principles by which something operates is way more valuable, since that knowledge is transferrable with little effort. Literals, variables, conditionals, commands, references, etc. are all common to both AS and Python and should be recognisable even without knowing the language itself. I mean, seriously, any moderately competent AppleScripter who understands what these things actually are and still can't figure out that: app('TextEdit').documents[1].text.get() is equivalent to: tell app "TextEdit" to get text of document 1 in their native tongue really isn't trying. Ditto the reverse. Nobody's expecting an ASer to write a fluent Python solution in response to a question by a Python user. Nor do they need to: a fluent AppleScript solution will do just fine. Writing code may be hard but _reading_ code is a piece of piss. And all that anyone needs to do is read code just well enough to infer its meaning, something both languages make pretty easy. Furthermore, the more that folk ask and answer questions on-list, the better they'll become at doing it. I don't expect the first burst of communication to be instant and flawless; it's a learning process and is going to take a bit of time and a bit of work by all parties. >But even the very limited documentation that >application creators provide for their AppleScript implementations will not >be extended to appscript, or even to raw AppleEvent documentation (I think >FMP may provide a bit of that.) It will mostly be up to you. I won't be answering technical questions on QXP, ID, FMP, Entourage, etc. myself because I'm not an expert in scripting any of them. I will be around to ride shotgun on them, filtering the appscript issues from the application issues where necessary (and I hope other appscript veterans will feel free to chip in here too;). I think you're overanalysing; worrying too much. AppleScripters may not always have a clue what they're talking about and be a bit prone to the Not Invented Heres, but on the whole they're a decent enthusiastic bunch of folk who genuinely want to help others and are willing to work at it. Main thing now is for application scripting questions to move off here and onto MacScrpt so we can at least get started on making this happen (I think we'll all agree that PythonMac isn't the most useful or appropriate place for discussing this stuff). Once there, we can knock out any kinks as we go. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From lee_cullens at mac.com Fri Apr 1 06:32:43 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Fri Apr 1 06:32:48 2005 Subject: [Pythonmac-SIG] RE: Localized project folder and .pth? Message-ID: <88e86ec2f04e3454c2be86e4dbe14a8a@mac.com> OS X 10.3.8 with the Mac Python add ons (and new to both Mac and Python) To keep a learning project together I'm creating my module files in a folder within my account. Not using any fancy IDE yet I brought up PythonIDE and (of course) the first import of one of my modules failed. Having read about a .pth file I created a one liner with a full path to my learning project folder and then looked around for where to put it. I noticed other .pth files in /Library/Python/2.3 so I put it there and now the imports of my modules work. The point here is though this worked, is this the correct (normally accepted) way to do such. That is, keeping a project's "unique" modules in an isolated folder (or folder structure), creating a .pth file to such and placing that file in /Library/Python/2.3? If someone has already elaborated on this subject then please just point me at the piece. I don't want to develop any "bad" practices that at best annoy others and at worst come back to bite me :~) Thanks, Lee C From bob at redivi.com Fri Apr 1 06:42:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 1 06:42:19 2005 Subject: [Pythonmac-SIG] RE: Localized project folder and .pth? In-Reply-To: <88e86ec2f04e3454c2be86e4dbe14a8a@mac.com> References: <88e86ec2f04e3454c2be86e4dbe14a8a@mac.com> Message-ID: <0501e800334d08e7c380d1d4ba8accda@redivi.com> On Mar 31, 2005, at 11:32 PM, Lee Cullens wrote: > OS X 10.3.8 with the Mac Python add ons (and new to both Mac and > Python) > > To keep a learning project together I'm creating my module files in a > folder within my account. Not using any fancy IDE yet I brought up > PythonIDE and (of course) the first import of one of my modules > failed. Having read about a .pth file I created a one liner with a > full path to my learning project folder and then looked around for > where to put it. I noticed other .pth files in /Library/Python/2.3 so > I put it there and now the imports of my modules work. > > The point here is though this worked, is this the correct (normally > accepted) way to do such. That is, keeping a project's "unique" > modules in an isolated folder (or folder structure), creating a .pth > file to such and placing that file in /Library/Python/2.3? Yes it's a perfectly good way to do it. I would go as far as saying the best way of doing it, especially on Mac OS X. If you want to localize this to your specific account, ~/Library/Python/2.3/site-packages is also a respected location for doing it (you will probably need to create this folder). When using the Python 2.4.1 build I would use ~/Library/Python/2.4/site-packages -- the normal site-packages path is deep within the framework. The tilde (~) means your home directory, if you're not familiar with the unix terminology. Also note that Finder's cmd-shift-G "Go to folder..." dialog also knows about tilde. > If someone has already elaborated on this subject then please just > point me at the piece. http://bob.pythonmac.org/archives/2005/02/06/using-pth-files-for- python-development/ If you poke around elsewhere on my blog, and on http://pythonmac.org/wiki/ (particularly the FAQ) you should find some interesting stuff... -bob From lee_cullens at mac.com Fri Apr 1 07:44:15 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Fri Apr 1 07:44:21 2005 Subject: [Pythonmac-SIG] RE: Localized project folder and .pth? In-Reply-To: <0501e800334d08e7c380d1d4ba8accda@redivi.com> References: <88e86ec2f04e3454c2be86e4dbe14a8a@mac.com> <0501e800334d08e7c380d1d4ba8accda@redivi.com> Message-ID: <3755a2be883992485de9baa70e38fa92@mac.com> Wow - great Bob. If I had looked there first I would not have bothered anyone, and since there are also answers to questions I haven't asked yet I'll go there first for Mac related Python issues. Especially when I embark on your new 2.4 download :~) Thanks again, Lee C PS: One point I didn't notice in my first quick pass through relates to your recently mentioning not to use Package Manager anymore. I checked out (and bookmarked) the newer package list you posted but there is one thing I miss. Being a foggy headed old man (with post-its all over) I liked how the package manager told me if I had something installed. Is the only work around to search with finder and check the version in get info? If you had already answered this question also, then just ignore me and I'll know to dig deeper. On Mar 31, 2005, at 11:42 PM, Bob Ippolito wrote: > > On Mar 31, 2005, at 11:32 PM, Lee Cullens wrote: > >> OS X 10.3.8 with the Mac Python add ons (and new to both Mac and >> Python) >> >> To keep a learning project together I'm creating my module files in a >> folder within my account. Not using any fancy IDE yet I brought up >> PythonIDE and (of course) the first import of one of my modules >> failed. Having read about a .pth file I created a one liner with a >> full path to my learning project folder and then looked around for >> where to put it. I noticed other .pth files in /Library/Python/2.3 >> so I put it there and now the imports of my modules work. >> >> The point here is though this worked, is this the correct (normally >> accepted) way to do such. That is, keeping a project's "unique" >> modules in an isolated folder (or folder structure), creating a .pth >> file to such and placing that file in /Library/Python/2.3? > > Yes it's a perfectly good way to do it. I would go as far as saying > the best way of doing it, especially on Mac OS X. > > If you want to localize this to your specific account, > ~/Library/Python/2.3/site-packages is also a respected location for > doing it (you will probably need to create this folder). When using > the Python 2.4.1 build I would use ~/Library/Python/2.4/site-packages > -- the normal site-packages path is deep within the framework. > > The tilde (~) means your home directory, if you're not familiar with > the unix terminology. Also note that Finder's cmd-shift-G "Go to > folder..." dialog also knows about tilde. > >> If someone has already elaborated on this subject then please just >> point me at the piece. > > http://bob.pythonmac.org/archives/2005/02/06/using-pth-files-for- > python-development/ > > If you poke around elsewhere on my blog, and on > http://pythonmac.org/wiki/ (particularly the FAQ) you should find some > interesting stuff... > > -bob > From bob at redivi.com Fri Apr 1 08:00:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 1 08:00:36 2005 Subject: [Pythonmac-SIG] RE: Localized project folder and .pth? In-Reply-To: <3755a2be883992485de9baa70e38fa92@mac.com> References: <88e86ec2f04e3454c2be86e4dbe14a8a@mac.com> <0501e800334d08e7c380d1d4ba8accda@redivi.com> <3755a2be883992485de9baa70e38fa92@mac.com> Message-ID: <6db1d18a5c828e396e594e373a56cb98@redivi.com> On Apr 1, 2005, at 12:44 AM, Lee Cullens wrote: > PS: One point I didn't notice in my first quick pass through relates > to your recently mentioning not to use Package Manager anymore. I > checked out (and bookmarked) the newer package list you posted but > there is one thing I miss. Being a foggy headed old man (with > post-its all over) I liked how the package manager told me if I had > something installed. Is the only work around to search with finder > and check the version in get info? Not yet, it's currently in the extreme KISS (keep it simple, stupid) phase and has no supporting tools (beyond the tools to build the packages). Either look in your site-packages folder, or peruse /Library/Receipts/. There probably are existing tools, not specific to Python, that allow you to browse the package receipts in a nice way. That feature is one of the reasons that PackageManager sucks. That check runs arbitrary Python code in-process, which can cause crashes (at start!), instability, and the check only works once (if you upgrade something, you must restart PackageManager to clear the stale stuff from sys.modules). -bob From thestation at swfla.rr.com Fri Apr 1 08:19:35 2005 From: thestation at swfla.rr.com (me) Date: Fri Apr 1 08:19:40 2005 Subject: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning? Message-ID: > I think your problem is to coerce the Quark data to something like > string or real. > The data type of quarks page width is horizontal measurement. > Only Quark Xpress can handle this data type. > You must coerce the data. I don't knoe how to do it in Pythons > AppScript > but her you have the code in AppleScript: > > tell application "QuarkXPress" > tell document 1 > > -- 1. Example ---- > set pw to page width > return pw > -- "210?mm" > return class of pw > -- horizontal measurement > > -- 2. Example ---- > set pw to page width as real > return pw > -- 210.0 > return class of pw > -- real My original AppleScript code uses the more generic coercion set pw to (page width as number) And should return the value in your preferred measurement system (the choice you set in Xpress Measurement preferences). I suspect Xpress holds all its values in an independent namespace. You are able to change Quark's measurement preference at whim, and every dialog changes (almost) instantly to the new units. You are able to type any measurement units into any dialog box, width: 32mm height: 4.3in length: 5p6 Xpress will accept them and convert the result to your preferred units. You can even type mixed unit calculations into dialog boxes 319mm + 3" and the result will be in your preferred units. But I haven't a clue where to find Quark's coercion method, or the keyword for number. Any other suggestions for converting this AppleScript coercion into python? tell application "QuarkXpress" tell document 1 set pw to (page width as number) pw.get(astype=k.Char) ## it doesn't like 'astype' or 'k.Char' pw.get(type=appscript.k.inch_units) Unfortunately, using one of Quark's classes simply returns another <_AE.AEDesc object> The trick of passing a coercion was a complete surprise. That idea isn't really obvious from the very nice documentation for appscript. Possibly it's just my poor comprehension? Where did you obtain the 'astype' parameter? I pulled 'type' out of my ass. I am still hoping to spawn a more fruitful discussion of how to explore an app's interface using appscript. But if we're complaining about having to be pre-cognizant of the most minute detail for an App's implementation of AppleScript before being able to do anything with it; I'd like to point out that being omniscient is a standard requirement for writing IN AppleScript. To do the most simple thing, you must bang your head against the wall until you hit upon the secret. Either by chance or by reading other people's discoveries. You're never, ever privy to the source. Don't even try to ask. That's why everyone loves AppleScript ;p You have to think very, very different. I am honestly amazed appscript works at all. From lee_cullens at mac.com Fri Apr 1 08:20:29 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Fri Apr 1 08:20:37 2005 Subject: [Pythonmac-SIG] RE: Localized project folder and .pth? In-Reply-To: <6db1d18a5c828e396e594e373a56cb98@redivi.com> References: <88e86ec2f04e3454c2be86e4dbe14a8a@mac.com> <0501e800334d08e7c380d1d4ba8accda@redivi.com> <3755a2be883992485de9baa70e38fa92@mac.com> <6db1d18a5c828e396e594e373a56cb98@redivi.com> Message-ID: Thanks yet again Bob. From hengist.podd at virgin.net Fri Apr 1 16:23:02 2005 From: hengist.podd at virgin.net (has) Date: Fri Apr 1 16:23:28 2005 Subject: [Pythonmac-SIG] Re: Re: appscript and XXXX - what is my app instance returning? Message-ID: 'me' wrote: >>tell application "QuarkXPress" >> tell document 1 >> set pw to page width as real pw = app('QuarkXPress').documents[1].page_width.get(astype=k.Float) >But I haven't a clue where to find Quark's coercion method, You pass the type you want the result returned as as an optional argument to the command. It's the same for any app, e.g.: from appscript import * print app('Finder').home.items.get(astype=k.alias_list) # return a list of Carbon.File.Aliases Of course, working out what coercions an application implements can be a barrel of laughs as it's one of those items that's often not documented by the developer. >or the keyword for number. AE type constants are in Carbon/AppleEvents.py. Appscript scrapes the constant names and lops off the 'type' so that e.g. typeChar becomes k.Char, typeFloat becomes k.Float, etc. A better system is definitely needed, but I haven't figured one out yet. >Any other suggestions for converting this AppleScript coercion into python? > tell application "QuarkXpress" > tell document 1 > set pw to (page width as number) > >pw.get(astype=k.Char) ## it doesn't like 'astype' or 'k.Char' The 'astype' argument should work ok. The problem is figuring out what value to supply; you'll get a coercion error otherwise. Try k.Float (what AS calls 'real'). >pw.get(type=appscript.k.inch_units) >Unfortunately, using one of Quark's classes simply returns >another <_AE.AEDesc object> The 'type' keyword argument isn't recognised, so is simply ignored. (I should really go back to raising an error on unknown argument names.) >The trick of passing a coercion was a complete surprise. It's what AS does, except AS obfuscates it to look like it's the language doing the coercion, not the application. AS is master of leaky abstractions. >That idea isn't really obvious from the very nice documentation for appscript. That's because I somehow forgot to document it. Apologies; I've added it to my TO DO list. >I am still hoping to spawn a more fruitful discussion of how to >explore an app's interface using appscript. What do you need to know? The built-in help() system is good for interactive exploration. Of course, since it depends on the application's terminology resource it can't show you any information not already supplied there; all it does is present what is available in a more helpful fashion. The appscript documentation still lacks a section on the basic concepts and principles behind application scripting which is a problem if you don't already know what you're looking at; obviously this will be addressed at some point. >But if we're complaining about having to be pre-cognizant of the >most minute detail >for an App's implementation of AppleScript before being able to do >anything with it; >I'd like to point out that being omniscient is a standard >requirement for writing IN AppleScript. Yep. Appscript is NOT a magic fix for the problems caused by individual applications' weird or broken scripting implementations and painfully inadequate documentation; the only solution for that is for individual users to petition those applications' developers to fix these problems. File bug reports, file feature requests, have all your fellow users get onto them too. The one thing appscript does give you is a decent language to write your scripts in. The AppleScript language, while it has some nice features and [largely unrealised] ideas, is mostly a piece of crud: slow, buggy, woefully short on the sorts of basic functionality you'd expect from any half-decent scripting language, and virtually zero library support. (Not the fault of the AS developers; blame the clueless suits in Apple management for suddenly choking off its life support two minutes after it was born and neglecting it ever since.) >To do the most simple thing, you must bang your head against the >wall until you hit upon the secret. Either by chance or by reading >other people's discoveries. You're never, ever privy to the source. >Don't even try to ask. The first really useful thing to learn in AppleScript is how to distinguish application-related problems from language-related problems. At least with appscript you only have the application-related problems to deal with (well, once it's finished, anyway; for now there's still some appscript-related issues to knock out, which is why threads like this are always very helpful for me too). And once you know a problem is application related, you'll know exactly whose balls to go bust until it gets fixed. :) No doubt starting with lots of very insistent requests for radically improved documentation. >I am honestly amazed appscript works at all. I'm not. The underlying technology - Apple events - is really quite sound, if not quite of the comfort levels we're used to seeing in these days of XML-RPC, SOAP, etc. (Remember, OS 7 was designed to run on 30MHz machines with a couple MB of RAM.) Probably the biggest problem is that the original APIs for resolving Apple events and object specifiers are pretty hairy, much harder to master than the equivalent APIs for assembing GUI interfaces, so designing and implementing scripting interfaces was really tough for application developers to do well. Plus you've got good old early-90s Apple slinging all this wonderful powerful complex technology out the door and then not bothering to explain to anyone how to actually use it. Cocoa Scripting was created to address the former problem (though CS still has lots of problems of its own), and Apple are ever-so-slowly starting to move on the latter (but still have a very long way to go). And hopefully application developers will start providing better documentation and implementations, especially if/when appscript and its ilk start drawing in sizeable numbers of tech-savvy and very demanding new users for this technology, cos there's nothing like a big vocal userbase banging at the door to motivate developers to do better. ;) Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From jdhunter at ace.bsd.uchicago.edu Fri Apr 1 16:40:43 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri Apr 1 16:53:33 2005 Subject: [Pythonmac-SIG] readline space problem? Message-ID: In ipython, which uses readline for tab completion in the shell, on my powerbook when I do >>>cd pyth The completer generates >>>cd python _ where the _ is a placeholder for where the cursor ends up. When completing on a long path, this is annoying, because I have to backspace out all those extras spaces. I brought this up on the ipython list and Fernando Perez and I spent some time trying to hunt it down. In the end, he was firmly convinced that this was a platform specific readline problem. I get this behavior in both the X11 xterm and the OS X Terminal. I'm have readline-2.3-binary and readline-2.3.source listed in my Python Install Manager. Someone on the ipython list suggested From: Eric Brown Subject: Re: [IPython-user] OSX tab completion To: Fernando Perez Cc: ipython-user@scipy.net Date: Thu, 31 Mar 2005 12:20:44 -0800 Fink's python and underlying readline do the right thing. There is also something (I can't remember what) to turn on os x's shipping readline to do the right thing. Search google. There is one rather difficult solution - rebuilding readline - and another which is just to change some configuration if I remember correctly. Does this ring a bell with anyone? Any ideas on how to fix this little annoyance? JDH From bob at redivi.com Fri Apr 1 17:17:01 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 1 17:17:07 2005 Subject: [Pythonmac-SIG] readline space problem? In-Reply-To: References: Message-ID: <707e634fea713853f6dc40195ae6c1d3@redivi.com> On Apr 1, 2005, at 9:40, John Hunter wrote: > > In ipython, which uses readline for tab completion in the shell, on my > powerbook when I do > >>>> cd pyth > > The completer generates > >>>> cd python _ > > > where the _ is a placeholder for where the cursor ends up. When > completing on a long path, this is annoying, because I have to > backspace out all those extras spaces. > > I brought this up on the ipython list and Fernando Perez and I spent > some time trying to hunt it down. In the end, he was firmly convinced > that this was a platform specific readline problem. I get this > behavior in both the X11 xterm and the OS X Terminal. > > I'm have readline-2.3-binary and readline-2.3.source listed in my > Python Install Manager. > > Someone on the ipython list suggested > > From: Eric Brown > Subject: Re: [IPython-user] OSX tab completion > To: Fernando Perez > Cc: ipython-user@scipy.net > Date: Thu, 31 Mar 2005 12:20:44 -0800 > > Fink's python and underlying readline do the right thing. > > There is also something (I can't remember what) to turn on os x's > shipping readline to do the right thing. Search google. There is > one > rather difficult solution - rebuilding readline - and another > which is > just to change some configuration if I remember correctly. > > > Does this ring a bell with anyone? Any ideas on how to fix this > little annoyance? Mac OS X does not ship with readline. If you downloaded readline from PackageManager, it's old and might have bugs. The one at http://pythonmac.org/packages/ should link in the latest version of readline as per darwinports when I built it (which is still most recent): 5.0.005. -bob From jdhunter at ace.bsd.uchicago.edu Fri Apr 1 17:13:08 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Fri Apr 1 17:25:51 2005 Subject: [Pythonmac-SIG] readline space problem? In-Reply-To: <707e634fea713853f6dc40195ae6c1d3@redivi.com> (Bob Ippolito's message of "Fri, 1 Apr 2005 10:17:01 -0500") References: <707e634fea713853f6dc40195ae6c1d3@redivi.com> Message-ID: >>>>> "Bob" == Bob Ippolito writes: Bob> Mac OS X does not ship with readline. If you downloaded Bob> readline from PackageManager, it's old and might have bugs. Bob> The one at http://pythonmac.org/packages/ should link in the Bob> latest version of readline as per darwinports when I built it Bob> (which is still most recent): 5.0.005. I just installed this package -- same problem.... Thanks for the suggestion, JDH From bob at redivi.com Fri Apr 1 17:47:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 1 17:47:25 2005 Subject: [Pythonmac-SIG] readline space problem? In-Reply-To: References: <707e634fea713853f6dc40195ae6c1d3@redivi.com> Message-ID: On Apr 1, 2005, at 10:13, John Hunter wrote: >>>>>> "Bob" == Bob Ippolito writes: > > Bob> Mac OS X does not ship with readline. If you downloaded > Bob> readline from PackageManager, it's old and might have bugs. > Bob> The one at http://pythonmac.org/packages/ should link in the > Bob> latest version of readline as per darwinports when I built it > Bob> (which is still most recent): 5.0.005. > > I just installed this package -- same problem.... Then either it's a bug in readline, or you have some kind of local configuration problem. If you search around the Fink project and find out that they're applying any patches, let me know and I'll see if I can do something, but I'm not going to research this further on my own. -bob From kquirk at solidworks.com Fri Apr 1 19:20:14 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Fri Apr 1 19:20:16 2005 Subject: [Pythonmac-SIG] Guidance, please? Message-ID: Hi, folks. I'm porting a commercial Python/C++ application from Windows to Mac, and trying to preserve 95% of the code base as completely cross platform. It's an OpenGL application that constructs its own GUI in the window, so I don't need ANY UI widgets. At all. I should warn you that this is my first experience coding for the Mac, though I have written code for a variety of platforms. The way it works on the PC side is that Python code calls a createWindow function in our app to manufacture the main window. This creates and initializes an OpenGL context. It then calls a mainloop() function that only returns when the app closes. The mainloop() knows about the GL context and can manipulate it. Our first pass at the port attempts to use Carbon to do the same thing. Everything has compiled and the app basically runs, but there are definitely issues, and in many ways the world would be made much nicer if we did something more appropriately "native" to the Mac platform. This is what I've come up with so far: Build a Python and NIB-based application similar to the OpenGLDemo application found in PyOpenGL. Basically, we construct a NIB and a driver module that doesn't do a whole lot more than instantiate an NSOpenGLView. The startup Python code for the app creates that window and has a bunch of handlers in place for all the user and window events. The aglContext object is retrieved from the NSOpenGLView and passed in to the C++ code for use in rendering. The handlers dispatch their various events as needed within the application structure. In most cases, they will be able to stay in python, but in some cases (resize, for example) the information will have to get passed in to the C++ code. A few questions: a) Is this a reasonable architecture? Please understand that rewriting our entire application to be more "Mac-ish" is not an option in this release. b) The intent is to create a single application that will run on as wide a range of OS X machines as possible. We've been developing on 10.3 and messing about with 10.4, and that's cool, but first blush seems to indicate that supporting 10.2 is much more problematic than 10.3. Am I correct about that? How much work is it to support both? Is it worth the trouble? I don't care about developing on 10.2, only about delivering on it. c) PyOpenGL seems to be constructing a menu that says things like "CocoaGL". I don't know how to change it, and it's not obvious from the combination of the demo app and the documentation I've managed to absorb to date. I'm sure I can come up with a ton of questions, but this seems to be one of those situations where you kind of need to know it all to know any of it. I don't yet know which questions are stupid ones, so please bear with me. Thanks, Kent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050401/6897fd2a/attachment.htm From waibel at opix.de Fri Apr 1 20:03:37 2005 From: waibel at opix.de (Peter Waibel) Date: Fri Apr 1 20:03:39 2005 Subject: [Pythonmac-SIG] Re: Re: appscript and XXXX - what is my app instance returning? In-Reply-To: References: Message-ID: <0e8f3ecf9c95b962a9980d4b93553203@opix.de> Try this: #################################### #!/usr/bin/pythonw from appscript import * qxd = app('QuarkXPress') # get the page width pw_hm = qxd.documents[1].page_width.get() # pw_hm is quarks class horizontal_measurement # coerce horizontal_measurement to k.Float pw_float = qxd.coerce(pw_hm,to=k.Float) print pw_float ################################### Quark uses a lot of special data types: agate_units centimeter_units cicero_units inch_units inch_decimal_units millimeter_units pica_units point_units base_units font_units grid_increment_units inset_units leading_units outset_units thick_units trap_units agates_point agates_rectangle centimeters_point centimeters_rectangle ciceros_point ciceros_rectangle inches_point inches_rectangle measurements_point measurements_rectangle millimeters_point millimeters_rectangle percent_point picas_point picas_rectangle points_point points_rectangle angle_measurement You must be very carefull to use the right data type. This is not an appscript problem! This is a Quark "feature". If you use has's help() function for the document object you will get exactly the info you need. Try qxd.help('-t document') and you will get: ======================================================================== ======== Appscript Help (-t document) Reference: app(u'/Applications/QuarkXPress/QuarkXPress.app') ------------------------------------------------------------------------ -------- Terminology for document class Class: document -- A document Parent: default_document Properties: ...... page_height : k.vertical_measurement (r/o) -- the height of a page in this document page_width : k.horizontal_measurement (r/o) -- the width of a page in this document ------- page_height and page_width are properties of the class document. The page inherits these properties from the document. This is another Quark "feature". The object hierachy in Quark is not tree but a labyrinth. I did coding with AppleScript for years. Most of them to drive QuarkXpress and I agree with has's statments that you have to distinguish application-related problems from language-related problems! For the past 2 hours I did my first lines of code with appscript. I'm pretty sure that I will switch to appscript! Has did a really good job! Peter Am 01.04.2005 um 16:23 schrieb has: > 'me' wrote: > >>> tell application "QuarkXPress" >>> tell document 1 >>> set pw to page width as real > > pw = app('QuarkXPress').documents[1].page_width.get(astype=k.Float) > >> But I haven't a clue where to find Quark's coercion method, > > You pass the type you want the result returned as as an optional > argument to the command. It's the same for any app, e.g.: > > from appscript import * > print app('Finder').home.items.get(astype=k.alias_list) # return a > list of Carbon.File.Aliases > > Of course, working out what coercions an application implements can be > a barrel of laughs as it's one of those items that's often not > documented by the developer. > > >> or the keyword for number. > > AE type constants are in Carbon/AppleEvents.py. Appscript scrapes the > constant names and lops off the 'type' so that e.g. typeChar becomes > k.Char, typeFloat becomes k.Float, etc. A better system is definitely > needed, but I haven't figured one out yet. > > >> Any other suggestions for converting this AppleScript coercion into >> python? >> tell application "QuarkXpress" >> tell document 1 >> set pw to (page width as number) >> >> pw.get(astype=k.Char) ## it doesn't like 'astype' or 'k.Char' > > The 'astype' argument should work ok. The problem is figuring out what > value to supply; you'll get a coercion error otherwise. Try k.Float > (what AS calls 'real'). > > >> pw.get(type=appscript.k.inch_units) >> Unfortunately, using one of Quark's classes simply returns >> another <_AE.AEDesc object> > > The 'type' keyword argument isn't recognised, so is simply ignored. (I > should really go back to raising an error on unknown argument names.) > > >> The trick of passing a coercion was a complete surprise. > > It's what AS does, except AS obfuscates it to look like it's the > language doing the coercion, not the application. AS is master of > leaky abstractions. > > >> That idea isn't really obvious from the very nice documentation for >> appscript. > > That's because I somehow forgot to document it. Apologies; I've added > it to my TO DO list. > > >> I am still hoping to spawn a more fruitful discussion of how to >> explore an app's interface using appscript. > > What do you need to know? > > The built-in help() system is good for interactive exploration. Of > course, since it depends on the application's terminology resource it > can't show you any information not already supplied there; all it does > is present what is available in a more helpful fashion. The appscript > documentation still lacks a section on the basic concepts and > principles behind application scripting which is a problem if you > don't already know what you're looking at; obviously this will be > addressed at some point. > > >> But if we're complaining about having to be pre-cognizant of the most >> minute detail >> for an App's implementation of AppleScript before being able to do >> anything with it; >> I'd like to point out that being omniscient is a standard requirement >> for writing IN AppleScript. > > Yep. Appscript is NOT a magic fix for the problems caused by > individual applications' weird or broken scripting implementations and > painfully inadequate documentation; the only solution for that is for > individual users to petition those applications' developers to fix > these problems. File bug reports, file feature requests, have all your > fellow users get onto them too. > > The one thing appscript does give you is a decent language to write > your scripts in. The AppleScript language, while it has some nice > features and [largely unrealised] ideas, is mostly a piece of crud: > slow, buggy, woefully short on the sorts of basic functionality you'd > expect from any half-decent scripting language, and virtually zero > library support. (Not the fault of the AS developers; blame the > clueless suits in Apple management for suddenly choking off its life > support two minutes after it was born and neglecting it ever since.) > > >> To do the most simple thing, you must bang your head against the wall >> until you hit upon the secret. Either by chance or by reading other >> people's discoveries. You're never, ever privy to the source. Don't >> even try to ask. > > The first really useful thing to learn in AppleScript is how to > distinguish application-related problems from language-related > problems. At least with appscript you only have the > application-related problems to deal with (well, once it's finished, > anyway; for now there's still some appscript-related issues to knock > out, which is why threads like this are always very helpful for me > too). And once you know a problem is application related, you'll know > exactly whose balls to go bust until it gets fixed. :) No doubt > starting with lots of very insistent requests for radically improved > documentation. > > >> I am honestly amazed appscript works at all. > > I'm not. The underlying technology - Apple events - is really quite > sound, if not quite of the comfort levels we're used to seeing in > these days of XML-RPC, SOAP, etc. (Remember, OS 7 was designed to run > on 30MHz machines with a couple MB of RAM.) Probably the biggest > problem is that the original APIs for resolving Apple events and > object specifiers are pretty hairy, much harder to master than the > equivalent APIs for assembing GUI interfaces, so designing and > implementing scripting interfaces was really tough for application > developers to do well. Plus you've got good old early-90s Apple > slinging all this wonderful powerful complex technology out the door > and then not bothering to explain to anyone how to actually use it. > > Cocoa Scripting was created to address the former problem (though CS > still has lots of problems of its own), and Apple are ever-so-slowly > starting to move on the latter (but still have a very long way to go). > And hopefully application developers will start providing better > documentation and implementations, especially if/when appscript and > its ilk start drawing in sizeable numbers of tech-savvy and very > demanding new users for this technology, cos there's nothing like a > big vocal userbase banging at the door to motivate developers to do > better. ;) > > Cheers, > > has > -- > http://freespace.virgin.net/hamish.sanderson/ > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Fri Apr 1 20:04:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 1 20:04:43 2005 Subject: [Pythonmac-SIG] Guidance, please? In-Reply-To: References: Message-ID: On Apr 1, 2005, at 12:20, Kent Quirk wrote: > I?m porting a commercial Python/C++ application from Windows to Mac, > and trying to preserve 95% of the code base as completely cross > platform. It?s an OpenGL application that constructs its own GUI in > the window, so I don?t need ANY UI widgets. At all. > > I should warn you that this is my first experience coding for the Mac, > though I have written code for a variety of platforms. > > The way it works on the PC side is that Python code calls a > createWindow function in our app to manufacture the main window. This > creates and initializes an OpenGL context. It then calls a mainloop() > function that only returns when the app closes. The mainloop() knows > about the GL context and can manipulate it. > > Our first pass at the port attempts to use Carbon to do the same > thing. Everything has compiled and the app basically runs, but there > are definitely issues, and in many ways the world would be made much > nicer if we did something more appropriately ?native? to the Mac > platform. Well, Carbon is perfectly native.. if it has issues, then you're doing something wrong. However, Carbon is a pain, and I would never recommend it for new code -- especially if you don't know your way around. > ?This is what I?ve come up with so far: > > Build a Python and NIB-based application similar to the OpenGLDemo > application found in PyOpenGL. Basically, we construct a NIB and a > driver module that doesn?t do a whole lot more than instantiate an > NSOpenGLView. ?The startup Python code for the app creates that window > and has a bunch of handlers in place for all the user and window > events. The aglContext object is retrieved from the NSOpenGLView and > passed in to the C++ code for use in rendering.? The handlers dispatch > their various events as needed within the application structure. In > most cases, they will be able to stay in python, but in some cases > (resize, for example) the information will have to get passed in to > the C++ code. Ok, just to clarify here, you're talking about PyObjC, not PyOpenGL. There is nothing Mac specific in PyOpenGL, especially NIB-related. > A few questions: > > a)???? Is this a reasonable architecture? Please understand that > rewriting our entire application to be more ?Mac-ish? is not an option > in this release. It's unclear how you're doing these "handlers" to capture events. Unless mainloop() pumps the NSRunLoop in some way, you're going to have some real problems... Cocoa is designed to facilitate event driven applications (and so is modern Carbon). Ideally you'd have an event driven application. If you don't, that sucks, but you can pump the events, at the expense of CPU time. There is some discussion of this at: http://www.cocoadev.com/index.pl?FlushingAppEventQueue > b)???? The intent is to create a single application that will run on > as wide a range of OS X machines as possible. We?ve been developing on > 10.3 and messing about with 10.4, and that?s cool, but first blush > seems to indicate that supporting 10.2 is much more problematic than > 10.3. Am I correct about that? How much work is it to support both? Is > it worth the trouble? I don?t care about developing on 10.2, only > about delivering on it. It is simply not really possible to build on 10.3+ and have it work on 10.2. You must build on the lowest common denominator platform, or build entirely from components built on the lowest common denominator platform. My personal recommendation would be to develop on Mac OS X 10.3. 10.4 support will come for free. When you're done with everything else, you can take care of getting everything compiled and built on 10.2. > c)???? PyOpenGL seems to be constructing a menu that says things like > ?CocoaGL?. I don?t know how to change it, and it?s not obvious from > the combination of the demo app and the documentation I?ve managed to > absorb to date. Again, we're talking about PyObjC. Read the documentation regarding Info.plist or the plist option to py2app. In particular, this has to do with the CFBundleName (and possibly related) keys. py2app defaults to using the name of the script you give it as the CFBundleName, which is usually convenient. -bob From kquirk at solidworks.com Fri Apr 1 23:31:06 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Fri Apr 1 23:31:10 2005 Subject: [Pythonmac-SIG] Guidance, please? Message-ID: Thank you for the reply. > Well, Carbon is perfectly native.. if it has issues, then you're doing > something wrong. However, Carbon is a pain, and I would never > recommend it for new code -- especially if you don't know your way > around. I'm beginning to believe that. :-) > > ?This is what I've come up with so far: > > > > Build a Python and NIB-based application similar to the OpenGLDemo > > application found in PyOpenGL. Basically, we construct a NIB and a > > driver module that doesn't do a whole lot more than instantiate an > > NSOpenGLView. ?The startup Python code for the app creates that window > > and has a bunch of handlers in place for all the user and window > > events. The aglContext object is retrieved from the NSOpenGLView and > > passed in to the C++ code for use in rendering.? The handlers dispatch > > their various events as needed within the application structure. In > > most cases, they will be able to stay in python, but in some cases > > (resize, for example) the information will have to get passed in to > > the C++ code. > > Ok, just to clarify here, you're talking about PyObjC, not PyOpenGL. > There is nothing Mac specific in PyOpenGL, especially NIB-related. Sorry, you're correct, of course. > > A few questions: > > > > a)???? Is this a reasonable architecture? Please understand that > > rewriting our entire application to be more "Mac-ish" is not an option > > in this release. > > It's unclear how you're doing these "handlers" to capture events. > Unless mainloop() pumps the NSRunLoop in some way, you're going to have > some real problems... Cocoa is designed to facilitate event driven > applications (and so is modern Carbon). > > Ideally you'd have an event driven application. If you don't, that > sucks, but you can pump the events, at the expense of CPU time. There > is some discussion of this at: > http://www.cocoadev.com/index.pl?FlushingAppEventQueue It is in fact an event driven app on the mac. On the PC, we pump the events. Our Carbon implementation of mainloop installs a timer and then just calls RunApplicationEventLoop(). I don't mind removing the call to mainloop entirely if that's what makes sense in a Python/Cocoa implementation. What I meant by handlers are the methods that handle the operating system events. Currently they all come in to an event dispatcher which calls various methods in Python or C++. I'm perfectly happy to have that dispatcher be a collection of Python methods. I hope I've been clearer about it: is this making sense now? If not, maybe the question I should be asking is this: "I am porting a Python-based OpenGL application that needs to play nice on Mac OS X. What it needs is the ability to open an OpenGL context, set the cursor, get mouse and keyboard events, and have access to various platform APIs like printing and Quicktime. Given that I've never coded in Objective C, what's the best way to implement it?" My premise here is that the answer starts with PyObjC. But I'm still struggling with how to structure it. > My personal recommendation would be to develop on Mac OS X > 10.3. 10.4 support will come for free. When you're done with > everything else, you can take care of getting everything compiled and > built on 10.2. Thank you. That's what I needed to hear. > > c)???? PyOpenGL seems to be constructing a menu that says things like > > "CocoaGL". I don't know how to change it, and it's not obvious from > > the combination of the demo app and the documentation I've managed to > > absorb to date. > > Again, we're talking about PyObjC. Read the documentation regarding > Info.plist or the plist option to py2app. In particular, this has to > do with the CFBundleName (and possibly related) keys. py2app defaults > to using the name of the script you give it as the CFBundleName, which > is usually convenient. Ah. I haven't taken the time yet to understand py2app. Back into the pool! From jcd2102 at columbia.edu Sat Apr 2 17:24:06 2005 From: jcd2102 at columbia.edu (J. Devaney) Date: Sat Apr 2 17:24:09 2005 Subject: [Pythonmac-SIG] Audio I/O Message-ID: <1112455446.424eb9162ee98@cubmail.cc.columbia.edu> Hello, I'm working on a python project that requires audio I/O (via the soundcard) - I basically just need a stream that can be analyzed in real-time and stored to a file. I've looked into various options - such as portaudio using a python wrapper - but since portability isn't really I issue I was wondering if there was a more direct (and simpler approach). Any suggestions or advice would be greatly appreciated. Thanks, Johanna -- johanna devaney phd student, music theory e: jcd2102@columbia.edu From enrike at altern.org Sat Apr 2 23:57:16 2005 From: enrike at altern.org (altern) Date: Sun Apr 3 00:55:58 2005 Subject: [Pythonmac-SIG] Audio I/O In-Reply-To: <1112455446.424eb9162ee98@cubmail.cc.columbia.edu> References: <1112455446.424eb9162ee98@cubmail.cc.columbia.edu> Message-ID: <424F153C.3020708@altern.org> J. Devaney wrote: > Hello, > > I'm working on a python project that requires audio I/O (via the > soundcard) - I basically just need a stream that can be analyzed in > real-time and stored to a file. I've looked into various options - > such as portaudio using a python wrapper - but since portability > isn't really I issue I was wondering if there was a more direct > (and simpler approach). > > Any suggestions or advice would be greatly appreciated. > > Thanks, > > Johanna maybe this is not what you are looking for but you could use something like PureData or SuperCollider to analise the sound real time and then pass the info to python via OpenSoundControl protocol, there is a python implementation and runs pretty well. -- enrike From bugbee at seanet.com Sun Apr 3 10:12:52 2005 From: bugbee at seanet.com (Larry Bugbee) Date: Sun Apr 3 10:12:58 2005 Subject: [Pythonmac-SIG] distutils/swig - Loaded module does not contain symbol... In-Reply-To: <6534ed7363745df734e696909fce2395@mac.com> References: <6534ed7363745df734e696909fce2395@mac.com> Message-ID: <921354e496816098d92d5ca23b134421@seanet.com> I'm stuck. I'm trying to make a Python extension from some relatively simple code written in C. I created a setup.py and built the module. Upon importing, I keep getting an ImportError. I built and got the same error with both python 2.3 and 2.4.1. (I am running 10.3.8. swig is 1.3.24. gcc is 3.3.) Going back to basics I created an even simpler test case with the same results. arith.c ======= int add(int a, int b) { return a+b; } arith.i ======= %module arith int add(int a, int b); setup.py ======== import distutils from distutils.core import setup, Extension setup(name = 'arith', version = '1.0', ext_modules = [Extension('arith', ['arith.i', 'arith.c'])]) python setup.py install >>>import arith The error message... ImportError: Loaded module does not contain symbol _initarith Perhaps you have a suggestion? Tx, Larry From bob at redivi.com Sun Apr 3 10:55:06 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Apr 3 10:55:23 2005 Subject: [Pythonmac-SIG] distutils/swig - Loaded module does not contain symbol... In-Reply-To: <921354e496816098d92d5ca23b134421@seanet.com> References: <6534ed7363745df734e696909fce2395@mac.com> <921354e496816098d92d5ca23b134421@seanet.com> Message-ID: <2f4596d76669183f21a270f7d4b3a63d@redivi.com> On Apr 3, 2005, at 4:12 AM, Larry Bugbee wrote: > I'm stuck. I'm trying to make a Python extension from some relatively > simple code written in C. I created a setup.py and built the module. > Upon importing, I keep getting an ImportError. I built and got the > same error with both python 2.3 and 2.4.1. (I am running 10.3.8. > swig is 1.3.24. gcc is 3.3.) > > Going back to basics I created an even simpler test case with the same > results. > > arith.c > ======= > int add(int a, int b) { > return a+b; > } > > arith.i > ======= > %module arith > int add(int a, int b); > > setup.py > ======== > import distutils > from distutils.core import setup, Extension > setup(name = 'arith', > version = '1.0', > ext_modules = [Extension('arith', ['arith.i', 'arith.c'])]) > > > python setup.py install > >>>import arith from distutils.core import setup, Extension setup( name='arith', version='1.0', ext_modules=[ # swig generates arith.py -- so extension is _arith.so Extension('_arith', ['arith.i', 'arith.c']), ], ) -bob From bugbee at seanet.com Sun Apr 3 11:19:44 2005 From: bugbee at seanet.com (Larry Bugbee) Date: Sun Apr 3 11:19:50 2005 Subject: [Pythonmac-SIG] distutils/swig - Loaded module does not contain symbol... In-Reply-To: <2f4596d76669183f21a270f7d4b3a63d@redivi.com> References: <6534ed7363745df734e696909fce2395@mac.com> <921354e496816098d92d5ca23b134421@seanet.com> <2f4596d76669183f21a270f7d4b3a63d@redivi.com> Message-ID: <76b5e8f05931dea4f754fadf4ddcee79@seanet.com> Thanks Bob! ...that combined with arith.py not being copied to site-package. Which raises another question, ought not arith.py be copied and if so, a bug? Anyway, much appreciated. I'm off and running again. Thanks. Larry On Apr 3, 2005, at 12:55 AM, Bob Ippolito wrote: > > On Apr 3, 2005, at 4:12 AM, Larry Bugbee wrote: > >> I'm stuck. I'm trying to make a Python extension from some >> relatively simple code written in C. I created a setup.py and built >> the module. Upon importing, I keep getting an ImportError. I built >> and got the same error with both python 2.3 and 2.4.1. (I am running >> 10.3.8. swig is 1.3.24. gcc is 3.3.) >> >> Going back to basics I created an even simpler test case with the >> same results. >> >> arith.c >> ======= >> int add(int a, int b) { >> return a+b; >> } >> >> arith.i >> ======= >> %module arith >> int add(int a, int b); >> >> setup.py >> ======== >> import distutils >> from distutils.core import setup, Extension >> setup(name = 'arith', >> version = '1.0', >> ext_modules = [Extension('arith', ['arith.i', 'arith.c'])]) >> >> >> python setup.py install >> >>>import arith > > from distutils.core import setup, Extension > setup( > name='arith', > version='1.0', > ext_modules=[ > # swig generates arith.py -- so extension is _arith.so > Extension('_arith', ['arith.i', 'arith.c']), > ], > ) > > -bob > > From bob at redivi.com Sun Apr 3 20:06:52 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Apr 3 20:06:58 2005 Subject: [Pythonmac-SIG] distutils/swig - Loaded module does not contain symbol... In-Reply-To: <76b5e8f05931dea4f754fadf4ddcee79@seanet.com> References: <6534ed7363745df734e696909fce2395@mac.com> <921354e496816098d92d5ca23b134421@seanet.com> <2f4596d76669183f21a270f7d4b3a63d@redivi.com> <76b5e8f05931dea4f754fadf4ddcee79@seanet.com> Message-ID: On Apr 3, 2005, at 5:19 AM, Larry Bugbee wrote: > On Apr 3, 2005, at 12:55 AM, Bob Ippolito wrote: > >> >> On Apr 3, 2005, at 4:12 AM, Larry Bugbee wrote: >> >>> I'm stuck. I'm trying to make a Python extension from some >>> relatively simple code written in C. I created a setup.py and built >>> the module. Upon importing, I keep getting an ImportError. I built >>> and got the same error with both python 2.3 and 2.4.1. (I am >>> running 10.3.8. swig is 1.3.24. gcc is 3.3.) >>> >>> Going back to basics I created an even simpler test case with the >>> same results. >>> >>> arith.c >>> ======= >>> int add(int a, int b) { >>> return a+b; >>> } >>> >>> arith.i >>> ======= >>> %module arith >>> int add(int a, int b); >>> >>> setup.py >>> ======== >>> import distutils >>> from distutils.core import setup, Extension >>> setup(name = 'arith', >>> version = '1.0', >>> ext_modules = [Extension('arith', ['arith.i', 'arith.c'])]) >>> >>> >>> python setup.py install >>> >>>import arith >> >> from distutils.core import setup, Extension >> setup( >> name='arith', >> version='1.0', >> ext_modules=[ >> # swig generates arith.py -- so extension is _arith.so >> Extension('_arith', ['arith.i', 'arith.c']), >> ], >> ) >> > Thanks Bob! ...that combined with arith.py not being copied to > site-package. > > Which raises another question, ought not arith.py be copied and if so, > a bug? > > Anyway, much appreciated. I'm off and running again. Thanks. You have to specify that as well, of course. I forget what the setup kwarg is for plain modules, though. -bob From bugbee at seanet.com Sun Apr 3 22:58:56 2005 From: bugbee at seanet.com (Larry Bugbee) Date: Sun Apr 3 22:59:00 2005 Subject: [Pythonmac-SIG] distutils/swig - Loaded module does not contain symbol... In-Reply-To: References: <6534ed7363745df734e696909fce2395@mac.com> <921354e496816098d92d5ca23b134421@seanet.com> <2f4596d76669183f21a270f7d4b3a63d@redivi.com> <76b5e8f05931dea4f754fadf4ddcee79@seanet.com> Message-ID: A bug perhaps? Poking around some more I think I see now what was happening. distutils is not automagically copying the swig generated arith.py unless it is there from a previous build (residue). After deleting all residue so that it looks like a 1st time build.... If I attempt a build and install as a single step python setup.py install arith.py is not copied. If I do it in two steps python setup.py build python setup.py install it works. Other args like 'packages' and 'py_modules' don't change this basic behavior. Is someone in a position to confirm these findings? ...and then perhaps a bug report? Again Bob, my thanks. Larry On Apr 3, 2005, at 11:06 AM, Bob Ippolito wrote: > On Apr 3, 2005, at 5:19 AM, Larry Bugbee wrote: > >> On Apr 3, 2005, at 12:55 AM, Bob Ippolito wrote: >> >>> >>> On Apr 3, 2005, at 4:12 AM, Larry Bugbee wrote: >>> >>>> I'm stuck. I'm trying to make a Python extension from some >>>> relatively simple code written in C. I created a setup.py and >>>> built the module. Upon importing, I keep getting an ImportError. >>>> I built and got the same error with both python 2.3 and 2.4.1. (I >>>> am running 10.3.8. swig is 1.3.24. gcc is 3.3.) >>>> >>>> Going back to basics I created an even simpler test case with the >>>> same results. >>>> >>>> arith.c >>>> ======= >>>> int add(int a, int b) { >>>> return a+b; >>>> } >>>> >>>> arith.i >>>> ======= >>>> %module arith >>>> int add(int a, int b); >>>> >>>> setup.py >>>> ======== >>>> import distutils >>>> from distutils.core import setup, Extension >>>> setup(name = 'arith', >>>> version = '1.0', >>>> ext_modules = [Extension('arith', ['arith.i', 'arith.c'])]) >>>> >>>> >>>> python setup.py install >>>> >>>import arith >>> >>> from distutils.core import setup, Extension >>> setup( >>> name='arith', >>> version='1.0', >>> ext_modules=[ >>> # swig generates arith.py -- so extension is _arith.so >>> Extension('_arith', ['arith.i', 'arith.c']), >>> ], >>> ) >>> >> Thanks Bob! ...that combined with arith.py not being copied to >> site-package. >> >> Which raises another question, ought not arith.py be copied and if >> so, a bug? >> >> Anyway, much appreciated. I'm off and running again. Thanks. > > You have to specify that as well, of course. I forget what the setup > kwarg is for plain modules, though. > > -bob > From jdhunter at ace.bsd.uchicago.edu Sun Apr 3 23:31:49 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Sun Apr 3 23:44:44 2005 Subject: [Pythonmac-SIG] readline space problem? In-Reply-To: (Bob Ippolito's message of "Fri, 1 Apr 2005 10:47:19 -0500") References: <707e634fea713853f6dc40195ae6c1d3@redivi.com> Message-ID: Bob> Then either it's a bug in readline, or you have some kind of Bob> local configuration problem. If you search around the Fink Bob> project and find out that they're applying any patches, let Bob> me know and I'll see if I can do something, but I'm not going Bob> to research this further on my own. Hi Bob, Just wanted to update you on this. Fernando took a deeper look at this, and found that a readline macro needs to be set at compile time to prevent the space from being inserted. This is normally set by the python configure, which apparently apple does not use define_macros=[('HAVE_RL_COMPLETION_APPEND_CHARACTER', None)], The complete post is below. Thanks for taking a look at this. JDH From: Fernando Perez Subject: Re: [IPython-user] Re: OSX tab completion To: Robert Kern Cc: ipython-user@scipy.net Date: Fri, 01 Apr 2005 19:03:27 -0700 Organization: Applied Mathematics, University of Colorado at Boulder Robert Kern wrote: >> Robert, does this mean you also have the same problem? I didn't >> realize that this was a widespread OSX issue. If someone has a >> definitive solution/answer to this, please let me know so I can add >> this information to the user's guide for future reference. > Yes, I have the same problem. I am using my own build of readline > 5.0. Unless I get more info very soon, this is also the build that > will be in MacEnthon. OK, this is definitely controlled by the python build of readline.c. Here are some pointers. From the Gnu readline manual at http://cnswww.cns.cwru.edu/~chet/readline/readline.html, I found this note: Variable: int rl_completion_append_character When a single completion alternative matches at the end of the command line, this character is appended to the inserted completion text. The default is a space character (` '). Setting this to the null character (`\0') prevents anything being appended automatically. This can be changed in application-specific completion functions to provide the "most sensible word separator character" according to an application-specific command line syntax specification. Indeed, in the Python 2.4.1 source tree, in Modules/readline.c, around line 717 we find: #ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER rl_completion_append_character ='\0'; #endif Now, a grep of the whole source tree reveals: planck[Python-2.4.1]> egrep -rn HAVE_RL_COMPLETION_APPEND_CHARACTER * configure:19433:#define HAVE_RL_COMPLETION_APPEND_CHARACTER 1 configure.in:2861: AC_DEFINE(HAVE_RL_COMPLETION_APPEND_CHARACTER, 1, Modules/readline.c:487:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER Modules/readline.c:579:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER Modules/readline.c:716:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER Modules/readline.c:858:#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER pyconfig.h.in:375:#undef HAVE_RL_COMPLETION_APPEND_CHARACTER So what appears to occur is that under OSX, for whatever reason, configure is NOT defining the HAVE_RL_COMPLETION_APPEND_CHARACTER macro, and hence the rl_completion_append_character is never reset to '\0'. In this case, as indicated above, the readline library will default to appending a space. With this info, it should be possible to track down why under OSX (at least under certain builds), the HAVE_RL_COMPLETION_APPEND_CHARACTER macro is not being defined. Worse case, you could just modify readline.c to make the above change unconditionally, without worrying about this macro (just strip the ifdef/endif). Note that this variable is NOT exposed publically by the python readline API, so this has to be fixed at build time, you can't reset it later at runtime via any kind of user setting (at least not that I can see). I hope this helps some. Best, f _______________________________________________ IPython-user mailing list IPython-user@scipy.net http://scipy.net/mailman/listinfo/ipython-user From bob at redivi.com Mon Apr 4 00:04:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 4 00:04:45 2005 Subject: [Pythonmac-SIG] readline space problem? In-Reply-To: References: <707e634fea713853f6dc40195ae6c1d3@redivi.com> Message-ID: On Apr 3, 2005, at 5:31 PM, John Hunter wrote: > > Bob> Then either it's a bug in readline, or you have some kind of > Bob> local configuration problem. If you search around the Fink > Bob> project and find out that they're applying any patches, let > Bob> me know and I'll see if I can do something, but I'm not going > Bob> to research this further on my own. > > Just wanted to update you on this. Fernando took a deeper look at > this, and found that a readline macro needs to be set at compile time > to prevent the space from being inserted. This is normally set by the > python configure, which apparently apple does not use > > define_macros=[('HAVE_RL_COMPLETION_APPEND_CHARACTER', None)], Again, Apple did not do anything. readline is *not part of OS X*, so it can't possibly be their fault. This problem would be the fault of whomever built the extension, out of tree... in this case, either Jack or me, depending on where you got it from. Unfortunately I won't get around to fixing this for a while, but the Python 2.4.1 distribution I built comes with a readline extension built at the same time as Python, so it should work fine. -bob From Jack.Jansen at cwi.nl Mon Apr 4 00:38:17 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Apr 4 00:38:17 2005 Subject: [Pythonmac-SIG] Embedding with CW6 In-Reply-To: <20732218f235a554e4964c428f32fac6@spvi.com> References: <20732218f235a554e4964c428f32fac6@spvi.com> Message-ID: <48a789d59e91916ae42641e4f22751b2@cwi.nl> On 24-mrt-05, at 14:28, Steve Spicklemire wrote: > Hi Folks, > > Back in the pretty old days (python 1.5 or so I think) I developed a > Macromedia Director (MMD) scripting Xtra that allowed Lingo scripts to > use python as an embedded language. It worked great... but I moved on > and haven't done anything Carbon in years. Now I find myself in a > situation where I need to get that Xtra working with the latest MMD. > The Macromedia XDK seems to only support Codewarrior on the Mac. I > have only CW6 at this point (I have an email sent off to Metrowerks > asking how I might get CW7) so I guess I can't build the latest > sources (as they seem to want CW7). So.. the question is: What's the > latest set of sources that will likely work on CW6? (in case I can't > get CW7). It's difficult to tell (I have to work from the log messages, and compare checkins to release tags), but it seems I made the switch from CW6 to CW7 in December 2001. The log messages seem to suggest that 2.2 was released with CW7. So that means 2.1 is the last version that'll build with CW6... -- 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 OpenMacNews at speakeasy.net Mon Apr 4 03:03:20 2005 From: OpenMacNews at speakeasy.net (OpenMacNews) Date: Mon Apr 4 03:03:27 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... Message-ID: <311FD5BA5420240EAAD6E814@tiedgar> hi all, i've originally posted this on python-list -- but I have a suspicion my questions may have to do with Mac-specific issues, so I'll try here as well ... i've successfully built Python-2.4.1 from src on OSX 10.3.8 as a framework install with, simply: ./configure \ --enable-framework \ --with-threads \ --with-cxx=g++ \ --enable-ipv6 \ --enable-toolbox-glue make frameworkinstall i'm next attempting to build same but linking against an external instance of libxml2 (v2.6.18) installed in /usr/local ... i've tried the ususal combinations of setting LDFLAGS and/or assigning --with-libs (="/usr/local/lib/libxml2.2.6.18.dylib"), to no avail. no matter what i do, the build links against the 'native' /usr/lib/libxml* ... successful w/ no error, just the 'wrong' lib. wondering whether i had unusual path probs, i also tried mv'ing the native libs out of the way, so that the only instance of libxml* is found in /usr/local/lib, but then the make fails, complaining that /usr/lib/libxml* is not found. sigh. i'm fairly sure i'm missing something trivial here ... any suggestions/pointers as to how to link *my* libxml into the framework build? thanks! richard From rkern at ucsd.edu Mon Apr 4 03:03:26 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 4 03:03:30 2005 Subject: [Pythonmac-SIG] MacEnthon 0.0 testing release Message-ID: <4250925E.1070107@ucsd.edu> I am pleased to announce the availability of MacEnthon 0.0! MacEnthon is the OS X counterpart to the popular "Enthought Edition" of Python: a convenient bundling of a number of packages geared for the scientific community. Right now, it targets the Apple-installed Python 2.3.0. Once I am satisfied with this release, I will consider cutting a release for Python 2.4.1. This is currently just a test release. Please do not tell newbies to go install it, yet. For a full list of packages, please see the ReadMe: http://download.enthought.com/MacEnthon/ReadMe.html To download: http://download.enthought.com/MacEnthon/MacEnthon-0.0.dmg Included is a CLI uninstaller, enthonbegone.py . It may leave a few empty directories hanging about, but otherwise it works fairly well. See its help for more information. When you encounter problems, packaging/build bugs, or missing documentation, please log it on the Enthon issue tracker and assign the issue to "rkern": https://www.enthought.com/roundup/enthon/ Thank you all. -- 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 rkern at ucsd.edu Mon Apr 4 03:15:13 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 4 03:15:20 2005 Subject: [Pythonmac-SIG] MacEnthon 0.0 testing release In-Reply-To: <4250925E.1070107@ucsd.edu> References: <4250925E.1070107@ucsd.edu> Message-ID: <42509521.3050102@ucsd.edu> Robert Kern wrote: > I am pleased to announce the availability of MacEnthon 0.0! I should add that the disk image is 158 MiB large and that the installed files take up... I'm not actually sure, but it's under 700 MiB, I believe. Zip archives of individual packages will be available when I get around to it. -- 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 Apr 4 03:37:10 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 4 03:37:22 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <311FD5BA5420240EAAD6E814@tiedgar> References: <311FD5BA5420240EAAD6E814@tiedgar> Message-ID: On Apr 3, 2005, at 21:03, OpenMacNews wrote: > i've originally posted this on python-list -- but I have a suspicion > my questions may have to do with Mac-specific issues, so I'll try here > as well ... > > i've successfully built Python-2.4.1 from src on OSX 10.3.8 as a > framework install with, simply: > > ./configure \ > --enable-framework \ > --with-threads \ > --with-cxx=g++ \ > --enable-ipv6 \ > --enable-toolbox-glue > > make frameworkinstall > > i'm next attempting to build same but linking against an external > instance of libxml2 (v2.6.18) installed in /usr/local ... > > i've tried the ususal combinations of setting LDFLAGS and/or assigning > --with-libs (="/usr/local/lib/libxml2.2.6.18.dylib"), to no avail. > > no matter what i do, the build links against the 'native' > /usr/lib/libxml* ... successful w/ no error, just the 'wrong' lib. Neither Python itself, nor any extension in the standard library, links to libxml. What the heck are you talking about? -bob From bob at redivi.com Mon Apr 4 03:40:59 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 4 03:41:05 2005 Subject: [Pythonmac-SIG] MacEnthon 0.0 testing release In-Reply-To: <4250925E.1070107@ucsd.edu> References: <4250925E.1070107@ucsd.edu> Message-ID: <1ff831e8a757b3e09711a38007c2de9f@redivi.com> On Apr 3, 2005, at 21:03, Robert Kern wrote: > I am pleased to announce the availability of MacEnthon 0.0! > > MacEnthon is the OS X counterpart to the popular "Enthought Edition" > of Python: a convenient bundling of a number of packages geared for > the scientific community. Right now, it targets the Apple-installed > Python 2.3.0. Once I am satisfied with this release, I will consider > cutting a release for Python 2.4.1. This is currently just a test > release. Please do not tell newbies to go install it, yet. Excellent. You should probably be using PyProtocols CVS. Which revision of PyObjC is in there? I made some commits today... Hopefully you didn't pick something up while I was in the midst of working on the new Xcode templates... -bob From rkern at ucsd.edu Mon Apr 4 03:48:00 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 4 03:48:09 2005 Subject: [Pythonmac-SIG] MacEnthon 0.0 testing release In-Reply-To: <1ff831e8a757b3e09711a38007c2de9f@redivi.com> References: <4250925E.1070107@ucsd.edu> <1ff831e8a757b3e09711a38007c2de9f@redivi.com> Message-ID: <42509CD0.9090604@ucsd.edu> Bob Ippolito wrote: > > On Apr 3, 2005, at 21:03, Robert Kern wrote: > >> I am pleased to announce the availability of MacEnthon 0.0! >> >> MacEnthon is the OS X counterpart to the popular "Enthought Edition" >> of Python: a convenient bundling of a number of packages geared for >> the scientific community. Right now, it targets the Apple-installed >> Python 2.3.0. Once I am satisfied with this release, I will consider >> cutting a release for Python 2.4.1. This is currently just a test >> release. Please do not tell newbies to go install it, yet. > > > Excellent. You should probably be using PyProtocols CVS. Works for me. > Which > revision of PyObjC is in there? I made some commits today... Hopefully > you didn't pick something up while I was in the midst of working on the > new Xcode templates... Apparently I did. I touched a 00README.txt to get it to build. I'll rebuild tomorrow or whenever you guys think it's wise. I've been following the PyObjC list and the str-unicode issues. -- 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 Apr 4 04:00:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 4 04:00:57 2005 Subject: [Pythonmac-SIG] MacEnthon 0.0 testing release In-Reply-To: <42509CD0.9090604@ucsd.edu> References: <4250925E.1070107@ucsd.edu> <1ff831e8a757b3e09711a38007c2de9f@redivi.com> <42509CD0.9090604@ucsd.edu> Message-ID: <40d6f1db77eb06ca491da6337dad513c@redivi.com> On Apr 3, 2005, at 21:48, Robert Kern wrote: > Bob Ippolito wrote: >> On Apr 3, 2005, at 21:03, Robert Kern wrote: >>> I am pleased to announce the availability of MacEnthon 0.0! >>> >>> MacEnthon is the OS X counterpart to the popular "Enthought Edition" >>> of Python: a convenient bundling of a number of packages geared for >>> the scientific community. Right now, it targets the Apple-installed >>> Python 2.3.0. Once I am satisfied with this release, I will consider >>> cutting a release for Python 2.4.1. This is currently just a test >>> release. Please do not tell newbies to go install it, yet. >> Excellent. You should probably be using PyProtocols CVS. > > Works for me. > >> Which revision of PyObjC is in there? I made some commits today... >> Hopefully you didn't pick something up while I was in the midst of >> working on the new Xcode templates... > > Apparently I did. I touched a 00README.txt to get it to build. I'll > rebuild tomorrow or whenever you guys think it's wise. I've been > following the PyObjC list and the str-unicode issues. I trashed that 00README because it's no longer relevant to anything else in the repository. The new docs aren't written yet. It's fine to rebuild tomorrow, but I think we might make another relatively major change in the next week, aside from updated docs. -bob From OpenMacNews at speakeasy.net Mon Apr 4 04:44:33 2005 From: OpenMacNews at speakeasy.net (OpenMacNews) Date: Mon Apr 4 04:44:40 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: References: <311FD5BA5420240EAAD6E814@tiedgar> Message-ID: <6400729F1EE915D92B913377@tiedgar> hi bob, >> no matter what i do, the build links against the 'native' >> /usr/lib/libxml* ... successful w/ no error, just the 'wrong' lib. > Neither Python itself, nor any extension in the standard library, links to libxml. well, that's good -- & at least consistent with why there's no significant reference to libxml in the src ... if that's the case, then it seems even more odd to me that the python build is sensitive to its presence & location ... as, > What the heck are you talking about? simply the output of my python build's 'make' (well, 'make frameworkinstall', anyway ... ): >> but then the make fails, complaining that /usr/lib/libxml* is not found with 'native' libxml* mv'd from /usr/lib, % ls -al *xml* su: /usr/local/bin/ls: No match. and libxml2-2.6.18 installed in /usr/local/lib, % ls -al /usr/local/lib/*xml* -rwxr-xr-x 1 root staff 3038292 Apr 3 19:18 libxml2.2.6.18.dylib lrwxr-xr-x 1 root staff 20 Apr 3 19:18 libxml2.2.dylib -> libxml2.2.6.18.dylib -rw-r--r-- 1 root staff 3651384 Apr 3 19:18 libxml2.a lrwxr-xr-x 1 root staff 20 Apr 3 19:18 libxml2.dylib -> libxml2.2.6.18.dylib -rwxr-xr-x 1 root staff 848 Apr 3 19:18 libxml2.la -rw-r--r-- 1 root staff 228 Apr 3 19:18 xml2Conf.sh python 'make' dies with ... ... Mkdir ///Applications/MacPython-2.4 /bin/mkdir -p ///Applications/MacPython-2.4 StandaloneExecutable ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLaunc her StandaloneExecutable.LinkUsingFileList ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLaunc her gcc -o ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonL auncher "-L/Volumes/Projects/ports/Python-2.4.1/Mac/OSX/PythonLauncher/build" "-L/Volumes/Projects/ports/Python-2.4.1/Mac/OSX/PythonLauncher/build" "-F/Volumes/Projects/ports/Python-2.4.1/Mac/OSX/PythonLauncher/build" "-F/Volumes/Projects/ports/Python-2.4.1/Mac/OSX/PythonLauncher/build" -filelist /Volumes/Projects/ports/Python-2.4.1/Mac/OSX/PythonLauncher/build/Pytho nLauncher.build/PythonLauncher.build/Objects-normal/LinkFileList "-arch" "ppc" "-s" "-prebind" "-Wl,-no_arch_warnings" "-framework" "Cocoa" "-framework" "Carbon" ld: warning prebinding disabled because dependent library: /usr/lib/libz.1.dylib is not prebound ld: warning can't open dynamic library: /usr/lib/libxml2.2.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _xmlSAXUserParseMemory referenced from Foundation expected to be defined in /usr/lib/libxml2.2.dylib ...failed StandaloneExecutable.LinkUsingFileList ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLaunc her ... ** BUILD FAILED ** make[1]: *** [install_PythonLauncher] Error 1 make: *** [frameworkinstallapps] Error 2 *something's* expecting libxml2 to be there ... richard From rkern at ucsd.edu Mon Apr 4 05:08:30 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 4 05:08:35 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <6400729F1EE915D92B913377@tiedgar> References: <311FD5BA5420240EAAD6E814@tiedgar> <6400729F1EE915D92B913377@tiedgar> Message-ID: <4250AFAE.4010305@ucsd.edu> OpenMacNews wrote: > /Volumes/Projects/ports/Python-2.4.1/Mac/OSX/PythonLauncher/build/Pytho > nLauncher.build/PythonLauncher.build/Objects-normal/LinkFileList > "-arch" "ppc" "-s" "-prebind" "-Wl,-no_arch_warnings" "-framework" > "Cocoa" "-framework" "Carbon" > ld: warning prebinding disabled because dependent library: > /usr/lib/libz.1.dylib is not prebound > ld: warning can't open dynamic library: /usr/lib/libxml2.2.dylib > (checking > for undefined symbols may be affected) (No such file or directory, > errno = > 2) > ld: Undefined symbols: > _xmlSAXUserParseMemory referenced from Foundation expected to be > defined in > /usr/lib/libxml2.2.dylib > ...failed StandaloneExecutable.LinkUsingFileList > > ///Applications/MacPython-2.4/PythonLauncher.app/Contents/MacOS/PythonLaunc > her ... > ** BUILD FAILED ** > make[1]: *** [install_PythonLauncher] Error 1 > make: *** [frameworkinstallapps] Error 2 > > *something's* expecting libxml2 to be there ... I'll bet that it's either Cocoa or Carbon. In that case, you definitely *don't* want it to use your own libxml2. Leave it be. -- 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 OpenMacNews at speakeasy.net Mon Apr 4 05:23:55 2005 From: OpenMacNews at speakeasy.net (OpenMacNews) Date: Mon Apr 4 05:24:03 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <4250AFAE.4010305@ucsd.edu> References: <311FD5BA5420240EAAD6E814@tiedgar> <6400729F1EE915D92B913377@tiedgar> <4250AFAE.4010305@ucsd.edu> Message-ID: <5AF0008DBBFF2D85173FCA94@tiedgar> hi robert, >> *something's* expecting libxml2 to be there ... > > I'll bet that it's either Cocoa or Carbon. In that case, you definitely > *don't* want it to use your own libxml2. makes possible sense in that there's a reference to 'Foundation', which given your suspicion, refers to the OSX FoundationClass(es)? I.e., Cocoa/Carbon? >> ld: Undefined symbols: >> _xmlSAXUserParseMemory referenced from Foundation expected to be >> defined in >> /usr/lib/libxml2.2.dylib thought i'd be very hard pressed to prove or disprove ... > Leave it be. Which is certainly good advice if that IS the case ... yet I'm still a little foggy on the whole matter given Bob's earlier comment: > either Python itself, nor any extension in the standard library, links to libxml. What the heck are you talking about? which, iiuc, would suggest no dependence whatsoever on libxml -- either direct or indirect via Cocoa/Carbon. so, again, > Leave it be. seems to be good advice. what concerns me a bit is that 'other' apps i'm building depend on my *external* libxml, and will -- eventually -- 'touch' some Python, which will depend 'still' on the native (cocoa/carbon related) libxml ... Will this 'version incompatibility' come back to bite me in the ass? i simply dunno. short of understanding/resolving the libxml dependence i *am* seeing, I guess I'll just have to wait and see when i get there =) thx, richard From lee_cullens at mac.com Mon Apr 4 05:39:20 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Mon Apr 4 05:39:27 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> Message-ID: <673ae337023357cea68eaeb2ef9c9b0f@mac.com> Well Bob - I decided to install your 2.4.1 before I get to a point where I could screw up something important :~) In an initial pass through my learning project, all worked well so far. The only thing I had to do was copy my localized package .pth file to a new folder ~/Library/Python/2.4/site-packages. I also installed the new py2app package but have not progressed to the point of using it yet. Mainly what I am waiting on now is Kevin to announce that he has checked out SPE with wxPy 2.5.4.1, then I'll see if I need to update/move/change a path/whatever my previously downloaded wxPython. Thanks for the effort Bob, Lee C On Mar 31, 2005, at 10:12 AM, Bob Ippolito wrote: > I've put together an "official unofficial" framework build > distribution of Python 2.4.1 for Mac OS X 10.3 (and later, but that is > not tested yet). It is built using the same tools that Jack builds the > official MacPython distribution with. > > -bob > From rkern at ucsd.edu Mon Apr 4 05:43:53 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 4 05:44:05 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <5AF0008DBBFF2D85173FCA94@tiedgar> References: <311FD5BA5420240EAAD6E814@tiedgar> <6400729F1EE915D92B913377@tiedgar> <4250AFAE.4010305@ucsd.edu> <5AF0008DBBFF2D85173FCA94@tiedgar> Message-ID: <4250B7F9.1040002@ucsd.edu> OpenMacNews wrote: > hi robert, > >>> *something's* expecting libxml2 to be there ... >> >> >> I'll bet that it's either Cocoa or Carbon. In that case, you definitely >> *don't* want it to use your own libxml2. > > > makes possible sense in that there's a reference to 'Foundation', which > given your suspicion, refers to the OSX FoundationClass(es)? I.e., > Cocoa/Carbon? Foundation is its own framework (see /System/Library/Frameworks) which is implicitly linked in by Cocoa and Carbon. > >> ld: Undefined symbols: > >> _xmlSAXUserParseMemory referenced from Foundation expected to be > >> defined in > >> /usr/lib/libxml2.2.dylib > > thought i'd be very hard pressed to prove or disprove ... > >> Leave it be. > > > Which is certainly good advice if that IS the case ... yet I'm still a > little foggy on the whole matter given Bob's earlier comment: > >> either Python itself, nor any extension in the standard library, links to > > libxml. What the heck are you talking about? > > which, iiuc, would suggest no dependence whatsoever on libxml -- either > direct or indirect via Cocoa/Carbon. No, he only meant directly, I'm sure. > so, again, > >> Leave it be. > > > seems to be good advice. > > what concerns me a bit is that 'other' apps i'm building depend on my > *external* libxml, and will -- eventually -- 'touch' some Python, which > will depend 'still' on the native (cocoa/carbon related) libxml ... > > Will this 'version incompatibility' come back to bite me in the ass? i > simply dunno. > > short of understanding/resolving the libxml dependence i *am* seeing, I > guess I'll just have to wait and see when i get there =) Always a good idea. Don't fix it until it breaks. And it probably won't. -- 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 OpenMacNews at speakeasy.net Mon Apr 4 05:52:45 2005 From: OpenMacNews at speakeasy.net (OpenMacNews) Date: Mon Apr 4 05:52:52 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <4250B7F9.1040002@ucsd.edu> References: <311FD5BA5420240EAAD6E814@tiedgar> <6400729F1EE915D92B913377@tiedgar> <4250AFAE.4010305@ucsd.edu> <5AF0008DBBFF2D85173FCA94@tiedgar> <4250B7F9.1040002@ucsd.edu> Message-ID: <105D4D687050B0EB479F7345@tiedgar> robert, > Foundation is its own framework (see /System/Library/Frameworks) yup. > which is implicitly linked in by Cocoa and Carbon. sigh. more to learn. =-) clearly time to unpack & actually read my new copy of Hillegass' book ... >> which, iiuc, would suggest no dependence whatsoever on libxml -- either >> direct or indirect via Cocoa/Carbon. > > No, he only meant directly, I'm sure. hmmm. ok. > Always a good idea. Don't fix it until it breaks. And it probably won't. well, rats! so much for the 'pleasant aesthetics' of version consistency ;-) thx & cheers, richard From bob at redivi.com Mon Apr 4 05:54:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 4 05:55:01 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <5AF0008DBBFF2D85173FCA94@tiedgar> References: <311FD5BA5420240EAAD6E814@tiedgar> <6400729F1EE915D92B913377@tiedgar> <4250AFAE.4010305@ucsd.edu> <5AF0008DBBFF2D85173FCA94@tiedgar> Message-ID: On Apr 3, 2005, at 23:23, OpenMacNews wrote: >>> *something's* expecting libxml2 to be there ... >> >> I'll bet that it's either Cocoa or Carbon. In that case, you >> definitely >> *don't* want it to use your own libxml2. > > makes possible sense in that there's a reference to 'Foundation', > which given your suspicion, refers to the OSX FoundationClass(es)? > I.e., Cocoa/Carbon? > > >> ld: Undefined symbols: > >> _xmlSAXUserParseMemory referenced from Foundation expected to > be > >> defined in > >> /usr/lib/libxml2.2.dylib > > thought i'd be very hard pressed to prove or disprove ... Foundation is part of Cocoa, yes. >> Leave it be. > > Which is certainly good advice if that IS the case ... yet I'm still a > little foggy on the whole matter given Bob's earlier comment: > >> either Python itself, nor any extension in the standard library, >> links to > libxml. What the heck are you talking about? > > which, iiuc, would suggest no dependence whatsoever on libxml -- > either direct or indirect via Cocoa/Carbon. No, you don't understand correctly. That's not what I meant. > so, again, > >> Leave it be. > > seems to be good advice. > > what concerns me a bit is that 'other' apps i'm building depend on my > *external* libxml, and will -- eventually -- 'touch' some Python, > which will depend 'still' on the native (cocoa/carbon related) libxml > ... > > Will this 'version incompatibility' come back to bite me in the ass? > i simply dunno. > > short of understanding/resolving the libxml dependence i *am* seeing, > I guess I'll just have to wait and see when i get there =) You are crazy! Messing with /usr/lib or /System is just *BEGGING* to break your OS. If you reboot with that libxml moved, your system might not even come up! DO NOT DO THAT. EVER. The fact that Foundation internally uses libxml is none of your business. Mac OS X uses a 2 level symbol namespace, and will not have a problem with this, unless you use stupid linker flags like -flat_namespace. Python, since 2.3 (possibly in some 2.2 version as well, but I don't care), will not use -flat_namespace. If you statically link to your external libxml, then it's impossible to have a problem, because the symbols aren't looked up at runtime and aren't exported to other modules. -bob From bob at redivi.com Mon Apr 4 06:01:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 4 06:01:10 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <105D4D687050B0EB479F7345@tiedgar> References: <311FD5BA5420240EAAD6E814@tiedgar> <6400729F1EE915D92B913377@tiedgar> <4250AFAE.4010305@ucsd.edu> <5AF0008DBBFF2D85173FCA94@tiedgar> <4250B7F9.1040002@ucsd.edu> <105D4D687050B0EB479F7345@tiedgar> Message-ID: <299ac382adb45861300a9ccb76d21fc2@redivi.com> On Apr 3, 2005, at 23:52, OpenMacNews wrote: >> Foundation is its own framework (see /System/Library/Frameworks) > > yup. > >> which is implicitly linked in by Cocoa and Carbon. Actually no, Carbon doesn't link to Foundation. Everything written in Objective-C does, though. You're probably thinking of CoreFoundation. > sigh. more to learn. =-) > > clearly time to unpack & actually read my new copy of Hillegass' book > ... That book isn't going to talk about mundane details about how Mac OS X's internal frameworks are linked together (which changes every release, and is really none of your business). Though the book will probably be enlightening, it's not in any way relevant to this. Why are you building your own framework anyway? The one I built is perfectly good, and I actually know what I'm doing ;) -bob From rkern at ucsd.edu Mon Apr 4 06:08:12 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 4 06:08:18 2005 Subject: [Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ... In-Reply-To: <299ac382adb45861300a9ccb76d21fc2@redivi.com> References: <311FD5BA5420240EAAD6E814@tiedgar> <6400729F1EE915D92B913377@tiedgar> <4250AFAE.4010305@ucsd.edu> <5AF0008DBBFF2D85173FCA94@tiedgar> <4250B7F9.1040002@ucsd.edu> <105D4D687050B0EB479F7345@tiedgar> <299ac382adb45861300a9ccb76d21fc2@redivi.com> Message-ID: <4250BDAC.9010709@ucsd.edu> Bob Ippolito wrote: > On Apr 3, 2005, at 23:52, OpenMacNews wrote: > >>> Foundation is its own framework (see /System/Library/Frameworks) >> >> >> yup. >> >>> which is implicitly linked in by Cocoa and Carbon. > > > Actually no, Carbon doesn't link to Foundation. Everything written in > Objective-C does, though. You're probably thinking of CoreFoundation. Ah, yes, you're right. Thank you. -- 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 Henning.Ramm at mediapro-gmbh.de Mon Apr 4 09:43:32 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Mon Apr 4 09:43:35 2005 Subject: [Pythonmac-SIG] XML handler design Message-ID: >If you want a cleaner coder, you give might one of the more "pythonic" >XML APIs, like ElementTree or XIST a try. > >ElementTree: http://effbot.org/zone/element-index.htm >XIST: http://www.livinglogic.de/Python/xist/ Thank you for this links - lots of interesting stuff there that I didn't know. Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From lee_cullens at mac.com Mon Apr 4 16:17:13 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Mon Apr 4 16:17:22 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> Message-ID: <5555860b2adc91fced5ecdf850bc0247@mac.com> Bob, One thing I noticed with your 2.4.1 build is that in the PythonIDE Help menu "Python Documentation" and "Lookup in Python Documentation" are dimmed out (not available). Such in the 2.3 PythonIDE is still available though. This time I did look in the Mac Python FAQ first, but the suggestion there did not remedy the problem. Thanks, Lee C On Mar 31, 2005, at 10:12 AM, Bob Ippolito wrote: > I've put together an "official unofficial" framework build > distribution of Python 2.4.1 for Mac OS X 10.3 (and later, but that is > not tested yet). It is built using the same tools that Jack builds the > official MacPython distribution with. > > -bob From bob at redivi.com Mon Apr 4 16:34:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 4 16:34:40 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <5555860b2adc91fced5ecdf850bc0247@mac.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <5555860b2adc91fced5ecdf850bc0247@mac.com> Message-ID: On Apr 4, 2005, at 10:17, Lee Cullens wrote: > One thing I noticed with your 2.4.1 build is that in the PythonIDE > Help menu "Python Documentation" and "Lookup in Python Documentation" > are dimmed out (not available). Such in the 2.3 PythonIDE is still > available though. > > This time I did look in the Mac Python FAQ first, but the suggestion > there did not remedy the problem. I have no idea. If it's broken, it's broken in the source -- I didn't do it. I don't use PythonIDE, so I'm not really interested in tracking it down myself. -bob From lee_cullens at mac.com Mon Apr 4 22:13:12 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Mon Apr 4 22:13:18 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <5555860b2adc91fced5ecdf850bc0247@mac.com> Message-ID: <08ed64ad4d448cf0fbdd5e5a4282faaf@mac.com> Personally I think these little package idiosyncrasies are what discourage non-hacker users and businesses that might otherwise advance the use of Python, to the benefit of those that have enough experience and skills to prepare and maintain a presentable tool - but we all have a perfect right to our own priorities and outlook. I (so far) am using PythonIDE as a simple higher level (than the terminal) alternative. IDLE uses cr line endings instead of the Unix lf which has caused me some annoyances, and though I versonized wxPython so I could get SPE to run I find it has a way to go yet (at least on a Mac OS X platform). Neither am I ready yet to invest in Wing till I get up to speed in this "neighborhood" and I'm watching where Xcode might go. Anyway, I looked at the two versions (2.3 and 2.4) of the PythonIDE package and at PytyhonIDEMain.py in particular. There is a self labeled hack in PytyhonIDEMain.py for building the Help menu (telling the Help Viewer about the Python documentation) that looks in two different places. In the 2.3 MacPython version there is an additional resource that satisfies the search, namely Contents/Resources/English.lproj. In the 2.4 version that resource is missing. The other place it looks is in the Python application inside the framework and I haven't tracked that down yet in the 2.3 version to see if it is there also, but it is obviously not there in the 2.4 version. Copying the 2.3 resource into 2.4 would result in 2.3 documentation for the 2.4 version so such is no solution. So somewhere along the line from the Mac 2.3 version to your Mac 2.4 version the documentation resource was overlooked or dropped for some other reason. Maybe someone has an idea how I could remedy the situation (?) and in the meantime I'll continue developing my skills in this "neighborhood" till I understand enough to solve the issue without screwing something else up. Thanks for all your efforts and the 2.4 build Bob and to all a good and prosperous day, Lee C "It is unwise to be too sure of one's own wisdom. It is healthy to be reminded that the strongest might weaken and the wisest might err." -- Mahatma Gandhi "Pay attention. You don't know what disguise your next teacher will be wearing." -- ? On Apr 4, 2005, at 10:34 AM, Bob Ippolito wrote: > > On Apr 4, 2005, at 10:17, Lee Cullens wrote: > >> One thing I noticed with your 2.4.1 build is that in the PythonIDE >> Help menu "Python Documentation" and "Lookup in Python Documentation" >> are dimmed out (not available). Such in the 2.3 PythonIDE is still >> available though. >> >> This time I did look in the Mac Python FAQ first, but the suggestion >> there did not remedy the problem. > > I have no idea. If it's broken, it's broken in the source -- I didn't > do it. I don't use PythonIDE, so I'm not really interested in > tracking it down myself. > > -bob > From bob at redivi.com Tue Apr 5 00:16:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 00:16:33 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <08ed64ad4d448cf0fbdd5e5a4282faaf@mac.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <5555860b2adc91fced5ecdf850bc0247@mac.com> <08ed64ad4d448cf0fbdd5e5a4282faaf@mac.com> Message-ID: <58e025fbfca61bd0b923a6caf49cc514@redivi.com> On Apr 4, 2005, at 16:13, Lee Cullens wrote: > On Apr 4, 2005, at 10:34 AM, Bob Ippolito wrote: > >> >> On Apr 4, 2005, at 10:17, Lee Cullens wrote: >> >>> One thing I noticed with your 2.4.1 build is that in the PythonIDE >>> Help menu "Python Documentation" and "Lookup in Python >>> Documentation" are dimmed out (not available). Such in the 2.3 >>> PythonIDE is still available though. >>> >>> This time I did look in the Mac Python FAQ first, but the suggestion >>> there did not remedy the problem. >> >> I have no idea. If it's broken, it's broken in the source -- I >> didn't do it. I don't use PythonIDE, so I'm not really interested in >> tracking it down myself. >> > Personally I think these little package idiosyncrasies are what > discourage non-hacker users and businesses that might otherwise > advance the use of Python, to the benefit of those that have enough > experience and skills to prepare and maintain a presentable tool - but > we all have a perfect right to our own priorities and outlook. I'm not sure I agree with "advance the use of Python". These sorts of people don't generally contribute much back in my experience. They might have "advanced uses for Python", but probably aren't doing anyone else favors. Nobody is paid to make Python on Mac OS X suitable for new users. Those who are (teachers, etc.) haven't bothered to contribute any patches (recently, anyway) as far as I can tell. Complaining to the tune of "if you don't do this, people won't use Python" isn't going to make anyone do anything. Personally, my top priorities for Python on Mac OS X are to make sure that it works, that I can do everything I want to do with it, and to make sure functionality is available so that people who know what they're doing can get things done. Catering to new users is not a priority of *mine*. Note that there are other people that work on this stuff and might feel differently. > I (so far) am using PythonIDE as a simple higher level (than the > terminal) alternative. IDLE uses cr line endings instead of the Unix > lf which has caused me some annoyances, and though I versonized > wxPython so I could get SPE to run I find it has a way to go yet (at > least on a Mac OS X platform). Neither am I ready yet to invest in > Wing till I get up to speed in this "neighborhood" and I'm watching > where Xcode might go. IDLE's line encoding setting can't be changed? > Anyway, I looked at the two versions (2.3 and 2.4) of the PythonIDE > package and at PytyhonIDEMain.py in particular. There is a self > labeled hack in PytyhonIDEMain.py for building the Help menu (telling > the Help Viewer about the Python documentation) that looks in two > different places. In the 2.3 MacPython version there is an additional > resource that satisfies the search, namely > Contents/Resources/English.lproj. In the 2.4 version that resource is > missing. The other place it looks is in the Python application inside > the framework and I haven't tracked that down yet in the 2.3 version > to see if it is there also, but it is obviously not there in the 2.4 > version. Copying the 2.3 resource into 2.4 would result in 2.3 > documentation for the 2.4 version so such is no solution. > > So somewhere along the line from the Mac 2.3 version to your Mac 2.4 > version the documentation resource was overlooked or dropped for some > other reason. Maybe someone has an idea how I could remedy the > situation (?) and in the meantime I'll continue developing my skills > in this "neighborhood" till I understand enough to solve the issue > without screwing something else up. Unfortunately I'm going to be quite busy for the next week or two, and probably won't be able to research this further. If somebody finds a specific fix, I might be able to do something about it. -bob From lee_cullens at mac.com Tue Apr 5 03:38:52 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 03:39:00 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <58e025fbfca61bd0b923a6caf49cc514@redivi.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <5555860b2adc91fced5ecdf850bc0247@mac.com> <08ed64ad4d448cf0fbdd5e5a4282faaf@mac.com> <58e025fbfca61bd0b923a6caf49cc514@redivi.com> Message-ID: <5689a9a36fbf5f9ca9927b28a38094f4@mac.com> On Apr 4, 2005, at 6:16 PM, Bob Ippolito wrote: > > On Apr 4, 2005, at 16:13, Lee Cullens wrote: > >> On Apr 4, 2005, at 10:34 AM, Bob Ippolito wrote: >> >>> >>> On Apr 4, 2005, at 10:17, Lee Cullens wrote: >>> >>>> One thing I noticed with your 2.4.1 build is that in the PythonIDE >>>> Help menu "Python Documentation" and "Lookup in Python >>>> Documentation" are dimmed out (not available). Such in the 2.3 >>>> PythonIDE is still available though. >>>> >>>> This time I did look in the Mac Python FAQ first, but the >>>> suggestion there did not remedy the problem. >>> >>> I have no idea. If it's broken, it's broken in the source -- I >>> didn't do it. I don't use PythonIDE, so I'm not really interested >>> in tracking it down myself. >>> >> Personally I think these little package idiosyncrasies are what >> discourage non-hacker users and businesses that might otherwise >> advance the use of Python, to the benefit of those that have enough >> experience and skills to prepare and maintain a presentable tool - >> but we all have a perfect right to our own priorities and outlook. > > I'm not sure I agree with "advance the use of Python". These sorts of > people don't generally contribute much back in my experience. They > might have "advanced uses for Python", but probably aren't doing > anyone else favors. Nobody is paid to make Python on Mac OS X > suitable for new users. Those who are (teachers, etc.) haven't > bothered to contribute any patches (recently, anyway) as far as I can > tell. > I'm talking about a little bit wider perspective Bob. It is one thing in the world of the accomplished hacker/artist to be able to use Python to be more productive, where little idiosyncrasies/bugs are easily worked out when needed because one has the skills. It is also understandable in the culture where one is contributing their time and effort mostly freely, to not quite reach a "polished" package because there is just so much one can get done and there is an over abundance of both necessary and interesting issues to deal with (not to mention too few to deal with them). I've been there in a different "neighborhood," but I also took a little bit wider perspective so I could afford to retire and play in a new "neighborhood." I'm talking about the idea that if a software environment never progresses substantially beyond hackerdom (i.e. never gains wide acceptance in the professional and business communities) then few of those that contributed so much to the base will benefit materialistically. That's ok if one is retired like myself or has sufficient other earnings, but the world can be a cruel place for those that end up without much. If a software environment like Python were to gain wide acceptance in the professional and business communities there would be even more opportunities for those with the greatest skills because there will always be new issues like evolving protocals, formats and so on, not to mention the language itself. Just the perspective of a retired software engineer. I can respect your opinion without having to wholeheartedly agree. > Complaining to the tune of "if you don't do this, people won't use > Python" isn't going to make anyone do anything. Personally, my top > priorities for Python on Mac OS X are to make sure that it works, that > I can do everything I want to do with it, and to make sure > functionality is available so that people who know what they're doing > can get things done. Catering to new users is not a priority of > *mine*. Note that there are other people that work on this stuff and > might feel differently. > I'm *not* complaining as you put it and I'm *not* trying to make anyone *do* anything. You misunderstand me. I think what you are doing in making Python easier to use on the Macintosh is admirable, as are the efforts of others I don't yet know well enough to single out. Your (and others) efforts make it that much easier for me to further my own skills on the platform I prefer. Primarily, I noted a small problem with the package (as much for everyone's sake as my own), did some initial problem isolation and asked if *anyone* had any solutions or ideas. If none are forthcoming then when I learn to construct a 2.4 help resource I'll include it in the IDLE bundle and share my solution. >> I (so far) am using PythonIDE as a simple higher level (than the >> terminal) alternative. IDLE uses cr line endings instead of the Unix >> lf which has caused me some annoyances, and though I versonized >> wxPython so I could get SPE to run I find it has a way to go yet (at >> least on a Mac OS X platform). Neither am I ready yet to invest in >> Wing till I get up to speed in this "neighborhood" and I'm watching >> where Xcode might go. > > IDLE's line encoding setting can't be changed? > I've tried several combinations of the IDLE "Options" and still end up with a cr line ending. I'll try again as I would rather use IDLE than PythonIDE and if I'm not successful may eventually "customize" the damn thing unless I've moved on to something I like better. I know I could already pass a script file through a script to change the line endings, but then would have to change back to work with the original script in IDLE again. >> Anyway, I looked at the two versions (2.3 and 2.4) of the PythonIDE >> package and at PytyhonIDEMain.py in particular. There is a self >> labeled hack in PytyhonIDEMain.py for building the Help menu (telling >> the Help Viewer about the Python documentation) that looks in two >> different places. In the 2.3 MacPython version there is an >> additional resource that satisfies the search, namely >> Contents/Resources/English.lproj. In the 2.4 version that resource >> is missing. The other place it looks is in the Python application >> inside the framework and I haven't tracked that down yet in the 2.3 >> version to see if it is there also, but it is obviously not there in >> the 2.4 version. Copying the 2.3 resource into 2.4 would result in >> 2.3 documentation for the 2.4 version so such is no solution. >> >> So somewhere along the line from the Mac 2.3 version to your Mac 2.4 >> version the documentation resource was overlooked or dropped for some >> other reason. Maybe someone has an idea how I could remedy the >> situation (?) and in the meantime I'll continue developing my skills >> in this "neighborhood" till I understand enough to solve the issue >> without screwing something else up. > > Unfortunately I'm going to be quite busy for the next week or two, and > probably won't be able to research this further. If somebody finds a > specific fix, I might be able to do something about it. > Fair enough. > -bob > Thanks for your thoughts, Lee C From charles.hartman at conncoll.edu Tue Apr 5 04:12:07 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Apr 5 04:12:16 2005 Subject: [Pythonmac-SIG] new Python & wxPython Message-ID: <1027346e610a419642d2b933e6776a61@conncoll.edu> Probably everybody else knows this already, but I'll mention that under OS 10.3.8 I'm now happily running Python 2.4.1 with wxPython 2.5.4.1. (I had a hard time getting wxPython built -- wouldn't have gotten it at all without lots of help from Robin Dunn -- but anyone who knew what he or she was doing wouldn't have any trouble.) The two *seem* to be playing perfectly happily together. Charles Hartman Professor of English, Poet in Residence http://cherry.conncoll.edu/cohar http://villex.blogspot.com From bob at redivi.com Tue Apr 5 04:16:46 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 04:17:01 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <5689a9a36fbf5f9ca9927b28a38094f4@mac.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <5555860b2adc91fced5ecdf850bc0247@mac.com> <08ed64ad4d448cf0fbdd5e5a4282faaf@mac.com> <58e025fbfca61bd0b923a6caf49cc514@redivi.com> <5689a9a36fbf5f9ca9927b28a38094f4@mac.com> Message-ID: <240cf03b77ffb4b178faefbdc75d643d@redivi.com> On Apr 4, 2005, at 9:38 PM, Lee Cullens wrote: > > On Apr 4, 2005, at 6:16 PM, Bob Ippolito wrote: > >> >> On Apr 4, 2005, at 16:13, Lee Cullens wrote: >> >>> On Apr 4, 2005, at 10:34 AM, Bob Ippolito wrote: >>> >>>> >>>> On Apr 4, 2005, at 10:17, Lee Cullens wrote: >>>> >>>>> One thing I noticed with your 2.4.1 build is that in the PythonIDE >>>>> Help menu "Python Documentation" and "Lookup in Python >>>>> Documentation" are dimmed out (not available). Such in the 2.3 >>>>> PythonIDE is still available though. >>>>> >>>>> This time I did look in the Mac Python FAQ first, but the >>>>> suggestion there did not remedy the problem. >>>> >>>> I have no idea. If it's broken, it's broken in the source -- I >>>> didn't do it. I don't use PythonIDE, so I'm not really interested >>>> in tracking it down myself. >>>> >>> Personally I think these little package idiosyncrasies are what >>> discourage non-hacker users and businesses that might otherwise >>> advance the use of Python, to the benefit of those that have enough >>> experience and skills to prepare and maintain a presentable tool - >>> but we all have a perfect right to our own priorities and outlook. >> >> I'm not sure I agree with "advance the use of Python". These sorts >> of people don't generally contribute much back in my experience. >> They might have "advanced uses for Python", but probably aren't doing >> anyone else favors. Nobody is paid to make Python on Mac OS X >> suitable for new users. Those who are (teachers, etc.) haven't >> bothered to contribute any patches (recently, anyway) as far as I can >> tell. >> > > I'm talking about a little bit wider perspective Bob. It is one thing > in the world of the accomplished hacker/artist to be able to use > Python to be more productive, where little idiosyncrasies/bugs are > easily worked out when needed because one has the skills. It is also > understandable in the culture where one is contributing their time and > effort mostly freely, to not quite reach a "polished" package because > there is just so much one can get done and there is an over abundance > of both necessary and interesting issues to deal with (not to mention > too few to deal with them). I've been there in a different > "neighborhood," but I also took a little bit wider perspective so I > could afford to retire and play in a new "neighborhood." Unfortunately there are quite a few hard problems to solve "under the iceberg" before I think it's worth polishing it on Mac OS X for new users. Most importantly, building standalone applications has to work correctly (py2app), there has to be an easy way to find and use third party stuff (PyPI, PythonEggs, bdist_mpkg, MacEnthon, ...), good frameworks for various application domains need to exist (PyObjC, wxPython, Twisted, SciPy, PEAK, ...), and there needs to be an IDE that has the right design. It's definitely well on its way there, and there has been a lot of activity in these areas recently (except the IDE front, on OS X anyway). All of the IDEs I've played with have real architectural issues, except for IDLE and Wing. IDLE at least can run and debug external processes, which is absolutely necessary in order to have an IDE that works right, but it suffers from Tkinter heritage and other cruft. Wing is commercial, but as far as I can tell, they have solved the hard problems (except making it nice on OS X, of course). I haven't tried SPE. PythonIDE is basically unstable buggy crufty ancient code that I wouldn't personally touch with a 10 foot pole. It has no syntax highlighting, all of the debugging/interpreters are run in-process, etc. > I'm talking about the idea that if a software environment never > progresses substantially beyond hackerdom (i.e. never gains wide > acceptance in the professional and business communities) then few of > those that contributed so much to the base will benefit > materialistically. That's ok if one is retired like myself or has > sufficient other earnings, but the world can be a cruel place for > those that end up without much. If a software environment like Python > were to gain wide acceptance in the professional and business > communities there would be even more opportunities for those with the > greatest skills because there will always be new issues like evolving > protocals, formats and so on, not to mention the language itself. > > Just the perspective of a retired software engineer. I can respect > your opinion without having to wholeheartedly agree. Well, Python as a language is already widely accepted enough that it can be used in many professional environments (i.e. Google). Personally I'm not convinced that popularizing the language is going to make anyone rich. Consumers buy the stuff you write in Python, and use the services that are powered by Python. The only people that should care about Python are the people making the stuff, and only because it was the best tool for the job. Of course, you could make money if your consumers are developers, and you're writing commercial developer tools for Python, but developers have never really been a huge market and there's a lot to compete with (Wing, Eclipse, Emacs, Vim, ... and I expect that Visual Studio.NET and Xcode will grow Python support in the next two or three years). Not even mentioning the other programming languages. -bob From bob at redivi.com Tue Apr 5 04:20:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 04:20:30 2005 Subject: [Pythonmac-SIG] new Python & wxPython In-Reply-To: <1027346e610a419642d2b933e6776a61@conncoll.edu> References: <1027346e610a419642d2b933e6776a61@conncoll.edu> Message-ID: <11de0f43114e015acef21c941b70252d@redivi.com> On Apr 4, 2005, at 10:12 PM, Charles Hartman wrote: > Probably everybody else knows this already, but I'll mention that > under OS 10.3.8 I'm now happily running Python 2.4.1 with wxPython > 2.5.4.1. (I had a hard time getting wxPython built -- wouldn't have > gotten it at all without lots of help from Robin Dunn -- but anyone > who knew what he or she was doing wouldn't have any trouble.) The two > *seem* to be playing perfectly happily together. I'd love to see a binary distribution for this. Building wxWidgets/wxPython is painful and slow. I build a lot of stuff, but wxPython is something I'd rather have someone else deal with.. Hopefully the Python 2.4.1 distribution I put out is enough of a catalyst to get their wheels turning :) -bob From charles.hartman at conncoll.edu Tue Apr 5 04:29:51 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Apr 5 04:29:58 2005 Subject: [Pythonmac-SIG] new Python & wxPython In-Reply-To: <11de0f43114e015acef21c941b70252d@redivi.com> References: <1027346e610a419642d2b933e6776a61@conncoll.edu> <11de0f43114e015acef21c941b70252d@redivi.com> Message-ID: If I thought I knew enough to do it properly I'd do it happily. I like the combination very much, and I certainly agree it would be nice if it were easier to put together. Of course, Robin D does put together .dmg binaries from time to time; there just isn't one yet for wxPython 2.5.4. I don't know how to do it in a way that allows for the variations (unicode or not, replacing an old installation or not . . . trust me, everybody will be happier if I don't undertake this. Charles Hartman On Apr 4, 2005, at 10:20 PM, Bob Ippolito wrote: > > On Apr 4, 2005, at 10:12 PM, Charles Hartman wrote: > >> Probably everybody else knows this already, but I'll mention that >> under OS 10.3.8 I'm now happily running Python 2.4.1 with wxPython >> 2.5.4.1. (I had a hard time getting wxPython built -- wouldn't have >> gotten it at all without lots of help from Robin Dunn -- but anyone >> who knew what he or she was doing wouldn't have any trouble.) The two >> *seem* to be playing perfectly happily together. > > I'd love to see a binary distribution for this. Building > wxWidgets/wxPython is painful and slow. I build a lot of stuff, but > wxPython is something I'd rather have someone else deal with.. > > Hopefully the Python 2.4.1 distribution I put out is enough of a > catalyst to get their wheels turning :) > > -bob > From bob at redivi.com Tue Apr 5 04:42:25 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 04:42:31 2005 Subject: [Pythonmac-SIG] new Python & wxPython In-Reply-To: References: <1027346e610a419642d2b933e6776a61@conncoll.edu> <11de0f43114e015acef21c941b70252d@redivi.com> Message-ID: <6e5a342faf8bda4fc2d267862a8e8384@redivi.com> On Apr 4, 2005, at 10:29 PM, Charles Hartman wrote: > On Apr 4, 2005, at 10:20 PM, Bob Ippolito wrote: > >> >> On Apr 4, 2005, at 10:12 PM, Charles Hartman wrote: >> >>> Probably everybody else knows this already, but I'll mention that >>> under OS 10.3.8 I'm now happily running Python 2.4.1 with wxPython >>> 2.5.4.1. (I had a hard time getting wxPython built -- wouldn't have >>> gotten it at all without lots of help from Robin Dunn -- but anyone >>> who knew what he or she was doing wouldn't have any trouble.) The >>> two *seem* to be playing perfectly happily together. >> >> I'd love to see a binary distribution for this. Building >> wxWidgets/wxPython is painful and slow. I build a lot of stuff, but >> wxPython is something I'd rather have someone else deal with.. >> >> Hopefully the Python 2.4.1 distribution I put out is enough of a >> catalyst to get their wheels turning :) >> > If I thought I knew enough to do it properly I'd do it happily. I like > the combination very much, and I certainly agree it would be nice if > it were easier to put together. Of course, Robin D does put together > .dmg binaries from time to time; there just isn't one yet for wxPython > 2.5.4. I don't know how to do it in a way that allows for the > variations (unicode or not, replacing an old installation or not . . . > trust me, everybody will be happier if I don't undertake this. Having a non-unicode build seems pretty stupid to me. I think the only reason it's there is because Jaguar doesn't ship with all the necessary libraries, but I don't see why they can't just pull them from elsewhere and link them in. Unlike Windows, Mac OS X doesn't have separate ansi and unicode functions for everything. Some of the crusty old deprecated APIs take pascal strings in the system encoding (macroman, probably), but those aren't worth using. -bob From juntunen at well.com Tue Apr 5 04:45:41 2005 From: juntunen at well.com (Thomas Juntunen) Date: Tue Apr 5 04:45:47 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <5689a9a36fbf5f9ca9927b28a38094f4@mac.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/05, Lee Cullens imposed order on a stream of electrons to say: > Personally I think these little package idiosyncrasies are what > discourage non-hacker users and businesses that might otherwise > advance the use of Python, to the benefit of those that have enough > experience and skills to prepare and maintain a presentable tool - > but we all have a perfect right to our own priorities and outlook. You may be interested in this article: http://programming.newsforge.com/article.pl?sid=05/03/29/0747230 Cameron Laird writes: "So what was the bottom line from the PyCON 2005 conference, held here last week? Python is an open-source technology whose use in enterprise IT operations will only grow for the foreseeable future. Mission-critical development organizations often regard only a handful of languages -- C#, Java, XML, SQL, and few others -- as safe enough for serious projects. From this perspective, Python has been traditionally lumped with "experimental" or "toy" languages. Over and over, however, speakers at this conference presented evidence to the contrary." Here's what Laird says about Python's increasing popularity in the enterprise: "On the whole, however, Python looks more and more like a "safe choice": It's taught in classrooms, budgeted and used in large organizations worldwide, and appears to attract successful enthusiasts. The time looks ripe for a language that has always emphasized its ability to "play nicely" with other technologies on a full range of platforms." Now that companies such as Google, ESRI and Nokia advocate Python use, perhaps some serious resources will be put into polishing Python and its tools. Thomas Juntunen -----BEGIN PGP SIGNATURE----- Version: PGP SDK 3.2.2 iQA/AwUBQlHtwtFoei/9T3YdEQL9IACcCsrR7yohroUiCbgVYqotKnJ7u6YAn1fZ 4oHYTEZjIzXjJrOyH3mr/mo8 =9DtV -----END PGP SIGNATURE----- From lee_cullens at mac.com Tue Apr 5 04:50:28 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 04:50:35 2005 Subject: [Pythonmac-SIG] new Python & wxPython In-Reply-To: <11de0f43114e015acef21c941b70252d@redivi.com> References: <1027346e610a419642d2b933e6776a61@conncoll.edu> <11de0f43114e015acef21c941b70252d@redivi.com> Message-ID: <596000717d1d2058beaa6ccaf30807ba@mac.com> I had the wxPython 2.5.3.1 binary in /Applications/Python-2.3/Extras/wxPythonExtras and when I installed Bob's new 2.4 Python I downloaded the new 2.5.4.1 wxPython binary and installed it in /Applications/Python-2.4/Extras/wxPythonExtras. With what little I've done with it yet the setup seems to work. If I'm working in my home project area, I set the wx.pth to the version I want to be sure (I've only set it to the older version when I was checking out SPE). Lee C On Apr 4, 2005, at 10:20 PM, Bob Ippolito wrote: > > On Apr 4, 2005, at 10:12 PM, Charles Hartman wrote: > >> Probably everybody else knows this already, but I'll mention that >> under OS 10.3.8 I'm now happily running Python 2.4.1 with wxPython >> 2.5.4.1. (I had a hard time getting wxPython built -- wouldn't have >> gotten it at all without lots of help from Robin Dunn -- but anyone >> who knew what he or she was doing wouldn't have any trouble.) The two >> *seem* to be playing perfectly happily together. > > I'd love to see a binary distribution for this. Building > wxWidgets/wxPython is painful and slow. I build a lot of stuff, but > wxPython is something I'd rather have someone else deal with.. > > Hopefully the Python 2.4.1 distribution I put out is enough of a > catalyst to get their wheels turning :) > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From lee_cullens at mac.com Tue Apr 5 05:00:39 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 05:00:47 2005 Subject: [Pythonmac-SIG] new Python & wxPython In-Reply-To: <596000717d1d2058beaa6ccaf30807ba@mac.com> References: <1027346e610a419642d2b933e6776a61@conncoll.edu> <11de0f43114e015acef21c941b70252d@redivi.com> <596000717d1d2058beaa6ccaf30807ba@mac.com> Message-ID: Forgot to mention I installed both the ansi and unicode binaries of each (because didn't know what I needed) and all four play well so far. On Apr 4, 2005, at 10:50 PM, Lee Cullens wrote: > I had the wxPython 2.5.3.1 binary in > /Applications/Python-2.3/Extras/wxPythonExtras and when I installed > Bob's new 2.4 Python I downloaded the new 2.5.4.1 wxPython binary and > installed it in /Applications/Python-2.4/Extras/wxPythonExtras. > > With what little I've done with it yet the setup seems to work. If > I'm working in my home project area, I set the wx.pth to the version I > want to be sure (I've only set it to the older version when I was > checking out SPE). > > Lee C > > > On Apr 4, 2005, at 10:20 PM, Bob Ippolito wrote: > >> >> On Apr 4, 2005, at 10:12 PM, Charles Hartman wrote: >> >>> Probably everybody else knows this already, but I'll mention that >>> under OS 10.3.8 I'm now happily running Python 2.4.1 with wxPython >>> 2.5.4.1. (I had a hard time getting wxPython built -- wouldn't have >>> gotten it at all without lots of help from Robin Dunn -- but anyone >>> who knew what he or she was doing wouldn't have any trouble.) The >>> two *seem* to be playing perfectly happily together. >> >> I'd love to see a binary distribution for this. Building >> wxWidgets/wxPython is painful and slow. I build a lot of stuff, but >> wxPython is something I'd rather have someone else deal with.. >> >> Hopefully the Python 2.4.1 distribution I put out is enough of a >> catalyst to get their wheels turning :) >> >> -bob >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Tue Apr 5 05:19:19 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 05:19:25 2005 Subject: [Pythonmac-SIG] new Python & wxPython In-Reply-To: References: <1027346e610a419642d2b933e6776a61@conncoll.edu> <11de0f43114e015acef21c941b70252d@redivi.com> <596000717d1d2058beaa6ccaf30807ba@mac.com> Message-ID: <1b9aa58ed9477b193eb4d9870f306702@redivi.com> On Apr 4, 2005, at 11:00 PM, Lee Cullens wrote: > On Apr 4, 2005, at 10:50 PM, Lee Cullens wrote: > >> On Apr 4, 2005, at 10:20 PM, Bob Ippolito wrote: >> >>> >>> On Apr 4, 2005, at 10:12 PM, Charles Hartman wrote: >>> >>>> Probably everybody else knows this already, but I'll mention that >>>> under OS 10.3.8 I'm now happily running Python 2.4.1 with wxPython >>>> 2.5.4.1. (I had a hard time getting wxPython built -- wouldn't have >>>> gotten it at all without lots of help from Robin Dunn -- but anyone >>>> who knew what he or she was doing wouldn't have any trouble.) The >>>> two *seem* to be playing perfectly happily together. >>> >>> I'd love to see a binary distribution for this. Building >>> wxWidgets/wxPython is painful and slow. I build a lot of stuff, but >>> wxPython is something I'd rather have someone else deal with.. >>> >>> Hopefully the Python 2.4.1 distribution I put out is enough of a >>> catalyst to get their wheels turning :) >>> >> I had the wxPython 2.5.3.1 binary in >> /Applications/Python-2.3/Extras/wxPythonExtras and when I installed >> Bob's new 2.4 Python I downloaded the new 2.5.4.1 wxPython binary and >> installed it in /Applications/Python-2.4/Extras/wxPythonExtras. The /Applications/MacPython-2.4 folder is in no way special. If wxPython works, you're not using the Python 2.4.1 interpreter. Those binary distributions were built for Python 2.3 and *will not* work with Python 2.4, even if they were in the right place. >> With what little I've done with it yet the setup seems to work. If >> I'm working in my home project area, I set the wx.pth to the version >> I want to be sure (I've only set it to the older version when I was >> checking out SPE). >> > Forgot to mention I installed both the ansi and unicode binaries of > each (because didn't know what I needed) and all four play well so > far. The Jaguar builds won't be used by anything you have installed. As for the Panther builds, whichever one you installed last, wins.. but only for Python 2.3. -bob From lee_cullens at mac.com Tue Apr 5 05:22:07 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 05:22:12 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: References: Message-ID: <56ea35eb0fba350a2f9fba50c0aab6a6@mac.com> Thomas, Thanks, that is an interesting article. I sent it along to a corporate client I do occasional work for (paid for my G5 playground). I'm apprehensive about Microsoft involvement though because they can muddy up the waters badly with their excessive greed. Just like I'd be apprehensive about Macromedia adopting Blender, though they are probably not smart enough :~) Lee C "God save us from those that would save us." -- Laura Cullens c1945 On Apr 4, 2005, at 10:45 PM, Thomas Juntunen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/04/05, Lee Cullens imposed order on a stream of electrons to say: > >> Personally I think these little package idiosyncrasies are what >> discourage non-hacker users and businesses that might otherwise >> advance the use of Python, to the benefit of those that have enough >> experience and skills to prepare and maintain a presentable tool - >> but we all have a perfect right to our own priorities and outlook. > > > You may be interested in this article: > http://programming.newsforge.com/article.pl?sid=05/03/29/0747230 > > Thomas Juntunen From sw at wordtech-software.com Tue Apr 5 05:46:19 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue Apr 5 05:46:27 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens Message-ID: <42520A0B.5060106@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lee, If the code to actually look for the Python documentation is already in PythonIDE (even as a hack), then it sounds like the only thing that's missing is the documentation itself. Someone prepared an Apple Help Book of the Python2.3 docs that could be installed with the old Package Manager. It sounds like no one has done this for 2.4.1. Doing this, though, isn't hard. See this URL for info on ~ packaging a help book: http://developer.apple.com/documentation/Carbon/Conceptual/ProvidingUserAssitAppleHelp/user_help_intro/chapter_1_section_1.html Basically, you need to add some tags to the index page, run Apple's help indexing tool over the help directory, and put it in the right place in the app bundle. I've packaged Apple Help for some of my apps (none for Python) and it's a pretty basic process. I'd take a whack at doing this myself, but I'm not installing 2.4.1 for now--stuff I maintain depends on the Apple-provided Python. Hope this helps. - -- 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 iD8DBQFCUgoJJmdQs+6YVcoRAifBAKCMC57My2ILtKsaEyD6unN1Sgfp5ACfXAEW JwyuZ0VoAnAikq68NflqvnQ= =DXAx -----END PGP SIGNATURE----- From lee_cullens at mac.com Tue Apr 5 05:49:16 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 05:49:20 2005 Subject: [Pythonmac-SIG] new Python & wxPython In-Reply-To: <1b9aa58ed9477b193eb4d9870f306702@redivi.com> References: <1027346e610a419642d2b933e6776a61@conncoll.edu> <11de0f43114e015acef21c941b70252d@redivi.com> <596000717d1d2058beaa6ccaf30807ba@mac.com> <1b9aa58ed9477b193eb4d9870f306702@redivi.com> Message-ID: <615c5c98c089cf549f50c2bc7c6b4205@mac.com> Bob, Thanks for clarifying the point before I had an issue with such. Thought I tried this before but I just tried to import wxPython from 2.3 and 2. 4 and such only worked in 2.3 %) So, I'll just move the 2.5.4.1 binaries I downloaded over to 2.3 also. You saved me some more head banging. Thanks again, Lee C From lee_cullens at mac.com Tue Apr 5 06:09:37 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 06:09:42 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: <42520A0B.5060106@wordtech-software.com> References: <42520A0B.5060106@wordtech-software.com> Message-ID: <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> On Apr 4, 2005, at 11:46 PM, Kevin Walzer wrote: > Lee, > > If the code to actually look for the Python documentation is already in > PythonIDE (even as a hack), then it sounds like the only thing that's > missing is the documentation itself. > That is what I tried to say and I'm glad you understood it. > Someone prepared an Apple Help Book of the Python2.3 docs that could be > installed with the old Package Manager. It sounds like no one has done > this for 2.4.1. Doing this, though, isn't hard. See this URL for info > on > ~ packaging a help book: > > http://developer.apple.com/documentation/Carbon/Conceptual/ > ProvidingUserAssitAppleHelp/user_help_intro/chapter_1_section_1.html > > Basically, you need to add some tags to the index page, run Apple's > help > indexing tool over the help directory, and put it in the right place in > the app bundle. I've packaged Apple Help for some of my apps (none for > Python) and it's a pretty basic process. > > I'd take a whack at doing this myself, but I'm not installing 2.4.1 for > now--stuff I maintain depends on the Apple-provided Python. > > Hope this helps. > It sure does! I was just rummaging around ADC trying to see if I could figure out how to do it - that and if I can just drop the result in the IDLE app package (I am new to Mac if you hadn't guessed). I try not to get too far off on a tangent, but little things like this are good learning exercises and you have shortened the time it will take me to get through it. Many thanks Kevin, Lee C > - -- > 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 From rogerb at rogerbinns.com Tue Apr 5 07:03:34 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Tue Apr 5 07:03:37 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens References: <42520A0B.5060106@wordtech-software.com> Message-ID: <003401c5399c$d1f0fc80$3501a8c0@rogersqyvr14d3> > http://developer.apple.com/documentation/Carbon/Conceptual/ProvidingUserAssitAppleHelp/user_help_intro/chapter_1_section_1.html > > Basically, you need to add some tags to the index page, run Apple's help > indexing tool over the help directory, and put it in the right place in > the app bundle. I've packaged Apple Help for some of my apps (none for > Python) and it's a pretty basic process. I have tried that in many different ways and it never worked for me. I can get the help to appear etc but the searching never works. In the end I gave up. My help is actually authored in HelpBlocks (written by the original author of wxWidgets) and in the end I have it as HTML in a zip file. Roger From janssen at parc.com Tue Apr 5 07:34:26 2005 From: janssen at parc.com (Bill Janssen) Date: Tue Apr 5 07:34:53 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: Your message of "Mon, 04 Apr 2005 19:45:41 PDT." Message-ID: <05Apr4.223434pdt."58617"@synergy1.parc.xerox.com> > You may be interested in this article: > http://programming.newsforge.com/article.pl?sid=05/03/29/0747230 > > Cameron Laird writes: It's worth noting that Cameron Laird (who I'm sure is a perfectly nice guy) is an old-time Python fan already (as am I); take his pronouncements with a grain of salt. I love Python, and use it whenever I can, but I can tell you that the state of Python's libraries is problematic; there's highly polished code to deal with comma-separated values, but no parser for XML 1.1 (as of the end of the year). I was shocked to find that the client-side http library has no support for posting multipart documents, and no support for timeouts or server-side SSL support. And so on and so forth. Python has these holes for lots of things that are in the standard Java and Perl libraries. And what's in the standard library is hard to understand; there's no consistent editorial style across the library documentation, so it varies wildly from one module to the next. Things are being addressed, but piecemeal and haphazardly. Apparently no one is in charge of designing and building the standard library. That seems (to me) a major problem with the language as a whole. That combines with the problem that I have to shift to Java or Jython (thank God for Jim Hugunin and his successors) to get a reasonable portable UI toolkit (sorry, wxWindows isn't good enough). Bob's Cocoa work would be good enough, but it isn't portable. Bill From bob at redivi.com Tue Apr 5 07:55:47 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 07:55:54 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <05Apr4.223434pdt."58617"@synergy1.parc.xerox.com> References: <05Apr4.223434pdt."58617"@synergy1.parc.xerox.com> Message-ID: <4c0adb248aab971915dacc75a7bfb557@redivi.com> On Apr 5, 2005, at 1:34 AM, Bill Janssen wrote: >> You may be interested in this article: >> http://programming.newsforge.com/article.pl?sid=05/03/29/0747230 >> >> Cameron Laird writes: > > It's worth noting that Cameron Laird (who I'm sure is a perfectly nice > guy) is an old-time Python fan already (as am I); take his > pronouncements with a grain of salt. > > I love Python, and use it whenever I can, but I can tell you that the > state of Python's libraries is problematic; there's highly polished > code to deal with comma-separated values, but no parser for XML 1.1 > (as of the end of the year). I was shocked to find that the > client-side http library has no support for posting multipart > documents, and no support for timeouts or server-side SSL support. > And so on and so forth. Python has these holes for lots of things > that are in the standard Java and Perl libraries. And what's in the > standard library is hard to understand; there's no consistent > editorial style across the library documentation, so it varies wildly > from one module to the next. Highly polished code to handle comma-separated values my ass, it can't even do unicode. I ended up writing my own CSV parser. Though, for the most part, I parse the excel documents directly with jxl.jar (a java tool, which I can just use from the command line as-is), and then parse the XML it spits out. Perl doesn't really have any standard libraries. When you get Perl, you get the core plus CPAN. Everything else lives elsewhere. Perl doesn't even ship with enough stuff to use CPAN natively, it has to defer stuff to whatever command line tools it can find. Python doesn't have the infrastructure to work like this, but it's coming -- and it will be good. Smart people are working on solving these issues, and we can learn from the mistakes made with CPAN, PEAR, etc. If you want networking support, use Twisted, it can do all the things you're complaining about. If you want XML 1.1 support, I'm sure you can get that outside of the stdlib, using libxml2 bindings at worst case (don't know if ElementTree or the like supports 1.1, I haven't kept up much with XML). > Things are being addressed, but piecemeal and haphazardly. Apparently > no one is in charge of designing and building the standard library. > That seems (to me) a major problem with the language as a whole. I agree, the standard library is a real mess. All of the interesting advancements are happening elsewhere. Fortunately or unfortunately python-dev is largely interested in Python-the-language, not Python-the-environment. Though, the interesting and extremely useful stuff from the outside (if it's simple enough) usually ends up in the stdlib, eventually. > That combines with the problem that I have to shift to Java or Jython > (thank God for Jim Hugunin and his successors) to get a reasonable > portable UI toolkit (sorry, wxWindows isn't good enough). Bob's Cocoa > work would be good enough, but it isn't portable. Well if someone puts in the effort to finish the GNUStep support in PyObjC, you'd be able to target that and Cocoa without too much platform-specific code (assuming you use Renaissance or something, rather than Interface Builder). I'm not sure what the state of GNUStep itself is, though... -bob From lee_cullens at mac.com Tue Apr 5 08:26:39 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 08:26:48 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: <42521BB5.6090608@ucsd.edu> References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> <42521BB5.6090608@ucsd.edu> Message-ID: On Apr 5, 2005, at 1:01 AM, Robert Kern wrote: > Lee Cullens wrote: > >> I try not to get too far off on a tangent, but little things like >> this are good learning exercises and you have shortened the time it >> will take me to get through it. > > Allow me to shorten it further: > > Look in Mac/OSX/Doc of the source distribution. > Thanks Robert - you mean SorceForge I assume but I can't seem to find what you mean. I was going to download the HTML version of the 2.4 docs from the Python site. I was just starting to study what Kevin pointed me at and it looks like there is more than enough info to get the job done. Now if anyone knew how to change the line ending char in IDLE from cr to lf (as a selectable option) you would save me having no option but to hack the code :~) I can't believe it's not an option, but I can't discover it. Under the Options Keys tab there is a selection for IDLE Classic Mac, Unix and Windows, but that seems to be just for the shortcut keys, and of course the Help therein does not work. I think Bob is right in that PythonIDE won't last me very long in my learning cycle, but IDLE seems just a WIP. A (part time) corporate client is studying using Python more and is getting frustrated. It could mean more work for me, but I don't want or need it. I'm close to the point of just getting Wing and getting on with the software projects I want to do. All your thoughtful replies have been very much appreciated, Lee C > -- > 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 rkern at ucsd.edu Tue Apr 5 08:40:16 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue Apr 5 08:40:31 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> <42521BB5.6090608@ucsd.edu> Message-ID: <425232D0.1060008@ucsd.edu> Lee Cullens wrote: > > On Apr 5, 2005, at 1:01 AM, Robert Kern wrote: > >> Lee Cullens wrote: >> >>> I try not to get too far off on a tangent, but little things like >>> this are good learning exercises and you have shortened the time it >>> will take me to get through it. >> >> >> Allow me to shorten it further: >> >> Look in Mac/OSX/Doc of the source distribution. >> > Thanks Robert - you mean SorceForge I assume but I can't seem to find > what you mean. I was going to download the HTML version of the 2.4 docs > from the Python site. No, I mean the source code tarball. http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2 -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Tue Apr 5 08:42:25 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 08:42:29 2005 Subject: [Pythonmac-SIG] MySQL-python build instructions Message-ID: I've built MySQL-python, go fetch it from http://pythonmac.org/packages/ Note that it fails three of the tests it ships with, I don't know why, and I don't really care. I've never trusted MySQL-python, for reasons like this, but people seem to use it anyway. If you need/want to build it yourself: - Install egenix-mx-base - Get the installer from mysql.com - Install MySQL - Do the following (because the setup.py in MySQL-python is dumb):: cd /usr/local/mysql/include sudo ln -s . mysql cd /usr/local/mysql/lib sudo ln -s . mysql - Invoke setup.py like this: env PATH=/usr/local/mysql/bin:$PATH sudo python setup.py install That should work. -bob From Jonathan.Peirce at nottingham.ac.uk Tue Apr 5 12:09:14 2005 From: Jonathan.Peirce at nottingham.ac.uk (Jonathan Peirce) Date: Tue Apr 5 12:09:25 2005 Subject: [Pythonmac-SIG] bdist_mpkg with C sources Message-ID: <4410b98492e85f90b2c31179438982ab@psychology.nottingham.ac.uk> I'm wanting to make a mac installer for a python library I maintain that contains some C extensions and I'm not clear how to go about it since setup for bdist_mpkg doesn't accept ext_module. Does anyone have a simple-ish example of how to do this? Or will it be that bdist_mpkg will one day just act like the regular distutils bdist? Obviously ideally I would like not to have a separate setup.py for each platform I support - would be much nicer to have a single script like the one below (which does successfully build a mac binary distribution using bdist, just not the double-clickable installer) Thanks for any help, Jon --------- #!/usr/bin/env pythonw from distutils.core import setup, Extension import os from sys import platform local_path = 'psychopy' if platform=='darwin': package_data_path='/Library/Python/2.3/psychopy' else: package_data_path=os.path.join('lib','site-packages','psychopy') import psychopy #define the C extensions and platform-specific imports cExtensions = [] if platform=='win32': cExtensions.append(Extension('psychopy.ext._win32', sources = [os.path.join(local_path,'ext','_win32.c')], library_dirs=[os.path.join(local_path,'ext')])) elif platform=='darwin': import py2app, bdist_mpkg cExtensions.append(Extension('psychopy.ext._darwin', sources = [os.path.join(local_path,'ext','_darwin.m')], extra_link_args=['-framework','OpenGL'])) #run the setup script setup(name="PsychoPy", version = psychopy.__version__, description = "Psychophysics toolkit for Python", author= psychopy.__author__, author_email= psychopy.__author_email__, url="http://www.psychopy.org/", packages=['psychopy','psychopy.ext','psychopy.demos','monitors'], ext_modules = cExtensions, data_files= [(package_data_path, [ os.path.join(local_path,'LICENSE.txt'), os.path.join(local_path,'CHANGELOG.txt'), os.path.join(local_path,'README.txt')]), (os.path.join(package_data_path,'demos'), [ os.path.join(local_path,'demos','face.jpg')]) ] ) This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4390 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050405/65876bc9/attachment.bin From lee_cullens at mac.com Tue Apr 5 14:20:02 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 14:20:07 2005 Subject: [Pythonmac-SIG] RE: What is a good working environment? Message-ID: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> What is a good working environment? All of what Bob did for us is nice for exploring changes in 2.4 but is still too much of a WIP. I (as many of you) need to get on with some development work though and was wondering what basis to work from. Mostly what I will be doing is prototyping components of larger systems (and then maybe convincing them they can't do it any better than with Python :)), and multimedia presentations (beyond Director) that include animation (2d and 3D) and reinforcing gaming (word puzzels, image puzzles, and combinations). What I want to do for myself I'm content with doing only for Mac OS X (10.3.8+) and may deliver some via the web. However, what little I do for corporate clients anymore (don't want to get bogged down in work work) they still seem to want for MS Windows :( dislike that platform). Anyway, since all the components aren't there yet for Python 2.4 (and what are seem to be less than production quality), I'm assuming that at least 2.3 is solid enough (relatively speaking :). At least all the components are there (with the caveat of what was recently discussed regarding overall coordination and quality control). I'm also assuming that with the state of Python, Tiger will probably not go beyond 2.3 (not asking you to make any frowned upon predictions). So to look as well as possible on the Mac I should use what graphics components? Then for MS Windows candidates (cross-platform) I should use wxPython for graphics components? I *have* been perusing the components list (http://pythonmac.org/packages/) and brief descriptions, but only a limited amount of the detailed documentation so far. One point about the component list - I should use only the component versions flagged for py2.3 if such is to be my production platform? (Dumb questions sometimes yield surprising answers) Another very novice question - for the MS Windows executables do I need to transfer my script packages to my clunky old PC and construct such there, or can py2exe construct such on my Mac? Thank you for your thoughts, Lee C From hengist.podd at virgin.net Tue Apr 5 15:59:37 2005 From: hengist.podd at virgin.net (has) Date: Tue Apr 5 15:59:43 2005 Subject: [Pythonmac-SIG] application scripting info on pythonmac.org wiki Message-ID: Hi all, I've extended the appscript entry on the pythonmac.org wiki to provide appscript users with a place to post tips, tricks, example scripts, links, etc. on scripting individual applications with Python+appscript: http://pythonmac.org/wiki/AppscriptModule Not much there yet, obviously, but hopefully over time it'll grow into an important and valuable resource for application scripters. Please contribute! has -- http://freespace.virgin.net/hamish.sanderson/ From rkern at ucsd.edu Tue Apr 5 18:56:09 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue Apr 5 18:56:15 2005 Subject: [Pythonmac-SIG] bdist_mpkg with C sources In-Reply-To: <4410b98492e85f90b2c31179438982ab@psychology.nottingham.ac.uk> References: <4410b98492e85f90b2c31179438982ab@psychology.nottingham.ac.uk> Message-ID: <4252C329.10900@ucsd.edu> Jonathan Peirce wrote: > I'm wanting to make a mac installer for a python library I maintain that > contains some C extensions and I'm not clear how to go about it since > setup for bdist_mpkg doesn't accept ext_module. > > Does anyone have a simple-ish example of how to do this? Or will it be > that bdist_mpkg will one day just act like the regular distutils bdist? > Obviously ideally I would like not to have a separate setup.py for each > platform I support - would be much nicer to have a single script like > the one below (which does successfully build a mac binary distribution > using bdist, just not the double-clickable installer) I have built upwards of 40-ish packages with extension modules and packaged them with bdist_mpkg. I have found no such problem. Can you describe the actual problem that you are seeing in more detail? -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Tue Apr 5 20:13:51 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 20:13:57 2005 Subject: [Pythonmac-SIG] RE: What is a good working environment? In-Reply-To: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> References: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> Message-ID: On Apr 5, 2005, at 8:20 AM, Lee Cullens wrote: > What is a good working environment? > > All of what Bob did for us is nice for exploring changes in 2.4 but is > still too much of a WIP. I (as many of you) need to get on with some > development work though and was wondering what basis to work from. No, it's not a WIP. Python 2.4.1 is perfectly stable (FAR more so than 2.3.0, actually). Except for packages that I don't package myself, namely wxPython and matplotlib, everything in the pythonmac.org repository should also be available for Python 2.4. Also, I stopped using Python 2.3 after I built the 2.4.1 installer, so any packages built from here on out for 2.3 will be largely untested. I only build them as a convenience, because it's very little additional effort for me to do. Of course, nothing in the repository has any guarantee, but most of the stuff in there I use, so it can be considered tested -- but only for Python 2.4 (unless it has been in there a while). > Mostly what I will be doing is prototyping components of larger > systems (and then maybe convincing them they can't do it any better > than with Python :)), and multimedia presentations (beyond Director) > that include animation (2d and 3D) and reinforcing gaming (word > puzzels, image puzzles, and combinations). pygame + pyOpenGL may very well be the best solution for this. It's much simpler to understand than wxPython, and it's cross-platform. The downsides are that there is no widget set, it can not integrate with one (in a sane cross-platform manner), and you are limited to one window. Both of these packages are available for Python 2.4. > What I want to do for myself I'm content with doing only for Mac OS X > (10.3.8+) and may deliver some via the web. However, what little I do > for corporate clients anymore (don't want to get bogged down in work > work) they still seem to want for MS Windows :( dislike that > platform). > > Anyway, since all the components aren't there yet for Python 2.4 (and > what are seem to be less than production quality), I'm assuming that > at least 2.3 is solid enough (relatively speaking :). At least all > the components are there (with the caveat of what was recently > discussed regarding overall coordination and quality control). I'm > also assuming that with the state of Python, Tiger will probably not > go beyond 2.3 (not asking you to make any frowned upon predictions). Python 2.4.1 *is* production quality. All of the packages that I have built for 2.4.1 work exactly the same as they do on 2.3, but faster and with less bugs. The Python 2.3.0 interpreter that ships with Mac OS X 10.3 is *almost* production quality. The fact that the distribution I built didn't include a help book (which was apparently built by hand, and made available separately) really has no relevance at all to its "production quality". I *highly* recommend that you use Python 2.4. > So to look as well as possible on the Mac I should use what graphics > components? Then for MS Windows candidates (cross-platform) I should > use wxPython for graphics components? I *have* been perusing the > components list (http://pythonmac.org/packages/) and brief > descriptions, but only a limited amount of the detailed documentation > so far. One point about the component list - I should use only the > component versions flagged for py2.3 if such is to be my production > platform? (Dumb questions sometimes yield surprising answers) I'd recommend pygame first, unless you have some requirements that it can't handle. > Another very novice question - for the MS Windows executables do I > need to transfer my script packages to my clunky old PC and construct > such there, or can py2exe construct such on my Mac? Neither cx_Freeze nor py2exe make it reasonable to "cross-compile" like this. You will have to use Windows. -bob From bob at redivi.com Tue Apr 5 20:19:21 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 5 20:19:28 2005 Subject: [Pythonmac-SIG] bdist_mpkg with C sources In-Reply-To: <4252C329.10900@ucsd.edu> References: <4410b98492e85f90b2c31179438982ab@psychology.nottingham.ac.uk> <4252C329.10900@ucsd.edu> Message-ID: <5b17aa389c04982d47462b52d9986c9c@redivi.com> On Apr 5, 2005, at 12:56 PM, Robert Kern wrote: > Jonathan Peirce wrote: >> I'm wanting to make a mac installer for a python library I maintain >> that contains some C extensions and I'm not clear how to go about it >> since setup for bdist_mpkg doesn't accept ext_module. >> Does anyone have a simple-ish example of how to do this? Or will it >> be that bdist_mpkg will one day just act like the regular distutils >> bdist? Obviously ideally I would like not to have a separate setup.py >> for each platform I support - would be much nicer to have a single >> script like the one below (which does successfully build a mac binary >> distribution using bdist, just not the double-clickable installer) > > I have built upwards of 40-ish packages with extension modules and > packaged them with bdist_mpkg. I have found no such problem. Can you > describe the actual problem that you are seeing in more detail? bdist_mpkg *is* a regular bdist. It invokes the "install" command, and then pax'es up all the junk and puts it in a package. Try this: package_data_path=os.path.join(sys.prefix, 'lib','site-packages','psychopy') bdist_mpkg doesn't currently assume that the directories you give it are sys.prefix relative (maybe it should). I've never seen a package that makes that assumption (and apparently neither has Robert). -bob From lee_cullens at mac.com Tue Apr 5 21:32:51 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 5 21:32:58 2005 Subject: [Pythonmac-SIG] RE: What is a good working environment? In-Reply-To: References: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> Message-ID: <834b60ad67f5da0e705490409bee0787@mac.com> Thanks for your experienced guidance Bob, In retrospect, I guess my limited and naive exposure thus far has yielded up as many "annoyances" in 2.3 as in 2.4, so it was unfair diminishing the state of 2.4. Also, the new (to me) considerations regarding pygame and wxPython are applicable to both versions I'm sure. Is there some middle ground approach I might use for Mac OS X only development and deployment? The multimedia development I do goes beyond reasonable expectations with Director and Lingo scripting (and I have considerable experience there). One response mentioned how they were using Python and PyQT. My response might give a better idea of my mindset: ------------ My goal is to accomplish what I want to with Python and its components and I'm still naive enough to think I might be able to without undo hassle :~) I, of course, am not under any commercial pressure anymore and would not take on any occasional client project without doing feasibility testing of applicable functionality first. In my "working" career I was (among other things) involved in engineering modeling systems that are I'm sure quite outdated by now. The point being that such started with assembler and evolved through Fortran, APL, Pascal and C (first on IBM then HP Unix distributed systems) - areas I have no desire to get back into. The other areas were business applications with COBOL and flash-in-the pants higher level tools that is even more unappealing anymore. The upstart is that there are still a lot of different ideas I'd like to develop (in the sense of keeping my head busy) especially on the new Mac, but don't want to get off on too many troublesome tangents ;') I imagine though, that in holding down the size of executables some of the Python "components" will involve compile steps. What ever happened to my "perfect world" dreams :<)) -------------- Thanks yet again Bob, Lee C On Apr 5, 2005, at 2:13 PM, Bob Ippolito wrote: > > On Apr 5, 2005, at 8:20 AM, Lee Cullens wrote: > >> What is a good working environment? >> >> All of what Bob did for us is nice for exploring changes in 2.4 but >> is still too much of a WIP. I (as many of you) need to get on with >> some development work though and was wondering what basis to work >> from. > > No, it's not a WIP. Python 2.4.1 is perfectly stable (FAR more so > than 2.3.0, actually). Except for packages that I don't package > myself, namely wxPython and matplotlib, everything in the > pythonmac.org repository should also be available for Python 2.4. > > Also, I stopped using Python 2.3 after I built the 2.4.1 installer, so > any packages built from here on out for 2.3 will be largely untested. > I only build them as a convenience, because it's very little > additional effort for me to do. Of course, nothing in the repository > has any guarantee, but most of the stuff in there I use, so it can be > considered tested -- but only for Python 2.4 (unless it has been in > there a while). > >> Mostly what I will be doing is prototyping components of larger >> systems (and then maybe convincing them they can't do it any better >> than with Python :)), and multimedia presentations (beyond Director) >> that include animation (2d and 3D) and reinforcing gaming (word >> puzzels, image puzzles, and combinations). > > pygame + pyOpenGL may very well be the best solution for this. It's > much simpler to understand than wxPython, and it's cross-platform. > The downsides are that there is no widget set, it can not integrate > with one (in a sane cross-platform manner), and you are limited to one > window. Both of these packages are available for Python 2.4. > >> What I want to do for myself I'm content with doing only for Mac OS X >> (10.3.8+) and may deliver some via the web. However, what little I >> do for corporate clients anymore (don't want to get bogged down in >> work work) they still seem to want for MS Windows :( dislike that >> platform). >> >> Anyway, since all the components aren't there yet for Python 2.4 (and >> what are seem to be less than production quality), I'm assuming that >> at least 2.3 is solid enough (relatively speaking :). At least all >> the components are there (with the caveat of what was recently >> discussed regarding overall coordination and quality control). I'm >> also assuming that with the state of Python, Tiger will probably not >> go beyond 2.3 (not asking you to make any frowned upon predictions). > > Python 2.4.1 *is* production quality. All of the packages that I have > built for 2.4.1 work exactly the same as they do on 2.3, but faster > and with less bugs. The Python 2.3.0 interpreter that ships with Mac > OS X 10.3 is *almost* production quality. The fact that the > distribution I built didn't include a help book (which was apparently > built by hand, and made available separately) really has no relevance > at all to its "production quality". > > I *highly* recommend that you use Python 2.4. > >> So to look as well as possible on the Mac I should use what graphics >> components? Then for MS Windows candidates (cross-platform) I should >> use wxPython for graphics components? I *have* been perusing the >> components list (http://pythonmac.org/packages/) and brief >> descriptions, but only a limited amount of the detailed documentation >> so far. One point about the component list - I should use only the >> component versions flagged for py2.3 if such is to be my production >> platform? (Dumb questions sometimes yield surprising answers) > > I'd recommend pygame first, unless you have some requirements that it > can't handle. > >> Another very novice question - for the MS Windows executables do I >> need to transfer my script packages to my clunky old PC and construct >> such there, or can py2exe construct such on my Mac? > > Neither cx_Freeze nor py2exe make it reasonable to "cross-compile" > like this. You will have to use Windows. > > -bob > From lee_cullens at mac.com Wed Apr 6 04:53:03 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed Apr 6 04:53:10 2005 Subject: [Pythonmac-SIG] RE: What is a good working environment? In-Reply-To: References: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> Message-ID: <2fd8bc20b05a85c80900547bafe137c8@mac.com> I've been going through the listed components in more detail and wonder if anyone would venture a brief answer to the following. Relative to Bob's pygame vs. wxPython considerations and for what is intended for the Mac OS X platform only, how does PyObjC fit into the equation (functionally, mixing and difficulty wise)? The "presentation" category of apps I mentioned earlier would be multi windowed with widgets as in navigating through web pages (but locally based) and include reinforcing games. There is also a "gaming" app I want to develop that would allow novices to customize the content of various types of games and produce standalone high quality executables of their customized games. I do plan on doing detailed approach feasibility tests, but would like to narrow down potential candidates before such. I am learning fast (despite my age and because I'm no longer embarrassed by asking dumb questions), and many of you veterans will recognize the changing "playgrounds" syndrome :~) Thank you, Lee C On Apr 5, 2005, at 2:13 PM, Bob Ippolito wrote: > > On Apr 5, 2005, at 8:20 AM, Lee Cullens wrote: > >> What is a good working environment? >> > > pygame + pyOpenGL may very well be the best solution for this. It's > much simpler to understand than wxPython, and it's cross-platform. > The downsides are that there is no widget set, it can not integrate > with one (in a sane cross-platform manner), and you are limited to one > window. Both of these packages are available for Python 2.4. > > I'd recommend pygame first, unless you have some requirements that it > can't handle. From bob at redivi.com Wed Apr 6 05:14:06 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Apr 6 05:14:13 2005 Subject: [Pythonmac-SIG] RE: What is a good working environment? In-Reply-To: <2fd8bc20b05a85c80900547bafe137c8@mac.com> References: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> <2fd8bc20b05a85c80900547bafe137c8@mac.com> Message-ID: <7d5d34fc7bd01eecf42a1a9b5e2e7eba@redivi.com> On Apr 5, 2005, at 7:53 PM, Lee Cullens wrote: > On Apr 5, 2005, at 2:13 PM, Bob Ippolito wrote: > >> >> On Apr 5, 2005, at 8:20 AM, Lee Cullens wrote: >> >>> What is a good working environment? >>> >> >> pygame + pyOpenGL may very well be the best solution for this. It's >> much simpler to understand than wxPython, and it's cross-platform. >> The downsides are that there is no widget set, it can not integrate >> with one (in a sane cross-platform manner), and you are limited to >> one window. Both of these packages are available for Python 2.4. >> >> I'd recommend pygame first, unless you have some requirements that it >> can't handle. > > I've been going through the listed components in more detail and > wonder if anyone would venture a brief answer to the following. > > Relative to Bob's pygame vs. wxPython considerations and for what is > intended for the Mac OS X platform only, how does PyObjC fit into the > equation (functionally, mixing and difficulty wise)? > > The "presentation" category of apps I mentioned earlier would be multi > windowed with widgets as in navigating through web pages (but locally > based) and include reinforcing games. There is also a "gaming" app I > want to develop that would allow novices to customize the content of > various types of games and produce standalone high quality executables > of their customized games. > > I do plan on doing detailed approach feasibility tests, but would like > to narrow down potential candidates before such. I am learning fast > (despite my age and because I'm no longer embarrassed by asking dumb > questions), and many of you veterans will recognize the changing > "playgrounds" syndrome :~) PyObjC (plus, possibly, PyOpenGL) can do everything you want to do, and will probably be easier than wxPython or PyQt (depending on how your brain works, I guess)... but I think you'll have to write a fair share of custom views, controls, etc. to implement this sort of thing. I would highly recommend doing some other things with PyObjC first, and playing around with Objective-C a little bit on its own (so you can more easily read Apple's documentation) before trying to do this. In other words, it takes some experience before you learn how to properly design an application using any framework, so plan on doing a couple simpler throwaway projects with whatever you choose before doing something so large. If you don't, you'll probably do it all wrong, and end up with a real mess on your hands. -bob From Jonathan.Peirce at nottingham.ac.uk Wed Apr 6 12:51:41 2005 From: Jonathan.Peirce at nottingham.ac.uk (Jon Peirce) Date: Wed Apr 6 12:52:05 2005 Subject: [Pythonmac-SIG] bdist_mpkg with C sources In-Reply-To: <20050405193258.D14041E400D@bag.python.org> References: <20050405193258.D14041E400D@bag.python.org> Message-ID: Many thanks Robert and Bob, Looks like it was nothgin more than a duff installation of py2app (sorry). After your messages I got no further until i tried on a fresh installation on a new machine (with the LOVELY macEnthon). You're right - it all works just fine :)) If I work out what was wrong on the first machine I'll let you know. chrs again, Jon On 5 Apr 2005, at 20:32, pythonmac-sig-request@python.org wrote: > From: Bob Ippolito > Date: 5 April 2005 19:19:21 BST > To: Robert Kern > Cc: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] bdist_mpkg with C sources > > > > On Apr 5, 2005, at 12:56 PM, Robert Kern wrote: > >> Jonathan Peirce wrote: >>> I'm wanting to make a mac installer for a python library I maintain >>> that contains some C extensions and I'm not clear how to go about it >>> since setup for bdist_mpkg doesn't accept ext_module. >>> Does anyone have a simple-ish example of how to do this? Or will it >>> be that bdist_mpkg will one day just act like the regular distutils >>> bdist? Obviously ideally I would like not to have a separate >>> setup.py for each platform I support - would be much nicer to have a >>> single script like the one below (which does successfully build a >>> mac binary distribution using bdist, just not the double-clickable >>> installer) >> >> I have built upwards of 40-ish packages with extension modules and >> packaged them with bdist_mpkg. I have found no such problem. Can you >> describe the actual problem that you are seeing in more detail? > > bdist_mpkg *is* a regular bdist. It invokes the "install" command, > and then pax'es up all the junk and puts it in a package. > > Try this: > package_data_path=os.path.join(sys.prefix, > 'lib','site-packages','psychopy') > > bdist_mpkg doesn't currently assume that the directories you give it > are sys.prefix relative (maybe it should). I've never seen a package > that makes that assumption (and apparently neither has Robert). > > -bob Jon Peirce +44 (0) 115 84 67176 http://www.peirce.org.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2638 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050406/22e91a78/attachment.bin From dangoor at gmail.com Wed Apr 6 17:59:41 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Wed Apr 6 17:59:43 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: References: <70e164530f6f81abaa27f37fd8780c21@mac.com> Message-ID: <3f085ecd050406085942fcac11@mail.gmail.com> On Mar 31, 2005 2:52 AM, Lee Cullens wrote: > TextWrangler is (to me) too much like its big brother - a do-all > "develop it yourself" sandbox. Great if that's what your into, but a > sidetrack to me. For the moment I'll stick with the simpler > SubEthaEdit which I can even use in Terminal (instead of Pico). > Besides I liked "The Hitchhikers Guide To The Galaxy" (origin of Sub > Etha) - was it the late 70's or the 80's they serialized it on PBS (I'm > forgetting too much)? I've become fond of TextMate lately. It's a fairly new editor and is missing some features, but what it does it does well. It has good project organization and makes it easy to switch between files in your project. The really spiffy thing, though, is that it is very easily extended via Unix filters. So, you can make filters that do anything to your text in any language (eg Python) and have the result pop back into your buffer. There are a fair number of add-ons available already (because of how easy it is to extend), but they're only accessible via a Subversion repository at the moment. TextMate is $39, which is infinitely more than free, but considerably less than BBEdit. Kevin From rowen at cesmail.net Wed Apr 6 19:15:11 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Wed Apr 6 19:17:09 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation References: <70e164530f6f81abaa27f37fd8780c21@mac.com> <3f085ecd050406085942fcac11@mail.gmail.com> Message-ID: In article <3f085ecd050406085942fcac11@mail.gmail.com>, Kevin Dangoor wrote: >... > I've become fond of TextMate lately. It's a fairly new editor and is > missing some features, but what it does it does well. It has good > project organization and makes it easy to switch between files in your > project. The really spiffy thing, though, is that it is very easily > extended via Unix filters. So, you can make filters that do anything > to your text in any language (eg Python) and have the result pop back > into your buffer. There are a fair number of add-ons available already > (because of how easy it is to extend), but they're only accessible via > a Subversion repository at the moment. > > TextMate is $39, which is infinitely more than free, but considerably > less than BBEdit. I agree it has great potential. However, I also feel it has too many rough edges and am waiting for it to mature. Problems include: - Wretched syntax coloring for Python (orange and other colors on black strike you?). Yes you can change it, but it's not easy. - Multiple undo undoes one keystroke at a time. - Code folding is nice, but does not work well with Python (and this cannot be fixed unless the editor's folding support is improved) - No toolbar (nor any contextual menu substitute). I normally hate toolbars, but a pop-up menu of functions and objects along the top of a source file is really handy. Easy access to file-specific settings such as line ending and tab spacing is also something I use a lot. TextMate has a lot of potential. Once they polish it up a bit I plan to switch. $39 is an excellent price (even considering that TextWranger does more for free). (By the way, Pepper allows you to write filters in the language of your choice. I think TextWrangler does, as well.) I just gave WingIDE a try yesterday, at Bob Ippolito's suggestion, and I am really impressed. The fact that is X11 is a problem, but the debugger is great (boy have I missed not having a good debugger) and the code browser isn't bad either. And it allows one to test GUI apps without fuss (unlike IDLE, which at least at one time required removing the "root.mainloop()" statement from Tkinter apps before running them. Has anyone tried EricIDE and WingIDE? Any idea of the relative merits and weaknesses? -- Russell From lee_cullens at mac.com Wed Apr 6 20:04:23 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Wed Apr 6 20:04:31 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: <3f085ecd050406085942fcac11@mail.gmail.com> References: <70e164530f6f81abaa27f37fd8780c21@mac.com> <3f085ecd050406085942fcac11@mail.gmail.com> Message-ID: <70f5f5f6a49ca65e2dfaa1167803e53d@mac.com> Thanks Kevin, I've got bookmarks on it, Pydev and Wing, but for now am using the basics until I "really" need more. Lee C On Apr 6, 2005, at 11:59 AM, Kevin Dangoor wrote: > On Mar 31, 2005 2:52 AM, Lee Cullens wrote: >> TextWrangler is (to me) too much like its big brother - a do-all >> "develop it yourself" sandbox. Great if that's what your into, but a >> sidetrack to me. For the moment I'll stick with the simpler >> SubEthaEdit which I can even use in Terminal (instead of Pico). >> Besides I liked "The Hitchhikers Guide To The Galaxy" (origin of Sub >> Etha) - was it the late 70's or the 80's they serialized it on PBS >> (I'm >> forgetting too much)? > > I've become fond of TextMate lately. It's a fairly new editor and is > missing some features, but what it does it does well. It has good > project organization and makes it easy to switch between files in your > project. The really spiffy thing, though, is that it is very easily > extended via Unix filters. So, you can make filters that do anything > to your text in any language (eg Python) and have the result pop back > into your buffer. There are a fair number of add-ons available already > (because of how easy it is to extend), but they're only accessible via > a Subversion repository at the moment. > > TextMate is $39, which is infinitely more than free, but considerably > less than BBEdit. > > Kevin > From rowen at cesmail.net Wed Apr 6 23:21:27 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Wed Apr 6 23:24:02 2005 Subject: [Pythonmac-SIG] Keymap file for WingIDE Message-ID: I have put up a basic keymap file for WingIDE that makes it look more like a traditional Mac text editor. More could be done, but it handles the basics. See for a link. The file is presently here: but if it moves, try the first link. -- Russell From Chris.Barker at noaa.gov Thu Apr 7 01:04:12 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Apr 7 01:04:33 2005 Subject: [Pythonmac-SIG] Re: IDE recommendation In-Reply-To: References: <70e164530f6f81abaa27f37fd8780c21@mac.com> <3f085ecd050406085942fcac11@mail.gmail.com> Message-ID: <42546AEC.1070404@noaa.gov> >> I've become fond of TextMate lately. Does it have incremental search? I really, really love 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 charles.hartman at conncoll.edu Thu Apr 7 01:46:01 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Apr 7 01:46:10 2005 Subject: [Pythonmac-SIG] Keymap file for WingIDE In-Reply-To: References: Message-ID: That is really, really helpful. I've been using Custom Key Bindings for this, because my first attempt to make a keymap file didn't work well. This is much cleaner (though it has the temporary disadvantage that Wing has to be restarted for each change in the keymap). I've uncommented the source-folding lines, and they work fine. Thanks for doing this. I hope you've told Wing Tech Support about it. (They're extraordinarily helpful.) Charles Hartman On Apr 6, 2005, at 5:21 PM, Russell E. Owen wrote: > I have put up a basic keymap file for WingIDE that makes it look more > like a traditional Mac text editor. More could be done, but it handles > the basics. > > See for a link. > > The file is presently here: > but if > it > moves, try the first link. > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From lee_cullens at mac.com Thu Apr 7 03:19:47 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu Apr 7 03:19:55 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> Message-ID: <6b7b9d30e318f2b22010be4f0f720a2b@mac.com> Just a followup. I thought since I was the one that complained _coupled_ with Bob's mention of not much help in pulling it all together on OS X, that I would see if I was far enough along yet to prepare the needed Help Viewer resource to include in the pythonIDE package. Kevin Walzer graciously pointed me at the appropriate ADC instructions, and Robert Kern tried to make it even simpler by pointing me to the applicable scripts in the 2.4 source distribution. After studying both approaches I believe it would take *me* a minimum of several days to create the said resource file, or even longer trying to use the source distribution scripts (figuring out exactly how to). One thing I did note in the scripts is that Jack makes some changes in the docs that he must believe are appropriate and if I were to take the former approach (ADC instructions) I should mimic in the spirit of he and Bob's work. Balancing this with the relevant need (does anyone other than a novice like me even care about PythonIDE on a Mac?) and that I've decided to bite the bullet and go with Wing, I've decided to forego this little exercise (barring any crowd riot :~) and proceed with my Python learning cycle (after which I might be able to provide more meaningful help in furthering Python on Mac OS X). Lee C From charles.hartman at conncoll.edu Thu Apr 7 04:14:57 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Apr 7 04:15:05 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: <6b7b9d30e318f2b22010be4f0f720a2b@mac.com> References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> <6b7b9d30e318f2b22010be4f0f720a2b@mac.com> Message-ID: Welcome to the Wing bandwagon (??). I like it a whole lot. It works a little more easily on Windows (which I use only to build distributables) than on Mac (where I use it all the time), because of the X11 layer on Mac; but it works well and has great support. I strongly recommend that you download and install the Mac keymap that Russell Owen just posted here. It reduces the alien feel of X11 a fair amount. Charles Hartman On Apr 6, 2005, at 9:19 PM, Lee Cullens wrote: > Just a followup. I thought since I was the one that complained > _coupled_ with Bob's mention of not much help in pulling it all > together on OS X, that I would see if I was far enough along yet to > prepare the needed Help Viewer resource to include in the pythonIDE > package. > > Kevin Walzer graciously pointed me at the appropriate ADC > instructions, and Robert Kern tried to make it even simpler by > pointing me to the applicable scripts in the 2.4 source distribution. > > After studying both approaches I believe it would take *me* a minimum > of several days to create the said resource file, or even longer > trying to use the source distribution scripts (figuring out exactly > how to). One thing I did note in the scripts is that Jack makes some > changes in the docs that he must believe are appropriate and if I were > to take the former approach (ADC instructions) I should mimic in the > spirit of he and Bob's work. > > Balancing this with the relevant need (does anyone other than a novice > like me even care about PythonIDE on a Mac?) and that I've decided to > bite the bullet and go with Wing, I've decided to forego this little > exercise (barring any crowd riot :~) and proceed with my Python > learning cycle (after which I might be able to provide more meaningful > help in furthering Python on Mac OS X). > > Lee C > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From peterf at semiotx.com Wed Apr 6 05:30:44 2005 From: peterf at semiotx.com (Peter Fraterdeus) Date: Thu Apr 7 04:43:51 2005 Subject: [Pythonmac-SIG] Problem during installing MySQL module in Python Message-ID: Hello! Did you ever resolve this problem with MySQLda? .... At the end of the installation, had received the following message _mysql.c: In function `_mysql_ConnectionObject_shutdown': _mysql.c:1545: error: too few arguments to function `mysql_shutdown' error: command 'gcc' failed with exit status 1 .... I'm having the same problem on a linux box. Perhaps the same question I should ask also: Jack Jansen Jack.Jansen at cwi.nl : Have you checked that the version of mysql that you have installed is actually the same version as what the MySQLdba extension expects? This looks like the sort of error that could happen if the two don't match: it appears the function signature of mysql_shutdown() is different from what MySQLdba expects... But it would be good to know if you have figured this out! Thanks Peter -- AzByCx DwEvFu GtHsIr JqKpLo MnNmOl PkQjRi ShTgUf VeWdXc YbZa&@ Peter Fraterdeus http://www.fraterdeus.com http://www.galenaphotos.com http://www.dezinecafe.com - designdigerati (r) Global Design Community - Free Intercultural Review - now Plone driven! http://www.semiotx.com Web Strategy Consulting "Words that work."(tm) Communication Design and Typography From lee_cullens at mac.com Thu Apr 7 04:52:50 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu Apr 7 04:52:57 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> <6b7b9d30e318f2b22010be4f0f720a2b@mac.com> Message-ID: <32f1293698b4c71a4e45055d569d3a4e@mac.com> Thanks Charles, Yes, I had saved Russell's post. I'll be getting Wing in a few days (I use my monthly SS deposit to pay for my toys :~) I wasted a month fighting with a sleazy Apple reseller, then went to Apple.com to order my G5, so by the time I got it installed Feb. was almost over. Since then I've got my LAN set up (with the clunky ol PCs :<)), worked my way through "Mac OS X Panther Unleashed" and most of the way through "Learning Python," so I'm making pretty good progress. Lee C On Apr 6, 2005, at 10:14 PM, Charles Hartman wrote: > Welcome to the Wing bandwagon (??). I like it a whole lot. It works a > little more easily on Windows (which I use only to build > distributables) than on Mac (where I use it all the time), because of > the X11 layer on Mac; but it works well and has great support. I > strongly recommend that you download and install the Mac keymap that > Russell Owen just posted here. It reduces the alien feel of X11 a fair > amount. > > Charles Hartman > > > On Apr 6, 2005, at 9:19 PM, Lee Cullens wrote: > >> Just a followup. I thought since I was the one that complained >> _coupled_ with Bob's mention of not much help in pulling it all >> together on OS X, that I would see if I was far enough along yet to >> prepare the needed Help Viewer resource to include in the pythonIDE >> package. >> >> Kevin Walzer graciously pointed me at the appropriate ADC >> instructions, and Robert Kern tried to make it even simpler by >> pointing me to the applicable scripts in the 2.4 source distribution. >> >> After studying both approaches I believe it would take *me* a minimum >> of several days to create the said resource file, or even longer >> trying to use the source distribution scripts (figuring out exactly >> how to). One thing I did note in the scripts is that Jack makes some >> changes in the docs that he must believe are appropriate and if I >> were to take the former approach (ADC instructions) I should mimic in >> the spirit of he and Bob's work. >> >> Balancing this with the relevant need (does anyone other than a >> novice like me even care about PythonIDE on a Mac?) and that I've >> decided to bite the bullet and go with Wing, I've decided to forego >> this little exercise (barring any crowd riot :~) and proceed with my >> Python learning cycle (after which I might be able to provide more >> meaningful help in furthering Python on Mac OS X). >> >> Lee C From Chris.Barker at noaa.gov Thu Apr 7 08:01:11 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Apr 7 08:01:25 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> <6b7b9d30e318f2b22010be4f0f720a2b@mac.com> Message-ID: <4254CCA7.9000907@noaa.gov> Charles Hartman wrote: > Welcome to the Wing bandwagon (??). I like it a whole lot. It works a > little more easily on Windows (which I use only to build distributables) > than on Mac (where I use it all the time), because of the X11 layer on > Mac; Isn't Wing built with QT? If so, are they working on a native version? -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 Apr 7 08:13:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Apr 7 08:13:27 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: <4254CCA7.9000907@noaa.gov> References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> <6b7b9d30e318f2b22010be4f0f720a2b@mac.com> <4254CCA7.9000907@noaa.gov> Message-ID: <8ff934dee7482296aaeb2e290fdd624f@redivi.com> On Apr 6, 2005, at 11:01 PM, Chris Barker wrote: > Charles Hartman wrote: >> Welcome to the Wing bandwagon (??). I like it a whole lot. It works a >> little more easily on Windows (which I use only to build >> distributables) than on Mac (where I use it all the time), because of >> the X11 layer on Mac; > > Isn't Wing built with QT? If so, are they working on a native version? No, and I doubt it. % macho_find WingIDE.app ... WingIDE.app/Contents/MacOS/bin/gtk-bin/lib/libgtk-x11-2.0.0.200.4.dylib ... -bob From Henning.Ramm at mediapro-gmbh.de Thu Apr 7 08:33:28 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Apr 7 08:33:30 2005 Subject: [Pythonmac-SIG] IDE recommendation Message-ID: Does anyone have experience with jEdit? (www.jedit.org) It's an GPL'ed all purpose editor written in Java that claims to also support Python. I had no time to test it yet besides that it runs on MacOS X, but it's extremely configurable and enhanceable (plugins, macros etc.). Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From Chris.Barker at noaa.gov Thu Apr 7 08:41:52 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Thu Apr 7 08:42:03 2005 Subject: [Pythonmac-SIG] Python documentation in PythonIDE--for Lee Cullens In-Reply-To: <8ff934dee7482296aaeb2e290fdd624f@redivi.com> References: <42520A0B.5060106@wordtech-software.com> <70112aaf303913d9c7ef1bfb0d0345b4@mac.com> <6b7b9d30e318f2b22010be4f0f720a2b@mac.com> <4254CCA7.9000907@noaa.gov> <8ff934dee7482296aaeb2e290fdd624f@redivi.com> Message-ID: <4254D630.40206@noaa.gov> Bob Ippolito wrote: >> Isn't Wing built with QT? If so, are they working on a native version? > > No, and I doubt it. > > % macho_find WingIDE.app > ... > WingIDE.app/Contents/MacOS/bin/gtk-bin/lib/libgtk-x11-2.0.0.200.4.dylib Well, that explains the X dependence! maybe GTK will really become a cross platform toolkit some 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 konrad.hinsen at laposte.net Thu Apr 7 09:06:35 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Thu Apr 7 09:06:37 2005 Subject: [Pythonmac-SIG] IDE recommendation In-Reply-To: References: Message-ID: On 07.04.2005, at 08:33, wrote: > Does anyone have experience with jEdit? (www.jedit.org) > It's an GPL'ed all purpose editor written in Java that claims > to also support Python. I use it for editing, also for Python code, but it's just an editor, not an IDE. It has Python support for syntax coloring, and it is scriptable in Python through a Jython plugin. The Jython plugin also provides a minimal IDE for Jython, but all my code requires standard C Python, so I don't use that feature. My current setup is jEdit for major editing and Emacs for interactive testing and debugging. I wish a single tool would be good for both, but I can live with those two rather well. Konrad. -- ------------------------------------------------------------------------ ------- Konrad Hinsen Laboratoire Leon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr ------------------------------------------------------------------------ ------- From sw at wordtech-software.com Thu Apr 7 18:30:28 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu Apr 7 18:30:34 2005 Subject: [Pythonmac-SIG] A note on WingIDE Message-ID: <42556024.9030806@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wasn't sure if anyone realized this, but WingIDE provides a free license ~ for open-source/non-commercial projects. You have to apply, so I'm not sure how difficult it is to obtain, but that is certainly attractive if you're doing FOSS only. http://wingware.com/store/prices - -- 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 iD8DBQFCVWAjJmdQs+6YVcoRAumdAJ4tz+3XcEaOWg7evBcag7aGLKwrCwCeOAoq rJsTHg6o7PprFDIlp2RpbvY= =tX4c -----END PGP SIGNATURE----- From sw at wordtech-software.com Thu Apr 7 18:35:18 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu Apr 7 18:35:22 2005 Subject: [Pythonmac-SIG] ANN: AquaMacs distribution of Emacs Message-ID: <42556146.50107@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In case anyone is interested, David Reitter and I are working on a distribution of Carbon Emacs that includes a lot of Aqua-specific customizations (keyboard shortcuts, use of native file dialogs, etc.) to make Emacs more HIG-compliant. http://www.wordtech-software.com/aquamacs.html - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.smallbizmac.com http://www.kevin-walzer.com mailto:sw@wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVWFGJmdQs+6YVcoRAmPpAJ4uW1Ng4XPtUwzlqjDSvK6oyHiVmACfQJJR 4B8bnWSYfkjDr3IZnMMtOe4= =qPJF -----END PGP SIGNATURE----- From charles.hartman at conncoll.edu Thu Apr 7 19:47:37 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu Apr 7 20:31:13 2005 Subject: [Pythonmac-SIG] A note on WingIDE In-Reply-To: <42556024.9030806@wordtech-software.com> References: <42556024.9030806@wordtech-software.com> Message-ID: On Apr 7, 2005, at 12:30 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Wasn't sure if anyone realized this, but WingIDE provides a free > license > ~ for open-source/non-commercial projects. You have to apply, so I'm > not > sure how difficult it is to obtain, but that is certainly attractive if > you're doing FOSS only. -- not difficult. I explained my project to them just a little before I was ready to release it as OS Certified, pointed them at its web site, and filled out the simple downloadable form. They've been great. I could never have afforded the two-platform license I need if I'm to distribute for Windows as well as Mac (which is to say, octupling my user base). Charles Hartman From konrad.hinsen at laposte.net Thu Apr 7 22:53:27 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Thu Apr 7 22:53:30 2005 Subject: [Pythonmac-SIG] ANN: AquaMacs distribution of Emacs In-Reply-To: <42556146.50107@wordtech-software.com> References: <42556146.50107@wordtech-software.com> Message-ID: <6e4f4322102ecf680fde104310557182@laposte.net> On 07.04.2005, at 18:35, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In case anyone is interested, David Reitter and I are working on a > distribution of Carbon Emacs that includes a lot of Aqua-specific > customizations (keyboard shortcuts, use of native file dialogs, etc.) > to > make Emacs more HIG-compliant. > > http://www.wordtech-software.com/aquamacs.html This looked promising, so I tested it - for about five minutes. This beast is less ergonomic than standard Emacs and less ergonomic than any standard Mac text editor - who wants that? Unless of course I have overlooked something essential... 1) No more than one buffer per window. I tend to have about twenty buffers in an Emacs session. Twenty windows? Not on my iBook! And.. having two files on top of each other in one window is often very useful. It's one of the reasons why I still use Emacs. 2) File completion with the pop-up dialog is a lot worse than no file completion at all. The idea of Emacs-style (and readline-style) file completion is that one can always type one more letter to reduce the number of choices. No more with that silly dialog box. 3) Python-mode seems to work only partially. In particular, py-shell doesn't work. No more Python debugging in Emacs... Oh well... it's in the trashcan, life goes on as usual :-) Konrad. From sw at wordtech-software.com Thu Apr 7 23:35:15 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu Apr 7 23:35:18 2005 Subject: [Pythonmac-SIG] Update on SPE-OSX Message-ID: <4255A793.8080901@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've gotten some inquiries about SPE-OSX crashing with the latest version of wxPython. I've done some digging and it looks like it's a bug in wxPython's underlying wxMac libraries. Stefan Cosmor (wxMac maintainer) has committed a fix to CVS and Robin Dunn tells me it will be included in the next binary release of wxPython, which will be in a few days. I'll double-check then and, if everything seems OK, release a new version along with advice to update to the new wxPython. Thanks for everyone's patience. - -- 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 iD8DBQFCVaeSJmdQs+6YVcoRAqzVAJ4oX+/gnBvH6RsBaHWQdJNTeLlnFQCdEizz DN+BpkyTRn77Zkvhu+1FezM= =tcrJ -----END PGP SIGNATURE----- From lee_cullens at mac.com Fri Apr 8 23:43:41 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Fri Apr 8 23:43:50 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <2f4f83fe12fb301cac600685df80421b@redivi.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <2f4f83fe12fb301cac600685df80421b@redivi.com> Message-ID: <5c6ab478aba34c763a2a6906724bfa59@mac.com> On Mar 31, 2005, at 11:10 AM, Bob Ippolito wrote: > > On Mar 31, 2005, at 10:59 AM, Charles Hartman wrote: > >> 2. (Then I need to set a path variable to say which one will be used >> in various contexts, such as debugging, building with py2app, etc.?) > > When typing "python": > - If /usr/bin comes before /usr/local/bin in your PATH then Python > 2.3.0 will be used, if /usr/local/bin comes first, then Python 2.4.1 > will be used (of course, with sufficient other crap installed, this > may not be true). > > When typing "python2.3" > - Will always choose 2.3.0 (unless you have other crap installed) > > When typing "python2.4" > - Will always choose 2.4.1 (unless you have other crap installed, or > /usr/local/bin is not in the path) > > When running scripts installed by Python packages, their "#!" lines > are rewritten to point to a *specific* Python. In those cases, it's > whichever you installed most recently. For example, the bdist_mpkg > script that comes with py2app. > -bob > It has been a dense day as I've had my head around an OOP design pattern approach, so I'm sure I'm missing the obvious with this side track :~) Having a little trouble getting at Python 2.4 and wondered what I need to set to get such by default. Do I need to reset the whole sys.path each time? I also wanted Wing to access 2.4 in interactive mode before I setup a project, so I wanted something outside of Wing to stick. I used 2.4 previously but that was through Applications/MacPython-2.4/PythonIDE so I tried copying the Wing folder over to Applications/MacPython-2.4/ (from Applications/) but then Wing comes all garbled still (trying to) referencing 2.3. The Terminal try follows, in turn followed by the PythonIDE in 2.4 sys.path: ***Terminal*** Chinook ~ 240 $python2.4 -bash: python2.4: command not found Chinook ~ 241 $python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python23.zip', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/Numeric', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PyObjC', '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/wx-2.5.3-mac-ansi', '/Users/Chinook/Library/Python/2.3/site-packages', '/Users/Chinook/PythonWIP/PythonScripts', '/Users/Chinook/PythonProjects'] >>> ***PythonIDE (in 2.4)*** Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] Type "copyright", "credits" or "license" for more information. MacPython IDE 1.0.2 >>> import sys >>> sys.path ['/Applications/MacPython-2.4/PythonIDE.app/Contents/Resources', '/Library/Frameworks/Python.framework/Versions/2.4/Mac/Tools/IDE', '/Applications/MacPython-2.4/PythonIDE.app/Contents/Resources', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python24.zip', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat- darwin', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat- mac', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat- mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib- tk', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib- dynload', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages', '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/py2app', '/Users/Chinook/Library/Python/2.4/site-packages', '/Users/Chinook/PythonWIP/PythonScripts', '/Users/Chinook/PythonProjects'] >>> Thanks, Lee C From bob at redivi.com Fri Apr 8 23:59:44 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 8 23:59:51 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <5c6ab478aba34c763a2a6906724bfa59@mac.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <2f4f83fe12fb301cac600685df80421b@redivi.com> <5c6ab478aba34c763a2a6906724bfa59@mac.com> Message-ID: <1efe4de043c2fdd2df46bedaaf802c22@redivi.com> On Apr 8, 2005, at 2:43 PM, Lee Cullens wrote: > > On Mar 31, 2005, at 11:10 AM, Bob Ippolito wrote: > >> >> On Mar 31, 2005, at 10:59 AM, Charles Hartman wrote: >> >>> 2. (Then I need to set a path variable to say which one will be used >>> in various contexts, such as debugging, building with py2app, etc.?) >> >> When typing "python": >> - If /usr/bin comes before /usr/local/bin in your PATH then Python >> 2.3.0 will be used, if /usr/local/bin comes first, then Python 2.4.1 >> will be used (of course, with sufficient other crap installed, this >> may not be true). >> >> When typing "python2.3" >> - Will always choose 2.3.0 (unless you have other crap installed) >> >> When typing "python2.4" >> - Will always choose 2.4.1 (unless you have other crap installed, or >> /usr/local/bin is not in the path) >> >> When running scripts installed by Python packages, their "#!" lines >> are rewritten to point to a *specific* Python. In those cases, it's >> whichever you installed most recently. For example, the bdist_mpkg >> script that comes with py2app. > > It has been a dense day as I've had my head around an OOP design > pattern approach, so I'm sure I'm missing the obvious with this side > track :~) > > Having a little trouble getting at Python 2.4 and wondered what I need > to set to get such by default. Do I need to reset the whole sys.path > each time? I also wanted Wing to access 2.4 in interactive mode > before I setup a project, so I wanted something outside of Wing to > stick. When I say PATH I mean the PATH environment variable. sys.path is a side-effect of which interpreter was run, not the cause of it. By the time sys.path even exists, you're already running Python, so how could that be relevant? > I used 2.4 previously but that was through > Applications/MacPython-2.4/PythonIDE so I tried copying the Wing > folder over to Applications/MacPython-2.4/ (from Applications/) but > then Wing comes all garbled still (trying to) referencing 2.3. The > Terminal try follows, in turn followed by the PythonIDE in 2.4 > sys.path: I've said this to you before, those folders are *NOT IN ANY WAY SPECIAL*. Moving stuff around on the filesystem isn't going to do anything (except break stuff). Read , hopefully you'll figure it out. If not, search the archives or ask the Wing folk. I don't really have time right now to explain in more detail than I already have. -bob From charles.hartman at conncoll.edu Sat Apr 9 00:54:19 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat Apr 9 01:09:45 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <5c6ab478aba34c763a2a6906724bfa59@mac.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <2f4f83fe12fb301cac600685df80421b@redivi.com> <5c6ab478aba34c763a2a6906724bfa59@mac.com> Message-ID: <3d087189e2b463e58a737d8e54875d94@conncoll.edu> I haven't thought all the way through it, but this might be helpful: Put Python 2.4 where it belongs, put Wing where it belongs (in Applications). Make the adjustment in your project. In Project | Properties, the item "Python Executable" can be set to Custom, and in that field, begin typing (it will help) the path to the Python you want. (For me, that's /usr/bin/pythonw for Python 2.3 and /user/local/bin/pythonw for Python 2.4.) Hope this helps. Charles Hartman Professor of English, Poet in Residence *the Scandroid* is available at: http://cherry.conncoll.edu/cohar/Programs http://villex.blogspot.com On Apr 8, 2005, at 5:43 PM, Lee Cullens wrote: > > On Mar 31, 2005, at 11:10 AM, Bob Ippolito wrote: > >> >> On Mar 31, 2005, at 10:59 AM, Charles Hartman wrote: >> >>> 2. (Then I need to set a path variable to say which one will be used >>> in various contexts, such as debugging, building with py2app, etc.?) >> >> When typing "python": >> - If /usr/bin comes before /usr/local/bin in your PATH then Python >> 2.3.0 will be used, if /usr/local/bin comes first, then Python 2.4.1 >> will be used (of course, with sufficient other crap installed, this >> may not be true). >> >> When typing "python2.3" >> - Will always choose 2.3.0 (unless you have other crap installed) >> >> When typing "python2.4" >> - Will always choose 2.4.1 (unless you have other crap installed, or >> /usr/local/bin is not in the path) >> >> When running scripts installed by Python packages, their "#!" lines >> are rewritten to point to a *specific* Python. In those cases, it's >> whichever you installed most recently. For example, the bdist_mpkg >> script that comes with py2app. >> -bob >> > > It has been a dense day as I've had my head around an OOP design > pattern approach, so I'm sure I'm missing the obvious with this side > track :~) > > Having a little trouble getting at Python 2.4 and wondered what I need > to set to get such by default. Do I need to reset the whole sys.path > each time? I also wanted Wing to access 2.4 in interactive mode > before I setup a project, so I wanted something outside of Wing to > stick. > > I used 2.4 previously but that was through > Applications/MacPython-2.4/PythonIDE so I tried copying the Wing > folder over to Applications/MacPython-2.4/ (from Applications/) but > then Wing comes all garbled still (trying to) referencing 2.3. The > Terminal try follows, in turn followed by the PythonIDE in 2.4 > sys.path: > > ***Terminal*** > Chinook ~ 240 $python2.4 > -bash: python2.4: command not found > Chinook ~ 241 $python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> sys.path > ['', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python23.zip', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-darwin', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/lib-scriptpackages', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-tk', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/lib-dynload', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/Numeric', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PyObjC', > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/wx-2.5.3-mac-ansi', > '/Users/Chinook/Library/Python/2.3/site-packages', > '/Users/Chinook/PythonWIP/PythonScripts', > '/Users/Chinook/PythonProjects'] > >>> > > ***PythonIDE (in 2.4)*** > Python 2.4.1 (#2, Mar 31 2005, 00:05:10) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] > Type "copyright", "credits" or "license" for more information. > MacPython IDE 1.0.2 > >>> import sys > >>> sys.path > ['/Applications/MacPython-2.4/PythonIDE.app/Contents/Resources', > '/Library/Frameworks/Python.framework/Versions/2.4/Mac/Tools/IDE', > '/Applications/MacPython-2.4/PythonIDE.app/Contents/Resources', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python24.zip', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat- > darwin', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat- > mac', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat- > mac/lib-scriptpackages', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib- > tk', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib- > dynload', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- > packages', > '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- > packages/py2app', '/Users/Chinook/Library/Python/2.4/site-packages', > '/Users/Chinook/PythonWIP/PythonScripts', > '/Users/Chinook/PythonProjects'] > >>> > > Thanks, > Lee C > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From lee_cullens at mac.com Sat Apr 9 08:32:26 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Sat Apr 9 08:32:32 2005 Subject: [Pythonmac-SIG] ANN: MacPython 2.4.1 installer In-Reply-To: <3d087189e2b463e58a737d8e54875d94@conncoll.edu> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <2f4f83fe12fb301cac600685df80421b@redivi.com> <5c6ab478aba34c763a2a6906724bfa59@mac.com> <3d087189e2b463e58a737d8e54875d94@conncoll.edu> Message-ID: Thanks for the reply Charles, I knew about the project perfs and after spending considerable time studying Bob's reply decided to go that way. I have a little bare bones project which loads and the shell is then indeed Python 2.4, which accomplishes what I wanted for the moment. In following all the tree threads from where Bob pointed me I went through the module she-bang line, the session setting in bash and new info (to me) such as the user environment plist and setting LSEnvironment for the application. All of the choices were more work than the Wing project perfs and some even had potential troublesome side effects. It was a learning exercise :~) - thanks again, Lee C PS: I never touched Python 2.4 and I ghosted my volume immediately before moving Wing - after almost 50 years of this I know better than to paint myself into a corner :<)) "Seek wisdom early or seek it not, least ye be overcome with regrets." -- Laura Cullens c1940s On Apr 8, 2005, at 6:54 PM, Charles Hartman wrote: > I haven't thought all the way through it, but this might be helpful: > Put Python 2.4 where it belongs, put Wing where it belongs (in > Applications). Make the adjustment in your project. In Project | > Properties, the item "Python Executable" can be set to Custom, and in > that field, begin typing (it will help) the path to the Python you > want. (For me, that's /usr/bin/pythonw for Python 2.3 and > /user/local/bin/pythonw for Python 2.4.) Hope this helps. > > Charles Hartman > Professor of English, Poet in Residence > *the Scandroid* is available at: > http://cherry.conncoll.edu/cohar/Programs > http://villex.blogspot.com > > On Apr 8, 2005, at 5:43 PM, Lee Cullens wrote: > >> >> On Mar 31, 2005, at 11:10 AM, Bob Ippolito wrote: >> >>> >>> On Mar 31, 2005, at 10:59 AM, Charles Hartman wrote: >>> >>>> 2. (Then I need to set a path variable to say which one will be >>>> used in various contexts, such as debugging, building with py2app, >>>> etc.?) >>> >>> When typing "python": >>> - If /usr/bin comes before /usr/local/bin in your PATH then Python >>> 2.3.0 will be used, if /usr/local/bin comes first, then Python 2.4.1 >>> will be used (of course, with sufficient other crap installed, this >>> may not be true). >>> >>> When typing "python2.3" >>> - Will always choose 2.3.0 (unless you have other crap installed) >>> >>> When typing "python2.4" >>> - Will always choose 2.4.1 (unless you have other crap installed, or >>> /usr/local/bin is not in the path) >>> >>> When running scripts installed by Python packages, their "#!" lines >>> are rewritten to point to a *specific* Python. In those cases, it's >>> whichever you installed most recently. For example, the bdist_mpkg >>> script that comes with py2app. >>> -bob >>> >> >> It has been a dense day as I've had my head around an OOP design >> pattern approach, so I'm sure I'm missing the obvious with this side >> track :~) >> >> Having a little trouble getting at Python 2.4 and wondered what I >> need to set to get such by default. Do I need to reset the whole >> sys.path each time? I also wanted Wing to access 2.4 in interactive >> mode before I setup a project, so I wanted something outside of Wing >> to stick. >> >> I used 2.4 previously but that was through >> Applications/MacPython-2.4/PythonIDE so I tried copying the Wing >> folder over to Applications/MacPython-2.4/ (from Applications/) but >> then Wing comes all garbled still (trying to) referencing 2.3. The >> Terminal try follows, in turn followed by the PythonIDE in 2.4 >> sys.path: >> >> ***Terminal*** >> Chinook ~ 240 $python2.4 >> -bash: python2.4: command not found >> Chinook ~ 241 $python >> Python 2.3 (#1, Sep 13 2003, 00:49:11) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import sys >> >>> sys.path >> ['', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python23.zip', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-darwin', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-mac', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/plat-mac/lib-scriptpackages', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-tk', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/lib-dynload', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/Numeric', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/PyObjC', >> '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >> python2.3/site-packages/wx-2.5.3-mac-ansi', >> '/Users/Chinook/Library/Python/2.3/site-packages', >> '/Users/Chinook/PythonWIP/PythonScripts', >> '/Users/Chinook/PythonProjects'] >> >>> >> >> ***PythonIDE (in 2.4)*** >> Python 2.4.1 (#2, Mar 31 2005, 00:05:10) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] >> Type "copyright", "credits" or "license" for more information. >> MacPython IDE 1.0.2 >> >>> import sys >> >>> sys.path >> ['/Applications/MacPython-2.4/PythonIDE.app/Contents/Resources', >> '/Library/Frameworks/Python.framework/Versions/2.4/Mac/Tools/IDE', >> '/Applications/MacPython-2.4/PythonIDE.app/Contents/Resources', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python24.zip', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> plat-darwin', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> plat-mac', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> plat-mac/lib-scriptpackages', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib- >> tk', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib- >> dynload', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> site-packages', >> '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ >> site-packages/py2app', >> '/Users/Chinook/Library/Python/2.4/site-packages', >> '/Users/Chinook/PythonWIP/PythonScripts', >> '/Users/Chinook/PythonProjects'] >> >>> >> >> Thanks, >> Lee C From joachimm at mac.se Sun Apr 10 03:59:49 2005 From: joachimm at mac.se (=?ISO-8859-1?Q?Joachim_M=E5rtensson?=) Date: Sun Apr 10 03:59:52 2005 Subject: [Pythonmac-SIG] Problems with grammar for dparser In-Reply-To: <4255A793.8080901@wordtech-software.com> References: <4255A793.8080901@wordtech-software.com> Message-ID: <42588895.3070501@mac.se> Hello, I am playing around a little bit with dparser, and I thought that maybe someone on this list can help me out (There does not seem to be a dparser list, atleast not an active one). I am total n00b to parsers so this might be very easy. I want a parser that can parse both these lines (What I am looking to construct is a parser of a _very_ limited subset of objective-c). [[self _rowsForAddingContentObject:content] retain] NSArray *contentRowArray This is what I have so far. from dparser import Parser def d_objcmsg(t): 'objcmsg: "\[" (objcmsg|var) msg "\]" ' def d_varDef(t): 'varDef: classname "\*" var' def d_classname(t): 'classname: "[A-Z][A-Za-z_0-9]*"' def d_var(t): 'var: "[a-z_][A-Za-z_0-9]*" ' def d_msg(t): 'msg: (msgWithArg|"[a-z_][A-Za-z_0-9]*")' def d_msgWithArg(t): 'msgWithArg: "[a-z_][A-Za-z_0-9]*" ":" (var|objcmsg)' this makes the "[[self _rowsForAddingContentObject:content] retain]" line pass, however I get a syntax error on the other one. Switching the placing of d_obcmsg and d_varDef makes the other line pass, but then the first fail with a syntax error. I want both of the lines to pass. Anyone have any ideas? Joachim From sw at wordtech-software.com Sun Apr 10 04:43:13 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Apr 10 04:43:22 2005 Subject: [Pythonmac-SIG] SPE-OSX crashes fixed Message-ID: <425892C1.5000005@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I tested my current build of SPE-OSX (0.7.2.d) against the new release of wxPython (2.5.5) and it launches and runs smoothly. The crashes that many people were reporting were a result of a bug in wxMac (the underlying libraries of wxPython on OSX) and that bug has been fixed. So, go ahead and download the new release of wxPython (wxpython.org) and ~ the current build of SPE-OSX should work fine; I see no point in packaging up a new 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 iD8DBQFCWJLAJmdQs+6YVcoRAj4ZAJ9WvNJv9PbpMonK6kVXyWbpvChUVwCfQsxb X6cVl1aZIVr81Q/a1ecnAoU= =ZeRU -----END PGP SIGNATURE----- From bob at redivi.com Sun Apr 10 04:48:29 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Apr 10 04:48:40 2005 Subject: [Pythonmac-SIG] Problems with grammar for dparser In-Reply-To: <42588895.3070501@mac.se> References: <4255A793.8080901@wordtech-software.com> <42588895.3070501@mac.se> Message-ID: <3e16a67c24e52384866af57ff00df6d1@redivi.com> On Apr 9, 2005, at 6:59 PM, Joachim M?rtensson wrote: > Hello, I am playing around a little bit with dparser, and I thought > that maybe someone on this list can help me out (There does not seem > to be a dparser list, atleast not an active one). I am total n00b to > parsers so this might be very easy. I want a parser that can parse > both these lines (What I am looking to construct is a parser of a > _very_ limited subset of objective-c). You might have better luck asking comp.lang.python (aka python-list). None of what you're doing is Mac specific, so you'd be better off asking a larger audience. -bob From tgray at Princeton.EDU Sun Apr 10 07:12:46 2005 From: tgray at Princeton.EDU (Tim Gray) Date: Sun Apr 10 07:12:53 2005 Subject: [Pythonmac-SIG] matplotlib installation issues Message-ID: Hi, I've been trying to install matplotlib .74 for a little bit and have been running into some problems. I installed python 2.4.1 from and Tcl/TkAqua 8.4.9 from . I then compiled and installed zlib 1.2.2, libpng 1.2.8, freetype 2.1.9, Numeric 23.8, and numarray 1.2.3, in that order. Nothing seemed to go wrong at these stages. Finally I was ready to compile/install matplotlib. It seemed to progress well. When it came time to import pylab, python exited. I've tried installing matplotlib .72-1 and the same thing happened. It also happened when I tried someone's pre-compiled version of .73. When running python -v, I saw this same error everytime, any version of matplotlib: # /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/transforms.pyc matches /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/transforms.py import matplotlib.transforms # precompiled from /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/transforms.pyc # /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/_transforms.pyc matches /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/_transforms.py import matplotlib._transforms # precompiled from /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/_transforms.pyc Illegal instruction I'd really like to make this work. Any suggestions? From lee_cullens at mac.com Sun Apr 10 09:13:05 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Sun Apr 10 09:13:10 2005 Subject: [Pythonmac-SIG] RE: Python 2.4 & wxPython In-Reply-To: <7d5d34fc7bd01eecf42a1a9b5e2e7eba@redivi.com> References: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> <2fd8bc20b05a85c80900547bafe137c8@mac.com> <7d5d34fc7bd01eecf42a1a9b5e2e7eba@redivi.com> Message-ID: <4c5ab7d2237e0a909e147405898677a3@mac.com> Probably only news to me, but a Mac OS 10.3 wxPython (2.5.5.1) binary is now up for Python 2.4 (http://wxpython.sourceforge.net/download.php#prerequisites). I don't see it yet on the list Bob referred me to (http://pythonmac.org/packages/), but perhaps it will be soon. Lee C From bob at redivi.com Sun Apr 10 10:13:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Apr 10 10:13:32 2005 Subject: [Pythonmac-SIG] RE: Python 2.4 & wxPython In-Reply-To: <4c5ab7d2237e0a909e147405898677a3@mac.com> References: <82dfdd9a3d9b609f02a6d71c2c0dcad7@mac.com> <2fd8bc20b05a85c80900547bafe137c8@mac.com> <7d5d34fc7bd01eecf42a1a9b5e2e7eba@redivi.com> <4c5ab7d2237e0a909e147405898677a3@mac.com> Message-ID: On Apr 10, 2005, at 12:13 AM, Lee Cullens wrote: > Probably only news to me, but a Mac OS 10.3 wxPython (2.5.5.1) binary > is now up for Python 2.4 > (http://wxpython.sourceforge.net/download.php#prerequisites). > > I don't see it yet on the list Bob referred me to > (http://pythonmac.org/packages/), but perhaps it will be soon. It's new, you're the first I've heard it from. I'll try and remember to wrap it up and post it next week. -bob From hengist.podd at virgin.net Sun Apr 10 20:40:27 2005 From: hengist.podd at virgin.net (has) Date: Sun Apr 10 20:41:06 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 Message-ID: Hi all, Just a quick heads-up on my latest venture into the wild and wonderful world of the Open Scripting Architecture, MacPythonOSA: http://freespace.virgin.net/hamish.sanderson/MacPythonOSA_project.dmg.gz Only semi-complete and minimally documented, and functioning more at proof-of-concept than production-quality level, but you should be able to build it and get a taste of Python a-la OSA. See the Tests folder for example scripts. Basic stuff like compilation, execution and display is fairly complete, and event sending and handling is mostly working at the raw AE code level. Other things like terminology support and recording are still to do, along with somehow insulating scripts from one another by providing each with its own module namespace, stdout and stderr. Please make sure you read the docs and install the latest version of aem before use: http://freespace.virgin.net/hamish.sanderson/aem-0.6.0.tar.gz If there's any problems getting it going then drop me a note. I will definitely need expert advice on the finer points of OSA component implementation in order to complete it, so if someone can help me out there it would be hugely appreciated. Regards, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Sun Apr 10 21:10:30 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Apr 10 21:10:36 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: References: Message-ID: <5563a9346cfa15dd9dc78b883974d465@redivi.com> On Apr 10, 2005, at 11:40 AM, has wrote: > Just a quick heads-up on my latest venture into the wild and wonderful > world of the Open Scripting Architecture, MacPythonOSA: .. > I will definitely need expert advice on the finer points of OSA > component implementation in order to complete it, so if someone can > help me out there it would be hugely appreciated. In the implementation, you do this: #define MAX_CSTRING_PATH_SIZE 32768 /* Because 32KB should be enough for anyone... */ 32KB is *way* oversized and could actually cause a problem because the default stack size on Mac OS X is rather small. The right way is to just use MAXPATHLEN. MAXPATHLEN is defined in , but you're already including python.h -- which should guarantee that it is defined (even on platforms that don't on their own). You #include -- which should actually be #include "MacPythonOSA.h" -- because it's not a system header. Though obviously it doesn't make a difference in this case. The style you use for C code is totally whack, especially the indentation. It would be a lot more readable if you wrote it in a standard style, the obvious choice would be PEP 7 . You should refactor this so that it doesn't link to Python.framework directly, and instead loads up all of the symbols at runtime based upon a configurable Python library. The biggest reason for this is: if the process is already linked to Python, and you link in a different one by virtue of this component being loaded into the process (not even initialized), it could very well crash. The py2app plugin template doesn't currently look for an existing linked interpreter, but it will at some point soon because I have to refactor it anyway. If you detect an interpreter other than the one you expected, it should probably prevent the component from being initialized -- since you need the aem extension to be present. -bob From hengist.podd at virgin.net Sun Apr 10 21:47:48 2005 From: hengist.podd at virgin.net (has) Date: Sun Apr 10 21:47:58 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: <5563a9346cfa15dd9dc78b883974d465@redivi.com> References: <5563a9346cfa15dd9dc78b883974d465@redivi.com> Message-ID: Bob Ippolito wrote: >In the implementation, you do this: > >#define MAX_CSTRING_PATH_SIZE 32768 /* Because 32KB should be enough for anyone... */ > >32KB is *way* oversized and could actually cause a problem because the default stack size on Mac OS X is rather small. The right way is to just use MAXPATHLEN. MAXPATHLEN is defined in , but you're already including python.h -- which should guarantee that it is defined (even on platforms that don't on their own). Yeah, it's pretty goofy; didn't know what to make it so just stuck in something big for the meantime. Fixed. (BTW, needed to include for some reason; compiler wasn't finding it without.) >You #include -- which should actually be #include "MacPythonOSA.h" -- because it's not a system header. Though obviously it doesn't make a difference in this case. Fixed. Much appreciated; my C is not exactly great, as you can tell. Project's re-uploaded. >The style you use for C code is totally whack, especially the indentation. It would be a lot more readable if you wrote it in a standard style, the obvious choice would be PEP 7 . That's just me; really don't care for either PEP7 or C syntax in general. It can always get run through a pretty printer later on. Spite just makes it tolerable in the meantime.:) >You should refactor this so that it doesn't link to Python.framework directly, and instead loads up all of the symbols at runtime based upon a configurable Python library. The biggest reason for this is: if the process is already linked to Python, and you link in a different one by virtue of this component being loaded into the process (not even initialized), it could very well crash. The py2app plugin template doesn't currently look for an existing linked interpreter, but it will at some point soon because I have to refactor it anyway. If you detect an interpreter other than the one you expected, it should probably prevent the component from being initialized -- since you need the aem extension to be present. Good advice, though I'm not sufficiently up on C programming or OS internals to have a clue how to do it. Any pointers? Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From Benjamin.Abecassis at cea.fr Sun Apr 10 21:19:30 2005 From: Benjamin.Abecassis at cea.fr (Benjamin Abecassis) Date: Sun Apr 10 23:48:43 2005 Subject: [Pythonmac-SIG] problems with installing scipy on mac Message-ID: <49469.81.57.232.138.1113160770.squirrel@dsm-mail> Hi all, I had to re-install macosX and i'm struggling to re)install scipy... I think i have installed everything necessary but the installation exits with sh: line 1: f95: command not found sh: line 1: f95: command not found error: Command "f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.darwin-7.3.1-Power_Macintosh-2.3/Lib/fftpack/dfftpack/dcosqb.o" failed with exit status 127 furthermore it says Could not locate executable g77 Could not locate executable f77 whereas g77 is installed and present in usr/local/bin !!!??? another problem is thath gnuplot does not start when i simply type 'gnuplot' in a terminal window i have to type 'usr/local/bin/gnuplot' for it to work. May these problem be related ?? thanks a lot in advance... B.A. From listspam at flowtheory.net Sun Apr 10 23:46:20 2005 From: listspam at flowtheory.net (Joshua Ginsberg) Date: Sun Apr 10 23:48:44 2005 Subject: [Pythonmac-SIG] Fwd: PPC OSX vs. x86 Linux Message-ID: Sorry for the crosspost, but perhaps some of you more familiar with the OS X Python guts might have some theories. Thanks! -jag -------------- next part -------------- A non-text attachment was scrubbed... Name: Pasted Graphic.tiff Type: image/tiff Size: 17326 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050410/bbef7a95/PastedGraphic-0002.tiff -------------- next part -------------- Joshua Ginsberg -- joshg@brainstorminternet.net Brainstorm Internet Network Operations 970-247-1442 x131 Begin forwarded message: > From: Joshua Ginsberg > Date: April 8, 2005 11:02:38 AM MDT > To: python-list@mail.python.org > Cc: Subject: PPC OSX vs. x86 Linux > > Hello -- > > I writing some python code to do some analysis of my mail logs. I took > a 10,000 line snippet from them (the files are about 5-6 million > usually) to test my code with. I'm developing it on a Powerbook G4 > 1.2GHz with 1.25GB of RAM and the Apple distributed Python* and I > tested my code on the 10,000 line snippet. It took 2 minutes and 10 > seconds to process that snippet. Way too slow -- I'd be looking at > about 20 hours to process a single daily log file. > > Just for fun, I copied the same code and the same log snippet to a > dual-proc P3 500MHz machine running Fedora Core 2* with 1GB of RAM and > tested it there. This machine provides web services and domain control > for my network, so it's moderately utilized. The same code took six > seconds to execute. > > Granted I've got the GUI and all of that bogging down my Mac. However, > I had nothing else fighting for CPU cycles and 700MB of RAM free when > my testing was done. Even still, what would account for such a wide, > wide, wide variation in the time required to process the data file? > The code is 90% regular expressions and string finds. > > Theories? Thanks! > > -jag > > > * versions are: > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > and > Python 2.3.3 (#1, May 7 2004, 10:31:40) > [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2 > -------------- next part -------------- A non-text attachment was scrubbed... Name: Pasted Graphic.tiff Type: image/tiff Size: 17326 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050410/bbef7a95/PastedGraphic-0003.tiff -------------- next part -------------- > > Joshua Ginsberg -- joshg@brainstorminternet.net > Brainstorm Internet Network Operations > 970-247-1442 x131-- > http://mail.python.org/mailman/listinfo/python-list From Jack.Jansen at cwi.nl Mon Apr 11 00:07:39 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Apr 11 00:07:39 2005 Subject: [Pythonmac-SIG] Audio I/O In-Reply-To: <1112455446.424eb9162ee98@cubmail.cc.columbia.edu> References: <1112455446.424eb9162ee98@cubmail.cc.columbia.edu> Message-ID: On 2-apr-05, at 17:24, J. Devaney wrote: > I'm working on a python project that requires audio I/O (via the > soundcard) - I basically just need a stream that can be analyzed in > real-time and stored to a file. I've looked into various options - > such as portaudio using a python wrapper - but since portability > isn't really I issue I was wondering if there was a more direct > (and simpler approach). There's the Carbon.Snd module, which interfaces to the old Sound Manager, and there's the Quicktime module. I don't think the Quicktime module as shipped with Python 2.3 (which Apple ships with 10.3) supports capturing, but I think that the Quicktime module in 2.4 should support it. But: I don't know of people who have tried it, so please report back here whether it works. You can also download and install the new Quicktime for Python 2.3: if you open the experimental database in Package Manager you'll see it listed. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Mon Apr 11 00:14:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 11 00:14:14 2005 Subject: [Pythonmac-SIG] Fwd: PPC OSX vs. x86 Linux In-Reply-To: References: Message-ID: <066c2653d9042a2903532e502b928cfc@redivi.com> On Apr 10, 2005, at 2:46 PM, Joshua Ginsberg wrote: >> I writing some python code to do some analysis of my mail logs. I >> took a 10,000 line snippet from them (the files are about 5-6 million >> usually) to test my code with. I'm developing it on a Powerbook G4 >> 1.2GHz with 1.25GB of RAM and the Apple distributed Python* and I >> tested my code on the 10,000 line snippet. It took 2 minutes and 10 >> seconds to process that snippet. Way too slow -- I'd be looking at >> about 20 hours to process a single daily log file. >> >> Just for fun, I copied the same code and the same log snippet to a >> dual-proc P3 500MHz machine running Fedora Core 2* with 1GB of RAM >> and tested it there. This machine provides web services and domain >> control for my network, so it's moderately utilized. The same code >> took six seconds to execute. >> >> Granted I've got the GUI and all of that bogging down my Mac. >> However, I had nothing else fighting for CPU cycles and 700MB of RAM >> free when my testing was done. Even still, what would account for >> such a wide, wide, wide variation in the time required to process the >> data file? The code is 90% regular expressions and string finds. >> >> * versions are: >> Python 2.3 (#1, Sep 13 2003, 00:49:11) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin >> and >> Python 2.3.3 (#1, May 7 2004, 10:31:40) >> [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2 Try it with a newer version of Python on Mac OS X. I had a similar problem, and it turned out to be Python 2.3.0's fault. Specifically, the implementation of the datetime module's parser was really, really, really stupid and slow in early versions of Python 2.3. -bob From bob at redivi.com Mon Apr 11 00:15:11 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 11 00:15:16 2005 Subject: [Pythonmac-SIG] problems with installing scipy on mac In-Reply-To: <49469.81.57.232.138.1113160770.squirrel@dsm-mail> References: <49469.81.57.232.138.1113160770.squirrel@dsm-mail> Message-ID: <0a8f889580bb505bbfc56e24657be10f@redivi.com> On Apr 10, 2005, at 12:19 PM, Benjamin Abecassis wrote: > I had to re-install macosX and i'm struggling to re)install scipy... > I think i have installed everything necessary but the installation > exits with > > sh: line 1: f95: command not found > sh: line 1: f95: command not found > error: Command "f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o > build/temp.darwin-7.3.1-Power_Macintosh-2.3/Lib/fftpack/dfftpack/ > dcosqb.o" > failed with exit status 127 > > furthermore it says > Could not locate executable g77 > Could not locate executable f77 > > whereas g77 is installed and present in usr/local/bin !!!??? > another problem is thath gnuplot does not start when i simply type > 'gnuplot' in a terminal window i have to type 'usr/local/bin/gnuplot' > for > it to work. > May these problem be related ?? These problems are definitely related. You need to manipulate your PATH environment variable in order to include /usr/local/bin. If you need more information about the PATH environment variable, search the archives.. I posted something related in the past few days. -bob From rkern at ucsd.edu Mon Apr 11 00:53:18 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 11 00:53:23 2005 Subject: [Pythonmac-SIG] problems with installing scipy on mac In-Reply-To: <49469.81.57.232.138.1113160770.squirrel@dsm-mail> References: <49469.81.57.232.138.1113160770.squirrel@dsm-mail> Message-ID: <4259AE5E.8030105@ucsd.edu> Benjamin Abecassis wrote: > Hi all, > I had to re-install macosX and i'm struggling to re)install scipy... > I think i have installed everything necessary but the installation exits with > > sh: line 1: f95: command not found > sh: line 1: f95: command not found > error: Command "f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o > build/temp.darwin-7.3.1-Power_Macintosh-2.3/Lib/fftpack/dfftpack/dcosqb.o" > failed with exit status 127 > > furthermore it says > Could not locate executable g77 > Could not locate executable f77 > > whereas g77 is installed and present in usr/local/bin !!!??? > another problem is thath gnuplot does not start when i simply type > 'gnuplot' in a terminal window i have to type 'usr/local/bin/gnuplot' for > it to work. > May these problem be related ?? Probably you don't have /usr/local/bin in your PATH environment variable. -- 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 Apr 11 01:03:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 11 01:04:03 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: References: <5563a9346cfa15dd9dc78b883974d465@redivi.com> <386410748069ee99ea8900aeca25d21f@redivi.com> Message-ID: On Apr 10, 2005, at 3:53 PM, has wrote: >> A multi-process model would be a lot more robust overall. Linking to >> Python is problematic if there's even a remote possibility the >> process might also be using a Python interpreter. >> >> If you remove the need for that and communicate with existing Python >> interpreters exclusively, it would probably be much better overall >> (though much more work). > > Yep, removing Python from the component would require quite a lot more > in C, which I'm not keen on for maintenance's sake. Even if each > script runs as a seperate process, I really want the OSA component and > script daemon to remain written in Python where it's manageable. > Besides, I'm simply not willing to pursue it as a sizeable C project > myself - I've other things to do - so if C-ifying it is the only > option then someone else will have to adopt it. Not as much extra code as you'd think. The easiest way to do it would be as an apple event "router". You receive the events from the OSA interface, start up a Python process running code that can accept apple events from your router (if it's not already running), and then toss the events to the correct process (each component instance could correspond to a pid, maybe). >> Threading sounds like a bad idea, given the constraints on them, the >> difficulty to do it correctly, and the pain they are to debug when >> not behaving correctly. > > Yep, I suspect there's no easy solution and it's going to be a > struggle either way. Stupid Python. Just how painful are Python > threads anyway (sub-interpreters specifically)? > > The only other option would be to find some way to provide each script > with an independent module namespace and std I/O objects despite > Python's global obsession, in which case we could safely run all > scripts in the main thread (still not ideal, but good enough for most > situations). I've no idea if that's practical or not though; it'd need > someone familiar with Python's internals to answer it. Nope, not practical. Sub-interpreters are going to cause problems with extension modules, and there is no way to have separate module namespaces for different code running in the same interpreter. Redirecting I/O at all sounds like a bad idea in the first place. -bob From rkern at ucsd.edu Mon Apr 11 06:24:37 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 11 06:25:04 2005 Subject: [Pythonmac-SIG] ANN: MacEnthon 0.1 Message-ID: <4259FC05.9070008@ucsd.edu> MacEnthon is the OS X counterpart to the popular "Enthought Edition" of Python: a convenient bundling of a number of packages geared for the scientific community. Right now, it targets the Apple-installed Python 2.3.0. Once I am satisfied with this release, I will consider cutting a release for Python 2.4.1. This is still just a test release. Please do not tell newbies to go install it, yet. New in this release: - some updates to packages from CVS/SVN - all documentation is now under /Developer/Python - enthonutil.py, a module that allows you to easily make your own "sumo" distribution; see /Developer/Python/MacEnthon/enthonutil-example.py For a full list of packages, please see the ReadMe: http://download.enthought.com/MacEnthon/ReadMe.html To download: http://download.enthought.com/MacEnthon/MacEnthon-0.1.dmg Included is a CLI uninstaller, enthonbegone.py . It may leave a few empty directories some .pyc's hanging about, but otherwise it works fairly well. See its help for more information. When you encounter problems, packaging/build bugs, or missing documentation, please log it on the Enthon issue tracker and assign the issue to "rkern": https://www.enthought.com/roundup/enthon/ I haven't gotten much feedback, so I can only assume that it's perfect. Barring anything particularly idiotic that I've done, I will probably only make one more "final" MacEnthon for Python 2.3.0. When I recover from that, I'll start thinking about 2.4.1. -- 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 hengist.podd at virgin.net Mon Apr 11 14:06:58 2005 From: hengist.podd at virgin.net (has) Date: Mon Apr 11 14:07:18 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: References: <5563a9346cfa15dd9dc78b883974d465@redivi.com> <386410748069ee99ea8900aeca25d21f@redivi.com> Message-ID: Bob wrote: >>>A multi-process model would be a lot more robust overall. [...] If you [...] communicate with existing Python interpreters exclusively, it would probably be much better overall (though much more work). >> >>Yep, removing Python from the component would require quite a lot more in C, which I'm not keen on for maintenance's sake. > >Not as much extra code as you'd think. The easiest way to do it would be as an apple event "router". You receive the events from the OSA interface, start up a Python process running code that can accept apple events from your router (if it's not already running), and then toss the events to the correct process (each component instance could correspond to a pid, maybe). Bit more to it than that, unfortunately: - OSA uses Component Manager - not Apple events - to communicate with language components, so the MacPythonOSA component would need to handle each OSA call, stuff its arguments into an IPC message, send the message to the script daemon to process and wait for its response. (This is just the easy bit, btw.) - In addition, the daemon also has to be able to send various messages to the OSA component to be handled there concurrently: CallActiveProc, CreateAppleEvent, SendAppleEvent, RedispatchAppleEvent. - Finally, it needs to do all this without any support from the client app and without treading on its toes in any way. And, very preferably, without an onerous IPC overhead that would limit its usefulness. Not trivial, and might get very sticky. Figuring out the details of what's involved and what the potential problems are is beyond my own modest abilities; someone else will have to do all the legwork here. >>>Threading sounds like a bad idea, given the constraints on them, the difficulty to do it correctly, and the pain they are to debug when not behaving correctly. >> >>Yep, I suspect there's no easy solution and it's going to be a struggle either way. Stupid Python. Just how painful are Python threads anyway (sub-interpreters specifically)? >> >>The only other option would be to find some way to provide each script with an independent module namespace and std I/O objects despite Python's global obsession, in which case we could safely run all scripts in the main thread (still not ideal, but good enough for most situations). I've no idea if that's practical or not though; it'd need someone familiar with Python's internals to answer it. > >Nope, not practical. Sub-interpreters are going to cause problems with extension modules, Yep, I'm aware of that. The question is how serious those problems would be? Concurrency is less of a problem than usual as OSA scripts are typically executed sequentially; the main issue is when script A imports module X and sets some of its state, then script B imports module X and sets the same state to something else, which will cause A some serious upset the next time it attempts to use it. My goal is for MacPythonOSA to be a great OSA component first, and a great Python second. "Good enough" will be acceptable (after all, it's Python's fault we're in this mess in the first place:p). MacPythonOSA is not a 'standard' Python, and isn't intended to be: it's provided as an alternative to AppleScript and other OSA languages, not as an alternative to other Pythons. It's always going to provide a subset of normal Python functionality by its very nature and has no real application outside of OSA. So if I need to impose a few modest rules regarding usage (e.g. "Thou shalt not open and close the same file handle from different scripts at the same time", which is fair enough) then that may be entirely acceptable. The question is, how difficult will Python make it for users to reasonably follow these rules: will it merely take a modicum of common sense (acceptable), or require intimate knowledge of the inner workings of half of Python (not)? >and there is no way to have separate module namespaces for different code running in the same interpreter. The only possibility is we could install custom import hooks each time we initialise/call into an OSA script and provide our own non-global module management system. Which might be practical as long as there's only ever one script being executed at a time. Still not an ideal solution though, since it would limit _all_ use to strictly single-threaded. i.e. Some multithreaded clients may open a separate component instance in each of its own threads, allowing it to execute multiple scripts in parallel even when the component language doesn't support threading itself - e.g. AppleScript. Not sure I like the idea of being even worse than AppleScript. All options suck; all we can do is find the one that sucks least intolerably for our needs. :p >Redirecting I/O at all sounds like a bad idea in the first place. stdin/stdout/stderr have no meaning within OSA: stdin is completely redundant; redirecting stdout to the host application as log events is the closest thing that makes sense; and mirroring stderr as log events in addition to its usual behaviour would also be helpful to users (there's no standard 'log error' event AFAIK, unfortunately). Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Apr 11 18:41:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 11 18:41:15 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: References: <5563a9346cfa15dd9dc78b883974d465@redivi.com> <386410748069ee99ea8900aeca25d21f@redivi.com> Message-ID: <2cffecafd45e093d4232277052607f2b@redivi.com> On Apr 11, 2005, at 5:06 AM, has wrote: > Bob wrote: > >>>> A multi-process model would be a lot more robust overall. [...] If >>>> you [...] communicate with existing Python interpreters >>>> exclusively, it would probably be much better overall (though much >>>> more work). >>> >>> Yep, removing Python from the component would require quite a lot >>> more in C, which I'm not keen on for maintenance's sake. >> >> Not as much extra code as you'd think. The easiest way to do it >> would be as an apple event "router". You receive the events from the >> OSA interface, start up a Python process running code that can accept >> apple events from your router (if it's not already running), and then >> toss the events to the correct process (each component instance could >> correspond to a pid, maybe). > > Bit more to it than that, unfortunately: > > - OSA uses Component Manager - not Apple events - to communicate with > language components, so the MacPythonOSA component would need to > handle each OSA call, stuff its arguments into an IPC message, send > the message to the script daemon to process and wait for its response. > (This is just the easy bit, btw.) > > - In addition, the daemon also has to be able to send various messages > to the OSA component to be handled there concurrently: CallActiveProc, > CreateAppleEvent, SendAppleEvent, RedispatchAppleEvent. > > - Finally, it needs to do all this without any support from the client > app and without treading on its toes in any way. And, very preferably, > without an onerous IPC overhead that would limit its usefulness. Python over IPC is going to be way faster than AppleScript ever was. Mach is good at IPC anyway. > Not trivial, and might get very sticky. Figuring out the details of > what's involved and what the potential problems are is beyond my own > modest abilities; someone else will have to do all the legwork here. I'd say the same thing about Python sub-interpreters. >>>> Threading sounds like a bad idea, given the constraints on them, >>>> the difficulty to do it correctly, and the pain they are to debug >>>> when not behaving correctly. >>> >>> Yep, I suspect there's no easy solution and it's going to be a >>> struggle either way. Stupid Python. Just how painful are Python >>> threads anyway (sub-interpreters specifically)? >>> >>> The only other option would be to find some way to provide each >>> script with an independent module namespace and std I/O objects >>> despite Python's global obsession, in which case we could safely run >>> all scripts in the main thread (still not ideal, but good enough for >>> most situations). I've no idea if that's practical or not though; >>> it'd need someone familiar with Python's internals to answer it. >> >> Nope, not practical. Sub-interpreters are going to cause problems >> with extension modules, > > Yep, I'm aware of that. The question is how serious those problems > would be? Concurrency is less of a problem than usual as OSA scripts > are typically executed sequentially; the main issue is when script A > imports module X and sets some of its state, then script B imports > module X and sets the same state to something else, which will cause A > some serious upset the next time it attempts to use it. > > My goal is for MacPythonOSA to be a great OSA component first, and a > great Python second. "Good enough" will be acceptable (after all, it's > Python's fault we're in this mess in the first place:p). MacPythonOSA > is not a 'standard' Python, and isn't intended to be: it's provided as > an alternative to AppleScript and other OSA languages, not as an > alternative to other Pythons. It's always going to provide a subset of > normal Python functionality by its very nature and has no real > application outside of OSA. So if I need to impose a few modest rules > regarding usage (e.g. "Thou shalt not open and close the same file > handle from different scripts at the same time", which is fair enough) > then that may be entirely acceptable. The question is, how difficult > will Python make it for users to reasonably follow these rules: will > it merely take a modicum of common sense (acceptable), or require > intimate knowledge of the inner workings of half of Python (not)? Python modules that use the PyGILState macros will likely be incompatible with anything that does sub-interpreters, and likely a lot of other ones will be too. Sub-interpreters get just shy of no testing whatsoever. Many extensions aren't going to like being initialized twice. PyObjC is definitely, without a doubt, going to barf with sub-interpreters. Other stuff probably will too. >> and there is no way to have separate module namespaces for different >> code running in the same interpreter. > > The only possibility is we could install custom import hooks each time > we initialise/call into an OSA script and provide our own non-global > module management system. Which might be practical as long as there's > only ever one script being executed at a time. > > Still not an ideal solution though, since it would limit _all_ use to > strictly single-threaded. i.e. Some multithreaded clients may open a > separate component instance in each of its own threads, allowing it to > execute multiple scripts in parallel even when the component language > doesn't support threading itself - e.g. AppleScript. Not sure I like > the idea of being even worse than AppleScript. That still doesn't fix the problems with extensions.. pure Python stuff isn't a big deal. > All options suck; all we can do is find the one that sucks least > intolerably for our needs. :p > > >> Redirecting I/O at all sounds like a bad idea in the first place. > > stdin/stdout/stderr have no meaning within OSA: stdin is completely > redundant; redirecting stdout to the host application as log events is > the closest thing that makes sense; and mirroring stderr as log events > in addition to its usual behaviour would also be helpful to users > (there's no standard 'log error' event AFAIK, unfortunately). Yeah, they have no meaning -- so why bother mapping them to something else? Going where they normally go, and having the user pop open Console if they want to see them, is probably fine. If you were doing Python over IPC, you'd be able to get these and redirect them wherever without trying to trick Python because you'd have access to the pipes. -bob From arthur at iaaa.nl Mon Apr 11 19:03:49 2005 From: arthur at iaaa.nl (Arthur Elsenaar) Date: Mon Apr 11 19:04:11 2005 Subject: [Pythonmac-SIG] Audio I/O In-Reply-To: References: <1112455446.424eb9162ee98@cubmail.cc.columbia.edu> Message-ID: On Apr 10, 2005, at 23:07, Jack Jansen wrote: > > On 2-apr-05, at 17:24, J. Devaney wrote: > >> I'm working on a python project that requires audio I/O (via the >> soundcard) - I basically just need a stream that can be analyzed in >> real-time and stored to a file. I've looked into various options - >> such as portaudio using a python wrapper - but since portability >> isn't really I issue I was wondering if there was a more direct >> (and simpler approach). > > There's the Carbon.Snd module, which interfaces to the old Sound > Manager, and there's the Quicktime module. > I don't think the Quicktime module as shipped with Python 2.3 (which > Apple ships with 10.3) supports capturing, but I think that the > Quicktime module in 2.4 should support it. But: I don't know of people > who have tried it, so please report back here whether it works. > > You can also download and install the new Quicktime for Python 2.3: if > you open the experimental database in Package Manager you'll see it > listed. I installed the backport to 2.3 of Quicktime from Bob's page. Is there any documentation on how to use this? A simple movieplayer example perhaps? Is Apple's Speech manager also being worked on? Thanks, Arthur. From bob at redivi.com Mon Apr 11 19:35:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 11 19:35:26 2005 Subject: [Pythonmac-SIG] Audio I/O In-Reply-To: References: <1112455446.424eb9162ee98@cubmail.cc.columbia.edu> Message-ID: On Apr 11, 2005, at 10:03 AM, Arthur Elsenaar wrote: > > On Apr 10, 2005, at 23:07, Jack Jansen wrote: > >> >> On 2-apr-05, at 17:24, J. Devaney wrote: >> >>> I'm working on a python project that requires audio I/O (via the >>> soundcard) - I basically just need a stream that can be analyzed in >>> real-time and stored to a file. I've looked into various options - >>> such as portaudio using a python wrapper - but since portability >>> isn't really I issue I was wondering if there was a more direct >>> (and simpler approach). >> >> There's the Carbon.Snd module, which interfaces to the old Sound >> Manager, and there's the Quicktime module. >> I don't think the Quicktime module as shipped with Python 2.3 (which >> Apple ships with 10.3) supports capturing, but I think that the >> Quicktime module in 2.4 should support it. But: I don't know of >> people who have tried it, so please report back here whether it >> works. >> >> You can also download and install the new Quicktime for Python 2.3: >> if you open the experimental database in Package Manager you'll see >> it listed. > > I installed the backport to 2.3 of Quicktime from Bob's page. Is there > any documentation on how to use this? A simple movieplayer example > perhaps? I think the deal is that you more or less find examples in C, and guess how they might work from the QuickTime package. It's an automatically generated extension. > Is Apple's Speech manager also being worked on? No, but you can get at that from PyObjC via NSSpeechSynthesizer. -bob From hengist.podd at virgin.net Mon Apr 11 21:15:46 2005 From: hengist.podd at virgin.net (has) Date: Mon Apr 11 21:16:06 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: <2cffecafd45e093d4232277052607f2b@redivi.com> References: <5563a9346cfa15dd9dc78b883974d465@redivi.com> <386410748069ee99ea8900aeca25d21f@redivi.com> <2cffecafd45e093d4232277052607f2b@redivi.com> Message-ID: Bob wrote: >>- OSA uses Component Manager - not Apple events - to communicate with language components, so the MacPythonOSA component would need to handle each OSA call, stuff its arguments into an IPC message, send the message to the script daemon to process and wait for its response. (This is just the easy bit, btw.) >> >>- In addition, the daemon also has to be able to send various messages to the OSA component to be handled there concurrently: CallActiveProc, CreateAppleEvent, SendAppleEvent, RedispatchAppleEvent. >> >>- Finally, it needs to do all this without any support from the client app and without treading on its toes in any way. And, very preferably, without an onerous IPC overhead that would limit its usefulness. > >Python over IPC is going to be way faster than AppleScript ever was. Python+aem's actually a bit slower than AppleScript given most of the data conversion and event packing/unpacking is done in Python rather than C. (Not much though.) I think the main bottlenecks for AE-based IPC lie elsewhere; AS is guilty of a lot of things but I don't believe this is one of them. >Mach is good at IPC anyway. Mach messages could be preferable to Apple events: less chance of stepping on others' toes, perhaps? I really don't know the first thing about Mach messaging though. How big and complex a job would you guess a Mach messaging-based system would be, given the requirements above? >>Not trivial, and might get very sticky. > >I'd say the same thing about Python sub-interpreters. Of course. Like I say, there is no particularly good solution. If I thought the multi-process option would be trivial to do there wouldn't be any question, but it's not (especially not for me) so I'm just keeping my options wide open at this stage. >Python modules that use the PyGILState macros will likely be incompatible with anything that does sub-interpreters, and likely a lot of other ones will be too. Sub-interpreters get just shy of no testing whatsoever. Many extensions aren't going to like being initialized twice. PyObjC is definitely, without a doubt, going to barf with sub-interpreters. Other stuff probably will too. Yep. The next question is how significant these limitations would be for users, given the types of tasks OSA languages are actually used for (a fairly small list)? I suppose a reasonable parallel would be with mod_python, another specialised Python environment that manages to find sub-interpreters useful for all their caveats. Mind, it's not competing against standard MacPython but filling a separate niche, so lack of support for even something major like PyObjC may not be such an issue as it seems. Just as long as it doesn't lack support for Carbon.AE...;) Compared to the IPC option, which I know is a big technical job, how much work and complexity would there be in implementing a sub-interpreter solution? If it's the sort of thing that could be gotten up and running in a few dozen lines of code then I'd be very tempted to do that for now. (mod_python might even provide a useful template for doing this; I'd need to look.) Even if it's only a stopgap measure to be subsequently be reworked at leisure for IPC, at least it'd give us something we can ship. Or will it be just as big and complex as the IPC option? >>>Redirecting I/O at all sounds like a bad idea in the first place. >> >>stdin/stdout/stderr have no meaning within OSA: > >Yeah, they have no meaning -- so why bother mapping them to something else? Because 'print' in Python serves pretty much the same purpose as 'log' in AppleScript, and since Python prints to stdout it seems logical to redirect stdout to send log events to the host process instead. It can still go to Console as well if folks think that'd be useful. The primary goal is to make MacPythonOSA a good OSA citizen, even when it means diverging from conventional Python behaviour; any useful Unixisms we can retain on top of its OSA-ness are simply a bonus. Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Apr 11 21:53:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 11 21:53:44 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: References: <5563a9346cfa15dd9dc78b883974d465@redivi.com> <386410748069ee99ea8900aeca25d21f@redivi.com> <2cffecafd45e093d4232277052607f2b@redivi.com> Message-ID: <018465137efa55cc7606fbfec4dbb8db@redivi.com> On Apr 11, 2005, at 12:15 PM, has wrote: > Bob wrote: > >>> - OSA uses Component Manager - not Apple events - to communicate >>> with language components, so the MacPythonOSA component would need >>> to handle each OSA call, stuff its arguments into an IPC message, >>> send the message to the script daemon to process and wait for its >>> response. (This is just the easy bit, btw.) >>> >>> - In addition, the daemon also has to be able to send various >>> messages to the OSA component to be handled there concurrently: >>> CallActiveProc, CreateAppleEvent, SendAppleEvent, >>> RedispatchAppleEvent. >>> >>> - Finally, it needs to do all this without any support from the >>> client app and without treading on its toes in any way. And, very >>> preferably, without an onerous IPC overhead that would limit its >>> usefulness. >> >> Python over IPC is going to be way faster than AppleScript ever was. > > Python+aem's actually a bit slower than AppleScript given most of the > data conversion and event packing/unpacking is done in Python rather > than C. (Not much though.) I think the main bottlenecks for AE-based > IPC lie elsewhere; AS is guilty of a lot of things but I don't believe > this is one of them. Yes, the brokering of messages to and from an application may be marginally faster in AS, but everything else is slow. >> Mach is good at IPC anyway. > > Mach messages could be preferable to Apple events: less chance of > stepping on others' toes, perhaps? I really don't know the first thing > about Mach messaging though. > > How big and complex a job would you guess a Mach messaging-based > system would be, given the requirements above? You really shouldn't do mach directly, use sockets. Apple events use mach ports to do IPC on a single machine anyway. >>> Not trivial, and might get very sticky. >> >> I'd say the same thing about Python sub-interpreters. > > Of course. Like I say, there is no particularly good solution. If I > thought the multi-process option would be trivial to do there wouldn't > be any question, but it's not (especially not for me) so I'm just > keeping my options wide open at this stage. Well if you think that sub-interpreters are going to be any easier, you're mistaken. >> Python modules that use the PyGILState macros will likely be >> incompatible with anything that does sub-interpreters, and likely a >> lot of other ones will be too. Sub-interpreters get just shy of no >> testing whatsoever. Many extensions aren't going to like being >> initialized twice. PyObjC is definitely, without a doubt, going to >> barf with sub-interpreters. Other stuff probably will too. > > Yep. The next question is how significant these limitations would be > for users, given the types of tasks OSA languages are actually used > for (a fairly small list)? I suppose a reasonable parallel would be > with mod_python, another specialised Python environment that manages > to find sub-interpreters useful for all their caveats. Mind, it's not > competing against standard MacPython but filling a separate niche, so > lack of support for even something major like PyObjC may not be such > an issue as it seems. Just as long as it doesn't lack support for > Carbon.AE...;) > > Compared to the IPC option, which I know is a big technical job, how > much work and complexity would there be in implementing a > sub-interpreter solution? If it's the sort of thing that could be > gotten up and running in a few dozen lines of code then I'd be very > tempted to do that for now. (mod_python might even provide a useful > template for doing this; I'd need to look.) Even if it's only a > stopgap measure to be subsequently be reworked at leisure for IPC, at > least it'd give us something we can ship. Or will it be just as big > and complex as the IPC option? PyObjC support *is* a big deal. Presumably people will be wanting to call into Mac OS X APIs from scripts that run in Mac applications! >>>> Redirecting I/O at all sounds like a bad idea in the first place. >>> >>> stdin/stdout/stderr have no meaning within OSA: >> >> Yeah, they have no meaning -- so why bother mapping them to something >> else? > > Because 'print' in Python serves pretty much the same purpose as 'log' > in AppleScript, and since Python prints to stdout it seems logical to > redirect stdout to send log events to the host process instead. It can > still go to Console as well if folks think that'd be useful. The > primary goal is to make MacPythonOSA a good OSA citizen, even when it > means diverging from conventional Python behaviour; any useful > Unixisms we can retain on top of its OSA-ness are simply a bonus. So put something in the script's namespace that's called "log" and make it do what log does. -bob From rowen at cesmail.net Mon Apr 11 22:08:28 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Mon Apr 11 22:10:19 2005 Subject: [Pythonmac-SIG] Re: Keymap file for WingIDE References: Message-ID: In article , Charles Hartman wrote: > That is really, really helpful. I've been using Custom Key Bindings for > this, because my first attempt to make a keymap file didn't work well. > This is much cleaner (though it has the temporary disadvantage that > Wing has to be restarted for each change in the keymap). Actually, you can easily reload a keymap file (as per a helpful hint from Wing tech support). Just select the default keymap, click "Apply", then select "Override with..." and click "Apply" or "OK". > Thanks for doing this. I hope you've told Wing Tech Support about it. > (They're extraordinarily helpful.) I did and they said they were already working on such a file. They sent it to me and even incorporated some suggested I had. I have updated the file I am serving accordingly (with a few additional changes): I agree that Wing tech suport is amazing. WingIDE is a really nice program, as well. -- Russell From rowen at cesmail.net Mon Apr 11 22:12:48 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Mon Apr 11 22:25:05 2005 Subject: [Pythonmac-SIG] Re: ANN: MacEnthon 0.1 References: <4259FC05.9070008@ucsd.edu> Message-ID: In article <4259FC05.9070008@ucsd.edu>, Robert Kern wrote: > MacEnthon is the OS X counterpart to the popular "Enthought Edition" of > Python: a convenient bundling of a number of packages geared for the > scientific community. Right now, it targets the Apple-installed Python > 2.3.0. Once I am satisfied with this release, I will consider cutting a > release for Python 2.4.1. This is still just a test release. Please do > not tell newbies to go install it, yet. This looks amazing. Thank you very much. I have a lot of this stuff installed already and am wondering if I should risk it now or not, but I"ll certainly be using it in the future. -- Russell From rkern at ucsd.edu Mon Apr 11 23:23:28 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Apr 11 23:23:34 2005 Subject: [Pythonmac-SIG] Re: ANN: MacEnthon 0.1 In-Reply-To: References: <4259FC05.9070008@ucsd.edu> Message-ID: <425AEAD0.8030005@ucsd.edu> [Someday, I'll figure out how to work a mail program. Sorry for the repeats, Russell.] Russell E. Owen wrote: > In article <4259FC05.9070008@ucsd.edu>, Robert Kern wrote: > > >> MacEnthon is the OS X counterpart to the popular "Enthought Edition" >> of Python: a convenient bundling of a number of packages geared for >> the scientific community. Right now, it targets the Apple-installed >> Python 2.3.0. Once I am satisfied with this release, I will consider >> cutting a release for Python 2.4.1. This is still just a test >> release. Please do not tell newbies to go install it, yet. > > This looks amazing. Thank you very much. > > I have a lot of this stuff installed already and am wondering if I > should risk it now or not, but I"ll certainly be using it in the > future. I'm pretty sure that installing MacEnthon over top won't do much harm, but some of the stragglers might cause some weird but rare bugs (especially if there's code that does "try: import _something_old; except ImportError: etc."). It would be best if you moved the stuff already installed out of the way first. If they were installed from bdist_mpkg installers, you can use enthonbegone.py to remove them. $ pwd /Volumes/MacEnthon-0.1/Uninstaller $ ./enthonbegone.py -s /Library/Receipts/Numeric-platlib-23.7.pkg Starting MacEnthon Uninstaller Directories to delete: /Library/Python/2.3/Numeric Directories that will not be deleted: /Library/Python/2.3 $ sudo ./enthonbegone.py --logfile uninstall.log \ /Library/Receipts/Numeric-platlib-23.7.pkg ... -- 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 eichin at metacarta.com Mon Apr 11 23:32:18 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: Mon Apr 11 23:32:20 2005 Subject: [Pythonmac-SIG] ANN: AquaMacs distribution of Emacs In-Reply-To: <6e4f4322102ecf680fde104310557182@laposte.net> References: <42556146.50107@wordtech-software.com> <6e4f4322102ecf680fde104310557182@laposte.net> Message-ID: <7gu0md6lul.fsf@pikespeak.metacarta.com> > This looked promising, so I tested it - for about five minutes. This > beast is less ergonomic than standard Emacs and less ergonomic than It does look like it is an attempt at "emacs for mac users" which is very different than "mac-emacs for emacs users". Your review makes it very clear why I wouldn't want to use it either, but I'm a little odd :-) I'd been using fink emacs because it had X11 support and thus "better" meta key handling and color than the native tty-only one... and recently switched to Carbon Emacs: http://home.att.ne.jp/alpha/z123/emacs-mac-e.html because it got me nice anti-aliased fonts and more screen real estate (turning off tool-bar mode turns off the *mac* toolbar too, which might scare people, but I love it), as well as a very useful "do-applescript" function. (Note that I'm using the February version, there's a new April version out that I haven't tried yet.) Python mode works (well, the Tim Peters one I grabbed off the net a while back, it doesn't look like this emacs includes one, oddly.) What I *really* want to try next is to see if I can build it with PyMacs support (embed a python interpreter deeply into emacs, a hack that Fran?ois Pinard came up with a couple of years back) but I haven't had the time... From rkern at ucsd.edu Tue Apr 12 00:40:43 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue Apr 12 00:40:49 2005 Subject: [Pythonmac-SIG] Re: ANN: MacEnthon 0.1 In-Reply-To: <0908545d47a4898b41eb8d9aa0c16540@earthlink.net> References: <4259FC05.9070008@ucsd.edu> <0908545d47a4898b41eb8d9aa0c16540@earthlink.net> Message-ID: <425AFCEB.9020007@ucsd.edu> Tom Pollard wrote: > Actually, I was wondering how safe it would be to install MacEnthon if I > already had a significant number of these packages installed? > Everything I have was either built locally against the standard system > Python 2.3 or installed from one of Bob Ippolito's binary packages. > Will MacEnthon overwrite my existing packages? It will overwrite pre-existing packages. It won't delete anything, though. You'll just end up with some straggler files that were in your version but not in mine. I believe this is more-or-less safe (that is, if you want my version and not your own). Best, of course, is to move the packages you have out of the way. > Or get installed > alongside them somehow? Will I be able to select which MacEnthon > packages are installed? Yes, look for the "Custom Install" button after you select the drive to install to. -- 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 tomp at earthlink.net Mon Apr 11 23:11:50 2005 From: tomp at earthlink.net (Tom Pollard) Date: Tue Apr 12 04:18:31 2005 Subject: [Pythonmac-SIG] Re: ANN: MacEnthon 0.1 In-Reply-To: References: <4259FC05.9070008@ucsd.edu> Message-ID: <0908545d47a4898b41eb8d9aa0c16540@earthlink.net> On Apr 11, 2005, at 4:12 PM, Russell E. Owen wrote: > Robert Kern wrote: >> MacEnthon is the OS X counterpart to the popular "Enthought Edition" >> of >> Python: a convenient bundling of a number of packages geared for the >> scientific community. Right now, it targets the Apple-installed Python >> 2.3.0. Once I am satisfied with this release, I will consider cutting >> a >> release for Python 2.4.1. This is still just a test release. Please do >> not tell newbies to go install it, yet. > > This looks amazing. Thank you very much. > > I have a lot of this stuff installed already and am wondering if I > should risk it now or not, but I"ll certainly be using it in the > future. Actually, I was wondering how safe it would be to install MacEnthon if I already had a significant number of these packages installed? Everything I have was either built locally against the standard system Python 2.3 or installed from one of Bob Ippolito's binary packages. Will MacEnthon overwrite my existing packages? Or get installed alongside them somehow? Will I be able to select which MacEnthon packages are installed? Thanks, Tom From janssen at parc.com Tue Apr 12 04:48:37 2005 From: janssen at parc.com (Bill Janssen) Date: Tue Apr 12 04:49:11 2005 Subject: [Pythonmac-SIG] Re: ANN: MacEnthon 0.1 In-Reply-To: Your message of "Mon, 11 Apr 2005 13:12:48 PDT." Message-ID: <05Apr11.194846pdt."58617"@synergy1.parc.xerox.com> Thanks for doing this, Robert. A couple of suggestions: I'd use omniORB (omniorb.sourceforge.net, LGPL/GPL) instead of Fnorb. It's a very well-done piece of software, it's Open Group certified, it's been updated more recently (by better than a year), and includes more tools. In addition, the omniORB page doesn't lie about what they are providing (Fnorb is not "a pure Python CORBA ORB", as it claims). PyGTK would be greatly appreciated if you included it. Bill From hengist.podd at virgin.net Tue Apr 12 13:54:26 2005 From: hengist.podd at virgin.net (has) Date: Tue Apr 12 13:54:45 2005 Subject: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0 In-Reply-To: <018465137efa55cc7606fbfec4dbb8db@redivi.com> References: <5563a9346cfa15dd9dc78b883974d465@redivi.com> <386410748069ee99ea8900aeca25d21f@redivi.com> <2cffecafd45e093d4232277052607f2b@redivi.com> <018465137efa55cc7606fbfec4dbb8db@redivi.com> Message-ID: Bob wrote: >>>Python over IPC is going to be way faster than AppleScript ever was. >> >>Python+aem's actually a bit slower than AppleScript given most of the data conversion and event packing/unpacking is done in Python rather than C. > >Yes, the brokering of messages to and from an application may be marginally faster in AS, but everything else is slow. Yep, the AS language itself is slow, but I don't care about AS being crap - I care about MacPythonOSA being not-crap. :) >>How big and complex a job would you guess a Mach messaging-based system would be, given the requirements above? > >You really shouldn't do mach directly, use sockets. Apple events use mach ports to do IPC on a single machine anyway. Further proof that this task _definitely_ needs to be done by somebody other than me. :) >>Yep. The next question is how significant these limitations would be for users, given the types of tasks OSA languages are actually used for (a fairly small list)? > >PyObjC support *is* a big deal. Presumably people will be wanting to call into Mac OS X APIs from scripts that run in Mac applications! Some will, some won't. (Those that do could just stuff the PyObjC bits into a scriptable FBA and call it from their OSA script. So it's not like it'd be impossible, just lame.) Lots of useful OSA scripts are actually quite trivial code-wise. Anyway... Truth to tell, after a month spent swearing at the atrocious lack of documentation on implementing OSA components, right now I don't really care much for dealing with the braindeadedness of the Python C API as well. I just want to get _something_ stuffed in there so I can call the project "finished" and kick it out the door; leave other folks to make improvements in their own time. I'll even kick it out with zero script insulation, no concurrent execution support and a big fat health warning if nothing decent turns up. Though if someone want to step up and give me an ETA on a code patch that'll meet the necessary requirements by whatever means they like, please do; it would be much better for users if MacPythonOSA could ship with a permanent solution already in place. Either way though I want it out the door soon; I've already got enough 18 month-old "slam-dunk" projects on my books as it is. :p >>>>>Redirecting I/O at all sounds like a bad idea in the first place. >> >>Because 'print' in Python serves pretty much the same purpose as 'log' in AppleScript > >So put something in the script's namespace that's called "log" and make it do what log does. Thought of that, but 'print' feels natural from the end-user's POV and 'log' does not. Duplicating existing functionality simply to avoid doing a bit of extra work is just a copout; it's the developer's problem to make the users' lives easy, not vice-versa. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From lee_cullens at mac.com Tue Apr 12 15:27:04 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Tue Apr 12 15:27:14 2005 Subject: [Pythonmac-SIG] MacPython 2.4.1 and GTK+ In-Reply-To: <5c6ab478aba34c763a2a6906724bfa59@mac.com> References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <2f4f83fe12fb301cac600685df80421b@redivi.com> <5c6ab478aba34c763a2a6906724bfa59@mac.com> Message-ID: Maybe these old eyes are just missing it, but I can't seem to satisfy my curiosity on the following: 1) Use of GTK+, PyGTK and Gazpacho with Python 2.4 in general 2) GTK+, PyGTK and Gazpacho binaries for Mac OS X in general and more specifically for MacPython 2.4.1 3) wxPython vs GTK+ as a starting point for developing multimedia apps (for building sophisticated multimedia presentations) potentially for cross platform - opinions anyone or maybe another course? Thanks, Lee C PS Regarding my earlier posts waffling on an IDE, I've settled in with WingIDE. Thanks for all your comments and opinions. From eichin at metacarta.com Tue Apr 12 17:34:19 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: Tue Apr 12 17:34:28 2005 Subject: [Pythonmac-SIG] Re: ANN: MacEnthon 0.1 In-Reply-To: <425AFCEB.9020007@ucsd.edu> References: <4259FC05.9070008@ucsd.edu> <0908545d47a4898b41eb8d9aa0c16540@earthlink.net> <425AFCEB.9020007@ucsd.edu> Message-ID: <7gpsx0dn5w.fsf@pikespeak.metacarta.com> > Actually, I was wondering how safe it would be to install MacEnthon > if I already had a significant number of these packages installed? You could probably hack the uninstall script to just scan for what's already there, and run it before installing MacEnthon, so you know what it is going to overwrite - that's what I'm planning to do (I know I've added some stuff like wx and appscript, but I'm sure I've added other little bits that I've forgotten) but it is low on my list just now... From gandreas at gandreas.com Tue Apr 12 17:53:15 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Tue Apr 12 17:53:19 2005 Subject: [Pythonmac-SIG] PyOXIDE wishes? Message-ID: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> Sometime between now and WWDC, I'm planning on coming out with a major update for PyOXIDE , and was wondering what sort of functionality others have been hoping for. Right now the list is largely bug fix related: Folding improvements Better tracking of breakpoints during editing A few crashes on initial saves/quits Update the PyOXIDE homepage and only a few new features: Out of process interactive interpreter support (which should allow interactive interpreters using a different version of python) "Non Blocking" debugger (hopefully - this is the "big ugly" since it requires some interesting threading support) So if you're looking for features/support, now's the time to ask... Glenn Andreas????????????????????? gandreas@gandreas.com? oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From Chris.Barker at noaa.gov Tue Apr 12 18:31:02 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Tue Apr 12 18:31:44 2005 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> References: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> Message-ID: <425BF7C6.6030209@noaa.gov> gandreas@gandreas.com wrote: > Sometime between now and WWDC, I'm planning on coming out with a major > update for PyOXIDE Glenn, I'm sure you've seen the recent threads her bemoaning the lack of good tools (particularly open-source ones) for newbies developing with Python on OS-X. PyOxide seems to be the obvious candidate for filling that void of a "Mac-like" IDE. I haven't tested it for a while, but it seems that bugs are the biggest issue, rather than missing features. Robustness is FAR more important that features, except to marketing folks. That being said: > Right > now the list is largely bug fix related: Very good news--focus on that! > and only a few new features: > Out of process interactive interpreter support (which should allow > interactive interpreters using a different version of python) This is the only new feature I encourage you to support. Different versions of Python are nice, but not critical, but running the user's code out-of-process is very important. As others on this list have mentioned (Bob I., in particular, a voice to be listened to), an IDE that runs the user code in the same interpreter as the IDE is dead in the water as a serious tool. That is the ONE thing that kept me from using PythonWin, the old IDLE, and MacPython IDE. Good luck, I'm very much looking forward to being able to recommend a robust IDE for OS-X. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From bob at redivi.com Tue Apr 12 19:24:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 12 19:24:38 2005 Subject: [Pythonmac-SIG] MacPython 2.4.1 and GTK+ In-Reply-To: References: <7b64106f164cbe3aa3d747d9520b9649@redivi.com> <2f4f83fe12fb301cac600685df80421b@redivi.com> <5c6ab478aba34c763a2a6906724bfa59@mac.com> Message-ID: <45fdcf4242f383adeae0018471878a72@redivi.com> On Apr 12, 2005, at 6:27 AM, Lee Cullens wrote: > Maybe these old eyes are just missing it, but I can't seem to satisfy > my curiosity on the following: > > 1) Use of GTK+, PyGTK and Gazpacho with Python 2.4 in general > > 2) GTK+, PyGTK and Gazpacho binaries for Mac OS X in general and more > specifically for MacPython 2.4.1 > > 3) wxPython vs GTK+ as a starting point for developing multimedia > apps (for building sophisticated multimedia presentations) potentially > for cross platform - opinions anyone or maybe another course? GTK is not available natively for Mac OS X, only for X11. I don't really plan on adding X11 packages to my repository. -bob From bob at redivi.com Tue Apr 12 19:26:10 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 12 19:26:15 2005 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> References: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> Message-ID: <4d0cc92560413644c92dc293144a4d31@redivi.com> On Apr 12, 2005, at 8:53 AM, gandreas@gandreas.com wrote: > Sometime between now and WWDC, I'm planning on coming out with a major > update for PyOXIDE , and was > wondering what sort of functionality others have been hoping for. > Right now the list is largely bug fix related: > Folding improvements > Better tracking of breakpoints during editing > A few crashes on initial saves/quits > Update the PyOXIDE homepage > > and only a few new features: > Out of process interactive interpreter support (which should allow > interactive interpreters using a different version of python) > "Non Blocking" debugger (hopefully - this is the "big ugly" since it > requires some interesting threading support) > > So if you're looking for features/support, now's the time to ask... If you write the debugger the same way you write the out of process interpreter, which you should, you don't have the threading problem any more. -bob From mathieu at garambrogne.net Tue Apr 12 20:49:18 2005 From: mathieu at garambrogne.net (Mathieu Lecarme) Date: Tue Apr 12 20:49:22 2005 Subject: [Pythonmac-SIG] webcam snapshot from Python Message-ID: <440b103237bffe03561ff4b221f7e650@garambrogne.net> There is a win32 project http://videocapture.sourceforge.net/ But on Mac Quicktime know how to grab picture from a webcam. HackTV seams to be a nice example for that. How can i take a picture (not a movie) from a webcam with macPython? I wait for QuickTime 7 and i use AppleEvents? M. From delza at livingcode.org Tue Apr 12 20:59:08 2005 From: delza at livingcode.org (Dethe Elza) Date: Tue Apr 12 20:59:13 2005 Subject: [Pythonmac-SIG] Hide application icon Message-ID: HI folks, I'm writing a statusbar app and don't want an icon to show up in the Dock. What is the correct way to hide/remove the icon? --Dethe What dark passions and ancient evils have been held in check by the grim totalitarianism of the profit motive? --Bruce Sterling -------------- 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/20050412/6285b8bf/smime-0001.bin From sw at wordtech-software.com Tue Apr 12 21:07:21 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Tue Apr 12 21:07:56 2005 Subject: [Pythonmac-SIG] PyOxide features wish list Message-ID: <425C1C69.2050909@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. py2app support. I believe it still supports bundlebuilder only? 2. Less crashiness. I can make PyOxide blow up consistently by typing # in the interpreter. The stuff I package is somewhat fragile/crashy, but nothing like that. - -- 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 iD8DBQFCXBxpJmdQs+6YVcoRAjd6AJ40FEImnQ2OmRFUyF4XsV9ED/G38gCeJXnG d+waV66d7Zas7n6jgx45wUk= =U3Nk -----END PGP SIGNATURE----- From enrike at altern.org Tue Apr 12 20:16:00 2005 From: enrike at altern.org (altern) Date: Tue Apr 12 21:15:13 2005 Subject: [Pythonmac-SIG] PyOXIDE wishes? In-Reply-To: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> References: <87c5ace5e7d3881e955b0b908e179051@gandreas.com> Message-ID: <425C1060.4090507@altern.org> hi probaly stupid request, but just wanted to say that on my spanish mac i cannot get the [ at all, so i am always copying and pasting from somewhere else. thanks. gandreas@gandreas.com wrote: > Sometime between now and WWDC, I'm planning on coming out with a major > update for PyOXIDE , and was > wondering what sort of functionality others have been hoping for. Right > now the list is largely bug fix related: > Folding improvements > Better tracking of breakpoints during editing > A few crashes on initial saves/quits > Update the PyOXIDE homepage > > and only a few new features: > Out of process interactive interpreter support (which should allow > interactive interpreters using a different version of python) > "Non Blocking" debugger (hopefully - this is the "big ugly" since it > requires some interesting threading support) > > So if you're looking for features/support, now's the time to ask... > > > Glenn Andreas gandreas@gandreas.com > oh my! > quadrium | build, mutate, evolve | images, textures, backgrounds, art > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- enrike From Martina at Oefelein.de Tue Apr 12 21:59:48 2005 From: Martina at Oefelein.de (Martina Oefelein) Date: Tue Apr 12 21:59:52 2005 Subject: [Pythonmac-SIG] Hide application icon In-Reply-To: References: Message-ID: Hi Dethe Elza: > I'm writing a statusbar app and don't want an icon to show up in the > Dock. What is the correct way to hide/remove the icon? set LSUIElement to "1" in your info.plist http://developer.apple.com/documentation/MacOSX/Conceptual/ BPRuntimeConfig/Concepts/PListKeys.html#//apple_ref/doc/uid/20001431/ TPXREF136 ciao Martina From delza at livingcode.org Tue Apr 12 22:46:04 2005 From: delza at livingcode.org (Dethe Elza) Date: Tue Apr 12 22:46:08 2005 Subject: [Pythonmac-SIG] Hide application icon In-Reply-To: References: Message-ID: Thanks! I thought I'd tried that, but my Info.plist wasn't getting picked up. I blew away dist/ and build/ and rebuilt with -P Info.plist and it worked. I'll work up a simple statusbar example for the PyObjC examples if there's any interest. --Dethe On 12-Apr-05, at 12:59 PM, Martina Oefelein wrote: > Hi Dethe Elza: > >> I'm writing a statusbar app and don't want an icon to show up in the >> Dock. What is the correct way to hide/remove the icon? > > set LSUIElement to "1" in your info.plist > > http://developer.apple.com/documentation/MacOSX/Conceptual/ > BPRuntimeConfig/Concepts/PListKeys.html#//apple_ref/doc/uid/20001431/ > TPXREF136 > > > ciao > Martina > > Email is where knowledge goes to die. --Bill French -------------- 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/20050412/e55e1651/smime.bin From bob at redivi.com Tue Apr 12 23:11:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 12 23:11:27 2005 Subject: [Pythonmac-SIG] Hide application icon In-Reply-To: References: Message-ID: <4df52a4d38136c0b2db2bdb083095689@redivi.com> On Apr 12, 2005, at 1:46 PM, Dethe Elza wrote: > On 12-Apr-05, at 12:59 PM, Martina Oefelein wrote: > >> Hi Dethe Elza: >> >>> I'm writing a statusbar app and don't want an icon to show up in the >>> Dock. What is the correct way to hide/remove the icon? >> >> set LSUIElement to "1" in your info.plist >> >> http://developer.apple.com/documentation/MacOSX/Conceptual/ >> BPRuntimeConfig/Concepts/PListKeys.html#//apple_ref/doc/uid/20001431/ >> TPXREF136 >> > Thanks! I thought I'd tried that, but my Info.plist wasn't getting > picked up. I blew away dist/ and build/ and rebuilt with -P > Info.plist and it worked. > > I'll work up a simple statusbar example for the PyObjC examples if > there's any interest. Yes please.. if you do it soon, I'll throw it in the next release of PyObjC. -bob From delza at livingcode.org Tue Apr 12 23:58:07 2005 From: delza at livingcode.org (Dethe Elza) Date: Tue Apr 12 23:58:12 2005 Subject: [Pythonmac-SIG] Hide application icon In-Reply-To: <4df52a4d38136c0b2db2bdb083095689@redivi.com> References: <4df52a4d38136c0b2db2bdb083095689@redivi.com> Message-ID: I'll try to get that to you tonight then. --Dethe On 12-Apr-05, at 2:11 PM, Bob Ippolito wrote: > > On Apr 12, 2005, at 1:46 PM, Dethe Elza wrote: > >> On 12-Apr-05, at 12:59 PM, Martina Oefelein wrote: >> >>> Hi Dethe Elza: >>> >>>> I'm writing a statusbar app and don't want an icon to show up in >>>> the Dock. What is the correct way to hide/remove the icon? >>> >>> set LSUIElement to "1" in your info.plist >>> >>> http://developer.apple.com/documentation/MacOSX/Conceptual/ >>> BPRuntimeConfig/Concepts/PListKeys.html#//apple_ref/doc/uid/ >>> 20001431/TPXREF136 >>> >> Thanks! I thought I'd tried that, but my Info.plist wasn't getting >> picked up. I blew away dist/ and build/ and rebuilt with -P >> Info.plist and it worked. >> >> I'll work up a simple statusbar example for the PyObjC examples if >> there's any interest. > > Yes please.. if you do it soon, I'll throw it in the next release of > PyObjC. > > -bob > > A miracle, even if it's a lousy miracle, is still a miracle. --Teller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2488 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050412/c459c842/smime.bin From brendansimons at yahoo.ca Wed Apr 13 06:21:31 2005 From: brendansimons at yahoo.ca (Brendan Simons) Date: Wed Apr 13 06:21:40 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 24, Issue 23 In-Reply-To: <20050412185938.6E8651E400E@bag.python.org> References: <20050412185938.6E8651E400E@bag.python.org> Message-ID: <38ec1394d1be34078cb7ffdf1de60642@yahoo.ca> OK I'll bite The crash-fixes, and out-of-process debugger are by far the most important improvements. I think anything else you accomplish after that is gravy There are some UI issues I'd like cleaned up eventually. For instance: - I have no idea what the IDE console does, and it's a confusing thing to display as the default app window. A more HIG-compliant behaviour would be to display a blank editor window, with perhaps an interactive session behind. - The editor window should remember my view settings between sessions (ie, whether I displayed lines, invisible characters etc) - I would love a tree-view pane of classes and functions in an open module. The treeview that comes with Mark Hammonds Pythonwin even displays inherited class methods, which is really handy for opening new files - When debugging, an uncaught exception should not only display the stack trace, but also the state of all local variables at each level in the stack. I can send you a screenshot of RealBasic's debugger to give you an idea of how intuitive this interface is. - There's a white vertical bar at the right edge of your (otherwise really attractive) application icon. - What's a module browser? That's all I can come up with on the top of my head. I haven't had much chance to use PyOxide that much because the version I have crashes before I can get it to run any of my scripts. I look forward to your revision! -Brendan -- Brendan Simons On 12-Apr-05, at 2:59 PM, pythonmac-sig-request@python.org wrote: > From: "Chris Barker" > Date: April 12, 2005 12:31:02 PM EDT > To: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] PyOXIDE wishes? > > > gandreas@gandreas.com wrote: >> Sometime between now and WWDC, I'm planning on coming out with a >> major update for PyOXIDE > > Glenn, > > I'm sure you've seen the recent threads her bemoaning the lack of good > tools (particularly open-source ones) for newbies developing with > Python on OS-X. PyOxide seems to be the obvious candidate for filling > that void of a "Mac-like" IDE. I haven't tested it for a while, but it > seems that bugs are the biggest issue, rather than missing features. > Robustness is FAR more important that features, except to marketing > folks. > > That being said: > > Right >> now the list is largely bug fix related: > > Very good news--focus on that! > >> and only a few new features: >> Out of process interactive interpreter support (which should >> allow interactive interpreters using a different version of python) > > This is the only new feature I encourage you to support. Different > versions of Python are nice, but not critical, but running the user's > code out-of-process is very important. As others on this list have > mentioned (Bob I., in particular, a voice to be listened to), an IDE > that runs the user code in the same interpreter as the IDE is dead in > the water as a serious tool. That is the ONE thing that kept me from > using PythonWin, the old IDLE, and MacPython IDE. > > Good luck, I'm very much looking forward to being able to recommend a > robust IDE for OS-X. > > -Chris > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker@noaa.gov > > From delza at livingcode.org Wed Apr 13 08:17:55 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Apr 13 08:18:00 2005 Subject: [Pythonmac-SIG] Simple Statusitem example Message-ID: <07b819daccdfefa9b23ec79380bcbc6b@livingcode.org> Here is a very simple example of a statusbar item, requiring no further resources. A real statusitem would probably have a Nib to load a menu and maybe a configuration panel from, icons, etc. ================ begin statusitem.py ====================== import objc from Foundation import * from AppKit import * from PyObjCTools import NibClassBuilder, AppHelper start_time = NSDate.date() class Timer(NSObject): ''' Application delegate ''' statusbar = None def applicationDidFinishLaunching_(self, notification): print 'timer launched' # Make the statusbar item statusbar = NSStatusBar.systemStatusBar() # if you use an icon, the length can be NSSquareStatusItemLength statusitem = statusbar.statusItemWithLength_(NSVariableStatusItemLength) self.statusitem = statusitem # Need to retain this for later # statusitem.setImage_(some_image) #statusitem.setMenu_(some_menu) statusitem.setToolTip_('Seconds since startup') statusitem.setAction_('terminate:') # must have some way to exit self.timer = NSTimer.alloc().initWithFireDate_interval_target_selector_userInfo_repea ts_( start_time, 1.0, self, 'display:', None, True ) NSRunLoop.currentRunLoop().addTimer_forMode_(self.timer, NSDefaultRunLoopMode) self.timer.fire() def display_(self, notification): print 'display:' self.statusitem.setTitle_(elapsed()) def elapsed(): return str(int(NSDate.date().timeIntervalSinceDate_(start_time))) if __name__ == "__main__": app = NSApplication.sharedApplication() delegate = Timer.alloc().init() app.setDelegate_(delegate) AppHelper.runEventLoop() ====================== end statusitem.py ================================ The main thing about the setup file is to pass LSUIElement = '1' in the plist to suppress the dock icon. The program should perhaps hide itself as well. ====================== begin setup.py ================================== ''' Minimal setup.py example, run with: % python setup.py py2app ''' from distutils.core import setup import py2app NAME = 'Uptime' SCRIPT = 'statusitem.py' VERSION = '0.1' ID = 'uptime' plist = dict( CFBundleName = NAME, CFBundleShortVersionString = ' '.join([NAME, VERSION]), CFBundleGetInfoString = NAME, CFBundleExecutable = NAME, CFBundleIdentifier = 'org.livingcode.examples.%s' % ID, LSUIElement = '1' ) app_data = dict(script=SCRIPT, plist=plist) setup( app = [app_data], ) ====================== end setup.py ==================================== --Dethe Windows has detected the mouse has moved. Please restart your system for changes to take effect. -------------- 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/20050412/ea18e28b/smime.bin From Henning.Ramm at mediapro-gmbh.de Wed Apr 13 08:22:31 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Wed Apr 13 08:22:30 2005 Subject: [Pythonmac-SIG] PyOXIDE wishes? Message-ID: >So if you're looking for features/support, now's the time to ask... Some more information on the homepage would be nice, too. Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From delza at livingcode.org Wed Apr 13 17:46:19 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Apr 13 17:46:23 2005 Subject: [Pythonmac-SIG] Simple Statusitem example In-Reply-To: <07b819daccdfefa9b23ec79380bcbc6b@livingcode.org> References: <07b819daccdfefa9b23ec79380bcbc6b@livingcode.org> Message-ID: <9b4ca1a0aaa363c43140548723c1be7e@livingcode.org> Replying to myself... In another thread, Bob suggests waiting until the 29th to release PyObjC 1.3.1, so I guess I have a little more time to work on this example. Perhaps I'll keep this as a dirt simple example, and work up a more realistic one with an icon, menu, and dialog. I had about an hour last night to knock this together, which stretched out a little longer because I'd never used NSTimer before. Are there any examples people would like to see? What would actually be *useful* to show in the status bar? ITunes and clocks have been done to death, but I'm sure there's something that would be nice to have which would make a good example. --Dethe On 12-Apr-05, at 11:17 PM, Dethe Elza wrote: > Here is a very simple example of a statusbar item, requiring no > further resources. A real statusitem would probably have a Nib to > load a menu and maybe a configuration panel from, icons, etc. > > ================ begin statusitem.py ====================== > > import objc > from Foundation import * > from AppKit import * > from PyObjCTools import NibClassBuilder, AppHelper > > start_time = NSDate.date() > > > class Timer(NSObject): > ''' > Application delegate > ''' > statusbar = None > > def applicationDidFinishLaunching_(self, notification): > print 'timer launched' > # Make the statusbar item > statusbar = NSStatusBar.systemStatusBar() > # if you use an icon, the length can be > NSSquareStatusItemLength > statusitem = > statusbar.statusItemWithLength_(NSVariableStatusItemLength) > self.statusitem = statusitem # Need to retain this for later > # statusitem.setImage_(some_image) > #statusitem.setMenu_(some_menu) > statusitem.setToolTip_('Seconds since startup') > statusitem.setAction_('terminate:') # must have some way to > exit > self.timer = > NSTimer.alloc().initWithFireDate_interval_target_selector_userInfo_repe > ats_( > start_time, > 1.0, > self, > 'display:', > None, > True > ) > NSRunLoop.currentRunLoop().addTimer_forMode_(self.timer, > NSDefaultRunLoopMode) > self.timer.fire() > > def display_(self, notification): > print 'display:' > self.statusitem.setTitle_(elapsed()) > > > def elapsed(): > return str(int(NSDate.date().timeIntervalSinceDate_(start_time))) > > if __name__ == "__main__": > app = NSApplication.sharedApplication() > delegate = Timer.alloc().init() > app.setDelegate_(delegate) > AppHelper.runEventLoop() > > ====================== end statusitem.py > ================================ > > The main thing about the setup file is to pass LSUIElement = '1' in > the plist to suppress the dock icon. > The program should perhaps hide itself as well. > > ====================== begin setup.py > ================================== > > ''' > Minimal setup.py example, run with: > % python setup.py py2app > ''' > > from distutils.core import setup > import py2app > > NAME = 'Uptime' > SCRIPT = 'statusitem.py' > VERSION = '0.1' > ID = 'uptime' > > plist = dict( > CFBundleName = NAME, > CFBundleShortVersionString = ' '.join([NAME, VERSION]), > CFBundleGetInfoString = NAME, > CFBundleExecutable = NAME, > CFBundleIdentifier = 'org.livingcode.examples.%s' % ID, > LSUIElement = '1' > ) > > > app_data = dict(script=SCRIPT, plist=plist) > > setup( > app = [app_data], > ) > > ====================== end setup.py > ==================================== > > --Dethe > > > Windows has detected the mouse has moved. Please restart your system > for changes to take > effect._______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > "Isn't 'A guy tried to smuggle plutonium from Tajikistan into Afganistan or Pakistan' just a fancy way of saying 'Live for the moment?'" --Get Your War On -------------- 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/20050413/1a1a5d5b/smime.bin From delza at livingcode.org Wed Apr 13 19:23:02 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed Apr 13 19:23:06 2005 Subject: [Pythonmac-SIG] Simple Statusitem example In-Reply-To: References: <07b819daccdfefa9b23ec79380bcbc6b@livingcode.org> <9b4ca1a0aaa363c43140548723c1be7e@livingcode.org> Message-ID: <68468b0e6ab37b0eedbe6a0643cec0c2@livingcode.org> Hi Tom, Thanks, that sounds like a good example. I'll take a look at it. Any others out there? --Dethe On 13-Apr-05, at 9:36 AM, Tom Pollard wrote: > Hi Dethe, > > You asked: >> Are there any examples people would like to see? What would actually >> be *useful* to show in the status bar? ITunes and clocks have been >> done to death, but I'm sure there's something that would be nice to >> have which would make a good example. > > How about a network activity icon, something like what's in the > Windows tray? Currently, you have to open the Network preferences > panel to see whether you've got a network connection. It sometimes > takes a few minutes to get a DHCP address from my office network when > I connect first the laptop in the morning, and I've wished there was a > way to see easily when the network comes up (besides seeing whether I > can load a web page.) > > Tom > > "Ambiguity, calculated or generative, as a means of discontinuous organization, at first seems familiar to us" -- Pain Not Bread, An introduction to Du Fu -------------- 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/20050413/9302140e/smime.bin From eichin at metacarta.com Wed Apr 13 19:52:57 2005 From: eichin at metacarta.com (eichin@metacarta.com) Date: Wed Apr 13 19:53:10 2005 Subject: [Pythonmac-SIG] Simple Statusitem example In-Reply-To: <9b4ca1a0aaa363c43140548723c1be7e@livingcode.org> References: <07b819daccdfefa9b23ec79380bcbc6b@livingcode.org> <9b4ca1a0aaa363c43140548723c1be7e@livingcode.org> Message-ID: <7gpswy36o6.fsf@pikespeak.metacarta.com> > Are there any examples people would like to see? What would actually > be *useful* to show in the status bar? ITunes and clocks have been Assuming I'm not confused and the "status bar" is the same as the "right side of the menu bar", http://menu.jeweledplatypus.org/ has a long list of examples that might be useful ideas. One that came to mind as "easy" is a pop- or imap-mailbox "how much new mail" checker - you could just use the native imaplib to do the work, *that* part would only be a dozen lines of code, but it would need "periodic update", "allow user configuration", and ideally "store password in keychain", all of which are mac-specific in interesting ways. A "weather bug" is another one; the general "check this web page for changes" (based on an xpath string or even a regexp scan) would be a useful base, you could build a "current nagios status (red/yellow/green)" scraper out of that... even a stock-watcher, though it's about 5 years too late for that :-) From ml at fgranger.com Thu Apr 14 12:34:23 2005 From: ml at fgranger.com (Fran=?ISO-8859-1?B?5w==?=ois Granger) Date: Thu Apr 14 12:34:22 2005 Subject: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 24, Issue 23 In-Reply-To: <38ec1394d1be34078cb7ffdf1de60642@yahoo.ca> Message-ID: Le 13/04/05 6:21, ??Brendan Simons?? a ?crit?: > - I would love a tree-view pane of classes and functions in an open > module. The treeview that comes with Mark Hammonds Pythonwin even > displays inherited class methods, which is really handy for opening new > files > > - When debugging, an uncaught exception should not only display the > stack trace, but also the state of all local variables at each level in > the stack. I can send you a screenshot of RealBasic's debugger to give > you an idea of how intuitive this interface is. Another good exemple of these features is the way it is done in PytonIDE. -- Convert from markup to markup: http://fgranger.net1.nerim.net/mtom/ From smichr at bigfoot.com Fri Apr 15 18:02:25 2005 From: smichr at bigfoot.com (Chris Smith) Date: Fri Apr 15 18:03:16 2005 Subject: [Pythonmac-SIG] timeit and import problem Message-ID: I was recently trying to use the timeit module and although I was able to do so without problem on a Windows machine, I get a "cannot import y1" ImportError from the following script. ### import timeit def y1(): print 'y1 executed' def y2(): print 'y2 executed' for f in [y1,y2]: name = f.__name__ print name; f() t=timeit.Timer('%s()' % name, 'from __main__ import %s' % name) print t.timeit(1) ### --the output-- y1 y1 executed ** ImportError I am using the IDE for 2.3.3 under OS X (10.2.8). I am able to successfully run timeit in other ways, but I like the above way to loop through the codes that I want to test. /c From Jack.Jansen at cwi.nl Sat Apr 16 23:06:14 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Apr 16 23:06:19 2005 Subject: [Pythonmac-SIG] webcam snapshot from Python In-Reply-To: <440b103237bffe03561ff4b221f7e650@garambrogne.net> References: <440b103237bffe03561ff4b221f7e650@garambrogne.net> Message-ID: <223e116dd0fbe780427ca0dbe37e4bf7@cwi.nl> On 12-apr-05, at 20:49, Mathieu Lecarme wrote: > There is a win32 project http://videocapture.sourceforge.net/ > But on Mac Quicktime know how to grab picture from a webcam. HackTV > seams to be a nice example for that. > How can i take a picture (not a movie) from a webcam with macPython? The Quicktime module should be able to do this, if you're using 2.4.1. If you're still using 2.3 you can download and install the new Quicktime module through Package Manager or from Bob's package list. For the documentation you read Apple's C quicktime docs, and remember that a C function like "FooBarMovie(Movie *m, int x, int y)" will be represented in Python as a method of the Movie object, i.e. call m.FooBarMovie(x, y). And the same question as I asked in a similar thread last week: the quicktime module should be able to handle capturing, but I've never had any feedback that it actually works. So please report back here. -- 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 enrike at altern.org Sun Apr 17 12:30:31 2005 From: enrike at altern.org (altern) Date: Sun Apr 17 14:23:32 2005 Subject: [Pythonmac-SIG] changging inheritance on the fly? Message-ID: <42623AC7.4060904@altern.org> hi probably a bit offtopic since it is nothing mac specific but i didnt know where to ask. is it possible to change the superclass a class inherits from on the fly? for example i have this class inheriting from Top but i want it to inherit later on the fly from another class living in another module. I am doing this below but it doesnt work, 'm' doesnt change. Maybe i have to define the class Test on the fly to achive this? but i dont like much to do that. any other suggestions? thanks #this is what i am doing now: import mymodule as m def start(): import othermodule as m class Test(m.Top): def __init__(self): pass thanks!! -- enrike From bob at redivi.com Sun Apr 17 14:26:32 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Apr 17 14:26:38 2005 Subject: [Pythonmac-SIG] changging inheritance on the fly? In-Reply-To: <42623AC7.4060904@altern.org> References: <42623AC7.4060904@altern.org> Message-ID: <7867e15f9462a683031efab69839baa5@redivi.com> On Apr 17, 2005, at 6:30 AM, altern wrote: > probably a bit offtopic since it is nothing mac specific but i didnt > know where to ask. > > is it possible to change the superclass a class inherits from on the > fly? > for example i have this class inheriting from Top but i want it to > inherit later on the fly from another class living in another module. > I am doing this below but it doesnt work, 'm' doesnt change. Maybe i > have to define the class Test on the fly to achive this? but i dont > like much to do that. any other suggestions? thanks Probably, but don't. What you're doing is best done other ways. -bob From mwh at python.net Sun Apr 17 19:42:36 2005 From: mwh at python.net (Michael Hudson) Date: Sun Apr 17 19:42:37 2005 Subject: [Pythonmac-SIG] changging inheritance on the fly? In-Reply-To: <42623AC7.4060904@altern.org> (altern's message of "Sun, 17 Apr 2005 12:30:31 +0200") References: <42623AC7.4060904@altern.org> Message-ID: <2mpswt9u5v.fsf@starship.python.net> altern writes: > hi > > probably a bit offtopic since it is nothing mac specific but i didnt > know where to ask. python-list? > is it possible to change the superclass a class inherits from on the fly? You can assign to __bases__. > for example i have this class inheriting from Top but i want it to > inherit later on the fly from another class living in another > module. I am doing this below but it doesnt work, 'm' doesnt > change. Maybe i have to define the class Test on the fly to achive > this? but i dont like much to do that. any other suggestions? thanks > > #this is what i am doing now: > > import mymodule as m > > def start(): > import othermodule as m > > class Test(m.Top): > def __init__(self): > pass The way you ask the question suggests you don't know Python especially well. As Bob says, there are likely better ways to acheive your goal. Cheers, mwh -- But since I'm not trying to impress anybody in The Software Big Top, I'd rather walk the wire using a big pole, a safety harness, a net, and with the wire not more than 3 feet off the ground. -- Grant Griffin, comp.lang.python From enrike at altern.org Sun Apr 17 21:16:26 2005 From: enrike at altern.org (altern) Date: Sun Apr 17 22:15:21 2005 Subject: [Pythonmac-SIG] changging inheritance on the fly? In-Reply-To: <2mpswt9u5v.fsf@starship.python.net> References: <42623AC7.4060904@altern.org> <2mpswt9u5v.fsf@starship.python.net> Message-ID: <4262B60A.1040304@altern.org> Michael Hudson wrote: > altern writes: > > >>hi >> >>probably a bit offtopic since it is nothing mac specific but i didnt >>know where to ask. > > > python-list? > > >>is it possible to change the superclass a class inherits from on the fly? > > > You can assign to __bases__. > > >>for example i have this class inheriting from Top but i want it to >>inherit later on the fly from another class living in another >>module. I am doing this below but it doesnt work, 'm' doesnt >>change. Maybe i have to define the class Test on the fly to achive >>this? but i dont like much to do that. any other suggestions? thanks >> >>#this is what i am doing now: >> >>import mymodule as m >> >>def start(): >> import othermodule as m >> >>class Test(m.Top): >> def __init__(self): >> pass > > > The way you ask the question suggests you don't know Python especially > well. As Bob says, there are likely better ways to acheive your goal. any tips about those other ways? i am reading pattern design books tring to find some way to do what i need, i know there must be some way but i am not a computer programmer myself, i keep learning... thanks! > Cheers, > mwh > -- enrike From Chris.Barker at noaa.gov Mon Apr 18 08:53:55 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Apr 18 08:54:01 2005 Subject: [Pythonmac-SIG] changging inheritance on the fly? In-Reply-To: <4262B60A.1040304@altern.org> References: <42623AC7.4060904@altern.org> <2mpswt9u5v.fsf@starship.python.net> <4262B60A.1040304@altern.org> Message-ID: <42635983.7020601@noaa.gov> altern wrote: > Michael Hudson wrote: >> The way you ask the question suggests you don't know Python especially >> well. As Bob says, there are likely better ways to acheive your goal. > > any tips about those other ways? A) this is more of a topic for comp.lang.python, but as long s we're here... B) We can't help you without knowing what it is you're trying to do. No one needs to "change the base class of a class" for it's own sake. Clearly, you have something you need to accomplich, and you thought that might be a way to do it. If you tell us what you need to accomplish, we might be able to suggest a way to do it. C) just guessing, but maybe what you want is a factory function, which will create the class you need on the fly. A search for "factory" and python should get you something. -Chris From konrad.hinsen at laposte.net Mon Apr 18 15:40:16 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon Apr 18 15:40:08 2005 Subject: [Pythonmac-SIG] Package installation Message-ID: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> While installing some Mac applications, I wondered if Python package installation could not be just as simple as application installation: copy a bundle to some folder (/Applications/PythonPackages or /Library/Python or whatever) and use it. For updating, throw away the old bundle and install the new one. For test-driving a new version, put it into a test directory that has priority on the search path. No installers, no passwords, and always a clear view of what is installed. Unless I have overlooked something, this should require no more than 1) A modified import procedure for MacPython 2) A new document bundle format for Python packages 3) Perhaps some clever code that caches bundle information for efficiency in imports. An added advantage of specific bundles would be the possibility to include binary modules for different Python versions in one bundle, transparent to the user, although this would only work in practice for a few agreed-upon Python versions that packager would be required to have. So now my question to the Mac veterans: does this sound realistic? And desirable? Konrad. From bob at redivi.com Mon Apr 18 15:51:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 18 15:51:27 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> Message-ID: <8560572880ee2d57f0de43509bffc405@redivi.com> On Apr 18, 2005, at 9:40 AM, konrad.hinsen@laposte.net wrote: > While installing some Mac applications, I wondered if Python package > installation could not be just as simple as application installation: > copy a bundle to some folder (/Applications/PythonPackages or > /Library/Python or whatever) and use it. For updating, throw away the > old bundle and install the new one. For test-driving a new version, > put it into a test directory that has priority on the search path. No > installers, no passwords, and always a clear view of what is > installed. > > Unless I have overlooked something, this should require no more than > 1) A modified import procedure for MacPython > 2) A new document bundle format for Python packages > 3) Perhaps some clever code that caches bundle information for > efficiency in imports. > > An added advantage of specific bundles would be the possibility to > include binary modules for different Python versions in one bundle, > transparent to the user, although this would only work in practice for > a few agreed-upon Python versions that packager would be required to > have. > > So now my question to the Mac veterans: does this sound realistic? And > desirable? 4) Hundreds of hours spent pushing a new format to the rest of the Python world 5) Thousands of hours spent modifying existing distutils scripts and software to deal with it, since it wouldn't be compatible with the way that things normally work, many packages will need special treatment. The advantage that bdist_mpkg has is that it's compatible with anything distutils-based and require no source changes (to either the setup script or the package itself). Most of the time, if you click on a package from http://pythonmac.org/packages/ Safari will unzip it and open the installer right up... Is it really that hard? Can users be trusted to put Python packages in the right place on their own? If they have multiple versions of Python installed? I would say no. -bob From konrad.hinsen at laposte.net Mon Apr 18 17:12:52 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon Apr 18 17:12:40 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <8560572880ee2d57f0de43509bffc405@redivi.com> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> Message-ID: <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> On Apr 18, 2005, at 15:51, Bob Ippolito wrote: > 4) Hundreds of hours spent pushing a new format to the rest of the > Python world The Python world would not care, the packages bundles would be created with some tool based on distutils, just like py2app does today. Only the Mac Python world would be concerned/ > 5) Thousands of hours spent modifying existing distutils scripts and > software to deal with it, since it wouldn't be compatible with the way > that things normally work, many packages will need special treatment. Good point. How many packages out there do non-standard things in their setup.py that concern the subsequent packaging? I don't know. > The advantage that bdist_mpkg has is that it's compatible with > anything distutils-based and require no source changes (to either the > setup script or the package itself). Most of the time, if you click > on a package from http://pythonmac.org/packages/ Safari will unzip it > and open the installer right up... Is it really that hard? No. The problem I have with it is not installation, but version management. Finding out what versions of what packages are installed is not straightforward. Removing a package requires knowledge that the average Mac user doesn't have. Installing a package that was already installed will happily overwrite files, and might silently downgrade an installation or even create an inconsistent installation. Of course these problems are the same for other Mac libraries, but at least for Python we could do something about it. > Can users be trusted to put Python packages in the right place on > their own? If they have multiple versions of Python installed? I > would say no. They do manage for applications, so why wouldn't they for Python packages? Konrad -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr --------------------------------------------------------------------- From bob at redivi.com Mon Apr 18 17:43:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 18 17:43:29 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: On Apr 18, 2005, at 11:12 AM, konrad.hinsen@laposte.net wrote: > On Apr 18, 2005, at 15:51, Bob Ippolito wrote: > >> 4) Hundreds of hours spent pushing a new format to the rest of the >> Python world > > The Python world would not care, the packages bundles would be created > with some tool based on distutils, just like py2app does today. Only > the Mac Python world would be concerned/ Unfortunately it's not that simple because you want to change the way the runtime works. >> 5) Thousands of hours spent modifying existing distutils scripts and >> software to deal with it, since it wouldn't be compatible with the >> way that things normally work, many packages will need special >> treatment. > > Good point. How many packages out there do non-standard things in > their setup.py that concern the subsequent packaging? I don't know. Too many. >> The advantage that bdist_mpkg has is that it's compatible with >> anything distutils-based and require no source changes (to either the >> setup script or the package itself). Most of the time, if you click >> on a package from http://pythonmac.org/packages/ Safari will unzip it >> and open the installer right up... Is it really that hard? > > No. The problem I have with it is not installation, but version > management. Finding out what versions of what packages are installed > is not straightforward. Removing a package requires knowledge that the > average Mac user doesn't have. Installing a package that was already > installed will happily overwrite files, and might silently downgrade > an installation or even create an inconsistent installation. > > Of course these problems are the same for other Mac libraries, but at > least for Python we could do something about it. I don't think that Installer will silently downgrade stuff. Packages that create inconsistent installations on upgrade are pretty rare. Removing packages is just not something that needs to happen very often, and when you actually need to do it, you probably know perfectly well how to do it. >> Can users be trusted to put Python packages in the right place on >> their own? If they have multiple versions of Python installed? I >> would say no. > > They do manage for applications, so why wouldn't they for Python > packages? Take a look at the archives and see how many people run into problems with multiple Python installations, etc. All that said, if you still think it's worth doing then go write some code. Ideas aren't worth much around here without an implementation. It's entirely possible that I'm just jaded from dealing with packaging issues the past few years and your proposal is more practical and easier than I think it will be. -bob From konrad.hinsen at laposte.net Mon Apr 18 18:01:23 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon Apr 18 18:01:30 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: On 18.04.2005, at 17:43, Bob Ippolito wrote: > Unfortunately it's not that simple because you want to change the way > the runtime works. But only by adding a strategy for searching for packages. Those who don't use it will never find out. > I don't think that Installer will silently downgrade stuff. Packages > that create Does it keep track of version numbers then? The Apple docs are quite silent about the installer. > inconsistent installations on upgrade are pretty rare. Removing > packages is just not something that needs to happen very often, and > when you actually need to do it, you probably know perfectly well how > to do it. Removing is indeed frequent only as a step in updating. There are cases where an update requires removing the old version first, e.g. when a module has been replaced by a subpackage of the same name. > Take a look at the archives and see how many people run into problems > with multiple Python installations, etc. Isn't that mostly because of MacPython and Fink Python being installed in parallel? Fink Python wouldn't be concerned at all. > All that said, if you still think it's worth doing then go write some > code. That was my plan, but it's always good to check first if there are some evident problems that were overlooked. Konrad. -- ------------------------------------------------------------------------ ------- Konrad Hinsen Laboratoire Leon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr ------------------------------------------------------------------------ ------- From Chris.Barker at noaa.gov Mon Apr 18 18:02:21 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Apr 18 18:03:26 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: <4263DA0D.7070600@noaa.gov> konrad.hinsen@laposte.net wrote: >> Can users be trusted to put Python packages in the right place on >> their own? If they have multiple versions of Python installed? I >> would say no. > > They do manage for applications, so why wouldn't they for Python packages? No, they don't. Mac users put Applications all over the place on their systems. In fact, one of the main advantages of the self contained application bundle is that you can do exactly that: put it anywhere, and you can click on it to run it. The old Macintosh was specifically designed to support that kind of behavior. They advertised the fact that files could be moved all over the place without disrupting the system (this wasn't entirely true, when it came to the system folder, but it was a lot more true than with Unix or DOS/Windows). That legacy lives on. If you don't give Mac users an installer, many, many, people will drop a bundle some arbitrary place, and expect it to work. That being said, better uninstallation and version managing would be great. This is one place that Apple is WAY behind the Linux distros. They all have package managing systems, many of them pretty darn nice. I'd love to see some kind of package versioning management built into things from the Python side, one that will work across platforms. wxPython has a pretty good approach: http://wiki.wxpython.org/index.cgi/MultiVersionInstalls -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov From delza at livingcode.org Mon Apr 18 18:09:25 2005 From: delza at livingcode.org (Dethe Elza) Date: Mon Apr 18 18:09:25 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: On 18-Apr-05, at 8:12 AM, konrad.hinsen@laposte.net wrote: > No. The problem I have with it is not installation, but version > management. Finding out what versions of what packages are installed > is not straightforward. If the problem is version management, the solution may not be to build a new installer process. Encouraging vendors to add metadata to their distutils scripts for a) version, and b) a URL to check for updates, would be useful. A good place to start would be to build a tool which goes through python installed libraries and attempts to determine the version of each, reporting back with all the versions (and a list of libraries for which version couldn't be determined). Another low-tech solution would be to start a wiki page with known latest versions, urls to download the latest versions, and the above script. No reinvention of the wheel needed, just leveraging what we already have in a different way. --Dethe When laws are outlawed, only outlaws will have laws. From bob at redivi.com Mon Apr 18 18:18:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 18 18:19:08 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: <5a6311f05011080b87c6fd97541cd814@redivi.com> On Apr 18, 2005, at 12:09 PM, Dethe Elza wrote: > On 18-Apr-05, at 8:12 AM, konrad.hinsen@laposte.net wrote: > >> No. The problem I have with it is not installation, but version >> management. Finding out what versions of what packages are installed >> is not straightforward. > > If the problem is version management, the solution may not be to build > a new installer process. Encouraging vendors to add metadata to their > distutils scripts for a) version, and b) a URL to check for updates, > would be useful. A good place to start would be to build a tool which > goes through python installed libraries and attempts to determine the > version of each, reporting back with all the versions (and a list of > libraries for which version couldn't be determined). Another low-tech > solution would be to start a wiki page with known latest versions, > urls to download the latest versions, and the above script. No > reinvention of the wheel needed, just leveraging what we already have > in a different way. Which would be nice, except distutils preserves no metadata at all upon installation. -bob From bob at redivi.com Mon Apr 18 18:24:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 18 18:24:48 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: <3b9219d5b62b8b01c4aea5821ad420a1@redivi.com> On Apr 18, 2005, at 12:01 PM, konrad.hinsen@laposte.net wrote: > On 18.04.2005, at 17:43, Bob Ippolito wrote: > >> Unfortunately it's not that simple because you want to change the way >> the runtime works. > > But only by adding a strategy for searching for packages. Those who > don't use it will never find out. That doesn't work for scripts, headers, dependent libraries, etc. distutils has to know how to find the headers, users have to know how to find the scripts so they can put them in their PATH, dependent libraries have to go somewhere (i.e. wxPython -> wxWidgets, pygame -> SDL, SDL_*), etc. >> I don't think that Installer will silently downgrade stuff. Packages >> that create > > Does it keep track of version numbers then? The Apple docs are quite > silent about the installer. Apple has plenty of docs on the installer, the format it uses, what happens during an installation, etc. Yes, the version number is in the receipt. >> inconsistent installations on upgrade are pretty rare. Removing >> packages is just not something that needs to happen very often, and >> when you actually need to do it, you probably know perfectly well how >> to do it. > > Removing is indeed frequent only as a step in updating. There are > cases where an update requires removing the old version first, e.g. > when a module has been replaced by a subpackage of the same name. Yes, there are cases where that happens, but they're rare. It's both possible and reasonable to do this from a preflight upgrade script in an installer package for those special cases. >> Take a look at the archives and see how many people run into problems >> with multiple Python installations, etc. > > Isn't that mostly because of MacPython and Fink Python being installed > in parallel? Fink Python wouldn't be concerned at all. No, not really. Search the archives. -bob From konrad.hinsen at laposte.net Mon Apr 18 18:47:23 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Mon Apr 18 18:47:25 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: <4c895b78ed80d574e495221dfdb78723@laposte.net> On 18.04.2005, at 18:09, Dethe Elza wrote: > new installer process. Encouraging vendors to add metadata to their > distutils scripts for a) version, and b) a URL to check for updates, > would be Most do, but the data is not kept in the installation. > useful. A good place to start would be to build a tool which goes > through python installed libraries and attempts to determine the > version of each, I would say that's impossible. One installation unit can contain any number of modules and packages, and one package can contain the contents of more than one installation unit. > couldn't be determined). Another low-tech solution would be to start > a wiki page with known latest versions, urls to download the latest > versions, and Something better already exists, the Python Package Index. Unfortunately many packages are not in it, and others are listed with outdated versions. That of course points to the major problem of all attempts at handling Python packages: acceptance. There even still packages around that don't use distutils. Konrad. -- ------------------------------------------------------------------------ ------- Konrad Hinsen Laboratoire Leon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr ------------------------------------------------------------------------ ------- From bob at redivi.com Mon Apr 18 18:49:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 18 18:49:26 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <4c895b78ed80d574e495221dfdb78723@laposte.net> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> <4c895b78ed80d574e495221dfdb78723@laposte.net> Message-ID: <083b6061aa5a4b490db32dbe0345c89a@redivi.com> On Apr 18, 2005, at 12:47 PM, konrad.hinsen@laposte.net wrote: >> couldn't be determined). Another low-tech solution would be to start >> a wiki page with known latest versions, urls to download the latest >> versions, and > > Something better already exists, the Python Package Index. > Unfortunately many packages are not in it, and others are listed with > outdated versions. > > That of course points to the major problem of all attempts at handling > Python packages: acceptance. There even still packages around that > don't use distutils. Yup, there are. PyKQueue is/was one of them! The Makefile didn't even work on Mac OS X. I submitted a setup.py to the maintainer that does work on OS X (and presumably still FreeBSD) just this weekend. -bob From lee_cullens at mac.com Mon Apr 18 18:51:59 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Mon Apr 18 18:52:04 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> Message-ID: <7d3fab8f6c3870278aea6f7596889b5d@mac.com> On Apr 18, 2005, at 12:09 PM, Dethe Elza wrote: > > Another low-tech solution would be to start a wiki page with known > latest versions, urls to download the latest versions, and the above > script. No reinvention of the wheel needed, just leveraging what we > already have in a different way. > > --Dethe > Isn't this what Bob is doing with http://pythonmac.org/packages/ Being new to this "playground" my concern is the next round of versions since they will likely be applicable by the time I get really productive. Say if Apple goes to 2.4 then what about Bob's build, and subsequently Bob's(?) 2.5 (__future__) build? I for one would like a more transparent and manageable versioning. I don't want to move things around (I'll play by the rules), but I would like to be able to add new versions and remove old versions of Python and components combined. As I understand it, such is what Bob did with 2.4, but what he did is not overly obvious to me (I understand Bob is working within the conventions and constraints of the Mac OS X implementation) and the additional learning curve distracts from the finished app package (at my age without the time of youth one gets more focused :~). My 2 cents, Lee C From bob at redivi.com Mon Apr 18 19:18:16 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 18 19:18:23 2005 Subject: [Pythonmac-SIG] Package installation In-Reply-To: <7d3fab8f6c3870278aea6f7596889b5d@mac.com> References: <261f9b43217bd5d1f811dc8e912bab81@laposte.net> <8560572880ee2d57f0de43509bffc405@redivi.com> <4977b4b1180146f1a2ce2a2d224ef8c9@laposte.net> <7d3fab8f6c3870278aea6f7596889b5d@mac.com> Message-ID: On Apr 18, 2005, at 12:51 PM, Lee Cullens wrote: > > On Apr 18, 2005, at 12:09 PM, Dethe Elza wrote: > >> >> Another low-tech solution would be to start a wiki page with known >> latest versions, urls to download the latest versions, and the above >> script. No reinvention of the wheel needed, just leveraging what we >> already have in a different way. > > Isn't this what Bob is doing with http://pythonmac.org/packages/ More or less, minus the script, and any metadata beyond the canonical URL, name, and version. > Being new to this "playground" my concern is the next round of > versions since they will likely be applicable by the time I get really > productive. Say if Apple goes to 2.4 then what about Bob's build, and > subsequently Bob's(?) 2.5 (__future__) build? Unless you explicitly screw things up by setting PYTHONPATH or running stuff with the wrong python interpreter, then what Apple does and what other people do are completely separate. The build bugs were fixed in Python 2.3.5 and Python 2.4.1. Of course, since 10.3 ships with 2.3.0, then it needs to be patched (PantherPythonFix). That said, on Mac OS X 10.3+ builds of things, the extensions are actually portable amongst Python interpreters of the same version since they don't directly link to a Python library... so it would be possible to share the same set of extensions between two Python 2.3.x (though I'm not sure why you would want to have two Python 2.3.x installed in the first place). > I for one would like a more transparent and manageable versioning. I > don't want to move things around (I'll play by the rules), but I would > like to be able to add new versions and remove old versions of Python > and components combined. As I understand it, such is what Bob did > with 2.4, but what he did is not overly obvious to me (I understand > Bob is working within the conventions and constraints of the Mac OS X > implementation) and the additional learning curve distracts from the > finished app package (at my age without the time of youth one gets > more focused :~). I didn't do anything special, I built Python 2.4.1, unmodified. The problems in the past were bugs in Python that have been squashed. -bob From smichr at bigfoot.com Thu Apr 21 06:15:35 2005 From: smichr at bigfoot.com (Chris Smith) Date: Thu Apr 21 06:16:41 2005 Subject: [Pythonmac-SIG] Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: Message-ID: <027ED692-B21C-11D9-B60E-000393C0D100@bigfoot.com> On Tuesday, Apr 19, 2005, Lee Cullens wrote: > I assume you mean PythonIDE for Python 2.3 (I usually use 2.4 and > WingIDE). Here it is (indents screwed up with var font): > > HTH, > Lee C > >> import timeit >> def y1(): >> print ?y1 executed? >> def y2(): >> print ?y2 executed? >> for f in [y1,y2]: >> name = f.__name__ >> print name; f() >> t=timeit.Timer(?%s()? % name, ?from __main__ import %s? % name) >> print t.timeit(1) I wrote this yesterday.... ------------------ Well, how bizarre! Now I run the code again (after having restarted the PythonIDE) and now I can't get it to NOT work. And it previously had not run for many tries. I don't suppose this is some sort of quantum effect ;-) Oh well, I'll keep my eyes open to see if this happens again. ------------------ And now today, the problem is back again :-( What's going on? Here is a smaller code: ### def y1(): print 'y1 executed' for f in [y1]: name = f.__name__ f() s1 = '%s()' % name s2 = 'from __main__ import %s' % name t=timeit.Timer(s1, s2) print t.timeit(1) ### Here is the full report from the traceback window {it's great to be able to cut and paste from that window, thanks Just} ''' ImportError: cannot import name y1 Traceback (innermost last) File "", line 10, in ? File "timeit.py", line 158, in timeit return self.inner(it, self.timer) File "", line 3, in inner ''' ** If I click on the edit button it says that cannot be found. Is this an error to pay attention to or is that an unrelated problem of trying to browse a (perhaps compiled) source file? Here is what I've tried to reproduce the problem: 1) I have restarted the system (10.2.8) and run nothing but this script and still get the error. 2) removed my PythonStartup and sitecustomize.py codes after quitting; problem still persists 3) re-installed MacPython 2.3.3 after moving the old version's macPython 2.3.3 folder to the desktop 4) I have tried running the script in the add with and without the "run as __main__" option. I DO NOT have the error show up when I run the script through the Terminal (i.e. %python timeitproblem.py). I also DO NOT have the problem if I run the script with PyOXIDE. As noted yesterday, there are some unknown steps that make the problem go away, though I do not know what these are yet. Does anyone else have any insights? /c From smiles at saysomething.com Thu Apr 21 06:47:46 2005 From: smiles at saysomething.com (Christopher Smith) Date: Thu Apr 21 06:48:42 2005 Subject: [Pythonmac-SIG] pyoxide 0.7.1 crashes on startup Message-ID: <81A6E27A-B220-11D9-B60E-000393C0D100@saysomething.com> I was able to run the 0.6 version of pyoxide, but neither 0.7 nor 0.7.1 are running (for very long) for me. They start up, show me the releasenotes.rtf text for about 3 seconds and then the application quits "unexpectedly". Does anyone know how to work around this or what might be causing this problem? running mac os 10.2.8 python 2.3.3 framework installed /c From Y.Benita at pharm.uu.nl Thu Apr 21 16:06:11 2005 From: Y.Benita at pharm.uu.nl (Yair Benita) Date: Thu Apr 21 21:10:59 2005 Subject: [Pythonmac-SIG] python slowing down on large files Message-ID: Hi All, I am using python 2.3 on Panther and have a question. I use python to read a huge 1Gb text file, one line at a time. For each line a functions is performed and the result is written to an output file. No information should accumulate as the file is being read and yet, the first few thousands line go very very fast and then the program slows down gradually. Any idea what could go wrong. I can't think of any memory leak as most of the script is fairly simple. Also, looking at the Activity Monitor I don't see that it takes huge amounts of RAM and there is plenty of free memory available. Thanks, Yair Benita From bob at redivi.com Thu Apr 21 21:16:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Apr 21 21:16:50 2005 Subject: [Pythonmac-SIG] python slowing down on large files In-Reply-To: References: Message-ID: <4e9b7d08b6636239b08911428263867e@redivi.com> On Apr 21, 2005, at 10:06 AM, Yair Benita wrote: > I am using python 2.3 on Panther and have a question. > I use python to read a huge 1Gb text file, one line at a time. > For each line a functions is performed and the result is written to an > output file. No information should accumulate as the file is being > read and > yet, the first few thousands line go very very fast and then the > program > slows down gradually. > Any idea what could go wrong. I can't think of any memory leak as most > of > the script is fairly simple. Also, looking at the Activity Monitor I > don't > see that it takes huge amounts of RAM and there is plenty of free > memory > available. Test with Python 2.4.1. Panther's 2.3.0 is quite old and has a few known bugs (though none that would cause this behavior that I know of). If you get the same results with 2.4.1 then post the script. Presumably if it's not a Python 2.3.0 bug, then doing something wrong, and we can only guess what that is unless you show the script. -bob From gandreas at gandreas.com Thu Apr 21 22:16:33 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Thu Apr 21 22:16:37 2005 Subject: [Pythonmac-SIG] pyoxide 0.7.1 crashes on startup In-Reply-To: <81A6E27A-B220-11D9-B60E-000393C0D100@saysomething.com> References: <81A6E27A-B220-11D9-B60E-000393C0D100@saysomething.com> Message-ID: <08da07b4ee6b7c2eec7b8da073aefdde@gandreas.com> On Apr 20, 2005, at 11:47 PM, Christopher Smith wrote: > I was able to run the 0.6 version of pyoxide, but neither 0.7 nor > 0.7.1 are running (for very long) for me. They start up, show me the > releasenotes.rtf text for about 3 seconds and then the application > quits "unexpectedly". Does anyone know how to work around this or what > might be causing this problem? > > running mac os 10.2.8 > python 2.3.3 framework installed > > /c > I don't have a 10.2.x system handy to do any testing on, so not sure how much help I can give, but do you have a crash log from when it fails? That might help me figure out what's going on... Glenn Andreas????????????????????? gandreas@gandreas.com? oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From smichr at bigfoot.com Fri Apr 22 03:06:47 2005 From: smichr at bigfoot.com (Chris Smith) Date: Fri Apr 22 06:48:21 2005 Subject: [Pythonmac-SIG] Re: Weird import problem with PythonIDE on Mac (was 'import problem') Message-ID: ### def y1(): pass def foo(): from __main__ import y1 pass foo() ### Here is a version of the code, stripped of the timeit code. The above segment exhibits the same symptoms as the previously submitted one. Even though I am running this as "__main__" it behaves as though it is not __main__. i.e. if I run this with pyOxide without the 'run as __main__' option, it generates the same ImportError ('Can't import y1') as it does when run in the PythonIDE. In the pythonIDE it generates the error whether the 'run as __main__' option is on or off. As a test of that option, I verified that the following code only runs when the __main__ option is on and it worked as expected: ### if __name__=='__main__': print 'running as main' ### /c From bob at redivi.com Fri Apr 22 07:21:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 22 07:21:30 2005 Subject: [Pythonmac-SIG] Re: Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: References: Message-ID: <69019775ddec78595d1aef38394f20a3@redivi.com> On Apr 21, 2005, at 9:06 PM, Chris Smith wrote: > ### > def y1(): > pass > def foo(): > from __main__ import y1 > pass > foo() > ### > > Here is a version of the code, stripped of the timeit code. The above > segment exhibits the same symptoms as the previously submitted one. > > Even though I am running this as "__main__" it behaves as though it is > not __main__. i.e. if I run this with pyOxide without the 'run as > __main__' option, it generates the same ImportError ('Can't import > y1') as it does when run in the PythonIDE. > > In the pythonIDE it generates the error whether the 'run as __main__' > option is on or off. As a test of that option, I verified that the > following code only runs when the __main__ option is on and it worked > as expected: The issue probably lies with the fact that (definitely) PythonIDE and (probably) PyOXIDE have the dumbest possible implementation of an interactive interpreter. They use the *same interpreter* that runs the IDE itself. Since the module namespace is flat, there can only be one __main__, and it belongs to the IDE. This is the least of the issues you will experience when using such an interpreter. Wing and IDLE don't have this problem, last I checked. Other than that, I have no idea which IDEs are stupid and which are not. -bob From Jack.Jansen at cwi.nl Fri Apr 22 10:31:11 2005 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Apr 22 10:31:35 2005 Subject: [Pythonmac-SIG] Re: Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: References: Message-ID: <3d415fdeb32d3619ac81ad0bc8ad6e18@cwi.nl> On 22 Apr 2005, at 03:06, Chris Smith wrote: > ### > def y1(): > pass > def foo(): > from __main__ import y1 > pass > foo() > ### > > Here is a version of the code, stripped of the timeit code. The above > segment exhibits the same symptoms as the previously submitted one. > > Even though I am running this as "__main__" it behaves as though it is > not __main__. i.e. if I run this with pyOxide without the 'run as > __main__' option, it generates the same ImportError ('Can't import > y1') as it does when run in the PythonIDE. > > In the pythonIDE it generates the error whether the 'run as __main__' > option is on or off. As a test of that option, I verified that the > following code only runs when the __main__ option is on and it worked > as expected: > > ### > if __name__=='__main__': > print 'running as main' > ### As always, reading the source provides the answer. If you look in PyEdit.py, method Editor.execstring(), you'll see that the only thing "run as __main__" does is set the module name to "__main__". It does *not* change the globals dictionary to __main__. I'm not sure about the reasoning behind this, I think Just wanted to make sure that if you had two edit windows open both with "run as __main__" selected they didn't influence each other. On the other hand I can imageine that if you do that, open two windows in __main__ mode, the behaviour you want is exactly that. Just? -- 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 Y.Benita at pharm.uu.nl Fri Apr 22 10:38:41 2005 From: Y.Benita at pharm.uu.nl (Yair Benita) Date: Fri Apr 22 10:38:44 2005 Subject: [Pythonmac-SIG] Upgrading to 2.4.1 Message-ID: Upgrading to a new version of python is always tricky as I have many many modules that may not work properly after upgrading (biopython, etc.). If I install the new python 2.4.1 from the installer package provided, will it co-exist with my python 2.3.3 or will it replace it? If it co-exist how do I control which one is used when simply typing /usr/bin/python at the command line? Thanks, Yair From Y.Benita at pharm.uu.nl Fri Apr 22 10:52:22 2005 From: Y.Benita at pharm.uu.nl (Yair Benita) Date: Fri Apr 22 10:52:25 2005 Subject: [Pythonmac-SIG] python slowing down on large files In-Reply-To: <4e9b7d08b6636239b08911428263867e@redivi.com> Message-ID: Hi Bob, Thanks for the tips. It a bit tricky to put the script as its a bit complex. Its build in a way that there is a class that makes all calculations and returns the output. Lets simplify: class objX: def __init__(self, params): .... def method1 (self): .... def method2(self): .... def __str__(self): the output I need ## now there is a loop that reads the file file = open(path, "r") for line in file.xreadlines(): x, y, z = line.split() NewObj = objX(x,y,z) NewObj.method1() NewObj.method2() print NewObj file.close() As you can see nothing should be stored. The objX class may contain whatever methods needed and make complex calculations but it is reused after each line is read. Right? Suppose there is a memory leak in one of the methods. Shouldn't it be released once a new line is read and an object with the exact same name is created? Is it possible that the NewObj created after each line doesn't removed from memory the previous NewObj? Yair on 21/4/2005 21:16, Bob Ippolito at bob@redivi.com wrote: > > On Apr 21, 2005, at 10:06 AM, Yair Benita wrote: > >> I am using python 2.3 on Panther and have a question. >> I use python to read a huge 1Gb text file, one line at a time. >> For each line a functions is performed and the result is written to an >> output file. No information should accumulate as the file is being >> read and >> yet, the first few thousands line go very very fast and then the >> program >> slows down gradually. >> Any idea what could go wrong. I can't think of any memory leak as most >> of >> the script is fairly simple. Also, looking at the Activity Monitor I >> don't >> see that it takes huge amounts of RAM and there is plenty of free >> memory >> available. > > Test with Python 2.4.1. Panther's 2.3.0 is quite old and has a few > known bugs (though none that would cause this behavior that I know of). > If you get the same results with 2.4.1 then post the script. > Presumably if it's not a Python 2.3.0 bug, then doing something wrong, > and we can only guess what that is unless you show the script. > > -bob > From bob at redivi.com Fri Apr 22 10:52:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 22 10:52:33 2005 Subject: [Pythonmac-SIG] Upgrading to 2.4.1 In-Reply-To: References: Message-ID: <18691bb8759c14d70ee2f651a6ae18ed@redivi.com> On Apr 22, 2005, at 4:38 AM, Yair Benita wrote: > Upgrading to a new version of python is always tricky as I have many > many > modules that may not work properly after upgrading (biopython, etc.). None of them will work. They will all have to be re-installed for the new version of Python. > If I install the new python 2.4.1 from the installer package provided, > will > it co-exist with my python 2.3.3 or will it replace it? co-exist, unless you broke it somehow (i.e. using PYTHONPATH, etc.). > If it co-exist how do I control which one is used when simply typing > /usr/bin/python at the command line? NEVER EVER change anything in /usr (except /usr/local) or /System. DO NOT EVER DO THAT. BAD. What you probably want to change is the PATH environment variable. Search the archives. -bob From just at letterror.com Fri Apr 22 10:52:47 2005 From: just at letterror.com (Just van Rossum) Date: Fri Apr 22 10:53:04 2005 Subject: [Pythonmac-SIG] Re: Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: <3d415fdeb32d3619ac81ad0bc8ad6e18@cwi.nl> Message-ID: Jack Jansen wrote: > As always, reading the source provides the answer. > > If you look in PyEdit.py, method Editor.execstring(), you'll see that > the only thing "run as __main__" does is set the module name to > "__main__". It does *not* change the globals dictionary to __main__. > > I'm not sure about the reasoning behind this, I think Just wanted to > make sure that if you had two edit windows open both with "run as > __main__" selected they didn't influence each other. On the other hand > I can imageine that if you do that, open two windows in __main__ mode, > the behaviour you want is exactly that. It largely as Bob wrote: you can't do this sanely if the script runs in the same process as the IDE. And what you said: I don't want __main__ scripts to share a namespace. The "Run as __main__" feature is intended to support the if __name__ == "__main__" idiom, nothing else. Importing __main__ is a very silly thing to do anyway, if you ask me. Just From whamoo at rknet.it Fri Apr 22 12:19:00 2005 From: whamoo at rknet.it (whamoo) Date: Fri Apr 22 12:19:08 2005 Subject: [Pythonmac-SIG] It is normal in python2.3 shipped with apple? Message-ID: i'm writing a program that must use the python 2.3 shipped with apple, and i'm using the plistlib, but seem that the panther native version of python doesn't have module named utils.iso8601..... Can someome confirm this please? I'm get this error with the base ship python: Traceback (most recent call last): File "ratto/script/iphoto.py", line 31, in ? pl = plistlib.Plist.fromFile( iPhotoPlist ) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/plistlib.py", line 212, in fromFile plist = p.parse(pathOrFile) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/plistlib.py", line 303, in parse parser.ParseFile(file) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/plistlib.py", line 315, in handleEndElement handler() File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/plistlib.py", line 374, in end_date self.addObject(Date(self.getData())) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/plistlib.py", line 270, in __init__ from xml.utils.iso8601 import parse ImportError: No module named utils.iso8601 Obviously i don't have this error on python2.4 thanks for help Whamoo From smichr at bigfoot.com Fri Apr 22 12:41:11 2005 From: smichr at bigfoot.com (Chris Smith) Date: Fri Apr 22 12:42:15 2005 Subject: [Pythonmac-SIG] Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: Message-ID: <0AE73573-B31B-11D9-9F38-000393C0D100@bigfoot.com> On Friday, Apr 22, 2005, at 03:52 America/Chicago, Just van Rossum - just@letterror.com wrote: > Importing __main__ is a very silly thing to do anyway, if you ask me. > All comments from you, Bob, and Jack have been *very* helpful. I think I understand better what is going on. What's got me scratching my head is that I thought it worked several at one time, but I must have been misunderstanding what script was actually being run. (?) Anyway, as to importing from main, I was trying to learn to use the timeit module and wanted to be able to pass functions to it (rather than literal strings of code). The init of timeit takes the strings you pass and creates a function that is exec'ed. Do you have a suggestion as to what can I give a module so it has enough information to execute a function that resides in __main__? Here is a visual of what is going on: ------__main__ def y1(): pass import foo foo.run(string_from_main) #what should I pass? ------external module, foo def run(string_from_main): # exec(string_from_main) #y1 is run as if it were in __main__ /c From just at letterror.com Fri Apr 22 13:10:44 2005 From: just at letterror.com (Just van Rossum) Date: Fri Apr 22 13:10:48 2005 Subject: [Pythonmac-SIG] It is normal in python2.3 shipped with apple? In-Reply-To: Message-ID: whamoo wrote: > i'm writing a program that must use the python 2.3 shipped with > apple, and i'm using the plistlib, but seem that the panther native > version of python doesn't have module named utils.iso8601..... Can > someome confirm this please? Correct. The 2.3 plistlib depends on PyXML for iso8601, and even then support for that is spotty. However, you can grab 2.4's plistlib from CVS: http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/ Lib/plat-mac/plistlib.py Just From gandreas at gandreas.com Fri Apr 22 15:03:25 2005 From: gandreas at gandreas.com (gandreas@gandreas.com) Date: Fri Apr 22 15:03:28 2005 Subject: [Pythonmac-SIG] Re: Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: <69019775ddec78595d1aef38394f20a3@redivi.com> References: <69019775ddec78595d1aef38394f20a3@redivi.com> Message-ID: On Apr 22, 2005, at 12:21 AM, Bob Ippolito wrote: > > On Apr 21, 2005, at 9:06 PM, Chris Smith wrote: > >> ### >> def y1(): >> pass >> def foo(): >> from __main__ import y1 >> pass >> foo() >> ### >> >> Here is a version of the code, stripped of the timeit code. The >> above segment exhibits the same symptoms as the previously submitted >> one. >> >> Even though I am running this as "__main__" it behaves as though it >> is not __main__. i.e. if I run this with pyOxide without the 'run as >> __main__' option, it generates the same ImportError ('Can't import >> y1') as it does when run in the PythonIDE. >> >> In the pythonIDE it generates the error whether the 'run as __main__' >> option is on or off. As a test of that option, I verified that the >> following code only runs when the __main__ option is on and it worked >> as expected: > > The issue probably lies with the fact that (definitely) PythonIDE and > (probably) PyOXIDE have the dumbest possible implementation of an > interactive interpreter. They use the *same interpreter* that runs > the IDE itself. Since the module namespace is flat, there can only be > one __main__, and it belongs to the IDE. This is the least of the > issues you will experience when using such an interpreter. > PyOXIDE has the option of running as an internal interpreter or an external interpreter. Running internally allows for more interactive development since you can spawn interactive interpreters that run in the same name space (so you can work with the results of executing), and the environment is then persistent between runs. You can also run a script internally "as __main__" or not (i.e, have the module name set to "__main__" so the 'if __name__=="__main__"' works). If you run externally, you, of course, get __main__, but you can't easily investigate the result environment (unless you enable debugging and put a breakpoint at the last line of code, at which point you can show a console interpreter which executes (remotely) in that environment). Both modes support full debugging capabilities, though the "internal" version is faster (and a little more flexible) since it doesn't need to do all the rpc/object proxy stuff... Glenn Andreas????????????????????? gandreas@gandreas.com? oh my! quadrium | build, mutate, evolve | images, textures, backgrounds, art From hengist.podd at virgin.net Fri Apr 22 15:05:28 2005 From: hengist.podd at virgin.net (has) Date: Fri Apr 22 15:05:57 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats Message-ID: Hi all, Just wondering if there's anything in MacPython for converting HFS paths to POSIX and vice-versa, or is my memory playing tricks on me? If not, does anyone have some code they don't mind sharing? Ta, has -- http://freespace.virgin.net/hamish.sanderson/ From ml at fgranger.com Fri Apr 22 15:53:16 2005 From: ml at fgranger.com (Fran=?ISO-8859-1?B?5w==?=ois Granger) Date: Fri Apr 22 15:53:20 2005 Subject: [Pythonmac-SIG] It is normal in python2.3 shipped with apple? In-Reply-To: Message-ID: Le 22/04/05 12:19, ??whamoo?? a ?crit?: > i'm writing a program that must use the python 2.3 shipped with apple, > and i'm using the plistlib, but seem that the panther native version of > python doesn't have module named utils.iso8601..... Can someome confirm > this please? > > I'm get this error with the base ship python: > > Traceback (most recent call last): [...] > "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/plat-mac/plistlib.py", line 270, in __init__ > from xml.utils.iso8601 import parse > ImportError: No module named utils.iso8601 > > Obviously i don't have this error on python2.4 fgranger:~ fgranger$ python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from xml.utils.iso8601 import parse Traceback (most recent call last): File "", line 1, in ? ImportError: No module named utils.iso8601 >>> Same here -- Convert from markup to markup: http://fgranger.net1.nerim.net/mtom/ From dave.opstad at monotypeimaging.com Fri Apr 22 15:55:38 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Fri Apr 22 15:55:44 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: Message-ID: > Just wondering if there's anything in MacPython for converting HFS paths to > POSIX and vice-versa, or is my memory playing tricks on me? If not, does > anyone have some code they don't mind sharing? To clarify: are you asking for something that converts a string with colons to one with slashes and back; or something that converts from a slashpath into FSRefs or FSSpecs? Dave From Larry.A.Meyn at nasa.gov Fri Apr 22 16:15:57 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Fri Apr 22 16:16:14 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: References: Message-ID: <115d326a2db8ea9d717e86b8b1363f49@nasa.gov> Has, Jack helped me out awhile back in creating HFS paths. The archive is at http://mail.python.org/pipermail/pythonmac-sig/2003-August/008527.html Larry On Apr 22, 2005, at 6:05 AM, has wrote: > Hi all, > > Just wondering if there's anything in MacPython for converting HFS > paths to POSIX and vice-versa, or is my memory playing tricks on me? > If not, does anyone have some code they don't mind sharing? > > Ta, > > has > -- > http://freespace.virgin.net/hamish.sanderson/ > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From njriley at uiuc.edu Fri Apr 22 16:56:10 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri Apr 22 16:56:14 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: References: Message-ID: <20050422145610.GA63142@uiuc.edu> On Fri, Apr 22, 2005 at 02:05:28PM +0100, has wrote: > Just wondering if there's anything in MacPython for converting HFS > paths to POSIX and vice-versa, or is my memory playing tricks on me? > If not, does anyone have some code they don't mind sharing? Keep in mind that HFS paths aren't unique, whereas POSIX paths are, so you should be using FSRefs, CFURLs, POSIX paths or aliases for canonical representations, cognizant of all the tradeoffs between those formats. In [1]: from Carbon.CoreFoundation import * In [2]: from Carbon.CF import * In [3]: u = CFURLCreateFromFileSystemRepresentation('/Applications', False) In [4]: u.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() Out[4]: u'/Applications' In [5]: u.CFURLCopyFileSystemPath(kCFURLHFSPathStyle).toPython() Out[5]: u'Onyx:Applications' If you _really_ must go from an imprecise HFS path to something else: In [5]: u = toCF('Onyx:').CFURLCreateWithFileSystemPath(kCFURLHFSPathStyle, False) In [6]: u.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() Out[6]: u'/Applications' and so forth. -- Nicholas Riley | From urrestieta at gmail.com Tue Apr 19 17:02:02 2005 From: urrestieta at gmail.com (altern) Date: Fri Apr 22 17:20:44 2005 Subject: [Pythonmac-SIG] changging inheritance on the fly? In-Reply-To: <42635983.7020601@noaa.gov> References: <42623AC7.4060904@altern.org> <2mpswt9u5v.fsf@starship.python.net> <4262B60A.1040304@altern.org> <42635983.7020601@noaa.gov> Message-ID: <42651D6A.1000802@altern.org> Chris Barker wrote: > altern wrote: > >> Michael Hudson wrote: >> >>> The way you ask the question suggests you don't know Python especially >>> well. As Bob says, there are likely better ways to acheive your goal. >> >> >> any tips about those other ways? > > > A) this is more of a topic for comp.lang.python, but as long s we're > here... > > B) We can't help you without knowing what it is you're trying to do. No > one needs to "change the base class of a class" for it's own sake. > Clearly, you have something you need to accomplich, and you thought that > might be a way to do it. If you tell us what you need to accomplish, we > might be able to suggest a way to do it. > > C) just guessing, but maybe what you want is a factory function, which > will create the class you need on the fly. A search for "factory" and > python should get you something. yes, i am checking few patterns to see if can match what need. Maybe factory pattern i am not sure yet I didnt have the time to check it properly. Thanks to all for the tips despite of being off topic... > -Chris > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- enrike From maxnoel_fr at yahoo.fr Fri Apr 22 17:00:23 2005 From: maxnoel_fr at yahoo.fr (Max Noel) Date: Fri Apr 22 17:20:47 2005 Subject: [Tutor] Re: [Pythonmac-SIG] Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: <0AE73573-B31B-11D9-9F38-000393C0D100@bigfoot.com> References: <0AE73573-B31B-11D9-9F38-000393C0D100@bigfoot.com> Message-ID: <2d467e1207737ca240b98741d3045b9c@yahoo.fr> On Apr 22, 2005, at 11:41, Chris Smith wrote: > Do you have a suggestion as to what can I give a module so it has > enough information to execute a function that resides in __main__? > Here is a visual of what is going on: > > ------__main__ > def y1(): > pass > import foo > foo.run(string_from_main) #what should I pass? > > ------external module, foo > > def run(string_from_main): > # > exec(string_from_main) #y1 is run as if it were in __main__ > > > /c Python makes it easy to do because functions (and classes) are objects. Here: # in __main__ def y1(): pass import foo foo.run(y1) # in foo def run(functionFromMain): functionFromMain() -- Max maxnoel_fr at yahoo dot fr -- ICQ #85274019 "Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine?" From hengist.podd at virgin.net Fri Apr 22 18:08:47 2005 From: hengist.podd at virgin.net (has) Date: Fri Apr 22 18:08:54 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: <115d326a2db8ea9d717e86b8b1363f49@nasa.gov> References: <115d326a2db8ea9d717e86b8b1363f49@nasa.gov> Message-ID: Dave Opstad wrote: > > Just wondering if there's anything in MacPython for converting HFS paths to > > POSIX and vice-versa, or is my memory playing tricks on me? If not, does > > anyone have some code they don't mind sharing? > >To clarify: are you asking for something that converts a string with colons >to one with slashes and back; or something that converts from a slashpath >into FSRefs or FSSpecs? The former; e.g. 'Mac HD:Users:has:' to '/Users/has' and back. ... Larry Meyn wrote: >Jack helped me out awhile back in creating HFS paths. The archive is at http://mail.python.org/pipermail/pythonmac-sig/2003-August/008527.html Thanks, I hadn't thought of that. (BTW, that code should really use FSRefs and FSGetCatalogInfo() as FSSpecs can't show long filenames.) For what I'm doing, it'd probably be better if it wasn't limited to existing filesystem locations though. ... Nicholas Riley wrote: >Keep in mind that HFS paths aren't unique, whereas POSIX paths are, so >you should be using FSRefs, CFURLs, POSIX paths or aliases for >canonical representations, cognizant of all the tradeoffs between >those formats. > >from Carbon.CoreFoundation import * I'm kinda leery of using MacPython's CF wrapper as it's a bit buggy in places. Still your example looks like it works ok - good suggestion, thanks. One bit I'm not sure about though - if I run this: u = toCF('A Non-mounted Drive:').CFURLCreateWithFileSystemPath(kCFURLHFSPathStyle, False) print u.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() I get '/A Non-mounted Drive' whereas I was assuming it should be '/Volumes/A Non-mounted Drive' - is that correct? ... Anyway, might help to show what I'm actually working on: http://freespace.virgin.net/hamish.sanderson/macfile-0.1.0.tar.gz It's a simple Swiss-army-knife wrapper for the various filesystem-related types floating around MacPython, mostly cos I got sick of dealing directly with them in appscript all the time. The Alias class is quite straightforward; the File class tries to be clever by retaining the original object it was constructed with and deferring to that as much as possible when performing conversions, etc. I'm not sure how useful HFS path conversion options will really be; it seemed an idea to put it in for completeness' sake, but perhaps it's just overkill? I'd be very happy to take a second opinion on this, as well as any comments on the rest of the design and implementation folks might have (e.g. there may be some unsafe assumptions being made, subtle bugs and user gotchas, etc. that I've not accounted for). Many thanks, has From Chris.Barker at noaa.gov Fri Apr 22 18:36:40 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Apr 22 18:37:53 2005 Subject: [Pythonmac-SIG] Upgrading to 2.4.1 In-Reply-To: <18691bb8759c14d70ee2f651a6ae18ed@redivi.com> References: <18691bb8759c14d70ee2f651a6ae18ed@redivi.com> Message-ID: <42692818.8080209@noaa.gov> Bob Ippolito wrote: > On Apr 22, 2005, at 4:38 AM, Yair Benita wrote: >> If it co-exist how do I control which one is used when simply typing >> /usr/bin/python at the command line? > > NEVER EVER change anything in /usr (except /usr/local) or /System. DO > NOT EVER DO THAT. BAD. I think the OP was not proposing that, but rather was trying to figure out how to run the different pythons. So to give a little more info: Apple puts their python (2.3.0) in: /usr/bin/python When you install 2.4.* (and any python that isn't supplied by Apple, hopefully), it will not put it in /usr/bin . It should put it in /usr/local/bin/python (or maybe /opt/... or /sw/....) So, after installing python2.4, you'll have two "python" executables, but they won't be in the same place. This is where PATH comes in. try typing: $PATH at the command line. It will give you a colon separated list of paths that bash looks for executables in. It looks in the order given, so if you have /usr/local/bin and /usr/bin in your path, and there is a python in each one, it will find the one in the path that comes first in the list. Many folks recommend manipulating your PATH as the way to set the default python. For instance, if you put: export PATH=/usr/local/bin:$PATH in your .profile file (there are other placed to put it as well, search the web for suggestions), then bash will find the new version first, and run that when you type "python". However, the most common way to specify python in a script is: #!/usr/bin/env python This lets the shell figure out where python is, rather than specifying the exact path. This is nice, and makes your scripts more portable, but it means that if you manipulate PATH, you'll change what it found, and old scripts that depend on the old python will stop working (this was an infamous problem with RedHat Linux a while back, I don't know if they've fixed it.) Because of this, I don't recommend altering your default python in that way. I put: export $PATH:PATH=/usr/local/bin in my .profile, so that the system one is found first. By the way, this doesn't just affect python, it affects every command line program. I don't want to accidentally change the default anything. Want I do instead is specify the version I want at the command line or in the script: $ python2.4 or #!/usr/bin/env python2.4 (or python2.3, of course) There should be a /usr/local/bin/python2.4 after you install 2.4. If not the distribution is broken, but you can fix it easily with a link. This way, after you upgrade, anything you write now can use python2.4, and anything you wrote before can still use 2.3. I hope that helped. You know, this is enough of FAQ, it must be in the Wiki by now. If not, I guess I should add it (or perhaps the OP could put this in) -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 cookedm at physics.mcmaster.ca Fri Apr 22 19:13:00 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Fri Apr 22 19:13:02 2005 Subject: [Pythonmac-SIG] Upgrading to 2.4.1 In-Reply-To: <42692818.8080209@noaa.gov> (Chris Barker's message of "Fri, 22 Apr 2005 09:36:40 -0700") References: <18691bb8759c14d70ee2f651a6ae18ed@redivi.com> <42692818.8080209@noaa.gov> Message-ID: "Chris Barker" writes: > Because of this, I don't recommend altering your default python in > that way. I put: > > export $PATH:PATH=/usr/local/bin You mean export PATH=$PATH:/usr/local/bin of course? > in my .profile, so that the system one is found first. By the way, > this doesn't just affect python, it affects every command line > program. I don't want to accidentally change the default anything. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca From njriley at uiuc.edu Fri Apr 22 19:24:57 2005 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri Apr 22 19:25:31 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: References: <115d326a2db8ea9d717e86b8b1363f49@nasa.gov> Message-ID: <20050422172457.GA76692@uiuc.edu> On Fri, Apr 22, 2005 at 05:08:47PM +0100, has wrote: > I'm kinda leery of using MacPython's CF wrapper as it's a bit buggy in places. Still your example looks like it works ok - good suggestion, thanks. > > One bit I'm not sure about though - if I run this: > > u = toCF('A Non-mounted Drive:').CFURLCreateWithFileSystemPath(kCFURLHFSPathStyle, False) > > print u.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() > > I get '/A Non-mounted Drive' whereas I was assuming it should be > '/Volumes/A Non-mounted Drive' - is that correct? >>> u = toCF('Data:').CFURLCreateWithFileSystemPath(kCFURLHFSPathStyle, False) >>> u.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() u'/Volumes/Data' >>> u = toCF('Foo:').CFURLCreateWithFileSystemPath(kCFURLHFSPathStyle, False) >>> u.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() u'/Foo' Yeah, I see what you mean. You can't expect this kind of conversion to work on a nonexistent file, and it's not one-to-one in any case... I'd suggest just documenting it and leaving it. -- Nicholas Riley | From Chris.Barker at noaa.gov Fri Apr 22 20:19:43 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Apr 22 20:20:55 2005 Subject: [Pythonmac-SIG] Upgrading to 2.4.1 In-Reply-To: References: <18691bb8759c14d70ee2f651a6ae18ed@redivi.com> <42692818.8080209@noaa.gov> Message-ID: <4269403F.4050404@noaa.gov> David M. Cooke wrote: >>that way. I put: >> >>export $PATH:PATH=/usr/local/bin > > You mean > > export PATH=$PATH:/usr/local/bin > > of course? Yes, of course. that's a good way to confuse a newbie! Sorry about 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 Larry.A.Meyn at nasa.gov Sat Apr 23 03:39:47 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Sat Apr 23 03:40:26 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: References: <115d326a2db8ea9d717e86b8b1363f49@nasa.gov> Message-ID: On Apr 22, 2005, at 9:08 AM, has wrote: > > I'm not sure how useful HFS path conversion options will really be; it > seemed an idea to put it in for completeness' sake, but perhaps it's > just overkill? There are still some scriptable applications that only deal with HFS paths, so I would vote for including conversion options if it's no too much trouble. However, the need will decrease with time. (Although I think KaleidaGraph may never get upgraded scripting abilities.) Larry From bob at redivi.com Sat Apr 23 04:00:37 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Apr 23 04:00:42 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: References: <115d326a2db8ea9d717e86b8b1363f49@nasa.gov> Message-ID: <330bca4374b3421c869bda617ed5b3a7@redivi.com> On Apr 22, 2005, at 9:39 PM, Larry Meyn wrote: > On Apr 22, 2005, at 9:08 AM, has wrote: > >> I'm not sure how useful HFS path conversion options will really be; >> it seemed an idea to put it in for completeness' sake, but perhaps >> it's just overkill? > > There are still some scriptable applications that only deal with HFS > paths, so I would vote for including conversion options if it's no too > much trouble. However, the need will decrease with time. (Although I > think KaleidaGraph may never get upgraded scripting abilities.) Does it really take HFS paths as strings, and not FSSpec? Even if it did, wouldn't a FSSpec be coerced to a HFS path string along the way? I'm really not sure you ever really need or want to use HFS path literals, anywhere, ever, anymore. -bob From sw at wordtech-software.com Sat Apr 23 04:37:25 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sat Apr 23 04:37:28 2005 Subject: [Pythonmac-SIG] Repackaging for Tiger? Message-ID: <4269B4E5.8080302@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've gotten some inquiries from users about my Python packages--PyQt in particular--and whether they will run on Tiger. Is it safe to say that Python stuff built/packaged against 2.3 on Panther will probably need to be repackaged for Tiger, assuming Tiger is using a more recent version of Python than 2.3.0? - -- 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 iD8DBQFCabTlJmdQs+6YVcoRAlrsAJ0SpjW+70Q4vxh1Av/t2YZFDjSlAACfZ/ab bKAWFaGF+L1e6OnCC+xzxhE= =JEFq -----END PGP SIGNATURE----- From bob at redivi.com Sat Apr 23 04:51:48 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat Apr 23 04:51:54 2005 Subject: [Pythonmac-SIG] Repackaging for Tiger? In-Reply-To: <4269B4E5.8080302@wordtech-software.com> References: <4269B4E5.8080302@wordtech-software.com> Message-ID: On Apr 22, 2005, at 10:37 PM, Kevin Walzer wrote: > I've gotten some inquiries from users about my Python packages--PyQt in > particular--and whether they will run on Tiger. Is it safe to say that > Python stuff built/packaged against 2.3 on Panther will probably need > to > be repackaged for Tiger, assuming Tiger is using a more recent version > of Python than 2.3.0? Maybe. Applications built by py2app will definitely work, other things may not. There may or may not be a workaround to allow Panther stuff to work. I'm not going to announce anything until Tiger is shipping. -bob From Larry.A.Meyn at nasa.gov Sat Apr 23 08:53:14 2005 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Sat Apr 23 08:53:19 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats In-Reply-To: <330bca4374b3421c869bda617ed5b3a7@redivi.com> References: <115d326a2db8ea9d717e86b8b1363f49@nasa.gov> <330bca4374b3421c869bda617ed5b3a7@redivi.com> Message-ID: On Apr 22, 2005, at 7:00 PM, Bob Ippolito wrote: > On Apr 22, 2005, at 9:39 PM, Larry Meyn wrote: > >> On Apr 22, 2005, at 9:08 AM, has wrote: >> >>> I'm not sure how useful HFS path conversion options will really be; >>> it seemed an idea to put it in for completeness' sake, but perhaps >>> it's just overkill? >> >> There are still some scriptable applications that only deal with HFS >> paths, so I would vote for including conversion options if it's no >> too much trouble. However, the need will decrease with time. >> (Although I think KaleidaGraph may never get upgraded scripting >> abilities.) > > Does it really take HFS paths as strings, and not FSSpec? Even if it > did, wouldn't a FSSpec be coerced to a HFS path string along the way? > KaleidaGraph has it's own scripting language, so for anything beyond open and close commands, one passes a KaleidaGraph script as a string. Hence the need for HFS path strings. I've got some code, based on what Jack suggested, that does what I need. Offhand, I can't think of any other applications with this requirement, so it may not be worth Has' time to support HFS path strings in his project if this is such a rare need. Larry From dgodon at comcast.net Sat Apr 23 10:10:37 2005 From: dgodon at comcast.net (Demian Godon) Date: Sat Apr 23 10:08:40 2005 Subject: [Pythonmac-SIG] appscript: click command not working Message-ID: <426A02FD.8000006@comcast.net> Question from a newbie (to both applescript and python): Can someone please explain why the following script does not cause the "Start Server" button to be clicked? #!/usr/bin/pythonw from appscript import * app('/Applications/Utilities/OSXvnc.app').activate() app('System Events').application_processes['OSXvnc'].windows[1].buttons[4].click() The equivelant applescript works: activate application "OSXvnc" tell application "System Events" tell application process "OSXvnc" -- GUI Scripting statements: click button 4 of window 1 end tell end tell Thanks, -D From hengist.podd at virgin.net Sat Apr 23 10:51:20 2005 From: hengist.podd at virgin.net (has) Date: Sat Apr 23 11:07:59 2005 Subject: [Pythonmac-SIG] appscript: click command not working Message-ID: Demian Godon wrote: >Question from a newbie (to both applescript and python): >Can someone please explain why the following script does not cause the >"Start Server" button to be clicked? > >app('/Applications/Utilities/OSXvnc.app').activate() >app('System Events').application_processes['OSXvnc'].windows[1].buttons[4].click() Not sure. It works on 10.2 (where I am), but this is the second time someone's reported this problem on 10.3. If I can reproduce it when I upgrade to 10.4 I should be able to nail it quite quickly. In the meantime, I believe the alternate form works correctly: app('System Events').click(app('System Events').application_processes['OSXvnc'].windows[1].buttons[4]) HTH has http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Sat Apr 23 11:01:35 2005 From: hengist.podd at virgin.net (has) Date: Sat Apr 23 11:08:02 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIX formats Message-ID: Larry Meyn wrote: >On Apr 22, 2005, at 7:00 PM, Bob Ippolito wrote: > > >> There are still some scriptable applications that only deal with HFS > >> paths, so I would vote for including conversion options if it's no > >> too much trouble. However, the need will decrease with time. > >> (Although I think KaleidaGraph may never get upgraded scripting > >> abilities.) > > > > Does it really take HFS paths as strings, and not FSSpec? Even if it > > did, wouldn't a FSSpec be coerced to a HFS path string along the way? > > >KaleidaGraph has it's own scripting language, so for anything beyond >open and close commands, one passes a KaleidaGraph script as a string. >Hence the need for HFS path strings. I've got some code, based on what >Jack suggested, that does what I need. Offhand, I can't think of any >other applications with this requirement, so it may not be worth Has' >time to support HFS path strings in his project if this is such a rare >need. Yeah, I think based on what folk here have said I'll leave out HFS path support for the time being. If I start getting lots of requests for it I can always add it in later along with the relevant caveats, but if it's just an occasional thing then they can always get a POSIX path and use Jack or Nicholas's code to convert it themselves. Many thanks to all for the input, has -- http://freespace.virgin.net/hamish.sanderson/ From dgodon at comcast.net Sun Apr 24 00:10:04 2005 From: dgodon at comcast.net (Demian Godon) Date: Sun Apr 24 00:08:07 2005 Subject: [Pythonmac-SIG] appscript: click command not working In-Reply-To: References: Message-ID: <426AC7BC.3020401@comcast.net> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050423/54ffaf43/attachment.html From sw at wordtech-software.com Sun Apr 24 06:20:33 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Sun Apr 24 06:20:40 2005 Subject: [Pythonmac-SIG] py2applet--is it really this easy? Message-ID: <426B1E91.1070603@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In anticipation of repackaging my Python developer tools for Tiger, I gave py2applet (the gui droplet) a try, since I wasn't quite sure how it worked. I had been playing with a PyQt app called mindmap, so I decided to use this as a test case. I dragged and dropped the main launcher script on the py2applet icon, and it proceeded to create a standalone package complete with PyQt libraries stuffed in! This was quite unexpected: I guess I thought py2applet worked in the same way that buildapplet did. Is it this easy? I realize that I will need to edit the info.plist and icon bits to get it completely customized (since I didn't use a py2app setup script), but this blows my mind. Is py2applet really this simple? Bob, you're amazing. Thanks for such a useful tool. With a little more testing/learning, I'll be ready to bag bundlebuilder/buildapplet for good. 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 iD8DBQFCax6QJmdQs+6YVcoRAjJPAKCG0vKXnCEMwjHS2ShiRNuEt+F8NwCdFJRv tb5n5Wc8BkhvcpX8v+fybKg= =+loj -----END PGP SIGNATURE----- From bob at redivi.com Sun Apr 24 07:09:39 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Apr 24 07:09:42 2005 Subject: [Pythonmac-SIG] py2applet--is it really this easy? In-Reply-To: <426B1E91.1070603@wordtech-software.com> References: <426B1E91.1070603@wordtech-software.com> Message-ID: On Apr 24, 2005, at 12:20 AM, Kevin Walzer wrote: > In anticipation of repackaging my Python developer tools for Tiger, I > gave py2applet (the gui droplet) a try, since I wasn't quite sure how > it > worked. I had been playing with a PyQt app called mindmap, so I decided > to use this as a test case. I dragged and dropped the main launcher > script on the py2applet icon, and it proceeded to create a standalone > package complete with PyQt libraries stuffed in! This was quite > unexpected: I guess I thought py2applet worked in the same way that > buildapplet did. Hell no, py2app exists because buildapplet/bundlebuilder sucks. > Is it this easy? I realize that I will need to edit the info.plist and > icon bits to get it completely customized (since I didn't use a py2app > setup script), but this blows my mind. Is py2applet really this simple? Yes, it really is that easy. Actually, if you want to keep the drag+drop workflow you can drag an icns file and Info.plist template and it will use those. Any data files you drag in will go right into Resources (which is the current directory upon startup) too. I suggest stripping down the Info.plist file down to only the keys you would like to customize, though, so you don't end up overriding something py2app ought to control. It fills in the blanks for anything necessary. -bob From bob at redivi.com Mon Apr 25 04:32:35 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 25 04:32:42 2005 Subject: [Pythonmac-SIG] zipfile still has 2GB boundary bug Message-ID: The "2GB bug" that was supposed to be fixed in was not actually fixed. The zipinfo offsets in the structures are still signed longs, so the fix allows you to write one file that extends past the 2G boundary, but if any extend past that point you are screwed. I have opened a new bug and patch that should fix this issue . This is a backport candidate to 2.4.2 and 2.3.6 (if that ever happens). On a related note, if anyone else has a bunch of really big and ostensibly broken zip archives created by dumb versions of the zipfile module, I have written a script that can rebuild the central directory in-place. Ping me off-list if you're interested and I'll clean it up. Someone should think about rewriting the zipfile module to be less hideous, include a repair feature, and be up to date with the latest specifications . Additionally, it'd also be useful if someone were to include support for Apple's "extensions" to the zip format (the __MACOSX folder and its contents) that show up when BOM (private framework) is used to create archives (i.e. Finder in Mac OS X 10.3+). I'm not sure if these are documented anywhere, but I can help with reverse engineering if someone is interested in writing the code. On that note, Mac OS X 10.4 (Tiger) is supposed to have new APIs (or changes to existing APIs?) to facilitate resource fork preservation, ACLs, and Spotlight hooks in tar, cp, mv, etc. Someone should spend some time looking at the Darwin 8 sources for these tools (when they're publicly available in the next few weeks) to see what would need to be done in Python to support them in the standard library (the os, tarfile, etc. modules). -bob From charles.hartman at conncoll.edu Mon Apr 25 13:53:58 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon Apr 25 13:54:02 2005 Subject: [Pythonmac-SIG] zipfile still has 2GB boundary bug In-Reply-To: References: Message-ID: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> > > Someone should think about rewriting the zipfile module to be less > hideous, include a repair feature, and be up to date with the latest > specifications . -- and allow *deleting* a file from a zipfile. As far as I can tell, you now can't (except by rewriting everything but that to a new zipfile and renaming). Somewhere I saw a patch request for this, but it was languishing, a year or more old. Or am I just totally missing something? Charles Hartman From smichr at bigfoot.com Mon Apr 25 15:18:08 2005 From: smichr at bigfoot.com (Chris Smith) Date: Mon Apr 25 15:19:04 2005 Subject: [Pythonmac-SIG] Re: Weird import problem with PythonIDE on Mac (was 'import problem') In-Reply-To: <2d467e1207737ca240b98741d3045b9c@yahoo.fr> Message-ID: <774F538A-B58C-11D9-BB74-000393C0D100@bigfoot.com> On Friday, Apr 22, 2005, at 10:00 America/Chicago, Max Noel wrote: > >> Do you have a suggestion as to what can I give a module so it has >> enough information to execute a function that resides in __main__? >> Here is a visual of what is going on: >> >> ------__main__ >> def y1(): >> pass >> import foo >> foo.run(string_from_main) #what should I pass? >> >> ------external module, foo >> >> def run(string_from_main): >> # >> exec(string_from_main) #y1 is run as if it were in __main__ >> >> >> /c > > Python makes it easy to do because functions (and classes) are > objects. Here: > > # in __main__ > def y1(): > pass > import foo > foo.run(y1) > > > # in foo > def run(functionFromMain): > functionFromMain() > Yes, I know about this, but this is not the problem. The problem is knowing what *strings* to pass to the timeit module so it can access a function that is written in one's __main__. Basically, the timeit module uses a template to construct a function which is (in the timeit module) compiled and then executed. You get to send two strings: an initialization string that is run once and the code string that appears in a loop. Here, for example, is the function that is reconstructed and run without success (in mac's pythonIDE: ### def inner(_it, _timer): from __main__ import y1 # I supplied this _t0 = _timer() for _i in _it: y1() # and I supplied this _t1 = _timer() return _t1 - _t0 ### The way the IDE works, this import fails. There are two ways I have found around the problem: 1) wrap the functions of __main__ into a triple quoted string and then parsing it apart and sending it to timeit (not too elegant/pythonic): ### brute force passing of function to timeit funcs=''' def y1(): print 'y1 executed' def y2(): print 'y2 executed' ''' for f in funcs.split('def'): f = f.strip() if not f: continue name = f.split('(')[0] t=timeit.Timer('def '+f) print name,t.timeit(1) ### 2) the other approach is to add an additional argument to the timeit __init__ that accepts globals() from the calling program: ### def __init__(self, stmt="pass", setup="pass", timer=default_timer, glbls = globals): """Constructor. See class doc string.""" # changed here - -^ self.timer = timer stmt = reindent(stmt, 8) setup = reindent(setup, 4) src = template % {'stmt': stmt, 'setup': setup} self.src = src # Save for traceback display code = compile(src, dummy_src_name, "exec") ns = {} exec code in glbls, ns # and here self.inner = ns["inner"] ### Then __main__ can send functions like this: ### def y1(): print 'y1 executed' def y2(): print 'y2 executed' for f in [y1,y2]: func = f.__name__ t=timeit.Timer(stmt = "%s()" % func, glbls = globals()) print func, t.timeit(1) ### {If you read to here, thanks. Is there a better way to accomplish this with the current timeit module without modifying timeit? i.e. is there another way to pass the needed information as a string that timeit's created function can execute?} /c From bob at redivi.com Mon Apr 25 15:53:13 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 25 15:53:25 2005 Subject: [Pythonmac-SIG] zipfile still has 2GB boundary bug In-Reply-To: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> References: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> Message-ID: <6a8c0d96b4709c84b223395306646ef0@redivi.com> On Apr 25, 2005, at 7:53 AM, Charles Hartman wrote: >> >> Someone should think about rewriting the zipfile module to be less >> hideous, include a repair feature, and be up to date with the latest >> specifications . > > -- and allow *deleting* a file from a zipfile. As far as I can tell, > you now can't (except by rewriting everything but that to a new > zipfile and renaming). Somewhere I saw a patch request for this, but > it was languishing, a year or more old. Or am I just totally missing > something? No, you're not missing anything. Deleting is hard, I guess. Either you'd have to shuffle the zip file around to reclaim the space, or just leave that spot alone and just remove its entry in the central directory. You'd probably want to look at what other software does to decide which approach to use (by default?). I don't see any markers in the format that would otherwise let you say "this file was deleted". -bob From Benjamin.Schollnick at xerox.com Mon Apr 25 16:13:38 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Mon Apr 25 16:14:08 2005 Subject: [Pythonmac-SIG] converting file paths between HFS and POSIXformats Message-ID: <266589E1B9392B4C9195CC25A07C73B9AA501F@usa0300ms04.na.xerox.net> > The former; e.g. 'Mac HD:Users:has:' to '/Users/has' and back. The issue is that it has to be partially hard coded.... I have not figured out a way to do this completely platform independent... >>> import os >>> mac_path = "Mac HD:Users:has:" >>> PC_path = str(os.sep).join (mac_path.split (":")) >>> print PC_path Mac HD\Users\has\ - Benjamin From Chris.Barker at noaa.gov Mon Apr 25 19:06:02 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Mon Apr 25 19:07:25 2005 Subject: [Pythonmac-SIG] py2applet--is it really this easy? In-Reply-To: References: <426B1E91.1070603@wordtech-software.com> Message-ID: <426D237A.6040401@noaa.gov> Bob Ippolito wrote: > On Apr 24, 2005, at 12:20 AM, Kevin Walzer wrote: >> I dragged and dropped the main launcher >> script on the py2applet icon, and it proceeded to create a standalone >> package complete with PyQt libraries stuffed in! > Yes, it really is that easy. So what's the difference between an "App" and a "Applet" ? -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 Apr 25 19:24:24 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 25 19:24:36 2005 Subject: [Pythonmac-SIG] py2applet--is it really this easy? In-Reply-To: <426D237A.6040401@noaa.gov> References: <426B1E91.1070603@wordtech-software.com> <426D237A.6040401@noaa.gov> Message-ID: <141b436c2e2a8fdf51eac98f4cee9b2b@redivi.com> On Apr 25, 2005, at 1:06 PM, Chris Barker wrote: > > > Bob Ippolito wrote: >> On Apr 24, 2005, at 12:20 AM, Kevin Walzer wrote: >>> I dragged and dropped the main launcher >>> script on the py2applet icon, and it proceeded to create a standalone >>> package complete with PyQt libraries stuffed in! > >> Yes, it really is that easy. > > So what's the difference between an "App" and a "Applet" ? An applet was created with drag+drop or the py2applet command line script. -bob From charles.hartman at conncoll.edu Mon Apr 25 20:44:05 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon Apr 25 20:44:11 2005 Subject: [Pythonmac-SIG] py2applet--is it really this easy? In-Reply-To: <141b436c2e2a8fdf51eac98f4cee9b2b@redivi.com> References: <426B1E91.1070603@wordtech-software.com> <426D237A.6040401@noaa.gov> <141b436c2e2a8fdf51eac98f4cee9b2b@redivi.com> Message-ID: <542f3ae4e99a4c55e99b5e1c305de71b@conncoll.edu> When I tried the applet approach, and burned the result to a CD and tried to copy it to another 10.3 Mac, I got an error message saying that something could not be copied; it had to do with a "framework", but I don't have the exact wording. (It's a multi-module script using wxPython; the applet was big, like 14Mb as opposed to the 11Mb app that py2app makes, if that's a clue.) ? Charles Hartman On Apr 25, 2005, at 1:24 PM, Bob Ippolito wrote: > > On Apr 25, 2005, at 1:06 PM, Chris Barker wrote: > >> >> >> Bob Ippolito wrote: >>> On Apr 24, 2005, at 12:20 AM, Kevin Walzer wrote: >>>> I dragged and dropped the main launcher >>>> script on the py2applet icon, and it proceeded to create a >>>> standalone >>>> package complete with PyQt libraries stuffed in! >> >>> Yes, it really is that easy. >> >> So what's the difference between an "App" and a "Applet" ? > > An applet was created with drag+drop or the py2applet command line > script. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Mon Apr 25 20:55:55 2005 From: bob at redivi.com (Bob Ippolito) Date: Mon Apr 25 20:56:10 2005 Subject: [Pythonmac-SIG] py2applet--is it really this easy? In-Reply-To: <542f3ae4e99a4c55e99b5e1c305de71b@conncoll.edu> References: <426B1E91.1070603@wordtech-software.com> <426D237A.6040401@noaa.gov> <141b436c2e2a8fdf51eac98f4cee9b2b@redivi.com> <542f3ae4e99a4c55e99b5e1c305de71b@conncoll.edu> Message-ID: <1d2d47972dcc146e7a416592cad7535f@redivi.com> On Apr 25, 2005, at 2:44 PM, Charles Hartman wrote: > When I tried the applet approach, and burned the result to a CD and > tried to copy it to another 10.3 Mac, I got an error message saying > that something could not be copied; it had to do with a "framework", > but I don't have the exact wording. (It's a multi-module script using > wxPython; the applet was big, like 14Mb as opposed to the 11Mb app > that py2app makes, if that's a clue.) Make sure you're using the latest py2app (currently 0.1.9, or 0.2.0 in svn). Write down exact messages or take screenshots. Put together more explicit steps to reproduce, and send me a zip of the resultant .app using Finder's "create archive". It's likely the method you're using, not py2app itself. -bob From charles.hartman at conncoll.edu Tue Apr 26 04:46:55 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue Apr 26 04:47:01 2005 Subject: [Pythonmac-SIG] py2app, wxPython, and unicode Message-ID: <74672cfa22e1a17e6f4b158d5f20cac8@conncoll.edu> Maybe this is the wrong place to ask. (I'm confused.) I've got a Mac 2.4.1 app using the unicode build of wxPython 2.5.4.1. I'm loading a text file that contains an accented (>128) character and displaying it in a wxPython widget (a StyledTextCtrl). I've got the encoding/decoding etc all taken care of (I think!) elsewhere inside the app. But now I have a problem right at the front end, reading and displaying the file. It works fine in the WingIDE. When I build it with py2app, though, I get a problem. If I use this: self.myStyledTextCtrl.DisplayText(f.read()) the file is displayed up to the line that includes the accented character, then no more. If I use this: defaultEncoding = wx.GetDefaultPyEncoding() . . . data = f.read() self.WholeText.DisplayText(unicode(data, defaultEncoding)) the file doesn't display at all. Because of the difference between standalone and in-the-IDE, I can't figure out where the problem lies. Any clues very welcome. (I'm getting very sick of unicode.) Charles Hartman From bob at redivi.com Tue Apr 26 04:55:09 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 26 04:55:11 2005 Subject: [Pythonmac-SIG] py2app, wxPython, and unicode In-Reply-To: <74672cfa22e1a17e6f4b158d5f20cac8@conncoll.edu> References: <74672cfa22e1a17e6f4b158d5f20cac8@conncoll.edu> Message-ID: <94331074da5793f232c0a76c89f42956@redivi.com> On Apr 25, 2005, at 10:46 PM, Charles Hartman wrote: > Maybe this is the wrong place to ask. (I'm confused.) I've got a Mac > 2.4.1 app using the unicode build of wxPython 2.5.4.1. I'm loading a > text file that contains an accented (>128) character and displaying it > in a wxPython widget (a StyledTextCtrl). I've got the > encoding/decoding etc all taken care of (I think!) elsewhere inside > the app. But now I have a problem right at the front end, reading and > displaying the file. > > It works fine in the WingIDE. > > When I build it with py2app, though, I get a problem. If I use this: > self.myStyledTextCtrl.DisplayText(f.read()) > the file is displayed up to the line that includes the accented > character, then no more. If I use this: > defaultEncoding = wx.GetDefaultPyEncoding() > . . . > data = f.read() > self.WholeText.DisplayText(unicode(data, defaultEncoding)) > the file doesn't display at all. > > Because of the difference between standalone and in-the-IDE, I can't > figure out where the problem lies. Any clues very welcome. (I'm > getting very sick of unicode.) The default encoding is dumb. Never use the default encoding. Pick something explicitly. I bet there's a difference in the default encoding between running in the IDE and running explicitly. One or the other is probably even raising an exception at unicode(data, defaultEncoding). -bob From konrad.hinsen at laposte.net Tue Apr 26 11:09:46 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Tue Apr 26 11:09:29 2005 Subject: [Pythonmac-SIG] Building packages Message-ID: <82a382ec65ad74b4f5c986b400f5ba8f@laposte.net> I have both Apple's Python 2.3 and MacPython 2.4.1 installed on my machine, both with some add-on packages from pythonmac.org. I had noticed when installing them that the packages for Python 2.3 and Python 2.4 have identical names, meaning that the second one to be installed is treated as an "upgrade" by the installer. However, that seemed merely a cosmetical nuisance: both versions are installed, but only the last one installed can be traced in /Library/Receipts. However, with py2app the conflict seems more serious: both have /usr/local/bin/bdist_mpkg, using different Python versions. It seems thus that I can build packages for only one Python installation at a time, having to reinstall py2app to build packages for the other one. I am rather sure that sooner or later I will make a mistake somewhere. One workaround would be to rename bdist_mpkg and then install the other one, but that would work only if the executable script is the only conflicting file. I don't see any easy way to verify this, I would have to go through the file lists of both packages. Does anyone have a better solution? Konrad (having fond memories of RPM at the moment) From bob at redivi.com Tue Apr 26 11:27:03 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 26 11:27:06 2005 Subject: [Pythonmac-SIG] Building packages In-Reply-To: <82a382ec65ad74b4f5c986b400f5ba8f@laposte.net> References: <82a382ec65ad74b4f5c986b400f5ba8f@laposte.net> Message-ID: On Apr 26, 2005, at 5:09 AM, konrad.hinsen@laposte.net wrote: > I have both Apple's Python 2.3 and MacPython 2.4.1 installed on my > machine, both with some add-on packages from pythonmac.org. I had > noticed when installing them that the packages for Python 2.3 and > Python 2.4 have identical names, meaning that the second one to be > installed is treated as an "upgrade" by the installer. However, that > seemed merely a cosmetical nuisance: both versions are installed, but > only the last one installed can be traced in /Library/Receipts. This was fixed in r455 (Apr 1st)... I'm not sure if it made the 0.1.9 release or not (it happened at about the same time), but it's been on the trunk for weeks. > However, with py2app the conflict seems more serious: both have > /usr/local/bin/bdist_mpkg, using different Python versions. It seems > thus that I can build packages for only one Python installation at a > time, having to reinstall py2app to build packages for the other one. > I am rather sure that sooner or later I will make a mistake somewhere. > > One workaround would be to rename bdist_mpkg and then install the > other one, but that would work only if the executable script is the > only conflicting file. I don't see any easy way to verify this, I > would have to go through the file lists of both packages. > > Does anyone have a better solution? I do something equivalent to this (where both python installations have a pth file pointing to the src directory of py2app svn trunk, and the scripts dir of py2app is in my PATH): python2.4 `which bdist_mpkg` -z python2.3 `which bdist_mpkg` -z ... then I move dist/*.zip to the right place, generate md5 checksums, edit the data file that generates the html, run a script that makes new html and then does rsync over ssh to the server. Generally I'll do my own installation by downloading from the web site and installing that to make sure it works (but I only really test python 2.4 packages these days). -bob From bmackenzie at avpress.com Tue Apr 26 21:55:59 2005 From: bmackenzie at avpress.com (Bill MacKenzie) Date: Tue Apr 26 21:56:12 2005 Subject: [Pythonmac-SIG] EPS to JPEG with PIL Message-ID: <35EBDBCC-B68D-11D9-B449-000393816E90@avpress.com> I need to convert EPS files to JPEG files. So far, all I get is failure notices. The first question is will PIL do this trick? And the second is, OK what am I doing wrong? I've installed PIL-1.1.5-py2.3-macosx10.3 on my IMac running OS 10.3.7 and Python 2.3 (#1, Sep 13 2003, 00:49:11). I adapted the following test from the PDF version of the handbook _ PIL 1.1.3 | March 12, 2002 | Fredrik Lundh, Matthew Ellis. I run the script with Python-Launcher 2.3. #!/usr/bin/python import os, sys import Image infile='/text/data/1055.eps' outfile = "/text/1055.pdf" if infile != outfile: try: im = Image.open(infile) print infile, im.format, "%dx%d" % im.size, im.mode im.thumbnail((15, 15)) im.save(outfile, "PDF") except IOError: print 'Cannot create ' +outfile+' thumbnail for', infile I've tried JPEG, BMP, PDF, etc as output types and get the same message. P120:~ billmac$ "/usr/bin/python" "/text/PIL_test.py" && echo Exit status: $? && exit 1 /text/data/1055.eps EPS 70x71 L Cannot create /text/1055.pdf thumbnail for /text/data/1055.eps Exit status: 0 logout [Process exited - exit code 1] It's seeing the file, but can't create the export. What am I missing? Thanks, Bill Bill MacKenzie Special Projects Antelope Valley Press bill.mackenzie@avpress.com From bob at redivi.com Tue Apr 26 22:37:40 2005 From: bob at redivi.com (Bob Ippolito) Date: Tue Apr 26 22:37:43 2005 Subject: [Pythonmac-SIG] EPS to JPEG with PIL In-Reply-To: <35EBDBCC-B68D-11D9-B449-000393816E90@avpress.com> References: <35EBDBCC-B68D-11D9-B449-000393816E90@avpress.com> Message-ID: On Apr 26, 2005, at 3:55 PM, Bill MacKenzie wrote: > I need to convert EPS files to JPEG files. So far, all I get is > failure notices. > > The first question is will PIL do this trick? Not without Ghostscript installed. You might want to look to the CoreGraphics wrapper that comes with Apple's distribution of Python, or to PyObjC's NSImage, NSBitmapImageRep, etc. Apple's stuff is (orders of magnitude) faster and produces better output anyway. You might want to look at Zac's Thumbscrew app for some example source in this arena: http://www.urbanape.com/software -bob From gvanrossum at gmail.com Wed Apr 27 02:24:44 2005 From: gvanrossum at gmail.com (Guido van Rossum) Date: Wed Apr 27 02:24:50 2005 Subject: [Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug In-Reply-To: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> References: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> Message-ID: > > Someone should think about rewriting the zipfile module to be less > > hideous, include a repair feature, and be up to date with the latest > > specifications . > > -- and allow *deleting* a file from a zipfile. As far as I can tell, > you now can't (except by rewriting everything but that to a new zipfile > and renaming). Somewhere I saw a patch request for this, but it was > languishing, a year or more old. Or am I just totally missing > something? Please don't propose a grand rewrite (even it's only a single module). Given that the API is mostly sensible, please propose gradual refactoring of the implementation, perhaps some new API methods, and so on. Don't throw away the work that went into making it work in the first place! http://www.joelonsoftware.com/articles/fog0000000069.html -- --Guido van Rossum (home page: http://www.python.org/~guido/) From bob at redivi.com Wed Apr 27 03:00:43 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Apr 27 03:00:48 2005 Subject: [Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug In-Reply-To: References: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> Message-ID: <6cc9cf942f6b6fa876741dff724e87cd@redivi.com> On Apr 26, 2005, at 8:24 PM, Guido van Rossum wrote: >>> Someone should think about rewriting the zipfile module to be less >>> hideous, include a repair feature, and be up to date with the latest >>> specifications . >> >> -- and allow *deleting* a file from a zipfile. As far as I can tell, >> you now can't (except by rewriting everything but that to a new >> zipfile >> and renaming). Somewhere I saw a patch request for this, but it was >> languishing, a year or more old. Or am I just totally missing >> something? > > Please don't propose a grand rewrite (even it's only a single module). > Given that the API is mostly sensible, please propose gradual > refactoring of the implementation, perhaps some new API methods, and > so on. Don't throw away the work that went into making it work in the > first place! Well, I didn't necessarily mean it should be thrown away and started from scratch -- however, once you get all the ugly out of it, there's not much left! Obviously there's something wrong with the way it's written if it took years and *several passes* to correctly identify and fix a simple format character case bug. Most of this can be blamed on the struct module, which is more obscure and error-prone than writing the same code in C. One of the most useful things that could happen to the zipfile module would be a stream interface for both reading and writing. Right now it's slow and memory hungry when dealing with large chunks. The use case that lead me to fix this bug is a tool that archives video to zip files of targa sequences with a reference QuickTime movie.. so I end up with thousands of bite sized chunks. This >2GB bug really caused me some grief in that I didn't test with such large sequences because I didn't have any. I didn't end up finding out about it until months later because client *ignored* the exceptions raised by the GUI and came back to me with broken zip files. Fortunately the TOC in a zip file can be reconstructed from an otherwise pristine stream. Of course, I had to rewrite half of the zipfile module to come up with such a recovery program, because it's not designed well enough to let me build such a tool on top of it. Another "bug" I ran into was that it has some crazy default for the ZipInfo record: it assumes the platform ("create_system") is Windows regardless of where you are! This caused some really subtle and annoying issues with some unzip tools (of course, on everyone's machines except mine). Fortunately someone was able to figure out why and send me a patch, but it was completely unexpected and I didn't see such craziness documented anywhere. If it weren't for this patch, it'd either still be broken, or I'd have switched to some other way of creating archives! The zipfile module is good enough to create input files for zipimport.. which is well tested and generally works -- barring the fact that zipimport has quite a few rough edges of its own. I certainly wouldn't recommend it for any heavy duty tasks in its current state. -bob From gvanrossum at gmail.com Wed Apr 27 06:19:47 2005 From: gvanrossum at gmail.com (Guido van Rossum) Date: Wed Apr 27 06:19:54 2005 Subject: [Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug In-Reply-To: <6cc9cf942f6b6fa876741dff724e87cd@redivi.com> References: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> <6cc9cf942f6b6fa876741dff724e87cd@redivi.com> Message-ID: > > Please don't propose a grand rewrite (even it's only a single module). > > Given that the API is mostly sensible, please propose gradual > > refactoring of the implementation, perhaps some new API methods, and > > so on. Don't throw away the work that went into making it work in the > > first place! > > Well, I didn't necessarily mean it should be thrown away and started > from scratch Well, you *did* say "rewrite". :-) > -- however, once you get all the ugly out of it, there's > not much left! Obviously there's something wrong with the way it's > written if it took years and *several passes* to correctly identify and > fix a simple format character case bug. Most of this can be blamed on > the struct module, which is more obscure and error-prone than writing > the same code in C. I think the reason is different -- it just hasn't had all that much use beyond the one use case for which it was written (zipping up the Python library). Also, don't underestimate the baroqueness of the zip spec. > One of the most useful things that could happen to the zipfile module > would be a stream interface for both reading and writing. Right now > it's slow and memory hungry when dealing with large chunks. The use > case that lead me to fix this bug is a tool that archives video to zip > files of targa sequences with a reference QuickTime movie.. so I end up > with thousands of bite sized chunks. Sounds like a use case nobody else has tried yet. > This >2GB bug really caused me some grief in that I didn't test with > such large sequences because I didn't have any. I didn't end up > finding out about it until months later because client *ignored* the > exceptions raised by the GUI and came back to me with broken zip files. > Fortunately the TOC in a zip file can be reconstructed from an > otherwise pristine stream. Of course, I had to rewrite half of the > zipfile module to come up with such a recovery program, because it's > not designed well enough to let me build such a tool on top of it. Given more typical use cases for zip files (sending around collections of source files) I'm not surprised that a bug that only occurs for files >2GB remained hidden for so long. I don't remember if you have Python CVS permissions, but you sound like you really know the module as well as the zip file spec, so I'm hoping that you'll find the time to do some reconstructive surgery on the zip module for Python 2.5, without breaking the existing APIs. I like the idea you have for a stream API; I recall that the one time I had to use it I was surprised that the API dealt with files as string buffers exclusively. > Another "bug" I ran into was that it has some crazy default for the > ZipInfo record: it assumes the platform ("create_system") is Windows > regardless of where you are! I vaguely recall that the initial author was a Windows-head; perhaps he didn't realize how useful the module would be on other platforms, or that it would make any difference at all. > This caused some really subtle and > annoying issues with some unzip tools (of course, on everyone's > machines except mine). Fortunately someone was able to figure out why > and send me a patch, but it was completely unexpected and I didn't see > such craziness documented anywhere. If it weren't for this patch, it'd > either still be broken, or I'd have switched to some other way of > creating archives! > > The zipfile module is good enough to create input files for zipimport.. > which is well tested and generally works -- barring the fact that > zipimport has quite a few rough edges of its own. I certainly wouldn't > recommend it for any heavy duty tasks in its current state. So, please fix it! -- --Guido van Rossum (home page: http://www.python.org/~guido/) From alan.mcintyre at esrgtech.com Wed Apr 27 03:48:06 2005 From: alan.mcintyre at esrgtech.com (Alan McIntyre) Date: Wed Apr 27 10:23:32 2005 Subject: [Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug In-Reply-To: <6cc9cf942f6b6fa876741dff724e87cd@redivi.com> References: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> <6cc9cf942f6b6fa876741dff724e87cd@redivi.com> Message-ID: <426EEF56.8090905@esrgtech.com> Bob Ippolito wrote: > One of the most useful things that could happen to the zipfile module > would be a stream interface for both reading and writing. Right now > it's slow and memory hungry when dealing with large chunks. The use > case that lead me to fix this bug is a tool that archives video to zip > files of targa sequences with a reference QuickTime movie.. so I end > up with thousands of bite sized chunks. While it's probably not an improvement on the order of magnitude you're looking for, there's a patch (1121142) that lets you read large items out of a zip archive via a file-like object. I'm occasionally running into the 2GB problem myself, so if any changes are made to get around that I can at least help out by testing it against some "real-life" data sets. Alan From shane at hathawaymix.org Wed Apr 27 06:15:16 2005 From: shane at hathawaymix.org (Shane Hathaway) Date: Wed Apr 27 10:23:34 2005 Subject: [Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug In-Reply-To: <6cc9cf942f6b6fa876741dff724e87cd@redivi.com> References: <0a276f3a753a57d89e65013ca77a3714@conncoll.edu> <6cc9cf942f6b6fa876741dff724e87cd@redivi.com> Message-ID: <426F11D4.1080707@hathawaymix.org> Bob Ippolito wrote: > The zipfile module is good enough to create input files for zipimport.. > which is well tested and generally works -- barring the fact that > zipimport has quite a few rough edges of its own. I certainly wouldn't > recommend it for any heavy duty tasks in its current state. That's interesting because Java seems to suffer from similar problems. In the early days of Java, although a jar file was a zip file, Java wouldn't read jar files created by the standard zip utilities I used. I think the distinction was that the jar utility stored the files uncompressed. Java is fixed now, but I think it illustrates that zip files are non-trivial. BTW, I don't think the jar utility can delete files from a zip file either. ;-) Shane From Benjamin.Schollnick at xerox.com Wed Apr 27 16:58:26 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Wed Apr 27 16:59:09 2005 Subject: [Pythonmac-SIG] ZipFile revision.... Message-ID: <266589E1B9392B4C9195CC25A07C73B9AA5033@usa0300ms04.na.xerox.net> Folks, There's been a lot of talk lately about changes to the ZipFile module... Along with people stating that there are few "real life" applications for it.... Here's a small "gift"... A "Quick" Backup utility for your files.... Example: c:\develope\backup\backup.py --source c:\install_software --target c:\backups\ --label installers c:\develope\backup\backup.py --source c:\develope --target c:\backups\ --label development -z .pyc c:\develope\backup\backup.py --source "C:\Program Files\Microsoft SQL Server\MSSQL\Data" --target c:\backups\ --label sql It's evolved a bit, but still could use some work.... It's currently only tested in a windows environment... So don't expect Mac OS X resource forks to be preserved..... But it creates and verifies 1Gb+ zip files.... If you wish to use this to help benchmark, test, etc, any changes to the ZipFile module please feel free to... - Benjamin """Backup Creator Utility This utility will backup the tree of files that you indicate, into a archive of your choice. """ # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # __version__ = '0.95' # Human Readable Version number version_info = (0,9,5) # Easier format version data for comparisons # i.e. if version_info > (1,2,5) # # if __version__ > '1.00' is a little more contrived. __author__ = 'Benjamin A. Schollnick' __date__ = '2004-12-28' # yyyy-mm-dd __email__ = 'Benjamin.Schollnick@xerox.com' __module_name__ = "Archive Backup Tool" __short_cright__= "" import bas_init import os import os.path import sys import time import zipfile ####################################################################### class zip_file_engine: """The archive backup tool uses pregenerated classes to allow multiple styles of archives to be created. This is the wrapper around the Python ZIPFILE module. """ def __init__ ( self ): """ Inputs -- None Outputs -- None """ self.Backup_File = None self.Backup_Open = False self.Backup_ReadOnly = None self.Backup_FileName = None def close_Backup (self ): """This will close the current Archive file, and reset the internal structures to a clean state. Inputs -- None Outputs -- None """ if self.Backup_Open <> False: self.Backup_File.close () self.Backup_File = None self.Backup_Open = False self.Backup_ReadOnly = None self.Backup_FileName = None def open_Backup ( self, readonly = False, filename = r"./temp.zip"): """This will open a archive file. Currently appending is not formally supported... The Read Only / Read/Write status is set via the readonly flag. Inputs -- Readonly: True = Read/Write False = Read Only Filename contains the full file/pathname of the zip file. Outputs -- None """ if self.Backup_Open == True: self.close_Backup () self.Backup_Filename = filename if readonly == False: self.Backup_File = zipfile.ZipFile ( filename, "r", zipfile.ZIP_DEFLATED ) self.Backup_Open = True self.Backup_ReadOnly = True self.Backup_FileName = filename else: self.Backup_File = zipfile.ZipFile ( filename, "w", zipfile.ZIP_DEFLATED ) self.Backup_Open = True self.Backup_ReadOnly = False self.Backup_FileName = filename def Verify_ZipFile ( self, FileName ): """Will create a temporary Zip File object, and verify the Zip file at location. Inputs - FileName - The filename of the ZIP file to verify. Outputs - True - File Intact CRCs match Anything else, File Corrupted. String Contains the 1st corrupted file. """ temporary_Backup_File = zip_file_engine ( ) temporary_Backup_File.open_Backup ( False, FileName) test_results = temporary_Backup_File.Backup_File.testzip () temporary_Backup_File.close_Backup() return test_results def Verify_Backup (self, FileName ): """ Generic Wrapper around the Verify_ZipFile object. """ return self.Verify_ZipFile ( FileName ) def add_file_to_Backup ( self, filename, archived_filename): """Add a file to the writable Zip file. inputs - filename = Filename of the file to be added archived_filename = the Filename stored in the archive. Outputs - None - Zip file is in Read Only Mode True - File has been added to the Zip File. -1 - Or the Zipfile engine is not initialized. """ if self.Backup_ReadOnly: # Archive is read only! return None elif self.Backup_ReadOnly == False: # Archive is Read Write Mode if self.Backup_File <> None: # Zip File Engine is initialized self.Backup_File.write (filename, archived_filename) # Return Success return True else: # Zip File Engine is *NOT* initialized. return -1 ######################################################################## # No_Archive = 1 ZIP = 2 class backup_system: """Main Class for the Backup Engine. Inputs - default_source = The pathname for the source files. default_target = The pathname for the archive to be written to. default_tag = the prepended text tag for the archive file. Outputs - None """ def __init__ ( self, default_source = None, default_target = None, default_exclude = "", default_extensions = "", default_tag = None, prepend = False, quiet = False): """The initialization routines for the Backup Engine. Inputs - default_source = The pathname for the source files. default_target = The pathname for the archive to be written to. default_exclude = default_tag = the text tag for the archive file. prepend = Deterimines the placement of the default tag. True - The tag is prepended to the filename False - The Tag is appended to the filename. The default is to append the default_tag. (False) quiet = Forcibly prevent any output from the directory walk. Outputs - None; Internal Values are initialized for the core engine. """ self.directory_to_backup = default_source self.backup_storage_location = default_target self.base_filename = default_tag self.archive_filename = None self.force_quiet = quiet # self.exlude_files_dir = default_exlude self.exclude_files_dir = default_exclude.upper().strip().split(",") self.exclude_exts = default_extensions.upper().strip().split(",") if default_tag == None: self.archive_filename_template = "%m_%d_%Y__%H_%M_%S" else: if (prepend==True): self.archive_filename_template = self.base_filename + "_%m_%d_%Y__%H_%M_%S" elif (prepend==None) or (prepend==False): self.archive_filename_template = "%m_%d_%Y__%H_%M_%S_" + self.base_filename self.archive_filename_extension = ".zip" self.archive_engine_to_use = None def create_archive_filename ( self ): """This sets the archive filename in the object. This is set, to prevent timing issues internally. Inputs - None Outputs - None; Internally creates the archives filename from the backup_storage_location, and the archive_filename_template. """ self.archive_filename = self.backup_storage_location + os.sep + time.strftime (self.archive_filename_template, time.localtime() ) + self.archive_filename_extension def Verify_Backup ( self ): """ Wrapper around the archive_engines verify routines. This will automatically start the verification process, and return the results. Inputs - None Outputs - True - File Intact CRCs match Anything else, File Corrupted. String Contains details from the archiver engine. """ return self.archive_engine_to_use.Verify_Backup ( self.archive_filename ) def start_archive_engine ( self, Backup_Type): """ Initializae the derived archive_engine, depending on the Backup_Type. Inputs - Backup_Type 1 - None 2 - Zip Outputs - None """ if Backup_Type == 2: self.archive_engine_to_use = zip_file_engine () self.create_archive_filename () self.archive_engine_to_use.open_Backup ( readonly = True, filename = self.archive_filename ) def close_archive_file ( self ): """Stop and Close the Archive File. This does terminate the Archive Engine. But does not terminate the Backup_Engine. Inputs - None Outputs - None; Internally resets the archive engine to a closed state. """ self.archive_engine_to_use.close_Backup () def walk_directory_tree ( self, notify_directory = None, notify_file = None ): """Walk the source directory tree, and add each file/directory into the archive file. Inputs - notify_directory (Pointer) - see below notify_file (Pointer) - see below Outputs - None If you wish to have a console output for the walk function, you can have that via the notify_directory and notify_file functions.... Create two stubs and pass them to the walk routine. The routines only have a single input, either a directory name, or a filename, depending on the function. def notify_dir ( directory_name ): print print "Processing Directory - %s " % directory_name def notify_file ( file_name ): print "\t\tFile - %s " % file_name Backup_Engine.walk_directory_tree ( notify_directory = notify_dir, notify_file = notify_file ) """ selfexclude = os.path.normpath(self.archive_filename) if self.force_quiet: notify_directory = None notify_file = None for root, dirs, files in os.walk( self.directory_to_backup ): if notify_directory <> None: notify_directory ( root ) for file in files: if notify_file <> None: notify_file ( file ) # # Add the file to the backup zip file. # if os.path.normpath(file) <> selfexclude: # self.archive_engine_to_use.add_file_to_Backup ( root + os.sep + file, root + os.sep + file) # else: # print "Skipping, it is backup file - %s" % file exclude_file = False if os.path.normpath(file) == selfexclude: exclude_file = True if file.strip().upper() in self.exclude_files_dir: exclude_file = True if root <> '.': root_segment = root.strip().upper().split(os.sep) for x in root_segment: if x in self.exclude_files_dir: exclude_file = True #self.exclude_exts for x in self.exclude_exts: #print "X: ", x.strip(), " - ", os.path.splitext( file )[1].upper().strip() #print x.strip() == os.path.splitext( file )[1].upper().strip() if x.strip() == os.path.splitext( file )[1].upper().strip(): exclude_file = True if not exclude_file: self.archive_engine_to_use.add_file_to_Backup ( root + os.sep + file, root + os.sep + file) # else: # print "Skipping - %s" % file exclude_file = False def notify_dir ( directory_name ): print print "Processing Directory - %s " % directory_name def notify_file ( file_name ): print "\t\tFile - %s " % file_name def Backup_Directories_App (): """Example Application that will backup the Directories as stated in the command line. Inputs - None Outputs - None; FileSystem, Archive file. """ initialization_data = bas_init.initialization_wrapper () initialization_data.cmd_line_interface.add_option ("-s", "--source", action="store", type="string", dest="source", help="Directory Tree to Read From", default=".") initialization_data.cmd_line_interface.add_option ("-t", "--target", action="store", type="string", dest="target", help="Directory to write the backup to", default=".") initialization_data.cmd_line_interface.add_option ("-l", "--label", action="store", type="string", dest="label", help="What to Label the Backup File as", default="backup") initialization_data.cmd_line_interface.add_option ("-p", "--pre", action="store_true", dest="prelabel", help="If used, the label is prepended to the filename. Otherwise it is appended.") initialization_data.cmd_line_interface.add_option ("-q", "--quiet", action="store_true", dest="quiet", help="Force File & Directory printing to be turned off.") initialization_data.cmd_line_interface.add_option ("-x", "--exclude", action="store", type="string", dest="exclude", help="List of files/directories to exclude", default="") initialization_data.cmd_line_interface.add_option ("-z", "--extensions", action="store", type="string", dest="exclude_exts", help="List of file extensions to exclude", default="") initialization_data.run_cmd_line_parse ( ) print "Initialization Successful..." print Backup_Engine = backup_system ( initialization_data.cmd_line_options.source, initialization_data.cmd_line_options.target, initialization_data.cmd_line_options.exclude, initialization_data.cmd_line_options.exclude_exts, initialization_data.cmd_line_options.label, initialization_data.cmd_line_options.prelabel, initialization_data.cmd_line_options.quiet) Backup_Engine.start_archive_engine ( ZIP ) print "Backup Archive - %s " % Backup_Engine.archive_filename Backup_Engine.walk_directory_tree ( notify_directory = notify_dir, notify_file = notify_file ) Backup_Engine.close_archive_file () print "Verifying the Archive File...." if Backup_Engine.Verify_Backup ( ): print print "The Backup has failed!" print print "This file, %s, is bad." % test else: print print "The Backup has been verified!" print print "Backup is successful." print print "Backup Application has completed." if __name__ == "__main__": # If run from the Command line Backup_Directories_App () # run the unit test. From dave.opstad at monotypeimaging.com Wed Apr 27 21:39:03 2005 From: dave.opstad at monotypeimaging.com (Dave Opstad) Date: Wed Apr 27 21:39:10 2005 Subject: [Pythonmac-SIG] Repackaging for Tiger? In-Reply-To: <4269B4E5.8080302@wordtech-software.com> Message-ID: > I've gotten some inquiries from users about my Python packages--PyQt in > particular--and whether they will run on Tiger. Is it safe to say that > Python stuff built/packaged against 2.3 on Panther will probably need to > be repackaged for Tiger, assuming Tiger is using a more recent version > of Python than 2.3.0? For what it's worth, I've heard that 2.3.5 is the version of Python included with Tiger, but I haven't tried to confirm that since we'll all know the answer the day after tomorrow... Dave From janssen at parc.com Wed Apr 27 22:36:02 2005 From: janssen at parc.com (Bill Janssen) Date: Wed Apr 27 22:36:52 2005 Subject: [Pythonmac-SIG] Repackaging for Tiger? In-Reply-To: Your message of "Wed, 27 Apr 2005 12:39:03 PDT." Message-ID: <05Apr27.133609pdt."58617"@synergy1.parc.xerox.com> Aren't micro releases supposed to be backwards compatible? I'd expect an extension like PIL built against Python 2.3.0 to work with 2.3.5, as well. But perhaps the non-Python MacOS libraries have changed enough to make that fail. Stuck on 2.3 for another 18 months, eh? Bill > > I've gotten some inquiries from users about my Python packages--PyQt in > > particular--and whether they will run on Tiger. Is it safe to say that > > Python stuff built/packaged against 2.3 on Panther will probably need to > > be repackaged for Tiger, assuming Tiger is using a more recent version > > of Python than 2.3.0? > > For what it's worth, I've heard that 2.3.5 is the version of Python included > with Tiger, but I haven't tried to confirm that since we'll all know the > answer the day after tomorrow... > > Dave From bob at redivi.com Wed Apr 27 22:55:41 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Apr 27 22:55:54 2005 Subject: [Pythonmac-SIG] Repackaging for Tiger? In-Reply-To: <05Apr27.133609pdt."58617"@synergy1.parc.xerox.com> References: <05Apr27.133609pdt."58617"@synergy1.parc.xerox.com> Message-ID: <822ff6355589915dbacd0e235ee58bb4@redivi.com> On Apr 27, 2005, at 4:36 PM, Bill Janssen wrote: >>> I've gotten some inquiries from users about my Python packages--PyQt >>> in >>> particular--and whether they will run on Tiger. Is it safe to say >>> that >>> Python stuff built/packaged against 2.3 on Panther will probably >>> need to >>> be repackaged for Tiger, assuming Tiger is using a more recent >>> version >>> of Python than 2.3.0? >> >> For what it's worth, I've heard that 2.3.5 is the version of Python >> included >> with Tiger, but I haven't tried to confirm that since we'll all know >> the >> answer the day after tomorrow... >> > Aren't micro releases supposed to be backwards compatible? I'd expect > an extension like PIL built against Python 2.3.0 to work with 2.3.5, > as well. But perhaps the non-Python MacOS libraries have changed > enough to make that fail. Extensions built for Python 2.3.x work fine with 2.3.x for any x assuming everything else that matters is the same... but there are plenty of outside factors that could have changed that would at least require a little preparation to make a package built for 10.3 work for 10.4 (or vice versa, when possible). > Stuck on 2.3 for another 18 months, eh? Only if you want to be. Python 2.4.1 is the only Python I "support". I still build packages for 2.3, only because it takes an extra few seconds to do so, but I don't test them anymore. -bob From daryl.spitzer at gmail.com Thu Apr 28 00:41:42 2005 From: daryl.spitzer at gmail.com (Daryl Spitzer) Date: Thu Apr 28 00:41:56 2005 Subject: [Pythonmac-SIG] EPS to JPEG with PIL In-Reply-To: References: <35EBDBCC-B68D-11D9-B449-000393816E90@avpress.com> Message-ID: You may also want to look at http://www.macdevcenter.com/pub/a/mac/2004/03/19/core_graphics.html -- Daryl On 4/26/05, Bob Ippolito wrote: > > On Apr 26, 2005, at 3:55 PM, Bill MacKenzie wrote: > > > I need to convert EPS files to JPEG files. So far, all I get is > > failure notices. > > > > The first question is will PIL do this trick? > > Not without Ghostscript installed. You might want to look to the > CoreGraphics wrapper that comes with Apple's distribution of Python, or > to PyObjC's NSImage, NSBitmapImageRep, etc. Apple's stuff is (orders > of magnitude) faster and produces better output anyway. > > You might want to look at Zac's Thumbscrew app for some example source > in this arena: http://www.urbanape.com/software > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From sw at wordtech-software.com Thu Apr 28 05:14:34 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu Apr 28 05:14:41 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? Message-ID: <4270551A.5080808@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As I plan to update my Python packages for Tiger, I'd like to get some feedback on which Python people are going to use, the system Python (which I'm surmising is 2.3.x) or Bob's 2.4.1 package. I'm inclined to support just one Python, particularly if there is a strong pull toward one version or the other. So please let me know. - -- 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 iD8DBQFCcFUZJmdQs+6YVcoRAv2gAJ0RuE6roMPaoyl3cLgSmZXtzjmRAQCfbNsq iWMUqdWtUiv0MQrbSXy0Q6k= =1sH+ -----END PGP SIGNATURE----- From sw at wordtech-software.com Thu Apr 28 05:16:54 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Thu Apr 28 05:16:57 2005 Subject: [Pythonmac-SIG] MacPython add-ons? Message-ID: <427055A6.2060202@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone know if Jack is planning a new version of MacPython add-ons for Tiger, as he did with Panther? - -- 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 iD8DBQFCcFWmJmdQs+6YVcoRAsrBAJ47eM1BymOl64Ws83lY4bPkCc+cMwCeILWN 2pPyNBYpk5wfDzeXxuH9MNU= =qED2 -----END PGP SIGNATURE----- From bob at redivi.com Thu Apr 28 05:25:42 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Apr 28 05:25:48 2005 Subject: [Pythonmac-SIG] MacPython add-ons? In-Reply-To: <427055A6.2060202@wordtech-software.com> References: <427055A6.2060202@wordtech-software.com> Message-ID: <6AA65898-A73B-421B-A1C0-E83DF8E624E6@redivi.com> On Apr 27, 2005, at 11:16 PM, Kevin Walzer wrote: > Does anyone know if Jack is planning a new version of MacPython add- > ons > for Tiger, as he did with Panther? Since some people already have Tiger I'm just going to go ahead and say it... The Panther ones should work fine, as long as /Library/Python/2.3 ends up in sys.path. In Tiger, it was changed to /Library/Python/2.3/ site-packages to be consistent with the rest of the universe (i.e. ~/ Library/Python/2.3/site-packages). If you install this: http://pythonmac.org/packages/TigerPython23Compat.pkg.zip It will make a .pth in /Library/Python/2.3/site-packages that will add /Library/Python/2.3 as a site directory, so packages intended for Panther's 2.3.0 will be usable by Tiger's 2.3.5. -bob From lee_cullens at mac.com Thu Apr 28 05:26:05 2005 From: lee_cullens at mac.com (Lee Cullens) Date: Thu Apr 28 05:26:12 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <4270551A.5080808@wordtech-software.com> References: <4270551A.5080808@wordtech-software.com> Message-ID: You asked, I'm still getting up to speed for some multimedia development, but I've been using 2.4 on my Mac since Bob put the thing up. I'll continue to do so with Tiger also. Lee C On Apr 27, 2005, at 11:14 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > As I plan to update my Python packages for Tiger, I'd like to get some > feedback on which Python people are going to use, the system Python > (which I'm surmising is 2.3.x) or Bob's 2.4.1 package. I'm inclined to > support just one Python, particularly if there is a strong pull toward > one version or the other. So please let me know. > > > - -- > 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 > > iD8DBQFCcFUZJmdQs+6YVcoRAv2gAJ0RuE6roMPaoyl3cLgSmZXtzjmRAQCfbNsq > iWMUqdWtUiv0MQrbSXy0Q6k= > =1sH+ > -----END PGP SIGNATURE----- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From delza at livingcode.org Thu Apr 28 05:59:25 2005 From: delza at livingcode.org (Dethe Elza) Date: Thu Apr 28 05:59:23 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <4270551A.5080808@wordtech-software.com> References: <4270551A.5080808@wordtech-software.com> Message-ID: <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> I'm using 2.4.1 and will be generally be running the latest stable release. Using py2app makes it so convenient to just include the Python I'm working with, and it's now easy to install the latest Python, there's less and less reason to fiddle around with older versions. --Dethe From bob at redivi.com Thu Apr 28 06:03:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Apr 28 06:03:12 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> References: <4270551A.5080808@wordtech-software.com> <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> Message-ID: On Apr 27, 2005, at 11:59 PM, Dethe Elza wrote: > I'm using 2.4.1 and will be generally be running the latest stable > release. Using py2app makes it so convenient to just include the > Python I'm working with, and it's now easy to install the latest > Python, there's less and less reason to fiddle around with older > versions. Yeah, same here :) -bob From Henning.Ramm at mediapro-gmbh.de Thu Apr 28 08:31:36 2005 From: Henning.Ramm at mediapro-gmbh.de (Henning.Ramm@mediapro-gmbh.de) Date: Thu Apr 28 08:31:42 2005 Subject: [Pythonmac-SIG] ZipFile revision.... Message-ID: >import bas_init What's this? > print "This file, %s, is bad." % test test is undefined. Best regards, Henning Hraban Ramm S?dkurier Medienhaus / MediaPro Support/Admin/Development Dept. From mark at mophilly.com Thu Apr 28 16:56:20 2005 From: mark at mophilly.com (Mark Phillips) Date: Fri Apr 29 02:32:59 2005 Subject: [Pythonmac-SIG] Python and Startup Item Message-ID: I have created a Startup Item for macos x server 10.3.9 that invokes a shell script to start a python process. The startup item is called but the script fails. The app works if invoked from the terminal. The log simply says the script failed. The Startup Item script cd's to the appropriate directory, then ./AppLauncher to invoke the launch script. The launch script includes "/usr/bin/env python Launch.py". Both AppLauncher shell script and Launch.py have been thoroughly tested on Linux. The sys log in Server Admin tool says only that the Startup Item script failed. Where can I find debug or more detail about the failure? Mark Phillips From bob at redivi.com Thu Apr 28 20:49:56 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 02:41:38 2005 Subject: [Pythonmac-SIG] Repackaging for Tiger? In-Reply-To: <05Apr28.111130pdt."58617"@synergy1.parc.xerox.com> References: <05Apr28.111130pdt."58617"@synergy1.parc.xerox.com> Message-ID: On Apr 28, 2005, at 2:11 PM, Bill Janssen wrote: > Bob Ippolito writes: >> Only if you want to be. Python 2.4.1 is the only Python I "support". >> I still build packages for 2.3, only because it takes an extra few >> seconds to do so, but I don't test them anymore. > > That's too bad, Bob. If as rumored 2.3.5 is the Python on Tiger, I'd > expect that to be what people building packages for Tiger would use. > And you've been a big help (dramatic understatement there :-) to the > Mac+Python community in the past -- I imagine we'll miss that help. Well, as I said, I'll still be building Python 2.3 packages so long as it is convenient to do so.. However, I quite like Python 2.4 (enhanced speed, bug fixes and feature enhancements, generator expressions, decorators, etc.), so I have no good reason to use Python 2.3. I will test PyObjC and py2app under Python 2.3, but packages that are "third party" to me aren't going to get any attention in that environment. -bob From bob at redivi.com Thu Apr 28 17:32:08 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 02:41:39 2005 Subject: [Pythonmac-SIG] Building packages In-Reply-To: <6a55650d813fac489d928d9bf89c7ab1@laposte.net> References: <82a382ec65ad74b4f5c986b400f5ba8f@laposte.net> <6a55650d813fac489d928d9bf89c7ab1@laposte.net> Message-ID: <9192FF87-2469-4907-81F4-45B99EEB8EB8@redivi.com> On Apr 28, 2005, at 5:03 AM, konrad.hinsen@laposte.net wrote: > On Apr 26, 2005, at 11:27, Bob Ippolito wrote: > > >> I do something equivalent to this (where both python installations >> have a pth file pointing to the src directory of py2app svn trunk, >> and the scripts dir of py2app is in my PATH): >> >> python2.4 `which bdist_mpkg` -z >> python2.3 `which bdist_mpkg` -z >> > > Thanks, that works fine. One more technical question: how did you > add documentation to the py2app package? By manually modifying the > automatically generated package, or using some non-obvious > functionality? Subclassing the bdist_mpkg command. Adding extra stuff to the package requires explicit support for bdist_mpkg inside the setup.py. >> ... then I move dist/*.zip to the right place, generate md5 >> checksums, edit the data file that generates the html, run a >> script that makes new html and then does rsync over ssh to the >> server. Generally I'll do my own installation by downloading from >> the web site and installing that to make sure it works (but I only >> really test python 2.4 packages these days). >> > > A more strategic question: what do you see as the role of your > package repository? A collection of what you happen to use, made > public? A standard repository that anyone can and should contribute > to? Or something else? The idea is that it should be a standard repository that anyone can and should contribute to, where "anyone" is a small number of people that I can trust to build good working packages :) > To give a concrete example, should I refer users of my packages to > your site for stuff like NumPy, or better offer a copy on my own > server to be sure to have 23.7 at all times? pythonmac packages will only have the latest version of any given package around, so if Numeric is upgraded to 23.8 then that will be the only version available. If you want old versions of things, then you should make a copy of it. Though I usually don't delete old packages, you shouldn't depend on me keeping the zips around long after they've disappeared from the index. -bob From charles.hartman at conncoll.edu Thu Apr 28 13:48:42 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Apr 29 02:41:40 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: References: <4270551A.5080808@wordtech-software.com> <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> Message-ID: What, do without generator expressions?? I don't think so. Charles Hartman On Apr 28, 2005, at 12:03 AM, Bob Ippolito wrote: > > On Apr 27, 2005, at 11:59 PM, Dethe Elza wrote: > >> I'm using 2.4.1 and will be generally be running the latest stable >> release. Using py2app makes it so convenient to just include the >> Python I'm working with, and it's now easy to install the latest >> Python, there's less and less reason to fiddle around with older >> versions. > > Yeah, same here :) > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From charles.hartman at conncoll.edu Thu Apr 28 17:28:48 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Apr 29 02:41:45 2005 Subject: [Pythonmac-SIG] message delays on list? Message-ID: [incidental gripe] I don't understand why -- sometimes, not always -- it can take two hours or more for a message I send to show up on the list. Just server gaggage somewhere? Charles Hartman From janssen at parc.com Thu Apr 28 20:20:53 2005 From: janssen at parc.com (Bill Janssen) Date: Fri Apr 29 02:41:51 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: Your message of "Wed, 27 Apr 2005 20:14:34 PDT." <4270551A.5080808@wordtech-software.com> Message-ID: <05Apr28.112055pdt."58617"@synergy1.parc.xerox.com> Whichever one ships with new Macs (presumably 2.3.5). Bill > As I plan to update my Python packages for Tiger, I'd like to get some > feedback on which Python people are going to use, the system Python > (which I'm surmising is 2.3.x) or Bob's 2.4.1 package. I'm inclined to > support just one Python, particularly if there is a strong pull toward > one version or the other. So please let me know. From janssen at parc.com Thu Apr 28 20:11:25 2005 From: janssen at parc.com (Bill Janssen) Date: Fri Apr 29 02:41:53 2005 Subject: [Pythonmac-SIG] Repackaging for Tiger? In-Reply-To: Your message of "Wed, 27 Apr 2005 13:55:41 PDT." <822ff6355589915dbacd0e235ee58bb4@redivi.com> Message-ID: <05Apr28.111130pdt."58617"@synergy1.parc.xerox.com> Bob Ippolito writes: > Only if you want to be. Python 2.4.1 is the only Python I "support". > I still build packages for 2.3, only because it takes an extra few > seconds to do so, but I don't test them anymore. That's too bad, Bob. If as rumored 2.3.5 is the Python on Tiger, I'd expect that to be what people building packages for Tiger would use. And you've been a big help (dramatic understatement there :-) to the Mac+Python community in the past -- I imagine we'll miss that help. Bill From konrad.hinsen at laposte.net Thu Apr 28 11:13:02 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Fri Apr 29 02:42:35 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> References: <4270551A.5080808@wordtech-software.com> <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> Message-ID: <62b590de85b68e95bd2b87e27809e21c@laposte.net> On Apr 28, 2005, at 5:59, Dethe Elza wrote: > I'm using 2.4.1 and will be generally be running the latest stable > release. Using py2app makes it so convenient to just include the > Python I'm working with, and it's now easy to install the latest > Python, there's less and less reason to fiddle around with older > versions. > It depends on what you distribute. If it's double-clickable applications, I agree. But I distribute libraries and command-line tools for /usr/local/bin. Unless I have overlooked something, py2app can't do those, and I imagine it would be difficult to build command-line tools that would find a Python version inside an application bundle at an unknown location. So if I go for 2.4, I have to tell all my users to install 2.4 first. That by itself wouldn't perhaps be a big issue (one package more to install), but there is also the problem that if some libraries are provided for 2.3 and others for 2.4, much of the attraction of Python for occasional programmers would be gone. In short, I expect to have to offer packages for both 2.3 and 2.4 and explain the difference to people who don't really care. I'd be happier if the Mac world could agree on a single Python version. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr --------------------------------------------------------------------- From konrad.hinsen at laposte.net Thu Apr 28 11:03:47 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Fri Apr 29 02:42:36 2005 Subject: [Pythonmac-SIG] Building packages In-Reply-To: References: <82a382ec65ad74b4f5c986b400f5ba8f@laposte.net> Message-ID: <6a55650d813fac489d928d9bf89c7ab1@laposte.net> On Apr 26, 2005, at 11:27, Bob Ippolito wrote: > I do something equivalent to this (where both python installations > have a pth file pointing to the src directory of py2app svn trunk, and > the scripts dir of py2app is in my PATH): > > python2.4 `which bdist_mpkg` -z > python2.3 `which bdist_mpkg` -z Thanks, that works fine. One more technical question: how did you add documentation to the py2app package? By manually modifying the automatically generated package, or using some non-obvious functionality? > ... then I move dist/*.zip to the right place, generate md5 checksums, > edit the data file that generates the html, run a script that makes > new html and then does rsync over ssh to the server. Generally I'll > do my own installation by downloading from the web site and installing > that to make sure it works (but I only really test python 2.4 packages > these days). A more strategic question: what do you see as the role of your package repository? A collection of what you happen to use, made public? A standard repository that anyone can and should contribute to? Or something else? To give a concrete example, should I refer users of my packages to your site for stuff like NumPy, or better offer a copy on my own server to be sure to have 23.7 at all times? Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr --------------------------------------------------------------------- From charles.hartman at conncoll.edu Thu Apr 28 15:57:46 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Apr 29 02:42:38 2005 Subject: [Pythonmac-SIG] py2app, unicode, etc Message-ID: <78dac1f68eff9be1e0a016bf3436460d@conncoll.edu> I'm using Python 2.4.1 with wxPython 2.5.4.1 Unicode build. While tracking down messy little problems with string-vs-unicode stuff, I put some code like this in my app: defEng = wx.GetDefaultPyEncoding() print 'default encoding is %s' % defEng If I run this from within the WingIDE debugger, I get default encoding is mac-roman If I run it from the command line, I get default encoding is mac-roman If I use py2app to build a standalone, I get default encoding is utf-8 How come? Charles Hartman From konrad.hinsen at laposte.net Thu Apr 28 22:01:24 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Fri Apr 29 02:43:02 2005 Subject: [Pythonmac-SIG] Building packages In-Reply-To: <9192FF87-2469-4907-81F4-45B99EEB8EB8@redivi.com> References: <82a382ec65ad74b4f5c986b400f5ba8f@laposte.net> <6a55650d813fac489d928d9bf89c7ab1@laposte.net> <9192FF87-2469-4907-81F4-45B99EEB8EB8@redivi.com> Message-ID: On Apr 28, 2005, at 17:32, Bob Ippolito wrote: > Subclassing the bdist_mpkg command. Adding extra stuff to the package > requires explicit support for bdist_mpkg inside the setup.py. OK - something to explore. > The idea is that it should be a standard repository that anyone can > and should contribute to, where "anyone" is a small number of people > that I can trust to build good working packages :) So I guess there is a certification procedure ;-) > pythonmac packages will only have the latest version of any given > package around, so if Numeric is upgraded to 23.8 then that will be > the only version available. If you want old versions of things, then > you should make a copy of it. Though I usually I don't necessarily want old versions, but since Numeric is not binary compatible from one version to the next, I need either stability or a mechanism that makes it reasonable to update my packages a day after Numeric changes. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr --------------------------------------------------------------------- From mark at mophilly.com Fri Apr 29 00:41:00 2005 From: mark at mophilly.com (Mark Phillips) Date: Fri Apr 29 02:50:16 2005 Subject: [Pythonmac-SIG] Python and Startup Items Message-ID: <9f8a70b5292f4f3376f990950867825a@mophilly.com> I have created a Startup Item for macos x server 10.3.9 that invokes a shell script to start a python process. The startup item is called but the script fails. The app works if invoked from the terminal. The log simply says the script failed. The Startup Item script cd's to the appropriate directory, then ./AppLauncher to invoke the launch script. The launch script includes "/usr/bin/env python Launch.py". Both AppLauncher shell script and Launch.py have been thoroughly tested on Linux. The sys log in Server Admin tool says only that the Startup Item script failed. Where can I find debug or more detail about the failure? Mark Phillips Mark Phillips Mophilly & Associates On the web at http://www.mophilly.com On the phone at 619 444-9210 From Benjamin.Schollnick at xerox.com Thu Apr 28 13:46:27 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Fri Apr 29 02:50:32 2005 Subject: [Pythonmac-SIG] ZipFile revision.... Message-ID: <266589E1B9392B4C9195CC25A07C73B9124C48@usa0300ms04.na.xerox.net> My mistake.... >>import bas_init > What's this? Opps... Forgot about that.... I never intended to release this to the public.... I'll send that out as soon as I get into the office... It is a standardized Application Initialization routine(s). It handles Logfile, ConfigParser setup, and maintaince, that I usually use in multiple applications. > > print "This file, %s, is bad." % test > test is undefined. Haven't run into that... I'll check that out... I think it might just be bad word wrapping from a commented line? I'll have to look into this once I'm in the office... I'm remotely accessing the mail system right now... - Ben From rogerb at rogerbinns.com Fri Apr 29 04:04:46 2005 From: rogerb at rogerbinns.com (Roger Binns) Date: Fri Apr 29 04:04:43 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? References: <05Apr28.112055pdt."58617"@synergy1.parc.xerox.com> Message-ID: <004301c54c5f$d16c31a0$3501a8c0@rogersqyvr14d3> > Whichever one ships with new Macs (presumably 2.3.5). Since I use the same Python version on all platforms, I'll be sticking with 2.3 for a while. The biggest issue is the legal mess with redistributing a Microsoft DLL with Python 2.4 on Windows. If that wasn't an issue, I'd be seriously considering 2.4 in the next month or two :-) Roger From charles.hartman at conncoll.edu Fri Apr 29 04:35:22 2005 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri Apr 29 04:35:28 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <004301c54c5f$d16c31a0$3501a8c0@rogersqyvr14d3> References: <05Apr28.112055pdt."58617"@synergy1.parc.xerox.com> <004301c54c5f$d16c31a0$3501a8c0@rogersqyvr14d3> Message-ID: <2cbdd678c6a316ae2d79045949ca12f5@conncoll.edu> I don't know about that. If I'm building an Open Source app for Mac and Windows (py2app and py2exe standalones), using Python 2.4.1, is there a problem? Charles Hartman On Apr 28, 2005, at 10:04 PM, Roger Binns wrote: >> Whichever one ships with new Macs (presumably 2.3.5). > > Since I use the same Python version on all platforms, I'll be > sticking with 2.3 for a while. The biggest issue is the > legal mess with redistributing a Microsoft DLL with Python 2.4 > on Windows. > > If that wasn't an issue, I'd be seriously considering 2.4 in > the next month or two :-) > > Roger > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Fri Apr 29 04:50:57 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 04:51:03 2005 Subject: [Pythonmac-SIG] py2app, unicode, etc In-Reply-To: <78dac1f68eff9be1e0a016bf3436460d@conncoll.edu> References: <78dac1f68eff9be1e0a016bf3436460d@conncoll.edu> Message-ID: <759dcb755ffe6c13679af8d802c7faad@redivi.com> On Apr 28, 2005, at 9:57 AM, Charles Hartman wrote: > I'm using Python 2.4.1 with wxPython 2.5.4.1 Unicode build. While > tracking down messy little problems with string-vs-unicode stuff, I > put some code like this in my app: > defEng = wx.GetDefaultPyEncoding() > print 'default encoding is %s' % defEng > If I run this from within the WingIDE debugger, I get > default encoding is mac-roman > If I run it from the command line, I get > default encoding is mac-roman > If I use py2app to build a standalone, I get > default encoding is utf-8 > > How come? Because wx.GetDefaultPyEncoding() is weird. It should be returning 'ascii' (because that's python's default default encoding), but for some reason it is returning 'mac-roman'. However, py2app sets the default encoding to utf-8 because that's what the encoding of terminal/console/etc. are. and apparently wx's weird function is picking that up. -bob From bob at redivi.com Fri Apr 29 04:55:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 04:55:19 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <2cbdd678c6a316ae2d79045949ca12f5@conncoll.edu> References: <05Apr28.112055pdt."58617"@synergy1.parc.xerox.com> <004301c54c5f$d16c31a0$3501a8c0@rogersqyvr14d3> <2cbdd678c6a316ae2d79045949ca12f5@conncoll.edu> Message-ID: <5c450fa494fb1c0a416e5e8184764728@redivi.com> Sort of. It depends on what versions of Windows you care about. The older ones don't ship with the version of the runtime that Python 2.4 is built against. It's just a dll that you need to get in their hands, but you'll need to read the license to see if you're allowed to redistribute it or not. In any case, win32 licensing is totally off-topic for here. -bob On Apr 28, 2005, at 10:35 PM, Charles Hartman wrote: > I don't know about that. If I'm building an Open Source app for Mac > and Windows (py2app and py2exe standalones), using Python 2.4.1, is > there a problem? > > Charles Hartman > > On Apr 28, 2005, at 10:04 PM, Roger Binns wrote: > >>> Whichever one ships with new Macs (presumably 2.3.5). >> >> Since I use the same Python version on all platforms, I'll be >> sticking with 2.3 for a while. The biggest issue is the >> legal mess with redistributing a Microsoft DLL with Python 2.4 >> on Windows. >> >> If that wasn't an issue, I'd be seriously considering 2.4 in >> the next month or two :-) >> >> Roger >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Fri Apr 29 04:58:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 04:58:09 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <62b590de85b68e95bd2b87e27809e21c@laposte.net> References: <4270551A.5080808@wordtech-software.com> <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> <62b590de85b68e95bd2b87e27809e21c@laposte.net> Message-ID: <39391d988458b2f9b7cde2c76d8b42bf@redivi.com> On Apr 28, 2005, at 5:13 AM, konrad.hinsen@laposte.net wrote: > On Apr 28, 2005, at 5:59, Dethe Elza wrote: > >> I'm using 2.4.1 and will be generally be running the latest stable >> release. Using py2app makes it so convenient to just include the >> Python I'm working with, and it's now easy to install the latest >> Python, there's less and less reason to fiddle around with older >> versions. >> > It depends on what you distribute. If it's double-clickable > applications, I agree. But I distribute libraries and command-line > tools for /usr/local/bin. Unless I have overlooked something, py2app > can't do those, and I imagine it would be difficult to build > command-line tools that would find a Python version inside an > application bundle at an unknown location. So if I go for 2.4, I have > to tell all my users to install 2.4 first. That by itself wouldn't > perhaps be a big issue (one package more to install), but there is > also the problem that if some libraries are provided for 2.3 and > others for 2.4, much of the attraction of Python for occasional > programmers would be gone. So stop providing libraries for 2.3, eliminate the confusion, and have them install that one extra package. > In short, I expect to have to offer packages for both 2.3 and 2.4 and > explain the difference to people who don't really care. I'd be happier > if the Mac world could agree on a single Python version. Well if it were my decision I'd say that people should stop caring about 2.3, because 2.4 is better in every way (except "they don't already have it") and more supported. 2.3 is more or less at the end of its life, it might have another minor update or two, but Mac users will probably never see them. -bob From kquirk at solidworks.com Fri Apr 29 07:43:29 2005 From: kquirk at solidworks.com (Kent Quirk) Date: Fri Apr 29 07:43:32 2005 Subject: [Pythonmac-SIG] strange py2app problem? Message-ID: I've spent all day trying to get my rather large port of a Python/C++ app to package properly using py2app. Let's just say I've learned a lot. :-) But not quite enough, apparently. I now have a packaged .app with (I hope) everything I need inside it. If I run it from XCode, it runs. If I run it from the command line (as "open myapp.app/" it runs. But if I run it by doubleclicking the app file, it fails. The failure is obscure -- I get a message that I've failed to initialize something that should have long since been initialized. I suspect that either I'm not finding a particular library or framework, or that I'm somehow finding (and loading) it more than once. I've checked paths and environment, and I believe that any remaining differences in these areas are completely unrelated (like the term environment variables). But I've been known to be wrong from time to time. Can anyone offer any suggestions as to where else to look? I'm about out of ideas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20050429/fad062f7/attachment.html From bob at redivi.com Fri Apr 29 07:59:04 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 07:59:12 2005 Subject: [Pythonmac-SIG] strange py2app problem? In-Reply-To: References: Message-ID: <2600F637-FFF1-4D53-946E-6CD42241FC22@redivi.com> On Apr 29, 2005, at 1:43 AM, Kent Quirk wrote: > I've spent all day trying to get my rather large port of a Python/C+ > + app to package properly using py2app. Let's just say I've learned > a lot. :-) > > But not quite enough, apparently. > > I now have a packaged .app with (I hope) everything I need inside > it. If I run it from XCode, it runs. If I run it from the command > line (as "open myapp.app/" it runs. But if I run it by > doubleclicking the app file, it fails. The failure is obscure -- I > get a message that I've failed to initialize something that should > have long since been initialized. I suspect that either I'm not > finding a particular library or framework, or that I'm somehow > finding (and loading) it more than once. > > I've checked paths and environment, and I believe that any > remaining differences in these areas are completely unrelated (like > the term environment variables). But I've been known to be wrong > from time to time. If you send me a copy of whatever it is you're packaging I can probably figure it out in a few minutes. Otherwise, if you post something concrete (the error message(s), os.environ dumps, etc.) then I'll put some thought into it, and hopefully can diagnose-by- proxy sometime in the next week or two. -bob From konrad.hinsen at laposte.net Fri Apr 29 15:03:27 2005 From: konrad.hinsen at laposte.net (konrad.hinsen@laposte.net) Date: Fri Apr 29 15:03:15 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <39391d988458b2f9b7cde2c76d8b42bf@redivi.com> References: <4270551A.5080808@wordtech-software.com> <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> <62b590de85b68e95bd2b87e27809e21c@laposte.net> <39391d988458b2f9b7cde2c76d8b42bf@redivi.com> Message-ID: <385aefb7828151c0d8af55dbe9e659ac@laposte.net> On Apr 29, 2005, at 4:58, Bob Ippolito wrote: > So stop providing libraries for 2.3, eliminate the confusion, and have > them install that one extra package. That's what I would do if I were reasonably sure that everyone else did the same. Which makes me wondering: who is distributing Mac Python packages at all at the moment? There's the PackageManager archive, yours, and Fink, but is there anything else? Fink is separate anyway (they have their own Python), and PackageManager seems to be on its way to the museum. So if your archive is the only one that matters anyway, then we (the participants of this SIG) could start a massive packaging campaign to make it the "industry standard". > Well if it were my decision I'd say that people should stop caring > about 2.3, because 2.4 is better in every way (except "they don't > already have it") and more Personally, I agree, but then I know how important the "they already have it" (plus "it's the official Apple version") argument is for many others. Since I publish packages for the benefit of others, I do listen to them. Konrad. -- --------------------------------------------------------------------- Konrad Hinsen Laboratoire L?on Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: khinsen@cea.fr --------------------------------------------------------------------- From Benjamin.Schollnick at xerox.com Thu Apr 28 16:30:25 2005 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Fri Apr 29 15:28:01 2005 Subject: [Pythonmac-SIG] ZipFile revision.... Message-ID: <266589E1B9392B4C9195CC25A07C73B9AA503A@usa0300ms04.na.xerox.net> My apologies.... I forgot two supplemental imports... (Hopefully a file attach will work on the list...) > -----Original Message----- > From: pythonmac-sig-bounces@python.org > [mailto:pythonmac-sig-bounces@python.org] On Behalf Of > Henning.Ramm@mediapro-gmbh.de > Sent: Thursday, April 28, 2005 2:32 AM > To: pythonmac-sig@python.org > Subject: RE: [Pythonmac-SIG] ZipFile revision.... > > > > >import bas_init > > What's this? > > > print "This file, %s, is bad." % test > > test is undefined. Interesting... Found the section... My version has never created a bad zip file... Here's the revision... print "Verifying the Archive File...." test = Backup_Engine.Verify_Backup ( ) if test: print print "The Backup has failed!" print print "This file, %s, is bad." % test else: print print "The Backup has been verified!" print print "Backup is successful." print print "Backup Application has completed." -------------- next part -------------- A non-text attachment was scrubbed... Name: bas_logging.py Type: application/octet-stream Size: 3950 bytes Desc: bas_logging.py Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050428/e1ee333e/bas_logging-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: bas_init.py Type: application/octet-stream Size: 25738 bytes Desc: bas_init.py Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050428/e1ee333e/bas_init-0001.obj From bob at redivi.com Fri Apr 29 15:29:07 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 15:29:22 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <385aefb7828151c0d8af55dbe9e659ac@laposte.net> References: <4270551A.5080808@wordtech-software.com> <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> <62b590de85b68e95bd2b87e27809e21c@laposte.net> <39391d988458b2f9b7cde2c76d8b42bf@redivi.com> <385aefb7828151c0d8af55dbe9e659ac@laposte.net> Message-ID: On Apr 29, 2005, at 9:03 AM, konrad.hinsen@laposte.net wrote: > On Apr 29, 2005, at 4:58, Bob Ippolito wrote: > > >> So stop providing libraries for 2.3, eliminate the confusion, and >> have them install that one extra package. >> > > That's what I would do if I were reasonably sure that everyone else > did the same. > > Which makes me wondering: who is distributing Mac Python packages > at all at the moment? There's the PackageManager archive, yours, > and Fink, but is there anything else? Fink is separate anyway (they > have their own Python), and PackageManager seems to be on its way > to the museum. > > So if your archive is the only one that matters anyway, then we > (the participants of this SIG) could start a massive packaging > campaign to make it the "industry standard". I would say that the PackageManager archive doesn't really matter. There's not much in there, and from what I've seen it's caused more headaches than it has cured. Also, nearly everything there should also be in pythonmac packages. There's MacEnthon, which matters, and is currently only supporting Panther's 2.3.0. That may or may not change depending on what's best for Enthought and their customers/community. The majority of the work that went into MacEnthon was well underway before 2.4.1 was available, so it's understandable that they used Python 2.3 at the time. > >> Well if it were my decision I'd say that people should stop caring >> about 2.3, because 2.4 is better in every way (except "they don't >> already have it") and more >> > > Personally, I agree, but then I know how important the "they > already have it" (plus "it's the official Apple version") argument > is for many others. Since I publish packages for the benefit of > others, I do listen to them. Well, traditionally, the "official Apple version" hasn't been so great. In Mac OS X 10.2 it was a disaster. Mac OS X 10.3 it was ok, but had some problems. Apple did get everything right in Tiger's build of Python, as far as I can tell, however, that only *really* matters if you're targeting Mac OS X 10.4 (no more no less) and Python 2.3. I would have to imagine that anything you build that depends on Apple's Python 2.3 will no longer function in Mac OS X 10.5 (because it will hopefully include Python 2.5). However, I can nearly guarantee it WILL work if you stick to a third party Python build (unless Apple screws something up badly). I would recommend use of Apple's Python under the following circumstances: - Writing plugins for otherwise non-Python applications. There can only be one Python interpreter per-process, and it makes sense to use the one that's there. This is a trade-off between cooperation of plugins and plugin authors, and compatibility with future versions of Mac OS X. Alternatively, on a per-application basis, it might make sense to have a "meta-plugin" that includes a Python 2.4 interpreter plus some useful libraries (PyObjC, etc.) that other python-based plugins could depend on. - wxPython 2.5.3 or TclTkAqua applications where using the stock libraries and saving 20MB or so (uncompressed) is worth the trade-off of targeting Tiger specifically (knowing that Panther and 10.5 will be incompatible). Or otherwise if saving the 1-2MB of interpreter overhead is worth the risk, though I'd hope that not to be the case. - Anything that otherwise targets Tiger specifically where using Python 2.4 features isn't important. -bob From rswerdlow at goombah.com Fri Apr 29 15:37:46 2005 From: rswerdlow at goombah.com (Bob Swerdlow) Date: Fri Apr 29 15:38:35 2005 Subject: [Pythonmac-SIG] Launching Python Subprocesses with Py2App Message-ID: <05b401c54cc0$b8479d20$066fa8c0@RSWERDLOW800> Hi, I am upgrading our application from bundlebuilder to py2app. It looks great and it looks like it will run on Tiger, which my bundlebuilder version does not. However, I've run into a problem because our application launches subprocesses to run other Python scripts. In the old version with bundlebuilder, sys.executable was in the same location as the Resources, so we used that path to find the file containing the main script for the new process and then used subprocess.POpen to launch sys.executable with that path as an argument. This does not work with py2App because sys.executable is no longer in the same place as the other files and the modules are compressed into site-packages.zip. I found the FAQ on how to locate the bundle resources, but the files that I want python to run cannot be accessed from the command line (since it is in site-packages.zip). I tried adding a copy of the main script for one of the new process as a 'resource', and I can launch it, but site-packages.zip is not in its PYTHONPATH and so it cannot find the other modules it needs. So, the question is, how do I configure my code using py2app so that I can launch a subprocess that runs one of the python scripts embedded in the bundle? Thanks for your help! Bob From bob at redivi.com Fri Apr 29 15:57:50 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 15:58:00 2005 Subject: [Pythonmac-SIG] Launching Python Subprocesses with Py2App In-Reply-To: <05b401c54cc0$b8479d20$066fa8c0@RSWERDLOW800> References: <05b401c54cc0$b8479d20$066fa8c0@RSWERDLOW800> Message-ID: <3E1C2165-3624-4DF3-974D-35131001576A@redivi.com> On Apr 29, 2005, at 9:37 AM, Bob Swerdlow wrote: > I am upgrading our application from bundlebuilder to py2app. It > looks great and it looks like it will run on Tiger, which my > bundlebuilder version does not. Something to finally put the nails in the coffin.. > However, I've run into a problem because our application launches > subprocesses to run other Python scripts. In the old version with > bundlebuilder, sys.executable was in the same location as the > Resources, so we used that path to find the file containing the > main script for the new process and then used subprocess.POpen to > launch sys.executable with that path as an argument. This does not > work with py2App because sys.executable is no longer in the same > place as the other files and the modules are compressed into site- > packages.zip. > > I found the FAQ on how to locate the bundle resources, but the > files that I want python to run cannot be accessed from the command > line (since it is in site-packages.zip). I tried adding a copy of > the main script for one of the new process as a 'resource', and I > can launch it, but site-packages.zip is not in its PYTHONPATH and > so it cannot find the other modules it needs. > > So, the question is, how do I configure my code using py2app so > that I can launch a subprocess that runs one of the python scripts > embedded in the bundle? This use case is not currently well supported by py2app. If you're using py2app from svn, sys.executable will point to something, but PYTHONPATH won't quite be setup properly. If you do this somewhere before you start spawning subprocesses, it might work: # written in Mail... import os import sys # this is definitely currently necessary os.environ['PYTHONPATH'] = ':'.join([p for p in sys.path if isinstance (p, basestring)]) # don't know if this is necessary, might still be set from the py2app bootstrap os.environ['PYTHONHOME'] = sys.prefix But again, I don't support this very well yet because none of my applications need it and I have a bunch of higher priority things to deal with, so YMMV. Patches accepted. Some future version of py2app is going to move sys.executable into the MacOS folder, so don't start hard coding any weird hacks based upon where it happens to sit. -bob From sw at wordtech-software.com Fri Apr 29 16:25:02 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri Apr 29 16:25:09 2005 Subject: [Pythonmac-SIG] WordTech packages: Python 2.4 only Message-ID: <427243BE.9010501@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've decided to support Bob's Python 2.4 only with my various packages (PyQt-Mac, SPE, etc.) as it appears that most people prefer to use the latest version. It will take a couple of weeks to get everything migrated to the new version and tested. I will continue to the older 2.3.0 versions for Panther, but they will not be supported anymore, nor will they be repackaged for Python 2.3.5 on Tiger. - -- 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 iD8DBQFCckO9JmdQs+6YVcoRAn60AJ0Svj0YvrdbbChIcOXWziqxhAPuRACfQ3jA 7rTcslFAJyFHyorwYCuDLN8= =4DBE -----END PGP SIGNATURE----- From sw at wordtech-software.com Fri Apr 29 16:38:54 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri Apr 29 16:39:00 2005 Subject: [Pythonmac-SIG] Python help package for PythonIDE--2.4 Message-ID: <427246FE.4050702@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Because I am migrating my packages to Bob's 2.4 package, and because I find the Python Apple Help package in Jack's 2.3 tools very helpful, I am going to work on implementing this in Bob's package. When it's ready, I will make the package available for installation on Tiger. Bob, if you want, I can also provide the materials to you for inclusion in your package. - -- 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 iD8DBQFCckb9JmdQs+6YVcoRAutvAJ0TIXUVFhvpHm2mgZC5IHyvpELAkwCggpac MilfeqDI0dcaAHWOixlBZ9k= =NWhh -----END PGP SIGNATURE----- From sw at wordtech-software.com Fri Apr 29 17:05:10 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri Apr 29 17:05:13 2005 Subject: [Pythonmac-SIG] py2applet and Python 2.4 Message-ID: <42724D26.7050501@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm experimenting with py2applet and the Python 2.4.1 package. I previously installed py2app in the standard way against Apple's system Python. py2applet calls #!/usr/bin/python and when I changed that to #!/usr/local/bin/python, it complained that py2app modules couldn't be found. Is there a way to easily get py2app configured for 2.4.1 or do I ~ need to build it from source? - -- 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 iD8DBQFCck0lJmdQs+6YVcoRAj5aAJ47qUojK5ZIXZz7+986aED6D/4NfwCdGH8z 6L0Ea92HMFWPsiU0W3QkjNc= =Po2k -----END PGP SIGNATURE----- From sw at wordtech-software.com Fri Apr 29 17:09:07 2005 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri Apr 29 17:09:10 2005 Subject: [Pythonmac-SIG] py2app/2.4 Message-ID: <42724E13.2030308@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doh! I found a pre-built installer on Bob's site. Sorry for the false alarm. - -- 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 iD8DBQFCck4TJmdQs+6YVcoRAka7AJ96aNpY6XIddyR722XrmFsxQvb0gQCeI95F MKnHHGx7+IQqegY3aIJnuH0= =eC5N -----END PGP SIGNATURE----- From mark at mophilly.com Fri Apr 29 22:04:36 2005 From: mark at mophilly.com (Mark Phillips) Date: Fri Apr 29 22:04:45 2005 Subject: [Pythonmac-SIG] Python and Startup Items In-Reply-To: <9f8a70b5292f4f3376f990950867825a@mophilly.com> References: <9f8a70b5292f4f3376f990950867825a@mophilly.com> Message-ID: <25c1c2a366a05a92157f9c30f4aae696@mophilly.com> On Apr 28, 2005, I wrote: > I have created a Startup Item for macos x server 10.3.9 that invokes a > shell script to start a python process. The startup item is called but > the script fails. For anyone who read my query and wondered "yeah, what is the solution to that"... Gary Perez provided the solution I needed: system daemons and mach_init.d. You can read his page regarding Webware for details. Scroll to the bottom of his page. Worked perfectly. BTW, I failed to specify in my post that I was concerned with system services, not user level startup behavior. Mark Phillips From Chris.Barker at noaa.gov Fri Apr 29 23:24:04 2005 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri Apr 29 22:25:38 2005 Subject: [Pythonmac-SIG] Which Python are people going to use? In-Reply-To: <385aefb7828151c0d8af55dbe9e659ac@laposte.net> References: <4270551A.5080808@wordtech-software.com> <5a6f7c0f3e6ba45e6753773356a8ccfc@livingcode.org> <62b590de85b68e95bd2b87e27809e21c@laposte.net> <39391d988458b2f9b7cde2c76d8b42bf@redivi.com> <385aefb7828151c0d8af55dbe9e659ac@laposte.net> Message-ID: <4272A5F4.8020701@noaa.gov> konrad.hinsen@laposte.net wrote: > So if your archive is the only one that matters anyway, then we (the > participants of this SIG) could start a massive packaging campaign to > make it the "industry standard". Yes, Yes, Yes! please, let's all do this! It's really a nightmare that people can get packages from all over the place, and they are all a little different, etc. I'd love it if I could just send everyone to the same place for everything. It's bad enought hat fink confuses everyone. If we do do this, it would be nice to spruce up that site a little bit. A few thoughts: * The main page could have links to repositories for each OS-X and Python version, rather than having it all in a big list. * Each package could have a reference of some kind to he maintainer, who will not always be Bob. For instance, I contributed the matplotlib package...which I have yet to update for 2.4 and the latest version of MPL. * I'd even like to see MacEnthon distributed here, but if not, should we have packages that duplicate what's in there? (matplotlib, for instance) perhaps there should be a link to it there as well. * There are a number of libraries that OS-X does not provide that I suspect are needed by various python packages (libjpeg, libpng, ???). Would it make sense to have a "dynamic library package" that other packages depended on, rather than staticly linking them to each package? * Is there anything we should be doing with PyPi? > Personally, I agree, but then I know how important the "they already > have it" (plus "it's the official Apple version") That actually helps me a lot with marketing Python to co-workers, though I guess I can get some bang just by saying that Apple is delivering Python by default, even if my stuff doesn't use their version. -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 serge at rohan.sdsu.edu Fri Apr 29 22:33:16 2005 From: serge at rohan.sdsu.edu (Serge Rey) Date: Fri Apr 29 22:33:50 2005 Subject: [Pythonmac-SIG] py2app question Message-ID: <20050429203316.GA17364@typhoon.sdsu.edu> i'm trying to build a tkinter app using py2app and think i'm almost there but have hit a bit of a bump. the app starts but then immediately closes if i start it either of the following two ways: a. clicking on the starsgui.app icon in finder b. open starsgui.app (from a shell) however, from a shell if i cd into: starsgui.app/Contents/MacOS and then ./starsgui.app the built app runs just fine. so my question is, am i neglecting something painfully obvious that explains why cases a and b don't quite work yet? this is all under python 2.4 and py2app 0.1.9 thanks, s. -- Serge Rey http://geography.sdsu.edu/People/Faculty/rey.html To recognize that nature has neither a preference for our species nor a bias against it takes only a little courage. -- James Randi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050429/2ff46295/attachment.pgp From bob at redivi.com Fri Apr 29 22:36:15 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 22:36:26 2005 Subject: [Pythonmac-SIG] py2app question In-Reply-To: <20050429203316.GA17364@typhoon.sdsu.edu> References: <20050429203316.GA17364@typhoon.sdsu.edu> Message-ID: On Apr 29, 2005, at 4:33 PM, Serge Rey wrote: > i'm trying to build a tkinter app using py2app and think i'm almost > there but have hit a bit of a bump. > > the app starts but then immediately closes if i start it either of the > following two ways: > > a. clicking on the starsgui.app icon in finder > b. open starsgui.app (from a shell) > > however, from a shell if i cd into: > starsgui.app/Contents/MacOS > and then > ./starsgui.app > > the built app runs just fine. > > > so my question is, am i neglecting something painfully obvious that > explains why cases a and b don't quite work yet? > > this is all under python 2.4 and py2app 0.1.9 Sounds like you did something really weird. The executable shouldn't be named starsgui.app?! You're going to have to post more about what you're doing (i.e. at least your setup.py) before I'd know something definitive. -bob From serge at rohan.sdsu.edu Fri Apr 29 23:09:40 2005 From: serge at rohan.sdsu.edu (Serge Rey) Date: Fri Apr 29 23:10:22 2005 Subject: [Pythonmac-SIG] py2app question In-Reply-To: References: <20050429203316.GA17364@typhoon.sdsu.edu> Message-ID: <20050429210940.GC17364@typhoon.sdsu.edu> On Fri, Apr 29, 2005 at 04:36:15PM -0400, Bob Ippolito wrote: > > On Apr 29, 2005, at 4:33 PM, Serge Rey wrote: > > >i'm trying to build a tkinter app using py2app and think i'm almost > >there but have hit a bit of a bump. > > > >the app starts but then immediately closes if i start it either of the > >following two ways: > > > > a. clicking on the starsgui.app icon in finder > > b. open starsgui.app (from a shell) > > > >however, from a shell if i cd into: > > starsgui.app/Contents/MacOS > >and then > > ./starsgui.app > > > >the built app runs just fine. > > > > > >so my question is, am i neglecting something painfully obvious that > >explains why cases a and b don't quite work yet? > > > >this is all under python 2.4 and py2app 0.1.9 > > Sounds like you did something really weird. The executable shouldn't > be named starsgui.app?! You're going to have to post more about what > you're doing (i.e. at least your setup.py) before I'd know something > definitive. sorry, the executable is starsgui not starsgui.app so the successful start is with ./starsgui from within starsgui.app/Contents/MacOs here is setup.py: from distutils.core import setup import py2app setup( app=['starsgui.py'], ) -- Serge Rey http://geography.sdsu.edu/People/Faculty/rey.html Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it. - Richard Feynman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20050429/b86ebb3b/attachment.pgp From bob at redivi.com Fri Apr 29 23:51:26 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Apr 29 23:51:34 2005 Subject: [Pythonmac-SIG] py2app question In-Reply-To: <20050429210940.GC17364@typhoon.sdsu.edu> References: <20050429203316.GA17364@typhoon.sdsu.edu> <20050429210940.GC17364@typhoon.sdsu.edu> Message-ID: On Apr 29, 2005, at 5:09 PM, Serge Rey wrote: > On Fri, Apr 29, 2005 at 04:36:15PM -0400, Bob Ippolito wrote: > >> >> On Apr 29, 2005, at 4:33 PM, Serge Rey wrote: >> >> >>> i'm trying to build a tkinter app using py2app and think i'm almost >>> there but have hit a bit of a bump. >>> >>> the app starts but then immediately closes if i start it either >>> of the >>> following two ways: >>> >>> a. clicking on the starsgui.app icon in finder >>> b. open starsgui.app (from a shell) >>> >>> however, from a shell if i cd into: >>> starsgui.app/Contents/MacOS >>> and then >>> ./starsgui.app >>> >>> the built app runs just fine. >>> >>> >>> so my question is, am i neglecting something painfully obvious that >>> explains why cases a and b don't quite work yet? >>> >>> this is all under python 2.4 and py2app 0.1.9 >>> >> >> Sounds like you did something really weird. The executable shouldn't >> be named starsgui.app?! You're going to have to post more about what >> you're doing (i.e. at least your setup.py) before I'd know something >> definitive. >> > > sorry, the executable is starsgui not starsgui.app > so the successful start is with ./starsgui > from within starsgui.app/Contents/MacOs > > > here is setup.py: > > from distutils.core import setup > import py2app > setup( > app=['starsgui.py'], > ) Perhaps there's something weird about what your application assumes its environment is going to be? Check /Applications/Utilities/Console -bob From python at adhamh.com Sat Apr 30 00:56:16 2005 From: python at adhamh.com (Adhamh Findlay) Date: Sat Apr 30 00:56:49 2005 Subject: [Pythonmac-SIG] mounting an afp volume Message-ID: <4272BB90.8070400@adhamh.com> Hi All, Python newbie here! I'd like to know the "correct" way to mount an afp volume. Currently I'm using makedirs to create the mount point and then using os.system() to call mount_afp. I've looked for a Carbon.File call that can do this, but couldn't find anything up-to-date. Suggestions? Thanks, Adhamh