From etienne at cs.vu.nl Wed Oct 1 04:33:50 2003 From: etienne at cs.vu.nl (Etienne Posthumus) Date: Wed Oct 1 04:33:54 2003 Subject: [Pythonmac-SIG] WebKit, SVG In-Reply-To: Message-ID: On dinsdag, sep 30, 2003, at 21:10 Europe/Amsterdam, Glenn Andreas wrote: > I've added using WebKit to the "Python Help" window in PyOXIDE - it > took more time to get the pydoc HTML web server running Did you get compile PyObjC from source, or install with Package Manager? I can't figure out how to get Python WebKit installed if you added the WebKit SDK after installing PyObjC. Any tips? Etienne Posthumus From oussoren at cistron.nl Wed Oct 1 04:34:53 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 1 04:34:56 2003 Subject: [Pythonmac-SIG] WebKit, SVG In-Reply-To: <44296DA8-F31B-11D7-B2D5-000A9574DA40@cs.vu.nl> References: <44296DA8-F31B-11D7-B2D5-000A9574DA40@cs.vu.nl> Message-ID: <215E8E5D-F3EA-11D7-896A-0003931CFE24@cistron.nl> On 30 sep 2003, at 9:54, Etienne Posthumus wrote: > > On dinsdag, sep 30, 2003, at 08:29 Europe/Amsterdam, Dinu Gherman > wrote: >> Are there any examples (code, text) of the benefits of using >> the WebKit? > > The 'One-line Browser' example was quite compelling for me... > self.webView.mainFrame().loadRequest_(NSURLRequest.requestWithURL_(NSUR > L.URLWithString_(self.urlText.stringValue()))) > > Can anyone tell me how to get WebKit (the Python part) installed on a > MacPython + PyObjC that was installed via Package Manager? From > reading the list archives it seems you need to install the WebKit SDK > and then compile PyObjC from source to have it included. > But is there an alternative to get WebKit if you don't want to > re-compile from source? You could use an installer package and python2.2 ;-). The only alternatives to get WebKit with PackMan are (1) find someone who already has WebKit and ask them to send you the WebKit module (the directory ..../site-packages/PyObjC/WebKit) and (2) pester the PackMan maintainer (aka Jack) to install the WebKit SDK on the machine he uses to build the binary packages. I'm (slowly) finishing up a 1.0 release of PyObjC, and might include a PackMan receipe with that release. Ronald From gandreas at delver.com Wed Oct 1 10:21:44 2003 From: gandreas at delver.com (Glenn Andreas) Date: Wed Oct 1 10:22:20 2003 Subject: [Pythonmac-SIG] WebKit, SVG Message-ID: At 10:33 AM +0200 10/1/03, Etienne Posthumus wrote: >On dinsdag, sep 30, 2003, at 21:10 Europe/Amsterdam, Glenn Andreas wrote: >>I've added using WebKit to the "Python Help" window in PyOXIDE - it >>took more time to get the pydoc HTML web server running > >Did you get compile PyObjC from source, or install with Package Manager? >I can't figure out how to get Python WebKit installed if you added >the WebKit SDK after installing PyObjC. > >Any tips? > >Etienne Posthumus PyOXIDE is a little different in that it is a Objective-C application that uses the Python framework (rather than a stand-alone set of scripts). The application itself links with the Webkit framework (as well as the Cocoa framework, Python framework, and SystemPreferences framework), but otherwise uses PyObjC as installed with the Package Manager. Other than just adding the framework (which, as near as I can tell just adds another -framework option tot he build process) nothing else was done. I'm guessing that if you can build PyObjC just adding the Webkit framework would be sufficient to ensure that Webkit classes are available (I did no tweaks with PyObjC or make a WebKit module or anything, so I may be missing something, but then again, I'm just using a WebView in a window, so nothing complicated) -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From earthyfemme at earthlink.net Wed Oct 1 12:26:32 2003 From: earthyfemme at earthlink.net (earthyfemme) Date: Wed Oct 1 12:26:40 2003 Subject: [Pythonmac-SIG] Python for beginners Message-ID: <31225617.1065025597133.JavaMail.root@waldorf.psp.pas.earthlink.net> I'm new to Python.. where is a good tutorial for beginners? "I have seen the future, and it licks itself clean." \r\n-Bucky the Cat, "Get Fuzzy" \r\n From mwh at python.net Wed Oct 1 12:29:24 2003 From: mwh at python.net (Michael Hudson) Date: Wed Oct 1 12:28:43 2003 Subject: [Pythonmac-SIG] Python for beginners In-Reply-To: <31225617.1065025597133.JavaMail.root@waldorf.psp.pas.earthlink.net> (earthyfemme@earthlink.net's message of "Wed, 1 Oct 2003 12:26:32 -0400 (GMT-04:00)") References: <31225617.1065025597133.JavaMail.root@waldorf.psp.pas.earthlink.net> Message-ID: <2m3cec2a6z.fsf@starship.python.net> earthyfemme writes: > I'm new to Python.. where is a good tutorial for beginners? Start here: http://www.python.org/topics/learn If that doesn't suit, please tell us why! Cheers, mwh -- "An infinite number of monkeys at an infinite number of keyboards could produce something like Usenet." "They could do a better job of it." -- the corollaries to Gene Spafford's Axiom #2 of Usenet From oussoren at cistron.nl Wed Oct 1 15:11:48 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 1 15:11:54 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <82A9F6F2-F3C3-11D7-9758-000A95686CD8@redivi.com> References: <82A9F6F2-F3C3-11D7-9758-000A95686CD8@redivi.com> Message-ID: <1B1EBC9E-F443-11D7-862D-0003931CFE24@cistron.nl> On 1 okt 2003, at 5:58, Bob Ippolito wrote: > How about making up a URL scheme for Package Manager.. for example: > > pypimp://undefined.org/pimp/?Numeric This might be pretty usefull, and might reduce the load on the central scapegoat. Another idea: Add a function of comparing versions to pimp. The current plists seem to use a simple string comparison for comparing versions and that doesn't always work. As an example, the entry for PyObjC contains something like: import objc if objc.__version__ < "1.0b1": raise "old version installed" That won't work whenever we get around releasing pyobjc-1.0, as "1.0" < "1.0b1" :-(. Ronald From bob at redivi.com Wed Oct 1 15:23:24 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 1 15:24:01 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <1B1EBC9E-F443-11D7-862D-0003931CFE24@cistron.nl> Message-ID: On Wednesday, Oct 1, 2003, at 15:11 America/New_York, Ronald Oussoren wrote: > > On 1 okt 2003, at 5:58, Bob Ippolito wrote: > >> How about making up a URL scheme for Package Manager.. for example: >> >> pypimp://undefined.org/pimp/?Numeric > > This might be pretty usefull, and might reduce the load on the central > scapegoat. > > Another idea: Add a function of comparing versions to pimp. The > current plists seem to use a simple string comparison for comparing > versions and that doesn't always work. As an example, the entry for > PyObjC contains something like: > > import objc > if objc.__version__ < "1.0b1": > raise "old version installed" > > That won't work whenever we get around releasing pyobjc-1.0, as "1.0" > < "1.0b1" :-(. We need to standardize on a way to do this, obviously.. The string comparison thing is bad, and the scapegoat has to figure out how to find the version for each package (which isn't always possible, because not every package includes this metadata). There should be a standard sys.version_info way of getting package versions. -bob From oussoren at cistron.nl Wed Oct 1 15:33:28 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 1 15:33:33 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: <21B70E0D-F446-11D7-862D-0003931CFE24@cistron.nl> On 1 okt 2003, at 21:23, Bob Ippolito wrote: >> >> That won't work whenever we get around releasing pyobjc-1.0, as "1.0" >> < "1.0b1" :-(. > > We need to standardize on a way to do this, obviously.. The string > comparison thing is bad, and the scapegoat has to figure out how to > find the version for each package (which isn't always possible, > because not every package includes this metadata). > > There should be a standard sys.version_info way of getting package > versions. Not necessarily. It would be nice if every package used the same layout of the version string (maybe the scheme used by python itself), but the Linux package manager seem to have an pretty accurate heuristic for comparing versions. Borrowing that heuristic would also work. BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' option. That makes it harder to throw away packages that are not really needed. Ronald From bob at redivi.com Wed Oct 1 15:39:55 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 1 15:40:32 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <21B70E0D-F446-11D7-862D-0003931CFE24@cistron.nl> Message-ID: <08E6F66E-F447-11D7-9758-000A95686CD8@redivi.com> On Wednesday, Oct 1, 2003, at 15:33 America/New_York, Ronald Oussoren wrote: > > On 1 okt 2003, at 21:23, Bob Ippolito wrote: > >>> >>> That won't work whenever we get around releasing pyobjc-1.0, as >>> "1.0" < "1.0b1" :-(. >> >> We need to standardize on a way to do this, obviously.. The string >> comparison thing is bad, and the scapegoat has to figure out how to >> find the version for each package (which isn't always possible, >> because not every package includes this metadata). >> >> There should be a standard sys.version_info way of getting package >> versions. > > Not necessarily. It would be nice if every package used the same > layout of the version string (maybe the scheme used by python itself), > but the Linux package manager seem to have an pretty accurate > heuristic for comparing versions. Borrowing that heuristic would also > work. Can you find a reference for this? I'm not even sure which Linux package manager you're referring to. > BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' > option. That makes it harder to throw away packages that are not > really needed. You would either need to keep receipts, or the scapegoat would have to maintain an "uninstall program" for each package. Receipts is probably the way to go here, and that would at least partially solve the version-number-string problem (because the scapegoat wouldn't necessarily have to maintain a version checker for each package, but that would be incompatible with packages that the user installed themselves unless distutils was modified to support receipts). -bob From oussoren at cistron.nl Wed Oct 1 16:04:12 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 1 16:04:18 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <08E6F66E-F447-11D7-9758-000A95686CD8@redivi.com> References: <08E6F66E-F447-11D7-9758-000A95686CD8@redivi.com> Message-ID: <6D030FEA-F44A-11D7-862D-0003931CFE24@cistron.nl> On 1 okt 2003, at 21:39, Bob Ippolito wrote: > > On Wednesday, Oct 1, 2003, at 15:33 America/New_York, Ronald Oussoren > wrote: > >> >> On 1 okt 2003, at 21:23, Bob Ippolito wrote: >> >>>> >>>> That won't work whenever we get around releasing pyobjc-1.0, as >>>> "1.0" < "1.0b1" :-(. >>> >>> We need to standardize on a way to do this, obviously.. The string >>> comparison thing is bad, and the scapegoat has to figure out how to >>> find the version for each package (which isn't always possible, >>> because not every package includes this metadata). >>> >>> There should be a standard sys.version_info way of getting package >>> versions. >> >> Not necessarily. It would be nice if every package used the same >> layout of the version string (maybe the scheme used by python >> itself), but the Linux package manager seem to have an pretty >> accurate heuristic for comparing versions. Borrowing that heuristic >> would also work. > > Can you find a reference for this? I'm not even sure which Linux > package manager you're referring to. I don't have a reference at hand, but I'm pretty sure RPM generally "does the right thing" with version numbers. I haven't built linux packages for years though, after I switched to Debian on my Linux machine I haven't felt the need to built packages. > >> BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' >> option. That makes it harder to throw away packages that are not >> really needed. > > You would either need to keep receipts, or the scapegoat would have to > maintain an "uninstall program" for each package. Receipts is > probably the way to go here, and that would at least partially solve > the version-number-string problem (because the scapegoat wouldn't > necessarily have to maintain a version checker for each package, but > that would be incompatible with packages that the user installed > themselves unless distutils was modified to support receipts). I don't see how receipts would help with the version-number problem, other than making it easier to find a version number. Distutils also creates a PKG-INFO file in the source-distribution, that's an easy source for information about packages (to bad this isn't installed when you install a package). I don't think that adding receipts to PackMan would be usefull, unless the end-goal is pushing that code into distutils/the python core. Ronald From bob at redivi.com Wed Oct 1 16:56:02 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 1 16:56:41 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <6D030FEA-F44A-11D7-862D-0003931CFE24@cistron.nl> Message-ID: On Wednesday, Oct 1, 2003, at 16:04 America/New_York, Ronald Oussoren wrote: > > On 1 okt 2003, at 21:39, Bob Ippolito wrote: > >> >> On Wednesday, Oct 1, 2003, at 15:33 America/New_York, Ronald Oussoren >> wrote: >> >>> >>> On 1 okt 2003, at 21:23, Bob Ippolito wrote: >>> >>>>> >>>>> That won't work whenever we get around releasing pyobjc-1.0, as >>>>> "1.0" < "1.0b1" :-(. >>>> >>>> We need to standardize on a way to do this, obviously.. The string >>>> comparison thing is bad, and the scapegoat has to figure out how to >>>> find the version for each package (which isn't always possible, >>>> because not every package includes this metadata). >>>> >>>> There should be a standard sys.version_info way of getting package >>>> versions. >>> >>> Not necessarily. It would be nice if every package used the same >>> layout of the version string (maybe the scheme used by python >>> itself), but the Linux package manager seem to have an pretty >>> accurate heuristic for comparing versions. Borrowing that heuristic >>> would also work. >> >> Can you find a reference for this? I'm not even sure which Linux >> package manager you're referring to. > > I don't have a reference at hand, but I'm pretty sure RPM generally > "does the right thing" with version numbers. I haven't built linux > packages for years though, after I switched to Debian on my Linux > machine I haven't felt the need to built packages. I'd be willing to guess that RPM generally "does the right thing" with version numbers, because the developers that make then generally "provide the right information" to the build tools :) Python developers currently do not have a real standard way of choosing version numbers and they definitely do not put the version number anywhere standard in their modules and packages. >> >>> BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' >>> option. That makes it harder to throw away packages that are not >>> really needed. >> >> You would either need to keep receipts, or the scapegoat would have >> to maintain an "uninstall program" for each package. Receipts is >> probably the way to go here, and that would at least partially solve >> the version-number-string problem (because the scapegoat wouldn't >> necessarily have to maintain a version checker for each package, but >> that would be incompatible with packages that the user installed >> themselves unless distutils was modified to support receipts). > > I don't see how receipts would help with the version-number problem, > other than making it easier to find a version number. Distutils also > creates a PKG-INFO file in the source-distribution, that's an easy > source for information about packages (to bad this isn't installed > when you install a package). Having an installed PKG-INFO file would be awesome, but how would this accommodate non-package installs unless the PKG-INFO file was part of a receipt that got stashed somewhere? Personally I think anything installed in site-packages should be a package in the first place, even if it has an __init__ that says from module import *. > I don't think that adding receipts to PackMan would be usefull, unless > the end-goal is pushing that code into distutils/the python core. Receipts are the only reasonable way to do uninstallation and would let us do version checking without running arbitrary Python code (which I really don't like, mixing metadata with code). -bob From just at letterror.com Thu Oct 2 04:15:49 2003 From: just at letterror.com (Just van Rossum) Date: Thu Oct 2 04:15:36 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: Bob Ippolito wrote: > > I don't think that adding receipts to PackMan would be usefull, > > unless the end-goal is pushing that code into distutils/the python > > core. > > Receipts are the only reasonable way to do uninstallation and would > let us do version checking without running arbitrary Python code > (which I really don't like, mixing metadata with code). Same here/Mee too: - I really dislike PackMan executing code from the .plist - Receipts are the way to go Just From Jack.Jansen at cwi.nl Thu Oct 2 17:48:29 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Oct 2 17:48:34 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <1B1EBC9E-F443-11D7-862D-0003931CFE24@cistron.nl> References: <82A9F6F2-F3C3-11D7-9758-000A95686CD8@redivi.com> <1B1EBC9E-F443-11D7-862D-0003931CFE24@cistron.nl> Message-ID: <28C65F74-F522-11D7-91B8-000A27B19B96@cwi.nl> On 1-okt-03, at 21:11, Ronald Oussoren wrote: > Another idea: Add a function of comparing versions to pimp. The intention was that there was going to be a default version check that worked exactly this way. This should be done for the next version. The default version check should probably first use a verbatim string equality check, if that fails get '[0-9.]*' from both versions and compare those for less and greater, and if those are identical but the rest of the version strings differ give up. > BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' > option. That makes it harder to throw away packages that are not > really needed. distutils should support this, then it would be easy. There's hooks in pimp to record what files have been installed, but as this information is incomplete I didn't follow up on it. For binary installations life is easier, as we *do* know what has been installed, but there still another problem: installs can overwrite existing files, so we should stash these away somewhere. For this we could probably look for good ideas in other installers. And Just said: > - I really dislike PackMan executing code from the .plist I can't think of any other way to make things truly extensible. But we should definitely allow for some sort of public key scheme to be used. I've been toying with the idea of using the secure http of your browser, something like a "check integrity" button that would take the MD5 sum of the database, get an entry IntegrityCheck from the database (of the form "https://www.python.org/pimp/integrity/%s.html") fill in the md5sum and send your browser there. Probably the user should get a dialog first (from pimp) explaining how to check the integrity (look at the padlock) and what it means (you're only trusting the fact that whoever maintains the website also created this pimp database). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Thu Oct 2 18:37:05 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 2 18:37:45 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <28C65F74-F522-11D7-91B8-000A27B19B96@cwi.nl> Message-ID: On Thursday, Oct 2, 2003, at 17:48 America/New_York, Jack Jansen wrote: > > On 1-okt-03, at 21:11, Ronald Oussoren wrote: >> Another idea: Add a function of comparing versions to pimp. > > The intention was that there was going to be a default version check > that worked > exactly this way. This should be done for the next version. The default > version check should probably first use a verbatim string equality > check, if that > fails get '[0-9.]*' from both versions and compare those for less and > greater, > and if those are identical but the rest of the version strings differ > give up. I suppose I'll go ahead and start working on the next version of pimp/packman, since I'm maintaining the larger database and you don't seem to have a lot of time on your hands. >> BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' >> option. That makes it harder to throw away packages that are not >> really needed. > > distutils should support this, then it would be easy. There's hooks > in pimp to record what files have been installed, but as this > information > is incomplete I didn't follow up on it. For binary installations life > is easier, as we *do* know what has been installed, but there still > another > problem: installs can overwrite existing files, so we should stash > these > away somewhere. For this we could probably look for good ideas in other > installers. Perhaps it should prompt the user? I think that's what most installers do (unless they're preserving stuff so you can roll back, which may or may not be a desired feature). Generally speaking, a given package will only be overwriting files from a previous version of itself, unless it's an upgrade to something in the standard library or elsewhere on your computer which will require administrator access. > > And Just said: >> - I really dislike PackMan executing code from the .plist > > I can't think of any other way to make things truly extensible. Well we're only talking about detecting a previous version of a particular module or package. I'm sure we could develop a reduced syntax that only allowed read only access to files that could parse python code down to abstract syntax trees and extract module level variables with the capability to regex them a bit. That should cover just about any conceivable case without actually executing anything completely arbitrary. > But we should definitely allow for some sort of public key scheme to > be used. I've been toying with the idea of using the secure http of > your browser, something like a "check integrity" button that would > take the MD5 sum of the database, get an entry IntegrityCheck from > the database (of the form > "https://www.python.org/pimp/integrity/%s.html") > fill in the md5sum and send your browser there. Probably the user > should get a dialog first (from pimp) explaining how to check the > integrity (look at the padlock) and what it means (you're only trusting > the fact that whoever maintains the website also created this pimp > database). I already purchased a GeoTrust (browsers trust this CA by default) SSL certificate for pythonmac.org with this purpose in mind. I'm not big on the MD5 sums of databases thing, I think that it should be done with signatures, a la GPG. That way the author could update the database, without python.org updating its, because the public key is the same. Say for example https://python.org/pimp/integrity.plist lists the public keys and/or SSL certificate information for each well known trusted third party database, upon going to that database it can verify the contents by way of the signature and/or SSL certificate. One or the other (signatures or SSL) should be enough, both prevent man in the middle attacks, but both are susceptible to either the signature-owner's computer being compromised, or the SSL webserver being compromised, which is an unlikely event. Using both wouldn't hurt though. -bob From just at letterror.com Fri Oct 3 03:57:57 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 03:57:39 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <28C65F74-F522-11D7-91B8-000A27B19B96@cwi.nl> Message-ID: Jack Jansen wrote: > And Just said: > > - I really dislike PackMan executing code from the .plist > > I can't think of any other way to make things truly extensible. I don't think PackMan needs to be extensible to such an extent. Am I right that the current Python snippets only do version checks? Receipts would work just as well, provided we limit version checking to packages installed through PackMan. I think that's a reasonable constraint. Just From Jack.Jansen at cwi.nl Fri Oct 3 04:35:29 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 04:34:58 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <8B7EE51E-F57C-11D7-BA00-0030655234CE@cwi.nl> On Friday, October 3, 2003, at 12:37 AM, Bob Ippolito wrote: > On Thursday, Oct 2, 2003, at 17:48 America/New_York, Jack Jansen wrote: > >> >> On 1-okt-03, at 21:11, Ronald Oussoren wrote: >>> Another idea: Add a function of comparing versions to pimp. >> >> The intention was that there was going to be a default version check >> that worked >> exactly this way. This should be done for the next version. The >> default >> version check should probably first use a verbatim string equality >> check, if that >> fails get '[0-9.]*' from both versions and compare those for less and >> greater, >> and if those are identical but the rest of the version strings differ >> give up. > > I suppose I'll go ahead and start working on the next version of > pimp/packman, since I'm maintaining the larger database and you don't > seem to have a lot of time on your hands. No, I think we should start with a PEP now. Something like PackMan should in future be a main component of the Python infrastructure for package deployment (the other two components are distutils and pypi), and it should be able to do different things for different people. Note that there are various classes of applications that aren't handled at all by PackMan currently, but probably should. Two I can come up with are: - administrators who want to setup Python with a standard set of extension modules on a large number of lab systems (think classrooms and such). - people doing turnkey solutions based on Python, with a formal acceptance testing and staging procedure. There's undoubtedly many more scenarios. At this point in time we have a strawman implementation that has proven to work fairly well in a limited field of application, but now I think we should take a step back and write up on what we would like the real thing to be. Then other people can comment on it, and we'll end up with a design that should last us for quite some time. If we just start hacking in pet features now it'll get more and more difficult to replace packman with something better in the future. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 3 04:42:53 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 04:42:25 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <942D6BF6-F57D-11D7-BA00-0030655234CE@cwi.nl> On Friday, October 3, 2003, at 09:57 AM, Just van Rossum wrote: > Jack Jansen wrote: > >> And Just said: >>> - I really dislike PackMan executing code from the .plist >> >> I can't think of any other way to make things truly extensible. > > I don't think PackMan needs to be extensible to such an extent. Am I > right that the current Python snippets only do version checks? Receipts > would work just as well, provided we limit version checking to packages > installed through PackMan. I think that's a reasonable constraint. No, receipts are specifically what I *don't* want. I want PackMan to do actual tests of what is available. The problem with receipts is that it causes a package manager to live in a completely self-centered world: it knows about everything it installed itself and nothing else. This means that if I'm an active developer on package X I always have to go out of my way, because the package manager doesn't know that I've built and installed it myself. I've come across this problem with Fink, SGI-inst and various other install managers. I want to build and install Python myself, and if someone reports a problem with package Y that depends on Python I want to use Fink to install Y, but let Y use my copy of Python (so I can test whether the bug has disappeared with my fix, let's assume for the discussion). This always turns out to be difficult without learning the internals of the package manager in question. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 3 04:50:31 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 04:49:55 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: On Friday, October 3, 2003, at 12:37 AM, Bob Ippolito wrote: >> But we should definitely allow for some sort of public key scheme to >> be used. I've been toying with the idea of using the secure http of >> your browser, something like a "check integrity" button that would >> take the MD5 sum of the database, get an entry IntegrityCheck from >> the database (of the form >> "https://www.python.org/pimp/integrity/%s.html") >> fill in the md5sum and send your browser there. Probably the user >> should get a dialog first (from pimp) explaining how to check the >> integrity (look at the padlock) and what it means (you're only >> trusting >> the fact that whoever maintains the website also created this pimp >> database). > > I already purchased a GeoTrust (browsers trust this CA by default) SSL > certificate for pythonmac.org with this purpose in mind. I'm not big > on the MD5 sums of databases thing, I think that it should be done > with signatures, a la GPG. That way the author could update the > database, without python.org updating its, because the public key is > the same. Sorry, I wasn't clear enough. There is no such thing as a central list of trusted packages. Your database would have an IntegrityCheck of . The integrity check succeeding would only mean that the database the user has on-disk is indeed the exact same database as what you created, and by trusting the database the end-user trusts you (or, actually, as you pointed out elsewhere, the end user trusts you and your webhoster). As md5 is included in the standard Python distribution, and its good enough for testing document integrity I see no reason to use something more elaborate. A PGP signature would allow offline verification, but the idea is that the https: integrity check URL handles that bit. -- 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 just at letterror.com Fri Oct 3 05:15:55 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 05:15:40 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <942D6BF6-F57D-11D7-BA00-0030655234CE@cwi.nl> Message-ID: [Just] > > I don't think PackMan needs to be extensible to such an extent. Am > > I right that the current Python snippets only do version checks? > > Receipts would work just as well, provided we limit version > > checking to packages installed through PackMan. I think that's a > > reasonable constraint. [Jack] > No, receipts are specifically what I *don't* want. I want PackMan to > do actual tests of what is available. Apart from availability/version tests, we're going to _need_ receipts if we want to support uninstalls. > The problem with receipts is that it causes a package manager to live > in a completely self-centered world: it knows about everything it > installed itself and nothing else. This means that if I'm an active > developer on package X I always have to go out of my way, because the > package manager doesn't know that I've built and installed it myself. I don't follow: if you're building/installing package X yourself, why would you then want to use PackMan for package X also? I see it pretty much as an either/or situation. PackMan could still detect the availability of package X, and warn the user that it wasn't installed by PackMan itself, and therefore can't tell which version it is. With imp.find_module() this can even be done without doing an actual import -- which touches on another pet peeve of mine, see below. > I've come across this problem with Fink, SGI-inst and various other > install managers. I want to build and install Python myself, and if > someone reports a problem with package Y that depends on Python I > want to use Fink to install Y, but let Y use my copy of Python (so I > can test whether the bug has disappeared with my fix, let's assume > for the discussion). This always turns out to be difficult without > learning the internals of the package manager in question. Hm, this sounds like a reason to clearly document what PackMan does and how it works. And to keep it dead simple. PackMan is for end users. A certain amount of complexity for _developers_ seems pretty much unavoidable, and would be totally acceptable to me. I strongly feel that executing arbitrary code (even from a trusted source) is a big nono. I already have problems with doing arbitrary imports: we've seen that this can cause problems for packages/modules that have import side effects (not that _that's_ a good thing, but it isn't under our control). But we've had this discussion before, and I don't think we're likely to agree here... Just From bob at redivi.com Fri Oct 3 07:13:07 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 07:13:46 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <90E9C412-F592-11D7-8C4A-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 04:50 America/New_York, Jack Jansen wrote: > > On Friday, October 3, 2003, at 12:37 AM, Bob Ippolito wrote: >>> But we should definitely allow for some sort of public key scheme to >>> be used. I've been toying with the idea of using the secure http of >>> your browser, something like a "check integrity" button that would >>> take the MD5 sum of the database, get an entry IntegrityCheck from >>> the database (of the form >>> "https://www.python.org/pimp/integrity/%s.html") >>> fill in the md5sum and send your browser there. Probably the user >>> should get a dialog first (from pimp) explaining how to check the >>> integrity (look at the padlock) and what it means (you're only >>> trusting >>> the fact that whoever maintains the website also created this pimp >>> database). >> >> I already purchased a GeoTrust (browsers trust this CA by default) >> SSL certificate for pythonmac.org with this purpose in mind. I'm not >> big on the MD5 sums of databases thing, I think that it should be >> done with signatures, a la GPG. That way the author could update the >> database, without python.org updating its, because the public key is >> the same. > > Sorry, I wasn't clear enough. There is no such thing as a central list > of trusted packages. > Your database would have an IntegrityCheck of > . > The integrity check succeeding would only mean that the database the > user has on-disk is > indeed the exact same database as what you created, and by trusting > the database the > end-user trusts you (or, actually, as you pointed out elsewhere, the > end user trusts you and > your webhoster). I don't understand how this could possibly be useful for a database that changes often. You need a public key algorithm, not a hashing algorithm. > As md5 is included in the standard Python distribution, and its good > enough for > testing document integrity I see no reason to use something more > elaborate. A PGP signature > would allow offline verification, but the idea is that the https: > integrity check URL > handles that bit. So let's put a public key algorithm into Python and do it the right way. md5 is not going to do what you want it to do. md5 can only verify that a file is very probably exactly the same as what it was when the hash was created, it doesn't tell you it was created by a trusted source. I don't want to implement a crappy solution just because Python doesn't come with particular functionality, functionality that would be useful on its own.. I mean, we *are* already adding functionality to Python, there's no reason we shouldn't be able to add the other bits to facilitate this. -bob From bob at redivi.com Fri Oct 3 07:28:54 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 07:29:32 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: On Friday, Oct 3, 2003, at 05:15 America/New_York, Just van Rossum wrote: > [Just] >>> I don't think PackMan needs to be extensible to such an extent. Am >>> I right that the current Python snippets only do version checks? >>> Receipts would work just as well, provided we limit version >>> checking to packages installed through PackMan. I think that's a >>> reasonable constraint. > > [Jack] >> No, receipts are specifically what I *don't* want. I want PackMan to >> do actual tests of what is available. > [Just] > Apart from availability/version tests, we're going to _need_ receipts > if > we want to support uninstalls. Distutils could/should make the Receipts. If this gets into distutils, this problem is pretty much solved for all but the user-copied-this-to-site-packages-themselves case, but they're pretty much on their own as far as I'm concerned :) [Jack] >> The problem with receipts is that it causes a package manager to live >> in a completely self-centered world: it knows about everything it >> installed itself and nothing else. This means that if I'm an active >> developer on package X I always have to go out of my way, because the >> package manager doesn't know that I've built and installed it myself. [Just] > I don't follow: if you're building/installing package X yourself, why > would you then want to use PackMan for package X also? I see it pretty > much as an either/or situation. > > PackMan could still detect the availability of package X, and warn the > user that it wasn't installed by PackMan itself, and therefore can't > tell which version it is. With imp.find_module() this can even be done > without doing an actual import -- which touches on another pet peeve of > mine, see below. I agree with Just here. [Jack] >> I've come across this problem with Fink, SGI-inst and various other >> install managers. I want to build and install Python myself, and if >> someone reports a problem with package Y that depends on Python I >> want to use Fink to install Y, but let Y use my copy of Python (so I >> can test whether the bug has disappeared with my fix, let's assume >> for the discussion). This always turns out to be difficult without >> learning the internals of the package manager in question. > [Just] > Hm, this sounds like a reason to clearly document what PackMan does and > how it works. And to keep it dead simple. > > PackMan is for end users. A certain amount of complexity for > _developers_ seems pretty much unavoidable, and would be totally > acceptable to me. I agree with this too, I don't think that our target audience is Jack, Just, Ronald, and Bob who are probably half the people who would want to build Python on the Mac themselves. Personally, if someone else had a database of precompiled modules I could install then I'd use theirs, so long as it was up to date and the modules had a tendency to work when I tried them. I'm not terribly often changing the code of someone else's module and recompiling it (other than to get it to work on the Mac), and when I do that the version number is more or less undefined. I am the only one in possession of that particular modified package, neither the author or maintainer created it, and there will be another at some point with a higher version number created by the official source who may or may not received and implemented my changes. As long as Package Manager has a certain amount of overrides so that I could (a) MAYBE be warned that "what you have is not an official version (as last seen by this database), are you sure you want to replace yours?" -- This check may be slow to do for large packages (would require calculating a hash, but maybe file sizes would be enough?). (b) have the option to install a package nomatter what PackMan thinks, unconditionally, if I've checked enough boxes then I think that would cover every use case for me personally. [Just] > I strongly feel that executing arbitrary code (even from a trusted > source) is a big nono. I already have problems with doing arbitrary > imports: we've seen that this can cause problems for packages/modules > that have import side effects (not that _that's_ a good thing, but it > isn't under our control). But we've had this discussion before, and I > don't think we're likely to agree here... I'm with Just on this. Besides, if we do find that PackMan's version-detection-features can't do something in the future we could always issue a PackMan or pimp upgrade. -bob From Jack.Jansen at cwi.nl Fri Oct 3 10:33:50 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 10:40:53 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <9AF6E738-F5AE-11D7-BA00-0030655234CE@cwi.nl> On Friday, October 3, 2003, at 11:15 AM, Just van Rossum wrote: > [Just] >>> I don't think PackMan needs to be extensible to such an extent. Am >>> I right that the current Python snippets only do version checks? >>> Receipts would work just as well, provided we limit version >>> checking to packages installed through PackMan. I think that's a >>> reasonable constraint. > > [Jack] >> No, receipts are specifically what I *don't* want. I want PackMan to >> do actual tests of what is available. > > Apart from availability/version tests, we're going to _need_ receipts > if > we want to support uninstalls. You're absolutely right. The statement I really wanted to make above was: "Using receipts for version testing is specifically what I *don't* want". >> The problem with receipts is that it causes a package manager to live >> in a completely self-centered world: it knows about everything it >> installed itself and nothing else. This means that if I'm an active >> developer on package X I always have to go out of my way, because the >> package manager doesn't know that I've built and installed it myself. > > I don't follow: if you're building/installing package X yourself, why > would you then want to use PackMan for package X also? I see it pretty > much as an either/or situation. Not for package X but for dependent packages! Think of the following scenario: you maintain package X, that is also in PackMan. Package Y depends on package X but you don't maintain it. With a know-it-all package manager you cannot install Y to use your X. There are now three options open to you: - trick the package manager to think that it installed X - install every package depending on X by hand - install two copies of X, one for your development and one through the package manager for use by dependent packages. All of this falls under my favorite annoyance #4: things that get in the way of developers for no obvious reason. > PackMan is for end users. A certain amount of complexity for > _developers_ seems pretty much unavoidable, and would be totally > acceptable to me. > > I strongly feel that executing arbitrary code (even from a trusted > source) is a big nono. Uhm... How about arbitrary setup.py scripts included with packages? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 3 11:03:13 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 11:02:44 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <90E9C412-F592-11D7-8C4A-000A95686CD8@redivi.com> Message-ID: On Friday, October 3, 2003, at 01:13 PM, Bob Ippolito wrote: >> Sorry, I wasn't clear enough. There is no such thing as a central >> list of trusted packages. >> Your database would have an IntegrityCheck of >> . >> The integrity check succeeding would only mean that the database the >> user has on-disk is >> indeed the exact same database as what you created, and by trusting >> the database the >> end-user trusts you (or, actually, as you pointed out elsewhere, the >> end user trusts you and >> your webhoster). > > I don't understand how this could possibly be useful for a database > that changes often. You need a public key algorithm, not a hashing > algorithm. The whole point of the exercise with md5 sums and using your browser for secure http access is to work around the fact that we have no public key algorithm in Python... If you know of one that has a license that is Python-compatible *and* you can convince Guido to incorporate it into Python 2.4: great! I'd gladly use it in PackMan. > So let's put a public key algorithm into Python and do it the right > way. md5 is not going to do what you want it to do. md5 can only > verify that a file is very probably exactly the same as what it was > when the hash was created, it doesn't tell you it was created by a > trusted source. On its own, no. But combined with another algorithm that allows a trusted source to advertise (in a secure way) the md5sums of all relevant documents s/he ever created it does. If you really want I could write it down in Needham-Burrows-Abadi formalism (or whatever the people involved were again). Or, to elaborate on the steps again (taking you as an example): 1. You change your pimp database. 2. You take the md5sum of it, let's say it's 12345 (but with many more digits:-) 3. You create a secure document https://undefined.org/pimp/integrity.html saying "I, Bob Ippolito, created this packman database. Use at your own risk". 4. You don't ever delete this file, even when updating the database. 5. You now upload the database to . 6. My mum downloads your database through packman, and presses the "integrity check" button. 6. She is presented with a dialog You can now use your internet browser to test that this database was actually created by %s. Check that the padlock is closed (if it is open there is a very good chance that this is a forged database). If you get a message about an untrusted certificate this is also a sign of a forgery. Finally check that the URL starts with https: and points to the website of %s. Note that all these checks only mean that this database has not been tampered with since it was created. Whether you trust %s remains wholly up to you. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Fri Oct 3 11:48:27 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 11:49:04 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <07B8F4AA-F5B9-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 11:03 America/New_York, Jack Jansen wrote: > > On Friday, October 3, 2003, at 01:13 PM, Bob Ippolito wrote: >>> Sorry, I wasn't clear enough. There is no such thing as a central >>> list of trusted packages. >>> Your database would have an IntegrityCheck of >>> . >>> The integrity check succeeding would only mean that the database the >>> user has on-disk is >>> indeed the exact same database as what you created, and by trusting >>> the database the >>> end-user trusts you (or, actually, as you pointed out elsewhere, the >>> end user trusts you and >>> your webhoster). >> >> I don't understand how this could possibly be useful for a database >> that changes often. You need a public key algorithm, not a hashing >> algorithm. > > The whole point of the exercise with md5 sums and using your browser > for secure http access is > to work around the fact that we have no public key algorithm in > Python... > > If you know of one that has a license that is Python-compatible *and* > you can convince > Guido to incorporate it into Python 2.4: great! I'd gladly use it in > PackMan. pyCrypto's license is the following (and is not dependent on any other libraries): =================================================================== Distribute and use freely; there are no restrictions on further dissemination and usage except those imposed by the laws of your country of residence. This software is provided "as is" without warranty of fitness for use or suitability for any purpose, express or implied. Use at your own risk or not at all. =================================================================== Incorporating the code into commercial products is permitted; you do not have to make source available or contribute your changes back (though that would be nice). That sounds Python compatible to me :) I think this problem is solved. Crypto supports the following public key algorithms: Public-key algorithms: RSA, DSA, ElGamal, qNEW. ElGamal is what PGP uses, IIRC. What's the procedure to convince Guido that Python should REALLY have this module as part of any distribution that also includes PackMan? >> So let's put a public key algorithm into Python and do it the right >> way. md5 is not going to do what you want it to do. md5 can only >> verify that a file is very probably exactly the same as what it was >> when the hash was created, it doesn't tell you it was created by a >> trusted source. > > On its own, no. But combined with another algorithm that allows a > trusted source to > advertise (in a secure way) the md5sums of all relevant documents s/he > ever created > it does. If you really want I could write it down in > Needham-Burrows-Abadi formalism > (or whatever the people involved were again). > > Or, to elaborate on the steps again (taking you as an example): > > 1. You change your pimp database. > 2. You take the md5sum of it, let's say it's 12345 (but with many more > digits:-) > 3. You create a secure document > https://undefined.org/pimp/integrity.html > saying "I, Bob Ippolito, created this packman database. Use at your > own risk". > 4. You don't ever delete this file, even when updating the database. > 5. You now upload the database to > . > 6. My mum downloads your database through packman, and presses the > "integrity check" > button. > 6. She is presented with a dialog > You can now use your internet browser to test that this database was > actually created by %s. Check that the padlock is closed (if it is > open there is a very good chance that this is a forged database). If > you get a message about an untrusted certificate this is also a sign > of a forgery. Finally check that the URL starts with https: and points > to the website of %s. > > Note that all these checks only mean that this database has not been > tampered > with since it was created. Whether you trust %s remains wholly up > to you. 1. You orchestrate some sort of man in the middle attack. 2. You take the existing integrity.html document 3. You create a new evil packman plist file 4. You add the md5sum of your evil packman plist file and append it to integrity.html 5. You upload the database and integrity.html to your evil man in the middle server The padlock thing helps some, but it only works for people with trusted SSL certificates, which are typically not cheap, and I wouldn't expect everyone maintaining a distribution to have one. I got a ridiculously good deal on the hosting for pythonmac.org, and it came with a free year long SSL cert, so that's why I have one. I'm not sure exactly how md5sum of the plist file helps anything, it seems like redundant information to me. Anyone that could alter the plist file could also alter integrity.html. With a public key algorithm you need to acquire the public key once (say from the site itself the first time you trust the package, the web site that pointed you to the repository, or from python.org somewhere if it's an "officially trusted" repository). Any time after you acquired the unmodified public key you can verify the authenticity of the package list so far as whomever made it was in possession of the public key. -bob From mwh at python.net Fri Oct 3 12:04:20 2003 From: mwh at python.net (Michael Hudson) Date: Fri Oct 3 12:03:36 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <07B8F4AA-F5B9-11D7-A43C-000A95686CD8@redivi.com> (Bob Ippolito's message of "Fri, 3 Oct 2003 11:48:27 -0400") References: <07B8F4AA-F5B9-11D7-A43C-000A95686CD8@redivi.com> Message-ID: <2md6dez4sb.fsf@starship.python.net> Bob Ippolito writes: > pyCrypto's license is the following (and is not dependent on any other > libraries): > =================================================================== > Distribute and use freely; there are no restrictions on further > dissemination and usage except those imposed by the laws of your > country of residence. This software is provided "as is" without > warranty of fitness for use or suitability for any purpose, express > or implied. Use at your own risk or not at all. > =================================================================== > > Incorporating the code into commercial products is permitted; you do > not have to make source available or contribute your changes back > (though that would be nice). > > That sounds Python compatible to me :) I think this problem is > solved. Crypto supports the following public key algorithms: > Public-key algorithms: RSA, DSA, ElGamal, qNEW. > > ElGamal is what PGP uses, IIRC. > > What's the procedure to convince Guido that Python should REALLY have > this module as part of any distribution that also includes PackMan? There are ghastly legal issues that obstruct crypto support (there have been threads on python-dev about this) and there's also a code quality/ease of maintenence issue about pyCrypto itself (I have no idea about it in this regard). Cheers, mwh -- And then the character-only displays went away (leading to increasingly silly graphical effects and finally to ads on web pages). -- John W. Baxter, comp.lang.python From kevino at tulane.edu Fri Oct 3 12:26:20 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Fri Oct 3 12:30:29 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <9AF6E738-F5AE-11D7-BA00-0030655234CE@cwi.nl> Message-ID: <521F3AD8-F5BE-11D7-B874-000393CB1C86@tulane.edu> Hi all, While I personally think Jack's approach is the best from a functionality point of view, I do agree with Just's position and I think we should not be storing any Python executable code into the plist files, version checking or otherwise. Doing things like running setup.py should take place within package manager, using the plist files to determine where said file is, etc. I think this is bad from a security perspective and like wxPython we've seen that module conflicts could occur. I think the solution to both Just and Jack's problems is to have a standard way in Python to store a version number that is NOT inside a Python code file. PKG-INFO springs to mind. Now, it doesn't solve our immediate problem re: dependencies but remember, we're designing software that is not even known by most of the Python community at this point. Once it is better known (I agree with Jack about the PEP), and people know that writing a simple PKG-INFO file and placing it in the root of their module will cause it to work well with PackageManager, they will start doing this. It also means we can take advantage of PKG-INFO even when PM didn't install the package. What do you think? Thanks, Kevin On Friday, October 3, 2003, at 07:33 AM, Jack Jansen wrote: > > On Friday, October 3, 2003, at 11:15 AM, Just van Rossum wrote: > >> [Just] >>>> I don't think PackMan needs to be extensible to such an extent. Am >>>> I right that the current Python snippets only do version checks? >>>> Receipts would work just as well, provided we limit version >>>> checking to packages installed through PackMan. I think that's a >>>> reasonable constraint. >> >> [Jack] >>> No, receipts are specifically what I *don't* want. I want PackMan to >>> do actual tests of what is available. >> >> Apart from availability/version tests, we're going to _need_ receipts >> if >> we want to support uninstalls. > > You're absolutely right. The statement I really wanted to make above > was: "Using receipts for version testing is specifically what I > *don't* want". > >>> The problem with receipts is that it causes a package manager to live >>> in a completely self-centered world: it knows about everything it >>> installed itself and nothing else. This means that if I'm an active >>> developer on package X I always have to go out of my way, because the >>> package manager doesn't know that I've built and installed it myself. >> >> I don't follow: if you're building/installing package X yourself, why >> would you then want to use PackMan for package X also? I see it pretty >> much as an either/or situation. > > Not for package X but for dependent packages! Think of the following > scenario: you maintain package X, that is also in PackMan. Package Y > depends on package X but you don't maintain it. With a know-it-all > package manager you cannot install Y to use your X. > > There are now three options open to you: > - trick the package manager to think that it installed X > - install every package depending on X by hand > - install two copies of X, one for your development and one > through the package manager for use by dependent packages. > > All of this falls under my favorite annoyance #4: things that > get in the way of developers for no obvious reason. > >> PackMan is for end users. A certain amount of complexity for >> _developers_ seems pretty much unavoidable, and would be totally >> acceptable to me. >> >> I strongly feel that executing arbitrary code (even from a trusted >> source) is a big nono. > > Uhm... How about arbitrary setup.py scripts included with packages? > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From just at letterror.com Fri Oct 3 12:47:40 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 12:47:26 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <9AF6E738-F5AE-11D7-BA00-0030655234CE@cwi.nl> Message-ID: Jack Jansen wrote: > > I don't follow: if you're building/installing package X yourself, > > why would you then want to use PackMan for package X also? I see it > > pretty much as an either/or situation. > > Not for package X but for dependent packages! Think of the following > scenario: you maintain package X, that is also in PackMan. Package Y > depends on package X but you don't maintain it. With a know-it-all > package manager you cannot install Y to use your X. I don't see why not: the dependencies don't need to be "hard". > There are now three options open to you: > - trick the package manager to think that it installed X > - install every package depending on X by hand > - install two copies of X, one for your development and one > through the package manager for use by dependent packages. - Install package Y, getting a dialog that goes something like this: Package Y depends on X version a.b.c. You've installed an unknown version of Y. What would you like to do? [Cancel] [Install X and Y a.b.c] [Install X] In other words, it could be up to the user to decide whether to let PackMan handle dependencies or not. > All of this falls under my favorite annoyance #4: things that > get in the way of developers for no obvious reason. Well, lets improve PackMan then... > > PackMan is for end users. A certain amount of complexity for > > _developers_ seems pretty much unavoidable, and would be totally > > acceptable to me. > > > > I strongly feel that executing arbitrary code (even from a trusted > > source) is a big nono. > > Uhm... How about arbitrary setup.py scripts included with packages? Isn't the whole point of PackMan to _not_ have to execute any setup.py's to begin with? With setup.py you build a distro, PackMan does the install without it. Am I missing something? Just From bob at redivi.com Fri Oct 3 12:47:09 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 12:47:43 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <2md6dez4sb.fsf@starship.python.net> Message-ID: <3AAC41A1-F5C1-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 12:04 America/New_York, Michael Hudson wrote: > Bob Ippolito writes: > >> pyCrypto's license is the following (and is not dependent on any other >> libraries): >> =================================================================== >> Distribute and use freely; there are no restrictions on further >> dissemination and usage except those imposed by the laws of your >> country of residence. This software is provided "as is" without >> warranty of fitness for use or suitability for any purpose, express >> or implied. Use at your own risk or not at all. >> =================================================================== >> >> Incorporating the code into commercial products is permitted; you do >> not have to make source available or contribute your changes back >> (though that would be nice). >> >> That sounds Python compatible to me :) I think this problem is >> solved. Crypto supports the following public key algorithms: >> Public-key algorithms: RSA, DSA, ElGamal, qNEW. >> >> ElGamal is what PGP uses, IIRC. >> >> What's the procedure to convince Guido that Python should REALLY have >> this module as part of any distribution that also includes PackMan? > > There are ghastly legal issues that obstruct crypto support (there > have been threads on python-dev about this) and there's also a code > quality/ease of maintenence issue about pyCrypto itself (I have no > idea about it in this regard). According to the homepage: With the relaxing of US export controls for encryption software, it's now possible to distribute cryptographic source code and export it from the US, so now anyone in the world can download the Python Cryptography Toolkit. What are the remaining legal issues? Can you point me to any semi-recent threads? I thought that since the laws were eased up in the US it was pretty safe to throw around cryptography software. Note that the intended use for PackMan isn't cryptography per se, it's cryptographic authentication. The documents themselves won't be encrypted, but will be signed cryptographically for authentication purposes only. As for code quality / ease of maintenance, a cursory glance of the source code makes me think that it looks clean, commented where it matters, and it's got unit tests that are less than trivial. A look at CVS shows that it the code is very stable (most of it hasn't been updated in 5 months or more), but there is still development/fixes (as recent as 3 weeks ago). I can attest to the fact that the code works, because I've seen it work in Twisted (the SSH client and server depend on Crypto, for example). As long as Twisted is around, Crypto will be around (at least one Twisted team member has access to Crypto CVS), which will presumably quite a long time. The code is also very simple, it seems to be as simple as possible but no simpler. Most of the code that looks strange is commented, for example: (from crypto/PublicKey/qNEW.py) # Ensure that p-1 is a multiple of q p = p - (p % (2*obj.q)-1) Not including higher level wrappers, these are the projects that I could easily find that depend on pycrypto to various degrees (which ensures that there's a user base that cares to keep pycrypto alive, working, and bug free): Twisted http://www.twistedmatrix.com/ absolutely necessary for Conch, the SSH2 client/server, optional for AES, DES, RSA, DSA elsewhere (encrypted TAPs, for example) secsh http://www.lag.net/~robey/secsh/ the second pure-python-except-for-pycrypto implementation of ssh2 - currently client only PythonOtp https://moin.conectiva.com.br/PythonOtp implements support for all requirements, recommendations, and optional features described in RFC2289. This RFC defines a standard for the implementation of OTP - one-time passwords (optional dependency on pycrypto for md4) hashtar http://nitace.bsd.uchicago.edu:8080/hashtar an encrypted archive utility designed for secure archiving to media vulnerable to corruption PyHIP http://honor.trusecure.com/pipermail/hipsec/2003-July/000001.html (not sure if it has a real homepage yet) Python Host Identity Protocol implementation (mobility/multihoming), I think it has something to do with ipv6 web2ldap http://www.web2ldap.de/ A generic LDAPv3 client which does not make any assumptions about the tree structure or LDAP schema (optionally uses pycrypto for md4) Cwm http://www.w3.org/2000/10/swap/doc/cwm.html Cwm is a general-purpose data processor for the semantic web... (looks like it intends to use pycrypto, if it does not already, the code is newer than the html that suggests it is moving from amkCrypto to pycrypto, same author) TechnoBot http://joi.ito.com/joiwiki/TechnoBot Joi's Technorati Jabber Alert System and Technorati Cosmos Sidebar Maker (needs pycrypto for hashing) dnd http://thayer.dartmouth.edu/~sting/sw.shtml A Python library for talking to Dartmouth Name Directory servers. -bob From bob at redivi.com Fri Oct 3 12:52:39 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 12:53:14 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <521F3AD8-F5BE-11D7-B874-000393CB1C86@tulane.edu> Message-ID: On Friday, Oct 3, 2003, at 12:26 America/New_York, Kevin Ollivier wrote: > Hi all, > > While I personally think Jack's approach is the best from a > functionality point of view, I do agree with Just's position and I > think we should not be storing any Python executable code into the > plist files, version checking or otherwise. Doing things like running > setup.py should take place within package manager, using the plist > files to determine where said file is, etc. > I think this is bad from a security perspective and like wxPython > we've seen that module conflicts could occur. > > I think the solution to both Just and Jack's problems is to have a > standard way in Python to store a version number that is NOT inside a > Python code file. PKG-INFO springs to mind. Now, it doesn't solve our > immediate problem re: dependencies but remember, we're designing > software that is not even known by most of the Python community at > this point. Once it is better known (I agree with Jack about the PEP), > and people know that writing a simple PKG-INFO file and placing it in > the root of their module will cause it to work well with > PackageManager, they will start doing this. It also means we can take > advantage of PKG-INFO even when PM didn't install the package. This would need to happen with distutils, I think this is a great idea, but I have some additions: 1 - not everything goes into a unique package, not everything is in a package at all, so the names of the PKG-INFO files would have to be mangled somehow or put into some hierarchy to make it unique 2 - we should also include installation receipts (both for source and binary installs) because we ought to if we're already modifying distutils. this would be something that is embedded in the PKG-INFO, is along side the PKG-INFO in a "receipt bundle" or something of that sort. 3 - while we're at it we should standardize a way to do binary installation of example scripts and non-in-the-code documentation -bob From bob at redivi.com Fri Oct 3 12:55:15 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 12:55:52 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <5CAA9920-F5C2-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 12:47 America/New_York, Just van Rossum wrote: > Jack Jansen wrote: > >>> I don't follow: if you're building/installing package X yourself, >>> why would you then want to use PackMan for package X also? I see it >>> pretty much as an either/or situation. >> >> Not for package X but for dependent packages! Think of the following >> scenario: you maintain package X, that is also in PackMan. Package Y >> depends on package X but you don't maintain it. With a know-it-all >> package manager you cannot install Y to use your X. > > I don't see why not: the dependencies don't need to be "hard". > >> There are now three options open to you: >> - trick the package manager to think that it installed X >> - install every package depending on X by hand >> - install two copies of X, one for your development and one >> through the package manager for use by dependent packages. > > - Install package Y, getting a dialog that goes something like this: > > Package Y depends on X version a.b.c. You've installed an > unknown version of Y. What would you like to do? > > [Cancel] [Install X and Y a.b.c] [Install X] > > In other words, it could be up to the user to decide whether to let > PackMan handle dependencies or not. > >> All of this falls under my favorite annoyance #4: things that >> get in the way of developers for no obvious reason. > > Well, lets improve PackMan then... Yes, this is exactly what I was thinking. All these gripes can be handled by the UI, and doesn't need to influence the architecture of the system so long as the system lets you override any of its guesses. >>> PackMan is for end users. A certain amount of complexity for >>> _developers_ seems pretty much unavoidable, and would be totally >>> acceptable to me. >>> >>> I strongly feel that executing arbitrary code (even from a trusted >>> source) is a big nono. >> >> Uhm... How about arbitrary setup.py scripts included with packages? > > Isn't the whole point of PackMan to _not_ have to execute any > setup.py's > to begin with? With setup.py you build a distro, PackMan does the > install without it. Am I missing something? I think Jack is thinking too much about source package installs, while you and I are focused on binary package installs? The binary ones are the real win of PackMan, and the source package installs would be icing on the cake, mostly. -bob From mwh at python.net Fri Oct 3 13:02:40 2003 From: mwh at python.net (Michael Hudson) Date: Fri Oct 3 13:01:58 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <3AAC41A1-F5C1-11D7-A43C-000A95686CD8@redivi.com> (Bob Ippolito's message of "Fri, 3 Oct 2003 12:47:09 -0400") References: <3AAC41A1-F5C1-11D7-A43C-000A95686CD8@redivi.com> Message-ID: <2m7k3mz233.fsf@starship.python.net> Bob Ippolito writes: > On Friday, Oct 3, 2003, at 12:04 America/New_York, Michael Hudson wrote: > >> There are ghastly legal issues that obstruct crypto support (there >> have been threads on python-dev about this) and there's also a code >> quality/ease of maintenence issue about pyCrypto itself (I have no >> idea about it in this regard). > > According to the homepage: > With the relaxing of US export controls for encryption software, it's > now possible to distribute cryptographic source code and export it > from the US, so now anyone in the world can download the Python > Cryptography Toolkit. OK, so that means it's legal for the authors of pyCrypto to "export" the software from the US -- that doesn't have a lot to do with whether it's legal for the person on the other end to use the software. > What are the remaining legal issues? Can you point me to any > semi-recent threads? I thought that since the laws were eased up in > the US it was pretty safe to throw around cryptography software. That only changed the situation in the US (and given where www.python.org *is* and how Python is developed... well, I don't understand it all). Here's the thread I was thinking of: http://mail.python.org/pipermail/python-dev/2003-April/034957.html Marc-Andre Lemburg's posts are the depressing ones. > Note that the intended use for PackMan isn't cryptography per se, it's > cryptographic authentication. The documents themselves won't be > encrypted, but will be signed cryptographically for authentication > purposes only. This *might* make a difference (but only if pyCrypto can be sliced up so that you can distribute a portion that can only do authentication). Given that RSA is easily (if not efficiently) implementable in Python, I share your probably opinion that this is all a pile of poo -- but I didn't write the world's laws. > As for code quality / ease of maintenance, a cursory glance of the > source code makes me think that it looks clean, commented where it > matters, and it's got unit tests that are less than trivial. [snippety] This doesn't seem to be a problem, then. Cheers, mwh -- Just put the user directories on a 486 with deadrat7.1 and turn the Octane into the afforementioned beer fridge and keep it in your office. The lusers won't notice the difference, except that you're more cheery during office hours. -- Pim van Riezen, asr From bob at redivi.com Fri Oct 3 13:23:25 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 13:24:01 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <2m7k3mz233.fsf@starship.python.net> Message-ID: <4B975AC2-F5C6-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 13:02 America/New_York, Michael Hudson wrote: > Bob Ippolito writes: > >> On Friday, Oct 3, 2003, at 12:04 America/New_York, Michael Hudson >> wrote: >> According to the homepage: >> With the relaxing of US export controls for encryption software, it's >> now possible to distribute cryptographic source code and export it >> from the US, so now anyone in the world can download the Python >> Cryptography Toolkit. > > OK, so that means it's legal for the authors of pyCrypto to "export" > the software from the US -- that doesn't have a lot to do with whether > it's legal for the person on the other end to use the software. > >> What are the remaining legal issues? Can you point me to any >> semi-recent threads? I thought that since the laws were eased up in >> the US it was pretty safe to throw around cryptography software. > > That only changed the situation in the US (and given where > www.python.org *is* and how Python is developed... well, I don't > understand it all). > > Here's the thread I was thinking of: > > http://mail.python.org/pipermail/python-dev/2003-April/034957.html > > Marc-Andre Lemburg's posts are the depressing ones. That is really depressing. Being a US citizen I don't generally think of or hear about other places having worse crypto laws than we do. Except for China, I guess, but these things are almost never involved in my normal thought processes. Ok, so now that hopes are dashed on this front, how about PackMan whines every time you use it (which you can turn off from the UI, if you are in a country where using pycrypto would be illegal and you aren't interesting in breaking any laws) until pycrypto is installed? This would be similar to how a web browser behaves when a SSL certificate is not trusted. I have memories of using Perl's CPAN, and it whining about not having a lot of internet related modules when you used it on a fresh Perl installation. One of the things it whined about was not having an md5 module for testing the authenticity of packages. -bob From kevino at tulane.edu Fri Oct 3 13:41:40 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Fri Oct 3 13:45:53 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <2m7k3mz233.fsf@starship.python.net> Message-ID: Hi all, What about making it an 'add-on' for Package Manager? I do see this as getting potentially very messy to get into Python core, if it is even possible. (And even if we could, it would restrict ways in which vendors from other countries could re-package the software - i.e. Linux vendor X in country Y may have to remove PM from their distro because of legal issues) Just make a prompt when the software is first run, saying something like: "While every effort is made to ensure that packages are legitimate and safe, some packages could contain viruses or malicious code that when run could cause harm to your computer. Please be aware that there is some risk involved, especially if you are loading Package Manager databases from non-official sources. If your country allows the import and use of cryptographic software, you may download an update to Package Manager that adds more verification controls for package authors from 'your URL here'." Or of course make the add-in show up in PackageManager itself. =) I think this is a compromise which side-steps any legal issues that might arise. Thanks, Kevin On Friday, October 3, 2003, at 10:02 AM, Michael Hudson wrote: > Bob Ippolito writes: > >> On Friday, Oct 3, 2003, at 12:04 America/New_York, Michael Hudson >> wrote: >> >>> There are ghastly legal issues that obstruct crypto support (there >>> have been threads on python-dev about this) and there's also a code >>> quality/ease of maintenence issue about pyCrypto itself (I have no >>> idea about it in this regard). >> >> According to the homepage: >> With the relaxing of US export controls for encryption software, it's >> now possible to distribute cryptographic source code and export it >> from the US, so now anyone in the world can download the Python >> Cryptography Toolkit. > > OK, so that means it's legal for the authors of pyCrypto to "export" > the software from the US -- that doesn't have a lot to do with whether > it's legal for the person on the other end to use the software. > >> What are the remaining legal issues? Can you point me to any >> semi-recent threads? I thought that since the laws were eased up in >> the US it was pretty safe to throw around cryptography software. > > That only changed the situation in the US (and given where > www.python.org *is* and how Python is developed... well, I don't > understand it all). > > Here's the thread I was thinking of: > > http://mail.python.org/pipermail/python-dev/2003-April/034957.html > > Marc-Andre Lemburg's posts are the depressing ones. > >> Note that the intended use for PackMan isn't cryptography per se, it's >> cryptographic authentication. The documents themselves won't be >> encrypted, but will be signed cryptographically for authentication >> purposes only. > > This *might* make a difference (but only if pyCrypto can be sliced up > so that you can distribute a portion that can only do authentication). > > Given that RSA is easily (if not efficiently) implementable in Python, > I share your probably opinion that this is all a pile of poo -- but I > didn't write the world's laws. > >> As for code quality / ease of maintenance, a cursory glance of the >> source code makes me think that it looks clean, commented where it >> matters, and it's got unit tests that are less than trivial. > [snippety] > > This doesn't seem to be a problem, then. > > Cheers, > mwh > > -- > Just put the user directories on a 486 with deadrat7.1 and turn the > Octane into the afforementioned beer fridge and keep it in your > office. The lusers won't notice the difference, except that you're > more cheery during office hours. -- Pim van Riezen, asr > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From just at letterror.com Fri Oct 3 13:44:42 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 14:24:28 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <5CAA9920-F5C2-11D7-A43C-000A95686CD8@redivi.com> Message-ID: Bob Ippolito wrote: > I think Jack is thinking too much about source package installs, > while you and I are focused on binary package installs? The binary > ones are the real win of PackMan, and the source package installs > would be icing on the cake, mostly. Yes. I'd even go so far as to not support source installs at all... Who needs source installs? I think it's only people who (for example) have their own private extension modules that extend Numeric. That should be a _very_ small group of people, and a rather savvy group at that: they might as well install Numeric without PackMan. Here's an issue that I'm not totally clear about: there are packages that need external frameworks, I think wxPython and Tcl/Tk are the main examples here. Are these special cases, or does PackMan need to _generally_ support installing external libraries? If the latter, what kind of consequences does that have for cross-platform support? Is that a reasonable goal/requirement at all? Just From bob at redivi.com Fri Oct 3 14:48:28 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 14:49:06 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <2D7D9590-F5D2-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 13:44 America/New_York, Just van Rossum wrote: > Bob Ippolito wrote: > >> I think Jack is thinking too much about source package installs, >> while you and I are focused on binary package installs? The binary >> ones are the real win of PackMan, and the source package installs >> would be icing on the cake, mostly. > > Yes. I'd even go so far as to not support source installs at all... It makes sense for pure python packages, because then they don't have to be packed up per-platform (not that it takes more than a few seconds for me to package something with my scripts). > Who needs source installs? I think it's only people who (for example) > have their own private extension modules that extend Numeric. That > should be a _very_ small group of people, and a rather savvy group at > that: they might as well install Numeric without PackMan. The extension modules are probably not inside Numeric itself, anyway. You're right though, some people like to use exotic compile flags and/or non-default libraries.. like Numeric+ATLAS. The ATLAS I'm using in my PackMan repository is the one embedded inside Apple's vecLib, because it was easy for me to do and should get the performance that the number cruncher's want (though, I may be wrong, I don't have any real benchmarks to throw at it). > Here's an issue that I'm not totally clear about: there are packages > that need external frameworks, I think wxPython and Tcl/Tk are the main > examples here. Are these special cases, or does PackMan need to > _generally_ support installing external libraries? If the latter, what > kind of consequences does that have for cross-platform support? Is that > a reasonable goal/requirement at all? pygame is another case. For the OS X platform I'm kind of leaning towards just making a Frameworks directory inside Python and having the required dylibs/frameworks live in there (Tcl/Tk, wxPython, SDL*, libpng, libtiff, etc). This would be excellent for bundle builder! Basically they would go in here (or the ~/Library equivalent): /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/ Contents/Frameworks And would all be linked with dylib ids of @executable_path/../Frameworks/whatever This would be extremely awesome. -bob From oussoren at cistron.nl Fri Oct 3 14:53:40 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Oct 3 14:53:45 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: On 3 okt 2003, at 19:44, Just van Rossum wrote: > Bob Ippolito wrote: > >> I think Jack is thinking too much about source package installs, >> while you and I are focused on binary package installs? The binary >> ones are the real win of PackMan, and the source package installs >> would be icing on the cake, mostly. > > Yes. I'd even go so far as to not support source installs at all... Not supporting/using source-installs would also reduce the length of the package list, which is a good thing. > > Who needs source installs? I think it's only people who (for example) > have their own private extension modules that extend Numeric. That > should be a _very_ small group of people, and a rather savvy group at > that: they might as well install Numeric without PackMan. Or write their own PackMan infrastruture for distributing their private extension modules. > > Here's an issue that I'm not totally clear about: there are packages > that need external frameworks, I think wxPython and Tcl/Tk are the main > examples here. Are these special cases, or does PackMan need to > _generally_ support installing external libraries? If the latter, what > kind of consequences does that have for cross-platform support? Is that > a reasonable goal/requirement at all? In general the python wrappers for existing C libraries need a seperate install of the wrapped library (if not included in the OS). I personally prefer to staticly the C library into the python extension (makes it easier to distribute the extension), but that is not always feasable (sp?). Ronald From kevino at tulane.edu Fri Oct 3 14:57:40 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Fri Oct 3 15:02:47 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <769D31EA-F5D3-11D7-B874-000393CB1C86@tulane.edu> On Friday, October 3, 2003, at 10:44 AM, Just van Rossum wrote: > Bob Ippolito wrote: > >> I think Jack is thinking too much about source package installs, >> while you and I are focused on binary package installs? The binary >> ones are the real win of PackMan, and the source package installs >> would be icing on the cake, mostly. > > Yes. I'd even go so far as to not support source installs at all... > > Who needs source installs? I think it's only people who (for example) > have their own private extension modules that extend Numeric. That > should be a _very_ small group of people, and a rather savvy group at > that: they might as well install Numeric without PackMan. > > Here's an issue that I'm not totally clear about: there are packages > that need external frameworks, I think wxPython and Tcl/Tk are the main > examples here. Are these special cases, or does PackMan need to > _generally_ support installing external libraries? If the latter, what > kind of consequences does that have for cross-platform support? Is that > a reasonable goal/requirement at all? I think PackMan needs to generally support installing external libraries (Python in general is great as a wrapper for C++ modules), but I think the solution to the cross-platform is to have platform specific databases, as Jack has been doing. You can still have cross-platform packages (i.e. all Python source), they just need to be added to each of the platform specific databases. The platform-specific packages can just point to a different install file on each platform. The only problem is that for some people this is doing three times the work when it's really redundant. Or, maybe a better solution is to have one database, but allow for each package to load different binary files for each platform, or to even 'block' a platform from installing it if there are incompatibilities. This would be more efficient overall, I think. I'm not sure source is particularly needed either. What I don't like is the idea that I get double the number of packages in my package list because there's a separate entry for binary and for source. Source install support would be OK with me, but only if it is unobtrusive to users who don't need it. Thanks, Kevin From gandreas at delver.com Fri Oct 3 15:08:36 2003 From: gandreas at delver.com (Glenn Andreas) Date: Fri Oct 3 15:09:27 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: Taking a step back here for a second, I think we're confusing a couple of things (at least different people seem to have different underlying assumptions/ideas/points of view here). When talking security, you need to define what it is that you are trying to secure in the first place, and what do you trust and what is beyond your control (and untrusted). It's not clear that we've done that yet... Is PackMan "trusted"? For example, are we trying to address "what if PackMan is compromised"? Because if it can be compromised, and we are assuming it was trusted in the first place, all the other layers of authentication, signatures, certificates, etc... are probably meaningless. I think the whole idea is to let the user "know" if the package that they just installed is really what they think they just installed, especially if it came from an untrusted host (e.g., I installed package Foo from Foobar.com, but want to make sure nobody hacked Foobar.com and installed an incorrect version of the Foo package), right? Certainly if we want to make sure that PackMan is trusted (and remains so), running any sort of code from Foo to get a version number would allow PackMan to become compromised. It is probably reasonable to assume that SSL is trusted (so a previously mentioned "man in the middle" attack shouldn't be possible with SSL), but is it reasonable to assume that your web-browser is trusted? If PackMan is trusted (and URL access or WebKit support it), could it just do SSL itself? If we look at PyCrypto, this would require that whatever used it be "trusted" (since otherwise something could subvert the authentication process and just fake the call to PyCrypto and return "why, yes, it is valid"). This really would require that whatever told the user that it was an authentic Foo package never run any code from Foo to get the version number. On the other hand, if PackMan were trusted (as were the MD5 modules), do a simple MD5 checksum of the package, and then getting the "official" checksum from a trusted host (python.org) with a trusted transport mechanism (SSL) and comparing them should be sufficient (though something a bit stronger than MD5 might be desirable). Just trying to look at things from a paranoid internet security mindset... -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From bob at redivi.com Fri Oct 3 15:16:53 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 15:17:31 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <25C0635C-F5D6-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 14:53 America/New_York, Ronald Oussoren wrote: > > On 3 okt 2003, at 19:44, Just van Rossum wrote: > >> Bob Ippolito wrote: >> >>> I think Jack is thinking too much about source package installs, >>> while you and I are focused on binary package installs? The binary >>> ones are the real win of PackMan, and the source package installs >>> would be icing on the cake, mostly. >> >> Yes. I'd even go so far as to not support source installs at all... > > Not supporting/using source-installs would also reduce the length of > the package list, which is a good thing. PackMan could easily suppress the multiple listings and just offer multiple flavors. The source vs. binary separation isn't inherent in the package name, it's appended based upon one of the other keys in the plist. > >> >> Who needs source installs? I think it's only people who (for example) >> have their own private extension modules that extend Numeric. That >> should be a _very_ small group of people, and a rather savvy group at >> that: they might as well install Numeric without PackMan. > Or write their own PackMan infrastruture for distributing their > private extension modules. Good point. >> >> Here's an issue that I'm not totally clear about: there are packages >> that need external frameworks, I think wxPython and Tcl/Tk are the >> main >> examples here. Are these special cases, or does PackMan need to >> _generally_ support installing external libraries? If the latter, what >> kind of consequences does that have for cross-platform support? Is >> that >> a reasonable goal/requirement at all? > > In general the python wrappers for existing C libraries need a > seperate install of the wrapped library (if not included in the OS). I > personally prefer to staticly the C library into the python extension > (makes it easier to distribute the extension), but that is not always > feasable (sp?). It's not always feasible, but that's what I typically do if possible. I dynamically link anything that is available as a framework though. -bob From just at letterror.com Fri Oct 3 15:38:56 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 15:38:34 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <769D31EA-F5D3-11D7-B874-000393CB1C86@tulane.edu> Message-ID: Kevin Ollivier wrote: > I think PackMan needs to generally support installing external > libraries (Python in general is great as a wrapper for C++ modules), As Bob and Ronald said, if feasable, linking such a lirbrary statically causes the least problems. > but I think the solution to the cross-platform is to have platform > specific databases, as Jack has been doing. You can still have > cross-platform packages (i.e. all Python source), they just need to > be added to each of the platform specific databases. The > platform-specific packages can just point to a different install file > on each platform. The only problem is that for some people this is > doing three times the work when it's really redundant. I'm not so much worried about the database part, but I do worry about whether there is a cross platform notion of what a library _is_. On OSX we have the luxury of having frameworks that can contain lots of stuff. But should packman be able to install (for example) Tcl/Tk on other unixy platforms? On Windows? I'm feeling rather pessimistic about that, so I tend to think that installing external libraries is beyond the scope of PackMan. Just From just at letterror.com Fri Oct 3 15:41:02 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 15:40:40 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <2D7D9590-F5D2-11D7-A43C-000A95686CD8@redivi.com> Message-ID: Bob Ippolito wrote: > > Yes. I'd even go so far as to not support source installs at all... > > It makes sense for pure python packages, because then they don't have > to be packed up per-platform (not that it takes more than a few > seconds for me to package something with my scripts). Sorry, I meant non-Python source. Should have said that explicitly. Python sources should of course be installed (as far as I'm concerned even by default). Just From bob at redivi.com Fri Oct 3 15:55:21 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 15:55:59 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <853AA813-F5DB-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 15:38 America/New_York, Just van Rossum wrote: > Kevin Ollivier wrote: > >> I think PackMan needs to generally support installing external >> libraries (Python in general is great as a wrapper for C++ modules), > > As Bob and Ronald said, if feasable, linking such a lirbrary statically > causes the least problems. Well, I said feasible ;) Which is correct spelling over here in the US, not sure about elsewhere >> but I think the solution to the cross-platform is to have platform >> specific databases, as Jack has been doing. You can still have >> cross-platform packages (i.e. all Python source), they just need to >> be added to each of the platform specific databases. The >> platform-specific packages can just point to a different install file >> on each platform. The only problem is that for some people this is >> doing three times the work when it's really redundant. > > I'm not so much worried about the database part, but I do worry about > whether there is a cross platform notion of what a library _is_. On OSX > we have the luxury of having frameworks that can contain lots of stuff. > But should packman be able to install (for example) Tcl/Tk on other > unixy platforms? On Windows? I'm feeling rather pessimistic about that, > so I tend to think that installing external libraries is beyond the > scope of PackMan. On Windows you can throw the DLLs somewhere near python.exe or the .pyd files (I forget which) and it will probably find them. This is solvable, and I see PackMan being a big hit for Windows users. I have a Windows machine at work and could figure this out once we're to that point, but I really only care about OS X. On OS X we can definitely put stuff wherever we need to and be able to find it. I'm already doing this with the SDL libraries, though in retrospect I want to shove them in the Python tree and include some metadata somewhere so that bundlebuilder will know that whenever it bundles pygame it should also bring over the frameworks. bundlebuilder *could* troll the mach-o header of the .so's for @executable_path/../Frameworks and do this right now without modification of the installation process. Another problem I've had with bundlebuilder is that some packages put "resource files" in their package, for example pygame includes the default .icns file and at least one .ttf that it needs for correct operation. It would be nice if pygame could tell bundlebuilder (by external metadata or directly) that it needs to have all of its files included in a plain way, not be shoved in a zip file. On Linux.. I don't know. Linux will typically already have dependencies like Tcl/Tk installed, and Linux users will probably be using something other than PackMan to install Python modules sanctioned by the OS vendor anyways (i.e. apt-get, rpm, whatever). I think that there are way too many flavors of linux to even think about where to find or put things (stuff that doesn't traditionally go in site-packages, that is) and users are more likely to have say, changed their ld.so.conf and put the module somewhere crazy than to change the search path on Windows or OS X. -bob From just at letterror.com Fri Oct 3 16:04:09 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 16:03:50 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <853AA813-F5DB-11D7-A43C-000A95686CD8@redivi.com> Message-ID: Bob Ippolito, shifting subjects: > Another problem I've had with bundlebuilder is that some packages put > "resource files" in their package, for example pygame includes the > default .icns file and at least one .ttf that it needs for correct > operation. It would be nice if pygame could tell bundlebuilder (by > external metadata or directly) that it needs to have all of its files > included in a plain way, not be shoved in a zip file. Bundlebuilder only puts .pyc data in a zip file, all other resources are included "in a plain way". However, the problem of data files belonging to Python modules/packages is much bigger than bundlebuilder, and deserves it's own PEP. BTW. here is a PEP that is immediately relevant to our (other) discussion: http://www.python.org/peps/pep-0262.html Just From bob at redivi.com Fri Oct 3 16:18:17 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 16:18:53 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: On Friday, Oct 3, 2003, at 15:08 America/New_York, Glenn Andreas wrote: > Taking a step back here for a second, I think we're confusing a couple > of things (at least different people seem to have different underlying > assumptions/ideas/points of view here). > > When talking security, you need to define what it is that you are > trying to secure in the first place, and what do you trust and what is > beyond your control (and untrusted). It's not clear that we've done > that yet... From my perspective: PackMan, or the user of PackMan, should trust the scapegoat. The scapegoat is the maintainer of a given PackMan database (plist file, currently). Currently, if you trust the PackMan database, you can trust its contents because every tarball (whether hosted at a trusted site or not) is tagged with md5. It is easy to attack this method by changing the plist file and potentially changing the contents of the tarballs. It's trivial to update the md5 hashes to look authentic. > Is PackMan "trusted"? For example, are we trying to address "what if > PackMan is compromised"? Because if it can be compromised, and we are > assuming it was trusted in the first place, all the other layers of > authentication, signatures, certificates, etc... are probably > meaningless. > > I think the whole idea is to let the user "know" if the package that > they just installed is really what they think they just installed, > especially if it came from an untrusted host (e.g., I installed > package Foo from Foobar.com, but want to make sure nobody hacked > Foobar.com and installed an incorrect version of the Foo package), > right? > > Certainly if we want to make sure that PackMan is trusted (and remains > so), running any sort of code from Foo to get a version number would > allow PackMan to become compromised. > > It is probably reasonable to assume that SSL is trusted (so a > previously mentioned "man in the middle" attack shouldn't be possible > with SSL), but is it reasonable to assume that your web-browser is > trusted? If PackMan is trusted (and URL access or WebKit support it), > could it just do SSL itself? PackMan doesn't really use a web browser at all. Besides, if their web browser was compromised then they're already screwed. Compromised users do not effect the security upstream. > If we look at PyCrypto, this would require that whatever used it be > "trusted" (since otherwise something could subvert the authentication > process and just fake the call to PyCrypto and return "why, yes, it is > valid"). This really would require that whatever told the user that > it was an authentic Foo package never run any code from Foo to get the > version number. If the user's computer is compromised with a false version of PyCrypto, they've already lost and there is nothing we can do for them. Again, compromised users don't effect security upstream. > On the other hand, if PackMan were trusted (as were the MD5 modules), > do a simple MD5 checksum of the package, and then getting the > "official" checksum from a trusted host (python.org) with a trusted > transport mechanism (SSL) and comparing them should be sufficient > (though something a bit stronger than MD5 might be desirable). An encrypted transport mechanism is not sufficient. Anyone can setup a SSL web server, not anyone can get a certificate signed by a particular CA (i.e. one of the big nasty CAs that browsers trust by default, or an official Python.org CA). There has to be a trusted public key somewhere to do anything more than hide communication from an eavesdropper. Transport encryption is looser than cryptographic authentication because presumably it's easier to compromise a server than to acquire the private key of the scapegoat (which usually means the server can be compromised, anyways). Anyways, here's what I see as a good enough solution: - PackMan ships with the URL and scapegoat public key of at least one PackMan database (for convenience) - PackMan databases are cryptographically signed for authentication purposes - User downloads a PackMan database - If user has pycrypto installed: - pycrypto verification of cryptographic signature is performed - if failed: warn user (allow them to notify scapegoat?) - else: no warning, maybe put a "padlock" somewhere - else: - warn user that the source can not be authenticated, please install pycrypto ASAP. maybe put an "obviously unlocked padlock" somewhere When downloading a package, before installation: - Database has sha-1 of the tarball already (was it md5? I don't remember.. sha-1 is the way to go these days, anyways) - Tarball gets downloaded - Compare database hash with actual hash of file: - if failed: warn user, allow them to continue anyway if they really want to (and option to notify scapegoat) - else: go ahead and install, no warnings To add new trusted databases to user's PackMan: - PackMan has a UI option to add a URL with a public key that they can copy + paste from a website (and maybe a checkbox to blindly trust without the public key) - Python.org has a SSL certificate, which the user can inspect + verify from their browser if they choose, and the python.org website will have a page so that users can copy and paste the public key and URLs from PackMan databases that Python.org trusts (its own, maybe mine? :) - This public key + URL doesn't necessarily have to come from Python.org, but the users of Python will probably trust these (since they're trusting software that they acquired from python.org already). I might be leaving something small out, but I think that the documents themselves need to be signed. The transport encryption is completely redundant and the only use for SSL would be for the certificate, because presumably a browser-trusted CA would not sell a SSL certificate to someone posing to be python.org with the same information as the real certificate (which would've been previously issued in their database). -bob From bob at redivi.com Fri Oct 3 16:23:49 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 16:24:26 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <7F7E90FA-F5DF-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 16:04 America/New_York, Just van Rossum wrote: > Bob Ippolito, shifting subjects: > >> Another problem I've had with bundlebuilder is that some packages put >> "resource files" in their package, for example pygame includes the >> default .icns file and at least one .ttf that it needs for correct >> operation. It would be nice if pygame could tell bundlebuilder (by >> external metadata or directly) that it needs to have all of its files >> included in a plain way, not be shoved in a zip file. > > Bundlebuilder only puts .pyc data in a zip file, all other resources > are > included "in a plain way". However, the problem of data files belonging > to Python modules/packages is much bigger than bundlebuilder, and > deserves it's own PEP. > > BTW. here is a PEP that is immediately relevant to our (other) > discussion: > > http://www.python.org/peps/pep-0262.html Excellent! I just scanned it. It covers all of our receipt needs and would alleviate us from doing unsafe version checking. Unfortunately the patch to distutils was never finished and it seems that it's been idle for a year. Coincidentally, the author of pycrypto wrote that PEP :) -bob From just at letterror.com Fri Oct 3 16:32:36 2003 From: just at letterror.com (Just van Rossum) Date: Fri Oct 3 16:32:13 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <7F7E90FA-F5DF-11D7-A43C-000A95686CD8@redivi.com> Message-ID: Bob Ippolito wrote: [PEP 262] > Excellent! I just scanned it. Same here, I didn't know it existed. > It covers all of our receipt needs and > would alleviate us from doing unsafe version checking. Unfortunately > the patch to distutils was never finished and it seems that it's been > idle for a year. > > Coincidentally, the author of pycrypto wrote that PEP :) He's also a (the?) driving force behind PyPI. Anyway, it turns out he has withdrawn that PEP: http://mail.python.org/pipermail/catalog-sig/2002-October/000243.html I don't agree with his arguments for withdrawing it _at_ _all_. I think it's _exactly_ what Python needs: we need a solution that works across Python installations across platforms. Maybe we should just grab that PEP and reanimate it. Just From bob at redivi.com Fri Oct 3 16:38:45 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 16:39:20 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <95336538-F5E1-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 16:32 America/New_York, Just van Rossum wrote: > Bob Ippolito wrote: > > [PEP 262] >> Excellent! I just scanned it. > > Same here, I didn't know it existed. > >> It covers all of our receipt needs and >> would alleviate us from doing unsafe version checking. Unfortunately >> the patch to distutils was never finished and it seems that it's been >> idle for a year. >> >> Coincidentally, the author of pycrypto wrote that PEP :) > > He's also a (the?) driving force behind PyPI. Anyway, it turns out he > has withdrawn that PEP: > > http://mail.python.org/pipermail/catalog-sig/2002-October/000243.html > > I don't agree with his arguments for withdrawing it _at_ _all_. I think > it's _exactly_ what Python needs: we need a solution that works across > Python installations across platforms. Maybe we should just grab that > PEP and reanimate it. Let's do it, I don't think Fink is the right way to make python tasty for OS X users, and Windows users have no Fink. I'll start looking at the distutils source this weekend to see where this needs to integrate. -bob From gandreas at delver.com Fri Oct 3 17:21:39 2003 From: gandreas at delver.com (Glenn Andreas) Date: Fri Oct 3 17:23:17 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme Message-ID: At 4:18 PM -0400 10/3/03, Bob Ippolito wrote: >On Friday, Oct 3, 2003, at 15:08 America/New_York, Glenn Andreas wrote: > >>Taking a step back here for a second, I think we're confusing a >>couple of things (at least different people seem to have different >>underlying assumptions/ideas/points of view here). >> >>When talking security, you need to define what it is that you are >>trying to secure in the first place, and what do you trust and what >>is beyond your control (and untrusted). It's not clear that we've >>done that yet... > >From my perspective: > PackMan, or the user of PackMan, should trust the scapegoat. >The scapegoat is the maintainer of a given PackMan database (plist >file, currently). > Currently, if you trust the PackMan database, you can trust >its contents because every tarball (whether hosted at a trusted site >or not) is tagged with md5. > It is easy to attack this method by changing the plist file >and potentially changing the contents of the tarballs. It's trivial >to update the md5 hashes to look authentic. So the database, contained in the plist file of PackMan, contains the MD5 (or better) values. If this file is easy to change, then so it the rest of PackMan, so nothing that the user sees when running PackMan can be trusted, correct? >>On the other hand, if PackMan were trusted (as were the MD5 >>modules), do a simple MD5 checksum of the package, and then getting >>the "official" checksum from a trusted host (python.org) with a >>trusted transport mechanism (SSL) and comparing them should be >>sufficient (though something a bit stronger than MD5 might be >>desirable). > >An encrypted transport mechanism is not sufficient. Anyone can >setup a SSL web server, not anyone can get a certificate signed by a >particular CA (i.e. one of the big nasty CAs that browsers trust by >default, or an official Python.org CA). There has to be a trusted >public key somewhere to do anything more than hide communication >from an eavesdropper. Transport encryption is looser than >cryptographic authentication because presumably it's easier to >compromise a server than to acquire the private key of the scapegoat >(which usually means the server can be compromised, anyways). Though SSL is more than just an encryption mechanism, it also provides an authentication mechanism . But I definitely agree that it is easier to compromise a server than aquire a private key. I'm clearly missing something here, because if we have the databases come from a trusted source (python.org) using SSL, we should be able to trust that they are correct when we get them (since part of the purpose of SSL is so that you know who you are talking to). If nothing changes them, and if the "user experience code" is trusted, they should reliably reflect if the packages downloaded from non-trusted hosts are valid. This may require retrieving the database from python.org every time that PackMan is run (though if anything can change the databases, it can change PackMan or whatever the "user experience code" is that verifies the intergrity), but I don't see what more is needed there. Or is part of the issue the desire to be able to obtain the database from a non-trusted host? (Which might as well then be the place where the package came from, and so the two might as well be the same). If they are packaged together, whomever signs the database could just sign the package (if you trust the signature of the database, you should be able to trust it on the package). >Anyways, here's what I see as a good enough solution: > - PackMan ships with the URL and scapegoat public key of at >least one PackMan database (for convenience) > - PackMan databases are cryptographically signed for >authentication purposes > - User downloads a PackMan database > - If user has pycrypto installed: > - pycrypto verification of cryptographic signature is performed > - if failed: warn user (allow them to notify >scapegoat?) > - else: no warning, maybe put a "padlock" somewhere > - else: > - warn user that the source can not be authenticated, >please install pycrypto ASAP. maybe put an "obviously unlocked >padlock" somewhere > >When downloading a package, before installation: > - Database has sha-1 of the tarball already (was it md5? I >don't remember.. sha-1 is the way to go these days, anyways) > - Tarball gets downloaded > - Compare database hash with actual hash of file: > - if failed: warn user, allow them to continue anyway >if they really want to (and option to notify scapegoat) > - else: go ahead and install, no warnings > >To add new trusted databases to user's PackMan: > - PackMan has a UI option to add a URL with a public key that >they can copy + paste from a website (and maybe a checkbox to >blindly trust without the public key) > - Python.org has a SSL certificate, which the user can >inspect + verify from their browser if they choose, and the >python.org website will have a page so that users can copy and paste >the public key and URLs from PackMan databases that Python.org >trusts (its own, maybe mine? :) > - This public key + URL doesn't necessarily have to come from >Python.org, but the users of Python will probably trust these (since >they're trusting software that they acquired from python.org >already). Exactly - if they trust it for the software in the first place, the ought to trust it for further updates. > >I might be leaving something small out, but I think that the >documents themselves need to be signed. I'm missing the difference between "each package is signed by trusted entity" vs "checksum of all packages is put in a single file that is then signed by trusted entity". After all, in either approach, updating it will require that trusted entity resign something. With a signed package, there is no issue of the database being out of date (or how versioning works in the database). If it is an issue of "trusted entity has to have entire sources and sign it", couldn't one just as easily have a single file with the checksum signed (and then the author of the package would send checksum it themselves and send it using some trusted mode of communication to the trusted entity, who gives them back the signed version of just that "mini-database")? Obviously, that secondary file can't be put in the same tarball/archive as the source, since that would change the checksum of the archive. > The transport encryption is completely redundant and the only use >for SSL would be for the certificate, because presumably a >browser-trusted CA would not sell a SSL certificate to someone >posing to be python.org with the same information as the real >certificate (which would've been previously issued in their >database). Right - eavesdropping on the conversation isn't an issue here, but knowing where something comes from is, and that the reason that browser-trusted CA's get the big bucks... -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From sarwat at sarwat.net Fri Oct 3 17:40:06 2003 From: sarwat at sarwat.net (Sarwat Khan) Date: Fri Oct 3 17:40:11 2003 Subject: [Pythonmac-SIG] PackageManager and Packages Message-ID: <27BCECCC-F5EA-11D7-A754-003065C9DF8C@sarwat.net> I've been trying to follow the Package Manager thread and it just keeps piling up and up :P I want to share some thoughts and a suggestion. First of all, I don't like the idea of having executable code in plists. However I'm not a fan of receipts either. I remember on FreeBSD installing XFree86, installing emacs (which can work fine without X), upgrading XFree86 (possibly by uninstalling and installing again), and then finding out that my emacs was screwed. Since X was optional the libraries were removed out from under emacs, and it was screwed. Just my $.02 there; I'd something smarter. When it comes to comparing versions, I've given up on using "1.0.1b2" and just started using integers and incrementing them. Apple's agvtool (Apple Generic Versioning) defines two version numbers for a product, the 'version' and the 'marketing version.' The version is a floating point number that is always increasing, like 85.5. The marketing version is a string like 1.0.1 b2 and is what the end-user sees. It's MUCH easier to deal with projects that use solid numbers for versions - 2 dimensional version numbers are much easier to compare than 5 dimensional ones :P The other thing is that it'd be a lot easier to uninstall packages if they weren't so messy about being installed. This might require a change to Python and how it handles stuff but honestly that's a good thing. zipimport is a great addition as it lets you specify one easily maintainable directory structure for a package, the only downside is that it has to be hard coded into a path (or a .pth I guess). But that's an example. Perhaps there's more we can do to Python's under-used import hooks to make package management easier to deal with; it's best to make the system better at accommodating the needs of a better Package Manager before we write a better Package Manager (like how it'd be great if distutils supported uninstall). Why can't an entire Python package be installed as a Mac OS X style bundle? foobar.pyndle/ Contents/ MacOS/ foobar.dylib Win32/ foobar.dll Resources/ python2.3/ site-packages/ foobar.py For now, I think you can hack together a .pth that adds enough entries together to make a bundle work. But this would make package removal much easier, although it doesn't directly solve the issue of dependancies. Perhaps Package Manager can maintain a tree based on meta-info provided with each bundle, and rebuild it if it detects it being out of sync. {sarwat khan : http://sarwat.net} From bob at redivi.com Fri Oct 3 18:03:52 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 18:04:27 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <798308EC-F5ED-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 17:21 America/New_York, Glenn Andreas wrote: > At 4:18 PM -0400 10/3/03, Bob Ippolito wrote: >> On Friday, Oct 3, 2003, at 15:08 America/New_York, Glenn Andreas >> wrote: >> >>> Taking a step back here for a second, I think we're confusing a >>> couple of things (at least different people seem to have different >>> underlying assumptions/ideas/points of view here). >>> >>> When talking security, you need to define what it is that you are >>> trying to secure in the first place, and what do you trust and what >>> is beyond your control (and untrusted). It's not clear that we've >>> done that yet... >> >> From my perspective: >> PackMan, or the user of PackMan, should trust the scapegoat. The >> scapegoat is the maintainer of a given PackMan database (plist file, >> currently). >> Currently, if you trust the PackMan database, you can trust its >> contents because every tarball (whether hosted at a trusted site or >> not) is tagged with md5. >> It is easy to attack this method by changing the plist file and >> potentially changing the contents of the tarballs. It's trivial to >> update the md5 hashes to look authentic. > > So the database, contained in the plist file of PackMan, contains the > MD5 (or better) values. > > If this file is easy to change, then so it the rest of PackMan, so > nothing that the user sees when running PackMan can be trusted, > correct? > >>> On the other hand, if PackMan were trusted (as were the MD5 >>> modules), do a simple MD5 checksum of the package, and then getting >>> the "official" checksum from a trusted host (python.org) with a >>> trusted transport mechanism (SSL) and comparing them should be >>> sufficient (though something a bit stronger than MD5 might be >>> desirable). >> >> An encrypted transport mechanism is not sufficient. Anyone can setup >> a SSL web server, not anyone can get a certificate signed by a >> particular CA (i.e. one of the big nasty CAs that browsers trust by >> default, or an official Python.org CA). There has to be a trusted >> public key somewhere to do anything more than hide communication from >> an eavesdropper. Transport encryption is looser than cryptographic >> authentication because presumably it's easier to compromise a server >> than to acquire the private key of the scapegoat (which usually means >> the server can be compromised, anyways). > > Though SSL is more than just an encryption mechanism, it also provides > an authentication mechanism . But I definitely agree that it is > easier to compromise a server than aquire a private key. Yes but AFAIK you can't get to this information without M2Crypto or some other OpenSSL wrapper. The SSL certificate authentication mechanism, in my opinion, should be for the user's eyes to trust when they look at a page containing the public key and URL of a particular PackMan database. > I'm clearly missing something here, because if we have the databases > come from a trusted source (python.org) using SSL, we should be able > to trust that they are correct when we get them (since part of the > purpose of SSL is so that you know who you are talking to). If > nothing changes them, and if the "user experience code" is trusted, > they should reliably reflect if the packages downloaded from > non-trusted hosts are valid. But using a cryptographic signature on the PackMan database is a little more secure, and is much easier and less expensive than SSL. I think the SSL trusted site should be used to acquire public keys and locations for PackMan databases that should be trusted. After the public key is acquired safely, the user can download the PackMan database files from untrusted communication channels because they can verify whether the person who signed it is who you think it is. > This may require retrieving the database from python.org every time > that PackMan is run (though if anything can change the databases, it > can change PackMan or whatever the "user experience code" is that > verifies the intergrity), but I don't see what more is needed there. The database has to be retrieved every time PackMan is run to check for new packages. > Or is part of the issue the desire to be able to obtain the database > from a non-trusted host? (Which might as well then be the place where > the package came from, and so the two might as well be the same). If > they are packaged together, whomever signs the database could just > sign the package (if you trust the signature of the database, you > should be able to trust it on the package). We don't need to sign packages because we are signing the database, and the database has hashes. But yes, it would be very nice to obtain PackMan databases through insecure means and verify their authenticity. We should definitely do this. >> Anyways, here's what I see as a good enough solution: >> - PackMan ships with the URL and scapegoat public key of at least >> one PackMan database (for convenience) >> - PackMan databases are cryptographically signed for authentication >> purposes >> - User downloads a PackMan database >> - If user has pycrypto installed: >> - pycrypto verification of cryptographic signature is performed >> - if failed: warn user (allow them to notify scapegoat?) >> - else: no warning, maybe put a "padlock" somewhere >> - else: >> - warn user that the source can not be authenticated, please >> install pycrypto ASAP. maybe put an "obviously unlocked padlock" >> somewhere >> >> When downloading a package, before installation: >> - Database has sha-1 of the tarball already (was it md5? I don't >> remember.. sha-1 is the way to go these days, anyways) >> - Tarball gets downloaded >> - Compare database hash with actual hash of file: >> - if failed: warn user, allow them to continue anyway if they >> really want to (and option to notify scapegoat) >> - else: go ahead and install, no warnings >> >> To add new trusted databases to user's PackMan: >> - PackMan has a UI option to add a URL with a public key that they >> can copy + paste from a website (and maybe a checkbox to blindly >> trust without the public key) >> - Python.org has a SSL certificate, which the user can inspect + >> verify from their browser if they choose, and the python.org website >> will have a page so that users can copy and paste the public key and >> URLs from PackMan databases that Python.org trusts (its own, maybe >> mine? :) >> - This public key + URL doesn't necessarily have to come from >> Python.org, but the users of Python will probably trust these (since >> they're trusting software that they acquired from python.org >> already). > > Exactly - if they trust it for the software in the first place, the > ought to trust it for further updates. Yes but a PackMan database doesn't have to come from python.org, therefore it is not trusted by PackMan by default (even if it is through SSL). Only the official PackMan database, and perhaps any databases it explicitly trusts, are to be trusted by the PackMan client. For example, the PackMan website ( http://www.python.org/packman/ ) currently links to my PackMan database. In the future, the PackMan website would also have the public key for my database, such that once you retrieve my database you will be able to verify that I was the last one to modify its contents because I will have signed it. >> I might be leaving something small out, but I think that the >> documents themselves need to be signed. > > I'm missing the difference between "each package is signed by trusted > entity" vs "checksum of all packages is put in a single file that is > then signed by trusted entity". After all, in either approach, > updating it will require that trusted entity resign something. With a > signed package, there is no issue of the database being out of date > (or how versioning works in the database). If it is an issue of > "trusted entity has to have entire sources and sign it", couldn't one > just as easily have a single file with the checksum signed (and then > the author of the package would send checksum it themselves and send > it using some trusted mode of communication to the trusted entity, who > gives them back the signed version of just that "mini-database")? > Obviously, that secondary file can't be put in the same > tarball/archive as the source, since that would change the checksum of > the archive. Each *PackMan database* is signed by a trusted entity. Not all PackMan databases will be hosted at python.org, such as mine. Not all PackMan databases, whether on python.org or not, will be maintained by the same scapegoat either. There is no need to sign tarballs, as they can be verified by hash from the PackMan database. Package authors are not directly involved in this process. It's up to a "platform scapegoat" to maintain the binary distributions for each package. However that happens is not part of the PackMan system, we're not trying to get too complicated. >> The transport encryption is completely redundant and the only use >> for SSL would be for the certificate, because presumably a >> browser-trusted CA would not sell a SSL certificate to someone posing >> to be python.org with the same information as the real certificate >> (which would've been previously issued in their database). > > Right - eavesdropping on the conversation isn't an issue here, but > knowing where something comes from is, and that the reason that > browser-trusted CA's get the big bucks... Exactly. We only need one host to be trusted by the big boys, which will host public keys for the rest of them (the ones that are trusted to some degree by the python.org team). Trusting anything else should be up to the user's explicit discretion. I have a SSL certificate and server that is trusted by the big boys at https://pythonmac.org/ which I will host for as long as is needed (and then some, probably) :) Does Camino or Safari even let you read a SSL certificate? I distinctly remember being able to look at them with some browser at some time.. I can't figure out how to do it with either of these though. -bob From Jack.Jansen at cwi.nl Fri Oct 3 18:23:29 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 18:23:35 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <7F7E90FA-F5DF-11D7-A43C-000A95686CD8@redivi.com> References: <7F7E90FA-F5DF-11D7-A43C-000A95686CD8@redivi.com> Message-ID: <3723C74C-F5F0-11D7-86EF-000A27B19B96@cwi.nl> Of the 44(!) message PackMan waiting for me I've marked quite a few, and I'll get to replying to them at some time. But this one I'll reply to now, because it's important: On 3-okt-03, at 22:23, Bob Ippolito wrote: >> BTW. here is a PEP that is immediately relevant to our (other) >> discussion: >> >> http://www.python.org/peps/pep-0262.html > > Excellent! I just scanned it. It covers all of our receipt needs and > would alleviate us from doing unsafe version checking. Unfortunately > the patch to distutils was never finished and it seems that it's been > idle for a year. Fully agreed. I'd never heard of this PEP (even though I try to scan them occasionally), but it reconciles the points Just and I are opposed on. At least, it seems to do so at first glance, and it's still a draft, so we can get it into shape. All the more reason to start writing that PEP, and get more people in this discussion. I'm going to be very busy this week, trying to make an October 1 deadline (I love deadlines, I love the "whooooossshhh"ing sound they make when the pass, to misquote Douglas Adams), but I promise I'm going to put some time into it in the near future. I have a set of goals (and, more important, non-goals) in my head, and while I think I've mentioned all of them at some point I should try and present them in a more formal way to help shape the discussion. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 3 18:32:45 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 18:32:49 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: <828CE050-F5F1-11D7-86EF-000A27B19B96@cwi.nl> On 3-okt-03, at 23:21, Glenn Andreas wrote: > I'm clearly missing something here, because if we have the databases > come from a trusted source (python.org) using SSL, This is what you're missing: we cannot use SSL to transfer the database, because core Python has no SSL support. We expect the end user to trust a number of entities (because a hole in any of these would make the whole excercise pointless): 1. Apple, anyone with admin access to their machine, and all the other parties involved with local infrastructure. 2. The Python maintainers. 3. The installed Python distribution, including PackMan (either because it was Apple-provided, or because people checked the signature on the website download page). 4. The scapegoat. 5. Anyone the scapegoat trusts wrt. web distribution (their webhoster, the key-signing Trusted Third Party). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 3 18:43:57 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 18:44:00 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <07B8F4AA-F5B9-11D7-A43C-000A95686CD8@redivi.com> References: <07B8F4AA-F5B9-11D7-A43C-000A95686CD8@redivi.com> Message-ID: <12B48F96-F5F3-11D7-86EF-000A27B19B96@cwi.nl> On 3-okt-03, at 17:48, Bob Ippolito wrote: >> On its own, no. But combined with another algorithm that allows a >> trusted source to >> advertise (in a secure way) the md5sums of all relevant documents >> s/he ever created >> it does. If you really want I could write it down in >> Needham-Burrows-Abadi formalism >> (or whatever the people involved were again). >> >> Or, to elaborate on the steps again (taking you as an example): >> >> 1. You change your pimp database. >> 2. You take the md5sum of it, let's say it's 12345 (but with many >> more digits:-) >> 3. You create a secure document >> https://undefined.org/pimp/integrity.html >> saying "I, Bob Ippolito, created this packman database. Use at >> your own risk". AAAARGH! Here I made a crucial mistake: the URL is specific to this instance of your database, in other words, it is . >> 4. You don't ever delete this file, even when updating the database. >> 5. You now upload the database to >> . >> 6. My mum downloads your database through packman, and presses the >> "integrity check" >> button. >> 6. She is presented with a dialog >> You can now use your internet browser to test that this database was >> actually created by %s. Check that the padlock is closed (if it is >> open there is a very good chance that this is a forged database). If >> you get a message about an untrusted certificate this is also a sign >> of a forgery. Finally check that the URL starts with https: and >> points >> to the website of %s. >> >> Note that all these checks only mean that this database has not been >> tampered >> with since it was created. Whether you trust %s remains wholly up >> to you. > > 1. You orchestrate some sort of man in the middle attack. > 2. You take the existing integrity.html document > 3. You create a new evil packman plist file > 4. You add the md5sum of your evil packman plist file and append it > to integrity.html > 5. You upload the database and integrity.html to your evil man in the > middle server > > The padlock thing helps some, but it only works for people with > trusted SSL certificates, which are typically not cheap, and I > wouldn't expect everyone maintaining a distribution to have one. Having a trusted SSL certificate is tantamount to the whole idea! Untrusted SSL certificates are as good as locking your door and leaving the key under a stone beside it.... But note that not everyone maintaining a pimp database would need one, it would just mean a little more work. If I had an SSL key, and you and I could communicate securely (lets say PGP-based) you would put a URL of the form in your database, send me the md5 sum whenever you change it, and I would create the 12345.html file with the contents "I, Jack Jansen, am convinced Bob Ippolito created this database". -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 3 18:52:41 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 18:52:44 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: <4B28811F-F5F4-11D7-86EF-000A27B19B96@cwi.nl> On 3-okt-03, at 18:47, Just van Rossum wrote: >>> I don't follow: if you're building/installing package X yourself, >>> why would you then want to use PackMan for package X also? I see it >>> pretty much as an either/or situation. >> >> Not for package X but for dependent packages! Think of the following >> scenario: you maintain package X, that is also in PackMan. Package Y >> depends on package X but you don't maintain it. With a know-it-all >> package manager you cannot install Y to use your X. > > I don't see why not: the dependencies don't need to be "hard". > >> There are now three options open to you: >> - trick the package manager to think that it installed X >> - install every package depending on X by hand >> - install two copies of X, one for your development and one >> through the package manager for use by dependent packages. > > - Install package Y, getting a dialog that goes something like this: > > Package Y depends on X version a.b.c. You've installed an > unknown version of Y. What would you like to do? > > [Cancel] [Install X and Y a.b.c] [Install X] Good point (except that you say "unknown version of Y" where you mean X:-). This, in combination with a standardised way to get version information a la AMK's PEP would do the trick for most cases. I'd still like the option of executable code, but then it would be the exception, so we could do something similar to what Apple's Installer does on Panther: if the package wants to execute code *before* you've said "yes" to install it it pops up a warning dialog saying "This installer wants to run code on your machine to do some pre-install tests. Is that okay with you?". -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Fri Oct 3 18:57:02 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 18:57:39 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <828CE050-F5F1-11D7-86EF-000A27B19B96@cwi.nl> Message-ID: On Friday, Oct 3, 2003, at 18:32 America/New_York, Jack Jansen wrote: > > On 3-okt-03, at 23:21, Glenn Andreas wrote: >> I'm clearly missing something here, because if we have the databases >> come from a trusted source (python.org) using SSL, > > This is what you're missing: we cannot use SSL to transfer the > database, because > core Python has no SSL support. > > We expect the end user to trust a number of entities (because a hole > in any > of these would make the whole excercise pointless): > 1. Apple, anyone with admin access to their machine, and all the other > parties involved with local infrastructure. > 2. The Python maintainers. > 3. The installed Python distribution, including PackMan (either because > it was Apple-provided, or because people checked the signature on > the > website download page). > 4. The scapegoat. > 5. Anyone the scapegoat trusts wrt. web distribution (their webhoster, > the > key-signing Trusted Third Party). When using PGP or something like it to sign the package list, #5 can be eliminated, because the scapegoat is the key signing entity and the web hoster does not have the private key. -bob From Jack.Jansen at cwi.nl Fri Oct 3 19:00:45 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 19:00:50 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <5CAA9920-F5C2-11D7-A43C-000A95686CD8@redivi.com> References: <5CAA9920-F5C2-11D7-A43C-000A95686CD8@redivi.com> Message-ID: <6C0C01EE-F5F5-11D7-86EF-000A27B19B96@cwi.nl> On 3-okt-03, at 18:55, Bob Ippolito wrote: >>>> PackMan is for end users. A certain amount of complexity for >>>> _developers_ seems pretty much unavoidable, and would be totally >>>> acceptable to me. >>>> >>>> I strongly feel that executing arbitrary code (even from a trusted >>>> source) is a big nono. >>> >>> Uhm... How about arbitrary setup.py scripts included with packages? >> >> Isn't the whole point of PackMan to _not_ have to execute any >> setup.py's >> to begin with? With setup.py you build a distro, PackMan does the >> install without it. Am I missing something? > > I think Jack is thinking too much about source package installs, while > you and I are focused on binary package installs? The binary ones are > the real win of PackMan, and the source package installs would be > icing on the cake, mostly. Agreed, but the source installs are a vital part of my plan for MacPython world domination: I want to break down the barriers between point-and-click installs and full-source installs. While breaking them down may be too much of a pie-in-the-sky goal I definitely want to make the transition easier. With all current open source the transition between being a mere user of a package and a full developer is a large leap. I would like to make that barrier lower. But, all that said, binary installs are indeed by far the most important. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 3 19:06:04 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 3 19:06:08 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: <29F9D8C8-F5F6-11D7-86EF-000A27B19B96@cwi.nl> On 3-okt-03, at 19:41, Kevin Ollivier wrote: > Hi all, > > What about making it an 'add-on' for Package Manager? I do see this as > getting potentially very messy to get into Python core, if it is even > possible. (And even if we could, it would restrict ways in which > vendors from other countries could re-package the software - i.e. > Linux vendor X in country Y may have to remove PM from their distro > because of legal issues) Just make a prompt when the software is first > run, saying something like: "While every effort is made to ensure that > packages are legitimate and safe, some packages could contain viruses > or malicious code that when run could cause harm to your computer. > Please be aware that there is some risk involved, especially if you > are loading Package Manager databases from non-official sources. If > your country allows the import and use of cryptographic software, you > may download an update to Package Manager that adds more verification > controls for package authors from 'your URL here'." Or of course make > the add-in show up in PackageManager itself. =) I think this is a > compromise which side-steps any legal issues that might arise. Very good idea! So we construct PackMan in such a way that it first tries a secure HTTP connection, and if that fails due to SSL support not being available in Python it shows the message. But: I don't think the SSL support should be downloadable through PackMan, PackMan should point you to an https: URL to load it in a trusted way. After it's securely transferred to your machine PackMan can take over again. -- 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 gandreas at delver.com Fri Oct 3 19:06:17 2003 From: gandreas at delver.com (Glenn Andreas) Date: Fri Oct 3 19:07:04 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <828CE050-F5F1-11D7-86EF-000A27B19B96@cwi.nl> References: <828CE050-F5F1-11D7-86EF-000A27B19B96@cwi.nl> Message-ID: At 12:32 AM +0200 10/4/03, Jack Jansen wrote: >On 3-okt-03, at 23:21, Glenn Andreas wrote: >>I'm clearly missing something here, because if we have the >>databases come from a trusted source (python.org) using SSL, > >This is what you're missing: we cannot use SSL to transfer the >database, because >core Python has no SSL support. Ah (light bulb comes on). But neither is there support for digital signature authentication in core Python... Still, at least it is easier to do the signature authentication outside/independant of PackMan than to download a database over SSL. -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From bob at redivi.com Fri Oct 3 19:06:43 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 19:07:17 2003 Subject: [Pythonmac-SIG] PackageManager and Packages In-Reply-To: <27BCECCC-F5EA-11D7-A754-003065C9DF8C@sarwat.net> Message-ID: <412939DA-F5F6-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 17:40 America/New_York, Sarwat Khan wrote: > I've been trying to follow the Package Manager thread and it just > keeps piling up and up :P I want to share some thoughts and a > suggestion. Yeah, it's definitely the fastest moving thread I've ever seen in pythonmac-sig! > First of all, I don't like the idea of having executable code in > plists. However I'm not a fan of receipts either. I remember on > FreeBSD installing XFree86, installing emacs (which can work fine > without X), upgrading XFree86 (possibly by uninstalling and installing > again), and then finding out that my emacs was screwed. Since X was > optional the libraries were removed out from under emacs, and it was > screwed. Just my $.02 there; I'd something smarter. I don't think this is going to be an issue for us. The scapegoat's job is to make sure that the dependencies listed for each package are accurate, and we can warn the user when an upgrade takes place.. for example: "Packages X 2.0 and Y 0.4 have not yet been certified to work with package Z 1.1, are you sure that you would like to upgrade Z at this time?" As for executable code in the plist, Jack had a good point about pre/post install checks and warnings, as with the OS X installer. I don't expect the need to use this feature, but I suppose we could keep it so long as it is not required for operation and adequate warnings are given to the user of the PackMan client. > When it comes to comparing versions, I've given up on using "1.0.1b2" > and just started using integers and incrementing them. Apple's agvtool > (Apple Generic Versioning) defines two version numbers for a product, > the 'version' and the 'marketing version.' The version is a floating > point number that is always increasing, like 85.5. The marketing > version is a string like 1.0.1 b2 and is what the end-user sees. It's > MUCH easier to deal with projects that use solid numbers for versions > - 2 dimensional version numbers are much easier to compare than 5 > dimensional ones :P That's an excellent idea. This depends on people using distutils in a smarter way though :) > The other thing is that it'd be a lot easier to uninstall packages if > they weren't so messy about being installed. This might require a > change to Python and how it handles stuff but honestly that's a good > thing. zipimport is a great addition as it lets you specify one easily > maintainable directory structure for a package, the only downside is > that it has to be hard coded into a path (or a .pth I guess). But > that's an example. Perhaps there's more we can do to Python's > under-used import hooks to make package management easier to deal > with; it's best to make the system better at accommodating the needs > of a better Package Manager before we write a better Package Manager > (like how it'd be great if distutils supported uninstall). > > Why can't an entire Python package be installed as a Mac OS X style > bundle? > > foobar.pyndle/ > Contents/ > MacOS/ > foobar.dylib > > Win32/ > > foobar.dll > Resources/ > python2.3/ > site-packages/ > foobar.py > > For now, I think you can hack together a .pth that adds enough entries > together to make a bundle work. But this would make package removal > much easier, although it doesn't directly solve the issue of > dependancies. Perhaps Package Manager can maintain a tree based on > meta-info provided with each bundle, and rebuild it if it detects it > being out of sync. I like this proposal but I think it may be too much of a change for it to get accepted into distutils. -bob From gandreas at delver.com Fri Oct 3 19:11:50 2003 From: gandreas at delver.com (Glenn Andreas) Date: Fri Oct 3 19:13:06 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme Message-ID: >On Friday, Oct 3, 2003, at 17:21 America/New_York, Glenn Andreas wrote: >>Though SSL is more than just an encryption mechanism, it also >>provides an authentication mechanism . But I definitely agree that >>it is easier to compromise a server than aquire a private key. > >Yes but AFAIK you can't get to this information without M2Crypto or >some other OpenSSL wrapper. The SSL certificate authentication >mechanism, in my opinion, should be for the user's eyes to trust >when they look at a page containing the public key and URL of a >particular PackMan database. And I'm guessing using OS-X specific libraries is out... > >>I'm clearly missing something here, because if we have the >>databases come from a trusted source (python.org) using SSL, we >>should be able to trust that they are correct when we get them >>(since part of the purpose of SSL is so that you know who you are >>talking to). If nothing changes them, and if the "user experience >>code" is trusted, they should reliably reflect if the packages >>downloaded from non-trusted hosts are valid. > >But using a cryptographic signature on the PackMan database is a >little more secure, and is much easier and less expensive than SSL. >I think the SSL trusted site should be used to acquire public keys >and locations for PackMan databases that should be trusted. After >the public key is acquired safely, the user can download the PackMan >database files from untrusted communication channels because they >can verify whether the person who signed it is who you think it is. So there is _one_ (or possibly _a few_) public key, obtained from a known & trusted location (python.org) via a trusted transport (SSL), so we know that those signatures are valid according to "python.org" as being able to sign PackMan databased. > >>This may require retrieving the database from python.org every time >>that PackMan is run (though if anything can change the databases, >>it can change PackMan or whatever the "user experience code" is >>that verifies the intergrity), but I don't see what more is needed >>there. > >The database has to be retrieved every time PackMan is run to check >for new packages. And it (or possibly "they") can be obtained from different untrusted locations (e.g. scapegoat.com), correct? The packages themselves then come from third party untrusted locations (e.g. mythirdpartypackage.com). Do hash on package, compare hash to data base entry (where the database itself has been authenticated by signature, which would have to be done outside of PackMan since core Python has no digital signature support, just like it has no SSL support), and if we match, everything is golden. So if the master public keys on python.org are subverted (either by recovery of private keys, or hacking of python.org to replace the key), then all bets are off, or if PackMan at some point is subverted (or a bunch of other trusted points on the user machine), similar issues abound. But if PackMan & friends are good to start with, and the packages themselves aren't subversive (or introduce other holes), everything seems pretty reasonable. The only other obvious vulnerability would be faking the hash (which is doable with weaker hashes like simple CRCs). There are "out of band" issues - for example, EvilHacker manages to compromise mythirdpartypackage.com, makes a new trojan version that package, sends mail to scapegoat ("Hey dude, got a new version, here's the hash") and then scapegoat updates the database with the now tainted version of the package, and the user thinks everything is dandy until they use ThirdPartyPackage which turns their machine into a toaster, but those are policy level issues. There is also the chance for some sort of "buffer overrun" (or other PackMan vulnerability) which would be used to subvert PackMan when downloading ThirdPartyPackage from the (now compromised by EvilHacker) mythirdpartypackage.com, or some other "man in the middle" scheme to activate the buffer overrun bug (during either the retrieval of the database or the package). The use of digital signatures could be avoided, but at the cost of keeping a hash of the valid databases on python.org, retrieved via SSL whenever the databases are updated. (And then that hash validates the database, just like the hash in the database validates the package), but then a new database require retrieving a new set of hashes which require a new SSL transaction which can't currently be done in the core Python (and we assume that OS-X specific libraries aren't usable). All in all, it seems that PackMan itself is the biggest vulnerability with this scheme (i.e, what happens with invalid databases are fed to it, or invalid packages, or are there other ways to get PackMan to execute untrusted code), since the rest of the system relies on existing mechanism that are "well travelled". I'm still not sure what mechanism would be used to verify the signature (without something like PyCrypto), but those are "details". -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From bob at redivi.com Fri Oct 3 19:19:43 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 19:20:17 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <12B48F96-F5F3-11D7-86EF-000A27B19B96@cwi.nl> Message-ID: <11F088E1-F5F8-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 18:43 America/New_York, Jack Jansen wrote: > > On 3-okt-03, at 17:48, Bob Ippolito wrote: > >>> On its own, no. But combined with another algorithm that allows a >>> trusted source to >>> advertise (in a secure way) the md5sums of all relevant documents >>> s/he ever created >>> it does. If you really want I could write it down in >>> Needham-Burrows-Abadi formalism >>> (or whatever the people involved were again). >>> >>> Or, to elaborate on the steps again (taking you as an example): >>> >>> 1. You change your pimp database. >>> 2. You take the md5sum of it, let's say it's 12345 (but with many >>> more digits:-) >>> 3. You create a secure document >>> https://undefined.org/pimp/integrity.html >>> saying "I, Bob Ippolito, created this packman database. Use at >>> your own risk". > > AAAARGH! Here I made a crucial mistake: the URL is specific to this > instance of your > database, in other words, it is > . > >>> 4. You don't ever delete this file, even when updating the database. >>> 5. You now upload the database to >>> . >>> 6. My mum downloads your database through packman, and presses the >>> "integrity check" >>> button. >>> 6. She is presented with a dialog >>> You can now use your internet browser to test that this database was >>> actually created by %s. Check that the padlock is closed (if it is >>> open there is a very good chance that this is a forged database). If >>> you get a message about an untrusted certificate this is also a sign >>> of a forgery. Finally check that the URL starts with https: and >>> points >>> to the website of %s. >>> >>> Note that all these checks only mean that this database has not >>> been tampered >>> with since it was created. Whether you trust %s remains wholly up >>> to you. >> >> 1. You orchestrate some sort of man in the middle attack. >> 2. You take the existing integrity.html document >> 3. You create a new evil packman plist file >> 4. You add the md5sum of your evil packman plist file and append it >> to integrity.html >> 5. You upload the database and integrity.html to your evil man in >> the middle server >> >> The padlock thing helps some, but it only works for people with >> trusted SSL certificates, which are typically not cheap, and I >> wouldn't expect everyone maintaining a distribution to have one. > > Having a trusted SSL certificate is tantamount to the whole idea! > Untrusted > SSL certificates are as good as locking your door and leaving the key > under a stone beside it.... > > But note that not everyone maintaining a pimp database would need one, > it would just mean a little more work. If I had an SSL key, and you and > I could communicate securely (lets say PGP-based) you would put a URL > of the form in your > database, send me the md5 sum whenever you change it, and I would > create > the 12345.html file with the contents "I, Jack Jansen, am convinced Bob > Ippolito created this database". I personally think this method is problematic as a sole source of trust because it makes it harder for a PackMan database to get updated. Unless of course scapegoat A and scapegoat B have an automated cryptographic method to exchange "integrity tokens". I much prefer the "I, Bob Ippolito, trust that Jack Jansen's public key is ....." method, but it could also say "... and his most recent database has a sha-1 hash of: " which would accommodate both of us. The third party integrity check is still a useful method to have because (a) In the case of a compromise, it provides a process for a key to be revoked (if enough people say "I, Some Trusted Person, no longer trust that Bob Ippolito's public key is ...") (b) it sort of skirts around the crypto import dependency for the unfortunate who are in countries that restrict its use. Assuming these people are allowed to use hashing algorithms :) I really like the public key idea and I think that we can implement it for most Python users hassle free, but I'm now convinced that we should also have Jack's third party hashes. -bob From bob at redivi.com Fri Oct 3 19:37:12 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 19:37:47 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <83A3BBA3-F5FA-11D7-A43C-000A95686CD8@redivi.com> On Friday, Oct 3, 2003, at 19:11 America/New_York, Glenn Andreas wrote: >> On Friday, Oct 3, 2003, at 17:21 America/New_York, Glenn Andreas >> wrote: >>> Though SSL is more than just an encryption mechanism, it also >>> provides an authentication mechanism . But I definitely agree that >>> it is easier to compromise a server than aquire a private key. >> >> Yes but AFAIK you can't get to this information without M2Crypto or >> some other OpenSSL wrapper. The SSL certificate authentication >> mechanism, in my opinion, should be for the user's eyes to trust when >> they look at a page containing the public key and URL of a particular >> PackMan database. > > And I'm guessing using OS-X specific libraries is out... Well I think that PackMan should be allowed to use Win32 specific libraries on Windows if available, OpenSSL on OS X and other posix systems if available, or command line utilities. But it has to know how to get along insecurely. The problem is distributing a version of Python contains crypto is not always feasible. I suppose we could distribute a module that dynamically links to one of these libraries if it exists (in a clean way), otherwise it does not import and PackMan would fall back to something else or get along insecurely. >>> I'm clearly missing something here, because if we have the databases >>> come from a trusted source (python.org) using SSL, we should be able >>> to trust that they are correct when we get them (since part of the >>> purpose of SSL is so that you know who you are talking to). If >>> nothing changes them, and if the "user experience code" is trusted, >>> they should reliably reflect if the packages downloaded from >>> non-trusted hosts are valid. >> >> But using a cryptographic signature on the PackMan database is a >> little more secure, and is much easier and less expensive than SSL. I >> think the SSL trusted site should be used to acquire public keys and >> locations for PackMan databases that should be trusted. After the >> public key is acquired safely, the user can download the PackMan >> database files from untrusted communication channels because they can >> verify whether the person who signed it is who you think it is. > > So there is _one_ (or possibly _a few_) public key, obtained from a > known & trusted location (python.org) via a trusted transport (SSL), > so we know that those signatures are valid according to "python.org" > as being able to sign PackMan databased. Yup, or the user could add a public key to their PackMan "trust ring" if they choose to, however they obtained it. >>> This may require retrieving the database from python.org every time >>> that PackMan is run (though if anything can change the databases, it >>> can change PackMan or whatever the "user experience code" is that >>> verifies the intergrity), but I don't see what more is needed there. >> >> The database has to be retrieved every time PackMan is run to check >> for new packages. > > And it (or possibly "they") can be obtained from different untrusted > locations (e.g. scapegoat.com), correct? The packages themselves then > come from third party untrusted locations (e.g. > mythirdpartypackage.com). Do hash on package, compare hash to data > base entry (where the database itself has been authenticated by > signature, which would have to be done outside of PackMan since core > Python has no digital signature support, just like it has no SSL > support), and if we match, everything is golden. Exactly, thanks for explaining this in a clear way. > So if the master public keys on python.org are subverted (either by > recovery of private keys, or hacking of python.org to replace the > key), then all bets are off, or if PackMan at some point is subverted > (or a bunch of other trusted points on the user machine), similar > issues abound. But if PackMan & friends are good to start with, and > the packages themselves aren't subversive (or introduce other holes), > everything seems pretty reasonable. The only other obvious > vulnerability would be faking the hash (which is doable with weaker > hashes like simple CRCs). Well, the first time the user downloads the trusted key list from python.org it should remember it and pop up a big nasty warning if it changes. Recovery of private keys is just something we have to hope does not happen. Replacing the key on python.org is only a problem for users who are using PackMan for the first time post-replace. Also, a replaced key would probably not match a more secure scapegoat.com's key. Although, if they can hack python.org and replace the key then they could add arbitrary databases. > There are "out of band" issues - for example, EvilHacker manages to > compromise mythirdpartypackage.com, makes a new trojan version that > package, sends mail to scapegoat ("Hey dude, got a new version, here's > the hash") and then scapegoat updates the database with the now > tainted version of the package, and the user thinks everything is > dandy until they use ThirdPartyPackage which turns their machine into > a toaster, but those are policy level issues. Yeah, we have to trust scapegoats. On a lighter note, I think that some of our computers would work perfectly well as a toaster, if only there was a slot for bread. > There is also the chance for some sort of "buffer overrun" (or other > PackMan vulnerability) which would be used to subvert PackMan when > downloading ThirdPartyPackage from the (now compromised by EvilHacker) > mythirdpartypackage.com, or some other "man in the middle" scheme to > activate the buffer overrun bug (during either the retrieval of the > database or the package). We are using Python.. this would almost have to be a kernel level exploit, I've never seen nor heard of any python socket over or underruns. If there happen to be any at some point, I seriously doubt that there's anything we could've done in anticipation (other than audit the code). > The use of digital signatures could be avoided, but at the cost of > keeping a hash of the valid databases on python.org, retrieved via SSL > whenever the databases are updated. (And then that hash validates the > database, just like the hash in the database validates the package), > but then a new database require retrieving a new set of hashes which > require a new SSL transaction which can't currently be done in the > core Python (and we assume that OS-X specific libraries aren't > usable). This is Jack's suggestion. I guess we should support both, and use whatever makes sense for the capabilities of the system. If SSL is not available, it will ask the user to use a SSL capable web browser and paste the appropriate hash into an input box in the PackMan UI. Or of course, just ignore the potential security risk, because they may not be allowed to use SSL or may not have any SSL capable software at their disposal. > All in all, it seems that PackMan itself is the biggest vulnerability > with this scheme (i.e, what happens with invalid databases are fed to > it, or invalid packages, or are there other ways to get PackMan to > execute untrusted code), since the rest of the system relies on > existing mechanism that are "well travelled". > > I'm still not sure what mechanism would be used to verify the > signature (without something like PyCrypto), but those are "details". We do have lots of options (pycrypto, Microsoft APIs, OpenSSL, OS X APIs, potentially there will be command line utilities available) however there is always the chance that zero of the options are available on some unlucky person's computer. We just have to keep that in mind, I guess. -bob From bob at redivi.com Fri Oct 3 20:49:49 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 3 20:50:24 2003 Subject: [Pythonmac-SIG] Starting a PEP for PIMP Message-ID: Now that we've had a lot of useful discussion about Package Manager, it's about time to start writing a collection of PEPs. Here's some notes: Extending PEP-241 ( http://www.python.org/peps/pep-0241.html ) --------------------------- As per Sarwat's suggestion for canonical version numbers, we do have somewhat of a solution that I was unaware of: the StrictVersion and LooseVersion classes in distutils.version. LooseVersion will pretty much allow us to compare arbitrary 1.0a2 vs 1.0b2 version numbers reliably. If they don't compare reliably or can not be parsed by LooseVersion, the package author is not following spec and should be smacked around :) We need more metadata, here's what we need: Metadata-Version: needs to be bumped above 1.0 Package-Name: We need something that tells us what the actual name of the package or module is! Right now the name is arbitrary and doesn't need to relate to the name of the module in Python. Depends: (optional) A list of other packages, by Package-Name (which must by definition follow python module naming guidelines), that this package depends on. Extends: (optional) A list of other packages, by Package-Name, that enhance the functionality of this package (i.e. Crypto extends twisted by enabling Conch (the SSH2 client/server)) I believe this will be sufficient. However it may be nice to be able to specify C or C++ libraries that a package wraps or depends on (but does not include). Ideas? One thing, related to Package-name, is that we should completely deprecate the practice where you can install a whole bunch of python modules flat in site-packages. If you have more than one file that belongs in site-packages, it should go in a separate folder and be referenced by a pth file. There should be a 1:1 relationship between the number of modules+packages in your site-packages, and the number of modules+packages that you installed. Discussion of PEP-243 ( http://www.python.org/peps/pep-0243.html ) ------------------------------- PEP-243 proposes a central module repository system for source modules. We should say that the PIMP system will supplant this because (a) it could take advantage of a central module repository if available and (b) it's easier these days to host open source projects anyways (a la sourceforge). Speaking of sourceforge, we should have special integration for sourceforge downloads in PIMP (let the user choose a preferred mirror, display to the use who is sponsoring their download). It's possible that the scapegoat may choose to come to an arrangement with the package maintainers such that package maintainers will host the scapegoat-built binary packages on their site to make it more economical for scapegoats. Embrace and Extend PEP-262 ( http://www.python.org/peps/pep-0262.html ) ----------------------------------------- PEP-262 is the holy grail for PIMP, it allows us to develop a sane way to do package management, especially uninstallation. For our platform, PEP-262 has one inherent deficiency: INSTALLDB (the location for receipts) is a fixed location and not a search path. I propose that we leverage sys.path in our quest to locate the installation receipt database, that way we can find /System/Library/... /Library/... /Network/Library/... ~/Library/... or whatever is appropriate for that particular installation of Python. The installation database could have a file name that would be unacceptable as a python package name, such as INSTALL-DB, this way it could not possibly be confused with an actual package. I think that we can deprecate the REQUIRES and PROVIDES files by adding Depends, Package-Name, and Extends to PKG-INFO. I don't think that the "PROVIDES" file makes a whole lot of sense, unless the strings used in provides means it corresponds to a definitive module interface. There is not currently any sort of registry or PEP for this kind of thing, so it's probably not at all useful. Since we have upgraded PEP-241, we should also upgrade the Package class in PEP-262 to include the new metadata. Our PEP ------------ This is where we describe exactly what PIMP is and does. I'll start on that sometime later this weekend, and probably write it to the pythonmac.org wiki so that anyone with ideas can jump in. I'd like some feedback on what I have here so far before I start, though. -bob From just at letterror.com Sat Oct 4 03:00:57 2003 From: just at letterror.com (Just van Rossum) Date: Sat Oct 4 03:00:44 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <828CE050-F5F1-11D7-86EF-000A27B19B96@cwi.nl> Message-ID: Jack Jansen wrote: > This is what you're missing: we cannot use SSL to transfer the > database, because core Python has no SSL support. What about: http://www.python.org/doc/current/lib/module-socket.html#l2h-2422 socket.ssl() seems available on OSX. Or is it the fact that that it doesn't do certificate verification the big showstopper? Just From just at letterror.com Sat Oct 4 03:08:37 2003 From: just at letterror.com (Just van Rossum) Date: Sat Oct 4 03:08:14 2003 Subject: [Pythonmac-SIG] Starting a PEP for PIMP In-Reply-To: Message-ID: Bob Ippolito wrote: > PEP-262 is the holy grail for PIMP, it allows us to develop a sane way > to do package management, especially uninstallation. (I thought it was the general consensus that "pimp" as a name was deprecated, and that "Package Manager" was the new name, PackMan for short. Or do you consider pimp something different from PackMan?) > For our platform, PEP-262 has one inherent deficiency: INSTALLDB (the > location for receipts) is a fixed location and not a search path. I > propose that we leverage sys.path in our quest to locate the > installation receipt database, that way we can find > /System/Library/... > /Library/... /Network/Library/... ~/Library/... or whatever is > appropriate for that particular installation of Python. The > installation database could have a file name that would be > unacceptable as a python package name, such as INSTALL-DB, this way > it could not possibly be confused with an actual package. Hm, having a search path for the database suggests that there can be more than one. Is that your intention? Just From just at letterror.com Sat Oct 4 04:27:14 2003 From: just at letterror.com (Just van Rossum) Date: Sat Oct 4 04:26:54 2003 Subject: [Pythonmac-SIG] Starting a PEP for PIMP In-Reply-To: Message-ID: Just van Rossum wrote: > Hm, having a search path for the database suggests that there can be > more than one. Is that your intention? Thinking about this a wee bit more: more than one database is indeed _needed_ if we support installing in different places, depending on the user. One database per location. Eg. stuff installed in site-packages should be registered in the database in site-packages. Just From ndrake at polya.net Sat Oct 4 11:01:32 2003 From: ndrake at polya.net (Nate Drake) Date: Sat Oct 4 11:01:37 2003 Subject: [Pythonmac-SIG] osascript question Message-ID: <10413.209.195.167.55.1065279692.squirrel@www.polya.net> Hi, I'm new to Python and really new to Applescript. Could someone explain while the following script works ok from the command-line but not when run as a CGI? #!/usr/local/bin/python import os print "Content-Type: text/html\n\n" applescript = 'osascript -e \"do shell script \\\"echo This is a shell script\\\" \"' #print applescript the_command = os.popen(applescript) print "Output of 'do shell script'

" for line in the_command.readlines(): print("Line: " + line) print "End of output" When it is run on the command-line the output of the "osascript" command is printed in the for loop ok. When run as a CGI only the print statements right before and right after the for loop print. Does it have something to do with the fact that do shell script starts a new sh process? Is there a way to get something like this to work? In the long run I'm looking to use osascript and do shell script to get itunes track data in my python CGI. I tried using PythonIDE's "Generate OSA Suite..." command on iTunes but I get this: ASKING FOR aete DICTIONARY IN '/Applications/iTunes.app' Launched /Applications/iTunes.app Unpack returned empty value: [] So, that is why I'm not using the Python OSA stuff. Thanks a lot! Nate From bob at redivi.com Sat Oct 4 15:58:58 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 4 15:59:37 2003 Subject: [Pythonmac-SIG] Starting a PEP for PIMP In-Reply-To: Message-ID: <3165EC40-F6A5-11D7-AAA7-000A95686CD8@redivi.com> On Saturday, Oct 4, 2003, at 03:08 America/New_York, Just van Rossum wrote: > Bob Ippolito wrote: > >> PEP-262 is the holy grail for PIMP, it allows us to develop a sane way >> to do package management, especially uninstallation. > > (I thought it was the general consensus that "pimp" as a name was > deprecated, and that "Package Manager" was the new name, PackMan for > short. Or do you consider pimp something different from PackMan?) Oh, sorry. PackMan it is. -bob From drewmccormack at mac.com Sun Oct 5 03:42:06 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Sun Oct 5 03:42:16 2003 Subject: [Pythonmac-SIG] [ANN] New PPlot release with python/ruby wrapping Message-ID: <6B3A08AF-F707-11D7-8E82-00039363BC02@mac.com> A new release of the plotting framework PPlot has just been made (http://pplot.sourceforge.net/). This release includes python and ruby wrapping code, so that you can create plots with scripts embedded in your applications. There is a simple Cocoa application example given that allows you to display plots by entering python scripts into a text view. PPlot is a lightweight framework written in C++, and designed to be platform and API independent. You can build using Qt or Cocoa for the Mac. The Cocoa version uses Cocoa native drawing, so you get all the benefits of Quartz. You can use C++ or Obj-C++ to create plots, of course, but if you use a bridge like PyObjC (http://pyobjc.sourceforge.net/) or RubyCocoa (http://www.imasy.or.jp/~hisa/mac/rubycocoa/index.en.html), you can now program directly in Python or Ruby in your Cocoa apps. Even without these bridges, you can run python and ruby scripts to generate plots from within a Cocoa app. Download: https://sourceforge.net/project/ showfiles.php?group_id=66291&release_id=188905 Drew McCormack ---------------------------------- Dr. Drew McCormack Trade Strategist (www.trade-strategist.com) Stock Market strategy design platform for Mac OS X. From seanh at unforgettable.com Sun Oct 5 13:20:10 2003 From: seanh at unforgettable.com (Sean Hummel) Date: Sun Oct 5 14:59:00 2003 Subject: [Pythonmac-SIG] MacOSX posixpath to macpath? Message-ID: <2C24C428-F758-11D7-BB61-000393CD4D12@unforgettable.com> I probably just didn't look around enough, however I have a problem with which I need help. The problem is that using Stuffit Installer Maker on OS X (even the supposed OSX version of this program,) with the Generated OSA wrappers, I need to pass string paths to SIM. However SIM does not accept the standard posix paths (i.e. '/Users/sean/instalerfile",) that the newest version of MacPython for OSX uses. (In this case 2.3) Instead it will only accept the old standard macintosh paths ("MacHD:Users:sean:installerfile") Is there a conversion function for handling this? I need one because of course these paths are going to be based off of different settings per developer. I of course would prefer not use paths, but that is the way that SIM works. From Martina at Oefelein.de Sun Oct 5 15:12:07 2003 From: Martina at Oefelein.de (Martina Oefelein) Date: Sun Oct 5 15:12:09 2003 Subject: [Pythonmac-SIG] osascript question In-Reply-To: <10413.209.195.167.55.1065279692.squirrel@www.polya.net> Message-ID: Hi Nate, > I'm new to Python and really new to Applescript. Could someone explain > while the following script works ok from the command-line but not when > run > as a CGI? ... > the_command = os.popen(applescript) the cgi runs under the user account of the web server, which probably doesn't have access to user-interface stuff (not to speak of iTunes.app running in your account). BTW, You might want to use popen3 to read stderr, in order to read possible error messages. > ASKING FOR aete DICTIONARY IN '/Applications/iTunes.app' > Launched /Applications/iTunes.app > Unpack returned empty value: [] you might try Bob's aeve module instead. Also search in the archives of this mailing lists for tips regarding iTunes. ciao Martina From Larry.A.Meyn at nasa.gov Sun Oct 5 15:38:37 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Sun Oct 5 15:38:56 2003 Subject: Fwd: [Pythonmac-SIG] MacOSX posixpath to macpath? Message-ID: <838313DA-F76B-11D7-90DB-000A95A06CF6@nasa.gov> Begin forwarded message: On Sunday, October 5, 2003, at 10:20 AM, Sean Hummel wrote: > I probably just didn't look around enough, however I have a problem > with which I need help. > > The problem is that using Stuffit Installer Maker on OS X (even the > supposed OSX version of this program,) with the Generated OSA > wrappers, I need to pass string paths to SIM. However SIM does not > accept the standard posix paths (i.e. '/Users/sean/instalerfile",) > that the newest version of MacPython for OSX uses. (In this case 2.3) > Instead it will only accept the old standard macintosh paths > ("MacHD:Users:sean:installerfile") > > Is there a conversion function for handling this? I need one because > of course these paths are going to be based off of different settings > per developer. > > I of course would prefer not use paths, but that is the way that SIM > works. > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > I had this problem in mid-August (see subject "[Pythonmac-SIG] AppleEvents in MacPython 2.3?") and received a lot of help. For known posix paths try the following functions: def makeOS9path(path): if path[0] != '/': return ":".join(path.split('/')) else: rootdisk = Carbon.File.FSRef('/').FSGetCatalogInfo(0)[2].as_tuple()[2] return rootdisk + ":".join(path.split('/')) def makeOS9abspath(path): """Returns an ":" delimited, OS 9 style absolute path. """ import Carbon.File, os.path abspath = os.path.abspath(path) rootdisk = Carbon.File.FSRef('/').FSGetCatalogInfo(0)[2].as_tuple()[2] abspath = rootdisk + ":".join(abspath.split('/')) if os.path.isdir(path): return abspath + ":" else: return abspath For new paths, Jack Jasen offered the following snippet, note the potential problem with names longer than 31 characters and names with ":" in them. I would suggest that we all ask application developers to start supporting posix paths in their scriptable applications. if os.path.exists(path): return makeOS9abspath(path) head, tail = os.path.split(path) head = makeOS9abspath(head) if len(tail) > 31 or ':' in tail: raise IOError, "Come up with good error message here" return macpath.join(head, unicode(tail, 'utf8').encode('mac-roman')) - Larry Meyn Aerospace Operations Modeling Office M/S 210-10 Phone: (650) 604-5038 NASA Ames Research Center Fax: (650) 604-0222 Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov E-Fax: (425) 944-5526 sent via e-mail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2802 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031005/6b8df4cf/attachment.bin From bob at redivi.com Sun Oct 5 15:48:55 2003 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 5 15:49:30 2003 Subject: [Pythonmac-SIG] osascript question In-Reply-To: Message-ID: On Sunday, Oct 5, 2003, at 15:12 America/New_York, Martina Oefelein wrote: > Hi Nate, > >> I'm new to Python and really new to Applescript. Could someone >> explain >> while the following script works ok from the command-line but not >> when run >> as a CGI? > ... >> the_command = os.popen(applescript) > > the cgi runs under the user account of the web server, which probably > doesn't have access to user-interface stuff (not to speak of > iTunes.app running in your account). > > BTW, You might want to use popen3 to read stderr, in order to read > possible error messages. What you should do is write a daemon (either via unix sockets or TCP) that runs under the user account and is a gateway between your CGI and iTunes. >> ASKING FOR aete DICTIONARY IN '/Applications/iTunes.app' >> Launched /Applications/iTunes.app >> Unpack returned empty value: [] > > you might try Bob's aeve module instead. Also search in the archives > of this mailing lists for tips regarding iTunes. Feel free to ask me questions about it or tell me if it breaks, I'll help you or fix it. -bob From p.thibault at bigfoot.com Sun Oct 5 16:50:26 2003 From: p.thibault at bigfoot.com (Pierre Thibault) Date: Sun Oct 5 16:55:18 2003 Subject: [Pythonmac-SIG] Unicode with the Mac Python IDE Message-ID: <8BFAA0C6-F775-11D7-A86F-000393C54658@bigfoot.com> Hello, I am have Python program that in UTF-8. When running from the IDE the accented characters are not showing well. But from the console everything is fine. In the beginning of my program I have the special comment to tell the parser that the file is in UTF-8: # -*- coding: utf-8 -*- But it is still not working with the IDE. What can I do? Is there a fix planned for this IDE bug? Regards. --------------------- Pierre From Jack.Jansen at cwi.nl Sun Oct 5 17:34:20 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sun Oct 5 17:34:28 2003 Subject: [Pythonmac-SIG] Unicode with the Mac Python IDE In-Reply-To: <8BFAA0C6-F775-11D7-A86F-000393C54658@bigfoot.com> Message-ID: On zondag, okt 5, 2003, at 22:50 Europe/Amsterdam, Pierre Thibault wrote: > Hello, > > I am have Python program that in UTF-8. When running from the IDE the > accented characters are not showing well. But from the console > everything is fine. In the beginning of my program I have the special > comment to tell the parser that the file is in UTF-8: > > # -*- coding: utf-8 -*- > > But it is still not working with the IDE. What can I do? Is there a > fix planned for this IDE bug? The IDE expects an old-style 8 bit character set. The current implementation of the IDE is at the end of its lifecycle, so don't expect a fix that works with the current codebase. But a new IDE will definitely be forthcoming, and it will definitely be unicode-based internally. -- - 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 p.thibault at bigfoot.com Sun Oct 5 18:40:27 2003 From: p.thibault at bigfoot.com (Pierre Thibault) Date: Sun Oct 5 18:40:31 2003 Subject: [Pythonmac-SIG] Unicode with the Mac Python IDE In-Reply-To: Message-ID: Le Dimanche, 5 octo 2003, ? 17:34 America/Montreal, Jack Jansen a ?crit : > The IDE expects an old-style 8 bit character set. The current > implementation > of the IDE is at the end of its lifecycle, so don't expect a fix that > works > with the current codebase. But a new IDE will definitely be > forthcoming, and > it will definitely be unicode-based internally. > Who is working on the new IDE and when this will be available? I would like to have more information on this project if possible. Regards. --------------------- Pierre From nate.drake at evoxis.com Sun Oct 5 19:48:31 2003 From: nate.drake at evoxis.com (Nate Drake) Date: Mon Oct 6 04:59:00 2003 Subject: [Pythonmac-SIG] osascript question In-Reply-To: References: Message-ID: <200310051948.31905.nate.drake@evoxis.com> On Sunday 05 October 2003 03:12 pm, Martina Oefelein wrote: > > the cgi runs under the user account of the web server, which probably > doesn't have access to user-interface stuff (not to speak of iTunes.app > running in your account). > > BTW, You might want to use popen3 to read stderr, in order to read > possible error messages. You are right! I used popen3 to get stderr. The web server user account does have access to the Window Server. Thanks for the tips. Nate From mwh at python.net Mon Oct 6 05:57:42 2003 From: mwh at python.net (Michael Hudson) Date: Mon Oct 6 05:56:54 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <4B975AC2-F5C6-11D7-A43C-000A95686CD8@redivi.com> (Bob Ippolito's message of "Fri, 3 Oct 2003 13:23:25 -0400") References: <4B975AC2-F5C6-11D7-A43C-000A95686CD8@redivi.com> Message-ID: <2mu16my9gp.fsf@starship.python.net> Bob Ippolito writes: [silly crypto laws] > That is really depressing. Being a US citizen I don't generally think > of or hear about other places having worse crypto laws than we do. > Except for China, I guess, but these things are almost never involved > in my normal thought processes. > > Ok, so now that hopes are dashed on this front, how about PackMan > whines every time you use it (which you can turn off from the UI, if > you are in a country where using pycrypto would be illegal and you > aren't interesting in breaking any laws) until pycrypto is installed? > This would be similar to how a web browser behaves when a SSL > certificate is not trusted. This sounds like a good idea. Perhaps the Python installer should already know the md5 of the pyCrypto download... > I have memories of using Perl's CPAN, and it whining about not having > a lot of internet related modules when you used it on a fresh Perl > installation. One of the things it whined about was not having an md5 > module for testing the authenticity of packages. Heh. My understanding is that hash functions are OK pretty much everywhere (though there's probably somewhere they're not...). Cheers, mwh -- It *is*, however, rather juvenile, in contravention of the Trades Descriptions Act, and will lead eventually to the Dragon of Unhappiness flying up your bottom. -- Peter Ellis, ucam.chat From bob at redivi.com Mon Oct 6 22:13:58 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 6 22:14:33 2003 Subject: [Pythonmac-SIG] Starting a PEP for PIMP In-Reply-To: Message-ID: On Friday, Oct 3, 2003, at 20:49 America/New_York, Bob Ippolito wrote: > Now that we've had a lot of useful discussion about Package Manager, > it's about time to start writing a collection of PEPs. Here's some > notes: I've collected these notes on the pythonmac.org wiki at http://pythonmac.org/wiki/NewPackageManager I've also added some quick notes on what PackMan should do and what the GUI should do covering most of what was said on the list, and some ideas of my own. Feel free to edit the wiki and add your own ideas or revise what's there, or just continue discussion here. After some more discussion/feedback (maybe a week, or two?) we can start writing the PEP and work on patches to distutils + PackMan. -bob From bob at redivi.com Tue Oct 7 14:45:22 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 7 14:45:58 2003 Subject: [Pythonmac-SIG] MacPython representation at PyConDC 2004? Message-ID: <683EEB77-F8F6-11D7-AAA7-000A95686CD8@redivi.com> PyCon DC 2004 is coming up next March ( http://www.python.org/pycon/dc2004/ ). Is anyone planning on giving any Mac-specific talks? I'd like to do one, but I haven't picked a topic yet and don't want to write a proposal for a talk that someone else is already planning to do :) Some of the potential topics I'm thinking of: * Package Manager (assuming we have the PEP written, perhaps we could arrange a sprint to work on it) * PyObjC (With a focus on application development in Cocoa) * Quicktime (Contingent on the QuickTime wrapper being fixed up a bit) * Apple Events * Porting software to OS X (Where did Apple think different, how to plan for it, what you can take advantage of, SystemStarter, etc.) * General Overview (run through which modules works which don't on OS X, emphasis on modules available only on OS X) * CoreAudio and Python (assuming someone gets around to writing wrappers and such, it would be fun to play with!) Who else here is thinking about going? -bob From s.jol at jol-tech.net Wed Oct 8 00:57:48 2003 From: s.jol at jol-tech.net (=?ISO-8859-1?Q?St=E9phane_Jolicoeur-Fidelia?=) Date: Wed Oct 8 00:57:54 2003 Subject: [Pythonmac-SIG] PyObj-c question ... In-Reply-To: Message-ID: Hi, I have a quick question about pyobjc: I am trying to build examples from a Cocoa programming book with pyobjc(i installed the latest version and am working from Project builder). I created a document based application and then proceeded to create MyDocument.h and MyDocument.m . My question is if I actually implement some methods in pure ObjC will the MyDocument.py be able to see them and be able to use them as is like any object method ? or will I just create useless files in my project? (or maybe i should ask how do i create a python object that is callable from objc? (I have seen mention of building partial Cocoa-Python apps,) Which would mean having MyDocument.h and .m import say MyPython.py as a lib or object ). Dazed and Confused NB: thanks for any help From Jack.Jansen at cwi.nl Wed Oct 8 04:24:23 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 8 04:23:41 2003 Subject: [Pythonmac-SIG] PyObj-c question ... In-Reply-To: Message-ID: On Wednesday, October 8, 2003, at 06:57 AM, St?phane Jolicoeur-Fidelia wrote: > Hi, > I have a quick question about pyobjc: I am trying to build examples > from a Cocoa programming book with pyobjc(i installed the latest > version and am working from Project builder). I created a document > based application and then proceeded to create MyDocument.h and > MyDocument.m . My question is if I actually implement some methods in > pure ObjC will the MyDocument.py be able to see them and be able to > use them as is like any object method ? or will I just create useless > files in my project? (or maybe i should ask how do i create a python > object that is callable from objc? (I have seen mention of building > partial Cocoa-Python apps,) Which would mean having MyDocument.h and > .m import say MyPython.py as a lib or object ). The quick answer is that you should do the PyObjC tutorials. This bit specifically, how the AutoBaseClass stuff connects all your classes through the NIB (or actually, how the NIB does it with help of AutoBaseClass) is explained in the first tutorial, which is Apple's CurrencyConverter but in Python. The tutorials are in the Doc subdirectory of the PyObjC distribution. -- 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 oussoren at cistron.nl Wed Oct 8 05:22:55 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 8 05:23:03 2003 Subject: [Pythonmac-SIG] PyObj-c question ... In-Reply-To: References: Message-ID: On 8 okt 2003, at 6:57, St?phane Jolicoeur-Fidelia wrote: > Hi, > I have a quick question about pyobjc: I am trying to build examples > from a Cocoa programming book with pyobjc(i installed the latest > version and am working from Project builder). I created a document > based application and then proceeded to create MyDocument.h and > MyDocument.m . My question is if I actually implement some methods in > pure ObjC will the MyDocument.py be able to see them and be able to > use them as is like any object method ? or will I just create useless > files in my project? (or maybe i should ask how do i create a python > object that is callable from objc? (I have seen mention of building > partial Cocoa-Python apps,) Which would mean having MyDocument.h and > .m import say MyPython.py as a lib or object ). > > Dazed and Confused I don't fully understand what your trying to do, but the most direct answer is 'no you cannot implement some methods of a class in python and others in Objective-C'. Why do you want to do that in the first place? If you really want to include pure ObjC classes in your project you can use the Cocoa-Python-ObjC template. Calling python methods from ObjC is easy enough if you use the right naming convention on the python side: Python: def myMethodWithArg_andArg_(self, arg1, arg2): print arg1, arg2 return 44 Objective-C: id result, arg1, arg2; result = [obj myMethodWithArg:arg1 andArg:arg2]; But as I wrote before: try to convert the entire example to Python, that makes your live much easier. And read the tutorials. Ronald From Jack.Jansen at cwi.nl Wed Oct 8 06:37:57 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 8 06:37:31 2003 Subject: [Pythonmac-SIG] PyObj-c question ... In-Reply-To: Message-ID: <7B7AB48A-F97B-11D7-BBD5-0030655234CE@cwi.nl> On Wednesday, October 8, 2003, at 11:22 AM, Ronald Oussoren wrote: > I don't fully understand what your trying to do, but the most direct > answer is 'no you cannot implement some methods of a class in python > and others in Objective-C'. But you can create a baseclass in one language and subclass that in the other, and tie them together through the NIB file, to get a very similar effect, can't you? -- 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 oussoren at cistron.nl Wed Oct 8 06:46:52 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 8 06:47:00 2003 Subject: [Pythonmac-SIG] PyObj-c question ... In-Reply-To: <7B7AB48A-F97B-11D7-BBD5-0030655234CE@cwi.nl> References: <7B7AB48A-F97B-11D7-BBD5-0030655234CE@cwi.nl> Message-ID: On 8 okt 2003, at 12:37, Jack Jansen wrote: > > On Wednesday, October 8, 2003, at 11:22 AM, Ronald Oussoren wrote: >> I don't fully understand what your trying to do, but the most direct >> answer is 'no you cannot implement some methods of a class in python >> and others in Objective-C'. > > But you can create a baseclass in one language and subclass that in > the other, and tie them together through the NIB file, to get a very > similar effect, can't you? Of course, that's no problem. However, IMHO you should have a very good reason to write methods in ObjC (like "I have loads of existing code that I want to reuse" or "Python isn't fast enough for this method"). Ronald From kim.branson at csiro.au Wed Oct 8 08:39:59 2003 From: kim.branson at csiro.au (Kim Branson) Date: Wed Oct 8 08:38:27 2003 Subject: [Pythonmac-SIG] python module module installation In-Reply-To: Message-ID: <878F1244-F98C-11D7-929D-000A9579AE94@csiro.au> Hi all, i'm new to python, and in the process of turning alot of perl into python...its scientific code and the fact that only i understand it ( given time to remember) and i have some new students has lead to the decision to convert to python. I tend to run this on a linux cluster but i want to do the dev work on my powerbook. I've got the mac python build 2.3, and python 2.2 (fink install or sys?) as well. i managed to get numeric python from the package manager and pulled down the scientific python modules is there any issue in using the mac python port of python2.3 vs the fink install? i assume there will be no differences assuming all modules i use are present on my target nodes. doing python2.3 setup.py install seemed to put it in the right place. ( even though its not in the package tree) Theres some stats stuff i'd like. except all i have are 3 files that are stats.py , io.py and pstat.py. Where should they go, can i put them in the same place? in the top level or do they need a sub directory to go in ? sorry for the dumb question... cheers Kim > _______________________________________________ > Pythonmac-SIG maillist? -? Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1361 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031008/60c42e55/attachment.bin From Benjamin.Schollnick at usa.xerox.com Wed Oct 8 14:04:03 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Wed Oct 8 14:04:15 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme Message-ID: <51B62EFFBC83D6118ADA00096BB030A107CADBB7@usamcms7.mc.usa.xerox.com> > I'm not so much worried about the database part, but I do worry about > whether there is a cross platform notion of what a library > _is_. On OSX > we have the luxury of having frameworks that can contain lots > of stuff. > But should packman be able to install (for example) Tcl/Tk on other > unixy platforms? On Windows? I'm feeling rather pessimistic > about that, > so I tend to think that installing external libraries is beyond the > scope of PackMan. I'm in the process of slowing catching up.... So apologies in advance, if someone has already suggested this. But I think that the point above, is being addressed wrongly... Yes, we want Packman to eventually be cross platform.... But, we are interested in the macintosh version. We're "experts" in the macintosh world. Abstract the darn thing. Make the abstraction model, OOP, and let the Unix Gurus inherit and replace the MACOSX specific code, and replace it with Unix Specific code. Sure, we should talk with the Unix coders, and the Windows coders, and ensure that there is a proper level of abstraction.... But, that's what the PEP is for... I realize I haven't caught up with the PEP discussion a couple days later, and hopefully someone has made this suggestion... But... - Benjamin From Benjamin.Schollnick at usa.xerox.com Wed Oct 8 14:17:52 2003 From: Benjamin.Schollnick at usa.xerox.com (Schollnick, Benjamin) Date: Wed Oct 8 14:18:07 2003 Subject: [Slight OT] RE: [Pythonmac-SIG] Package Manager idea, adding a UR L scheme Message-ID: <51B62EFFBC83D6118ADA00096BB030A107CADBB8@usamcms7.mc.usa.xerox.com> > I'd still like the option of executable code, but then it would be the > exception, so we could do something similar to what Apple's Installer > does > on Panther: if the package wants to execute code *before* you've said > "yes" > to install it it pops up a warning dialog saying "This > installer wants > to > run code on your machine to do some pre-install tests. Is that okay > with you?". Sorry... Slightly off topic.... But I ran into this today, while installing the new versions of ICal & Isync.... And it was a little suprising, but nice to see that warning! This is a feature that should be added, and should be *ENSURED* is available on all the OSes assuming this does become Cross Platform... Not having this "warning", is a large security issue... Which is half the problem with Windows! - Benjamin From rswerdlow at transpose.com Wed Oct 8 15:16:47 2003 From: rswerdlow at transpose.com (Bob Swerdlow) Date: Wed Oct 8 15:17:02 2003 Subject: [Pythonmac-SIG] Do I need to check array type code for byteswap()? Message-ID: <01ae01c38dd0$bbf58690$046fa8c0@RSWERDLOW800> We've got a cross-platform application written in python, using PyObjC and Cocoa on Mac OS X and PythonCard and wxPython on Windows. We use array.array to format some of the stuff that we save in files, and so need to use array.byteswap() to massage the data so we can read it. In the documentation at http://python.org/doc/current/lib/module-array.html, it states that byteswap is only supported for "values which are 1, 2, 4, or 8 bytes in size," yet all of the types listed in the table at the top of the page ARE one of those sizes. Is this a "future compatibility" issue or something? Do I need to check that the type code is one of those listed or can I assume that byteswap() is going to work since all of the types are permitted? Thanks, Bob From kevin at macosx.com Wed Oct 8 15:17:20 2003 From: kevin at macosx.com (kevin) Date: Wed Oct 8 15:17:28 2003 Subject: [Pythonmac-SIG] CoreAudio and Python In-Reply-To: Message-ID: <0A1ACC5F-F9C4-11D7-8EC4-003065555ABC@macosx.com> > * CoreAudio and Python (assuming someone gets around to writing > wrappers and such, it would be fun to play with!) My mouth is watering. i can't wait to see what will be possible with this. Core Audio is very promising. Coupled with Python this could be more than just fun, but incredibly useful for us mac/python music geeks. -kp-- From amk at amk.ca Wed Oct 8 15:37:09 2003 From: amk at amk.ca (amk@amk.ca) Date: Wed Oct 8 15:37:14 2003 Subject: [Pythonmac-SIG] Package manager notes Message-ID: <20031008193709.GB29078@rogue.amk.ca> Bob Ippolito let me know about the package manager discussion. I'm still reading through the past thread. Some quick notes: * I'm happy to revive PEP 262 for Python 2.4. My laptop died recently, and the required switch to a new machine that didn't have Quixote + mxBase + RDFlib + PyXML installed reminded me of why an installer would be useful. If we built Python packages for every platform, we wouldn't need a Python-specific database, but no one is building these packages, so getting all those packages installed is a pain. * This might be a good time to work on a package database; there are various other things that could be fixed in Distutils, and maybe it's time for a Distutils 2.0. * Regarding version comparisons: distutils.version has LooseVersion and StrictVersion classes that parse and compare version numbers. See the module's docstrings for details. * Note that PyCrypto doesn't help with verifying SSL server certificates; these are two different levels, and complicated tasks like ASN.1 parsing separate them. We could either fix the socket module to support server certificate verification, or we could use bits of PyCrypto to check signatures on a file. It would be possible to include a signature-only algorithm such as DSA in Python, subject to Guido's veto, but that's a non-trivial amount of packaging work, though, because it would need infrastructure for generating prime numbers, etc. --amk From jwblist at olympus.net Wed Oct 8 15:44:05 2003 From: jwblist at olympus.net (John W. Baxter) Date: Wed Oct 8 15:44:22 2003 Subject: [Pythonmac-SIG] Starting a PEP for PIMP In-Reply-To: <3165EC40-F6A5-11D7-AAA7-000A95686CD8@redivi.com> Message-ID: On 10/4/2003 12:58, "Bob Ippolito" wrote: > Oh, sorry. PackMan it is. I have the funny feeling there's a trade mark problem there. --John From Jack.Jansen at cwi.nl Wed Oct 8 17:14:52 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 8 17:14:58 2003 Subject: [Pythonmac-SIG] Do I need to check array type code for byteswap()? In-Reply-To: <01ae01c38dd0$bbf58690$046fa8c0@RSWERDLOW800> References: <01ae01c38dd0$bbf58690$046fa8c0@RSWERDLOW800> Message-ID: <7535CDDC-F9D4-11D7-8EF8-000A27B19B96@cwi.nl> On 8-okt-03, at 21:16, Bob Swerdlow wrote: > In the documentation at > http://python.org/doc/current/lib/module-array.html, > it states that byteswap is only supported for "values which are 1, 2, > 4, or > 8 bytes in size," yet all of the types listed in the table at the top > of the > page ARE one of those sizes. Is this a "future compatibility" issue or > something? Do I need to check that the type code is one of those > listed or > can I assume that byteswap() is going to work since all of the types > are > permitted? Post a bug report about this: the documentation should be clearer. If it would say "if you try to byteswap() on unsupported values you'll get an exception" you know that you don't have to worry. And practically: I wouldn't worry about it. As the typecode is stored with the array I can't imagine an implementation that would break things on byteswap() without telling you anything. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Wed Oct 8 17:30:51 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 8 17:30:56 2003 Subject: [Pythonmac-SIG] Starting a PEP for PIMP In-Reply-To: References: Message-ID: On 8-okt-03, at 21:44, John W. Baxter wrote: > On 10/4/2003 12:58, "Bob Ippolito" wrote: > >> Oh, sorry. PackMan it is. > > I have the funny feeling there's a trade mark problem there. Nope, that's "PacMan". There is another package that was called PackMan (or actually, it still is called that, but it seems to be dormant), it's some sort of a Sun tool written in Python. The homepage seems to be but it's down right now. I talked to the developer, and while he wouldn't be thrilled about another package called PackMan he said he wouldn't sue us:-) But still: I'm open to other good names. Unfortunately the Package Install Manager for Python was voted down:-) -- 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 eric.nieuwland at xs4all.nl Wed Oct 8 18:06:49 2003 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Wed Oct 8 18:06:57 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <83A3BBA3-F5FA-11D7-A43C-000A95686CD8@redivi.com> Message-ID: I've been catching up on this thread a bit and I'm under the impression that there meybe a mix-up on authentication needs when making packages available. First there the maintainer of the PackMan database needs to be assured that the source can be trusted. As there can be many sources, this is a hard problem and ultimately would require a full-blown PKI. Now I can hardly imagine anyone would like to set-up a PKI just for fun. PGP probably is the way to go here. Then there is the end-user who has to be convinced s/he can trust the PackMan database and the packages obtained through it. The discussion on MD5/SHA-1 and SSL seem to cover that fine. Bottom line is I would not try to implement a single mechanism and use it for both situations. Just my 10c. --eric From Jack.Jansen at cwi.nl Wed Oct 8 18:18:19 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 8 18:18:23 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> On 9-okt-03, at 0:06, Eric Nieuwland wrote: > First there the maintainer of the PackMan database needs to be assured > that the source can be trusted. As there can be many sources, this is > a hard problem and ultimately would require a full-blown PKI. Now I > can hardly imagine anyone would like to set-up a PKI just for fun. PGP > probably is the way to go here. I don't think so: I think MD5 is good enough here. The scapegoat downloaded a specific source distribution and built it without problems. S/he gets the md5 sum of that distribution, puts the URL and md5sum in the database and can be sure that whatever the end user downloads is correct. > Then there is the end-user who has to be convinced s/he can trust the > PackMan database and the packages obtained through it. The discussion > on MD5/SHA-1 and SSL seem to cover that fine. And now that I know there is SSL support in MacPython (which very pleasantly surprised me!!) I think we can solve everything except for name server spoofing (by having a wellknown secure-http URL in the distribution, that we use to check MD5 sums). Since this is as good as Safari is (which doesn't complain at all about certificates signed by unknown parties! To my surprise it doesn't even seem to let you find this out!!) I think it's good enough for us. -- 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 Wed Oct 8 18:46:21 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 8 18:47:22 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> References: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> Message-ID: <3D251A98-F9E1-11D7-9145-000A95BA5446@redivi.com> On Oct 8, 2003, at 18:18, Jack Jansen wrote: > > On 9-okt-03, at 0:06, Eric Nieuwland wrote: >> First there the maintainer of the PackMan database needs to be >> assured that the source can be trusted. As there can be many sources, >> this is a hard problem and ultimately would require a full-blown PKI. >> Now I can hardly imagine anyone would like to set-up a PKI just for >> fun. PGP probably is the way to go here. > > I don't think so: I think MD5 is good enough here. The scapegoat > downloaded a specific source distribution and built it without > problems. S/he gets the md5 sum of that distribution, puts the URL and > md5sum in the database and can be sure that whatever the end user > downloads is correct. > >> Then there is the end-user who has to be convinced s/he can trust the >> PackMan database and the packages obtained through it. The discussion >> on MD5/SHA-1 and SSL seem to cover that fine. > > And now that I know there is SSL support in MacPython (which very > pleasantly surprised me!!) > I think we can solve everything except for name server spoofing (by > having a wellknown > secure-http URL in the distribution, that we use to check MD5 sums). > > Since this is as good as Safari is (which doesn't complain at all > about certificates > signed by unknown parties! To my surprise it doesn't even seem to let > you find this out!!) > I think it's good enough for us. Safari sure does complain about certs signed by unknown parties, and even Mail.app does (in 10.3). From Safari: The website?s certificate was signed by an unknown certifying authority. You might be connecting to a website that is pretending to be ?svn.mobwire.com? which could put your confidential information at risk. Would you like to continue anyway? I haven't found a way in Safari to look at the certs, but Mail.app lets you look at certs. -bob From bob at redivi.com Wed Oct 8 21:45:08 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 8 21:45:33 2003 Subject: [Pythonmac-SIG] Package manager notes In-Reply-To: <20031008193709.GB29078@rogue.amk.ca> References: <20031008193709.GB29078@rogue.amk.ca> Message-ID: <366A5786-F9FA-11D7-9145-000A95BA5446@redivi.com> On Oct 8, 2003, at 15:37, amk@amk.ca wrote: > * Note that PyCrypto doesn't help with verifying SSL server > certificates; > these are two different levels, and complicated tasks like ASN.1 > parsing > separate them. We could either fix the socket module to support > server > certificate verification, or we could use bits of PyCrypto to > check signatures on a file. > > It would be possible to include a signature-only algorithm such as > DSA in Python, subject to Guido's veto, but that's a non-trivial > amount of > packaging work, though, because it would need infrastructure for > generating prime numbers, etc. PyOpenSSL or M2Crypto are what one would probably use for this. This is a perfectly fine solution for OS X, since all versions of OS X (that I'm aware of) come with OpenSSL out of the box. Windows does not, but Microsoft has cryptography APIs that could be wrapped for this purpose. I think the consensus is that Guido will probably veto any kind of possibly-illegal-somewhere crypto in the Python core, but I see no reason why we shouldn't be able to wrap the SSL stuff if the OS comes with a dynamic library that does it all (Python already ships like this, with limited SSL capability). I'd love to get PyCrypto in Python, but from the discussions I've been pointed to at python-dev make me think it will probably not happen. In any case, I don't think it will be so important to get lots of batteries in the Python core if people can just use PackMan to install things quick and easy. For versions of Python that ship with SSL certificate verification support it could come with enough information to verify the authenticity of the main PackMan database. Other versions could maybe ship with the hash and URL of a cryptography package and the public key of the main PackMan database, which should be relatively safe if the user is allowed to use cryptography. Otherwise, they're on their own as far as security goes. -bob From oussoren at cistron.nl Thu Oct 9 01:46:34 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Thu Oct 9 01:46:40 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> References: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> Message-ID: On 9 okt 2003, at 0:18, Jack Jansen wrote: > Since this is as good as Safari is (which doesn't complain at all > about certificates > signed by unknown parties! To my surprise it doesn't even seem to let > you find this out!!) > I think it's good enough for us. Safari does complain when I try to acccess a site with a self-signed certificate, and even on one with a valid cert signed by a dutch CA (an affiliate of verisign). I do find it pretty annoying that safari won't tell me the details of a cert or why it doesn't trust a cert. I'd file a bugreport if the safari key verification isn't good enough. Ronald > -- > Jack Jansen, , http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From mwh at python.net Thu Oct 9 05:54:22 2003 From: mwh at python.net (Michael Hudson) Date: Thu Oct 9 05:53:32 2003 Subject: [Pythonmac-SIG] Package manager notes In-Reply-To: <20031008193709.GB29078@rogue.amk.ca> (amk@amk.ca's message of "Wed, 8 Oct 2003 15:37:09 -0400") References: <20031008193709.GB29078@rogue.amk.ca> Message-ID: <2m7k3eybw1.fsf@starship.python.net> amk@amk.ca writes: > * This might be a good time to work on a package database; there are various > other things that could be fixed in Distutils, and maybe it's time for a > Distutils 2.0. Maybe, but that's a whole lot of tedious work. It would be a bit easier if we made a new package "distutils2" and didn't have to worry too much about breaking everyone's setup.py scripts. And it probably should have a serious design discussion first. Maybe a good sprint topic? Cheers, mwh -- > Touche! But this confirms you are composed of logic gates. Crud, I thought those were neurons in there. -- Thomas F. Burdick, Kenny Tilton, comp.lang.lisp From eric.nieuwland at xs4all.nl Thu Oct 9 14:04:25 2003 From: eric.nieuwland at xs4all.nl (Eric Nieuwland) Date: Thu Oct 9 14:04:29 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> References: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> Message-ID: <4694.80.126.135.77.1065722665.squirrel@webmail.xs4all.nl> Jack Jansen said: > > On 9-okt-03, at 0:06, Eric Nieuwland wrote: >> First there the maintainer of the PackMan database needs to be assured >> that the source can be trusted. As there can be many sources, this is >> a hard problem and ultimately would require a full-blown PKI. Now I >> can hardly imagine anyone would like to set-up a PKI just for fun. PGP >> probably is the way to go here. > > I don't think so: I think MD5 is good enough here. The scapegoat > downloaded a specific source distribution and built it without > problems. S/he gets the md5 sum of that distribution, puts the URL and > md5sum in the database and can be sure that whatever the end user > downloads is correct. OK. I assumed that the scapegoat would like to know for sure where the code came from. Otherwise, s/he has to either trust the source and thus the developer or review and test every package. >> Then there is the end-user who has to be convinced s/he can trust the >> PackMan database and the packages obtained through it. The discussion >> on MD5/SHA-1 and SSL seem to cover that fine. > > And now that I know there is SSL support in MacPython (which very > pleasantly surprised me!!) > I think we can solve everything except for name server spoofing (by > having a wellknown > secure-http URL in the distribution, that we use to check MD5 sums). Now if we could use a fixed IP-address for the next ten years or so, then we could by-pass the name server and avoid the spoofing issue. From Jack.Jansen at cwi.nl Thu Oct 9 15:06:43 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Thu Oct 9 15:06:53 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <4694.80.126.135.77.1065722665.squirrel@webmail.xs4all.nl> References: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> <4694.80.126.135.77.1065722665.squirrel@webmail.xs4all.nl> Message-ID: On 9-okt-03, at 20:04, Eric Nieuwland wrote: >> I don't think so: I think MD5 is good enough here. The scapegoat >> downloaded a specific source distribution and built it without >> problems. S/he gets the md5 sum of that distribution, puts the URL and >> md5sum in the database and can be sure that whatever the end user >> downloads is correct. > > OK. I assumed that the scapegoat would like to know for sure where the > code came from. Otherwise, s/he has to either trust the source and thus > the developer or review and test every package. It is *definitely* the intention that the scapegoat reviews and tests every package! That's why s/he is called the scapegoat (and not the "package collector" or some such): if something is wrong with a package, or if there is unforeseen interaction among packages you're free to blame the scapegoat. The situation is the same as my role for the MacPython core distribution: if there's something wrong you can blame me. Not that this makes any significant difference in the open source world: you can blame me all you like but you can't sue me. But the intention is indeed that the scapegoat tests the packages to approximately the same level as I test MacPython distributions. But: this is my view on PackMan (have a small number of reasonably well tested packages), Bob's view is pretty different: he uses it mainly to distribute many packages in pre-compiled form, making them available to people without the developer tools, but without much testing done (if I understand correctly). >> And now that I know there is SSL support in MacPython (which very >> pleasantly surprised me!!) >> I think we can solve everything except for name server spoofing (by >> having a wellknown >> secure-http URL in the distribution, that we use to check MD5 sums). > > Now if we could use a fixed IP-address for the next ten years or so, > then > we could by-pass the name server and avoid the spoofing issue. After thinking about it a bit harder I think it doesn't really make a difference:-( We are going to need digital signatures at some point, so if we're not going to have them in Python we have to warn users and provide them with an out-of-band way to test packages. -- 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 amk at amk.ca Thu Oct 9 15:30:10 2003 From: amk at amk.ca (amk@amk.ca) Date: Thu Oct 9 15:30:17 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: <524F0C65-F9DD-11D7-8EF8-000A27B19B96@cwi.nl> <4694.80.126.135.77.1065722665.squirrel@webmail.xs4all.nl> Message-ID: <20031009193010.GA1859@rogue.amk.ca> On Thu, Oct 09, 2003 at 09:06:43PM +0200, Jack Jansen wrote: > We are going to need digital signatures at some point, so if we're > not going to have them in Python we have to warn users and provide > them with an out-of-band way to test packages. Can we use GnuPG? It provides an interface for being run as a subprocess and reporting results back in a form usable for programs. Perhaps it could just require that GnuPG is available (via Fink or some other mechanism). --amk From bob at redivi.com Thu Oct 9 15:35:43 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 9 15:36:24 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: On Thursday, Oct 9, 2003, at 15:06 America/New_York, Jack Jansen wrote: > > On 9-okt-03, at 20:04, Eric Nieuwland wrote: >>> I don't think so: I think MD5 is good enough here. The scapegoat >>> downloaded a specific source distribution and built it without >>> problems. S/he gets the md5 sum of that distribution, puts the URL >>> and >>> md5sum in the database and can be sure that whatever the end user >>> downloads is correct. >> >> OK. I assumed that the scapegoat would like to know for sure where the >> code came from. Otherwise, s/he has to either trust the source and >> thus >> the developer or review and test every package. > > It is *definitely* the intention that the scapegoat reviews and tests > every > package! That's why s/he is called the scapegoat (and not the "package > collector" or some such): if something is wrong with a package, or if > there > is unforeseen interaction among packages you're free to blame the > scapegoat. > > The situation is the same as my role for the MacPython core > distribution: > if there's something wrong you can blame me. > > Not that this makes any significant difference in the open source > world: > you can blame me all you like but you can't sue me. But the intention > is > indeed that the scapegoat tests the packages to approximately the same > level > as I test MacPython distributions. > > But: this is my view on PackMan (have a small number of reasonably > well tested > packages), Bob's view is pretty different: he uses it mainly to > distribute > many packages in pre-compiled form, making them available to people > without > the developer tools, but without much testing done (if I understand > correctly). I do plenty of testing on a few of the packages, but some of them I don't know how to or have time to test thoroughly. If someone tells me that a package doesn't work, I'll fix it. You're right though, I'm more concerned with giving people an easy out to installing packages than to give them an easy out that works with 99% certainty. The quality of package I'm giving them is certainly no lower than if they had compiled it themselves with normal options, especially for the packages that I have to modify in some way or compile with exotic options (i.e. static libtiff, libjpeg, etc in PIL, vecLib support in Numeric, etc.). I suppose that's why I'm running the experimental/unofficial database :) Perhaps we should have a system where users of the packages can give a particular package in my repository a vote of confidence, which you can review and use to eventually migrate the package into the official stable repository. The same system should also be used to report bugs with packages, and to request new packages. By the way, with regard to the include statement in the plist, if I include your database but have a newer version of a particular package, do both versions show up or just the newest? -bob From bob at redivi.com Thu Oct 9 15:43:33 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 9 15:44:11 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <20031009193010.GA1859@rogue.amk.ca> Message-ID: On Thursday, Oct 9, 2003, at 15:30 America/New_York, amk@amk.ca wrote: > On Thu, Oct 09, 2003 at 09:06:43PM +0200, Jack Jansen wrote: >> We are going to need digital signatures at some point, so if we're >> not going to have them in Python we have to warn users and provide >> them with an out-of-band way to test packages. > > Can we use GnuPG? It provides an interface for being run as a > subprocess > and reporting results back in a form usable for programs. Perhaps it > could > just require that GnuPG is available (via Fink or some other > mechanism). I think it would be a lot easier on the users if we could just let them install a particular Python package that can do the signature verification. Is there anything in OpenSSL that could be exploited for this purpose? I think we could get away with including M2Crypto or PyOpenSSL with (Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS X is probably only salable in countries where OpenSSL is allowed, I don't see how distributing any cryptography libraries with the OS X version would be a legal problem. I'd rather not depend on Fink, or something "obscure" like GnuPG, because that kinda defeats the purpose of what we're doing. Besides, Fink has their own version of Python that they maintain a package repository for. -bob From gandreas at delver.com Thu Oct 9 15:57:01 2003 From: gandreas at delver.com (Glenn Andreas) Date: Thu Oct 9 15:58:17 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: >On Thursday, Oct 9, 2003, at 15:30 America/New_York, amk@amk.ca wrote: > >>On Thu, Oct 09, 2003 at 09:06:43PM +0200, Jack Jansen wrote: >>>We are going to need digital signatures at some point, so if we're >>>not going to have them in Python we have to warn users and provide >>>them with an out-of-band way to test packages. >> >>Can we use GnuPG? It provides an interface for being run as a subprocess >>and reporting results back in a form usable for programs. Perhaps it could >>just require that GnuPG is available (via Fink or some other mechanism). > >I think it would be a lot easier on the users if we could just let >them install a particular Python package that can do the signature >verification. Is there anything in OpenSSL that could be exploited >for this purpose? According to http://www.openssl.org/docs/crypto/DSA_sign.html it sure looks that way. Now if this is directly usable, that's another question... -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From bob at redivi.com Thu Oct 9 16:11:35 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 9 16:12:16 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: On Thursday, Oct 9, 2003, at 15:57 America/New_York, Glenn Andreas wrote: >> On Thursday, Oct 9, 2003, at 15:30 America/New_York, amk@amk.ca wrote: >> >>> On Thu, Oct 09, 2003 at 09:06:43PM +0200, Jack Jansen wrote: >>>> We are going to need digital signatures at some point, so if we're >>>> not going to have them in Python we have to warn users and provide >>>> them with an out-of-band way to test packages. >>> >>> Can we use GnuPG? It provides an interface for being run as a >>> subprocess >>> and reporting results back in a form usable for programs. Perhaps >>> it could >>> just require that GnuPG is available (via Fink or some other >>> mechanism). >> >> I think it would be a lot easier on the users if we could just let >> them install a particular Python package that can do the signature >> verification. Is there anything in OpenSSL that could be exploited >> for this purpose? > > According to http://www.openssl.org/docs/crypto/DSA_sign.html it sure > looks that way. > > Now if this is directly usable, that's another question... PyOpenSSL documentation (probably does it): http://pyopenssl.sourceforge.net/pyOpenSSL.txt (3.1.3 - X509Req objects) sign(pkey, digest) Sign the certificate, using the key pkey and the message digest algorithm identified by the string digest. verify(pkey) Verify a certificate request using the public key pkey. M2Crypto has an example implementation of S/MIME as a HOWTO on its page (sign, encrypt, decrypt, verify)! http://sandbox.rulemaker.net/ngps/m2/howto.smime.html It looks like doing this w/ M2Crypto would likely be more straightforward, but it's probably possible in either. It's *definitely* possible to verify a SSL certificate with either :) -bob From oussoren at cistron.nl Thu Oct 9 16:24:45 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Thu Oct 9 16:25:01 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: <9F00DD16-FA96-11D7-A624-0003931CFE24@cistron.nl> On 9 okt 2003, at 21:43, Bob Ippolito wrote: > I think we could get away with including M2Crypto or PyOpenSSL with > (Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS X > is probably only salable in countries where OpenSSL is allowed, I > don't see how distributing any cryptography libraries with the OS X > version would be a legal problem. We could also use the commandline openssl interface (/usr/bin/openssl) to avoid including crypto code with Python. Ronald From bob at redivi.com Thu Oct 9 16:35:37 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 9 16:36:14 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <9F00DD16-FA96-11D7-A624-0003931CFE24@cistron.nl> Message-ID: <23A79868-FA98-11D7-BAC6-000A95686CD8@redivi.com> On Thursday, Oct 9, 2003, at 16:24 America/New_York, Ronald Oussoren wrote: > > On 9 okt 2003, at 21:43, Bob Ippolito wrote: >> I think we could get away with including M2Crypto or PyOpenSSL with >> (Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS X >> is probably only salable in countries where OpenSSL is allowed, I >> don't see how distributing any cryptography libraries with the OS X >> version would be a legal problem. > > We could also use the commandline openssl interface (/usr/bin/openssl) > to avoid including crypto code with Python. I would consider including something like M2Crypto to be a lot more sane than trying to drive openssl command line, and just as legal. What's the difference between dynamically binding to an already present library to do crypto, or to call out another already present program linked to said already present library to do crypto? In both cases you're providing code that WILL do crypto if the software to do the grunt work is present, and in both cases you're not providing any crypto algorithms. The difference is that using M2Crypto is going to be A LOT easier than using openssl from the command line (believe me, I've tried it). -bob From jwblist at olympus.net Thu Oct 9 20:34:24 2003 From: jwblist at olympus.net (John W. Baxter) Date: Thu Oct 9 20:34:43 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <9F00DD16-FA96-11D7-A624-0003931CFE24@cistron.nl> Message-ID: On 10/9/2003 13:24, "Ronald Oussoren" wrote: > > On 9 okt 2003, at 21:43, Bob Ippolito wrote: >> I think we could get away with including M2Crypto or PyOpenSSL with >> (Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS X >> is probably only salable in countries where OpenSSL is allowed, I >> don't see how distributing any cryptography libraries with the OS X >> version would be a legal problem. > > We could also use the commandline openssl interface (/usr/bin/openssl) > to avoid including crypto code with Python. > This message reminded me...are we assuming installation of the "BSD subsystem" when the user installed Mac OS X? Sub question: is OpenSSL in the basic installation or in that optional part that should [almost] never be omitted? Of course, if Python is in the optional area, then we're assuming its installation. Further: don't answer (since you can't yet) but does Panther retain this distinction? --John From bob at redivi.com Thu Oct 9 23:45:02 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 9 23:45:25 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: References: Message-ID: <20CDB8B5-FAD4-11D7-A307-000A95BA5446@redivi.com> On Oct 9, 2003, at 20:34, John W. Baxter wrote: > On 10/9/2003 13:24, "Ronald Oussoren" wrote: > >> >> On 9 okt 2003, at 21:43, Bob Ippolito wrote: >>> I think we could get away with including M2Crypto or PyOpenSSL with >>> (Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS X >>> is probably only salable in countries where OpenSSL is allowed, I >>> don't see how distributing any cryptography libraries with the OS X >>> version would be a legal problem. >> >> We could also use the commandline openssl interface (/usr/bin/openssl) >> to avoid including crypto code with Python. >> > > This message reminded me...are we assuming installation of the "BSD > subsystem" when the user installed Mac OS X? Sub question: is OpenSSL > in > the basic installation or in that optional part that should [almost] > never > be omitted? I think if anyone omits the BSD layer they're just asking for serious trouble. I don't care about these people, personally. In any case, I'm relatively sure that CoreFoundation uses OpenSSL so I think that it's safe. > Of course, if Python is in the optional area, then we're assuming its > installation. If OpenSSL is in the optional layer then so is Python. I think that's pretty much a given. > Further: don't answer (since you can't yet) but does Panther retain > this > distinction? I don't recall seeing a BSD option when I might've installed Panther because I might have an ADC membership. I might try again though to make sure. -bob From Jack.Jansen at cwi.nl Fri Oct 10 05:01:05 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 10 05:00:33 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <9F00DD16-FA96-11D7-A624-0003931CFE24@cistron.nl> Message-ID: <47C945E6-FB00-11D7-A8F9-0030655234CE@cwi.nl> On Thursday, October 9, 2003, at 10:24 PM, Ronald Oussoren wrote: > > On 9 okt 2003, at 21:43, Bob Ippolito wrote: >> I think we could get away with including M2Crypto or PyOpenSSL with >> (Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS X >> is probably only salable in countries where OpenSSL is allowed, I >> don't see how distributing any cryptography libraries with the OS X >> version would be a legal problem. > > We could also use the commandline openssl interface (/usr/bin/openssl) > to avoid including crypto code with Python. This is a really good option! I've been toying with it a bit, and here's an idea for a scheme that could be everything to everyone (i.e. please shoot holes in it:-) 1. A database contains a number of signatures. Each of these is a tuple (algorithm, signature, additionalinfo). 2. PackMan has an extensible set of signature checkers (similar to the way unpacking archives is currently handled). These signature checkers are ordered, i.e. the code looks something like for checker in signature_checkers: for algorithm, signature, additionalinfo in db.signatures: if checker.can_handle(algorithm, additionalinfo): return checker.check(algorithm, db, signature, additionalinfo) 3. The very last signature checker is the "user checker": it takes the MD5 sum of the database (the signature field is empty for the user checker algorithm), tells the user what it is, shows additionalinfo (which is probably a secure url) and asks for "yes" or "no". The nice thing of having multiple checkers is that there could be two checkers for, say, x509 signatures: the first one would try to use M2Crypto, but if that isn't available in the current Python installation the second one would use /usr/bin/openssl. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 10 05:08:55 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 10 05:08:20 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <5FF03FD0-FB01-11D7-A8F9-0030655234CE@cwi.nl> On Thursday, October 9, 2003, at 09:35 PM, Bob Ippolito wrote: > I do plenty of testing on a few of the packages, but some of them I > don't know how to or have time to test thoroughly. If someone tells > me that a package doesn't work, I'll fix it. You're right though, I'm > more concerned with giving people an easy out to installing packages > than to give them an easy out that works with 99% certainty. The > quality of package I'm giving them is certainly no lower than if they > had compiled it themselves with normal options, especially for the > packages that I have to modify in some way or compile with exotic > options (i.e. static libtiff, libjpeg, etc in PIL, vecLib support in > Numeric, etc.). I suppose that's why I'm running the > experimental/unofficial database :) I'd still like to ask you to include the source distributions too... That will also make migration from the experimental to the official database easier. > Perhaps we should have a system where users of the packages can give a > particular package in my repository a vote of confidence, which you > can review and use to eventually migrate the package into the official > stable repository. The same system should also be used to report bugs > with packages, and to request new packages. I think we're getting on the turf of PyPi here. At least: I would hope that at some point in the future distutils, PackMan and PyPi are aware of each others existence, and each of them handles their part of the job. > By the way, with regard to the include statement in the plist, if I > include your database but have a newer version of a particular > package, do both versions show up or just the newest? I think that if the full names (name-version-flavor) are different you'll see both, but if their identical you'll see the one from the toplevel database (i.e. your database, in this case, as it is the one the user requested). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 10 05:22:10 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 10 05:21:35 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database Message-ID: <3994FDA0-FB03-11D7-A8F9-0030655234CE@cwi.nl> I started working on a PackMan database for Panther yesterday, and I ran into two cases that I think I couldn't have solved without the ability to run Python code from the database: 1. binary distributions are specific to the install location of Python, they're basically tar files. So, a binary distribution for Apple-MacPython is different from a binary distribution for JackJansen-MacPython. We work around this for per-user installs, but at a cost (such as C header files not being installed). So, I needed a new test to see where sys.prefix was pointing. 2. In Apple-installed Python sys.prefix/include/python2.3 is root-owned and readonly. This makes installers like Numeric fail (which want to write there). So I needed a new test for this (with the description being an explanation of the unix commands to run to fix this). All of these could have been handled in pimp itself, of course, but pimp is already out there, as distributed by Apple... -- 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 gherman at darwin.in-berlin.de Fri Oct 10 05:59:46 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Fri Oct 10 05:59:35 2003 Subject: [Pythonmac-SIG] Jython & Cocoa? Message-ID: <7A8BADB0-FB08-11D7-A9D6-00039345C610@darwin.in-berlin.de> Hi, I'm working on a Mac/Python/PyObjC article and wonder if there is any substantial experience with using Python code in combination with Cocoa projects implemented in Java (using Jython)? For the article this is only a marginal issue, of course, but it might be interesting to know more about limitations of Cocoa/Java/ Jython as compared to Cocoa/ObjC/PyObjC. E.g. I'm not quite sure if it is really "feasible" to subclass from Java Cocoa classes in Jython, etc... Thanks for any input! Dinu -- Dinu C. Gherman ...................................................................... "Even if you do learn to speak correct English, whom are you going to speak it to?" (Clarence Darrow) From gandreas at delver.com Fri Oct 10 09:53:22 2003 From: gandreas at delver.com (Glenn Andreas) Date: Fri Oct 10 09:55:01 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: <20CDB8B5-FAD4-11D7-A307-000A95BA5446@redivi.com> References: <20CDB8B5-FAD4-11D7-A307-000A95BA5446@redivi.com> Message-ID: At 11:45 PM -0400 10/9/03, Bob Ippolito wrote: >On Oct 9, 2003, at 20:34, John W. Baxter wrote: > >>On 10/9/2003 13:24, "Ronald Oussoren" wrote: >> >>> >>>On 9 okt 2003, at 21:43, Bob Ippolito wrote: >>>> I think we could get away with including M2Crypto or PyOpenSSL with >>>>(Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS X >>>>is probably only salable in countries where OpenSSL is allowed, I >>>>don't see how distributing any cryptography libraries with the OS X >>>>version would be a legal problem. >>> >>>We could also use the commandline openssl interface (/usr/bin/openssl) >>>to avoid including crypto code with Python. >>> >> >>This message reminded me...are we assuming installation of the "BSD >>subsystem" when the user installed Mac OS X? Sub question: is OpenSSL in >>the basic installation or in that optional part that should [almost] never >>be omitted? > >I think if anyone omits the BSD layer they're just asking for >serious trouble. I don't care about these people, personally. In >any case, I'm relatively sure that CoreFoundation uses OpenSSL so I >think that it's safe. I'm not so sure (at least not directly via a link to OpenSSL) - I just looked at Safari, which uses the SecurityFramework. SecurityFramework doesn't (dynamically) link with OpenSSL. However, it does contain routines like "DSA_do_sign" and "DSA_do_verify", so it appears that the library is statically linked into the SecurityFramework. However, the headers don't appear to mention these routines. SecurityFramework isn't part of the "optional BSD" layer, so if we link (dynamically) to it, everything should work. -- Glenn Andreas gandreas@delver.com Theldrow, Blobbo, Cythera, oh my! Be good, and you will be lonesome From bob at redivi.com Fri Oct 10 12:25:17 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 10 12:25:56 2003 Subject: [Pythonmac-SIG] Package Manager idea, adding a URL scheme In-Reply-To: Message-ID: <55D2863C-FB3E-11D7-BAC6-000A95686CD8@redivi.com> On Friday, Oct 10, 2003, at 09:53 America/New_York, Glenn Andreas wrote: > At 11:45 PM -0400 10/9/03, Bob Ippolito wrote: >> On Oct 9, 2003, at 20:34, John W. Baxter wrote: >> >>> On 10/9/2003 13:24, "Ronald Oussoren" wrote: >>> >>>> >>>> On 9 okt 2003, at 21:43, Bob Ippolito wrote: >>>>> I think we could get away with including M2Crypto or PyOpenSSL >>>>> with >>>>> (Mac)Python 2.4 since OS X comes with OpenSSL. Actually, since OS >>>>> X >>>>> is probably only salable in countries where OpenSSL is allowed, I >>>>> don't see how distributing any cryptography libraries with the OS X >>>>> version would be a legal problem. >>>> >>>> We could also use the commandline openssl interface >>>> (/usr/bin/openssl) >>>> to avoid including crypto code with Python. >>>> >>> >>> This message reminded me...are we assuming installation of the "BSD >>> subsystem" when the user installed Mac OS X? Sub question: is >>> OpenSSL in >>> the basic installation or in that optional part that should [almost] >>> never >>> be omitted? >> >> I think if anyone omits the BSD layer they're just asking for serious >> trouble. I don't care about these people, personally. In any case, >> I'm relatively sure that CoreFoundation uses OpenSSL so I think that >> it's safe. > > I'm not so sure (at least not directly via a link to OpenSSL) - I just > looked at Safari, which uses the SecurityFramework. > > SecurityFramework doesn't (dynamically) link with OpenSSL. > > However, it does contain routines like "DSA_do_sign" and > "DSA_do_verify", so it appears that the library is statically linked > into the SecurityFramework. However, the headers don't appear to > mention these routines. > > SecurityFramework isn't part of the "optional BSD" layer, so if we > link (dynamically) to it, everything should work. That's pretty ridiculous. Sounds good though, SecurityFramework it is! -bob From bob at redivi.com Fri Oct 10 12:29:06 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 10 12:29:40 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database In-Reply-To: <3994FDA0-FB03-11D7-A8F9-0030655234CE@cwi.nl> Message-ID: On Friday, Oct 10, 2003, at 05:22 America/New_York, Jack Jansen wrote: > I started working on a PackMan database for Panther yesterday, and I > ran into two cases that I think I couldn't have solved without the > ability > to run Python code from the database: > > 1. binary distributions are specific to the install location of Python, > they're basically tar files. So, a binary distribution for > Apple-MacPython > is different from a binary distribution for JackJansen-MacPython. > We work around this for per-user installs, but at a cost (such as C > header > files not being installed). So, I needed a new test to see where > sys.prefix > was pointing. > 2. In Apple-installed Python sys.prefix/include/python2.3 is > root-owned and > readonly. This makes installers like Numeric fail (which want to > write there). > So I needed a new test for this (with the description being an > explanation > of the unix commands to run to fix this). > > All of these could have been handled in pimp itself, of course, but > pimp > is already out there, as distributed by Apple... 1. This is because we're using bdist_dumb, which is just as smart as it sounds. We'll inevitably be using something else in the future that's a lot smarter. 2. We shouldn't really be putting things in /System, ever. Anything that does system-wide installation should use the authorization API in order to acquire root access, even if the user has admin gid. 3. It's not hard to put a revised pimp inside a revised PackageManager app bundle, or just rename pimp as the consensus seems to be (although, I kinda like it). -bob From brownr at ucalgary.ca Fri Oct 10 13:57:23 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Fri Oct 10 13:57:31 2003 Subject: [Pythonmac-SIG] Stopping execution of a Python script Message-ID: <33AFE47A-FB4B-11D7-B008-000A959814B0@ucalgary.ca> Is there a way to create a simple breakpoint in a Python script? Like a stop command that stops the interpreter but doesn't kick you back to the command line like sys.exit()? _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From njriley at uiuc.edu Fri Oct 10 14:58:44 2003 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri Oct 10 15:00:46 2003 Subject: [Pythonmac-SIG] Stopping execution of a Python script In-Reply-To: <33AFE47A-FB4B-11D7-B008-000A959814B0@ucalgary.ca> References: <33AFE47A-FB4B-11D7-B008-000A959814B0@ucalgary.ca> Message-ID: <20031010185843.GA68401@uiuc.edu> On Fri, Oct 10, 2003 at 11:57:23AM -0600, Robb Brown wrote: > Is there a way to create a simple breakpoint in a Python script? Like > a stop command that stops the interpreter but doesn't kick you back to > the command line like sys.exit()? import pdb; pdb.set_trace() is the standard idiom; it'll drop you into the debugger. -- =Nicholas Riley | From Jack.Jansen at cwi.nl Fri Oct 10 16:34:38 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 10 16:34:43 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database In-Reply-To: References: Message-ID: <2B03AD00-FB61-11D7-ABD8-000A27B19B96@cwi.nl> On 10-okt-03, at 18:29, Bob Ippolito wrote: >> 1. binary distributions are specific to the install location of >> Python, >> they're basically tar files. So, a binary distribution for >> Apple-MacPython >> is different from a binary distribution for JackJansen-MacPython. >> We work around this for per-user installs, but at a cost (such as >> C header >> files not being installed). So, I needed a new test to see where >> sys.prefix >> was pointing. >> 2. In Apple-installed Python sys.prefix/include/python2.3 is >> root-owned and >> readonly. This makes installers like Numeric fail (which want to >> write there). >> So I needed a new test for this (with the description being an >> explanation >> of the unix commands to run to fix this). >> >> All of these could have been handled in pimp itself, of course, but >> pimp >> is already out there, as distributed by Apple... > > 1. This is because we're using bdist_dumb, which is just as smart as > it sounds. We'll inevitably be using something else in the future > that's a lot smarter. Definitely (and actually fairly simple[*]), but even then you cannot be 100% sure that any binary distribution can be re-targeted to a different location. There's nothing stopping the author of setup.py to store sys.prefix in a datafile somewhere. [*] Now that Python has its own tar module we could have a bdist_slightlylessdumb that creates a tarfile that has magic tokens for places like sys.prefix, etc. While a normal tar couldn't extract these to the right place a Python script to do so is dead simple. > 2. We shouldn't really be putting things in /System, ever. Anything > that does system-wide installation should use the authorization API in > order to acquire root access, even if the user has admin gid. In theory I agree with this. In practice there are a number of problems: - Not putting anything into /System conflicts with the accepted Python usage of packages adding stuff to include/python2.3. Until Python/distutils learn about a secondary include directory I think we have no options but putting things into /System (or not allowing it, at the expensive of disabling Numeric support in many packages). - We don't have the authorization API right now > 3. It's not hard to put a revised pimp inside a revised > PackageManager app bundle, or just rename pimp as the consensus seems > to be (although, I kinda like it). Actually, that wouldn't even be needed due to pimp's ability to update itself: just add a module pimp_update to site-packages and pimp will override itself with the contents of that module (if the version number is higher). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Fri Oct 10 16:45:57 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 10 16:58:37 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database In-Reply-To: <2B03AD00-FB61-11D7-ABD8-000A27B19B96@cwi.nl> Message-ID: On Friday, Oct 10, 2003, at 16:34 America/New_York, Jack Jansen wrote: > > On 10-okt-03, at 18:29, Bob Ippolito wrote: > >>> 1. binary distributions are specific to the install location of >>> Python, >>> they're basically tar files. So, a binary distribution for >>> Apple-MacPython >>> is different from a binary distribution for JackJansen-MacPython. >>> We work around this for per-user installs, but at a cost (such as >>> C header >>> files not being installed). So, I needed a new test to see where >>> sys.prefix >>> was pointing. >>> 2. In Apple-installed Python sys.prefix/include/python2.3 is >>> root-owned and >>> readonly. This makes installers like Numeric fail (which want to >>> write there). >>> So I needed a new test for this (with the description being an >>> explanation >>> of the unix commands to run to fix this). >>> >>> All of these could have been handled in pimp itself, of course, but >>> pimp >>> is already out there, as distributed by Apple... >> >> 1. This is because we're using bdist_dumb, which is just as smart as >> it sounds. We'll inevitably be using something else in the future >> that's a lot smarter. > > Definitely (and actually fairly simple[*]), but even then you cannot > be 100% sure that any binary distribution can be re-targeted to a > different location. There's nothing stopping the author of setup.py to > store sys.prefix in a datafile somewhere. There's nothing stopping the author of setup.py from writing an application that doesn't work either.. or stopping the author from using Makefile instead of setup.py. I'm not really concerned with these people. > [*] Now that Python has its own tar module we could have a > bdist_slightlylessdumb that creates a tarfile that has magic tokens > for places like sys.prefix, etc. While a normal tar couldn't extract > these to the right place a Python script to do so is dead simple. That's what I was thinking. I was actually really surprised that you were using bdist_dumb and rewriting the sys.prefix out of the paths to do user installs. Whatever works, right? :) >> 2. We shouldn't really be putting things in /System, ever. >> Anything that does system-wide installation should use the >> authorization API in order to acquire root access, even if the user >> has admin gid. > > In theory I agree with this. In practice there are a number of > problems: > - Not putting anything into /System conflicts with the accepted Python > usage of packages adding stuff to include/python2.3. Until > Python/distutils learn about a secondary include directory I think we > have no options but putting things into /System (or not allowing it, > at the expensive of disabling Numeric support in many packages). Let's put that into the distutils discussion. Python packages should have a canonical way of having headers, scripts, dynamic libraries, and other arbitrary data (like fonts, icons, etc.) associated with them *in the same or folder (or a closely related folder with identical permissions)* as the package itself. We could propose something like Apple's bundles for this purpose (sans versioning, most likely). > - We don't have the authorization API right now That's not a really good excuse, I can fix that this weekend. >> 3. It's not hard to put a revised pimp inside a revised >> PackageManager app bundle, or just rename pimp as the consensus seems >> to be (although, I kinda like it). > > Actually, that wouldn't even be needed due to pimp's ability to update > itself: just add a module pimp_update to site-packages and pimp will > override itself with the contents of that module (if the version > number is higher). That works too, forgot about that. It's a shame that site-packages isn't allowed to just replace standard library stuff (by way of sys.path ordering), since there are so many batteries these days that don't necessarily update at the same speed as Python and it's quite possible for someone to botch packaging of a battery, such as you forgetting to have bsddb installed when you packaged Python ;) -bob From Jack.Jansen at cwi.nl Fri Oct 10 17:51:17 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 10 17:51:20 2003 Subject: [Pythonmac-SIG] PackMan - package variation scheme Message-ID: Now that we're happily arguing PackMan I'd like to toss another issue into the arena that I don't have a solution for: package variations. I have some ideas, but I'd like feedback, please. Currently a package has a name, a version and a flavor. Versions and flavors are relatively simple to understand (and handle): versions have an ordering (even though we may have trouble actually determining that ordering in code:-) and flavors are only interesting during installation: after installation the result is supposed to be identical whether a package was installed from source or binary. It might be a good idea to rename flavor to installationMethod, as that is really what it means right now. But there's another set of variables, and that is optional functionality in the package. Let's look at PIL, for example: depending on the availability of libraries (and Tkinter) at build time it will have jpeg support or not, freetype support or not and Tk support or not. I would like it if we could express this in Package Manager. At the moment, you cannot state that a package X depends on "PIL with Tkinter support" or "PyOpenGL with Numeric support", but there are definitely cases where you want to be able to say that. The first thing this would require is a naming scheme, but that's the easy bit. I think something like PIL/jpeg/tkinter-1.1.4-binary should do the trick, with some magic in the compare function for package/option1/option2 comparisons. Sidebar: notice that the names becoming even uglier than they are now isn't an issue: they'll be hidden by the GUI normally. The end user will just see "PIL", and only when s/he chooses so, or there is a dependency conflict or something will the PIL package fold open to show that there's a lot of flavors and options hiding in there. But the difficult bit is determining what is installed. Currently the version check returns yes/no/old/error, but it would need to return much more info. Moreover, it would need to be able to deduce that info ("does this PIL have freetype support"), and I don't know how to do this (without Python code in the PackMan database). Or is this again something we drop on distutils's plate? (Or, actually, on the database of installed packages that we think distutils should maintain). Oh yes: note that I use the example of variations in binary packages here all the time but something similar can be envisioned for source packages. Think of something like reportlab, which comes in an open source version and a more capable commercial version. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Fri Oct 10 18:05:39 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 10 18:06:14 2003 Subject: [Pythonmac-SIG] PackMan - package variation scheme In-Reply-To: Message-ID: On Friday, Oct 10, 2003, at 17:51 America/New_York, Jack Jansen wrote: > Now that we're happily arguing PackMan I'd like to toss another issue > into the arena that I don't have a solution for: package variations. > I have some ideas, but I'd like feedback, please. > > Currently a package has a name, a version and a flavor. Versions and > flavors are relatively simple to understand (and handle): versions have > an ordering (even though we may have trouble actually determining that > ordering in code:-) and flavors are only interesting during > installation: > after installation the result is supposed to be identical whether a > package was installed from source or binary. It might be a good idea > to rename flavor to installationMethod, as that is really what it means > right now. > > But there's another set of variables, and that is optional > functionality > in the package. Let's look at PIL, for example: depending on the > availability of libraries (and Tkinter) at build time it will have > jpeg support or not, freetype support or not and Tk support or not. > > I would like it if we could express this in Package Manager. At the > moment, > you cannot state that a package X depends on "PIL with Tkinter support" > or "PyOpenGL with Numeric support", but there are definitely cases > where > you want to be able to say that. > > The first thing this would require is a naming scheme, but that's the > easy bit. I think something like PIL/jpeg/tkinter-1.1.4-binary should > do the trick, with some magic in the compare function for > package/option1/option2 > comparisons. > > Sidebar: notice that the names becoming even uglier than they are > now isn't an issue: they'll be hidden by the GUI normally. The > end user will just see "PIL", and only when s/he chooses so, or there > is a dependency conflict or something will the PIL package fold > open to show that there's a lot of flavors and options hiding in > there. > > But the difficult bit is determining what is installed. Currently the > version check returns yes/no/old/error, but it would need to return > much more info. Moreover, it would need to be able to deduce that > info ("does this PIL have freetype support"), and I don't know how > to do this (without Python code in the PackMan database). > > Or is this again something we drop on distutils's plate? (Or, actually, > on the database of installed packages that we think distutils should > maintain). > > Oh yes: note that I use the example of variations in binary packages > here all the time but something similar can be envisioned for source > packages. Think of something like reportlab, which comes in an open > source version and a more capable commercial version. I like this suggestion on theoretical grounds but it sounds unnecessarily complex. Reportlab commercial should have a different name than Reportlab free. PyOpenGL should never be compiled without Numeric support, PIL should never be compiled without jpeg/freetype support, although Tk is kinda questionable. This is why we have scapegoats to compile packages with optimal configuration choices (as many batteries as possible). If a package wants this kind of flexibility it should be a "Recommended" thing that's determined at runtime and not build time. IMHO, libraries like libjpeg should be wrapped from Python and used like that by packages like PIL, rather than having 10 packages that use libjpeg's functionality in their own way. If you have to link to a library at build time, you ought to be exporting as much of that library's functionality that could possibly be useful. This just sounds like a chore to implement for relatively rare situations and I'm definitely not interested in writing the code for it. -bob From wtbridgman at radix.net Sat Oct 11 09:55:13 2003 From: wtbridgman at radix.net (W.T. Bridgman) Date: Sat Oct 11 09:55:02 2003 Subject: [Pythonmac-SIG] python module module installation In-Reply-To: <878F1244-F98C-11D7-929D-000A9579AE94@csiro.au> Message-ID: <893E9F58-FBF2-11D7-A319-0050E485FC7A@radix.net> I usually put these single file modules (pyfits,py, etc.) in site-packages/ under the lib/ tree (wherever it is in your installation). Just copy them to there and they should be in your PYTHONPATH. Frankly, I've been favoring framework installations over Apple's installation and Fink, just because I have a bit more control over where things go. Tom On Wednesday, October 8, 2003, at 08:39 AM, Kim Branson wrote: > > Hi all, > > i'm new to python, and in the process of turning alot of perl into > python...its scientific code and the fact that only i understand it ( > given time to remember) and i have some new students has lead to the > decision to convert to python. I tend to run this on a linux cluster > but i want to do the dev work on my powerbook. I've got the mac python > build 2.3, and python 2.2 (fink install or sys?) as well. i managed > to get numeric python from the package manager and pulled down the > scientific python modules > > is there any issue in using the mac python port of python2.3 vs the > fink install? i assume there will be no differences assuming all > modules i use are present on my target nodes. > > doing python2.3 setup.py install seemed to put it in the right place. > ( even though its not in the package tree) Theres some stats stuff i'd > like. except all i have are 3 files that are stats.py , io.py and > pstat.py. Where should they go, can i put them in the same place? in > the top level or do they need a sub directory to go in ? > > sorry for the dumb question... > > cheers > > > Kim > > > > > >> _______________________________________________ >> 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 Jack.Jansen at cwi.nl Sat Oct 11 18:19:14 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Oct 11 18:19:20 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database In-Reply-To: References: Message-ID: On 10-okt-03, at 22:45, Bob Ippolito wrote: >>> 1. This is because we're using bdist_dumb, which is just as smart >>> as it sounds. We'll inevitably be using something else in the >>> future that's a lot smarter. >> >> Definitely (and actually fairly simple[*]), but even then you cannot >> be 100% sure that any binary distribution can be re-targeted to a >> different location. There's nothing stopping the author of setup.py >> to store sys.prefix in a datafile somewhere. > > There's nothing stopping the author of setup.py from writing an > application that doesn't work either.. or stopping the author from > using Makefile instead of setup.py. I'm not really concerned with > these people. That's not fair: having sys.prefix be correct has been the case in distutils since day one. So if you're creating an extension module that needs a pathname at runtime or something like that it's perfectly legitimate to add dependencies on sys.prefix. But, all that said: there's little we can do about it... >> [*] Now that Python has its own tar module we could have a >> bdist_slightlylessdumb that creates a tarfile that has magic tokens >> for places like sys.prefix, etc. While a normal tar couldn't extract >> these to the right place a Python script to do so is dead simple. > > That's what I was thinking. I was actually really surprised that you > were using bdist_dumb and rewriting the sys.prefix out of the paths to > do user installs. Whatever works, right? :) Partly, yes. And it's also a result of my attempts to use source distributions unadultered (which lowers the maintainance load on the scapegoat). There's one alternative to bdist_dumb, that looks much better from the description, but it's not generally available: ActiveState have a way of building binary distributions where they basically do "setup.py build", then freeze the tree, remove all the sources and pack that into an archive. On the destination system they then do something quite like "setup.py install". This doesn't work with standard distutils, because the "install" always does the "build" too. I would like to see something like this standardised in distutils, because it keeps the setup.py script, so it allows the package writer to do things like sys.prefix dependencies, as long as they're done at install time, not build time. >>> 2. We shouldn't really be putting things in /System, ever. >>> Anything that does system-wide installation should use the >>> authorization API in order to acquire root access, even if the user >>> has admin gid. >> >> In theory I agree with this. In practice there are a number of >> problems: >> - Not putting anything into /System conflicts with the accepted >> Python usage of packages adding stuff to include/python2.3. Until >> Python/distutils learn about a secondary include directory I think we >> have no options but putting things into /System (or not allowing it, >> at the expensive of disabling Numeric support in many packages). > > Let's put that into the distutils discussion. Python packages should > have a canonical way of having headers, scripts, dynamic libraries, > and other arbitrary data (like fonts, icons, etc.) associated with > them *in the same or folder (or a closely related folder with > identical permissions)* as the package itself. We could propose > something like Apple's bundles for this purpose (sans versioning, most > likely). For datafiles: yes, definitely. But you can already do that by stuffing the datafile into your package. For headers and scripts the situation is different, as these are really for use outside of the package. I think I see more in a scheme similar to what we discussed here a couple of months ago for site-packages: having a number of these for different "authorization groups". So there's site-packages for vendor, system-wide, per-user, and similar for include files. Dynamic libraries are a whole different can of worms, I have no ready solution for that. >> - We don't have the authorization API right now > > That's not a really good excuse, I can fix that this weekend. Then please please please do it with bgen, or with another technology that will allow me to import this into the Python core distribution and keep it maintainable..... >> Actually, that wouldn't even be needed due to pimp's ability to >> update itself: just add a module pimp_update to site-packages and >> pimp will override itself with the contents of that module (if the >> version number is higher). > > That works too, forgot about that. It's a shame that site-packages > isn't allowed to just replace standard library stuff (by way of > sys.path ordering), since there are so many batteries these days that > don't necessarily update at the same speed as Python and it's quite > possible for someone to botch packaging of a battery, such as you > forgetting to have bsddb installed when you packaged Python That's by design: installing something should never break the standard stuff. There is a way around it, but I'll only tell you if you promise never to use it:-) Seriously: I discussed this with Guido and he sort-of agreed that while standard third-parties should never override parts of the standard lib there is one exception, and that's to allow Python core developers responsible for a specific platform to override parts of the standard library in case the platform ships with Python pre-installed. You're free to read that long snippet as "that's me":-). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Sat Oct 11 19:38:54 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 11 19:39:35 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database In-Reply-To: Message-ID: <137186E3-FC44-11D7-9BD6-000A95686CD8@redivi.com> On Saturday, Oct 11, 2003, at 18:19 America/New_York, Jack Jansen wrote: > > On 10-okt-03, at 22:45, Bob Ippolito wrote: >>>> 1. This is because we're using bdist_dumb, which is just as smart >>>> as it sounds. We'll inevitably be using something else in the >>>> future that's a lot smarter. >>> >>> Definitely (and actually fairly simple[*]), but even then you cannot >>> be 100% sure that any binary distribution can be re-targeted to a >>> different location. There's nothing stopping the author of setup.py >>> to store sys.prefix in a datafile somewhere. >> >> There's nothing stopping the author of setup.py from writing an >> application that doesn't work either.. or stopping the author from >> using Makefile instead of setup.py. I'm not really concerned with >> these people. > > That's not fair: having sys.prefix be correct has been the case in > distutils since day one. > So if you're creating an extension module that needs a pathname at > runtime or something like > that it's perfectly legitimate to add dependencies on sys.prefix. But, > all that said: there's > little we can do about it... Yeah but that should happen at runtime not build time, so I don't think it's really that relevant to PackMan. >>> [*] Now that Python has its own tar module we could have a >>> bdist_slightlylessdumb that creates a tarfile that has magic tokens >>> for places like sys.prefix, etc. While a normal tar couldn't extract >>> these to the right place a Python script to do so is dead simple. >> >> That's what I was thinking. I was actually really surprised that you >> were using bdist_dumb and rewriting the sys.prefix out of the paths >> to do user installs. Whatever works, right? :) > > Partly, yes. And it's also a result of my attempts to use source > distributions unadultered > (which lowers the maintainance load on the scapegoat). There's one > alternative to bdist_dumb, > that looks much better from the description, but it's not generally > available: ActiveState > have a way of building binary distributions where they basically do > "setup.py build", then > freeze the tree, remove all the sources and pack that into an archive. > On the destination > system they then do something quite like "setup.py install". This > doesn't work with standard > distutils, because the "install" always does the "build" too. > > I would like to see something like this standardised in distutils, > because it keeps the > setup.py script, so it allows the package writer to do things like > sys.prefix dependencies, > as long as they're done at install time, not build time. Sounds like a good solution to me. This "setup.py" mechanism should be part of the "frozen archive", and not in the plist. >>>> 2. We shouldn't really be putting things in /System, ever. >>>> Anything that does system-wide installation should use the >>>> authorization API in order to acquire root access, even if the user >>>> has admin gid. >>> >>> In theory I agree with this. In practice there are a number of >>> problems: >>> - Not putting anything into /System conflicts with the accepted >>> Python usage of packages adding stuff to include/python2.3. Until >>> Python/distutils learn about a secondary include directory I think >>> we have no options but putting things into /System (or not allowing >>> it, at the expensive of disabling Numeric support in many packages). >> >> Let's put that into the distutils discussion. Python packages should >> have a canonical way of having headers, scripts, dynamic libraries, >> and other arbitrary data (like fonts, icons, etc.) associated with >> them *in the same or folder (or a closely related folder with >> identical permissions)* as the package itself. We could propose >> something like Apple's bundles for this purpose (sans versioning, >> most likely). > > For datafiles: yes, definitely. But you can already do that by > stuffing the datafile into your package. For headers and scripts the > situation is different, as these are really for use outside of the > package. I think I see more in a scheme similar to what we discussed > here a couple of months ago for site-packages: having a number of > these for different "authorization groups". So there's site-packages > for vendor, system-wide, per-user, and similar for include files. > > Dynamic libraries are a whole different can of worms, I have no ready > solution for that. Well if you keep everything inside some kind of package structure, symlinks can make the files available wherever else they're needed. This has the added benefit of allowing the package itself to find its own documentation files or headers for whatever reason, and it makes it pretty easy for the user to figure out what scripts/headers/etc belong to which package they installed. >>> - We don't have the authorization API right now >> >> That's not a really good excuse, I can fix that this weekend. > > Then please please please do it with bgen, or with another technology > that will allow me to import this into the Python core distribution > and keep it maintainable..... I don't think bgen is the right solution, this API has about 10 functions to wrap and most of them are going to require special treatment. I'm going to prototype it in Pyrex, and I'll take it down to hand coded C if it needs to be. >>> Actually, that wouldn't even be needed due to pimp's ability to >>> update itself: just add a module pimp_update to site-packages and >>> pimp will override itself with the contents of that module (if the >>> version number is higher). >> >> That works too, forgot about that. It's a shame that site-packages >> isn't allowed to just replace standard library stuff (by way of >> sys.path ordering), since there are so many batteries these days that >> don't necessarily update at the same speed as Python and it's quite >> possible for someone to botch packaging of a battery, such as you >> forgetting to have bsddb installed when you packaged Python > > That's by design: installing something should never break the standard > stuff. There is a way around it, but I'll only tell you if you promise > never to use it:-) > > Seriously: I discussed this with Guido and he sort-of agreed that > while standard third-parties should never override parts of the > standard lib there is one exception, and that's to allow Python core > developers responsible for a specific platform to override parts of > the standard library in case the platform ships with Python > pre-installed. You're free to read that long snippet as "that's > me":-). The only way I'm aware of is to develop this "upgrade" feature into the package itself, which PyXML and PackMan both have. Other than that the only solution I know of is to jigger sys.path or sys.modules yourself, but that requires changing site.py or importing something else. One thing I'd like the power to "upgrade" are some of your bgen-erated modules, the QuickTime stuff being the prime example. Lots of functions in your Qt module don't work as they're supposed to, or just aren't there.. Basically, you can't create a Qt movie from scratch with your version. I have a modified version where I mostly just added functions with new names to your bgen. -bob From hansv at net4all.be Sun Oct 12 04:36:28 2003 From: hansv at net4all.be (Hans verschooten) Date: Sun Oct 12 04:36:34 2003 Subject: [Pythonmac-SIG] Python, Panter and Quartz Message-ID: <2C0FB910-FC8F-11D7-B2F2-000393DB2890@net4all.be> Following snippet was found on the Apple site "Python users can also script the powerful Quartz compositing engine." Can anybody give more info on this, what does it mean, what can it be used for,... Any clarification is much appreciated, Hans verschooten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 405 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031012/06d2fce1/attachment.bin From bob at redivi.com Sun Oct 12 06:47:25 2003 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 12 06:48:03 2003 Subject: [Pythonmac-SIG] Python, Panter and Quartz In-Reply-To: <2C0FB910-FC8F-11D7-B2F2-000393DB2890@net4all.be> Message-ID: <773D28C6-FCA1-11D7-9BD6-000A95686CD8@redivi.com> On Sunday, Oct 12, 2003, at 04:36 America/New_York, Hans verschooten wrote: > Following snippet was found on the Apple site > > "Python users can also script the powerful Quartz compositing engine." > > Can anybody give more info on this, what does it mean, what can it be > used for,... I'm pretty sure that it means that Panther includes a Python SWIG wrapper for the CoreGraphics framework, and not a whole lot more. -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 584 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031012/33db52d8/attachment.bin From bob at redivi.com Mon Oct 13 01:45:35 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 13 01:46:55 2003 Subject: [Pythonmac-SIG] ANN: Authorization 0.1 - Wrapper for Apple's Authorization API Message-ID: <7755CE38-FD40-11D7-9C70-000A95BA5446@redivi.com> Authorization is a wrapper for Apple's Authorization API. Basically, it allows you to spawn an arbitrary process as root after successfully authenticating an administrator. This is useful for installers, twiddling kernel settings (via sysctl or the like), etc. You can fetch the source from: http://undefined.org/python/Authorization-0.1.tar.gz (You'll need Pyrex 0.9 to build) Or you can install it from my Package Manager repository: http://undefined.org/python/pimp/ (for instructions and HTML package listing) All of Apple's examples for using the Authorization API are pretty convoluted.. I did get Python versions of them to work, but this is the usage pattern that I felt maintained the most security and makes the most sense for Python (this is also the test/test.py file in the source distribution). I haven't tested on Panther yet, but I'm relatively sure it should still work. -bob #!/usr/bin/env python import os, sys, struct, tempfile from Authorization import Authorization, kAuthorizationFlagDestroyRights AUTHORIZEDTOOL = "#!%s\n%s" % (sys.executable, r""" import os print os.getuid(), os.geteuid() os.setuid(0) print "I'm root!" """) def main(): auth = Authorization(destroyflags=(kAuthorizationFlagDestroyRights,)) fd, name = tempfile.mkstemp('.py') os.write(fd, AUTHORIZEDTOOL) os.close(fd) os.chmod(name, 0700) try: pipe = auth.executeWithPrivileges(name) sys.stdout.write(pipe.read()) pipe.close() finally: os.unlink(name) if __name__=='__main__': main() From patrickjmoran at earthlink.net Mon Oct 13 01:17:17 2003 From: patrickjmoran at earthlink.net (Patrick Moran) Date: Mon Oct 13 04:41:37 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk Message-ID: <8371A8FA-FD3C-11D7-9CA2-000A95A4EC40@earthlink.net> Hello, I'm new to Mac ... and I'm in the process of porting over some 3-D graphics tools I have running under Linux. My application uses PyOpenGL. I downloaded MacPython-OSX-2.3.1. Then, using PackageManager, I downloaded PyOpenGL-2.0.1.04beta- binary and _tkinter-2.3-binary. So far seems OK. The basic Tkinter widgets are working. Cool. But when I try to import OpenGL.Tk, in preparation to do some 3-D rendering, I get: [Patrick-Morans-Computer:~] pmoran% /usr/local/bin/pythonw Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> >>> >>> import OpenGL.GL >>> import OpenGL.Tk Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/OpenGL/Tk/__init__.py", line 81, in ? _default_root.tk.call('package', 'require', 'Togl') _tkinter.TclError: can't find package Togl I have a PowerBook, running OS X 10.2.8. Help, suggestions, would be appreciated. Is there some sort of path I need to set? Thanks. Pat From bob at redivi.com Mon Oct 13 05:35:36 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 13 05:36:36 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk In-Reply-To: <8371A8FA-FD3C-11D7-9CA2-000A95A4EC40@earthlink.net> References: <8371A8FA-FD3C-11D7-9CA2-000A95A4EC40@earthlink.net> Message-ID: <993EC134-FD60-11D7-93B8-000A95BA5446@redivi.com> On Oct 13, 2003, at 1:17, Patrick Moran wrote: > I'm new to Mac ... and I'm in the process of porting over some > 3-D graphics tools I have running under Linux. My application > uses PyOpenGL. I downloaded MacPython-OSX-2.3.1. Then, > using PackageManager, I downloaded PyOpenGL-2.0.1.04beta- > binary and _tkinter-2.3-binary. So far seems OK. The basic > Tkinter widgets are working. Cool. But when I try to import > OpenGL.Tk, in preparation to do some 3-D rendering, I get: > > [Patrick-Morans-Computer:~] pmoran% /usr/local/bin/pythonw > Python 2.3 (#2, Jul 30 2003, 11:45:28) > [GCC 3.1 20020420 (prerelease)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> > >>> > >>> import OpenGL.GL > >>> import OpenGL.Tk > Traceback (most recent call last): > File "", line 1, in ? > File > "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- > packages/OpenGL/Tk/__init__.py", line 81, in ? > _default_root.tk.call('package', 'require', 'Togl') > _tkinter.TclError: can't find package Togl > > I have a PowerBook, running OS X 10.2.8. > > Help, suggestions, would be appreciated. Is there some sort of path > I need to set? Unfortunately, you're out of luck. Togl has not been ported to OS X yet, at least not for AquaTk. I just took a look at Togl and it seems nontrivial to compile for OS X (at least a few hours). Your best bet is to get rid of your dependency on Tk altogether and switch to something like wxPython, pygame, GLUT, PyObjC + Cocoa, etc. for your GUI. -bob From gherman at darwin.in-berlin.de Mon Oct 13 06:18:32 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Mon Oct 13 06:18:17 2003 Subject: [Pythonmac-SIG] ANN: ReSTedit 0.3 beta - added HTML and PDF export Message-ID: <98EB5F56-FD66-11D7-8F80-00039345C610@darwin.in-berlin.de> Hi, I've added some experimental HTML and PDF export to ReSTedit. For PDF you'll need a local LaTeX installation (this is too big to in- clude in a binary build ;-) and even then you might need to fiddle with providing the correct LaTeX path in the source... As prelimi- nary samples the Readme now comes in HTML and PDF, too. Comments are very welcome, especially about how to disable some menu item, like the PDF export one, which doesn't work out as I'd expect... As usual, you can get it here: http://python.net/~gherman/ReSTedit.html Regards, Dinu -- Dinu C. Gherman ...................................................................... "The whole point of brainwashing, is that those being brainwashed don't know it." (Graham Haley) From p.oberndoerfer at urheberrecht.org Mon Oct 13 07:02:44 2003 From: p.oberndoerfer at urheberrecht.org (Pascal Oberndoerfer) Date: Mon Oct 13 07:02:55 2003 Subject: [Pythonmac-SIG] Python, Panter and Quartz In-Reply-To: <2C0FB910-FC8F-11D7-B2F2-000393DB2890@net4all.be> Message-ID: Hans verschooten at hansv@net4all.be: > Following snippet was found on the Apple site > > "Python users can also script the powerful Quartz compositing engine." > > Can anybody give more info on this, what does it mean, what can it be > used for,... > > Any clarification is much appreciated, > > Hans verschooten Some info from Apple's Technology Brief, Mac OS X for UNIX Users: "In addition, Panther provides CoreGraphics bindings for Python - a new approach for command-line scripts and server processes to manipulate graphics. This rich set of Python bindings was created using the open source WIG interface compiler (Simplified Wrapper and Interface Generator, for creating scriptable APIs from C functions). It can access the PDF-based Quartz graphics engine and QuickTime image formats (such as PNG, JPEG, TIFF, GIF), as well as some Cocoa renderings. The scripts can perform complex manipulations on PDF and images, such as: - Render PDF, HTML, and RTF documents into a bitmap (implicitly using the Cocoa NSText and WebKit) that could be streamed from the server to the client (for example, new images for different zoom levels - useful for maps). - Add content to a specific page in a PDF document. - Use HTML forms that feed their input through Python to generate a PDF, for a receipt or invoice of the entered data. - Generate an n-up printed preview of a multipage PDF document. - Create a single image or a PDF document as an index print from multiple original images. - Remove or add color profiles to images (like sips). - Soft-proof images by applying an ICC profile." HTH Pascal From gherman at darwin.in-berlin.de Mon Oct 13 12:41:13 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Mon Oct 13 12:41:08 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds Message-ID: <0E9C6AF9-FD9C-11D7-8F80-00039345C610@darwin.in-berlin.de> Hi, I'm fiddling with coloring cells in TableViews and OutlineViews, and it seems like I must be doing something very stupid. In any case I can't get the cells colored as I like. They just seem to "overpaint" themselves with the standard white background. The funniest thing of all is: I can see the background color tem- porarily when attempting to edit a cell's content, but afterwards it disappears again... It's really driving me nuts... Here's the sample code if somebody has a minute to look at it: http://python.net/~gherman/tmp/TableViewTest.tar.gz One column should be coloured in alternating red and yellow, but it isn't. Regards, Dinu -- Dinu C. Gherman ...................................................................... "He who can read but does not read good books has no advantage over the ones who can't read." (Mark Twain) From bob at redivi.com Mon Oct 13 13:09:40 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 13 13:10:20 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <0E9C6AF9-FD9C-11D7-8F80-00039345C610@darwin.in-berlin.de> Message-ID: <085197F1-FDA0-11D7-81D1-000A95686CD8@redivi.com> On Monday, Oct 13, 2003, at 12:41 America/New_York, Dinu Gherman wrote: > I'm fiddling with coloring cells in TableViews and OutlineViews, > and it seems like I must be doing something very stupid. In any > case I can't get the cells colored as I like. They just seem to > "overpaint" themselves with the standard white background. > > The funniest thing of all is: I can see the background color tem- > porarily when attempting to edit a cell's content, but afterwards > it disappears again... It's really driving me nuts... Here's the > sample code if somebody has a minute to look at it: > > http://python.net/~gherman/tmp/TableViewTest.tar.gz > > One column should be coloured in alternating red and yellow, but > it isn't. You're forgetting: cell.setDrawsBackground_(True) Remember also that the same cell object gets reused, so make sure to set all the values that you need to set (i.e. turn the background off for the other column, set the color to white, etc.). -bob From gherman at darwin.in-berlin.de Mon Oct 13 13:56:22 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Mon Oct 13 13:56:06 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <085197F1-FDA0-11D7-81D1-000A95686CD8@redivi.com> Message-ID: <8E138EAA-FDA6-11D7-8F80-00039345C610@darwin.in-berlin.de> Bob Ippolito: > You're forgetting: > cell.setDrawsBackground_(True) Oh dear! But ok, thanks! Now, I assume, there must be a *really* horrible hack to make this work on the outline column of NSOutline- Views, too, since its cells are NSButtonCells (without background colors) instead of NSTextFieldCells... Sigh! Dinu -- Dinu C. Gherman ...................................................................... "An expert is someone who knows some of the worst mistakes that can be made in his subject, and how to avoid them." (Werner Heisenberg) From amk at amk.ca Mon Oct 13 14:14:08 2003 From: amk at amk.ca (amk@amk.ca) Date: Mon Oct 13 14:14:23 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database In-Reply-To: References: Message-ID: <20031013181408.GA21044@rogue.amk.ca> On Sun, Oct 12, 2003 at 12:19:14AM +0200, Jack Jansen wrote: > system they then do something quite like "setup.py install". This > doesn't work with standard > distutils, because the "install" always does the "build" too. Would "python setup.py install --skip-build" do the job? --amk From Jack.Jansen at cwi.nl Mon Oct 13 16:57:53 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Oct 13 16:58:00 2003 Subject: [Pythonmac-SIG] PackMan - in defence of Python code in the database In-Reply-To: <20031013181408.GA21044@rogue.amk.ca> References: <20031013181408.GA21044@rogue.amk.ca> Message-ID: On 13-okt-03, at 20:14, amk@amk.ca wrote: > On Sun, Oct 12, 2003 at 12:19:14AM +0200, Jack Jansen wrote: >> system they then do something quite like "setup.py install". This >> doesn't work with standard >> distutils, because the "install" always does the "build" too. > > Would "python setup.py install --skip-build" do the job? Uhm... I wasn't aware of that option, so I never tried it. Anyone here willing to do some experimentation? -- 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 bweiland at chisystems.com Mon Oct 13 11:22:47 2003 From: bweiland at chisystems.com (bweiland@chisystems.com) Date: Mon Oct 13 16:58:57 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk Message-ID: According to Bob Ippolito: > Unfortunately, you're out of luck. Togl has not been ported to OS X > yet, at least not for AquaTk. I just took a look at Togl and it seems > nontrivial to compile for OS X (at least a few hours). Your best bet > is to get rid of your dependency on Tk altogether and switch to > something like wxPython, pygame, GLUT, PyObjC + Cocoa, etc. for your > GUI. > > -bob > Oddly enough, I was just going thru this same ordeal myself. Tk, if Togl worked, would probably still be the best option for portable python GUI's that need OpenGL stuff, IMHO. Here's why I think so (and not trying to start a flame war): - tried wxPython - had weird problems with low framerate and flicker compared to just drawing in a GLUT window (maybe this was just me?); besides, I like Tk better for a quick hacked-together interface; - pygame - would be good, but pyui doesn't seem to be working yet for GUI elements on OS X; - GLUT - not really enough GUI; - PyObjC - not portable, but otherwise nice; - also, PyQt would be great, but the license is restrictive (it precludes portability to Windows if you're using the GPL'ed version; it's expensive otherwise). Enough complaining -- I looked at trying to port it, but it seemed like a lot of time I can't spend right now (since I really don't understand how the whole Tk side of things is put together). If anyone can provide some pointers that could shorten the time, I might try. If anyone is inclined to do the port, there are at least two users who would want it ;) Bill Weiland From Laurent.Pierron at loria.fr Mon Oct 13 12:49:23 2003 From: Laurent.Pierron at loria.fr (Laurent Pierron) Date: Mon Oct 13 16:59:00 2003 Subject: [Pythonmac-SIG] Stopping execution of a Python script In-Reply-To: <33AFE47A-FB4B-11D7-B008-000A959814B0@ucalgary.ca> References: <33AFE47A-FB4B-11D7-B008-000A959814B0@ucalgary.ca> Message-ID: <3F8AD793.6070907@loria.fr> Robb Brown wrote: > Is there a way to create a simple breakpoint in a Python script? Like a > stop command that stops the interpreter but doesn't kick you back to the > command line like sys.exit()? > In module time : sleep(secs) Suspend execution for the given number of seconds. The argument may be a floating point number to indicate a more precise sleep time. The actual suspension time may be less than that requested because any caught signal will terminate the sleep() following execution of that signal's catching routine. Also, the suspension time may be longer than requested by an arbitrary amount because of the scheduling of other activity in the system. -- Laurent PIERRON From bob at redivi.com Mon Oct 13 17:04:13 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 13 17:04:51 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk In-Reply-To: Message-ID: On Monday, Oct 13, 2003, at 11:22 America/New_York, bweiland@chisystems.com wrote: > > According to Bob Ippolito: > >> Unfortunately, you're out of luck. Togl has not been ported to OS X >> yet, at least not for AquaTk. I just took a look at Togl and it seems >> nontrivial to compile for OS X (at least a few hours). Your best bet >> is to get rid of your dependency on Tk altogether and switch to >> something like wxPython, pygame, GLUT, PyObjC + Cocoa, etc. for your >> GUI. > Oddly enough, I was just going thru this same ordeal myself. Tk, if > Togl worked, would probably still be the best option for portable > python > GUI's that need OpenGL stuff, IMHO. Here's why I think so (and not > trying > to start a flame war): > - tried wxPython - had weird problems with low framerate and flicker > compared to just drawing in a GLUT window (maybe this was just me?); > besides, I like Tk better for a quick hacked-together interface; > - pygame - would be good, but pyui doesn't seem to be working yet > for GUI elements on OS X; > - GLUT - not really enough GUI; > - PyObjC - not portable, but otherwise nice; > - also, PyQt would be great, but the license is restrictive (it > precludes portability to Windows if you're using the GPL'ed version; > it's > expensive otherwise). > > Enough complaining -- I looked at trying to port it, but it seemed > like a lot of time I can't spend right now (since I really don't > understand > how the whole Tk side of things is put together). If anyone can > provide > some pointers that could shorten the time, I might try. If anyone is > inclined to do the port, there are at least two users who would want > it ;) I'll take a closer look at it later this week if I find the time. -bob From bob at redivi.com Mon Oct 13 18:25:39 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 13 18:28:01 2003 Subject: [Pythonmac-SIG] Twisted's cfreactor + PyObjC = Asynchronous Networking on OS X Message-ID: <2C8A3280-FDCC-11D7-81D1-000A95686CD8@redivi.com> For those of you who don't watch Twisted CVS, cfreactor is officially out of the sandbox. cfreactor is the CoreFoundation integration reactor for Twisted ( http://www.twistedmatrix.com/ ), which means that you can now seamlessly integrate Cocoa and Twisted (without digging around in my sandbox, that is). If you're running OS X and you'd like to play with cfreactor, check out the latest CVS and do a python setup.py install (so that it can build twisted/internet/cfsupport.so -- ignore the warnings, they are expected for Pyrex modules). There are two examples provided in doc/examples/Cocoa. You will need PyObjC 1.0 (though it may work with earlier betas, you should upgrade if you haven't yet) and MacPython 2.3 (not tested with Panther yet, but should work). The next release version of Twisted, which is expected very shortly, will include this new reactor and updated documentation. When it is released, it will also be available from my Package Manager repository ( http://undefined.org/python/pimp/ ). SimpleWebClient - Pretty much a straight port of doc/examples/qtdemo.py, a very simple app that downloads HTML and puts it in a text box. WebServicesTool - A Twisted port of b.bum's XML-RPC demo (which is included with PyObjC). For fun, compare how much simpler the Twisted version is (since it doesn't need to deal with threads), and how much more responsive it feels. To run either demo, use the buildapp.py script provided in the same folder as the application: python buildapp.py build And then: open build/ApplicationName.app Note that when using cfreactor you should *always* call reactor.run() while the NSRunLoop is in action (best place to put it is probably in your NSApplication delegate's applicationDidFinishLaunching_ method). If you're using threads, make sure to only call into Twisted from the main runLoop (which is where you have to do your drawing anyways). And of course, you should cfreactor.install() before importing any other Twisted modules (see the "Choosing a Reactor and GUI Toolkit Integration" HOWTO for more information). -bob From patrickjmoran at earthlink.net Mon Oct 13 19:03:35 2003 From: patrickjmoran at earthlink.net (Patrick Moran) Date: Mon Oct 13 19:03:42 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk In-Reply-To: Message-ID: <79283F00-FDD1-11D7-AB86-000A95A4EC40@earthlink.net> Hi, Hmmm. I've heard good things about wxWindows / wxPython. On the other hand, I have a fair amount of Tkinter code, so it would be a big step to do the port. I do still want something that's cross platform -- I still need to be able to run under Linux at least. I've downloaded wxPython via the PackageManager. I'll give it a try and see how well it works with a 3-D rendering window. Pat On Monday, October 13, 2003, at 02:04 PM, Bob Ippolito wrote: > > On Monday, Oct 13, 2003, at 11:22 America/New_York, > bweiland@chisystems.com wrote: > >> >> According to Bob Ippolito: >> >>> Unfortunately, you're out of luck. Togl has not been ported to OS X >>> yet, at least not for AquaTk. I just took a look at Togl and it >>> seems >>> nontrivial to compile for OS X (at least a few hours). Your best bet >>> is to get rid of your dependency on Tk altogether and switch to >>> something like wxPython, pygame, GLUT, PyObjC + Cocoa, etc. for your >>> GUI. >> Oddly enough, I was just going thru this same ordeal myself. Tk, if >> Togl worked, would probably still be the best option for portable >> python >> GUI's that need OpenGL stuff, IMHO. Here's why I think so (and not >> trying >> to start a flame war): >> - tried wxPython - had weird problems with low framerate and flicker >> compared to just drawing in a GLUT window (maybe this was just me?); >> besides, I like Tk better for a quick hacked-together interface; >> - pygame - would be good, but pyui doesn't seem to be working yet >> for GUI elements on OS X; >> - GLUT - not really enough GUI; >> - PyObjC - not portable, but otherwise nice; >> - also, PyQt would be great, but the license is restrictive (it >> precludes portability to Windows if you're using the GPL'ed version; >> it's >> expensive otherwise). >> >> Enough complaining -- I looked at trying to port it, but it seemed >> like a lot of time I can't spend right now (since I really don't >> understand >> how the whole Tk side of things is put together). If anyone can >> provide >> some pointers that could shorten the time, I might try. If anyone is >> inclined to do the port, there are at least two users who would want >> it ;) > > I'll take a closer look at it later this week if I find the time. > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From astraw at insightscientific.com Mon Oct 13 19:24:15 2003 From: astraw at insightscientific.com (Andrew Straw) Date: Mon Oct 13 19:24:32 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk In-Reply-To: References: Message-ID: <3F8B341F.2070809@insightscientific.com> Bob Ippolito wrote: > > On Monday, Oct 13, 2003, at 11:22 America/New_York, > bweiland@chisystems.com wrote: > >> >> According to Bob Ippolito: >> >>> Unfortunately, you're out of luck. Togl has not been ported to OS X >>> yet, at least not for AquaTk. I just took a look at Togl and it seems >>> nontrivial to compile for OS X (at least a few hours). Your best bet >>> is to get rid of your dependency on Tk altogether and switch to >>> something like wxPython, pygame, GLUT, PyObjC + Cocoa, etc. for your >>> GUI. >> >> Oddly enough, I was just going thru this same ordeal myself. Tk, if >> Togl worked, would probably still be the best option for portable python >> GUI's that need OpenGL stuff, IMHO. Here's why I think so (and not >> trying >> to start a flame war): >> - tried wxPython - had weird problems with low framerate and flicker >> compared to just drawing in a GLUT window (maybe this was just me?); >> besides, I like Tk better for a quick hacked-together interface; >> - pygame - would be good, but pyui doesn't seem to be working yet >> for GUI elements on OS X; >> - GLUT - not really enough GUI; >> - PyObjC - not portable, but otherwise nice; >> - also, PyQt would be great, but the license is restrictive (it >> precludes portability to Windows if you're using the GPL'ed version; >> it's >> expensive otherwise). >> >> Enough complaining -- I looked at trying to port it, but it seemed >> like a lot of time I can't spend right now (since I really don't >> understand >> how the whole Tk side of things is put together). If anyone can provide >> some pointers that could shorten the time, I might try. If anyone is >> inclined to do the port, there are at least two users who would want >> it ;) > > > I'll take a closer look at it later this week if I find the time. > > -bob Recently, the maintainer of PyOpenGL has indicated that he's dropping Togl support (for Windows?) in the next release due to high maintenance requirements and limited usage. Not to discourage you from working on Togl, but I therefore think Tk may not be your best long-term cross-platform solution for OpenGL + GUI unless someone is willing to take over python/togl maintenance in general (and on the Mac in specific). I'm surprised you haven't had good luck with wx. Did you spend long trying to get it to work? How does the wxGLCanvas demo work for you? Cheers! Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031014/ec0a2722/attachment-0001.bin From bob at redivi.com Mon Oct 13 19:44:47 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 13 19:45:24 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk In-Reply-To: <3F8B341F.2070809@insightscientific.com> Message-ID: <3A6E9C8A-FDD7-11D7-81D1-000A95686CD8@redivi.com> On Monday, Oct 13, 2003, at 19:24 America/New_York, Andrew Straw wrote: > Bob Ippolito wrote: > >> >> On Monday, Oct 13, 2003, at 11:22 America/New_York, >> bweiland@chisystems.com wrote: >> >>> According to Bob Ippolito: >>> >>>> Unfortunately, you're out of luck. Togl has not been ported to OS X >>>> yet, at least not for AquaTk. I just took a look at Togl and it >>>> seems >>>> nontrivial to compile for OS X (at least a few hours). Your best >>>> bet >>>> is to get rid of your dependency on Tk altogether and switch to >>>> something like wxPython, pygame, GLUT, PyObjC + Cocoa, etc. for your >>>> GUI. >>> >>> Oddly enough, I was just going thru this same ordeal myself. >>> Tk, if >>> Togl worked, would probably still be the best option for portable >>> python >>> GUI's that need OpenGL stuff, IMHO. Here's why I think so (and not >>> trying >>> to start a flame war): >>> - tried wxPython - had weird problems with low framerate and >>> flicker >>> compared to just drawing in a GLUT window (maybe this was just me?); >>> besides, I like Tk better for a quick hacked-together interface; >>> - pygame - would be good, but pyui doesn't seem to be working yet >>> for GUI elements on OS X; >>> - GLUT - not really enough GUI; >>> - PyObjC - not portable, but otherwise nice; >>> - also, PyQt would be great, but the license is restrictive (it >>> precludes portability to Windows if you're using the GPL'ed version; >>> it's >>> expensive otherwise). >>> >>> Enough complaining -- I looked at trying to port it, but it >>> seemed >>> like a lot of time I can't spend right now (since I really don't >>> understand >>> how the whole Tk side of things is put together). If anyone can >>> provide >>> some pointers that could shorten the time, I might try. If anyone >>> is >>> inclined to do the port, there are at least two users who would want >>> it ;) >> >> I'll take a closer look at it later this week if I find the time. > > Recently, the maintainer of PyOpenGL has indicated that he's dropping > Togl support (for Windows?) in the next release due to high > maintenance requirements and limited usage. Not to discourage you > from working on Togl, but I therefore think Tk may not be your best > long-term cross-platform solution for OpenGL + GUI unless someone is > willing to take over python/togl maintenance in general (and on the > Mac in specific). Well forget that then :) I'm not a big fan of Tk anyways. Here's what I recall seeing from when I looked at it last night, if it helps: * It doesn't use distutils (ugh) * There are a whole bunch of paths that need to be changed to get it to work * You probably don't want to use the -DLOCAL_TK_HEADERS (from memory.. probably wrong, but the name is similar) cflag, since the version they have locally isn't the patched AquaTk version * Tcl/Tk plugins end up living in /Library/Tcl * Tcl/Tk plugins are dylibs, not bundles * There's X11 support, and AGL (OS9) support (enabled with -Dmacintosh). The AGL stuff should work on OS X, but you'd probably have to rewrite a bunch of the code that shoves the context into a window. The X11 stuff is a lost cause, cause _tkinter with MacPython is compiled to link against AquaTk, not an X11 Tk. Though the AquaTk does have a subset of X11 headers inside it, so you may need to -I those when compiling. Not sure whether they're standard or not. I've attached the Makefile that I have so far (from Togl-1.6, looks like I checked it out from CVS at some point) -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 6467 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031013/864dff3c/Makefile.obj -------------- next part -------------- Here's the changes I had made to togl.c, just headers at this point: [crack:PyOpenGL2/src/Togl-1.6] bob% cvs diff -u togl.c Index: togl.c =================================================================== RCS file: /cvsroot/pyopengl/PyOpenGL2/src/Togl-1.6/togl.c,v retrieving revision 1.2 diff -u -r1.2 togl.c --- togl.c 4 Aug 2003 13:55:01 -0000 1.2 +++ togl.c 13 Oct 2003 23:43:42 -0000 @@ -37,11 +37,8 @@ /*** Mac headers ***/ #elif defined(macintosh) && !defined(WIN32) && !defined(X11) -#include -#include -#include -#include - +#include +#include #else /* make sure only one platform defined */ #error Unsupported platform, or confused platform defines... #endif @@ -60,6 +57,9 @@ #endif #ifdef WIN32 +# include +#endif +#ifdef macintosh # include #endif Have fun! :) -bob From brian_l at mac.com Mon Oct 13 23:24:13 2003 From: brian_l at mac.com (Brian Lenihan) Date: Mon Oct 13 23:24:19 2003 Subject: [Pythonmac-SIG] Twisted's cfreactor + PyObjC = Asynchronous Networking on OS X In-Reply-To: <2C8A3280-FDCC-11D7-81D1-000A95686CD8@redivi.com> References: <2C8A3280-FDCC-11D7-81D1-000A95686CD8@redivi.com> Message-ID: On Oct 13, 2003, at 3:25 PM, Bob Ippolito wrote: > For those of you who don't watch Twisted CVS, cfreactor is officially > out of the sandbox. cfreactor is the CoreFoundation integration > reactor for Twisted ( http://www.twistedmatrix.com/ ), which means > that you can now seamlessly integrate Cocoa and Twisted (without > digging around in my sandbox, that is). This is really nice. And the demos really are much more responsive. Nice work. From gherman at darwin.in-berlin.de Tue Oct 14 07:10:49 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Tue Oct 14 07:10:33 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <8E138EAA-FDA6-11D7-8F80-00039345C610@darwin.in-berlin.de> Message-ID: <11086472-FE37-11D7-8ECC-00039345C610@darwin.in-berlin.de> I sighed: > Oh dear! But ok, thanks! Now, I assume, there must be a *really* > horrible hack to make this work on the outline column of NSOutline- > Views, too, since its cells are NSButtonCells (without background > colors) instead of NSTextFieldCells... Sigh! As it turns out this is kind of an eternal issue in the Cocoa mailing lists, driving many people either into solid desparation or leading them to putting all their hope into Panther (10.3.) where Apple has finally added some direct support for alterna- ting background colors. BUT... drumrolls... using Python there's no need to despair! I've come up with a working solution that is probably the shortest one you can have (with MyOutlineView being subclassed in IB from NS\ OutlineView). SOFT_BLUE = NSColor.colorWithCalibratedRed_green_blue_alpha_( 0.92941, 0.95294, 0.99607, 1.0) class MyOutlineView(NibClassBuilder.AutoBaseClass): def drawRow_clipRect_(self, row, rect): if row % 2 == 0 and not self.isRowSelected_(row): SOFT_BLUE.set() bounds = self.rectOfRow_(row) path = NSBezierPath.fillRect_(bounds) NSOutlineView.drawRow_clipRect_(self, row, rect) It draws the entire row background at one, but maybe one can also change it a bit to draw only one cell, which would leave the grid (if drawn) untouched, I guess. For the fun of it you can also use something like NSBezierPath.\ pathWithOvalInRect_ or anything else to draw something really more unusual... ;-) The inspiration for this came from Evan Jones' implementation in Objective-C, which is, of course, several times larger than the code above, especially since it involves more than only this one method: http://www.eng.uwaterloo.ca/~ejones/software/osx-iappview.html Puh, that was a nice hunt! Regards and thanks, Dinu -- Dinu C. Gherman ...................................................................... "An expert is someone who knows some of the worst mistakes that can be made in his subject, and how to avoid them." (Werner Heisenberg) From drewmccormack at mac.com Tue Oct 14 12:28:46 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Tue Oct 14 12:29:41 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <11086472-FE37-11D7-8ECC-00039345C610@darwin.in-berlin.de> Message-ID: <7BC9932E-FE63-11D7-8CC9-00039363BC02@mac.com> > > SOFT_BLUE = NSColor.colorWithCalibratedRed_green_blue_alpha_( > 0.92941, 0.95294, 0.99607, 1.0) > > class MyOutlineView(NibClassBuilder.AutoBaseClass): > def drawRow_clipRect_(self, row, rect): > if row % 2 == 0 and not self.isRowSelected_(row): > SOFT_BLUE.set() > bounds = self.rectOfRow_(row) > path = NSBezierPath.fillRect_(bounds) > NSOutlineView.drawRow_clipRect_(self, row, rect) > > The inspiration for this came from Evan Jones' implementation in > Objective-C, which is, of course, several times larger than the > code above, especially since it involves more than only this one > method: As an fan of Obj-C, I can't really let this go unanswered. There seems quite a bit of animosity toward Obj-C from python programmers, and I don't really understand why. To test the statement above, I rewrote the python code in Obj-C: id SoftBlue = [NSColor colorWithCalibratedRed:0.92941 green: 0.95294 blue:0.99607 alpha:1.0]; @interface MyOutlineView : NSOutlineView { } @end @implementation MyOutlineView -(void)drawRow:(int)row clipRect:(NSRect)rect { if ( row % 2 == 0 && ! [self isRowSelected:row] ) { [SoftBlue set]; NSRect bounds = [self rectOfRow:row]; path = [NSBezierPath fillRect:bounds]; [self drawRow:row clipRect:rect]; } } @end This is 494 characters long. The python example is 445 characters long. So in this case Obj-C is 10% longer, and this is a worst case example, because the ratio of method code to class declaration code is low: python basically replaces the '@interface/@implementation' type keywords with a single 'class' keyword. This leads me to something that I think is better in Obj-C than python: the smalltalk method naming. I like python a lot, and use it when I can. It is a concise language, and there are countless modules available which you can't find in Obj-C. But I find remembering method signatures, particularly the number or order of arguments, much more difficult in python than Obj-C. I have to continually go back to docs to jolt my memory. You don't have that problem in Obj-C, because you remember the method name, and it tells you what the arguments are. You often also avoid in-code comments, because the method calls are self documenting. In my view, monolithic method naming is a hangup from C/C++ that afflicts otherwise good languages like Java and python. It is the same as the countless linux windows managers that were too short-sighted to avoid using a 'Start' button. The dominant technology of the day dictates the trends, whether for good or bad. Along these lines, has anyone ever 'hacked' the python interpreter to do smalltalk like messaging, with segmented names? I've been tempted to try it myself. You wouldn't think it would be that hard. Maybe just an extra stage to convert segmented names to underscored ones, the same way that PyObjC names methods. But I'm no python expert, so I don't know what would be involved. Drew ---------------------------------- Dr. Drew McCormack Trade Strategist (www.trade-strategist.com) Stock Market strategy design platform for Mac OS X. From bob at redivi.com Tue Oct 14 13:00:13 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 14 13:02:06 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <7BC9932E-FE63-11D7-8CC9-00039363BC02@mac.com> Message-ID: On Tuesday, Oct 14, 2003, at 12:28 America/New_York, Drew McCormack wrote: >> >> SOFT_BLUE = NSColor.colorWithCalibratedRed_green_blue_alpha_( >> 0.92941, 0.95294, 0.99607, 1.0) >> >> class MyOutlineView(NibClassBuilder.AutoBaseClass): >> def drawRow_clipRect_(self, row, rect): >> if row % 2 == 0 and not self.isRowSelected_(row): >> SOFT_BLUE.set() >> bounds = self.rectOfRow_(row) >> path = NSBezierPath.fillRect_(bounds) >> NSOutlineView.drawRow_clipRect_(self, row, rect) >> >> The inspiration for this came from Evan Jones' implementation in >> Objective-C, which is, of course, several times larger than the >> code above, especially since it involves more than only this one >> method: > As an fan of Obj-C, I can't really let this go unanswered. There seems > quite a bit of animosity toward Obj-C from python programmers, and I > don't really understand why. --snip-- though to make your char-to-char comparison more fair you should to replace the Python "NSOutlineView(self, " with "self." .. I believe Dinu was using it for readability or something but it shouldn't be necessary, even for that, because he named it MyOutlineView. Besides, your ObjC code won't even compile because the (seemingly useless, inherited from Dinu's Python) path variable isn't declared anywhere. Also, don't the newer compilers complain when you declare variables in the middle of code? Wouldn't you have to put a "NSRect bounds;" at the top of the block? Obviously you could just do [NSBezierPath fillRect:[self rectOfRow: row]] .. which is probably how I'd have done it in the first place. > This leads me to something that I think is better in Obj-C than > python: the smalltalk method naming. I like python a lot, and use it > when I can. It is a concise language, and there are countless modules > available which you can't find in Obj-C. But I find remembering method > signatures, particularly the number or order of arguments, much more > difficult in python than Obj-C. I have to continually go back to docs > to jolt my memory. You don't have that problem in Obj-C, because you > remember the method name, and it tells you what the arguments are. You > often also avoid in-code comments, because the method calls are self > documenting. Yes, Python methods are typically a lot shorter than ObjC methods, but there's obviously nothing stopping you from naming them like drawRow_clipRect_ :) > In my view, monolithic method naming is a hangup from C/C++ that > afflicts otherwise good languages like Java and python. It is the same > as the countless linux windows managers that were too short-sighted to > avoid using a 'Start' button. The dominant technology of the day > dictates the trends, whether for good or bad. > > Along these lines, has anyone ever 'hacked' the python interpreter to > do smalltalk like messaging, with segmented names? I've been tempted > to try it myself. You wouldn't think it would be that hard. Maybe just > an extra stage to convert segmented names to underscored ones, the > same way that PyObjC names methods. But I'm no python expert, so I > don't know what would be involved. Along the same lines, ObjC doesn't have a short way to say anything (no operators). Probably my favorite feature of Python are strings, lists and dicts, with all the great __setitem__/__getitem__ stuff to go with it. In ObjC, a+b never means anything useful, unless a and b are primitive C types.. that's obnoxious, because you'd have to say a.add_(b) or something like that... Imagine writing an equation like that. Sure, in ObjC you can use int, long, float, double.. but what about equivalents to Python's long or complex? What about doing arrays/matrices (Numeric), etc. You can't create a NSDictionary like {a:b}. Operators and other syntax is extremely important, more so than a forced message passing syntax. If you want message passing syntax just use keyword arguments all over the place: def cryptic(method, with, arguments): pass cryptic(method='foo', with='bar', arguments='baz') If Python had any sort of "ordered dictionary" and the kwarg parsing could use it then you would basically have smalltalk style message passing syntax (if you wanted it). If Python acted like this then I'm sure PyObjC probably would've ended up more like self(drawRow=row, clipRect=rect) then self.drawRow_clipRect_(row, rect). I find myself wanting the "ordered dictionary" type for all sorts of things, for example in a class declaration, where it could be potentially useful to a metaclass to know the order. In any case, yes, ObjC isn't that bad. I like it more than most things, but I prefer Python, primarily for syntax reasons. -bob From txagcs98 at hotmail.com Tue Oct 14 14:19:28 2003 From: txagcs98 at hotmail.com (William McLendon) Date: Tue Oct 14 14:19:32 2003 Subject: [Pythonmac-SIG] forking in python Message-ID: I've got a script where I want to fork one child thread that goes off to execute a sequence of other scripts, using popen or whatever. I don't care what it uses to launch them, but it needs to be something that serializes all the launches. I can get it working, but it looks like the main thread blocks till after the child thread is finished running all the processes in its tasklist. How can I make this so that the main thread doesn't block? I'd like it to be able to do other stuff during this time. Thanks! -William _________________________________________________________________ Never get a busy signal because you are always connected with high-speed Internet access. Click here to comparison-shop providers. https://broadband.msn.com From njriley at uiuc.edu Tue Oct 14 14:20:27 2003 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue Oct 14 14:20:50 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: References: <7BC9932E-FE63-11D7-8CC9-00039363BC02@mac.com> Message-ID: <20031014182027.GB43818@uiuc.edu> On Tue, Oct 14, 2003 at 01:00:13PM -0400, Bob Ippolito wrote: > Also, don't the newer compilers complain when you declare variables in > the middle of code? Wouldn't you have to put a "NSRect bounds;" at the > top of the block? Obviously you could just do [NSBezierPath > fillRect:[self rectOfRow: row]] .. which is probably how I'd have done > it in the first place. Actually vice versa; GCC 3.0 and later-based compilers support C99 variable declaration syntax for ObjC, meaning you can declare a variable anywhere in a block. It's very useful. I learned the languages (using each for one or more major projects) in the order Python, Smalltalk, then ObjC. While there are some features in each language I wish were in the others, over time I found myself appreciating the _longer_ method names in ObjC, for their clarity and consistency. The equivalent of -[NSArray objectAtIndex:] and -[NSDictionary objectForKey:] in Smalltalk is simply #at: - i.e., |array at: 3| or |dict at: 'hi'| would work as in Python, array[3] and dict['hi']. Especially, I like the consistent way in which ObjC constructors tend to be named. Smalltalk's syntax for method declaration is a lot more consistent than Python's; none of this special __ism for what otherwise would be considered operator overloading (Smalltalk binary messages such as #+ and #,). Of course, Smalltalk has its issues masquerading as 'consistency' such as weird operator precedence. That said, over the course of my language-learning journey Python has evolved from 1.5.2 to 2.3.2, and many of the deficiencies I perceived in Python have disappeared. The biggest language-level problem for me now: I still wish Python lambdas worked more like Lisp or Smalltalk blocks; they're too confusing and limiting for functional programming as is. -- =Nicholas Riley | From drewmccormack at mac.com Tue Oct 14 14:38:58 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Tue Oct 14 14:39:15 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: Message-ID: > though to make your char-to-char comparison more fair you should to > replace the Python "NSOutlineView(self, " with "self." .. I believe > Dinu was using it for readability or something but it shouldn't be > necessary, even for that, because he named it MyOutlineView. Besides, > your ObjC code won't even compile because the (seemingly useless, > inherited from Dinu's Python) path variable isn't declared anywhere. I guess I left out ' id '. 3 more chars. > > Also, don't the newer compilers complain when you declare variables in > the middle of code? Wouldn't you have to put a "NSRect bounds;" at > the top of the block? Obviously you could just do [NSBezierPath > fillRect:[self rectOfRow: row]] .. which is probably how I'd have done > it in the first place. No, you can declare a var anywhere, and if you use 'id', it doesn't even take up that much room. I do agree that nothing at all is better than 'id' though. Obj-C has the advantage that you can use static typing if you need it. This can help document the code, if nothing else. > >> This leads me to something that I think is better in Obj-C than >> python: the smalltalk method naming. I like python a lot, and use it >> when I can. It is a concise language, and there are countless modules >> available which you can't find in Obj-C. But I find remembering >> method signatures, particularly the number or order of arguments, >> much more difficult in python than Obj-C. I have to continually go >> back to docs to jolt my memory. You don't have that problem in Obj-C, >> because you remember the method name, and it tells you what the >> arguments are. You often also avoid in-code comments, because the >> method calls are self documenting. > > Yes, Python methods are typically a lot shorter than ObjC methods, but > there's obviously nothing stopping you from naming them like > drawRow_clipRect_ :)yp Sure, and in Obj-C I can do this: -(void)cryptic:arg1 :arg2 :arg3 {} [obj cryptic:a :b :c] It can be just as brief if it needs to be. I find the drawRow_clipRect_ a bit of an ugly hack, albeit unavoidable. It's just not pretty ;-) > Along the same lines, ObjC doesn't have a short way to say anything > (no operators). Probably my favorite feature of Python are strings, > lists and dicts, with all the great __setitem__/__getitem__ stuff to > go with it. In ObjC, a+b never means anything useful, unless a and b > are primitive C types.. that's obnoxious, because you'd have to say > a.add_(b) or something like that... Imagine writing an equation like > that. Well, I have a different view of operator overloading. I think it is generally unnecessary, and can even have negative effects. The problem is, a lot of people don't know what is happening behind the scenes. If you have a matrix expression in C++ like this a = b * c + d you are creating two temporary objects. This has lead to the dismal performance of C++ in number crunching in the past. At least in Objective-C, it is explicit: id temp = [b multByMatrix:c]; id temp2 = [temp addToMatrix:d]; [a assignToMatrix:temp2]; This immediately draws attention to problems, and could lead to optimizations, like this: id temp = [b multByMatrix:c]; a = [temp addToMatrix:d]; I'm not at all convinced by the C++ doctrine that everything must behave like a built in type. I think objects are fundamentally different, and there is no reason to think they should respond to '+' or '*' operators. Methods like 'add' and 'mult' are just as good in my mind. > Sure, in ObjC you can use int, long, float, double.. but what about > equivalents to Python's long or complex? ?? typedef struct _Complex { double real, imag; } Complex; > What about doing arrays/matrices (Numeric), etc. You can't create a > NSDictionary like {a:b}. Python built-in data structures are powerful and concise. Agreed. > Operators and other syntax is extremely important, more so than a > forced message passing syntax. If you want message passing syntax > just use keyword arguments all over the place: > > def cryptic(method, with, arguments): > pass > cryptic(method='foo', with='bar', arguments='baz') Sure, you can do it, but you don't. It is ugly, and it is not the 'python way'. In the same way, you can just write Obj-C methods the way I demonstrated above, but that is not the 'Obj-C way'. > > If Python had any sort of "ordered dictionary" and the kwarg parsing > could use it then you would basically have smalltalk style message > passing syntax (if you wanted it). If Python acted like this then I'm > sure PyObjC probably would've ended up more like self(drawRow=row, > clipRect=rect) then self.drawRow_clipRect_(row, rect). I find myself > wanting the "ordered dictionary" type for all sorts of things, for > example in a class declaration, where it could be potentially useful > to a metaclass to know the order. > > In any case, yes, ObjC isn't that bad. I like it more than most > things, but I prefer Python, primarily for syntax reasons. Where I prefer python is: indented form built in data structures excess of packages and modules Where I prefer Obj-C/Cocoa: Possibility of static typing (makes large programs more readable, and catches a few bugs at compile time) Design of libraries. Cocoa is beautifully designed and stable. I have the feeling python's libs have evolved in a less stable way. With each new release of python, things get replaced, indicating they weren't that well done the first time round. Drew From bob at redivi.com Tue Oct 14 15:11:22 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 14 15:11:59 2003 Subject: [OT] [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <20031014182027.GB43818@uiuc.edu> Message-ID: <32E91A90-FE7A-11D7-8F46-000A95686CD8@redivi.com> On Tuesday, Oct 14, 2003, at 14:20 America/New_York, Nicholas Riley wrote: > That said, over the course of my language-learning journey Python has > evolved from 1.5.2 to 2.3.2, and many of the deficiencies I perceived > in Python have disappeared. The biggest language-level problem for me > now: I still wish Python lambdas worked more like Lisp or Smalltalk > blocks; they're too confusing and limiting for functional programming > as is. I definitely agree with you here. lambda in Python is extremely weak and useless most of the time. Sometimes I also want more things to be generators.. sometimes I wish lists had a sort that returns a new list, which is want a want most of the time anyways.. but I guess that's better off being a function that can take arbitrary sequences as input and return a sorted list. I like descriptors but I want a better way to create them, using classmethod/staticmethod/etc after creating a regular function is kind of annoying and isn't good for readability. I want stackless to be part of Python's core, etc. In any case, I think many of us want a language that's not Python, but is very much like Python.. I think the PyPy project might be the best way to make this happen, and some extremely smart people are working on it so I have high hopes. Until then I'm pretty content with what we do have because it's more useful as a whole than any other language I've tried. -bob From gherman at darwin.in-berlin.de Tue Oct 14 15:30:17 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Tue Oct 14 15:30:00 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: Message-ID: Bob Ippolito: > Also, don't the newer compilers complain when you declare variables in > the middle of code? Wouldn't you have to put a "NSRect bounds;" at > the top of the block? Obviously you could just do [NSBezierPath > fillRect:[self rectOfRow: row]] .. which is probably how I'd have done > it in the first place. All valid points, but still, I didn't mean to bash Objective-C at all. My comparison was about my basically 7 pyLOC against something like 20-30 objcLOC (depending on how you count, braces, etc.) of Evan Jones' code (including other methods which are perhaps not strictly needed). I *do* like Obj-C a lot, but Python is less to read and type, and also faster to test and get running... > Along the same lines, ObjC doesn't have a short way to say anything > (no operators). Probably my favorite feature of Python are strings, > lists and dicts, with all the great __setitem__/__getitem__ stuff to > go with it. In ObjC, a+b never means anything useful, unless a and b > are primitive C types.. that's obnoxious, because you'd have to say > a.add_(b) or something like that... Imagine writing an equation like > that. Sure, in ObjC you can use int, long, float, double.. but what > about equivalents to Python's long or complex? What about doing > arrays/matrices (Numeric), etc. You can't create a NSDictionary like > {a:b}. Operators and other syntax is extremely important, more so > than a forced message passing syntax. If you want message passing > syntax just use keyword arguments all over the place: [...] That's quite a few things I already wanted to list in my upcoming article. ;-) Drew McCormack: > Where I prefer Obj-C/Cocoa: > Possibility of static typing (makes large programs more readable, and > catches a few bugs at compile time) > Design of libraries. Cocoa is beautifully designed and stable. I have > the feeling python's libs have evolved in a less stable way. With each > new release of python, things get replaced, indicating they weren't > that well done the first time round. Unfortunately, this is true, especially of the standard library. It lacks a huge amount of consistency, which Cocoa, being an in- house year-long development, definitly has - sigh! And sadly, as you would expect in an Open Source project, nobody seems to care about that, at least not enough to make a difference... Dinu -- Dinu C. Gherman ...................................................................... "The whole point of brainwashing, is that those being brainwashed don't know it." (Graham Haley) From bweiland at chisystems.com Tue Oct 14 16:04:36 2003 From: bweiland at chisystems.com (bweiland@chisystems.com) Date: Tue Oct 14 16:04:46 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk Message-ID: Responding to two messages (from Andrew and Bob): Andrew Straw wrote: > Recently, the maintainer of PyOpenGL has indicated that he's dropping > Togl support (for Windows?) in the next release due to high maintenance > requirements and limited usage. Not to discourage you from working on > Togl, but I therefore think Tk may not be your best long-term > cross-platform solution for OpenGL + GUI unless someone is willing to > take over python/togl maintenance in general (and on the Mac in specific). > > I'm surprised you haven't had good luck with wx. Did you spend long > trying to get it to work? How does the wxGLCanvas demo work for you? I'm going to do a bit more investigation; currently the wxGLCanvas demo doesn't work at all - it may be an installation problem. And no, I didn't spend much time on wx; it seemed strange that a wx-based demo (from OpenGLContext, IIRC) worked poorly (but ran), when a GLUT-based version of the same just flew on my 550Mhz, Radeon, OS X 10.2 Powerbook. Bob Ippolito, thanks for posting the Makefile and other info. It doesn't sound promising if Togl is being dropped elsewhere, though. Bill Weiland From bob at redivi.com Tue Oct 14 16:14:27 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 14 16:15:07 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: Message-ID: <03012834-FE83-11D7-8F46-000A95686CD8@redivi.com> On Tuesday, Oct 14, 2003, at 14:38 America/New_York, Drew McCormack wrote: >> Along the same lines, ObjC doesn't have a short way to say anything >> (no operators). Probably my favorite feature of Python are strings, >> lists and dicts, with all the great __setitem__/__getitem__ stuff to >> go with it. In ObjC, a+b never means anything useful, unless a and b >> are primitive C types.. that's obnoxious, because you'd have to say >> a.add_(b) or something like that... Imagine writing an equation like >> that. > Well, I have a different view of operator overloading. I think it is > generally unnecessary, and can even have negative effects. The problem > is, a lot of people don't know what is happening behind the scenes. If > you have a matrix expression in C++ like this > > a = b * c + d > > you are creating two temporary objects. This has lead to the dismal > performance of C++ in number crunching in the past. > At least in Objective-C, it is explicit: Yes, for doing math using custom types and creating temporary objects is kind of stupid. What you really want for that kind of math is to describe an operation and then apply the operation to a set of objects in such a way that doesn't create a bunch of useless temporary sludge. I'm sure there's some languages out there that do stuff like this (implicitly or explicitly) but I've never seen one that's mainstream. What I really meant were things like descriptors, sequences, slices, dicts, callable objects, etc. These are all generally very elegant in Python (once you get over __this__). >> Sure, in ObjC you can use int, long, float, double.. but what about >> equivalents to Python's long or complex? > ?? > typedef struct _Complex { > double real, imag; > } Complex; 's abs() can't take a _Complex. It's just not treated as nicely as the my-processor-understands-these-natively number types by the standard library. You can't add two _Complex with a + either. > Where I prefer Obj-C/Cocoa: > Possibility of static typing (makes large programs more readable, and > catches a few bugs at compile time) > Design of libraries. Cocoa is beautifully designed and stable. I have > the feeling python's libs have evolved in a less stable way. With each > new release of python, things get replaced, indicating they weren't > that well done the first time round. Explicit static typing is ok, sometimes, I just don't like to have to do it and I don't like to explicitly cast things all the time. Usually the only time I want to do it is for performance reasons (static typing of non-objects). What *really* bugs me about static typing in languages like C# is that you have to explicitly cast things from object to another type, even though it's an absolutely worthless convention for catching legitimately mismatched types at compile time. This sort of thing happens ALL the time when you're working with data structures like hash tables. Ideally static typing should be more like it is in ML. Cocoa is well designed and stable, but it's a GUI framework. Python doesn't really have one of those that doesn't inherit the warts from whichever underlying C/C++ library it's talking to. The exception, of course, is PyObjC which talks to Cocoa and doesn't come standard with very many warts. Apple has made good frameworks and bad frameworks (or at least, they release incomplete ones that a lot of people are using). The Authorization framework for example is a chore to use (in the way that they show you how to use it, at least) and allows for a few opportunities to hijack a file that's about to be given suid root, although they are difficult to pull off. Their installation framework kinda sucks, and often gives /Library g+w admin, which means that you can put arbitrary will-run-as-root-next-time-you-boot code in /Library/StartupItems as an administrator... This is a pretty big (read: almost Microsoft-like) security hole and will require changes to the frameworks (both implementation and interface) that they just haven't done yet. Personally, I think /Library/StartupItems scripts should be run as whichever user owns the bundle, which would solve that problem even if /Library had junked permissions, but would break a lot of existing software that needs startup items. A workaround for this is pretty easy though, on startup it could warn the user that "Warning: The following startup items wish to be run with full permissions but have not yet been granted access. If one of these startup items has malicious code, and you run it, you're screwed. Click this button if you would like to authorize any of them. Note that authorization requires an administrator login and password." That said, Apple code probably gets more eyes on it and more stringent review Python code. A lot of Python code I've seen in the wild looks like first-thing-that-worked prototypes, and this includes code in the standard library. I generally try and look at the source for Python libraries before I try and use them for anything. If the implementation or interface sucks, I'll probably find another one that does the same thing, try and help fix it, or write my own (either full replacement, or subset of it that's designed to do what I need). I can't do that with (some) Apple frameworks, although in many cases I'd like to. -bob From helloleo at netspace.net.au Tue Oct 14 23:04:33 2003 From: helloleo at netspace.net.au (helloleo) Date: Tue Oct 14 23:04:29 2003 Subject: [Pythonmac-SIG] tkinter on aqua? // pyhtonlauncher useful? Message-ID: <029d01c392c9$19526d60$a800000a@Odyssey.local> hi there i'm new to the list and new to macpython. two things i don't understand: - downloaded macpython and tried one of the tkinter demo. the don't work. do i have to download tkinter seperatly? does tkinter runs under aqua? - on my mac are three python binaries in different locations. which one should i bind to pythonlauncher? is pythonlauncher a useful utility? thanks for advice, leo From patrickjmoran at earthlink.net Tue Oct 14 23:20:10 2003 From: patrickjmoran at earthlink.net (Patrick Moran) Date: Tue Oct 14 23:20:12 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk In-Reply-To: Message-ID: <7BAEC2D5-FEBE-11D7-A606-000A95A4EC40@earthlink.net> Hi, I dipped my toe into wxPython ... on my Linux box at work, to start with. The wxGLCanvas demo works fine there. That's probably not news, but I decided to begin on the box I'm more familiar with. Next I'll try my luck with wxGLCanvas on my PowerBook. Pat On Tuesday, October 14, 2003, at 01:04 PM, bweiland@chisystems.com wrote: > > Responding to two messages (from Andrew and Bob): > > Andrew Straw wrote: > > > Recently, the maintainer of PyOpenGL has indicated that he's > dropping > > Togl support (for Windows?) in the next release due to high > maintenance > > requirements and limited usage. Not to discourage you from > working on > > Togl, but I therefore think Tk may not be your best long-term > > cross-platform solution for OpenGL + GUI unless someone is willing > to > > take over python/togl maintenance in general (and on the Mac in > specific). > > > > I'm surprised you haven't had good luck with wx. Did you spend > long > > trying to get it to work? How does the wxGLCanvas demo work for > you? > > I'm going to do a bit more investigation; currently the wxGLCanvas > demo doesn't work at all - it may be an installation problem. And no, > I > didn't spend much time on wx; it seemed strange that a wx-based demo > (from > OpenGLContext, IIRC) worked poorly (but ran), when a GLUT-based > version of > the same just flew on my 550Mhz, Radeon, OS X 10.2 Powerbook. > > Bob Ippolito, thanks for posting the Makefile and other info. It > doesn't sound promising if Togl is being dropped elsewhere, though. > > Bill Weiland > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From gherman at darwin.in-berlin.de Wed Oct 15 03:43:24 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Wed Oct 15 03:43:06 2003 Subject: [Pythonmac-SIG] FYI: Spy.app Message-ID: <419268BE-FEE3-11D7-8D8A-00039345C610@darwin.in-berlin.de> A cool freeware app for sprints etc... Dinu "Spy allows you to run a server on your Mac, that when accessed by any normal web browser, allows people to see a snapshot of your screen, as well as information about your Macintosh. But it does not stop there - they can look at a normal static image, or they can look at your screen, live, continously updated, in real-time!" http://www.silvernetwork.net/products/spy From Jack.Jansen at cwi.nl Wed Oct 15 05:49:19 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 15 05:49:10 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <7BC9932E-FE63-11D7-8CC9-00039363BC02@mac.com> Message-ID: On Tuesday, October 14, 2003, at 06:28 PM, Drew McCormack wrote: >> The inspiration for this came from Evan Jones' implementation in >> Objective-C, which is, of course, several times larger than the >> code above, especially since it involves more than only this one >> method: > As an fan of Obj-C, I can't really let this go unanswered. There seems > quite a bit of animosity toward Obj-C from python programmers, and I > don't really understand why. I think Dinu was just a bit overenthusiastic about Python here:-) And I agree: ObjC is a pretty neat language. The merging of Smalltalk and C looks pretty clunky at first sight, but if you see the amount of power they packed into the language with only very few extensions to C it's impressive. Compare that to C++ with its utterly baroque set of C extensions.... brrrr:-( > Along these lines, has anyone ever 'hacked' the python interpreter to > do smalltalk like messaging, with segmented names? I've been tempted > to try it myself. You wouldn't think it would be that hard. Maybe just > an extra stage to convert segmented names to underscored ones, the > same way that PyObjC names methods. But I'm no python expert, so I > don't know what would be involved. I've been thinking about it. And the nice thing is that "[" cannot currently occur as the start symbol for an expression, and I think a NAME after an expression is also safe, so adding rules like atom: '[' test methodarg* ']' methodarg: NAME ':' test should work... But getting Guido to incorporate this into the language is a different story:-) -- 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 drewmccormack at mac.com Wed Oct 15 06:00:46 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Wed Oct 15 06:01:11 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: Message-ID: <727041C4-FEF6-11D7-BF2E-00039363BC02@mac.com> >> Along these lines, has anyone ever 'hacked' the python interpreter to >> do smalltalk like messaging, with segmented names? I've been tempted >> to try it myself. You wouldn't think it would be that hard. Maybe >> just an extra stage to convert segmented names to underscored ones, >> the same way that PyObjC names methods. But I'm no python expert, so >> I don't know what would be involved. > > I've been thinking about it. And the nice thing is that "[" cannot > currently > occur as the start symbol for an expression, and I think a NAME after > an > expression is also safe, so adding rules like > atom: '[' test methodarg* ']' > methodarg: NAME ':' test > should work... > > But getting Guido to incorporate this into the language is a different > story:-) Sure, I don't expect the whole python world to switch to smalltalk method naming just because I like it ;-) It would be fun to see though, if not practical. drew ---------------------------------- Dr. Drew McCormack Trade Strategist (www.trade-strategist.com) Stock Market strategy design platform for Mac OS X. From gherman at darwin.in-berlin.de Wed Oct 15 06:33:10 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Wed Oct 15 06:32:56 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <727041C4-FEF6-11D7-BF2E-00039363BC02@mac.com> Message-ID: Drew McCormack: >> I've been thinking about it. And the nice thing is that "[" cannot >> currently >> occur as the start symbol for an expression, and I think a NAME after >> an >> expression is also safe, so adding rules like >> atom: '[' test methodarg* ']' >> methodarg: NAME ':' test >> should work... >> >> But getting Guido to incorporate this into the language is a >> different story:-) > Sure, I don't expect the whole python world to switch to smalltalk > method naming just because I like it ;-) It would be fun to see > though, if not practical. Whether ObjC brackets or C++/Python dot notation, there is no reason except taste to favour one over the other... Yes, maybe the more general method arguments in the former. If the Python GOAT had felt like it, we might have some syntax today like: one = Number(initWithInt:1) result = one(add:five andBeepWhenDone) while keeping comma-seperated args for functions, but anyway. Obviously we don't... The power is not in the square brackets, but in the method names, which is also why ST has only five keywords, or so. Maybe porting Trade Strategist to Python would be an inter- esting experience for you? ;-) BTW, www.trade-strategist.com is down... Dinu -- Dinu C. Gherman ...................................................................... "An age is called Dark, not because the light fails to shine, but because people refuse to see it." (James Michener) From oussoren at cistron.nl Wed Oct 15 06:35:33 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 15 06:35:33 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: References: Message-ID: <4E6D62BA-FEFB-11D7-A624-0003931CFE24@cistron.nl> On 15 okt 2003, at 11:49, Jack Jansen wrote: > >> Along these lines, has anyone ever 'hacked' the python interpreter to >> do smalltalk like messaging, with segmented names? I've been tempted >> to try it myself. You wouldn't think it would be that hard. Maybe >> just an extra stage to convert segmented names to underscored ones, >> the same way that PyObjC names methods. But I'm no python expert, so >> I don't know what would be involved. > > I've been thinking about it. And the nice thing is that "[" cannot > currently > occur as the start symbol for an expression, and I think a NAME after > an > expression is also safe, so adding rules like > atom: '[' test methodarg* ']' > methodarg: NAME ':' test > should work... I'm probably very dense, but isn't '[' the start of a list literal or list comprehension and therefore a valid start of an expression or statement?. Using angled brackets might work, but would introduce ambiguties: # This works fine y> # Oops Compound brackets might work, e.g. [@NSPoint pointWithX:x andY:y @], but are pretty ugly. > > But getting Guido to incorporate this into the language is a different > story:-) This would be a pretty cool hack, and it would solve the major aesthetic problem of PyObjC: the ugly method names. Ronald From drewmccormack at mac.com Wed Oct 15 06:51:20 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Wed Oct 15 06:51:29 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: Message-ID: <82A99E5C-FEFD-11D7-BF2E-00039363BC02@mac.com> > > Maybe porting Trade Strategist to Python would be an inter- > esting experience for you? ;-) BTW, www.trade-strategist.com > is down... Thanks for pointing this out: the site is up, but bloody Yahoo forgot to renew my domain name. As for porting to python: it's probably a bit late for that. I have around 20000 lines. Even if this is 10000 lines of python, it is still a lot of work. If it is any consolation, I might write TS in python with PyObjC if I were to begin the project now. Drew ---------------------------------- Dr. Drew McCormack Trade Strategist (www.trade-strategist.com) Stock Market strategy design platform for Mac OS X. From mwh at python.net Wed Oct 15 08:14:15 2003 From: mwh at python.net (Michael Hudson) Date: Wed Oct 15 08:13:20 2003 Subject: [Pythonmac-SIG] forking in python In-Reply-To: (William McLendon's message of "Tue, 14 Oct 2003 12:19:28 -0600") References: Message-ID: <2mk776snoo.fsf@starship.python.net> "William McLendon" writes: > I've got a script where I want to fork one child thread that goes off > to execute a sequence of other scripts, using popen or whatever. I > don't care what it uses to launch them, but it needs to be something > that serializes all the launches. > > I can get it working, but it looks like the main thread blocks till > after the child thread is finished running all the processes in its > tasklist. > > How can I make this so that the main thread doesn't block? I'd like > it to be able to do other stuff during this time. Not sure I understand, but aren't things like spawn*(P_NOWAIT, ...), wait() and waitpid() what you're looking for? Cheers, mwh -- if-you-need-your-own-xxx.py-you-know-where-to-shove-it-ly y'rs - tim -- Tim Peters dishes out versioning advice on python-dev From Jack.Jansen at cwi.nl Wed Oct 15 09:06:47 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 15 09:06:13 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <4E6D62BA-FEFB-11D7-A624-0003931CFE24@cistron.nl> Message-ID: <6E936103-FF10-11D7-B273-0030655234CE@cwi.nl> On Wednesday, October 15, 2003, at 12:35 PM, Ronald Oussoren wrote: >> I've been thinking about it. And the nice thing is that "[" cannot >> currently >> occur as the start symbol for an expression, and I think a NAME after >> an >> expression is also safe, so adding rules like >> atom: '[' test methodarg* ']' >> methodarg: NAME ':' test >> should work... > > I'm probably very dense, but isn't '[' the start of a list literal or > list comprehension and therefore a valid start of an expression or > statement?. No, it is *me* who is dense. Jack: open mouth, insert foot:-) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Wed Oct 15 09:17:02 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 15 09:16:30 2003 Subject: [Pythonmac-SIG] tkinter on aqua? // pyhtonlauncher useful? In-Reply-To: <029d01c392c9$19526d60$a800000a@Odyssey.local> Message-ID: On Wednesday, October 15, 2003, at 05:04 AM, helloleo wrote: > hi there > > i'm new to the list and new to macpython. > > two things i don't understand: > - downloaded macpython and tried one of the tkinter demo. the don't > work. do > i have to download tkinter seperatly? does tkinter runs under aqua? Yes. But the good news is you can download it through the PackageManager. And while it (the Package Manager) can't download and install AquaTk for you (which you also need) it does know that it's missing and point you to the correct website. > - on my mac are three python binaries in different locations. which one > should i bind to pythonlauncher? is pythonlauncher a useful utility? /usr/local/bin/python is a symlink to /Library/Frameworks/Python.framework/Versions/Current/bin/python, and these are the normal Python interpreter that comes with MacPython. pythonw is a script that runs a slightly different interpreter from that framework, and this is needed to run scripts that use GUI stuff, but it can also be used for running normal scripts. /usr/bin/python is a different beast: this is the python 2.2 that Apple includes with 10.2. And PythonLauncher does one thing only: it allows you to double-click Python scripts in the Finder. If you never do that that forget about PythonLauncher. -- 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 Wed Oct 15 09:21:02 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 09:21:36 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <6E936103-FF10-11D7-B273-0030655234CE@cwi.nl> Message-ID: <6C2FD2F2-FF12-11D7-882A-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 09:06 America/New_York, Jack Jansen wrote: > > On Wednesday, October 15, 2003, at 12:35 PM, Ronald Oussoren wrote: > >>> I've been thinking about it. And the nice thing is that "[" cannot >>> currently >>> occur as the start symbol for an expression, and I think a NAME >>> after an >>> expression is also safe, so adding rules like >>> atom: '[' test methodarg* ']' >>> methodarg: NAME ':' test >>> should work... >> >> I'm probably very dense, but isn't '[' the start of a list literal or >> list comprehension and therefore a valid start of an expression or >> statement?. > > No, it is *me* who is dense. Jack: open mouth, insert foot:-) Surely it would be theoretically parsable with no class between list literals or comprehensions.. you wouldn't have commas, or if you did, they would be after a colon.. and you wouldn't have the keywords "for" or "in". It probably wouldn't fit very well into the Python parser though. -bob From bob at redivi.com Wed Oct 15 09:40:25 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 09:41:04 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <6C2FD2F2-FF12-11D7-882A-000A95686CD8@redivi.com> Message-ID: <21879420-FF15-11D7-882A-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 09:21 America/New_York, Bob Ippolito wrote: > > On Wednesday, Oct 15, 2003, at 09:06 America/New_York, Jack Jansen > wrote: > >> >> On Wednesday, October 15, 2003, at 12:35 PM, Ronald Oussoren wrote: >> >>>> I've been thinking about it. And the nice thing is that "[" cannot >>>> currently >>>> occur as the start symbol for an expression, and I think a NAME >>>> after an >>>> expression is also safe, so adding rules like >>>> atom: '[' test methodarg* ']' >>>> methodarg: NAME ':' test >>>> should work... >>> >>> I'm probably very dense, but isn't '[' the start of a list literal >>> or list comprehension and therefore a valid start of an expression >>> or statement?. >> >> No, it is *me* who is dense. Jack: open mouth, insert foot:-) > > Surely it would be theoretically parsable with no class between list > literals or comprehensions.. you wouldn't have commas, or if you did, > they would be after a colon.. and you wouldn't have the keywords "for" > or "in". It probably wouldn't fit very well into the Python parser > though. no clash between list literals, I mean. Also every message would be an invalid list or list comprehension because of the space between the receiver and the first component of the selector. -bob From oussoren at cistron.nl Wed Oct 15 10:02:10 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 15 10:02:11 2003 Subject: [Pythonmac-SIG] NSTableView and NSOutlineView backgrounds In-Reply-To: <21879420-FF15-11D7-882A-000A95686CD8@redivi.com> References: <21879420-FF15-11D7-882A-000A95686CD8@redivi.com> Message-ID: <2BA6ACDA-FF18-11D7-A624-0003931CFE24@cistron.nl> On 15 okt 2003, at 15:40, Bob Ippolito wrote: > > On Wednesday, Oct 15, 2003, at 09:21 America/New_York, Bob Ippolito > wrote: > >> >> On Wednesday, Oct 15, 2003, at 09:06 America/New_York, Jack Jansen >> wrote: >> >>> >>> On Wednesday, October 15, 2003, at 12:35 PM, Ronald Oussoren wrote: >>> >>>>> I've been thinking about it. And the nice thing is that "[" cannot >>>>> currently >>>>> occur as the start symbol for an expression, and I think a NAME >>>>> after an >>>>> expression is also safe, so adding rules like >>>>> atom: '[' test methodarg* ']' >>>>> methodarg: NAME ':' test >>>>> should work... >>>> >>>> I'm probably very dense, but isn't '[' the start of a list literal >>>> or list comprehension and therefore a valid start of an expression >>>> or statement?. >>> >>> No, it is *me* who is dense. Jack: open mouth, insert foot:-) >> >> Surely it would be theoretically parsable with no class between list >> literals or comprehensions.. you wouldn't have commas, or if you did, >> they would be after a colon.. and you wouldn't have the keywords >> "for" or "in". It probably wouldn't fit very well into the Python >> parser though. > > no clash between list literals, I mean. > > Also every message would be an invalid list or list comprehension > because of the space between the receiver and the first component of > the selector. There's also the useability of this options, code like the example below "feel" like lists in Python. foo = [app beginSheet: mySheet modalForWindow: self.docWindow modalDelegate: self didEndSelector: "sheetDidEnd:" contextInfo: None ] Actually, this feels more like a dict than a list. It definitly does not shout 'methodcall' at me. BTW. Another option for segemented method names would be: foo = app( 'beginSheet:', mySheet, 'modalForWindow:', window, ... ) This requires not changes to the language, is implementable today and is ugly. A possible implemenation would the methohd below to ObjC classes and instances: def __call__(self, *args): # Python 2.3 only, no error-checking and no varargs methods keys = args[::2] actualArgs = args[1::2] mname = (''.join(keys)).replace(':', '_') return getattr(self, mname)(*actualArgS) The obvious change to app(beginSheet=mySheet, ...) would need changes to the language to preserve the order of arguments. Ronald From ben at mitchellfamily.com Mon Oct 13 19:20:36 2003 From: ben at mitchellfamily.com (Ben Mitchell) Date: Wed Oct 15 10:29:10 2003 Subject: [Pythonmac-SIG] ABAddressBook interface from Python? In-Reply-To: <79283F00-FDD1-11D7-AB86-000A95A4EC40@earthlink.net> References: <79283F00-FDD1-11D7-AB86-000A95A4EC40@earthlink.net> Message-ID: <1066087236.3f8b33440c37e@www.mitchellfamily.com> Hi Folks, Has anyone spent any time trying to access OS X's Address Book (ABAddressBook) through Python? I want to write some programs to allow me to merge mine back and forth with my web-exposed address book, and it'd certainly be easier to do in Python than C++... I haven't ever fiddled around with SWIG, but would that be the way to go here? Has anyone out there already built a SWIG Python module for accessing the Address Book? Thanks in advance... -Ben From bob at redivi.com Wed Oct 15 10:41:57 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 10:42:30 2003 Subject: [Pythonmac-SIG] ABAddressBook interface from Python? In-Reply-To: <1066087236.3f8b33440c37e@www.mitchellfamily.com> Message-ID: On Monday, Oct 13, 2003, at 19:20 America/New_York, Ben Mitchell wrote: > Hi Folks, > > Has anyone spent any time trying to access OS X's Address Book > (ABAddressBook) > through Python? I want to write some programs to allow me to merge > mine back > and forth with my web-exposed address book, and it'd certainly be > easier to do > in Python than C++... > > I haven't ever fiddled around with SWIG, but would that be the way to > go here? > Has anyone out there already built a SWIG Python module for accessing > the > Address Book? It's part of PyObjC ( http://pyobjc.sf.net/ ) - there's even a simple example in the Examples folder of the source distribution, with an ObjC version of the example for comparison. -bob From oussoren at cistron.nl Wed Oct 15 10:42:59 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 15 10:43:00 2003 Subject: [Pythonmac-SIG] ABAddressBook interface from Python? In-Reply-To: <1066087236.3f8b33440c37e@www.mitchellfamily.com> References: <79283F00-FDD1-11D7-AB86-000A95A4EC40@earthlink.net> <1066087236.3f8b33440c37e@www.mitchellfamily.com> Message-ID: PyObjC includes a wrapper for the AddressBook framework. Ronald From bob at redivi.com Wed Oct 15 13:32:55 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 13:33:31 2003 Subject: [Pythonmac-SIG] What's MacPython missing? Message-ID: <9C75F35E-FF35-11D7-9E91-000A95686CD8@redivi.com> I'm interested to know what people here would like to see for MacPython. Which modules from other platforms would you really like to see? Which Apple APIs/Frameworks would you like to use but aren't wrapped or aren't wrapped satisfactorily? What documentation do you think needs to be written/improved (specifically)? These are a few of the things I'm interested in: Easy to use ARB_VERTEX_PROGRAM support for PyOpenGL (something like a hybrid of ShaderBuilder and DrawBot) A numarray-esque syntax -> ARB_VERTEX_PROGRAM compiler (Cg *still* isn't available for the Mac, and ATI's RenderMonkey is DirectX) An optimized PPC backend for Psyco (I'm kind of working on this on and off.. at the PPC ASM compiler/decompiler stage) Better CoreAudio/AudioUnits support, here are some interesting projects I've seen: http://arrowtheory.com/software/hypersonic/index.html http://www.icculus.org/al_osx/ (Highly optimized partial OpenAL implementation) http://www.stolk.info/alpy/ (this is a GPL binding for OpenAL.. probably a poor license choice) Better use of AltiVec in numarray (especially vec_perm stuff.. very useful for byteswapped arrays and converting bitmaps) Some crazy bridge that lets you write Contextual Menu PlugIns in Python (eww, COM.. this might be a job for ctypes and an embedded Python?) A better PackageManager / distutils Fully functional SciPy / VTK / MayaVi PyQt for Qt/Mac A relatively bug free version of wxPython that's not noticeably slow ;) Stackless on Python 2.3 (I know, this doesn't really have anything to do specifically with MacPython, but it would be more useful to us if it was on the Python 2.3 codebase) A version of PIL (or something like it) that's updated for Python 2.2+ features and uses a more sensible storage mechanism (i.e. something that isn't hardcoded to do RGB/RGBX/RGBA only). I think leveraging the SDL libraries would be good for this, as they can deal with all kinds of bitmaps (arbitrary bit shifts for channels). I'd like to see the storage used actually be addressable directly as a numarray (pygame sort of does this, but not quite adequately). Would be nice of Apple open sourced the SWIG wrapper for CoreGraphics they wrote (included with vendor installed Python in MacOS X 10.3), the bgen wrapper is missing a LOT of useful stuff from there. A smarter version of bgen or something bgen-like that was more generic about the kind of C it could understand, and more modern about the wrappers it spit out (keyword arguments, new style types with initializers, etc). Potentially it could even preserve documentation from the original code, it would be relatively straightforward to do that with most (new?) Apple headers. Maybe even a version that spit out ctypes wrappers instead. -bob From larry.bugbee at boeing.com Wed Oct 15 13:44:28 2003 From: larry.bugbee at boeing.com (Bugbee, Larry) Date: Wed Oct 15 13:45:52 2003 Subject: [Pythonmac-SIG] What's MacPython missing? Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779020D6997@xch-nw-29.nw.nos.boeing.com> The nuisance item at the top of my list is.... a site-packages link. In the same way as we have links in Python.framework for Headers and Resources to their equivalents in the 'current' version, I'd like to see a link to the 'current' site-packages. This would provide a simple programmatic way to get there without first having to determine which is the current version and construct the path accordingly. Specialized, and perhaps further down the list is Orange, a machine learning/data mining library. http://magix.fri.uni-lj.si/orange/ Larry -----Original Message----- From: Bob Ippolito [mailto:bob@redivi.com] Sent: Wednesday, October 15, 2003 10:33 AM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] What's MacPython missing? I'm interested to know what people here would like to see for MacPython. Which modules from other platforms would you really like to see? Which Apple APIs/Frameworks would you like to use but aren't wrapped or aren't wrapped satisfactorily? What documentation do you think needs to be written/improved (specifically)? [snip] From larry.bugbee at boeing.com Wed Oct 15 13:47:01 2003 From: larry.bugbee at boeing.com (Bugbee, Larry) Date: Wed Oct 15 13:47:49 2003 Subject: [Pythonmac-SIG] What's MacPython missing? Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779023B7B2E@xch-nw-29.nw.nos.boeing.com> PS: Did M2Crypto make the list? -----Original Message----- From: Bugbee, Larry Sent: Wednesday, October 15, 2003 10:44 AM To: 'Bob Ippolito'; pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] What's MacPython missing? The nuisance item at the top of my list is.... a site-packages link. In the same way as we have links in Python.framework for Headers and Resources to their equivalents in the 'current' version, I'd like to see a link to the 'current' site-packages. This would provide a simple programmatic way to get there without first having to determine which is the current version and construct the path accordingly. Specialized, and perhaps further down the list is Orange, a machine learning/data mining library. http://magix.fri.uni-lj.si/orange/ Larry -----Original Message----- From: Bob Ippolito [mailto:bob@redivi.com] Sent: Wednesday, October 15, 2003 10:33 AM To: pythonmac-sig@python.org Subject: [Pythonmac-SIG] What's MacPython missing? I'm interested to know what people here would like to see for MacPython. Which modules from other platforms would you really like to see? Which Apple APIs/Frameworks would you like to use but aren't wrapped or aren't wrapped satisfactorily? What documentation do you think needs to be written/improved (specifically)? [snip] From Larry.A.Meyn at nasa.gov Wed Oct 15 14:19:22 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Oct 15 14:19:27 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <9C75F35E-FF35-11D7-9E91-000A95686CD8@redivi.com> Message-ID: <19B8C96E-FF3C-11D7-AFCE-000A95A06CF6@nasa.gov> SciPy and Chaco would be desireable. I'm looking for a nice cross-platform way to make plots. Right now I'm using graphite/piddle, but they no longer seem to be in active development. On Wednesday, October 15, 2003, at 10:32 AM, Bob Ippolito wrote: > I'm interested to know what people here would like to see for > MacPython. > Which modules from other platforms would you really like to see? > Which Apple APIs/Frameworks would you like to use but aren't wrapped > or aren't wrapped satisfactorily? > What documentation do you think needs to be written/improved > (specifically)? > > These are a few of the things I'm interested in: > Easy to use ARB_VERTEX_PROGRAM support for PyOpenGL (something like a > hybrid of ShaderBuilder and DrawBot) > A numarray-esque syntax -> ARB_VERTEX_PROGRAM compiler (Cg *still* > isn't available for the Mac, and ATI's RenderMonkey is DirectX) > > An optimized PPC backend for Psyco (I'm kind of working on this on > and off.. at the PPC ASM compiler/decompiler stage) > > Better CoreAudio/AudioUnits support, here are some interesting > projects I've seen: > http://arrowtheory.com/software/hypersonic/index.html > http://www.icculus.org/al_osx/ (Highly optimized partial OpenAL > implementation) > http://www.stolk.info/alpy/ (this is a GPL binding for OpenAL.. > probably a poor license choice) > > Better use of AltiVec in numarray (especially vec_perm stuff.. very > useful for byteswapped arrays and converting bitmaps) > > Some crazy bridge that lets you write Contextual Menu PlugIns in > Python (eww, COM.. this might be a job for ctypes and an embedded > Python?) > > A better PackageManager / distutils > > Fully functional SciPy / VTK / MayaVi > > PyQt for Qt/Mac > > A relatively bug free version of wxPython that's not noticeably slow > ;) > > Stackless on Python 2.3 (I know, this doesn't really have anything to > do specifically with MacPython, but it would be more useful to us if > it was on the Python 2.3 codebase) > > A version of PIL (or something like it) that's updated for Python > 2.2+ features and uses a more sensible storage mechanism (i.e. > something that isn't hardcoded to do RGB/RGBX/RGBA only). I think > leveraging the SDL libraries would be good for this, as they can deal > with all kinds of bitmaps (arbitrary bit shifts for channels). I'd > like to see the storage used actually be addressable directly as a > numarray (pygame sort of does this, but not quite adequately). > > Would be nice of Apple open sourced the SWIG wrapper for CoreGraphics > they wrote (included with vendor installed Python in MacOS X 10.3), > the bgen wrapper is missing a LOT of useful stuff from there. > > A smarter version of bgen or something bgen-like that was more > generic about the kind of C it could understand, and more modern about > the wrappers it spit out (keyword arguments, new style types with > initializers, etc). Potentially it could even preserve documentation > from the original code, it would be relatively straightforward to do > that with most (new?) Apple headers. Maybe even a version that spit > out ctypes wrappers instead. > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3315 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031015/7ee0974d/attachment.bin From wildpixel at mac.com Wed Oct 15 14:20:13 2003 From: wildpixel at mac.com (Daniel Lord) Date: Wed Oct 15 14:20:32 2003 Subject: [Pythonmac-SIG] Objective C and Cocoa Message-ID: <3860EF46-FF3C-11D7-96C5-003065F37370@mac.com> After listening to an off topic discussion of ObjC for a few days, I have to weigh in with a point none have really covered. Elegant? Yes. Labor-saving? Yes. But I still won't use them--ever. I don't use them and don't care about them any more than I care about Microsoft's single platform proprietary frameworks and languages. I reject all single platform solutions because I never know which platform I might want to run my code on and I am not even sure whether I'll continue with OSX or move to Linux in a couple of years. I realize this is personal preference and opinion, but I have read enough of that about ObjC lately in this forum to feel I can speak also. In my view, language idiosyncracies can always be worked around: every engineer has to compromise on tools and it is usually driven by the platform choice. The language rarely drives the paltform choice--it is the other way around. So arguing the merits of the languages ObjC and Python is, to my way of thinking, far less important than standards and ubiquity. Portability and reusability are paramount and ObjC and Cocoa get an F in that just like .NET. Python gets an A-plus and, despite disliking Tk, it is my language of choice and has little competition on the horizon at this time. I do wish Tk coudl be replaced by somethign better--but no good cross-platform GUI has come up yet. I have no use for a tool, no matter how clever or powerful, if I cannot take it and the things I build with it with me. Apple should have done a better job in tool selection: in time ObjC and Cocoa will be marginalized and that will be a shame for Aqua and other great Apple developments. From Larry.A.Meyn at nasa.gov Wed Oct 15 14:22:43 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Oct 15 14:22:48 2003 Subject: [Pythonmac-SIG] PackageManager Scrolling Problem Message-ID: <91BC980C-FF3C-11D7-AFCE-000A95A06CF6@nasa.gov> I've noticed in accessing Bob Ippolito's extensive package list, that you can't scroll to the bottom of the list and have it stay there. Has anyone else had this problem or it is something with my setup? Larry Meyn Aerospace Operations Modeling Office M/S 210-10 NASA Ames Research Center Moffett Field, CA 94035-1000 E-mail: Larry.A.Meyn@nasa.gov Phone: (650) 604-5038 Fax: (650) 604-0222 E-Fax: (425) 944-5526 sent via e-mail From bob at redivi.com Wed Oct 15 14:36:37 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 14:37:13 2003 Subject: [Pythonmac-SIG] Objective C and Cocoa In-Reply-To: <3860EF46-FF3C-11D7-96C5-003065F37370@mac.com> Message-ID: <8266615B-FF3E-11D7-9E91-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 14:20 America/New_York, Daniel Lord wrote: > After listening to an off topic discussion of ObjC for a few days, I > have to weigh in with a point none have really covered. > > Elegant? Yes. Labor-saving? Yes. But I still won't use them--ever. I > don't use them and don't care about them any more than I care about > Microsoft's single platform proprietary frameworks and languages. I > reject all single platform solutions because I never know which > platform I might want to run my code on and I am not even sure whether > I'll continue with OSX or move to Linux in a couple of years. I > realize this is personal preference and opinion, but I have read > enough of that about ObjC lately in this forum to feel I can speak > also. In my view, language idiosyncracies can always be worked around: > every engineer has to compromise on tools and it is usually driven by > the platform choice. The language rarely drives the paltform > choice--it is the other way around. So arguing the merits of the > languages ObjC and Python is, to my way of thinking, far less > important than standards and ubiquity. Portability and reusability are > paramount and ObjC and Cocoa get an F in that just like .NET. Python > gets an A-plus and, despite disliking Tk, it is my language of choice > and has little competition on the horizon at this time. I do wish Tk > coudl be replaced by somethign better--but no good cross-platform GUI > has come up yet. > > I have no use for a tool, no matter how clever or powerful, if I > cannot take it and the things I build with it with me. Apple should > have done a better job in tool selection: in time ObjC and Cocoa will > be marginalized and that will be a shame for Aqua and other great > Apple developments. GNUStep makes your rant pretty worthless. The are outstanding issues though: PyObjC doesn't support GNUStep yet (needs a volunteer or some of Ronald's time) Cocoa nib files are not directly portable to GNUStep (and vice versa, I guess, I think there's go-between tools though) - Renaissance which lets you do interfaces in XML and works on both GNUStep and Cocoa (I have used it, it works), but you can't use Apple's nice tool GNUStep isn't so hot on win32 yet Honestly, I don't care if it's a closed source single platform framework. What I care about is getting stuff done as elegantly and effortlessly as possible on the platform of my choice. Kludge sucks. But in any case, there's GNUStep, so in theory in the near future (as near as we, the open source community, make it) all this stuff would work on Linux and (with some work on the win32 port of GNUStep) win32. As far as your 'F' goes for .NET, that's unfair too -- there's Mono, and the Rotor project (Microsoft's Shared Source .NET implementation, I don't believe it has the GUI stuff though). Mono works on linux/x86 and can probably be hacked to work on OS X/ppc, though they don't officially support it (yet). Rotor works on FreeBSD, win32, OS X and can probably be hacked to work on Linux. -bob From bob at redivi.com Wed Oct 15 14:54:31 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 14:55:25 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <8CFC81BC2CC2A74F88BAB7180F00B779023B7B2E@xch-nw-29.nw.nos.boeing.com> Message-ID: <02E2CF84-FF41-11D7-9E91-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 13:47 America/New_York, Bugbee, Larry wrote: > PS: Did M2Crypto make the list? I just got M2Crypto to compile.. I had to hack the SWIG .i files and remove a lot of "const", add the rc5 methods and remove the aes methods.. but I can put that in my Package Manager repository and post the modified source later today. -bob From oussoren at cistron.nl Wed Oct 15 14:59:53 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 15 14:59:52 2003 Subject: [Pythonmac-SIG] Objective C and Cocoa In-Reply-To: <8266615B-FF3E-11D7-9E91-000A95686CD8@redivi.com> References: <8266615B-FF3E-11D7-9E91-000A95686CD8@redivi.com> Message-ID: On 15 okt 2003, at 20:36, Bob Ippolito wrote: > > On Wednesday, Oct 15, 2003, at 14:20 America/New_York, Daniel Lord > wrote: [rant about not using Cocoa and other platform-dependend libaries removed] > GNUStep makes your rant pretty worthless. The are outstanding issues > though: > PyObjC doesn't support GNUStep yet (needs a volunteer or some of > Ronald's time) I'm getting closer, at the moment more of the tests pass but I've broken some of the code because the unittests no longer pass on OSX (hurray for unittests!). The good news is that the different compiler-environment already helped me find some errors in the error-handling code. > Cocoa nib files are not directly portable to GNUStep (and vice versa, > I guess, I think there's go-between tools though) - Renaissance which > lets you do interfaces in XML and works on both GNUStep and Cocoa (I > have used it, it works), but you can't use Apple's nice tool > GNUStep isn't so hot on win32 yet There's also a GNUstep tool to convert NIB files to gmodel files. > > Honestly, I don't care if it's a closed source single platform > framework. What I care about is getting stuff done as elegantly and > effortlessly as possible on the platform of my choice. Kludge sucks. > But in any case, there's GNUStep, so in theory in the near future (as > near as we, the open source community, make it) all this stuff would > work on Linux and (with some work on the win32 port of GNUStep) win32. I don't care too much about having GNUstep available for when I'd like to move to Linux. AFAIK the GNUstep folks want to recreate NeXTstep, without much integration in the dominant desktop environments. GUI programs should contain of a portable core and a platform dependent GUI layer on top of that, this makes it a lot easier to make the look&feel just right for a given platform. wxWindows and other x-platform toolkits get close, but it is often noticeable that a GUI was developed on a foreign platform. Ronald From bob at redivi.com Wed Oct 15 14:59:50 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 15:00:50 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <8CFC81BC2CC2A74F88BAB7180F00B779020D6997@xch-nw-29.nw.nos.boeing.com> Message-ID: On Wednesday, Oct 15, 2003, at 13:44 America/New_York, Bugbee, Larry wrote: > The nuisance item at the top of my list is.... a site-packages link. > > In the same way as we have links in Python.framework for Headers and > Resources to their equivalents in the 'current' version, I'd like to > see a link to the 'current' site-packages. This would provide a > simple programmatic way to get there without first having to determine > which is the current version and construct the path accordingly. > > Specialized, and perhaps further down the list is Orange, a machine > learning/data mining library. http://magix.fri.uni-lj.si/orange/ (disclaimer: never used Orange, don't really know much about it) OrangeWidgets is dependent on PyQt.. I don't know if you need that for it to be useful though, but PyQt definitely does not exist for Qt/Mac yet. As far as locating site-packages programmatically goes.. [crack:~] bob% python -c "import distutils.sysconfig;print distutils.sysconfig.get_python_lib()" /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages -bob From oussoren at cistron.nl Wed Oct 15 15:12:55 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 15 15:12:53 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <9C75F35E-FF35-11D7-9E91-000A95686CD8@redivi.com> References: <9C75F35E-FF35-11D7-9E91-000A95686CD8@redivi.com> Message-ID: <94C19408-FF43-11D7-A624-0003931CFE24@cistron.nl> On 15 okt 2003, at 19:32, Bob Ippolito wrote: > I'm interested to know what people here would like to see for > MacPython. > Which modules from other platforms would you really like to see? Twisted? ;-) > Which Apple APIs/Frameworks would you like to use but aren't wrapped > or aren't wrapped satisfactorily? The API for detecting location changes. The exact API slips my mind at the moment, but I've used the corresponding command-line tool to change parts of the system configuration when moving between home and the office. That script didn't survive, but I'd like to reintroduce something like that (if only to turn of fetching mail in Mail.app when I'm at a location where I cannot access the internet). > A better PackageManager / distutils And a nicer IDE. > > A relatively bug free version of wxPython that's not noticeably slow > ;) I'm having problems even compiling wxMac at the moment (using GCC 3.3 on Panther). That's a little bit annoying because one of my collegues uses wxPython. > > Would be nice of Apple open sourced the SWIG wrapper for CoreGraphics > they wrote (included with vendor installed Python in MacOS X 10.3), > the bgen wrapper is missing a LOT of useful stuff from there. Fixing the bgen wrappers might be more usefull. Ronald From etienne at cs.vu.nl Wed Oct 15 15:19:24 2003 From: etienne at cs.vu.nl (Etienne Posthumus) Date: Wed Oct 15 15:19:28 2003 Subject: [Pythonmac-SIG] PackageManager Scrolling Problem In-Reply-To: <91BC980C-FF3C-11D7-AFCE-000A95A06CF6@nasa.gov> References: <91BC980C-FF3C-11D7-AFCE-000A95A06CF6@nasa.gov> Message-ID: On Wed, 15 Oct 2003, Larry Meyn wrote: > I've noticed in accessing Bob Ippolito's extensive package list, that > you can't scroll to the bottom of the list and have it stay there. Has > anyone else had this problem or it is something with my setup? I have it too, it's not unique to your setup. EP From bob at redivi.com Wed Oct 15 15:31:55 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 15:32:30 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <94C19408-FF43-11D7-A624-0003931CFE24@cistron.nl> Message-ID: <3C2768E2-FF46-11D7-9E91-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 15:12 America/New_York, Ronald Oussoren wrote: > > On 15 okt 2003, at 19:32, Bob Ippolito wrote: > >> I'm interested to know what people here would like to see for >> MacPython. >> Which modules from other platforms would you really like to see? > > Twisted? ;-) Twisted works just fine, that's my job (I'm the OS X maintainer), definitely let me know if you have any problems with it, or even better make an issue at http://twistedmatrix.com/bugs and assign it to me (etrepum). The new CoreFoundation integration is extremely cool ;) Twisted 1.1 is just around the corner and will come with it. >> Which Apple APIs/Frameworks would you like to use but aren't wrapped >> or aren't wrapped satisfactorily? > The API for detecting location changes. The exact API slips my mind at > the moment, but I've used the corresponding command-line tool to > change parts of the system configuration when moving between home and > the office. That script didn't survive, but I'd like to reintroduce > something like that (if only to turn of fetching mail in Mail.app when > I'm at a location where I cannot access the internet). Probably in SystemConfiguration somewhere. I'll look into it. >> A better PackageManager / distutils > And a nicer IDE. Oh definitely, a couple people are working on this apparently. Just has some nice looking stuff in DrawBot that would be a good basis for an IDE. What I really want to see as far as an IDE goes is a good class browser, help viewer, and graphical debugger. This doesn't really bother me so much, because I code in Vim, but it's an issue for a lot of people. >> Would be nice of Apple open sourced the SWIG wrapper for >> CoreGraphics they wrote (included with vendor installed Python in >> MacOS X 10.3), the bgen wrapper is missing a LOT of useful stuff from >> there. > > Fixing the bgen wrappers might be more usefull. But that's definitely harder ;) -bob From kevino at tulane.edu Wed Oct 15 15:29:31 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed Oct 15 15:34:46 2003 Subject: [Pythonmac-SIG] Objective C and Cocoa In-Reply-To: Message-ID: Hi Ronald, On Wednesday, October 15, 2003, at 11:59 AM, Ronald Oussoren wrote: > > On 15 okt 2003, at 20:36, Bob Ippolito wrote: [snip comments about GNUStep portability] >> >> Honestly, I don't care if it's a closed source single platform >> framework. What I care about is getting stuff done as elegantly and >> effortlessly as possible on the platform of my choice. Kludge sucks. >> But in any case, there's GNUStep, so in theory in the near future >> (as near as we, the open source community, make it) all this stuff >> would work on Linux and (with some work on the win32 port of GNUStep) >> win32. > > I don't care too much about having GNUstep available for when I'd like > to move to Linux. AFAIK the GNUstep folks want to recreate NeXTstep, > without much integration in the dominant desktop environments. > > GUI programs should contain of a portable core and a platform > dependent GUI layer on top of that, this makes it a lot easier to make > the look&feel just right for a given platform. wxWindows and other > x-platform toolkits get close, but it is often noticeable that a GUI > was developed on a foreign platform. Actually, you've hit on a good point here - one that has to deal with the developer (and the platform they're comfortable with) rather than the tools themselves. The real problem is not that wxWindows can't be used to write a solid Mac application (though yes it still needs tweaks and bug fixes to make it OS X optimized), the problem is that the developers using the toolkit don't know what interface paradigms (i.e. MDI) work on platform X but not on platform Y. So when writing behaviors, they tend to lean towards the same behaviors that exist on their primary platform. I think the solution here is that there needs to be a cross-platform "HIG" like the one Apple has for Mac, so that the developers know that by using certain interface elements or implementing certain behaviors that they aren't committing a no-no on any particular platform. IMHO, wxWindows is close enough that it's in 'bug fix' mode to tweak any problems that arise, as well as optimizing code to take advantage of Mac-only features whenever possible. The only major control that doesn't do the right thing on Mac, that I know of, is the wxListCtrl, which needs to be have its internal implementation moved to the DataBrowserControl instead of the ListCtrl that Mac classic/carbon uses. The main reason I'm so keen on wxWindows is that other toolkits commonly have the problem that they were *written* specifically for one platform, then ported to another. (Often using 'themes' to mimic look - ugh.) Portability wasn't necessarily an initial goal, but people started saying "Oh, can I run this on platform Y too?". Thus even though they run on other platforms, there are a lot of internal assumptions in the code which make it not really portable. *nix apps tend to follow Windows conventions to some extent so the change isn't so dramatic, but when porting a *nix toolkit to Mac or vice versa, it is bound to at least feel strange on the other platform. wxWindows is by far the closest thing I know of to something that "does the right thing". Thanks, Kevin From kevino at tulane.edu Wed Oct 15 15:40:12 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed Oct 15 15:45:20 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <94C19408-FF43-11D7-A624-0003931CFE24@cistron.nl> Message-ID: <64B20ECC-FF47-11D7-B1D5-000393CB1C86@tulane.edu> Hi, On Wednesday, October 15, 2003, at 12:12 PM, Ronald Oussoren wrote: [snip] >> >> A relatively bug free version of wxPython that's not noticeably slow >> ;) > > I'm having problems even compiling wxMac at the moment (using GCC 3.3 > on Panther). That's a little bit annoying because one of my collegues > uses wxPython. Are you using CVS or the 2.4.2 build? You might want to send a message to wx-dev@lists.wxwindows.org with your problem. Some folks there I believe get Panther seeds. I, unfortunately, won't be able to help with this for another 9 days, 7 hours, 20 minutes... (Assuming Apple really does deliver Python on the evening of the 24th. ;-) The wxPython binary installer should probably work on Panther as well though, if you want to try that. Also, I second the idea of improving wxPython, of course. =) Thanks, Kevin From oussoren at cistron.nl Wed Oct 15 15:52:00 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Wed Oct 15 15:51:57 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <64B20ECC-FF47-11D7-B1D5-000393CB1C86@tulane.edu> References: <64B20ECC-FF47-11D7-B1D5-000393CB1C86@tulane.edu> Message-ID: <0ABC9DE8-FF49-11D7-A624-0003931CFE24@cistron.nl> On 15 okt 2003, at 21:40, Kevin Ollivier wrote: > Hi, > > On Wednesday, October 15, 2003, at 12:12 PM, Ronald Oussoren wrote: > > [snip] > >>> >>> A relatively bug free version of wxPython that's not noticeably >>> slow ;) >> >> I'm having problems even compiling wxMac at the moment (using GCC 3.3 >> on Panther). That's a little bit annoying because one of my collegues >> uses wxPython. > > Are you using CVS or the 2.4.2 build? I downloaded wxPythonSrc-2.4.2.4 today, and that didn't work. I didn't try to debug the problem yet, I'll probably do so before contacting wx-dev. Ronald From bob at heeter.net Wed Oct 15 15:52:03 2003 From: bob at heeter.net (Bob Heeter) Date: Wed Oct 15 15:52:16 2003 Subject: [Pythonmac-SIG] Re: PackageManager Scrolling Problem Message-ID: Confirmation of this bug in PackMan: >From: Larry Meyn >Date: Wed, 15 Oct 2003 11:22:43 -0700 > >I've noticed in accessing Bob Ippolito's extensive package list, that you can't scroll to the bottom of the list and have it stay there. Has anyone else had this problem or it is something with my setup? I have the same problem. I'm running an older G3/500 PowerBook, which doesn't have a big enough screen to see Bob's whole list. :( (At the rate Bob's adding stuff, I expect the rest of you will get the same problem before long, no matter how big your monitor!) Software: vanilla OS X.2.8, vanilla MacPython 2.3. All I wanted to do was install piddle. After heroic efforts to make the PackMan window as large as possible, I managed to get piddle to show up on the bottom. Tangential comments after much lurking: (1) PackMan is a better name than PIMP for the Package Manager, especially for those of us old enough to have played the video game in the 80's. (2) The Python/Panther/Quartz angle could be big for me (but I'm small); my code uses Python/piddle to draw (sketch would be a better word) network maps as PDFs, and a more extensive graphical toolkit would help. -- Bob (a different Bob) -- Bob Heeter Livermore, California From larry.bugbee at boeing.com Wed Oct 15 15:51:15 2003 From: larry.bugbee at boeing.com (Bugbee, Larry) Date: Wed Oct 15 15:52:38 2003 Subject: [Pythonmac-SIG] What's MacPython missing? Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779020D69AB@xch-nw-29.nw.nos.boeing.com> I was thinking more of the convenience when working with make files. I have a workaround but it sure would be nice if it were cleaner. ...and now I have two. ;-) > The nuisance item at the top of my list is.... a site-packages link. > > In the same way as we have links in Python.framework for Headers and > Resources to their equivalents in the 'current' version, I'd like to > see a link to the 'current' site-packages. This would provide a > simple programmatic way to get there without first having to determine > which is the current version and construct the path accordingly. > > Specialized, and perhaps further down the list is Orange, a machine > learning/data mining library. http://magix.fri.uni-lj.si/orange/ (disclaimer: never used Orange, don't really know much about it) OrangeWidgets is dependent on PyQt.. I don't know if you need that for it to be useful though, but PyQt definitely does not exist for Qt/Mac yet. As far as locating site-packages programmatically goes.. [crack:~] bob% python -c "import distutils.sysconfig;print distutils.sysconfig.get_python_lib()" /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages -bob From marcus.h.mendenhall at vanderbilt.edu Wed Oct 15 15:54:59 2003 From: marcus.h.mendenhall at vanderbilt.edu (Marcus H. Mendenhall) Date: Wed Oct 15 15:55:51 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: Message-ID: <7521F886-FF49-11D7-9EE3-003065A81A70@vanderbilt.edu> > > From: Larry Meyn > Date: Wed Oct 15, 2003 1:19:22 PM America/Chicago > To: Bob Ippolito > Cc: pythonmac-sig@python.org > Subject: Re: [Pythonmac-SIG] What's MacPython missing? > > > SciPy and Chaco would be desireable. I'm looking for a nice > cross-platform way to make plots. Right now I'm using > graphite/piddle, but they no longer seem to be in active development. > I also used to use graphite/piddle for my graphics, but found another package which work very nicely: PyX. Look on sourceforge. PyX takes only very minor tweaking to get its setup.py to work. An important point of PyX is that it uses TeX for its text rendering, and so produces very pretty graphs very easily. It typically takes only about 1/10th the tweaking that graphite did to get beautiful output. However, because it uses TeX, it is a little slow, since each graph produced requires it to run TeX via a pipe. Realistically, this only takes a few seconds typically, even on my ancient 233MHz beige G3 at home, so it isn't too bad. Since I use the fink LaTeX package, I need to do: setenv CFLAGS -I/sw/include setenv LDFLAGS -L/sw/lib before running setup.py to get it to work properly, since it doesn't automatically look for fink packages. You might want to try it out. Marcus Mendenhall From larry.bugbee at boeing.com Wed Oct 15 16:02:12 2003 From: larry.bugbee at boeing.com (Bugbee, Larry) Date: Wed Oct 15 16:03:15 2003 Subject: [Pythonmac-SIG] What's MacPython missing? Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779023B7B33@xch-nw-29.nw.nos.boeing.com> The "Orange" I'm referring to is a machine learning/data mining/pattern recognition toolset. ...not related to any GUI widgets or PyQt. Totally different. For more info check out http://magix.fri.uni-lj.si/orange/ In it's space... very nice. Larry > Specialized, and perhaps further down the list is Orange, a machine > learning/data mining library. http://magix.fri.uni-lj.si/orange/ (disclaimer: never used Orange, don't really know much about it) OrangeWidgets is dependent on PyQt.. I don't know if you need that for it to be useful though, but PyQt definitely does not exist for Qt/Mac yet. As far as locating site-packages programmatically goes.. [crack:~] bob% python -c "import distutils.sysconfig;print distutils.sysconfig.get_python_lib()" /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages -bob From managan at llnl.gov Wed Oct 15 16:11:05 2003 From: managan at llnl.gov (Rob Managan) Date: Wed Oct 15 16:11:10 2003 Subject: [Pythonmac-SIG] Re: PackageManager Scrolling Problem In-Reply-To: References: Message-ID: At 12:52 PM -0700 10/15/03, Bob Heeter wrote: >Confirmation of this bug in PackMan: > >>From: Larry Meyn >>Date: Wed, 15 Oct 2003 11:22:43 -0700 >> >>I've noticed in accessing Bob Ippolito's extensive package list, >>that you can't scroll to the bottom of the list and have it stay >>there. Has anyone else had this problem or it is something with my >>setup? > >I have the same problem. I'm running an older G3/500 PowerBook, >which doesn't have a big enough screen to see Bob's whole list. :( >(At the rate Bob's adding stuff, I expect the rest of you will >get the same problem before long, no matter how big your monitor!) I see the same thing, but let me point out that if you select a line you can use the down arrow to move down through the list. Most of the information is replicated in the pane at the bottom, if no as succinctly. Not as satisfying but at least you can install things one by one if you need to!! -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808 From pecora at anvil.nrl.navy.mil Wed Oct 15 16:11:07 2003 From: pecora at anvil.nrl.navy.mil (Louis M. Pecora) Date: Wed Oct 15 16:11:21 2003 Subject: [Pythonmac-SIG] Plotting Packages (What's MacPython missing?) In-Reply-To: <7521F886-FF49-11D7-9EE3-003065A81A70@vanderbilt.edu> References: <7521F886-FF49-11D7-9EE3-003065A81A70@vanderbilt.edu> Message-ID: >I also used to use graphite/piddle for my graphics, but found another package which work very nicely: PyX. Look on sourceforge. > >PyX takes only very minor tweaking to get its setup.py to work. An important point of PyX is that it uses TeX for its text rendering, and so produces very pretty graphs very easily. It typically takes only about 1/10th the tweaking that graphite did to get beautiful output. However, because it uses TeX, it is a little slow, since each graph produced requires it to run TeX via a pipe. Realistically, this only takes a few seconds typically, even on my ancient 233MHz beige G3 at home, so it isn't too bad. Since I use the fink LaTeX >package, I need to do: >setenv CFLAGS -I/sw/include >setenv LDFLAGS -L/sw/lib > >before running setup.py to get it to work properly, since it doesn't automatically look for fink packages. > >You might want to try it out. > >Marcus Mendenhall Thanks, Marcus. This is good news. I still use Piddle, but in the system 9 'subspace' while running OS X. I'd like to move Python into the OS X world, but haven't found a replacement for Piddle (nice package, really, but neglected, it seems). -- Cheers, Lou Pecora From larry.bugbee at boeing.com Wed Oct 15 16:08:39 2003 From: larry.bugbee at boeing.com (Bugbee, Larry) Date: Wed Oct 15 16:12:48 2003 Subject: [Pythonmac-SIG] What's MacPython missing? Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779023B7B34@xch-nw-29.nw.nos.boeing.com> Apologies. My mistrake... I forgot Orange has Orange Widgets. (I've never used them, yet.) -----Original Message----- From: Bugbee, Larry Sent: Wednesday, October 15, 2003 1:02 PM To: Bob Ippolito Cc: pythonmac-sig@python.org Subject: RE: [Pythonmac-SIG] What's MacPython missing? The "Orange" I'm referring to is a machine learning/data mining/pattern recognition toolset. ...not related to any GUI widgets or PyQt. Totally different. For more info check out http://magix.fri.uni-lj.si/orange/ In it's space... very nice. Larry > Specialized, and perhaps further down the list is Orange, a machine > learning/data mining library. http://magix.fri.uni-lj.si/orange/ (disclaimer: never used Orange, don't really know much about it) OrangeWidgets is dependent on PyQt.. I don't know if you need that for it to be useful though, but PyQt definitely does not exist for Qt/Mac yet. As far as locating site-packages programmatically goes.. [crack:~] bob% python -c "import distutils.sysconfig;print distutils.sysconfig.get_python_lib()" /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Wed Oct 15 16:17:07 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 16:17:41 2003 Subject: [Pythonmac-SIG] Plotting Packages (What's MacPython missing?) In-Reply-To: Message-ID: <8CFEEC01-FF4C-11D7-9E91-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 16:11 America/New_York, Louis M. Pecora wrote: >> I also used to use graphite/piddle for my graphics, but found another >> package which work very nicely: PyX. Look on sourceforge. >> >> PyX takes only very minor tweaking to get its setup.py to work. An >> important point of PyX is that it uses TeX for its text rendering, >> and so produces very pretty graphs very easily. It typically takes >> only about 1/10th the tweaking that graphite did to get beautiful >> output. However, because it uses TeX, it is a little slow, since >> each graph produced requires it to run TeX via a pipe. >> Realistically, this only takes a few seconds typically, even on my >> ancient 233MHz beige G3 at home, so it isn't too bad. Since I use >> the fink LaTeX >> package, I need to do: >> setenv CFLAGS -I/sw/include >> setenv LDFLAGS -L/sw/lib >> >> before running setup.py to get it to work properly, since it doesn't >> automatically look for fink packages. >> >> You might want to try it out. >> >> Marcus Mendenhall > > Thanks, Marcus. This is good news. I still use Piddle, but in the > system 9 'subspace' while running OS X. I'd like to move Python into > the OS X world, but haven't found a replacement for Piddle (nice > package, really, but neglected, it seems). I did kinda port Piddle to OS X.. it's in my PackMan repository ( http://undefined.org/python/pimp/ ) or http://undefined.org/python/piddle-1.0.15-osx.tgz for source. It's not a port I'd swear by, but it should do just about everything the OS 9 one did. -bob From pecora at anvil.nrl.navy.mil Wed Oct 15 16:30:35 2003 From: pecora at anvil.nrl.navy.mil (Louis M. Pecora) Date: Wed Oct 15 16:30:56 2003 Subject: [Pythonmac-SIG] Plotting Packages (What's MacPython missing?) In-Reply-To: <8CFEEC01-FF4C-11D7-9E91-000A95686CD8@redivi.com> References: <8CFEEC01-FF4C-11D7-9E91-000A95686CD8@redivi.com> Message-ID: >I did kinda port Piddle to OS X.. it's in my PackMan repository ( http://undefined.org/python/pimp/ ) or http://undefined.org/python/piddle-1.0.15-osx.tgz for source. It's not a port I'd swear by, but it should do just about everything the OS 9 one did. > >-bob Thanks, also. Didn't know this. Will check it out. -- Cheers, Lou Pecora From Martina at Oefelein.de Wed Oct 15 17:12:02 2003 From: Martina at Oefelein.de (Martina Oefelein) Date: Wed Oct 15 17:12:19 2003 Subject: [Pythonmac-SIG] Objective C and Cocoa In-Reply-To: Message-ID: <38A9FBA2-FF54-11D7-B234-000A957DBE94@Oefelein.de> Hi Kevin, > The main reason I'm so keen on wxWindows is that other toolkits > commonly have the problem that they were *written* specifically for > one platform, then ported to another. (Often using 'themes' to mimic > look - ugh.) Portability wasn't necessarily an initial goal, but > people started saying "Oh, can I run this on platform Y too?". Thus > even though they run on other platforms, there are a lot of internal > assumptions in the code which make it not really portable. *nix apps > tend to follow Windows conventions to some extent so the change isn't > so dramatic, but when porting a *nix toolkit to Mac or vice versa, it > is bound to at least feel strange on the other platform. wxWindows is > by far the closest thing I know of to something that "does the right > thing". well, I must admit I haven't tried to use it yet, but the terminology and documentation I browsed so far feels rather Windows-ish. For example, "window" is encompassing controls and views as well as "real" windows (which are called "frames" in wxWindows). Other examples are SDI/MDI, per-window (pardon, per-frame) menus, right moues button, key names etc. That gives me (still) the impression of a "ported" toolkit and lets me wonder whether it would be possible to develop wxWindows apps using the Mac as main development platform. Thus I believe one would often have to think "backwards" to realize a particular feature - translating from Mac into (wx)Windows concepts and terminology, and hoping that wxWindows will translate this into the desired Mac look & behaviour. ciao Martina From Larry.A.Meyn at nasa.gov Wed Oct 15 17:42:17 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Oct 15 17:42:22 2003 Subject: [Pythonmac-SIG] Plotting Packages (What's MacPython missing?) In-Reply-To: <8CFEEC01-FF4C-11D7-9E91-000A95686CD8@redivi.com> Message-ID: <72A3B958-FF58-11D7-AFCE-000A95A06CF6@nasa.gov> On Wednesday, October 15, 2003, at 01:17 PM, Bob Ippolito wrote: > On Wednesday, Oct 15, 2003, at 16:11 America/New_York, Louis M. Pecora > wrote: > >>> I also used to use graphite/piddle for my graphics, but found >>> another package which work very nicely: PyX. Look on sourceforge. >>> >>> PyX takes only very minor tweaking to get its setup.py to work. An >>> important point of PyX is that it uses TeX for its text rendering, >>> and so produces very pretty graphs very easily. It typically takes >>> only about 1/10th the tweaking that graphite did to get beautiful >>> output. However, because it uses TeX, it is a little slow, since >>> each graph produced requires it to run TeX via a pipe. >>> Realistically, this only takes a few seconds typically, even on my >>> ancient 233MHz beige G3 at home, so it isn't too bad. Since I use >>> the fink LaTeX >>> package, I need to do: >>> setenv CFLAGS -I/sw/include >>> setenv LDFLAGS -L/sw/lib >>> >>> before running setup.py to get it to work properly, since it doesn't >>> automatically look for fink packages. >>> >>> You might want to try it out. >>> >>> Marcus Mendenhall >> >> Thanks, Marcus. This is good news. I still use Piddle, but in the >> system 9 'subspace' while running OS X. I'd like to move Python into >> the OS X world, but haven't found a replacement for Piddle (nice >> package, really, but neglected, it seems). > > I did kinda port Piddle to OS X.. it's in my PackMan repository ( > http://undefined.org/python/pimp/ ) or > http://undefined.org/python/piddle-1.0.15-osx.tgz for source. It's > not a port I'd swear by, but it should do just about everything the OS > 9 one did. > My thanks to Bob (and possibly others) for getting Piddle and graphite working on OS X. They both seem to have new setup.py files that work and the QuickDraw output has been resurrected. One thing I always liked about Piddle was the multiple choices for graphics output (PDF, QuickDraw, tk, etc.). Marcus, thanks for the info on PyX. --Larry From Jack.Jansen at cwi.nl Wed Oct 15 18:04:58 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 15 18:05:02 2003 Subject: [Pythonmac-SIG] Moderation is off again... Message-ID: <9DFDEB30-FF5B-11D7-9823-000A27B19B96@cwi.nl> Folks, the last few weeks all messages to the SIG that I had to approve manually were legitimate messages, so I've turned off the "only subscribers can post" option again. I'll turn it on again when the next virus hits, -- 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 Wed Oct 15 18:21:13 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 18:21:51 2003 Subject: [Pythonmac-SIG] ANN: DrawBot + Renaissance Message-ID: I went ahead and packed up my modified DrawBot (the one with widgets). More information and a link to download is on the pythonmac.org wiki: http://pythonmac.org/wiki/DrawBot Note that tarball includes the self-contained application, an unmodified binary build of GNUStep Renaissance, and all of DrawBot's source code. And yes, Just, I did borrow your moinmoin css ;) I hope you don't mind, I found yours to be much nicer and more readable than the mostly default style I was using previously. -bob From bob at redivi.com Wed Oct 15 20:24:34 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 20:25:55 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <3C2768E2-FF46-11D7-9E91-000A95686CD8@redivi.com> Message-ID: <1E3DEB92-FF6F-11D7-9E91-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 15:31 America/New_York, Bob Ippolito wrote: > On Wednesday, Oct 15, 2003, at 15:12 America/New_York, Ronald Oussoren > wrote: > >> On 15 okt 2003, at 19:32, Bob Ippolito wrote: >> >>> Which Apple APIs/Frameworks would you like to use but aren't >>> wrapped or aren't wrapped satisfactorily? >> The API for detecting location changes. The exact API slips my mind >> at the moment, but I've used the corresponding command-line tool to >> change parts of the system configuration when moving between home and >> the office. That script didn't survive, but I'd like to reintroduce >> something like that (if only to turn of fetching mail in Mail.app >> when I'm at a location where I cannot access the internet). > > Probably in SystemConfiguration somewhere. I'll look into it. My guess was right, it is the SystemConfiguration framework and the utility you were referring to is called "scutil" and is actually part of Darwin under APSL so it should be no problem to figure out how they're doing it. I'll do it this weekend if not sooner. -bob From robin at alldunn.com Wed Oct 15 20:49:59 2003 From: robin at alldunn.com (Robin Dunn) Date: Wed Oct 15 20:50:04 2003 Subject: [Pythonmac-SIG] Slow module loading revisited Message-ID: <3F8DEB37.4080607@alldunn.com> Hi all, Morgen and I spent a bunch of time today trying to figure out what is taking all the time when the wxPython extension module is being imported with MacPython-OSX. We've done some ktrace/kdumping and just like in a thread on Pythonmac-SIG from February[1] we are seeing about a six second delay just before HIToolbox is open()ed, although it was not after libcrypto in our case. (HIToolbox was also loaded a couple seconds before the delay with load_shared_file()...) We then set DYLD_TRACE and I wrote a script to decode the function calls it adds to a ktrace listing. It seems that there are many thousands of symbols that are being handled by dyld during that 6 second block of time (now expanded out to about 30 seconds because of all the logging.) Dyld is doing something (probably relocating/rebinding) with all those symbols at that time as we had supposed, but the surprise was that the wxWindows symbols are a very small fraction of the time, only about 7%. The bulk of the rest of the time is spent on what looks like Carbon symbols (at least I recognise a lot of them as Carbon APIs, the rest look like they might be internal stuff that the Carbon APIs themselves use...) As in [3] Morgen has tried rebuilding both Python and libwx_mac with and without prebinding, with no apparent change in the startup delay. Has there been any further enlightenment on this subject since February? Is the standard MacPython-OSX downloadable from Jack's page now built with or without prebinding? Any suggestions? [1]http://mail.python.org/pipermail/pythonmac-sig/2003-February/007309.html [2]http://mail.python.org/pipermail/pythonmac-sig/2002-December/006946.html [3]http://mail.python.org/pipermail/pythonmac-sig/2003-February/007313.html -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From helloleo at netspace.net.au Wed Oct 15 22:14:11 2003 From: helloleo at netspace.net.au (helloleo) Date: Wed Oct 15 22:13:59 2003 Subject: [Pythonmac-SIG] What's MacPython missing? References: <9C75F35E-FF35-11D7-9E91-000A95686CD8@redivi.com> Message-ID: <004a01c3938b$305b1a80$a800000a@Odyssey.local> hi there i don't know weather it's yet part of macpython or not, but i'd like to do automation of iTunes and iPhoto with python. maybe there's out there something like a wrapper object or so... cheers, leo ----- Original Message ----- From: "Bob Ippolito" To: Sent: Thursday, October 16, 2003 3:32 AM Subject: [Pythonmac-SIG] What's MacPython missing? > I'm interested to know what people here would like to see for MacPython. > Which modules from other platforms would you really like to see? > Which Apple APIs/Frameworks would you like to use but aren't wrapped > or aren't wrapped satisfactorily? > What documentation do you think needs to be written/improved > (specifically)? > > These are a few of the things I'm interested in: > Easy to use ARB_VERTEX_PROGRAM support for PyOpenGL (something like a > hybrid of ShaderBuilder and DrawBot) > A numarray-esque syntax -> ARB_VERTEX_PROGRAM compiler (Cg *still* > isn't available for the Mac, and ATI's RenderMonkey is DirectX) > > An optimized PPC backend for Psyco (I'm kind of working on this on and > off.. at the PPC ASM compiler/decompiler stage) > > Better CoreAudio/AudioUnits support, here are some interesting > projects I've seen: > http://arrowtheory.com/software/hypersonic/index.html > http://www.icculus.org/al_osx/ (Highly optimized partial OpenAL > implementation) > http://www.stolk.info/alpy/ (this is a GPL binding for OpenAL.. > probably a poor license choice) > > Better use of AltiVec in numarray (especially vec_perm stuff.. very > useful for byteswapped arrays and converting bitmaps) > > Some crazy bridge that lets you write Contextual Menu PlugIns in > Python (eww, COM.. this might be a job for ctypes and an embedded > Python?) > > A better PackageManager / distutils > > Fully functional SciPy / VTK / MayaVi > > PyQt for Qt/Mac > > A relatively bug free version of wxPython that's not noticeably slow ;) > > Stackless on Python 2.3 (I know, this doesn't really have anything to > do specifically with MacPython, but it would be more useful to us if it > was on the Python 2.3 codebase) > > A version of PIL (or something like it) that's updated for Python 2.2+ > features and uses a more sensible storage mechanism (i.e. something > that isn't hardcoded to do RGB/RGBX/RGBA only). I think leveraging the > SDL libraries would be good for this, as they can deal with all kinds > of bitmaps (arbitrary bit shifts for channels). I'd like to see the > storage used actually be addressable directly as a numarray (pygame > sort of does this, but not quite adequately). > > Would be nice of Apple open sourced the SWIG wrapper for CoreGraphics > they wrote (included with vendor installed Python in MacOS X 10.3), the > bgen wrapper is missing a LOT of useful stuff from there. > > A smarter version of bgen or something bgen-like that was more generic > about the kind of C it could understand, and more modern about the > wrappers it spit out (keyword arguments, new style types with > initializers, etc). Potentially it could even preserve documentation > from the original code, it would be relatively straightforward to do > that with most (new?) Apple headers. Maybe even a version that spit > out ctypes wrappers instead. > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From bob at redivi.com Wed Oct 15 22:39:34 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 15 22:40:11 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <004a01c3938b$305b1a80$a800000a@Odyssey.local> Message-ID: On Wednesday, Oct 15, 2003, at 22:14 America/New_York, helloleo wrote: > i don't know weather it's yet part of macpython or not, but i'd like > to do > automation of iTunes and iPhoto with python. maybe there's out there > something like a wrapper object or so... Your best bet for automating iTunes is to use aeve: http://undefined.org/python/#aeve I'm not sure if iPhoto is scriptable or not, but if it is then aeve would also be what you'd want to use. If it's not scriptable, you probably can't really automate it anyhow. -bob From bob at redivi.com Thu Oct 16 00:13:20 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 16 00:14:00 2003 Subject: [Pythonmac-SIG] Objective C and Cocoa In-Reply-To: Message-ID: <1376DBF5-FF8F-11D7-B559-000A95686CD8@redivi.com> On Wednesday, Oct 15, 2003, at 23:41 America/New_York, Kevin Ollivier wrote: > On Wednesday, October 15, 2003, at 02:12 PM, Martina Oefelein wrote: > >>> The main reason I'm so keen on wxWindows is that other toolkits >>> commonly have the problem that they were *written* specifically for >>> one platform, then ported to another. (Often using 'themes' to mimic >>> look - ugh.) Portability wasn't necessarily an initial goal, but >>> people started saying "Oh, can I run this on platform Y too?". Thus >>> even though they run on other platforms, there are a lot of internal >>> assumptions in the code which make it not really portable. *nix apps >>> tend to follow Windows conventions to some extent so the change >>> isn't so dramatic, but when porting a *nix toolkit to Mac or vice >>> versa, it is bound to at least feel strange on the other platform. >>> wxWindows is by far the closest thing I know of to something that >>> "does the right thing". >> >> well, I must admit I haven't tried to use it yet, but the terminology >> and documentation I browsed so far feels rather Windows-ish. For >> example, "window" is encompassing controls and views as well as >> "real" windows (which are called "frames" in wxWindows). Other >> examples are SDI/MDI, per-window (pardon, per-frame) menus, right >> moues button, key names etc. That gives me (still) the impression of >> a "ported" toolkit and lets me wonder whether it would be possible to >> develop wxWindows apps using the Mac as main development platform. >> >> Thus I believe one would often have to think "backwards" to realize a >> particular feature - translating from Mac into (wx)Windows concepts >> and terminology, and hoping that wxWindows will translate this into >> the desired Mac look & behaviour. > > There are a couple issues merged together here, so let me address them > individually: > > - terminology: Impressions/perceptions are hard to predict, and they > are largely based on the developer's predisposition and experiences. > (i.e. a developer who only/primarily develops on Mac will react to the > terminology differently than someone familiar with many platforms) It > is very true that wxWindows' terms may make some developers wonder if > it works or not as a Mac development tool; IMHO, the only issue is > whether or not they will take the time and effort to find out whether > or not their theory is correct. =) > > BTW, one can install wxPython and run the demo located at > /Applications/wxPythonOSX-2.4.x.x to see just about every major > wxWindows component in action. > > - functionality/paradigms: It's true that wxWindows supports the use > of some platform-specific paradigms, like per-frame menues. Developers > who care about Mac support will of course avoid them, and probably use > Mac-specific development practices as much as possible. If the > developer doesn't care about Mac support, it is fair to ask why they > shouldn't be allowed to use per-frame menues, for example. In that > sense, the pendulum swings both ways in that it is quite possible that > Mac-specific classes will be added to the Mac port, like wxDrawer, if > there's a demand for them. Also, Mac developers could just as easily > write ugly/bad applications using Carbon (and they do exist) if they > chose to ignore the Aqua HIG. wxWindows just makes Mac support *much* > simpler (and in some cases trivial) to implement. It's up to the > developer to decide whether or not they want Mac support. > > BTW, with regards to your specific points, it does properly interpret > CTRL+click as a right-click on Mac, as can be seen in the demo. And > since you can buy 2-button mice on Mac (and I use one) I don't think > talking about right clicks are totally inappropriate. =) It also > automatically does a number of other little things, like renames > "Exit" to "Quit" on Mac (for OS 9), lets you plug into the application > menu (on OS X) and changes CTRL+key shortcut keys to COMMAND+key on > Mac. > > Let me finally say that cross-platform applications can only be made > easier by a toolkit like wxWindows; there will not be a magic bullet > which makes it a non-issue. If I'm a developer who wants to optimize > for OS X (and I am =), I'll have to think about what I can do to make > my app more friendly to OS X users and focus on following the Apple > HIG. In any case, you are right that developers will need to 'think > different' when using a cross-platform toolkit, but in my experience > wxWindows is the best of the bunch when trying to make Mac-friendly > cross-platform applications. I think that the point that Ronald was trying to make earlier is that sometimes it's best to just develop multiple GUI frontends. It's definitely easier to develop a PyObjC+Cocoa application than a wxPython application assuming you like using OS X (subjective, but I don't think many of you will disagree). Cocoa encourages good model/view separation. So theoretically if you write it with Cocoa first, it shouldn't be terribly hard to write (or hope someone else writes) another frontend on top of that, whether that's wxWindows, GTK, or whatever. Nothing you've said so far leads me to believe that trying to make wxWindows fit both GUI paradigms (win32/linux and mac) is less effort than making wxWindows do what it does best (win32/linux) and spending the "mac thinking" time just writing a PyObjC/Cocoa frontend for Mac. wxWindows makes porting to the Mac easiest for people who don't own a Mac. In which case, they'll probably design it such that it's not consistent with the Apple HIG anyway. Of course, in some situations the application is more important than the interface, and the Mac user just won't care so much because it does what they need it to do. -bob From patrickjmoran at earthlink.net Thu Oct 16 01:58:02 2003 From: patrickjmoran at earthlink.net (Patrick Moran) Date: Thu Oct 16 01:59:49 2003 Subject: [Pythonmac-SIG] problem importing OpenGL.Tk In-Reply-To: <3F8B341F.2070809@insightscientific.com> Message-ID: Hi, I downloaded wxPython, and played with the demos from RunDemo. I tried the wxGLCanvas demo. Seemed a little balky to get the initial image in the window, but then seemed OK. (Balky meaning the rendering window starts blank, and I have to generate a bunch of mouse events before anything appears). Next step for me is to experiment some rendering my own data. Any helper apps for translating Tkinter to wxPython :-)? Pat On Monday, October 13, 2003, at 04:24 PM, Andrew Straw wrote: > Bob Ippolito wrote: > >> >> On Monday, Oct 13, 2003, at 11:22 America/New_York, >> bweiland@chisystems.com wrote: >> >>> >>> According to Bob Ippolito: >>> >>>> Unfortunately, you're out of luck. Togl has not been ported to OS X >>>> yet, at least not for AquaTk. I just took a look at Togl and it >>>> seems >>>> nontrivial to compile for OS X (at least a few hours). Your best >>>> bet >>>> is to get rid of your dependency on Tk altogether and switch to >>>> something like wxPython, pygame, GLUT, PyObjC + Cocoa, etc. for your >>>> GUI. >>> >>> Oddly enough, I was just going thru this same ordeal myself. >>> Tk, if >>> Togl worked, would probably still be the best option for portable >>> python >>> GUI's that need OpenGL stuff, IMHO. Here's why I think so (and not >>> trying >>> to start a flame war): >>> - tried wxPython - had weird problems with low framerate and >>> flicker >>> compared to just drawing in a GLUT window (maybe this was just me?); >>> besides, I like Tk better for a quick hacked-together interface; >>> - pygame - would be good, but pyui doesn't seem to be working yet >>> for GUI elements on OS X; >>> - GLUT - not really enough GUI; >>> - PyObjC - not portable, but otherwise nice; >>> - also, PyQt would be great, but the license is restrictive (it >>> precludes portability to Windows if you're using the GPL'ed version; >>> it's >>> expensive otherwise). >>> >>> Enough complaining -- I looked at trying to port it, but it >>> seemed >>> like a lot of time I can't spend right now (since I really don't >>> understand >>> how the whole Tk side of things is put together). If anyone can >>> provide >>> some pointers that could shorten the time, I might try. If anyone >>> is >>> inclined to do the port, there are at least two users who would want >>> it ;) >> >> >> I'll take a closer look at it later this week if I find the time. >> >> -bob > > > Recently, the maintainer of PyOpenGL has indicated that he's dropping > Togl support (for Windows?) in the next release due to high > maintenance requirements and limited usage. Not to discourage you > from working on Togl, but I therefore think Tk may not be your best > long-term cross-platform solution for OpenGL + GUI unless someone is > willing to take over python/togl maintenance in general (and on the > Mac in specific). > > I'm surprised you haven't had good luck with wx. Did you spend long > trying to get it to work? How does the wxGLCanvas demo work for you? > > Cheers! > Andrew > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bugbee at seanet.com Thu Oct 16 02:03:51 2003 From: bugbee at seanet.com (bugs) Date: Thu Oct 16 02:03:53 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <8CFC81BC2CC2A74F88BAB7180F00B779020D69AA@xch-nw-29.nw.nos.boeing.com> Message-ID: <83D5CA07-FF9E-11D7-A4F1-000393DB272E@seanet.com> Bob.... >> PS: Did M2Crypto make the list? > > I just got M2Crypto to compile.. I had to hack the SWIG .i files and > remove a lot of "const", add the rc5 methods and remove the aes > methods.. but I can put that in my Package Manager repository and post > the modified source later today. Interesting. That should work. I sense you built m2crypto-0.12-snap1 for Py2.3 to access Apple's OpenSSL 0.9.6i (Feb 19 2003), and if that's the case, you may want to so note in the install doc. I say that because I found messing with OpenSSL can be just that.... messy. If one is not careful, you can get dragged into having to fix a string of other dependencies on Apple's OpenSSL 0.9.6x. I wanted AES so I built m2crypto-0.12 for py23 to use OpenSSL 0.9.7c (30 Sep 2003) which I built and installed in /usr/local. ...and then built my M2Crypto around that. FWIW, I never got distutils/setup.py to emit the include files on the swig command line. I did some poking around and it seems there is a bug in lib/distutils/build_ext.py (at about line 531). Attempts to mod setup.py to include swig dirs fails. The dirs are not seen by build_ext.py, the dirs it does see are wrong, and NO include dirs make it to the swig command line. The workaround, fixing and running Makefile.osx, was successful. It sounds like we may be ready for distutils2. :-) Later, Larry From bob at redivi.com Thu Oct 16 02:21:57 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 16 02:22:34 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <83D5CA07-FF9E-11D7-A4F1-000393DB272E@seanet.com> Message-ID: <0B1C5530-FFA1-11D7-B559-000A95686CD8@redivi.com> On Thursday, Oct 16, 2003, at 02:03 America/New_York, bugs wrote: > Bob.... > >>> PS: Did M2Crypto make the list? >> >> I just got M2Crypto to compile.. I had to hack the SWIG .i files and >> remove a lot of "const", add the rc5 methods and remove the aes >> methods.. but I can put that in my Package Manager repository and post >> the modified source later today. > > Interesting. That should work. > > I sense you built m2crypto-0.12-snap1 for Py2.3 to access Apple's > OpenSSL 0.9.6i (Feb 19 2003), and if that's the case, you may want to > so note in the install doc. I say that because I found messing with > OpenSSL can be just that.... messy. Yeah, that's what I did. > If one is not careful, you can get dragged into having to fix a string > of other dependencies on Apple's OpenSSL 0.9.6x. I wanted AES so I > built m2crypto-0.12 for py23 to use OpenSSL 0.9.7c (30 Sep 2003) which > I built and installed in /usr/local. ...and then built my M2Crypto > around that. Ah.. well, if AES is needed then I'll have to do that, or depend on Panther (it includes AES). What do you think? > FWIW, I never got distutils/setup.py to emit the include files on the > swig command line. I did some poking around and it seems there is a > bug in lib/distutils/build_ext.py (at about line 531). Attempts to > mod setup.py to include swig dirs fails. The dirs are not seen by > build_ext.py, the dirs it does see are wrong, and NO include dirs make > it to the swig command line. The workaround, fixing and running > Makefile.osx, was successful. It sounds like we may be ready for > distutils2. :-) Yeah, well I took a different approach, I modified setup.py to run swig by hand (naive approach: swig nomatter what argv is.. real approach would be to make a fixed build_ext class, like Pyrex uses) and then I told distuils to treat the generated C wrapper as a regular C extension.. I didn't use the Makefile because it's just as easy for me to change a distutils script than it is to create a Makefile that builds with one particular version of Python. -bob From kevino at tulane.edu Thu Oct 16 02:52:32 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Thu Oct 16 02:57:07 2003 Subject: [Pythonmac-SIG] Objective C and Cocoa In-Reply-To: <1376DBF5-FF8F-11D7-B559-000A95686CD8@redivi.com> Message-ID: <514299B7-FFA5-11D7-B1D5-000393CB1C86@tulane.edu> Hi, On Wednesday, October 15, 2003, at 09:13 PM, Bob Ippolito wrote: [snip wxWindows comments] > > I think that the point that Ronald was trying to make earlier is that > sometimes it's best to just develop multiple GUI frontends. It's > definitely easier to develop a PyObjC+Cocoa application than a > wxPython application assuming you like using OS X (subjective, but I > don't think many of you will disagree). Cocoa encourages good > model/view separation. So theoretically if you write it with Cocoa > first, it shouldn't be terribly hard to write (or hope someone else > writes) another frontend on top of that, whether that's wxWindows, > GTK, or whatever. Nothing you've said so far leads me to believe that > trying to make wxWindows fit both GUI paradigms (win32/linux and mac) > is less effort than making wxWindows do what it does best > (win32/linux) and spending the "mac thinking" time just writing a > PyObjC/Cocoa frontend for Mac. To be honest, I doubt I could convince you as I think you're already sold on what approach you want to take, and considering your criteria for tools I think you chose what works best for you. I understand that. What I don't understand is that you debate the very usefulness of wxPython for Mac to anyone except "people who don't own Macs" or people who want a quick (and dirty) port to Mac. That, I think, is based more on how you feel about wxPython than anything else, but in any case contradicts my experiences with the wxPython developers I know of who are testing and tweaking their apps for Mac. As for your comment about 2-3 frontends being less work than a wxPython interface, I think that's highly subjective and depends on many factors, like the developer's familiarity with both tools, free time to work on the app, access to appropriate hardware and/or the kindness of others to port the application. In any case, since there's no one who actually has done this, I think this sort of debate would be pointless as it would be based on opinions only, not experience. I will say that I've never heard of having to learn two toolkits as being easier than learning one (i.e. Cocoa + wxWindows) so this would likely become a multi-person effort. > wxWindows makes porting to the Mac easiest for people who don't own a > Mac. In which case, they'll probably design it such that it's not > consistent with the Apple HIG anyway. Of course, in some situations > the application is more important than the interface, and the Mac user > just won't care so much because it does what they need it to do. I own two Macs, I've 'ported' (not really, wxPackageManager was built on Mac) two apps with wxPython, and in both cases they just ran on platforms other than what I designed them on, without my thinking they looked out of place or non-native. I'm having more trouble getting PIMP to run on Windows than anything else. ;-) (Dependencies on a couple command line apps that aren't available on Windows.) To convince me that PyObjC is the only real way to go for native Mac interfaces, you'd have to convince me (for example) that wxPackageManager is a poor interface for Mac that needs serious revising (not tweaking), that the interface problems are the result of the tools I use and not interface design mistakes on my part, and that re-writing it in PyObjC would solve all my problems, and have almost zero learning curve. Lastly, let me say that I'm not trying to argue that "wxPython is for everyone" or that "wxPython is superior" to PyObjC and I apologize if I gave anyone that impression. Such arguments are inherently pointless. It's all relative to the developer's needs. If I were developing Mac-only apps, I probably would be using PyObjC, but in the end all that matters is whether or not it can meet my needs/criteria. So when I promote wxPython, I'm not trying to win some battle or anything, I'm just sharing my own preferences and experiences with others in the hope that it may help some of them and maybe help wxPython or even Python as well. =) Kevin From gherman at darwin.in-berlin.de Thu Oct 16 07:00:55 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Thu Oct 16 07:00:43 2003 Subject: [Pythonmac-SIG] Konfabulator-like stuff, first shot Message-ID: <03DB13E7-FFC8-11D7-8098-00039345C610@darwin.in-berlin.de> Hi, this is probably just another overly enthusiastic pre-announce- ment, but it's just soo cool! I've converted my dusty TimeCycler screensaver into a Konfabulator-like Widget as a proof of concept rather than as anything else. But I do wonder how you'd write this as a pure Konfabulator widget in Javascript? - Brrrrr! ;-) Have a go at this binary if you like - DT means "desktop": http://python.net/~gherman/tmp/TimeCyclerDT.tar.gz Konfab,-watch-out'ly, Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "I once asked Ivan, 'How is it possible for you to have invented computer graphics, done the first object oriented software system and the first real time constraint solver all by yourself in one year?' And he said 'I didn't know it was hard.'" (Alan Kay on Ivan Sutherland) From mwh at python.net Thu Oct 16 07:40:20 2003 From: mwh at python.net (Michael Hudson) Date: Thu Oct 16 07:39:23 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <9C75F35E-FF35-11D7-9E91-000A95686CD8@redivi.com> (Bob Ippolito's message of "Wed, 15 Oct 2003 13:32:55 -0400") References: <9C75F35E-FF35-11D7-9E91-000A95686CD8@redivi.com> Message-ID: <2mad81s95n.fsf@starship.python.net> Bob Ippolito writes: > I'm interested to know what people here would like to see for MacPython. > Which modules from other platforms would you really like to see? > Which Apple APIs/Frameworks would you like to use but aren't > wrapped or aren't wrapped satisfactorily? > What documentation do you think needs to be written/improved > (specifically)? > > These are a few of the things I'm interested in: [...] > An optimized PPC backend for Psyco (I'm kind of working on > this on and off.. at the PPC ASM compiler/decompiler stage) Hey, me too! Armin was of the opinion that this would be seriously hard (i.e. about as hard as writing psyco for x86 was) until psyco is ready to become part of PyPy, though. [...] > A smarter version of bgen or something bgen-like that was more > generic about the kind of C it could understand, and more > modern about the wrappers it spit out (keyword arguments, new > style types with initializers, etc). Potentially it could > even preserve documentation from the original code, it would > be relatively straightforward to do that with most (new?) > Apple headers. Maybe even a version that spit out ctypes > wrappers instead. Do you know anything concrete about gcc-xml? Cheers, mwh -- But maybe I've just programmed in enough different languages to assume that they are, in fact, different. -- Tony J Ibbs explains why Python isn't Java on comp.lang.python From bob at redivi.com Thu Oct 16 09:49:17 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 16 09:49:54 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <2mad81s95n.fsf@starship.python.net> Message-ID: <891831AA-FFDF-11D7-B559-000A95686CD8@redivi.com> On Thursday, Oct 16, 2003, at 07:40 America/New_York, Michael Hudson wrote: > Bob Ippolito writes: > >> I'm interested to know what people here would like to see for >> MacPython. >> Which modules from other platforms would you really like to see? >> Which Apple APIs/Frameworks would you like to use but aren't >> wrapped or aren't wrapped satisfactorily? >> What documentation do you think needs to be written/improved >> (specifically)? >> >> These are a few of the things I'm interested in: > [...] >> An optimized PPC backend for Psyco (I'm kind of working on >> this on and off.. at the PPC ASM compiler/decompiler stage) > > Hey, me too! Armin was of the opinion that this would be seriously > hard (i.e. about as hard as writing psyco for x86 was) until psyco is > ready to become part of PyPy, though. I think having all those extra registers around, and the fact that most of the operations take a destination and two operands instead of just dest and src, might make it a bit nicer. But then again, the fact that Psyco was designed for x86 might mean that it would be hard to take advantage of. I really don't know, it's been a while since I've looked at the source. > [...] >> A smarter version of bgen or something bgen-like that was more >> generic about the kind of C it could understand, and more >> modern about the wrappers it spit out (keyword arguments, new >> style types with initializers, etc). Potentially it could >> even preserve documentation from the original code, it would >> be relatively straightforward to do that with most (new?) >> Apple headers. Maybe even a version that spit out ctypes >> wrappers instead. > > Do you know anything concrete about gcc-xml? I know that it's a real bitch to compile on OS X (but I did).. it's very odd. It must work to some degree because Pyste uses it, but I haven't taken a serious look at the output. It seems like one of those XML formats where you need to write a pretty significant translator from it to a data structure worth using. -bob From mwh at python.net Thu Oct 16 10:19:51 2003 From: mwh at python.net (Michael Hudson) Date: Thu Oct 16 10:18:55 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <891831AA-FFDF-11D7-B559-000A95686CD8@redivi.com> (Bob Ippolito's message of "Thu, 16 Oct 2003 09:49:17 -0400") References: <891831AA-FFDF-11D7-B559-000A95686CD8@redivi.com> Message-ID: <2m1xtds1rs.fsf@starship.python.net> Bob Ippolito writes: > On Thursday, Oct 16, 2003, at 07:40 America/New_York, Michael Hudson > wrote: > >> Bob Ippolito writes: >> >>> I'm interested to know what people here would like to see for >>> MacPython. >>> Which modules from other platforms would you really like to see? >>> Which Apple APIs/Frameworks would you like to use but aren't >>> wrapped or aren't wrapped satisfactorily? >>> What documentation do you think needs to be written/improved >>> (specifically)? >>> >>> These are a few of the things I'm interested in: >> [...] >>> An optimized PPC backend for Psyco (I'm kind of working on >>> this on and off.. at the PPC ASM compiler/decompiler stage) >> >> Hey, me too! Armin was of the opinion that this would be seriously >> hard (i.e. about as hard as writing psyco for x86 was) until psyco is >> ready to become part of PyPy, though. > > I think having all those extra registers around, and the fact that > most of the operations take a destination and two operands instead of > just dest and src, might make it a bit nicer. Oh sure. That wasn't what I meant. > But then again, the fact that Psyco was designed for x86 might mean > that it would be hard to take advantage of. I really don't know, > it's been a while since I've looked at the source. For one thing, I think there are some x86-isms in the source (e.g expecting stack based calling conventions) and for another the source is just a bitch. It certainly confused me plenty. [bgen2] >> Do you know anything concrete about gcc-xml? > > I know that it's a real bitch to compile on OS X (but I did).. it's > very odd. It must work to some degree because Pyste uses it, but I > haven't taken a serious look at the output. It seems like one of > those XML formats where you need to write a pretty significant > translator from it to a data structure worth using. Yeah, but less translating than from an arbitrary C header, right? . It would be depressing if gcc-xml sucked, because something like that is so obviously the right answer. Guess I should take a look myself... Cheers, mwh -- Need to Know is usually an interesting UK digest of things that happened last week or might happen next week. [...] This week, nothing happened, and we don't care. -- NTK Now, 2000-12-29, http://www.ntk.net/ From jpetrone at cnri.reston.va.us Thu Oct 16 13:09:06 2003 From: jpetrone at cnri.reston.va.us (Jason Petrone) Date: Thu Oct 16 13:09:11 2003 Subject: [Pythonmac-SIG] Re: [wxPython-mac] Slow module loading revisited In-Reply-To: <3F8DEB37.4080607@alldunn.com> References: <3F8DEB37.4080607@alldunn.com> Message-ID: <20031016170906.GA1818@cnri.reston.va.us> On Wed, Oct 15, 2003 at 05:49:59PM -0700, Robin Dunn wrote: > As in [3] Morgen has tried rebuilding both Python and libwx_mac with and > without prebinding, with no apparent change in the startup delay. Has > there been any further enlightenment on this subject since February? Is > the standard MacPython-OSX downloadable from Jack's page now built with > or without prebinding? Any suggestions? I was able to make some improvement in load time by linking the Carbon framework to the python executable, so it could be prebound. This was a while ago, and I forget all the steps involved, but one thing I had to do was compile wxMac with special flags to allow it to be loaded into a prebound python. Otherwise I would get a DYLD_DEBUG message like "can't load non-prebound library into prebound executable, disabling prebinding." Jason From marcus.h.mendenhall at vanderbilt.edu Thu Oct 16 13:15:14 2003 From: marcus.h.mendenhall at vanderbilt.edu (Marcus H. Mendenhall) Date: Thu Oct 16 13:15:47 2003 Subject: [Pythonmac-SIG] Python crash! In-Reply-To: Message-ID: <4E9A28FD-FFFC-11D7-83B4-003065A81A70@vanderbilt.edu> This is the first one of these I have seen in a while. I was running a program in the python IDE version: Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin IDE version 1.0.1 and hit Command-period to terminate the program. I got the following exciting result: ********** Date/Time: 2003-10-16 12:09:58 -0500 OS Version: 10.2.8 (Build 6R73) Host: mendenhall.fel.Vanderbilt.Edu Command: Python PID: 9368 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xf00fcee8 Thread 0 Crashed: #0 0x91ac2b5c in InternalDisplayChangedProc #1 0x90163230 in __CFRunLoopDoTimer #2 0x90148d28 in __CFRunLoopRun #3 0x90180f58 in CFRunLoopRunSpecific #4 0x969a3b70 in RunCurrentEventLoopInMode #5 0x969a41f4 in GetNextEventMatchingMask #6 0x969a8054 in WNEInternal #7 0x969adf0c in WaitNextEvent #8 0x001d8724 in init_Evt #9 0x10077090 in call_function (ceval.c:3440) #10 0x10074c68 in eval_frame (ceval.c:2117) #11 0x10075f80 in PyEval_EvalCodeEx (ceval.c:2663) #12 0x10077374 in fast_function (ceval.c:3529) #13 0x10077168 in call_function (ceval.c:3458) #14 0x10074c68 in eval_frame (ceval.c:2117) #15 0x10075f80 in PyEval_EvalCodeEx (ceval.c:2663) #16 0x10077374 in fast_function (ceval.c:3529) #17 0x10077168 in call_function (ceval.c:3458) #18 0x10074c68 in eval_frame (ceval.c:2117) #19 0x10075f80 in PyEval_EvalCodeEx (ceval.c:2663) #20 0x10077374 in fast_function (ceval.c:3529) #21 0x10077168 in call_function (ceval.c:3458) #22 0x10074c68 in eval_frame (ceval.c:2117) #23 0x10075f80 in PyEval_EvalCodeEx (ceval.c:2663) #24 0x10025a1c in function_call (funcobject.c:504) #25 0x1000c66c in PyObject_Call (abstract.c:1756) #26 0x10015afc in instancemethod_call (classobject.c:2433) #27 0x1000c66c in PyObject_Call (abstract.c:1756) #28 0x10076f24 in PyEval_CallObjectWithKeywords (ceval.c:3347) #29 0x1000edec in PyInstance_New (classobject.c:576) #30 0x1000c66c in PyObject_Call (abstract.c:1756) #31 0x10077498 in do_call (ceval.c:3644) #32 0x10077180 in call_function (ceval.c:3461) #33 0x10074c68 in eval_frame (ceval.c:2117) #34 0x10075f80 in PyEval_EvalCodeEx (ceval.c:2663) #35 0x10078df4 in PyEval_EvalCode (ceval.c:537) #36 0x100a9c54 in run_node (pythonrun.c:1206) #37 0x100a9400 in PyRun_SimpleFileExFlags (pythonrun.c:805) #38 0x100b5bd0 in Py_Main (main.c:415) #39 0x00001b5c in 0x1b5c #40 0x000019dc in 0x19dc PPC Thread State: srr0: 0x91ac2b5c srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x20000000 lr: 0x91ac2b48 ctr: 0x91ac2b3c mq: 0x00000000 r0: 0x90163230 r1: 0xbfffe200 r2: 0x44024244 r3: 0x000ea020 r4: 0xf00fcee8 r5: 0x00000000 r6: 0x00000001 r7: 0x00000000 r8: 0xa0131c4c r9: 0xa0001048 r10: 0x000449d0 r11: 0xa0132e30 r12: 0x91ac2b3c r13: 0x01cce63c r14: 0x00000000 r15: 0x00000001 r16: 0x00000000 r17: 0x00000000 r18: 0x24024244 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0xa1a52b48 r23: 0x000449a8 r24: 0x00000001 r25: 0xa01330f4 r26: 0x0000139d r27: 0xae987242 r28: 0xa0131674 r29: 0x000ea028 r30: 0xa1a5044c r31: 0x91ac2b48 The only slightly unusual thing about the program is that I was using signal handlers, which I haven't done a lot of before. Here is the program, for reference: from data_acquisition import LabPro_USB import time import Numeric import signal class mylabpro(LabPro_USB.LabPro_USB): def send_string(self, s='s', delay=0.05): #print s LabPro_USB.LabPro_USB.send_string(self, s, delay) keep_running=1 create_new_file=0 def handle_SIGINT(signum, frame): global keep_running keep_running=0 def handle_SIGHUP(signum, frame): global create_new_file create_new_file=1 def rt_test(): badloops=0 logfile=file("datagrab.txt","ab") lp=mylabpro(1) signal.signal(signal.SIGHUP, handle_SIGHUP) signal.signal(signal.SIGINT, handle_SIGINT) try: try: lp.wake() lp.reset() print lp.get_system_config() #just to vacuum the connection lp.setup_channel(chan=1, operation=1) #set up -10-10 volts readback #lp.setup_channel(chan=2, operation=1) #set up -10-10 volts readback #lp.setup_channel(chan=3, operation=14) #set up default 0-5 #lp.setup_channel(chan=4, operation=1) #set up default 0-5 #lp.setup_channel(chan=21, operation=1) #set up digital #lp.setup_channel(chan=22, operation=1) #set up digital lp.binary_mode(blocking_factor=1) samptime=0.101 lp.setup_data_collection(samptime=samptime, numpoints=-1, rectime=0) rtdata=[] starttime=time.time() laststamp=0.0 while(keep_running): time.sleep(0.01) newdata=lp.get_data_binary_realtime(channels=1) #rtdata+=newdata if newdata: timestamp=lp.data_timestamp fdata=Numeric.array(newdata,Numeric.Float) linevolts=lp.scale_binary_data(fdata[:,0],(-10.,10.)) #feedback=lp.scale_binary_data(fdata[:,1],(-10.,10.)) timevals=Numeric.add.accumulate(fdata[:,-1])+laststamp for i in range(len(newdata)): logfile.write("%.3f\t%.4f\t%.3f\n" % (timestamp, timevals[i], linevolts[i])) laststamp=timevals[-1] lp.stop() newdata=lp.get_data_binary_realtime(channels=1) finally: try: logfile.close() except: pass lp.close() except: import traceback traceback.print_exc() pass signal.signal(signal.SIGHUP, signal.SIG_DFL) signal.signal(signal.SIGINT, signal.SIG_DFL) rt_test() Anyone want to try to trace this down? Marcus Mendenhall From bob at redivi.com Thu Oct 16 13:26:15 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 16 13:26:53 2003 Subject: [Pythonmac-SIG] Python crash! In-Reply-To: <4E9A28FD-FFFC-11D7-83B4-003065A81A70@vanderbilt.edu> Message-ID: On Thursday, Oct 16, 2003, at 13:15 America/New_York, Marcus H. Mendenhall wrote: > This is the first one of these I have seen in a while. I was running > a program in the python IDE > --snip-- > The only slightly unusual thing about the program is that I was using > signal handlers, which I haven't done a lot of before. Here is the > program, for reference: --snip-- > Anyone want to try to trace this down? Python is not very good at signal handlers.. try not to use them, especially not in the IDE. They're just asking for trouble because signal handlers cause a condition that the interpreter isn't very capable of coping with. I would suggest attempting to do this in another way (i.e. using network sockets to ask your program to open a new file or quit). -bob From marcus.h.mendenhall at vanderbilt.edu Thu Oct 16 13:37:26 2003 From: marcus.h.mendenhall at vanderbilt.edu (Marcus H. Mendenhall) Date: Thu Oct 16 13:37:44 2003 Subject: [Pythonmac-SIG] Python crash! In-Reply-To: Message-ID: <688EBF0B-FFFF-11D7-83B4-003065A81A70@vanderbilt.edu> On Thursday, October 16, 2003, at 12:26 PM, Bob Ippolito wrote: > > On Thursday, Oct 16, 2003, at 13:15 America/New_York, Marcus H. > Mendenhall wrote: > >> This is the first one of these I have seen in a while. I was running >> a program in the python IDE >> > --snip-- >> The only slightly unusual thing about the program is that I was using >> signal handlers, which I haven't done a lot of before. Here is the >> program, for reference: > --snip-- >> Anyone want to try to trace this down? > > Python is not very good at signal handlers.. try not to use them, > especially not in the IDE. They're just asking for trouble because > signal handlers cause a condition that the interpreter isn't very > capable of coping with. I would suggest attempting to do this in > another way (i.e. using network sockets to ask your program to open a > new file or quit). > > -bob > > Thanks, Bob. Do you think the problem is specific to the IDE? Has trouble been actually seen outside of the IDE, or is it just a queasy feeling there that the Python interpreter is structured unsafely somewhere for signals? This program normally runs as a daemon, and I was just testing it in the IDE. Maybe that is why I have never seen the issue before? I may think about switching this to a different mechanism if there really is a reliability issue, even without the IDE, since I am starting work on a block of code I want to be VERY reliable. Marcus From bob at redivi.com Thu Oct 16 13:47:58 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 16 13:48:33 2003 Subject: [Pythonmac-SIG] Python crash! In-Reply-To: <688EBF0B-FFFF-11D7-83B4-003065A81A70@vanderbilt.edu> Message-ID: On Thursday, Oct 16, 2003, at 13:37 America/New_York, Marcus H. Mendenhall wrote: > > On Thursday, October 16, 2003, at 12:26 PM, Bob Ippolito wrote: > >> >> On Thursday, Oct 16, 2003, at 13:15 America/New_York, Marcus H. >> Mendenhall wrote: >> >>> This is the first one of these I have seen in a while. I was >>> running a program in the python IDE >>> >> --snip-- >>> The only slightly unusual thing about the program is that I was >>> using signal handlers, which I haven't done a lot of before. Here >>> is the program, for reference: >> --snip-- >>> Anyone want to try to trace this down? >> >> Python is not very good at signal handlers.. try not to use them, >> especially not in the IDE. They're just asking for trouble because >> signal handlers cause a condition that the interpreter isn't very >> capable of coping with. I would suggest attempting to do this in >> another way (i.e. using network sockets to ask your program to open a >> new file or quit). > > Do you think the problem is specific to the IDE? Has trouble been > actually seen outside of the IDE, or is it just a queasy feeling there > that the Python interpreter is structured unsafely somewhere for > signals? > > This program normally runs as a daemon, and I was just testing it in > the IDE. Maybe that is why I have never seen the issue before? > > I may think about switching this to a different mechanism if there > really is a reliability issue, even without the IDE, since I am > starting work on a block of code I want to be VERY reliable. The reason it's particularly problematic is that it doesn't really handle the signals when they happen, it puts the signal handler next in the bytecode queue. I've had problems with it as well, when I was in C code when it happened. This is probably what happened with you in the IDE. Chances are, if you're not using a C runloop (IDE or whatever) then you'll be OK.. but it may not be worth it. Personally, I would move it to another mechanism, besides.. using sockets instead of signals would get you better flexibility (remote control if you want it) and win32 compatibility (if you ever need it). -bob From just at letterror.com Thu Oct 16 14:40:39 2003 From: just at letterror.com (Just van Rossum) Date: Thu Oct 16 14:41:01 2003 Subject: [Pythonmac-SIG] Python crash! In-Reply-To: Message-ID: Bob Ippolito wrote: > The reason it's particularly problematic is that it doesn't really > handle the signals when they happen, it puts the signal handler next > in the bytecode queue. I've had problems with it as well, when I was > in C code when it happened. This is probably what happened with you > in the IDE. Chances are, if you're not using a C runloop (IDE or > whatever) then you'll be OK.. but it may not be worth it. When running with Python.framework, Python IDE will actually start a thread that listens to cmd-. events, and posts a SIGINT signal, which normally gets converted to a KeyboardInterrupt in the main thread. That normally seems to work just fine, but I have no idea what happens if you define your own signal handler for SIGINT. Just From txagcs98 at hotmail.com Thu Oct 16 14:50:23 2003 From: txagcs98 at hotmail.com (William McLendon) Date: Thu Oct 16 14:50:26 2003 Subject: [Pythonmac-SIG] thread blocking problem? Message-ID: This has me quite perplexed. I'm trying to make a little app that uses a basic http server that can launch a series of scripts and still run while the scripts are running. I'm attaching 2 source files that can replicate what's happening in my bigger script: I put these two files (myhttpd.py, execute.py) in one directory and run myhttpd.py. Load http://127.0.0.1:2000/ in a browser and hit the execute button. This should then kick off execute.py in a different thread? I've used a variety of different commands to run it (spawnv in this example) but the result is the same. The big problem is that the main thread running the http server seems to block till after execute.py is done. What is causing the blocking here? you can watch the progress of execute.py by doing tail -f out.txt in another window... the blocking should show up then. I've even tried making execute.py daemonize itself but the blocking still happens. #!/usr/bin/env python2.2 # myhttpd.py import os import time import BaseHTTPServer class httpRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): server_version='test/1.0' def do_POST(self): if self.path=='/execute': self.send_response(200,'OK') self.end_headers() self.wfile.write("\n" self.wfile.write("

done

\n") pid = os.fork() if pid == 0: os.spawnv(os.P_NOWAIT,'execute.py', ['']) os._exit(0) def do_GET(self): if self.path=='/': self.send_response(200,'OK') self.end_headers() self.wfile.write('\n') self.wfile.write('
\n') self.wfile.write(' \n') self.wfile.write('
\n') if __name__ == '__main__': server = BaseHTTPServer.HTTPServer(('127.0.0.1',2000), httpRequestHandler) while 1: server.handle_request() #!/usr/bin/env python # execute.py import os import time ofp = open('out.txt','a') n = 10 for i in range(n): time.sleep(3) ofp.write((n-i+1)*' ') ofp.write((2*i+1)*'.'+'\n') ofp.flush() for i in range(2): ofp.write((n)*' ') ofp.write('...\n') ofp.flush() ofp.close() I'm running this with python 2.2 on OS X 10.2.6 -- any help to get this to execute without blocking would be greatly appreciated. Thanks, -William _________________________________________________________________ See when your friends are online with MSN Messenger 6.0. Download it now FREE! http://msnmessenger-download.com From erik at letterror.com Fri Oct 17 04:31:57 2003 From: erik at letterror.com (Erik van Blokland) Date: Fri Oct 17 04:32:05 2003 Subject: [Pythonmac-SIG] ANN: DrawBot + Renaissance In-Reply-To: Message-ID: <5EF32E0A-007C-11D8-8C4A-000A956A726C@letterror.com> On Thursday, October 16, 2003, at 12:21 am, Bob Ippolito wrote: > And yes, Just, I did borrow your moinmoin css ;) I hope you don't > mind, I found yours to be much nicer and more readable than the mostly > default style I was using previously. Ha! except it was my moinmoin css! But I don't mind. And my intern Frederik De Bleser didn't mind either as I stole large parts of the code from him :) Cheers, Erik From speno at isc.upenn.edu Fri Oct 17 11:14:56 2003 From: speno at isc.upenn.edu (John P Speno) Date: Fri Oct 17 11:15:00 2003 Subject: [Pythonmac-SIG] thread blocking problem? In-Reply-To: References: Message-ID: <20031017151456.GA15952@isc.upenn.edu> On Thu, Oct 16, 2003 at 12:50:23PM -0600, William McLendon wrote: > if __name__ == '__main__': > server = BaseHTTPServer.HTTPServer(('127.0.0.1',2000), Could it be that BaseHTTPServer.HTTPServer is a SocketServer.TCPServer and not a SocketServer.ThreadingTCPServer or SocketServer.ForkingTCPServer? From txagcs98 at hotmail.com Fri Oct 17 14:14:05 2003 From: txagcs98 at hotmail.com (William McLendon) Date: Fri Oct 17 14:14:10 2003 Subject: [Pythonmac-SIG] thread blocking problem? Message-ID: I'm pretty new with this... What the differences in these are? Critical issues, etc? Is Python's fork()ing incomplete? Any workarounds? Thanks, -William >From: John P Speno >To: pythonmac-sig@python.org >Subject: Re: [Pythonmac-SIG] thread blocking problem? >Date: Fri, 17 Oct 2003 11:14:56 -0400 > >On Thu, Oct 16, 2003 at 12:50:23PM -0600, William McLendon wrote: > > if __name__ == '__main__': > > server = BaseHTTPServer.HTTPServer(('127.0.0.1',2000), > >Could it be that BaseHTTPServer.HTTPServer is a SocketServer.TCPServer >and not a SocketServer.ThreadingTCPServer or SocketServer.ForkingTCPServer? > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG@python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig _________________________________________________________________ Enjoy MSN 8 patented spam control and more with MSN 8 Dial-up Internet Service. Try it FREE for one month! http://join.msn.com/?page=dept/dialup From speno at isc.upenn.edu Fri Oct 17 14:29:55 2003 From: speno at isc.upenn.edu (John P Speno) Date: Fri Oct 17 14:29:59 2003 Subject: [Pythonmac-SIG] thread blocking problem? In-Reply-To: References: Message-ID: <20031017182955.GF12380@isc.upenn.edu> On Fri, Oct 17, 2003 at 12:14:05PM -0600, William McLendon wrote: > I'm pretty new with this... What the differences in these are? Critical > issues, etc? The differences are that the base HTTPServer can only process one request at a time while the forking and threading servers can process more than one at a time. The ForkingTCPServer creates a new child process to handle each request, while the ThreadingTCPServer uses a new thread per request. You may want to read the SocketServer.py module for the details. Another technique for doing this in one process or thread is the event driven module used by Twisted and Medusa for example. > Is Python's fork()ing incomplete? I'm not sure what you mean by that. > Any workarounds? Modify the HTTPServer class from BaseHTTPServer.py to inherit from Create your own server class like this (stolen from BaseHTTPServer.py: class ForkingHTTPServer(SocketServer.ForkingTCPServer): allow_reuse_address = 1 # Seems to make sense in testing environment def server_bind(self): """Override server_bind to store the server name.""" SocketServer.TCPServer.server_bind(self) host, port = self.socket.getsockname() self.server_name = socket.getfqdn(host) self.server_port = port And even this will probably work: class ForkingHTTPServer(BaseHTTPServer.HTTPServer, SocketServer.ForkingMixIn): pass Then just define your server like this: server = ForkingHTTPServer(('127.0.0.1', 2000), httpRequestHandler) None of this is specific to python on the Mac, but I'm not sure how well OS 9 handles either fork or threads. There's no problem on OS X. From bob at redivi.com Fri Oct 17 15:00:52 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 17 15:01:30 2003 Subject: [Pythonmac-SIG] thread blocking problem? In-Reply-To: Message-ID: <3A68EAA8-00D4-11D8-9C26-000A95686CD8@redivi.com> On Friday, Oct 17, 2003, at 14:14 America/New_York, William McLendon wrote: > I'm pretty new with this... What the differences in these are? > Critical issues, etc? > > Is Python's fork()ing incomplete? > > Any workarounds? > >> From: John P Speno >> To: pythonmac-sig@python.org >> Subject: Re: [Pythonmac-SIG] thread blocking problem? >> Date: Fri, 17 Oct 2003 11:14:56 -0400 >> >> On Thu, Oct 16, 2003 at 12:50:23PM -0600, William McLendon wrote: >> > if __name__ == '__main__': >> > server = BaseHTTPServer.HTTPServer(('127.0.0.1',2000), >> >> Could it be that BaseHTTPServer.HTTPServer is a SocketServer.TCPServer >> and not a SocketServer.ThreadingTCPServer or >> SocketServer.ForkingTCPServer? First of all, you said you're using: "python 2.2 on OS X 10.2.6". This sounds like the comes-with-Jaguar version of Python. It's buggy, unstable, and missing a few key things. Install MacPython 2.3. OS X 10.3 comes with (most of) MacPython 2.3, so you could just wait a week and upgrade your OS instead. Second, I suggest against using BaseHTTPServer. Twisted ( http://www.twistedmatrix.com/ ) is much more efficient (with multiple concurrent requests) than any of the BaseHTTPServer implementations, integrates with whatever networking you want (SMTP, IMAP, AIM, IRC, DNS, .. the list is huge), and is based on an async model rather than a threading/forking model so it's faster under Python (due to the GIL and such). Below is your example (myhttpd.py, the execute.py isn't changed, of course) naively translated to Twisted. Please read Twisted documentation if you decide to use it. The Twisted mailing list and the #twisted IRC channel on irc.freenode.net are also very helpful when you have questions that you can't answer yourself from the documentation. #!/usr/bin/env python # myhttpd.py from twisted.web.resource import Resource from twisted.web import server from twisted.internet import utils from twisted.python import log class ExecuteResource(Resource): def render(self, req): if not req.method == 'POST': return ("
\n"
                     "You may only POST to this resource\n"
                     "
\n") # this creates a deferred that will callback with # error or output.. the lambda will just trap+ignore # an error or output utils.getProcessOutput("execute.py").addBoth(lambda result: None) return ("
\n"
                 "Your process is running in the background\n"
                 "
\n") class RootResource(Resource): def render(self, req): return ("""\n\n\n""" """
\n""" """\n""" """
\n""") if __name__ == '__main__': import sys from twisted.internet import reactor log.startLogging(sys.stdout) root = Resource() root.putChild('execute', ExecuteResource()) root.putChild('', RootResource()) site = server.Site(root) reactor.listenTCP(2000, site) reactor.run() From lanceboyle at myrealbox.com Fri Oct 17 17:05:54 2003 From: lanceboyle at myrealbox.com (Lance Boyle) Date: Fri Oct 17 17:06:16 2003 Subject: [Pythonmac-SIG] Please explain this PackageManager message In-Reply-To: <6B3A08AF-F707-11D7-8E82-00039363BC02@mac.com> Message-ID: While downloading PyObjC 1.0 using PackageManager, I get this message: Not all files were unpacked: Library/Frameworks/Python.framework/Versions/2.3/bin/nibclassbuilder What does this mean? Do I need to do anything? Jerry From apicard at adobe.com Fri Oct 17 19:42:28 2003 From: apicard at adobe.com (Antoine Picard) Date: Fri Oct 17 19:47:19 2003 Subject: [Pythonmac-SIG] Japanese UI in Tkinter In-Reply-To: <20031017151456.GA15952@isc.upenn.edu> References: <20031017151456.GA15952@isc.upenn.edu> Message-ID: I'm creating a utility using Tkinter and I want to localize it for Japan. I already have it working on Windows and I had seen on another machine although some glyph showed up, some other didn't but, on my own machine, all the glyphs show up as gibberish. Is there some setting before running or during configure so that they show up properly in Tkinter? Note that I can print them to the darwin window and they show up properly when encoded as UTF-8 but not so in Tkinter. Thanks, -- Antoine Picard Type Department Adobe Systems Inc. From lanceboyle at myrealbox.com Fri Oct 17 19:59:31 2003 From: lanceboyle at myrealbox.com (Lance Boyle) Date: Fri Oct 17 19:59:32 2003 Subject: [Pythonmac-SIG] A very helpful page on Python, gnuplot, and Aquaterm Message-ID: I found this page http://www.physics.ucf.edu/~mdj/MacPython.html called "MacPython and Gnuplot in MacOS X" to be very useful in getting the popular gnuplot with the gnuplot.py bindings to run. The same site also has a page called "Minimal Python for Scientific Computing" at http://www.physics.ucf.edu/~mdj/MinimalPython.html which appears to be also very useful as a quick-and-dirty introduction. Jerry From drewmccormack at mac.com Sat Oct 18 04:06:01 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Sat Oct 18 04:06:16 2003 Subject: [Pythonmac-SIG] A very helpful page on Python, gnuplot, and Aquaterm In-Reply-To: Message-ID: On Saturday, October 18, 2003, at 01:59 AM, Lance Boyle wrote: > I found this page > http://www.physics.ucf.edu/~mdj/MacPython.html > called "MacPython and Gnuplot in MacOS X" to be very useful in getting > the popular gnuplot with the gnuplot.py bindings to run. > > The same site also has a page called "Minimal Python for Scientific > Computing" at > http://www.physics.ucf.edu/~mdj/MinimalPython.html > which appears to be also very useful as a quick-and-dirty introduction. > > Jerry > On this topic, can anyone recommend a plotting library for use on the Mac with python. I have seen the list on the python.org, but there are a lot there, and I would rather not have to try each one individually. My requirements are: - Publication quality - Must be able to do contour plots - Preferably a nice python object-based interface Drew From gherman at darwin.in-berlin.de Sat Oct 18 10:29:04 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Sat Oct 18 10:28:49 2003 Subject: [Pythonmac-SIG] A very helpful page on Python, gnuplot, and Aquaterm In-Reply-To: Message-ID: <6D0B1076-0177-11D8-AB1F-00039345C610@darwin.in-berlin.de> Drew McCormack: > On this topic, can anyone recommend a plotting library for use on the > Mac with python. I have seen the list on the python.org, but there are > a lot there, and I would rather not have to try each one individually. > My requirements are: > > - Publication quality > - Must be able to do contour plots > - Preferably a nice python object-based interface It depends a lot on what you really want to do. I'd recommend either of these: a) ReportLab + more business-like charts (bar, pie, line, scatter, etc) + quite fine-tunable + you can write your own + PDF and EPS output (plus SVG and bitmaps) + color-seperated EPS "on demand" + pure Python API - no contour stuff (unless you add it using Numeric, perhaps) - no 3D - lacking general scientific plots (unless you write them yourself) b) Gnuplot + EPS output (among others) + Python wrapper module + GnuplotEddie + contour stuff (also 3D) - probably more difficult to extend Otherwise look for Chaco or Ploticus, but I think neither of these has builtin support for contour plots, which I guess is hard to find outside Gnuplot, Mathematica, etc... Personally, I'd like to see some real Science-stuff based on the ReportLab Graphics API, but ok, I'm slightly biased. In any case, some output samples of the more exciting stuff I've done using RLG is hidden on my website: http://python.net/~gherman/tmp/TelcoInvoice.pdf http://python.net/~gherman/tmp/PyPy.pdf Have fun, Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "I once asked Ivan, 'How is it possible for you to have invented computer graphics, done the first object oriented software system and the first real time constraint solver all by yourself in one year?' And he said 'I didn't know it was hard.'" (Alan Kay on Ivan Sutherland) From mactov at projectomega.org Sat Oct 18 11:35:46 2003 From: mactov at projectomega.org (Mactov) Date: Sat Oct 18 11:36:01 2003 Subject: [Pythonmac-SIG] [Newbie question]MacPython and wxPython Message-ID: I just have downloaded and installed MacPython and wxPython and I can not launch my tut apps from the IDE (it even breaks). The only way for me to run my script is launching it from the command line. Can someone tell me where the "environment variables" to change are so that it works? Chris From kimnewsreply at lyris.komando.com Sat Oct 18 08:00:00 2003 From: kimnewsreply at lyris.komando.com (The Kim Komando Show Electronic Newsletter) Date: Sat Oct 18 17:13:02 2003 Subject: [Pythonmac-SIG] Kim Komando Show Electronic Newsletter -- October 18, 2003 Message-ID: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Issue Date: Oct. 18, 2003 Vol. 7, No. 42 Kim Komando Show Home Page: http://www.komando.com >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hang on! Another fast-reading no-holds-barred issue of The Kim Komando Show Newsletter has made its way through the gateways of the Internet. Now serving over 1,000,000 weekly by e-mail and over 8,000,000 on radio stations, I just want to say, "Thank you!" CONTENTS--WHAT'S IN YOUR INBOX THIS WEEK: -- ON THE QT: Free medications; speed tests & a funny Web site -- DIGITAL DIGRESSION: Fun and fast tips that work for you -- MY COLUMN: Limiting time spent using a computer -- COOL SITES: Real reality, kid-friendly portal and more! -- SHAREWARE PICK: A fun game -- SECURE COMPUTING: More patches for Windows -- MY KILLER TIP: Freebies for Outlook & Internet Explorer \o/ HEAR ME IN ALL 50 STATES THIS WEEKEND \o/ On this weekend's show: snooping on the kid's computer use; tips to stop spam; how to make sure digital memories last a long time; the latest computer news & all your calls! What a show! --> JOIN ME on the air during the LIVE broadcast of the show! That's Saturdays, 7 a.m. to 10 a.m. Pacific Time. Just call toll-free, 1-888-825-5254 --> FIND ME near you! Use the handy dandy map on my site: http://www.komando.com/findkimonair.asp ***************************************************** ***************************************************** THE FIRST VCR WAS MADE IN 1956 & WAS THE SIZE OF A PIANO Does your VCR still flash the time? Even if you have mastered that technology, how about PCs and the Web? Here's where my other two free e-mail newsletters can help! --> * Free computer tip Mon-Fri: Send e-mail to: tips@komando.com --> * Free cool site daily: Send e-mail to: cool@komando.com As always, I guarantee your privacy. Your e-mail address will not be sold or given to anyone else, ever! Warmly, Kim :) P.S. You can now sign up your friends & family to my newsletters. Just type your address and their addresses here: http://www.komando.com/newsletter.asp#friends P.P.S. In case you want to see a picture of that first VCR, go here: http://www.cedmagic.com/history/ampex-commercial-vtr-1956.html ***************************************************** ***************************************************** ON THE QT: COOL THINGS I PASS ALONG JUST FOR YOU --> DO YOU OR A FAMILY MEMBER QUALIFY FOR FREE MEDICINE? Most drug manufacturers sponsor what's called "Patient Assistance Programs." These programs are intended to help those who otherwise can't afford prescription drugs. This could include those who do not have health insurance or seniors not covered by Medicare. If you are approved, they say it only takes two to three weeks to get medications. Two places to help you find patient assistance programs for which you or a family member may qualify are: http://www.helpingpatients.org/ http://freemedicineprogram.com/ --> HOW FAST (OR SLOW) IS YOUR CONNECTION? Stop wondering. If you want a real-time readout on your Internet connection, check with the measuring services on the Web. Here are two places to run tests for free: Bandwidth Place: http://bandwidthplace.com/speedtest/ Broadband Reports: http://www.dslreports.com/stest --> FALL IS ALMOST HERE & YOU KNOW WHAT THAT MEANS You have reasons for not getting a flu shot, don't you? For example, you can get the flu from the shot, right? Wrong! The side effects are worse than the flu, correct? Get all the flu facts and find the location nearest you to get the shot here: http://www.findaflushot.com/lungusa/ --> STILL TO COME: Control time spent on a computer * Freebies to spell check Outlook Express & Internet Explorer * Play a great puzzle game * Dealing with presentations, start pages, & restarts ***************************************************** ***************************************************** YEA! YIPPEE!! HURRAY!!! MY NEW BOOK IS HERE! "The 50 Greatest Secrets of Digital Photography" is available! In this book, I teach you how to do it all, including: * Buy the right camera, take photos like a pro & share photos * Use editing software, digitize slides & negatives, & preserve memories * Manipulate images, use images in projects & print photos * Take pictures to sell products on eBay & protect and sell images * Pick the right scanner & use it for special projects * Clean up backgrounds, blur, whiten teeth & much more! * Step-by-step software instructions that make learning easy * Actual images used in examples so you can practice * And if you want, I will read the book to you! ORDER MY BOOK NOW IN OUR SECURE ONLINE MALL http://www.komando.com/kk_estore_40/details.asp?ProdID=47 WANT TO BUY IT WITH A CHECK OR MONEY ORDER? To pay by check or money order, complete and include this form in the envelope: http://www.komando.com/online_order_form.htm ***************************************************** ***************************************************** DIGITAL DIGRESSION: Tips That Work for You! --> WANT TO RECORD AUDIO FROM A DVD? So you have a DVD player in your computer. It makes sense that there should be a way to get the music off a movie disc. And once you do, you could create a CD of that music, right? Well, that would be wrong according to the Digital Millennium Copyright Act. You would be breaking the DVD's copyright protection measures. This means you would also be breaking the law. Now, there are software programs that claim to do this sort of thing. But since it is against the law, I will not pass along the names of them. Hopefully, one day soon the music and movie industries will catch up with technology. --> NEED SOME SCREEN SHOTS? I received this question via e-mail the other day. "How can I take pictures of what I see on the screen and put those in a Microsoft Word document?" Easy! Press the Print Screen (or PrtScn) key on your keyboard. This places a copy of the entire screen on the Windows Clipboard. To capture only the current active window, press the ALT + Print Screen keys. To paste the image into a document, select Edit from Word's menu and Paste. This tip works in Excel, FrontPage, Outlook, PowerPoint and Publisher, too. There are software programs you can buy that allow you to do more, such as save the shots in different file formats. Before you go buy a program, though, here are a few free ones to try: PrintScreen -- http://www.gadwin.com/printscreen/ HoverSnap -- http://www.hoverdesk.net/freeware.htm --> CAN THEY SEE YOU AND THE PRESENTATION? You're about to make a very important PowerPoint presentation. How do you make sure that everyone in the audience can see the slides? Avoid busy backgrounds and use simple fonts that are sans serif. In other words, Helvetica is more readable than Times. Follow the 8H (eight times height) rule to be sure people sitting in back can read the slides. The maximum viewing distance should not be more than 8 times the height of the screen. The text on the slides should be at least 1/50th the height of the screen. Don't put too much on each slide. The audience has come to see you, not a slide show. --> WOW! GET A FREE COMPUTER TIP DURING THE WEEK Become the ultimate computer user the easy and fun way! Send one e-mail to sign up for my tip of the day: tips@komando.com --> MORE GOODIES BELOW, SO KEEP ON READING: <-- * Rookie Rundown--Start pages & restarts * Better get these Windows updates ++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++ AND NOW, A PAID ADVERTISEMENT... --> ATTENTION EPSON PRINTER OWNERS: ** Chip Resetter for all Epson cartridges resets the "smart chip" http://colorfastink.com/product.aspx?product=Chip+Resetter --> REFILL YOUR OWN INKJET CARTRIDGES & SAVE MONEY ** You get 16 refills for $36.95 -- a $300 saving! http://www.colorfastink.com --> ARE YOU TOO BUSY TO REFILL YOUR OWN CARTRIDGES? ** Let Universal do it for you! A savings over 50%! http://www.colorfastink.com (click the "We refill for you" link) --> BUSINESS OPPORTUNITY ** You can sell Universal products to businesses in your town. http://www.colorfastink.com/affiliate +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ MY WEEKLY COLUMN: Put Time Limits on Kid's Computer Use Controlling how much time the kids sit in front of a box of electronics is nothing new. With the advent of computers and the Internet, solutions span the gamut. Selecting the right one is no simple choice. Products like Time-Scout Monitor and TV Allowance use the tough love approach. Both are pieces of hardware that control power to the monitor (or TV or video game). The idea behind it is simple. Without any power, no matter what the child does, it just will not work. The parent decides how much time the child has and works out the schedule with the child. Children use swipe cards to access their time with Time-Scout, and a personal identification number with TV Allowance. You might think that children would resent these restrictions. But parents say that children soon accommodate the limitation, especially if they are given the opportunity to decide when they can use the appliance. It gives them a sense of power. Jenny Meacham, of Orem, Utah, said she loves Time-Scout Monitor. She has put it on her televisions and two computers used by her children. "The kids can earn more time (on a TV or computer)," she said. "They can also lose time. But we use it mostly as a reward system." Meacham said her older children initially chafed at the constraints, but have since accepted it. Her son was spending hours at a time at Microsoft's Gaming Zone. She said he was upset by the limits, but has gotten past that. Time-Scout Monitor (http://www.time-scout.com) is $89.95 direct from the company. To use it, you plug the computer monitor, TV or video game into the power box and set the lock. The power box is plugged into the wall socket. A card reader is also provided. A parent uses an add-subtract card to create the time limits. The child also receives a card. When the child is ready to use the appliance, he or she swipes the card through the card reader. The appliance is turned on and the Time-Scout begins counting down the minutes. When the child is through, a swipe turns off the appliance and saves the child's remaining minutes. TV Allowance works similarly. The power cord of the TV, computer monitor or video game is plugged into TV Allowance, and the top is closed and locked. Each child is given a four-digit PIN. Like Time-Scout, parents and children decide together how much time will be granted. Once schedules are worked out, the children access their time with their PINs. TV Allowance counts down the time and turns the appliance off when time expires. The child cannot restore power until the next week. TV Allowance (http://www.tvallowance.com) is $99 for the first unit, and $79 for each additional one. Software programs are also available to monitor computer usage. PC TimeCop (http://www.familysafemedia.com, $35) includes limits to certain programs, certain times, maximum or minimum lengths of time, and many other restrictions. Other programs put more emphasis on limiting Internet access. Two such programs are CyberPatrol (http://www.cyberpatrol.com, $39) and Cyber Sentinel (http://www.securitysoft.com, $40). Keylogging capability is included with most programs. With this, you can see everything a child does on the computer. Just remember that hardware and software solutions are no substitute for old-fashioned parenting. Give the kids rules and see that they abide by them. If you need help coming up with the rules, use my 10 Commandments for Kids Online. It's free here: http://www.komando.com/kimskidscontract.html --> A LITTLE ABOUT ME: My weekly radio show is heard nationally by 8 million people on over 400 stations. I also do a Computer Minute each weekday, heard on more than 285 stations. I write a weekly column that runs in more than 100 newspapers. And my Q&A column appears weekly in USA Today. I also have a column on MSN's bCentral. You can read a bunch here: http://www.bcentral.com/articles/komando/default.asp --> STILL TO COME: Get the patch from Microsoft * Freebies you'll really dig and play a puzzle +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ AND NOW, A PAID ADVERTISEMENT... SAVE UP TO 70% ON YOUR LONG DISTANCE BILL! http://www.SaveOnPhone.com Tired of paying those high long distance charges? Why pay more to major carriers when you don't have to? SaveOnPhone can help you save hundreds of dollars each year! SaveOnPhone objectively compares the top 10 long distance plans with the lowest rates and no monthly fees. You'll find rates as low as 2.9 cents per minute! For significant savings, learn more about switching carriers today by visiting the site below: http://www.SaveOnPhone.com +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ ROOKIE RUNDOWN: Tips to get you up and going! --> A SAFE WAY TO START WINDOWS Having trouble with Windows? If Windows won't start, sometimes you can get in there and fix what ails you in Safe Mode. Heck, if you cannot get ScanDisk to ever finish, running it in Safe Mode normally does the trick. When you see the "Starting Windows" message, here are the secret keys to press: F5 -- Safe mode. This allows Windows to start with its most basic configuration, bypassing Autoexec.bat and Config.sys files and using the VGA driver for video and not loading networking software. F6 -- Safe mode (like F5) but with the addition of network support. F8 -- Gives you a menu of different options before Startup. This is a really good one to remember! --> TIRED OF WAITING FOR A WEB PAGE TO APPEAR? Waiting for a Web site to finish loading is annoying. When this happens to you, don't get all bent out of shape. Simply press the Esc key or click the red X on your browser's toolbar. This stops a Web site from loading. What if that slow Web page is your start or home page? Then change it! I have my home page set to a blank page. This way, my browser is open and ready for me to go where I want to fast! Internet Explorer: 1. Select Tools and then, Internet Options. 2. On the General Tab, click the Use Blank Button and OK. Netscape: 1. Select Edit and then Preferences/Navigator. 2. Under Navigator Starts With, select Blank Page and OK. --> KEEP READING: One great pun at the very end <-- * A puzzle game that's really fun * A list of freeware for Outlook and Internet Explorer ***************************************************** ***************************************************** QT BONUS: EVEN MORE COOL THINGS YOU NEED TO KNOW --> FINALLY, A NEW AIRLINE READY TO SERVE If you're like me, you have had more than a few bad air travel experiences. Here's a site that seems to have it all. They offer bench or cargo seating, claim to be on-time about 37% of the time, and make you share a bag of peanuts with the person seated next to you. You can tell that this type of service comes from the top. The Chairman asks in his letter, "What is it with you people?" For more than a few laughs, check the site out at: http://www.skyhighairlines.com/main.asp --> IN THE COOL SITES: Calcium supplements and lavish living <-- * And, wow! You won't want to miss the OE & IE Freebies! +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ AND NOW, A PAID ADVERTISEMENT... SURFING THE WEB IS NO LONGER A PRIVATE MATTER. Each time you go on the web, you are being tracked, making you vulnerable to relentless spam and annoying pop-ups. The solution: http://www.getprivatenow.com There, you get Anonymizer Privacy Manager and as a SPECIAL BONUS, FREE anti-spam software! It will stop spam, pop-ups and hidden tracking with the best in online security. My listeners receive the Anonymizer Privacy Manager and FREE anti-spam software for just $49.95 - a savings of $60. Go to http://www.getprivatenow.com and use my name, Kim +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ CALLING ALL LISTENERS! CALLING ALL LISTENERS! Catch my Kim Komando Computer Minute each weekday and don't forget to make an appointment to hear the big three hour show every weekend! You'll be glad that you did! -->TIP YOUR HAT & TUNE IN TO THESE FINE STATIONS! ~ Phoenix (KFYI 550 AM), Saturdays, noon ~ Denver (KHOW 630 AM), Sundays, 10 a.m. ~ Seattle (KQBZ 100.7 FM), Saturdays, 10 a.m. --> BULLETIN! TIME CHANGE HERE! ~ Greenville, SC (WORD 950 AM and WYRD 1330 AM), Sundays, 12 p.m. --> MY LISTENERS ARE #1 >From coast to coast I am on over 400 stations! Here are some of my wonderful affiliates: New York City (WCBS 880 AM), Atlanta (WSB 750 AM), Boston (WRKO 680 AM), San Antonio (WOAI 1200 AM), Honolulu (KHVH 830 AM), Tucson, AZ (KNST 790 AM), Tulsa, OK (KRMG 740 AM) and many more, like Chicago (WLS 890 AM) and Portland, OR (KXL 750 AM)! -->Oh where oh where has my Kimmie gone? Find me here: http://www.komando.com/findkimonair.asp ***************************************************** ***************************************************** OUR WEEKLY SELECTION OF UNIQUE & GREAT WEB SITES THE OFFICIAL INTERNET PICK OF THE WEEK (The best sites on a single subject...) THIS WEEK-- WEB CAMS PUT THE "REAL" IN REALITY http://www.komando.com/kool_show.asp?showID=4340176 Reality shows are a ratings blockbuster on television. The problem is, they've been edited, produced and tweaked to heighten the drama. If you want a "real" reality show, turn to the Web. Web cameras let you experience life in Paris, Tokyo and even Antarctica from the comfort of your own home. Here are some neat Web cam sites that I think you'll enjoy. FREE SITE: CALCIUM SUPPLEMENT http://www.viactiv.com/index.jhtml Enter your address for a free sample Viactiv Soft Calcium Chews. U.S. residents only. CONTEST SITE: THE BEST LIFE HAS TO OFFER http://bestlife.perfectprize.com/welcomenew.shtml Answer questions found on Forbes.com to win a chance for: a week in Paris, digital camcorder, Palm Tungsten T and more! Open to U.S. residents, 18 and over. KIDS SITE: JUNIOR WEB PORTAL http://www.lycoszone.com/ This kid safe Web portal has everything a kid would need. Play games, find homework help, watch cartoons and more! --> STOP WANDERING THE WEB IN SEARCH OF THE BEST Every day of the week, I uncover sites that are helpful or just plain fun! Subscribe by sending one e-mail to: cool@komando.com --> STILL TO COME: My freebie picks and more! +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ AND NOW, A PAID ADVERTISEMENT... ACCESS YOUR WORK OR HOME PC REMOTELY USING THE INTERNET OR A WIRELESS DEVICE http://www.gotomypc.com/s/kim/Q42003/news Imagine secure, instant access to your email, programs or network from anywhere you happen to be. Think of the possibilities and freedom! -- Leave work early and seamlessly finish from home -- Travel anywhere in the world & have access to your PC back home With any Internet-connected computer or wireless device, everything you need is at your fingertips with GoToMyPC. Try it FREE today! http://www.gotomypc.com/s/kim/Q42003/news use promo code KIM. +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ SHAREWARE PICK OF THE WEEK: (Smart software of all sorts) --> THIS WEEK'S FOCUS: Fun! Play a puzzle game! For Windows: Dweep Gold The object of the game is to reunite Dweep, a furry purple creature, with its babies. The only thing standing in Dweep's way is a maze of lasers, mirrors, bombs and other hazards. For Macs: Freddy's Forest Help Freddy catch a butterfly. Using boulders and trees, you'll have to put out fires, avoid collapsing bridges and build steps to reach the butterfly net. Once you get the net, try to capture the butterfly. --> Find my Shareware Pick for this week right here: http://www.komando.com/showpicks.asp --> Still to come so you better keep reading... THE KILLER TIP: Free files to enhance Outlook & Internet Explorer <-- +++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++ SECURE COMPUTING: Stuff to keep you safe from harm! --> GREETINGS FROM REDMOND, WASHINGTON Microsoft released a bunch of updates this week. One fixed a hole that could let a hacker get control of a computer that was connected to the Internet. Another patch closed an open path in Windows Messenger that also left a system vulnerable. But wait, there's more. Another fix was posted that prevented a scenario where if a user clicked on the URL hosted on a website, an attacker could have the ability to read or launch files present on the user's machine. The bottom-line: You need to drop by the link below and download the patches associated with the version of Windows running on your PC. http://microsoft.com/security/security_bulletins/20031015_windows.asp --> DON'T STOP READING NOW! THERE'S MORE BELOW! * There's the Killer Tip and one really bad pun +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ AND NOW, A PAID ADVERTISEMENT... PREMIUM UNLIMITED INTERNET ACCESS FOR $8.25/MO http://intergate.com/cgi-bin/refer.cgi?5546 No credit card required. Service includes 100 e-mail accounts, 100 MB of Web space, toll-free technical support, and over 40,000 newsgroups. Member of the BBB. No setup fees, no ads or banners, and NO busy signals. Service is also perfect when used as a broadband backup, for those who travel, and for those who cannot get broadband yet. Over 10,000 access numbers nationwide. Learn more now at: http://intergate.com/cgi-bin/refer.cgi?5546 +++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++ MY "KILLER TIP OF THE WEEK" IS JUST FOR YOU! Q. Hi Kim, Every once in a while on your show you will tell someone to get a free program that seems to pick up where Microsoft left off. One in particular is the free spell checker for Internet Explorer. Can you tell me where I might download that as well as some others I might want to check out for Outlook and Internet Explorer? A. There are a lot of nifty free programs written for Microsoft programs. Most are free for personal use. If you use them in a commercial enterprise, there could be a charge. Some authors ask for a donation. If you end up keeping the program, send them $10 or $20 for their work. It's the right thing to do. Below you will find a list of some freeware that I have found useful, starting with the spell checker you asked about. * IE Spell: Internet Explorer add-on that spell checks text input boxes on a webpage: http://www.iespell.com/download.php * GetFile: Internet Explorer add-on that allows you to find out the size of a file before downloading it: http://www.unhsolutions.net/GFS/ * Merriam-Webster Toolbar: Becomes a part of your Internet Explorer toolbar so you can look up words in the dictionary or thesaurus: http://www.m-w.com/tools/toolbar/ * OE Backup: Tool to backup your address book, folders and more for Outlook Express users: http://www.oehelp.com/OEBackup/Default.aspx * OE SpellChecker: Spell checker for Outlook Express: http://www.geocities.com/vampirefo/ * Browser Hijack Blaster: Protects any changes to your Internet Explorer home page or search page: http://www.wilderssecurity.net/bhblaster.html In case you are looking for a free firewall, spyware removal tool, anti-virus program, way to know all that is in your PC including product keys and serial numbers, you will find a list of those on my site here: http://www.komando.com/bestshareware.asp Thanks for writing! Kim :) +++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++ AND FINALLY, A LESSON FROM THE DOG There was once a handyman who had a dog named Mace. Mace was a great dog except he had one weird habit. He liked to eat grass, not just a little bit, but in quantities that would make a lawnmower blush. One day, the handyman lost his wrench in the tall grass while he was working outside. He looked and looked, but it was nowhere to be found. As it was getting dark, he gave up for the night and decided to look the next morning. When he awoke, he went outside, and saw that his dog had eaten the grass all in the area around where he had been working. His wrench now lay in plain sight, glinting in the sun. Going out to get his wrench, he called the dog over to him and said, "A grazing Mace, how sweet the hound, that saved a wrench for me." That one really hurt! See you on the radio! Kim :) ***************************************************** ***************************************************** NEWSLETTER HELP & OTHER STUFF -- If you cannot "click" on links in this e-mail, try copying the complete Web address into an open browser window's address bar. -- If you'd like to subscribe to this newsletter, Cool Site of the Day, or Tip of the Day, or if you need to change your subscription address, go to my online form: http://www.komando.com/newsletter.asp -- Want to advertise in my e-mail newsletters or on my national radio show? Send your product or site's details to: rates[NO SPAM]@komando.com (Please remove [NO SPAM]. (The address above is written to avoid spam collectors.) -- Copyright 2003, The Kim Komando Show. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of The Kim Komando Show is prohibited and strictly enforced. Newsletters may contain links to sites on the Internet owned and operated by third parties. The Kim Komando Show is not responsible for the availability of, or the content located on or through, any such third-party site. Information in this document is provided "as is," without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose and freedom from infringement. The user assumes the entire risk as to the accuracy and the use of this document. We will not be liable for any damages of any kind arising from the use of this information, including, but not limited to direct, indirect, incidental, punitive, and consequential damages. -- If you must, unsubscribe details are below. :/ You are currently subscribed to "kimsnewsletter" as: pythonmac-sig@python.org To unsubscribe, just send an e-mail to: leave-kimsnewsletter-1291829U@lyris.komando.com or enter your address (pythonmac-sig@python.org) at my online form: http://www.komando.com/unsubscribe.asp This newsletter is a free service of The Kim Komando Computer Show, one of the Top 10 Most Listened to Programs in the United States! Visit us on the Internet at: http://www.komando.com From unsubscribe-confirm at lyris.komando.com Sat Oct 18 16:50:34 2003 From: unsubscribe-confirm at lyris.komando.com (Lyris ListManager) Date: Sat Oct 18 17:44:56 2003 Subject: [Pythonmac-SIG] Your confirmation is needed (ok 1291829) Message-ID: Your email address 'pythonmac-sig@python.org' has been submitted to be unsubscribed from the 'kimsnewsletter' mailing list. This unsubscribe command requires your confirmation that you want to be unsubscribed. To confirm that you do want to unsubscribe, reply to this message so that the words "ok 1291829" appear somewhere on the subject line. Make sure that your reply message is addressed to unsubscribe-confirm@lyris.komando.com You will receive notification that your confirmation has been received, and that you have been unsubscribed. If you do not want to unsubscribe, do nothing. You will be kept on the mailing list. --- Return-Path: Received: from oratrix.oratrix.com ([192.16.197.220]) by lyris.komando.com with SMTP (Lyris ListManager WIN32 version 7.6); Sat, 18 Oct 2003 14:50:32 -0600 Received: from [24.132.3.41] (node10329.a2000.nl [24.132.3.41]) by oratrix.oratrix.com (Postfix) with ESMTP id F147AEF0D4 for ; Sat, 18 Oct 2003 23:44:45 +0200 (MET DST) Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: <4729ED1B-01B4-11D8-98EC-000A27B19B96@cwi.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed To: kimsnewsletter-request From: Jack Jansen Subject: Date: Sat, 18 Oct 2003 23:44:40 +0200 X-Mailer: Apple Mail (2.604) # Mail sent to leave-kimsnewsletter-1291829u was converted to these commands: unsubscribe kimsnewsletter pythonmac-sig@python.org confirm end # This is the text of the message that triggered the action: Return-Path: Received: from oratrix.oratrix.com ([192.16.197.220]) by lyris.komando.com with SMTP (Lyris ListManager WIN32 version 7.6); Sat, 18 Oct 2003 14:50:32 -0600 Received: from [24.132.3.41] (node10329.a2000.nl [24.132.3.41]) by oratrix.oratrix.com (Postfix) with ESMTP id F147AEF0D4 for ; Sat, 18 Oct 2003 23:44:45 +0200 (MET DST) Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: <4729ED1B-01B4-11D8-98EC-000A27B19B96@cwi.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed To: leave-kimsnewsletter-1291829U@lyris.komando.com From: Jack Jansen Subject: Date: Sat, 18 Oct 2003 23:44:40 +0200 X-Mailer: Apple Mail (2.604) -- 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 lyris-noreply at lyris.komando.com Sat Oct 18 16:55:17 2003 From: lyris-noreply at lyris.komando.com (Lyris ListManager) Date: Sat Oct 18 17:49:38 2003 Subject: [Pythonmac-SIG] You've left the Kim Komando Show Newsletter :/ Message-ID: Hello! Oh no, say it's not so! You're leaving us? Really? It looks like that you have successfully unsubscribed from The Kim Komando Show Free Electronic Newsletter with the following address: pythonmac-sig@python.org If you did not want to really unsubscribe or want to subscribe again just send an e-mail to: join-kimsnewsletter@lyris.komando.com We'd love to have you back. :) Cordially, Kim Komando The Kim Komando Show Free Electronic Newsletter http://www.komando.com From lyris-noreply at lyris.komando.com Sat Oct 18 16:55:56 2003 From: lyris-noreply at lyris.komando.com (Lyris ListManager) Date: Sat Oct 18 17:50:18 2003 Subject: [Pythonmac-SIG] You've left the Kim Komando Show Newsletter :/ Message-ID: Hello! Oh no, say it's not so! You're leaving us? Really? It looks like that you have successfully unsubscribed from The Kim Komando Show Free Electronic Newsletter with the following address: pythonmac-sig@python.org If you did not want to really unsubscribe or want to subscribe again just send an e-mail to: join-kimsnewsletter@lyris.komando.com We'd love to have you back. :) Cordially, Kim Komando The Kim Komando Show Free Electronic Newsletter http://www.komando.com From Jack.Jansen at cwi.nl Sat Oct 18 18:13:25 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Oct 18 18:13:32 2003 Subject: [Pythonmac-SIG] Please explain this PackageManager message In-Reply-To: References: Message-ID: <4B0B3B5C-01B8-11D8-98EC-000A27B19B96@cwi.nl> On 17-okt-03, at 23:05, Lance Boyle wrote: > While downloading PyObjC 1.0 using PackageManager, I get this message: > > Not all files were unpacked: > Library/Frameworks/Python.framework/Versions/2.3/bin/nibclassbuilder > > What does this mean? Do I need to do anything? This error message is indeed obscure, and I'm looking for a better one. The problem is that it can really mean different things in different circumstances: 1. If you do a "current user only" install of a package then anything the package tries to install outside of site-packages (like header files, or scripts, as in this case) is not installed. This is really an error by the scapegoat, as there is a way to list all the expected skips in the database. 2. If you do a system-wide install, but some directories are not writable you also get this message. This probably means that some directories were expected to be writable but weren't. This can be either a scapegoat error or a user error. The net result of all this is that you don't have the nibclassbuilder command line tool. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Sat Oct 18 18:19:47 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Oct 18 18:19:54 2003 Subject: [Pythonmac-SIG] [Newbie question]MacPython and wxPython In-Reply-To: References: Message-ID: <2EE99150-01B9-11D8-98EC-000A27B19B96@cwi.nl> On 18-okt-03, at 17:35, Mactov wrote: > I just have downloaded and installed MacPython and wxPython and I can > not launch my tut apps from the IDE (it even breaks). The only way for > me to run my script is launching it from the command line. Can someone > tell me where the "environment variables" to change are so that it > works? I think you cannot run wxPython scripts from the IDE. I'm not sure (Just? Robin?), but the IDE is Carbon-based, and mixing two GUI toolkits is usually not going to work. But: double-clicking your scripts from the Finder should work. This will launch them with PythonLauncher, which will in turn run them with "pythonw". By default this is done in a Terminal window, so you can see stdout and stderr, but you can change this behavior through PythonLauncher preferences or option-double-clicking the script. And there are two sets of preferences for ".py" scripts and ".pyw" scripts, so you could use ".pyw" for production scripts and set the PythonLauncher prefs to not show a terminal window for those. And there should have been a way to get the same behavior with the IDE, but unfortunately it seems to lead to a crash:-( -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Sat Oct 18 18:38:31 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 18 18:39:12 2003 Subject: [Pythonmac-SIG] Please explain this PackageManager message In-Reply-To: <4B0B3B5C-01B8-11D8-98EC-000A27B19B96@cwi.nl> Message-ID: On Saturday, Oct 18, 2003, at 18:13 America/New_York, Jack Jansen wrote: > On 17-okt-03, at 23:05, Lance Boyle wrote: > >> While downloading PyObjC 1.0 using PackageManager, I get this message: >> >> Not all files were unpacked: >> Library/Frameworks/Python.framework/Versions/2.3/bin/nibclassbuilder >> >> What does this mean? Do I need to do anything? > > This error message is indeed obscure, and I'm looking for a better > one. The > problem is that it can really mean different things in different > circumstances: > > 1. If you do a "current user only" install of a package then anything > the > package tries to install outside of site-packages (like header > files, or > scripts, as in this case) is not installed. This is really an error > by > the scapegoat, as there is a way to list all the expected skips in > the > database. > 2. If you do a system-wide install, but some directories are not > writable > you also get this message. This probably means that some directories > were expected to be writable but weren't. This can be either a > scapegoat > error or a user error. > > The net result of all this is that you don't have the nibclassbuilder > command line tool. 2. could be remedied in a future version of PackageManager with the Authorization module that I released. It's not the user's fault that they don't have permission to that folder, it's probably some installer's fault. Just FYI, this weekend I'm writing an ObjC wrapper for the SystemConfiguration framework (I expect to finish it tonight or tomorrow), which gives us access (via PyObjC) to a whole slew of things including but not limited to network and proxy settings, which would also be useful for the next iteration of PackageManager among other things. -bob From bob at redivi.com Sun Oct 19 03:51:20 2003 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 19 03:51:52 2003 Subject: [Pythonmac-SIG] ANN: Preview of SystemConfiguration wrapper Message-ID: <073FD03A-0209-11D8-B59D-000A95686CD8@redivi.com> http://undefined.org/python/SystemConfiguration-0.1.tar.gz This is a source distribution, it requires PyObjC and Developer Tools. The wrapper itself is (entirely) an ObjC framework, but it includes everything necessary for Python wrapping. I haven't done any documentation, real tests, especially testing of the runloop integration.. but here it is if someone wants to play with it. The ObjC is a little sloppy (three classes in one file), and the setup.py is a lot sloppy (thanks to distutils being not easily extensible), but it works.. or at least it should. I'll be adding stuff from MoreSCF, probably tomorrow, and writing more tests/examples and possibly some documentation over the next couple days. -bob From oussoren at cistron.nl Sun Oct 19 08:57:19 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Sun Oct 19 08:57:22 2003 Subject: [Pythonmac-SIG] ANN: Preview of SystemConfiguration wrapper In-Reply-To: <073FD03A-0209-11D8-B59D-000A95686CD8@redivi.com> References: <073FD03A-0209-11D8-B59D-000A95686CD8@redivi.com> Message-ID: On 19 okt 2003, at 9:51, Bob Ippolito wrote: > http://undefined.org/python/SystemConfiguration-0.1.tar.gz > > This is a source distribution, it requires PyObjC and Developer Tools. > The wrapper itself is (entirely) an ObjC framework, but it includes > everything necessary for Python wrapping. I haven't done any > documentation, real tests, especially testing of the runloop > integration.. but here it is if someone wants to play with it. The > ObjC is a little sloppy (three classes in one file), and the setup.py > is a lot sloppy (thanks to distutils being not easily extensible), but > it works.. or at least it should. I haven't looked at your code yet, but wouldn't it be better to generate the wrapper using bgen? That would make the wrapper easier to maintain and easier to integrate into MacPython/the python core. The CodeGenerator scripts in PyObjC could also be coaxed into generating a functioning wrapper That is, without significant changes to the scripts. The prototypes are different enough to require changes to the "parser". Ronald From bob at redivi.com Sun Oct 19 09:25:51 2003 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 19 09:26:30 2003 Subject: [Pythonmac-SIG] ANN: Preview of SystemConfiguration wrapper In-Reply-To: Message-ID: On Sunday, Oct 19, 2003, at 08:57 America/New_York, Ronald Oussoren wrote: > > On 19 okt 2003, at 9:51, Bob Ippolito wrote: > >> http://undefined.org/python/SystemConfiguration-0.1.tar.gz >> >> This is a source distribution, it requires PyObjC and Developer >> Tools. The wrapper itself is (entirely) an ObjC framework, but it >> includes everything necessary for Python wrapping. I haven't done >> any documentation, real tests, especially testing of the runloop >> integration.. but here it is if someone wants to play with it. The >> ObjC is a little sloppy (three classes in one file), and the setup.py >> is a lot sloppy (thanks to distutils being not easily extensible), >> but it works.. or at least it should. > > I haven't looked at your code yet, but wouldn't it be better to > generate the wrapper using bgen? That would make the wrapper easier > to maintain and easier to integrate into MacPython/the python core. > > The CodeGenerator scripts in PyObjC could also be coaxed into > generating a functioning wrapper That is, without significant changes > to the scripts. The prototypes are different enough to require changes > to the "parser". I decided against bgen for a couple reasons: - bgen is hard to use - I'm not yet convinced that the code generators save that much time in the long run - I wrote it by mostly by hand so I know that each and every method has been "audited" by someone to at least look like it should work ;) - Using a bgen-generated Python module doesn't feel much better than coding in C. These are named so that the module feels like they're using PyObjC. - SystemConfiguration is one of those should've-already-been-wrapped-in-ObjC-by-Apple frameworks that uses a lot of CoreFoundation types, so the bridge code is already in PyObjC for the most part (lots of CFDictionaryRef, CFArray, CFString, etc.) - It might be useful from ObjC someday. Surely by someone in the ObjC community that isn't using any or a lot of Python yet. - The SystemConfiguration framework has awkward rules about when you need to check for errors, so I'd have to write a lot of helpers by hand anyway. Since bgen helpers are in C, not ObjC, it would be much more of a pain in the ass to write them (i.e. more like 20 lines of code per hand-wrapped function instead of an average of maybe 4 here). -bob From bob at redivi.com Sun Oct 19 09:42:05 2003 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 19 09:42:37 2003 Subject: [Pythonmac-SIG] Japanese UI in Tkinter In-Reply-To: Message-ID: <06DC4E6D-023A-11D8-B59D-000A95686CD8@redivi.com> On Friday, Oct 17, 2003, at 19:42 America/New_York, Antoine Picard wrote: > I'm creating a utility using Tkinter and I want to localize it for > Japan. > > I already have it working on Windows and I had seen on another machine > although some glyph showed up, some other didn't but, on my own > machine, all the glyphs show up as gibberish. > > Is there some setting before running or during configure so that they > show up properly in Tkinter? > Note that I can print them to the darwin window and they show up > properly when encoded as UTF-8 but not so in Tkinter. I think you ought to ask the Aqua Tcl/Tk people about this, because it isn't really very specific to Python. Personally I'd recommend using another toolkit. wxWindows (wxPython) has localization and internationalization built in and will work OS X (mostly), X11 and Win32. Though you *might* want to consider consolidating as much of the functionality that can be consolidated and then develop two separate interfaces (one for Mac, one for Win32). At this point it's a lot easier to fix (and you're probably less likely to find) a bug in PyObjC than to fix a bug in wxWindows or Aqua Tcl/Tk. PyObjC applications are also lighter weight and much easier to distribute than wxPython or Tkinter applications. -bob From oussoren at cistron.nl Sun Oct 19 12:52:34 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Sun Oct 19 12:53:25 2003 Subject: [Pythonmac-SIG] ANN: Preview of SystemConfiguration wrapper In-Reply-To: References: Message-ID: On 19 okt 2003, at 15:25, Bob Ippolito wrote: > > On Sunday, Oct 19, 2003, at 08:57 America/New_York, Ronald Oussoren > wrote: > >> >> On 19 okt 2003, at 9:51, Bob Ippolito wrote: >> >>> http://undefined.org/python/SystemConfiguration-0.1.tar.gz >>> >>> This is a source distribution, it requires PyObjC and Developer >>> Tools. The wrapper itself is (entirely) an ObjC framework, but it >>> includes everything necessary for Python wrapping. I haven't done >>> any documentation, real tests, especially testing of the runloop >>> integration.. but here it is if someone wants to play with it. The >>> ObjC is a little sloppy (three classes in one file), and the >>> setup.py is a lot sloppy (thanks to distutils being not easily >>> extensible), but it works.. or at least it should. >> >> I haven't looked at your code yet, but wouldn't it be better to >> generate the wrapper using bgen? That would make the wrapper easier >> to maintain and easier to integrate into MacPython/the python core. >> >> The CodeGenerator scripts in PyObjC could also be coaxed into >> generating a functioning wrapper That is, without significant changes >> to the scripts. The prototypes are different enough to require >> changes to the "parser". > > I decided against bgen for a couple reasons: > - bgen is hard to use Yup, that's why PyObjC contains Scripts/CodeGenerator :-), writing those scripts was easier than getting bgen to work correctly. As I never managed to get a working bgen setup I cannot say if bgen is really hard to use or if it's just the lack of documentation that makes it so hard to use. > - I'm not yet convinced that the code generators save that much time > in the long run An important advantage of code generators is that you end up with a consistantly translated API. This may not be the perfect API, but makes it so much easier to use existing documentation and examples (all targetting the C API) when writing Python scripts that use the wrapped API. > - I wrote it by mostly by hand so I know that each and every method > has been "audited" by someone to at least look like it should work ;) > - Using a bgen-generated Python module doesn't feel much better than > coding in C. These are named so that the module feels like they're > using PyObjC. See me previous point, a more python-like interface is not necessarily an advantage. That won't keep me from using your wrappers though, the look pretty usefull as they are. > - SystemConfiguration is one of those > should've-already-been-wrapped-in-ObjC-by-Apple frameworks that uses a > lot of CoreFoundation types, so the bridge code is already in PyObjC > for the most part (lots of CFDictionaryRef, CFArray, CFString, etc.) I've been thinking about this. Should there be a 'PyCF' "project" for building good wrappers for CoreFoundation(-based) APIs? This could be done by changing the bgen scripts in MacPython, adapting the CodeGenerator scripts from PyObjC or writing something from scratch. > - It might be useful from ObjC someday. Surely by someone in the > ObjC community that isn't using any or a lot of Python yet. > - The SystemConfiguration framework has awkward rules about when you > need to check for errors, so I'd have to write a lot of helpers by > hand anyway. Since bgen helpers are in C, not ObjC, it would be much > more of a pain in the ass to write them (i.e. more like 20 lines of > code per hand-wrapped function instead of an average of maybe 4 here). Your ObjC wrappers seem to use a seperate function for raising the exception. A simular solution could be used in bgen-based wrappers (which could use ObjC to access the contents of CFArray/NSArray instances). Ronald From bob at redivi.com Sun Oct 19 15:14:05 2003 From: bob at redivi.com (Bob Ippolito) Date: Sun Oct 19 15:14:42 2003 Subject: [Pythonmac-SIG] ANN: Preview of SystemConfiguration wrapper In-Reply-To: Message-ID: <6814CE6E-0268-11D8-B59D-000A95686CD8@redivi.com> On Sunday, Oct 19, 2003, at 12:52 America/New_York, Ronald Oussoren wrote: > > On 19 okt 2003, at 15:25, Bob Ippolito wrote: > >> >> On Sunday, Oct 19, 2003, at 08:57 America/New_York, Ronald Oussoren >> wrote: >> >>> >>> On 19 okt 2003, at 9:51, Bob Ippolito wrote: >>> >>>> http://undefined.org/python/SystemConfiguration-0.1.tar.gz >>>> >>>> This is a source distribution, it requires PyObjC and Developer >>>> Tools. The wrapper itself is (entirely) an ObjC framework, but it >>>> includes everything necessary for Python wrapping. I haven't done >>>> any documentation, real tests, especially testing of the runloop >>>> integration.. but here it is if someone wants to play with it. The >>>> ObjC is a little sloppy (three classes in one file), and the >>>> setup.py is a lot sloppy (thanks to distutils being not easily >>>> extensible), but it works.. or at least it should. >>> >>> I haven't looked at your code yet, but wouldn't it be better to >>> generate the wrapper using bgen? That would make the wrapper easier >>> to maintain and easier to integrate into MacPython/the python core. >>> >>> The CodeGenerator scripts in PyObjC could also be coaxed into >>> generating a functioning wrapper That is, without significant >>> changes to the scripts. The prototypes are different enough to >>> require changes to the "parser". >> >> I decided against bgen for a couple reasons: >> - bgen is hard to use > > Yup, that's why PyObjC contains Scripts/CodeGenerator :-), writing > those scripts was easier than getting bgen to work correctly. > > As I never managed to get a working bgen setup I cannot say if bgen is > really hard to use or if it's just the lack of documentation that > makes it so hard to use. I've done it before, it's not super hard.. if you look at the PyQTSequence application on http://undefined.org/python/ I have the Quicktime bgen wrapper building outside the Python source tree. > >> - I'm not yet convinced that the code generators save that much time >> in the long run > > An important advantage of code generators is that you end up with a > consistantly translated API. This may not be the perfect API, but > makes it so much easier to use existing documentation and examples > (all targetting the C API) when writing Python scripts that use the > wrapped API. Sure. That can be solved though even if you rename the methods by keeping metadata as to what is wrapped. I've been thinking about doing that but I wanted to write the wrapper and not a code generator at this point. >> - I wrote it by mostly by hand so I know that each and every method >> has been "audited" by someone to at least look like it should work ;) >> - Using a bgen-generated Python module doesn't feel much better than >> coding in C. These are named so that the module feels like they're >> using PyObjC. > > See me previous point, a more python-like interface is not necessarily > an advantage. That won't keep me from using your wrappers though, the > look pretty usefull as they are. > >> - SystemConfiguration is one of those >> should've-already-been-wrapped-in-ObjC-by-Apple frameworks that uses >> a lot of CoreFoundation types, so the bridge code is already in >> PyObjC for the most part (lots of CFDictionaryRef, CFArray, CFString, >> etc.) > > I've been thinking about this. Should there be a 'PyCF' "project" for > building good wrappers for CoreFoundation(-based) APIs? This could be > done by changing the bgen scripts in MacPython, adapting the > CodeGenerator scripts from PyObjC or writing something from scratch. Maybe, but the ObjC stuff is pretty good at wrapping CoreFoundation APIs. >> - It might be useful from ObjC someday. Surely by someone in the >> ObjC community that isn't using any or a lot of Python yet. > >> - The SystemConfiguration framework has awkward rules about when you >> need to check for errors, so I'd have to write a lot of helpers by >> hand anyway. Since bgen helpers are in C, not ObjC, it would be much >> more of a pain in the ass to write them (i.e. more like 20 lines of >> code per hand-wrapped function instead of an average of maybe 4 >> here). > > Your ObjC wrappers seem to use a seperate function for raising the > exception. A simular solution could be used in bgen-based wrappers > (which could use ObjC to access the contents of CFArray/NSArray > instances). I wanted to raise the exception with as much information as possible.. I wrote a script to take the enumerator out of the header file and extract the documentation as well so it can raise that (see the huge +load). I didn't want to mess with anything Python specific so it can be used from pure ObjC. I think there's a demand for a nicer wrapper than MoreSCF, because I don't see a lot of people using SystemConfiguration yet. -bob From sarwat at sarwat.net Sun Oct 19 17:32:34 2003 From: sarwat at sarwat.net (Sarwat Khan) Date: Sun Oct 19 17:32:43 2003 Subject: [Pythonmac-SIG] Tips for using Python scripts from OS X apps Message-ID: I've released the latest version of my port of BitTorrent to Mac OS X, which has an Objective-C Cocoa front-end GUI and a Python back-end BitTorrent implementation. I thought I'd share some of the stuff I did as it's useful to anyone who wants to use /usr/bin/python on Mac OS X to run Python scripts in their OS X programs. I expect this post to be mostly one for the archives :) When I first shipped the thing, I shipped it with .pyo files for Python 2.2. These don't work on Python 2.3, which comes with Panther. After thinking about it for a while, I decided that what I want to do is include optimized code for both py2.2 and py2.3, as well as include the raw source code in case if the user has a version of Python that I don't expect. Python 2.3+'s zipimport module makes this feasible. When BitTorrentAgent initializes, it first reads a plist which describes the various optimized packages that are installed with the application. It compares this with /usr/bin/python, and then sets up some globals to make sure that things run smoothly, so that it uses the correct package for /usr/bin/python. The process of generating this plist is done by a script. You use it like this, % python2.3 BitTorrentAgent/Scripts/DefineInterpreters.py define ==> Defined python2.3 zipimport: 1 % python2.2 BitTorrentAgent/Scripts/DefineInterpreters.py define --no-zip ==> Defined python2.2 zipimport: 0 Defining an interpreter does two things. In addition to generating the plist for use by BitTorrentAgent's initialization routine, it maintains another dictionary that maps, for example, python2.3 <==> /usr/local/bin/python2.3. A Project Builder Build Phase uses this dictionary to compile the .py files into .pyo files when creating the optimized python2.3 package. The point of describing all of this is just to say that it's automated. You tell the one script which versions of python you want optimizations for and what kind of output you want (zip or no zip, zip is the default), and the build process will put those optimized packages into the build product's bundle for you. When your build product executes, it will read the generated plist and pick the right package for the user's python. If there is no optimized build for the user's python, it falls back to the raw source code. All the code and scripts in the BitTorrentAgent stuff that handles this is in the following files, - btagent.h - btagent_posix.c - implementation of btagent.h using posix API. - forks python, shuts down python, reads and writes to and from stdio with it. - btagent_posix_cf.c - implementation of btagent.h using posix and CoreFoundation API - This contains the initialization routine that reads the plist using CoreFoundation. - main.m - sets up the process group and signal handlers for the application process None of that is really specific to BitTorrent and the techniques can be applied to any app that needs to work with Python scripts. The scripts that manage the build process are the following, - BitTorrentAgent/Scripts/DefinePythonInterpreters.py - Lets you define and undefine Python executables and list their configured options - BitTorrentAgent/Scripts/InstallBitTorrentModules.py - Copies code from hard-coded source code directories and compiles them for each defined python interpreter with their configured options. Called during a build phase. The last thing worth mentioning is that the latest release of my BitTorrent port has BitTorrentAgent as a framework. That means you can embed BitTorrentAgent.framework into your applications and include BitTorrent seeding/downloading functionality. All without needing to rewrite BitTorrent into a C++ library, which so many people seem to be fond of doing... You can get the source from http://sarwat.net/opensource/ {sarwat khan : http://sarwat.net} From lyris-noreply at lyris.komando.com Sun Oct 19 19:42:45 2003 From: lyris-noreply at lyris.komando.com (Lyris ListManager) Date: Sun Oct 19 20:37:04 2003 Subject: [Pythonmac-SIG] You've left the Kim Komando Show Newsletter :/ Message-ID: Hello! Oh no, say it's not so! You're leaving us? Really? It looks like that you have successfully unsubscribed from The Kim Komando Show Free Electronic Newsletter with the following address: pythonmac-sig@python.org If you did not want to really unsubscribe or want to subscribe again just send an e-mail to: join-kimsnewsletter@lyris.komando.com We'd love to have you back. :) Cordially, Kim Komando The Kim Komando Show Free Electronic Newsletter http://www.komando.com From lyris-noreply at lyris.komando.com Mon Oct 20 10:36:38 2003 From: lyris-noreply at lyris.komando.com (Lyris ListManager) Date: Mon Oct 20 11:30:59 2003 Subject: [Pythonmac-SIG] You've left the Kim Komando Show Newsletter :/ Message-ID: Hello! Oh no, say it's not so! You're leaving us? Really? It looks like that you have successfully unsubscribed from The Kim Komando Show Free Electronic Newsletter with the following address: pythonmac-sig@python.org If you did not want to really unsubscribe or want to subscribe again just send an e-mail to: join-kimsnewsletter@lyris.komando.com We'd love to have you back. :) Cordially, Kim Komando The Kim Komando Show Free Electronic Newsletter http://www.komando.com From Leo.Broska at isys.com.au Tue Oct 21 03:27:04 2003 From: Leo.Broska at isys.com.au (Leo Broska) Date: Tue Oct 21 03:26:47 2003 Subject: [Pythonmac-SIG] python search paths Message-ID: <3C254B3516645947A40D65263A3B9FE8031889@osiris.odyssey.local> hi there one silly question at the beginning: how can i extend the python search paths? i guess i need that for installing aeve for apple event handling, because right now i get an error when i run setup: Traceback (most recent call last): File "/Users/leo/dev/python/aeve-0.0.3/setup.py", line 5, in ? import aeve File "/Users/leo/dev/python/aeve-0.0.3/aeve/__init__.py", line 30, in ? import aetypes File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/__init__.py", line 5, in ? from aeclass import * File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/aeclass.py", line 1, in ? from aecomplex import BaseClass File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/aecomplex.py", line 4, in ? from aesimple import Type, Enum, FourCharCode, AbsoluteOrdinal File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/aesimple.py", line 8, in ? import TECManager as TE ImportError: No module named TECManager any idea? thanks, leo From helloleo at netspace.net.au Tue Oct 21 03:37:11 2003 From: helloleo at netspace.net.au (helloleo) Date: Tue Oct 21 03:36:50 2003 Subject: [Pythonmac-SIG] python search paths // try to use aeve Message-ID: <00d001c397a6$24037ec0$a800000a@Odyssey.local> hi there one silly question at the beginning: how can i extend the python search paths? i guess i need that for installing aeve for apple event handling, because right now i get an error when i run setup: Traceback (most recent call last): File "/Users/leo/dev/python/aeve-0.0.3/setup.py", line 5, in ? import aeve File "/Users/leo/dev/python/aeve-0.0.3/aeve/__init__.py", line 30, in ? import aetypes File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/__init__.py", line 5, in ? from aeclass import * File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/aeclass.py", line 1, in ? from aecomplex import BaseClass File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/aecomplex.py", line 4, in ? from aesimple import Type, Enum, FourCharCode, AbsoluteOrdinal File "/Users/leo/dev/python/aeve-0.0.3/aeve/aetypes/aesimple.py", line 8, in ? import TECManager as TE ImportError: No module named TECManager any idea? thanks, leo From helloleo at netspace.net.au Tue Oct 21 03:39:58 2003 From: helloleo at netspace.net.au (helloleo) Date: Tue Oct 21 03:39:37 2003 Subject: [Pythonmac-SIG] gensuitemodule.py tried for aete Message-ID: <00d601c397a6$87736d80$a800000a@Odyssey.local> hi again sorry, i had another try with apple events, now with "aete"??? (seems to be built in macpython...) i called gensuitemodule.py (which seems to be related to "aete") in order to generate a dictionary, but i get the following error msg: ASKING FOR aete DICTIONARY IN '/Applications/Address Book.app' GetAppTerminology failed with errAEDescNotFound/resNotFound, trying manually Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/ge nsuitemodule.py", line 1212, in ? main() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/ge nsuitemodule.py", line 93, in main main_interactive() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/ge nsuitemodule.py", line 116, in main_interactive verbose=sys.stderr) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/ge nsuitemodule.py", line 197, in processfile aedata, sig = getappterminology(fullname, verbose=verbose) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/ge nsuitemodule.py", line 253, in getappterminology return reply[1]['----'], cr KeyError: '----' where does the error come from? thanks for any advice, leo From herndonp at mskcc.org Tue Oct 21 10:28:50 2003 From: herndonp at mskcc.org (Peter Herndon) Date: Tue Oct 21 10:29:08 2003 Subject: [Pythonmac-SIG] PostgreSQL and PL/Python Message-ID: Hello all, Has anyone had any success getting plpython to compile successfully for PostgreSQL? I am running OS 10.2.8, MacPython 2.3.2, and am working with PostgreSQL 7.4beta4. I've also tried with 7.3.4, and ran into even uglier errors -- it claims there's a syntax error in /usr/include/math.h -- so I stopped and tried with the latest beta. My results are somewhat frustrating, as I seem to be running into a problem with linking in the shared version of the Python library. I have set LDFLAGS to '-u __dummy -u_PyMac_Error -framework System -framework Python -framework CoreServices -framework Foundation', as per the Python documentation's advice (>>>import distutils.sysconfig, >>>distutils.sysconfig.get_config_var('LINKFORSHARED'). I have set my PATH to include /usr/local/bin, so as to find my updated python first. My ./configure options are straight-forward, './configure --with-perl --with-python --with-rendezvous --with-openssl --without-readline', and seem to work just fine. I'm suspicious of the last line, though. The relevant output is: checking for python... /usr/local/bin/python checking Python installation directories... /Library/Frameworks/Python.framework/Version/2.3/lib/python2.3 checking how to link an embedded Python application... -L/Library/Frameworks/Python.framework/Version/2.3/lib/python2.3/config -lpython2.3 However, when I run make, I get the following: plpython.c:41:19: dlfcn.h: No such file or directory [snip warnings regarding use of long double] make[3]: *** [plpython.o] Error 1 I took a look at plpython.c, and it is simply including dlfcn.h, so I looked at dlfcn.h and found two separate versions. One version is in postgresql-7.4beta4/src/include/port/win32/dlfcn.h, and is blank. The other is in my python 2.3.2 source tree, Python-2.3.2/PC/os2emx/dlfcn.h, and according to the comments in the file it "implements dlopen() -- Unix-like dynamic linking emulation functions for OS/2 using DosLoadModule() and company". It didn't seem relevant at all, so I commented out the include line in plpython.c, and tried again. My make results this time were somewhat more to the point, though no less frustrating. The output: [snip] gcc -no-cpp-precomp -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -bundle plpython.o -L../../../src/port -bundle_loader ../../../src/backend/postgres -L/Library/Frameworks/Python.framework/Version/2.3/lib/python2.3/config -lpython2.3 -o libplpython.so.0.0 ld: can't locate file for: -lpython2.3 make[3]: *** [libplpython.so.0.0] Error 1 [snip] Now, this is looking a lot like PostgreSQL's configure script, particularly the third output line quoted above, is somewhat ignorant of how to handle a framework build of Python as a shared library under OS X. Am I correct? How do I go about correcting this problem, does anyone have any hints on this one? FWIW, the PostgreSQL archives are remarkably reticent on the subject of compiling under OS X, and there are zero mentions of how to deal with building pl/python. Thanks in advance. ---Peter Herndon ===================================================================== Please note that this e-mail and any files transmitted with it may be privileged, confidential, and protected from disclosure under applicable law. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this communication or any of its attachments is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting this message, any attachments, and all copies and backups from your computer. From apicard at adobe.com Tue Oct 21 13:06:09 2003 From: apicard at adobe.com (Antoine Picard) Date: Tue Oct 21 13:11:36 2003 Subject: [Pythonmac-SIG] Japanese UI in Tkinter In-Reply-To: <06DC4E6D-023A-11D8-B59D-000A95686CD8@redivi.com> References: <06DC4E6D-023A-11D8-B59D-000A95686CD8@redivi.com> Message-ID: Thank you for your input. Unfortunately, it seems that wxpython for OSX does not support Unicode in its current version. I guess I'll have to see how far I can get with Tkaqua (I can at least get some glyphs to show up in Japanese although not all). -- Antoine Picard Type Department Adobe Systems Inc. From bob at redivi.com Tue Oct 21 15:29:57 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 21 15:30:35 2003 Subject: [Pythonmac-SIG] python search paths // try to use aeve In-Reply-To: <00d001c397a6$24037ec0$a800000a@Odyssey.local> Message-ID: On Tuesday, Oct 21, 2003, at 03:37 America/New_York, helloleo wrote: > hi there > > one silly question at the beginning: how can i extend the python search > paths? > > i guess i need that for installing aeve for apple event handling, > because > right now i get an error when i run setup: aeve depends on TECManager ( http://undefined.org/python/#TECManager ) and LaunchServices ( http://undefined.org/python/#LaunchServices ). The easiest way to get these extension modules is from my Package Manager repository, go to http://undefined.org/python/pimp/ for instructions. Just install aeve from there, and that should install both aeve and the dependencies. -bob From Jack.Jansen at cwi.nl Tue Oct 21 16:26:43 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Oct 21 16:26:48 2003 Subject: [Pythonmac-SIG] Please explain this PackageManager message In-Reply-To: References: Message-ID: On 19-okt-03, at 0:38, Bob Ippolito wrote: > Just FYI, this weekend I'm writing an ObjC wrapper for the > SystemConfiguration framework (I expect to finish it tonight or > tomorrow), which gives us access (via PyObjC) to a whole slew of > things including but not limited to network and proxy settings, which > would also be useful for the next iteration of PackageManager among > other things. Great! But note that we have access to most of those already, probably, through the IC module. The InternetConfig implementation on OSX uses the network preferences under the hood. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Tue Oct 21 16:35:21 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 21 16:35:57 2003 Subject: [Pythonmac-SIG] Please explain this PackageManager message In-Reply-To: Message-ID: <1727C70B-0406-11D8-A87E-000A95686CD8@redivi.com> On Tuesday, Oct 21, 2003, at 16:26 America/New_York, Jack Jansen wrote: > > On 19-okt-03, at 0:38, Bob Ippolito wrote: >> Just FYI, this weekend I'm writing an ObjC wrapper for the >> SystemConfiguration framework (I expect to finish it tonight or >> tomorrow), which gives us access (via PyObjC) to a whole slew of >> things including but not limited to network and proxy settings, which >> would also be useful for the next iteration of PackageManager among >> other things. > > Great! But note that we have access to most of those already, > probably, through the IC module. The InternetConfig implementation on > OSX uses the network preferences under the hood. InternetConfig uses SystemConfiguration in its implementation, and is deprecated for new applications. SystemConfiguration also lets you go regex searching for stuff, and let's you get change notifications. It's rather interesting, especially because you get access to Airport data (signal strength, network, etc) as well as power management settings and battery level. -bob From helloleo at netspace.net.au Wed Oct 22 10:18:46 2003 From: helloleo at netspace.net.au (Leo) Date: Wed Oct 22 10:18:42 2003 Subject: [Pythonmac-SIG] dict for addressbook? (was: Re: python search paths // try to use aeve) In-Reply-To: References: Message-ID: <3F9691C6.3060104@netspace.net.au> thanks bob, now it works: could automate iTunes. but where do i now get a python dictionary for the address book application? cheers, leo Bob Ippolito wrote: > > On Tuesday, Oct 21, 2003, at 03:37 America/New_York, helloleo wrote: > >> hi there >> >> one silly question at the beginning: how can i extend the python search >> paths? >> >> i guess i need that for installing aeve for apple event handling, >> because >> right now i get an error when i run setup: > > > aeve depends on TECManager ( http://undefined.org/python/#TECManager ) > and LaunchServices ( http://undefined.org/python/#LaunchServices ). > The easiest way to get these extension modules is from my Package > Manager repository, go to http://undefined.org/python/pimp/ for > instructions. Just install aeve from there, and that should install > both aeve and the dependencies. > > -bob > From Martina at Oefelein.de Wed Oct 22 16:02:38 2003 From: Martina at Oefelein.de (Martina Oefelein) Date: Wed Oct 22 16:02:40 2003 Subject: [Pythonmac-SIG] dict for addressbook? (was: Re: python search paths // try to use aeve) In-Reply-To: <3F9691C6.3060104@netspace.net.au> Message-ID: Hi Leo, > but where do i now get a python dictionary for the address book > application? I don't know if AddressBook.app is scriptable, but you can call the AddressBook API using PyObjC. ciao Martina From cjl at physics.otago.ac.nz Wed Oct 22 16:36:29 2003 From: cjl at physics.otago.ac.nz (Chris Lee) Date: Wed Oct 22 16:36:54 2003 Subject: [Pythonmac-SIG] MatFunc.py Message-ID: <69FD028C-04CF-11D8-987C-0003937807FC@physics.otago.ac.nz> Hi All, The other day I was searching for a curve fitting module (It turns out that our Matlab license doesn't cover the curve fitting toolbox). I found a module Matfunc.py but the urls leading to the actual module are broken. I was wondering if anyone has installed it or can send me a copy? Cheers Chris ########################## #Chris Lee # #Department of Physics # #Phone: ++64 3 4797750 # #Fax: ++64 3 4790964 # ########################## From helloleo at netspace.net.au Thu Oct 23 03:11:09 2003 From: helloleo at netspace.net.au (helloleo) Date: Thu Oct 23 03:10:49 2003 Subject: [Pythonmac-SIG] dict for addressbook? (was: Re: python search paths // try to use aeve) References: Message-ID: <00af01c39934$d5ba2080$a800000a@Odyssey.local> well, AddressBook *is* scriptable, but how and where do i find the functions and classes i can use via python? for itunes there was demo page on the aeve website... cheers, leo ----- Original Message ----- From: "Martina Oefelein" To: "Leo" Cc: Sent: Thursday, October 23, 2003 6:02 AM Subject: Re: [Pythonmac-SIG] dict for addressbook? (was: Re: python search paths // try to use aeve) > Hi Leo, > > > but where do i now get a python dictionary for the address book > > application? > > I don't know if AddressBook.app is scriptable, but you can call the > AddressBook API using PyObjC. > > ciao > Martina > > From eric at wichterich.net Thu Oct 23 05:07:07 2003 From: eric at wichterich.net (Eric Wichterich) Date: Thu Oct 23 05:07:13 2003 Subject: [Pythonmac-SIG] How to import libraries on Mac OS X? In-Reply-To: Message-ID: <46DC2D7B-0538-11D8-B36E-00039315E356@wichterich.net> Hello Pythonistas, I've written a Python library with some functions I want to use with other Python scripts. The library is located at (Mac OS X): /Users/username/Sites/projectname/cgi-bin/name_of_library.py (My scripts are located in this directory, too.) I use the statement: "from name_of_library import special_function" to import this special_function. When I launch the Apache-Server and call a script which wants to import this library, I get a "malformed header" error. But importing standard libraries, such as "from string import *", no error occurs. Maybe some environment variables must be set. But which? Any ideas? Thank you, Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 709 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031023/a0b2b1e4/attachment.bin From oussoren at cistron.nl Thu Oct 23 15:53:49 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Thu Oct 23 15:53:58 2003 Subject: [Pythonmac-SIG] dict for addressbook? (was: Re: python search paths // try to use aeve) In-Reply-To: <00af01c39934$d5ba2080$a800000a@Odyssey.local> References: <00af01c39934$d5ba2080$a800000a@Odyssey.local> Message-ID: <9E9B5778-0592-11D8-A4AE-0003931CFE24@cistron.nl> Do you really want to script AddressBook? If you want to change the contents of the addressbook database you can just as easily use the AddressBook bindings of PyObjC. If you really want to use applescript, the link below contains information about how you can create a wrapper module for an application's AppleScript dictionary (step 15): http://pyobjc.sourceforge.net/doc/extending_objc_with_python.php Ronald On 23 okt 2003, at 9:11, helloleo wrote: > well, AddressBook *is* scriptable, but how and where do i find the > functions > and classes i can use via python? > > for itunes there was demo page on the aeve website... > > cheers, leo > > ----- Original Message ----- > From: "Martina Oefelein" > To: "Leo" > Cc: > Sent: Thursday, October 23, 2003 6:02 AM > Subject: Re: [Pythonmac-SIG] dict for addressbook? (was: Re: python > search > paths // try to use aeve) > > >> Hi Leo, >> >>> but where do i now get a python dictionary for the address book >>> application? >> >> I don't know if AddressBook.app is scriptable, but you can call the >> AddressBook API using PyObjC. >> >> ciao >> Martina >> >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From eric at wichterich.net Thu Oct 23 16:08:36 2003 From: eric at wichterich.net (Eric Wichterich) Date: Thu Oct 23 16:08:53 2003 Subject: [Pythonmac-SIG] How to import libraries on Mac OS X? In-Reply-To: <553BBA10-0582-11D8-84FD-003065C9DF8C@sarwat.net> Message-ID: Hello Sarwat, the entry of the error_log is: [Thu Oct 23 21:54:46 2003] [error] [client 123.456.654.321] malformed header from script. Bad header= from name_of_library impo: /Users/username/Sites/projectname/cgi-bin/script.cgi The files were set to chmod "755". Greetings, Eric Am Donnerstag, 23.10.03 um 19:57 Uhr schrieb Sarwat Khan: > You should check /var/log/httpd/error_log for a description of the > error. > > What's likely to be happening is that when you try to import your > library, Python writes an error to out, and Apache sees this instead > of the standard HTTP header text that's supposed to be printed. So > Apache prints the malformed header stuff. > > You might want to make sure that the files in cgi-bin are world > readable, and that cgi-bin are world-executable (searchable). > > On Thursday, October 23, 2003, at 05:07 AM, Eric Wichterich wrote: > >> Hello Pythonistas, >> >> I've written a Python library with some functions I want to use with >> other Python scripts. >> The library is located at (Mac OS X): >> /Users/username/Sites/projectname/cgi-bin/name_of_library.py >> (My scripts are located in this directory, too.) >> >> I use the statement: "from name_of_library import special_function" >> to import this special_function. >> >> When I launch the Apache-Server and call a script which wants to >> import this library, I get a "malformed header" error. >> >> But importing standard libraries, such as "from string import *", no >> error occurs. >> >> Maybe some environment variables must be set. But which? Any ideas? >> >> Thank you, >> Eric >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > {sarwat khan : http://sarwat.net} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1858 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031023/a4939e2f/attachment.bin From eric.wichterich at gmx.de Fri Oct 24 04:23:50 2003 From: eric.wichterich at gmx.de (Eric Wichterich) Date: Fri Oct 24 04:24:03 2003 Subject: [Pythonmac-SIG] How to import libraries on Mac OS X? In-Reply-To: <12DBDDBE-05D1-11D8-BFC8-003065C9DF8C@sarwat.net> Message-ID: <657FEF3C-05FB-11D8-908E-00039315E356@gmx.de> Yes, there is a sh-bang at the top of the script: #!/usr/local/bin/python The script runs if I comment the statement "from name_of_library import special_function" out (except the error because of the missing functions which are in the library ;) ). The Apache-Config is set to allow cgis to execute in that directory. Options Indexes ExecCGI MultiViews AllowOverride None Order allow,deny Allow from all Am Freitag, 24.10.03 um 05:20 Uhr schrieb Sarwat Khan: > Do you have a sh-bang at the top of your script? Like > > #! /usr/bin/env python > > I don't think your script is running as a Python script. You might > want to take a look at the Python CGI FAQ here, > > http://starship.python.net/crew/davem/cgifaq/ > faqw.cgi?req=show&file=faq01.001.htp > > On Thursday, October 23, 2003, at 04:08 PM, Eric Wichterich wrote: > >> Hello Sarwat, >> >> the entry of the error_log is: >> [Thu Oct 23 21:54:46 2003] [error] [client 123.456.654.321] malformed >> header from script. Bad header= from name_of_library impo: >> /Users/username/Sites/projectname/cgi-bin/script.cgi >> >> The files were set to chmod "755". >> >> Greetings, >> Eric >> >> Am Donnerstag, 23.10.03 um 19:57 Uhr schrieb Sarwat Khan: >> >>> You should check /var/log/httpd/error_log for a description of the >>> error. >>> >>> What's likely to be happening is that when you try to import your >>> library, Python writes an error to out, and Apache sees this instead >>> of the standard HTTP header text that's supposed to be printed. So >>> Apache prints the malformed header stuff. >>> >>> You might want to make sure that the files in cgi-bin are world >>> readable, and that cgi-bin are world-executable (searchable). >>> >>> On Thursday, October 23, 2003, at 05:07 AM, Eric Wichterich wrote: >>> >>>> Hello Pythonistas, >>>> >>>> I've written a Python library with some functions I want to use >>>> with other Python scripts. >>>> The library is located at (Mac OS X): >>>> /Users/username/Sites/projectname/cgi-bin/name_of_library.py >>>> (My scripts are located in this directory, too.) >>>> >>>> I use the statement: "from name_of_library import >>>> special_function" to import this special_function. >>>> >>>> When I launch the Apache-Server and call a script which wants to >>>> import this library, I get a "malformed header" error. >>>> >>>> But importing standard libraries, such as "from string import *", >>>> no error occurs. >>>> >>>> Maybe some environment variables must be set. But which? Any ideas? >>>> >>>> Thank you, >>>> Eric >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>> >>> {sarwat khan : http://sarwat.net} >>> > > {sarwat khan : http://sarwat.net} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2881 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031024/20540466/attachment.bin From oussoren at cistron.nl Fri Oct 24 06:15:33 2003 From: oussoren at cistron.nl (Ronald Oussoren) Date: Fri Oct 24 06:15:37 2003 Subject: [Pythonmac-SIG] How to import libraries on Mac OS X? In-Reply-To: <657FEF3C-05FB-11D8-908E-00039315E356@gmx.de> References: <657FEF3C-05FB-11D8-908E-00039315E356@gmx.de> Message-ID: <008E5EC0-060B-11D8-A4AE-0003931CFE24@cistron.nl> What version of pyton do you use? Python 2.3 includes a module named cgitb that would be usefull here. At the top of you script add: import cgitb; cgitb.enable(). You will then be able to see the exceptions generated by your CGI-script. Ronald On 24 okt 2003, at 10:23, Eric Wichterich wrote: > Yes, there is a sh-bang at the top of the script: > #!/usr/local/bin/python > > The script runs if I comment the statement "from name_of_library > import special_function" out (except the error because of the missing > functions which are in the library ;) ). > > The Apache-Config is set to allow cgis to execute in that directory. > > Options Indexes ExecCGI MultiViews > AllowOverride None > Order allow,deny > Allow from all > > > > > Am Freitag, 24.10.03 um 05:20 Uhr schrieb Sarwat Khan: > >> Do you have a sh-bang at the top of your script? Like >> >> #! /usr/bin/env python >> >> I don't think your script is running as a Python script. You might >> want to take a look at the Python CGI FAQ here, >> >> http://starship.python.net/crew/davem/cgifaq/faqw.cgi? >> req=show&file=faq01.001.htp >> >> On Thursday, October 23, 2003, at 04:08 PM, Eric Wichterich wrote: >> >>> Hello Sarwat, >>> >>> the entry of the error_log is: >>> [Thu Oct 23 21:54:46 2003] [error] [client 123.456.654.321] >>> malformed header from script. Bad header= from name_of_library >>> impo: /Users/username/Sites/projectname/cgi-bin/script.cgi >>> >>> The files were set to chmod "755". >>> >>> Greetings, >>> Eric >>> >>> Am Donnerstag, 23.10.03 um 19:57 Uhr schrieb Sarwat Khan: >>> >>>> You should check /var/log/httpd/error_log for a description of the >>>> error. >>>> >>>> What's likely to be happening is that when you try to import your >>>> library, Python writes an error to out, and Apache sees this >>>> instead of the standard HTTP header text that's supposed to be >>>> printed. So Apache prints the malformed header stuff. >>>> >>>> You might want to make sure that the files in cgi-bin are world >>>> readable, and that cgi-bin are world-executable (searchable). >>>> >>>> On Thursday, October 23, 2003, at 05:07 AM, Eric Wichterich wrote: >>>> >>>>> Hello Pythonistas, >>>>> >>>>> I've written a Python library with some functions I want to use >>>>> with other Python scripts. >>>>> The library is located at (Mac OS X): >>>>> /Users/username/Sites/projectname/cgi-bin/name_of_library.py >>>>> (My scripts are located in this directory, too.) >>>>> >>>>> I use the statement: "from name_of_library import >>>>> special_function" to import this special_function. >>>>> >>>>> When I launch the Apache-Server and call a script which wants to >>>>> import this library, I get a "malformed header" error. >>>>> >>>>> But importing standard libraries, such as "from string import *", >>>>> no error occurs. >>>>> >>>>> Maybe some environment variables must be set. But which? Any ideas? >>>>> >>>>> Thank you, >>>>> Eric >>>>> _______________________________________________ >>>>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>>> >>>> >>>> {sarwat khan : http://sarwat.net} >>>> >> >> {sarwat khan : http://sarwat.net} > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3295 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031024/d92d0942/attachment.bin From pecora at anvil.nrl.navy.mil Fri Oct 24 10:53:09 2003 From: pecora at anvil.nrl.navy.mil (Louis M. Pecora) Date: Fri Oct 24 10:53:12 2003 Subject: [Pythonmac-SIG] Where's EditPythonPrefs ?? Message-ID: I finally made the change to OS X and downloaded and installed MacPython-2.3. But... I cannot find EditPythonPrefs. The documentation and help tell me to use it to add the path to my modules, but the only copies I have are old system 9 ones. Nothing like EditPythonPrefs seems to be in the new MacPython 2.3. Am I missing something. I've spent some time going through the help files, but I can't find a clue. Can anyone point me to how to add paths to modules with 2.3? Thanks for any help. -- Cheers, Lou Pecora -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20031024/9ee3815d/attachment.html From eric.wichterich at gmx.de Fri Oct 24 11:34:11 2003 From: eric.wichterich at gmx.de (Eric Wichterich) Date: Fri Oct 24 11:34:23 2003 Subject: [Pythonmac-SIG] How to import libraries on Mac OS X? In-Reply-To: <008E5EC0-060B-11D8-A4AE-0003931CFE24@cistron.nl> Message-ID: <83F04A7E-0637-11D8-8FE2-00039315E356@gmx.de> Thank you Ronald, I figured out that there is a problem with Apache and CGI, not with importing the library anymore. There is something Apache doesn't like. I only get the two different errors: Malformed header - or - premature end of file. These scripts work fine on a linux server with Apache... I'll keep working on it. It's just frustrating. Eric Am Freitag, 24.10.03 um 12:15 Uhr schrieb Ronald Oussoren: > What version of pyton do you use? Python 2.3 includes a module named > cgitb that would be usefull here. At the top of you script add: import > cgitb; cgitb.enable(). You will then be able to see the exceptions > generated by your CGI-script. > > > > Ronald > > On 24 okt 2003, at 10:23, Eric Wichterich wrote: > >> Yes, there is a sh-bang at the top of the script: >> #!/usr/local/bin/python >> >> The script runs if I comment the statement "from name_of_library >> import special_function" out (except the error because of the missing >> functions which are in the library ;) ). >> >> The Apache-Config is set to allow cgis to execute in that directory. >> >> Options Indexes ExecCGI MultiViews >> AllowOverride None >> Order allow,deny >> Allow from all >> >> >> >> >> Am Freitag, 24.10.03 um 05:20 Uhr schrieb Sarwat Khan: >> >>> Do you have a sh-bang at the top of your script? Like >>> >>> #! /usr/bin/env python >>> >>> I don't think your script is running as a Python script. You might >>> want to take a look at the Python CGI FAQ here, >>> >>> http://starship.python.net/crew/davem/cgifaq/ >>> faqw.cgi?req=show&file=faq01.001.htp >>> >>> On Thursday, October 23, 2003, at 04:08 PM, Eric Wichterich wrote: >>> >>>> Hello Sarwat, >>>> >>>> the entry of the error_log is: >>>> [Thu Oct 23 21:54:46 2003] [error] [client 123.456.654.321] >>>> malformed header from script. Bad header= from name_of_library >>>> impo: /Users/username/Sites/projectname/cgi-bin/script.cgi >>>> >>>> The files were set to chmod "755". >>>> >>>> Greetings, >>>> Eric >>>> >>>> Am Donnerstag, 23.10.03 um 19:57 Uhr schrieb Sarwat Khan: >>>> >>>>> You should check /var/log/httpd/error_log for a description of the >>>>> error. >>>>> >>>>> What's likely to be happening is that when you try to import your >>>>> library, Python writes an error to out, and Apache sees this >>>>> instead of the standard HTTP header text that's supposed to be >>>>> printed. So Apache prints the malformed header stuff. >>>>> >>>>> You might want to make sure that the files in cgi-bin are world >>>>> readable, and that cgi-bin are world-executable (searchable). >>>>> >>>>> On Thursday, October 23, 2003, at 05:07 AM, Eric Wichterich wrote: >>>>> >>>>>> Hello Pythonistas, >>>>>> >>>>>> I've written a Python library with some functions I want to use >>>>>> with other Python scripts. >>>>>> The library is located at (Mac OS X): >>>>>> /Users/username/Sites/projectname/cgi-bin/name_of_library.py >>>>>> (My scripts are located in this directory, too.) >>>>>> >>>>>> I use the statement: "from name_of_library import >>>>>> special_function" to import this special_function. >>>>>> >>>>>> When I launch the Apache-Server and call a script which wants to >>>>>> import this library, I get a "malformed header" error. >>>>>> >>>>>> But importing standard libraries, such as "from string import *", >>>>>> no error occurs. >>>>>> >>>>>> Maybe some environment variables must be set. But which? Any >>>>>> ideas? >>>>>> >>>>>> Thank you, >>>>>> Eric >>>>>> _______________________________________________ >>>>>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >>>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>>>> >>>>> >>>>> {sarwat khan : http://sarwat.net} >>>>> >>> >>> {sarwat khan : http://sarwat.net} >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3734 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031024/8c64e250/attachment-0001.bin From drewmccormack at mac.com Fri Oct 24 13:19:06 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Fri Oct 24 13:19:12 2003 Subject: [Pythonmac-SIG] iChat channel Message-ID: <2BF2A9E2-0646-11D8-AA5E-00039363BC02@mac.com> I just read on the CocoaDev list that they have a CocoaDev chat via iChat. I feel like someone has been having a massive party and I wasn't invited :-( Is there something like that for mac python development? If not, anyone interested? Maybe something like "MacPythonDev". The thing I like about IM is that you can get quick answers to little questions. A mailing list is great for the big debates and discussions, but the one liners are better handled through chat. Drew From bob at redivi.com Fri Oct 24 14:06:06 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 24 14:06:41 2003 Subject: [Pythonmac-SIG] iChat channel In-Reply-To: <2BF2A9E2-0646-11D8-AA5E-00039363BC02@mac.com> References: <2BF2A9E2-0646-11D8-AA5E-00039363BC02@mac.com> Message-ID: On Oct 24, 2003, at 1:19 PM, Drew McCormack wrote: > I just read on the CocoaDev list that they have a CocoaDev chat via > iChat. I feel like someone has been having a massive party and I > wasn't invited :-( > > Is there something like that for mac python development? If not, > anyone interested? Maybe something like "MacPythonDev". > > The thing I like about IM is that you can get quick answers to little > questions. A mailing list is great for the big debates and > discussions, but the one liners are better handled through chat. IRC probably makes more sense, because #python is also there. We could start a #macpython on irc.freenode.net From njriley at uiuc.edu Fri Oct 24 14:11:00 2003 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri Oct 24 14:12:41 2003 Subject: [Pythonmac-SIG] iChat channel In-Reply-To: References: <2BF2A9E2-0646-11D8-AA5E-00039363BC02@mac.com> Message-ID: <20031024181100.GA39428@uiuc.edu> On Fri, Oct 24, 2003 at 02:06:06PM -0400, Bob Ippolito wrote: > > On Oct 24, 2003, at 1:19 PM, Drew McCormack wrote: > > >I just read on the CocoaDev list that they have a CocoaDev chat via > >iChat. I feel like someone has been having a massive party and I > >wasn't invited :-( > > > >Is there something like that for mac python development? If not, > >anyone interested? Maybe something like "MacPythonDev". > > > >The thing I like about IM is that you can get quick answers to little > >questions. A mailing list is great for the big debates and > >discussions, but the one liners are better handled through chat. > > IRC probably makes more sense, because #python is also there. We could > start a #macpython on irc.freenode.net Or people could hang out on #macdev like I do... it's pretty low-traffic as is, especially in comparison with #python. -- =Nicholas Riley | From Martina at Oefelein.de Fri Oct 24 14:12:51 2003 From: Martina at Oefelein.de (Martina Oefelein) Date: Fri Oct 24 14:13:11 2003 Subject: [Pythonmac-SIG] How to import libraries on Mac OS X? In-Reply-To: <83F04A7E-0637-11D8-8FE2-00039315E356@gmx.de> Message-ID: Hi Eric, > I figured out that there is a problem with Apache and CGI, not with > importing the library anymore. There is something Apache doesn't like. > I only get the two different errors: Malformed header - or - premature > end of file. These scripts work fine on a linux server with Apache... check that your script has Unix line endings ciao Martina -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 424 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031024/262e9433/attachment.bin From bob at redivi.com Fri Oct 24 14:17:47 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 24 14:18:22 2003 Subject: [Pythonmac-SIG] iChat channel In-Reply-To: <20031024181100.GA39428@uiuc.edu> References: <2BF2A9E2-0646-11D8-AA5E-00039363BC02@mac.com> <20031024181100.GA39428@uiuc.edu> Message-ID: <5EA6EE8E-064E-11D8-9B7B-000A95686CD8@redivi.com> On Oct 24, 2003, at 2:11 PM, Nicholas Riley wrote: > On Fri, Oct 24, 2003 at 02:06:06PM -0400, Bob Ippolito wrote: >> >> On Oct 24, 2003, at 1:19 PM, Drew McCormack wrote: >> >>> I just read on the CocoaDev list that they have a CocoaDev chat via >>> iChat. I feel like someone has been having a massive party and I >>> wasn't invited :-( >>> >>> Is there something like that for mac python development? If not, >>> anyone interested? Maybe something like "MacPythonDev". >>> >>> The thing I like about IM is that you can get quick answers to little >>> questions. A mailing list is great for the big debates and >>> discussions, but the one liners are better handled through chat. >> >> IRC probably makes more sense, because #python is also there. We >> could >> start a #macpython on irc.freenode.net > > Or people could hang out on #macdev like I do... it's pretty > low-traffic as is, especially in comparison with #python. I've been in there a few times semi-recently and it's been pretty worthless for me.. two years ago there were a few people that knew what was up, but I think they worked for Apple or something :) I'd rather see a specific channel for MacPython. -bob From sarwat at sarwat.net Fri Oct 24 15:41:25 2003 From: sarwat at sarwat.net (Sarwat Khan) Date: Fri Oct 24 15:42:21 2003 Subject: [Pythonmac-SIG] iChat channel In-Reply-To: <20031024181100.GA39428@uiuc.edu> Message-ID: <0DCEF1C0-065A-11D8-ACCD-003065C9DF8C@sarwat.net> > Or people could hang out on #macdev like I do... it's pretty > low-traffic as is, especially in comparison with #python. I'd tip my hat to an iChat channel for MacPython though, given that it's much easier to access than an IRC channel (and the only free Mac IRC client I know of is ChatZilla, other than cli clients). {sarwat khan : http://sarwat.net} From israel at sandlotgames.com Fri Oct 24 21:36:16 2003 From: israel at sandlotgames.com (Israel C. Evans) Date: Fri Oct 24 21:36:40 2003 Subject: [Pythonmac-SIG] iChat channel In-Reply-To: <0DCEF1C0-065A-11D8-ACCD-003065C9DF8C@sarwat.net> Message-ID: I use x-chat ( http://www.xchat.org/about/ ) and Colloquy ( http://www.jump-ing.de/proj/colloquy.html ) for Mac os X. Both work fairly well. On Friday, October 24, 2003, at 12:41 PM, Sarwat Khan wrote: >> Or people could hang out on #macdev like I do... it's pretty >> low-traffic as is, especially in comparison with #python. > > I'd tip my hat to an iChat channel for MacPython though, given that > it's much easier to access than an IRC channel (and the only free Mac > IRC client I know of is ChatZilla, other than cli clients). > > {sarwat khan : http://sarwat.net} > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > ~Israel~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 830 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031024/4dd14f73/attachment.bin From bob at redivi.com Fri Oct 24 22:44:42 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 24 22:45:15 2003 Subject: [Pythonmac-SIG] Xcode + Python (pythonmac.org wiki) Message-ID: <2F4CA370-0695-11D8-ACD9-000A95686CD8@redivi.com> I've started an entry in the pythonmac.org wiki about Xcode + Python integration ( http://pythonmac.org/wiki/XcodeIntegration ). There's hardly anything there yet, right now just a replacement for the example StartupScript, but I plan on tinkering with Xcode this weekend and will be adding user scripts and/or plugins for stuff like pydoc integration. -bob From gus at mu.org Fri Oct 24 23:50:47 2003 From: gus at mu.org (Gus Mueller) Date: Fri Oct 24 23:50:51 2003 Subject: [Pythonmac-SIG] CoreGraphics and Python and Panther Message-ID: <20031025035047.GA22853@elvis.mu.org> I just wanted to say that wow, the CoreGraphics module in 10.3's python is awesome. Very neat, and I'm sure we're going to see some really cool stuff come out of it. Making pdf's has never been so easy. #!/usr/bin/python import os from CoreGraphics import * from urllib2 import * html = urlopen("http://www.python.org/").read() pageRect = CGRectMake(0, 0, 612, 792) ctx = CGPDFContextCreateWithFilename("python.pdf", pageRect) ctx.beginPage(pageRect) ctx.drawHTMLTextInRect(CGDataProviderCreateWithString(html), pageRect) ctx.endPage() ctx.finish() os.popen("/usr/bin/open -a Preview python.pdf") If whomever is responsible for this at Apple is listening- thanks! -gus -- August Mueller http://flyingmeat.com/ VoodooPad - 1st Place U.S., O'Reilly Mac OS X Innovators Contest round 2 "Christmas means carnage!" -- Ferdinand, the duck From drewmccormack at mac.com Sat Oct 25 01:46:57 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Sat Oct 25 01:47:04 2003 Subject: [Pythonmac-SIG] iChat channel In-Reply-To: References: Message-ID: Before iChat, I found the open-source 'Fire' to be the best. It is still a nice program, and can handle a number of IM protocols, including IRC. www.epicware.com/fire.html Drew On Saturday, October 25, 2003, at 3:36 AM, Israel C. Evans wrote: > I use x-chat ( http://www.xchat.org/about/ ) and Colloquy ( > http://www.jump-ing.de/proj/colloquy.html ) for Mac os X. Both work > fairly well. > > > > On Friday, October 24, 2003, at 12:41 PM, Sarwat Khan wrote: > >>> Or people could hang out on #macdev like I do... it's pretty >>> low-traffic as is, especially in comparison with #python. >> >> I'd tip my hat to an iChat channel for MacPython though, given that >> it's much easier to access than an IRC channel (and the only free Mac >> IRC client I know of is ChatZilla, other than cli clients). >> >> {sarwat khan : http://sarwat.net} >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG@python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > > > > ~Israel~ > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Sat Oct 25 21:19:17 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 25 21:19:54 2003 Subject: [Pythonmac-SIG] Hey, who put that Python in my Xcode? Message-ID: <6B39112D-0752-11D8-8E5A-000A95686CD8@redivi.com> Ok.. that was easy. I wrote an Xcode plugin that EMBEDS A PYTHON INTERPRETER INSIDE XCODE! This is very interesting.. I'm going to play with this more and clean it up, but this would make it really easy to hack around Xcode internals (god bless Objective C) and add Python specific features, or any feature for that matter. Our Next Generation MacPython IDE might actually *be* Xcode ;) I've put something quick up at http://pythonmac.org/wiki/XcodeIntegration -bob From artelse at mohr-i.nl Sun Oct 26 07:40:38 2003 From: artelse at mohr-i.nl (Arthur Elsenaar) Date: Sun Oct 26 07:40:40 2003 Subject: [Pythonmac-SIG] wxPython on 10.3 Message-ID: <9A388A0C-07B1-11D8-B182-000393825740@mohr-i.nl> Hi, was trying to compile wxPython on 10.3, so far the compiling went fine, but doing a python setup.py install resulted in a number of errors. The first one sh: line 1: wx-config: command not found The last one error: command 'gcc' failed with exit status 1 Anyone know how to proceed? Thanks, Arthur. From kevino at tulane.edu Sun Oct 26 12:45:27 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Sun Oct 26 12:50:10 2003 Subject: [Pythonmac-SIG] wxPython on 10.3 In-Reply-To: <9A388A0C-07B1-11D8-B182-000393825740@mohr-i.nl> References: <9A388A0C-07B1-11D8-B182-000393825740@mohr-i.nl> Message-ID: <2F92F54F-07DC-11D8-8AAD-000393CB1C86@tulane.edu> Hi Arthur, On Oct 26, 2003, at 4:40 AM, Arthur Elsenaar wrote: > Hi, > > was trying to compile wxPython on 10.3, so far the compiling went > fine, but doing a > python setup.py install resulted in a number of errors. > The first one > sh: line 1: wx-config: command not found There are two possible problems here: 1. Have you compiled wxWindows according to the build instructions in Build.OSX.txt before running setup.py? 2. You may need to add /usr/local/bin to your PATH. Just type the following into the terminal before building: setenv PATH /usr/local/bin:$PATH This command assumes you're using tcsh as your terminal shell. As a side note, I've heard rumors that Panther uses Bash as the default shell now, but I just upgraded Friday and mine is still using tcsh. Has anyone does a clean install, and if so, has your shell changed to bash? You can find the default shell with 'echo $SHELL'. HTH, Kevin From pijus at virketis.com Sun Oct 26 12:56:42 2003 From: pijus at virketis.com (Pijus Virketis) Date: Sun Oct 26 12:56:46 2003 Subject: [Pythonmac-SIG] turtle module Message-ID: Dear all, I am having trouble with the turtle module on my machine, and wanted to see if this is specific to my configuration (most likely), or a problem experienced by others as well. The basic issue is this: soon after given a drawing assignment, the turtle either becomes unresponsive, or fails altogether and brings Python down with it. By "drawing assignment" I mean something as simple as its own turtle.demo() function: after completing the first square, Python shuts down! While initialisation with turtle.reset() does not cause a crash, the turtle window cannot be closed and is unresponsive. I am running MacPython 2.3 with AquaTk/Tcl 8.4.4 on Mac OS X 10.2.8. Thank you! Pijus From artelse at mohr-i.nl Sun Oct 26 19:16:17 2003 From: artelse at mohr-i.nl (Arthur Elsenaar) Date: Sun Oct 26 19:16:30 2003 Subject: [Pythonmac-SIG] wxPython on 10.3 In-Reply-To: <2F92F54F-07DC-11D8-8AAD-000393CB1C86@tulane.edu> References: <9A388A0C-07B1-11D8-B182-000393825740@mohr-i.nl> <2F92F54F-07DC-11D8-8AAD-000393CB1C86@tulane.edu> Message-ID: Hi Kevin, > There are two possible problems here: > > 1. Have you compiled wxWindows according to the build instructions in > Build.OSX.txt before running setup.py? I did with the latest snapshot and configure, make and make install went error free. > 2. You may need to add /usr/local/bin to your PATH. Just type the > following into the terminal before building: > > setenv PATH /usr/local/bin:$PATH right, thanks, that cured some errors, but now I get a host of OpenGL errors.. it can't find a contrib/ogl directory that should have been there.. maybe I try compiling first plain vanilla and add other stuff later? > This command assumes you're using tcsh as your terminal shell. As a > side note, I've heard rumors that Panther uses Bash as the default > shell now, but I just upgraded Friday and mine is still using tcsh. > Has anyone does a clean install, and if so, has your shell changed to > bash? You can find the default shell with 'echo $SHELL'. 10.3 indeed has Bash as default shell, one needs to use export instead of setenv; export PATH=/usr/local/bin:$PATH Thanks again. Arthur From eric.wichterich at gmx.de Mon Oct 27 09:44:10 2003 From: eric.wichterich at gmx.de (Eric Wichterich) Date: Mon Oct 27 09:44:16 2003 Subject: [Pythonmac-SIG] How to import libraries on Mac OS X? In-Reply-To: <7212A6BD-064B-11D8-93C9-000A95841920@mac.com> Message-ID: <0664EEA4-088C-11D8-97EC-00039315E356@gmx.de> Hello Brian, thank you for your hint. Printing sys.path gives: ['/Users/username/Sites/projectname/cgi-bin', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python23.zip', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat- darwin', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat- mac', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat- mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- tk', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- dynload', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages'] Eric Am Freitag, 24.10.03 um 19:56 Uhr schrieb Brian Lenihan: > > On Oct 24, 2003, at 8:34 AM, Eric Wichterich wrote: > >> Thank you Ronald, >> >> I figured out that there is a problem with Apache and CGI, not with >> importing the library anymore. There is something Apache doesn't >> like. I only get the two different errors: Malformed header - or - >> premature end of file. These scripts work fine on a linux server with >> Apache... > > You may be running into a situation which causes the wrong python libs > to get loaded. You can test this by writing a simple cgi that imports > sys and prints sys.path. On OS X, the full path to the executable in > #! is not available to sys.argv which causes a lot of grief when > python loads whatever if finds first in your PATH like /usr/bin > instead of /usr/local/bin. > > The solution is to add a SetEnv directive for PYTHONPATH with the > correct paths. > From skip at pobox.com Mon Oct 27 12:44:21 2003 From: skip at pobox.com (Skip Montanaro) Date: Mon Oct 27 12:44:31 2003 Subject: [Pythonmac-SIG] What's MacPython missing? Message-ID: <16285.22901.32624.398544@montanaro.dyndns.org> Bob> Your best bet for automating iTunes is to use aeve: Bob> http://undefined.org/python/#aeve Bob> I'm not sure if iPhoto is scriptable or not, but if it is then aeve Bob> would also be what you'd want to use. Is there a list of scriptable Mac applications? I'd be interested in scripting TextEdit as a way of either viewing or converting rtf files dumped by MS Word. Skip From bob at redivi.com Mon Oct 27 12:49:31 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 27 12:50:05 2003 Subject: [Pythonmac-SIG] What's MacPython missing? In-Reply-To: <16285.22901.32624.398544@montanaro.dyndns.org> References: <16285.22901.32624.398544@montanaro.dyndns.org> Message-ID: On Oct 27, 2003, at 12:44 PM, Skip Montanaro wrote: > > Bob> Your best bet for automating iTunes is to use aeve: > Bob> http://undefined.org/python/#aeve > > Bob> I'm not sure if iPhoto is scriptable or not, but if it is > then aeve > Bob> would also be what you'd want to use. > > Is there a list of scriptable Mac applications? I'd be interested in > scripting TextEdit as a way of either viewing or converting rtf files > dumped > by MS Word. open "/Applications/AppleScript/Script Editor.app" File :: Open Dictionary This list should be pretty definitive.. choose an app and click "open" to see how to talk to it. -bob From kevino at tulane.edu Mon Oct 27 13:21:06 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Mon Oct 27 14:40:44 2003 Subject: [Pythonmac-SIG] wxPython on 10.3 In-Reply-To: References: <9A388A0C-07B1-11D8-B182-000393825740@mohr-i.nl> <2F92F54F-07DC-11D8-8AAD-000393CB1C86@tulane.edu> Message-ID: <54883986-08AA-11D8-8AAD-000393CB1C86@tulane.edu> Hi Arthur, On Oct 26, 2003, at 4:16 PM, Arthur Elsenaar wrote: > > Hi Kevin, > >> There are two possible problems here: >> >> 1. Have you compiled wxWindows according to the build instructions in >> Build.OSX.txt before running setup.py? > > I did with the latest snapshot and configure, make and make install > went error free. > >> 2. You may need to add /usr/local/bin to your PATH. Just type the >> following into the terminal before building: >> >> setenv PATH /usr/local/bin:$PATH > > right, thanks, that cured some errors, but now I get a host of OpenGL > errors.. it can't find a contrib/ogl directory that should have been > there.. maybe I try compiling first plain vanilla and add other stuff > later? What I did when I started building wxPython from source was turn off all the extensions by setting their BUILD_XXX value to 0 in setup.py (except for STC, which is needed for demo.py now) and then once that was building OK I went back and added the contribs back in by setting them to 1. Also, did you run a plain vanilla build of wxWindows? That is, did you simply call ./configure with no arguments? Adding --with-opengl will tell wxWindows to build the OpenGL library, which it doesn't do by default. >> This command assumes you're using tcsh as your terminal shell. As a >> side note, I've heard rumors that Panther uses Bash as the default >> shell now, but I just upgraded Friday and mine is still using tcsh. >> Has anyone does a clean install, and if so, has your shell changed to >> bash? You can find the default shell with 'echo $SHELL'. > > 10.3 indeed has Bash as default shell, one needs to use export instead > of setenv; > > export PATH=/usr/local/bin:$PATH Thanks! HTH, Kevin From ben at mitchellfamily.com Tue Oct 28 00:57:31 2003 From: ben at mitchellfamily.com (Ben Mitchell) Date: Tue Oct 28 00:57:55 2003 Subject: [Pythonmac-SIG] Traceback bug? In-Reply-To: <0DCEF1C0-065A-11D8-ACCD-003065C9DF8C@sarwat.net> Message-ID: <9E5BAD2A-090B-11D8-AED1-000A95A59C44@mitchellfamily.com> I'm noticing an odd behavior, and I'm wondering if it's a bug and if so if it's known. First off, I found this while unsuccessfully attempting to get eric3 to run on OSX. If you've been able to get this to run, I'd love to hear from you off list... That said, eric3 creates a package: /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/eric3 Under this directory are sub-packages such as: /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/eric3/UI /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/eric3/Project When I try to run it (and it crashes), I get the traceback stack: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/eric3/eric3.py", line 130, in ? mw = UserInterface(loc, args) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/UI/UserInterface.py", line 267, in __init__ File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/Project/ProjectBrowser.py", line 181, in __init__ File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/Project/ProjectBrowser.py", line 991, in __init__ File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/Project/ProjectBrowser.py", line 278, in __init__ File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/Project/ProjectBrowser.py", line 1027, in createPopupMenus AttributeError: qtdir BUT!!!!: The eric3 package directory is omitted from the path listings for files in the UI and Project sub-packages. The paths listed in the traceback DO NOT EXIST. The paths *should* be: /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/<<>>/UI/UserInterface.py /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages/<<>>/Project/ProjectBrowser.py <<<>>> added for emphasis I can't find any documentation indicating that the behavior I'm seeing here is the expected behavior??? Thanks, -Ben From bob at redivi.com Tue Oct 28 02:12:42 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 28 02:12:49 2003 Subject: [Pythonmac-SIG] ANN: PyInterpreter 0.2 Message-ID: <1F5B8F94-0916-11D8-8B4B-000A95686CD8@redivi.com> PyInterpreter is a set of PyObjC classes (and a nib) that makes it easy to put an interactive Python interpreter into just about any PyObjC application. It supports the following features: Colored stdout / stderr raw_input() / stdin.readline() support via modal dialog (a la PythonIDE) command history completion (OS X 10.3 and later only) Feel free to use this in your own projects, I'm hoping to get this into the PyObjC Examples tree sometime in the near future. See http://pythonmac.org/wiki/PyInterpreter for a screen shot, download, and more information. -bob From gherman at darwin.in-berlin.de Tue Oct 28 06:04:06 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Tue Oct 28 06:03:44 2003 Subject: [Pythonmac-SIG] ANN: ReSTedit 0.3 - a ReStructuredText editor/explorer Message-ID: <72DF05DC-0936-11D8-8827-00039345C610@darwin.in-berlin.de> ReSTedit 0.3 has been released and is available from: http://python.net/~gherman/ReSTedit.html The latest changes from 0.2 include: - proper file opening/saving capabilities (.txt) added - HTML and PDF export added (PDF needs LaTeX) Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The best way to predict the future is to invent it." (Alan Kay) From gherman at darwin.in-berlin.de Tue Oct 28 07:04:48 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Tue Oct 28 07:04:24 2003 Subject: [Pythonmac-SIG] "Fix and continue" Python code? Message-ID: Hi, does anyone know if Xcode supports the "Fix and continue" feature with Python code, too? Panther is still crawling into my home... Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The first principle is that you must not fool yourself - and you are the easiest person to fool." (Richard Feynman) From yserrano at cdr.ethz.ch Tue Oct 28 08:36:53 2003 From: yserrano at cdr.ethz.ch (Yves Serrano) Date: Tue Oct 28 08:40:02 2003 Subject: [Pythonmac-SIG] python 2.0 Message-ID: Hi I'm new on this mailing list :-) I work with python on mac os x. For blender 2.25 (3D program, http://www.blender.org) I need python 2.0 support on os x. Does anybody of you have a bin python 2.0 os x package? All I found is python21. The GameEngine in Blender 2.25 only works with python2.0. The compilation from source failed: libtool -o libpython2.0.dylib -dynamic libpython2.0.a -framework System -lcc_dynamic -arch_only ppc -U _environ ld: can't use -U flags when -twolevel_namespace is in effect libtool: internal link edit command failed make[1]: *** [libpython2.0.dylib] Error 1 make: *** [python] Error 2 Unitl now I don't have found a work version of python 2.0 for os x.... thanks yves From Jack.Jansen at cwi.nl Tue Oct 28 10:36:43 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Tue Oct 28 10:36:52 2003 Subject: [Pythonmac-SIG] python 2.0 In-Reply-To: Message-ID: <8817D9BB-095C-11D8-A7B6-0030655234CE@cwi.nl> On Tuesday, October 28, 2003, at 02:36 PM, Yves Serrano wrote: > Hi > > I'm new on this mailing list :-) > > I work with python on mac os x. > For blender 2.25 (3D program, http://www.blender.org) I need python > 2.0 support on os x. > Does anybody of you have a bin python 2.0 os x package? All I found is > python21. The GameEngine in Blender 2.25 only works with python2.0. > > The compilation from source failed: > libtool -o libpython2.0.dylib -dynamic libpython2.0.a -framework > System -lcc_dynamic -arch_only ppc -U _environ > ld: can't use -U flags when -twolevel_namespace is in effect > libtool: internal link edit command failed > make[1]: *** [libpython2.0.dylib] Error 1 > make: *** [python] Error 2 Phew, 2.0 is really old, the last time that code was compiled was probably under OSX 10.0, maybe even Public Beta... What you could try is add -flat_namespace to the linker flags. I don't remember exactly where to set it for 2.0, but if you find the spot where the "-U _environ" is set that would be a good place to try it. Hmm, but I'm not sure whether that is enough, I seem to remember there was magic for linking the main application too. A wholly different idea: could you install MacOSX 10.1 plus the accompanying developer tools on a spare partition? I think there's a reasonable chance that 10.1 will be able to build Python 2.0 out of the box. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From bob at redivi.com Tue Oct 28 10:45:48 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 28 10:46:50 2003 Subject: [Pythonmac-SIG] python 2.0 In-Reply-To: <8817D9BB-095C-11D8-A7B6-0030655234CE@cwi.nl> References: <8817D9BB-095C-11D8-A7B6-0030655234CE@cwi.nl> Message-ID: On Oct 28, 2003, at 10:36 AM, Jack Jansen wrote: > > On Tuesday, October 28, 2003, at 02:36 PM, Yves Serrano wrote: > >> Hi >> >> I'm new on this mailing list :-) >> >> I work with python on mac os x. >> For blender 2.25 (3D program, http://www.blender.org) I need python >> 2.0 support on os x. >> Does anybody of you have a bin python 2.0 os x package? All I found >> is python21. The GameEngine in Blender 2.25 only works with >> python2.0. >> >> The compilation from source failed: >> libtool -o libpython2.0.dylib -dynamic libpython2.0.a -framework >> System -lcc_dynamic -arch_only ppc -U _environ >> ld: can't use -U flags when -twolevel_namespace is in effect >> libtool: internal link edit command failed >> make[1]: *** [libpython2.0.dylib] Error 1 >> make: *** [python] Error 2 > > Phew, 2.0 is really old, the last time that code was compiled was > probably under OSX 10.0, > maybe even Public Beta... > > What you could try is add -flat_namespace to the linker flags. I don't > remember > exactly where to set it for 2.0, but if you find the spot where the > "-U _environ" is set that would be a good place to try it. > > Hmm, but I'm not sure whether that is enough, I seem to remember there > was magic for linking the main application too. > > A wholly different idea: could you install MacOSX 10.1 plus the > accompanying developer tools on a spare partition? I think there's a > reasonable chance that 10.1 will be able to build Python 2.0 out of the > box. The right solution, of course, is to just fix blender. Is that part of blender open source yet? I can't imagine that too much of it could depend on that particular version of Python. -bob From yserrano at cdr.ethz.ch Tue Oct 28 11:03:11 2003 From: yserrano at cdr.ethz.ch (Yves Serrano) Date: Tue Oct 28 11:06:32 2003 Subject: [Pythonmac-SIG] python 2.0 In-Reply-To: References: <8817D9BB-095C-11D8-A7B6-0030655234CE@cwi.nl> Message-ID: <3B0DFAD1-0960-11D8-8F34-000A95DA3F3A@cdr.ethz.ch> hi I know that python 2.0 is very old.... Blender is open source and they are working on a new gameEngine. The new Blender 2..28 has a more recent python version. But for now you must use blender 2.25 and python 2.0 if you want to use the gameEngine. I need it now.... I'm working with blender on linux, where it wasn't a problem to compile python 2.0 on a recent gentoo linux version. For a demonstration I want to present it on my powerbook. I will try the patch from the bsd port collection and your tips. http://www.freebsd.org/ports/python.html look for python-2.0.1_2 thanks for your help.... yves >>> Hi >>> >>> I'm new on this mailing list :-) >>> >>> I work with python on mac os x. >>> For blender 2.25 (3D program, http://www.blender.org) I need python >>> 2.0 support on os x. >>> Does anybody of you have a bin python 2.0 os x package? All I found >>> is python21. The GameEngine in Blender 2.25 only works with >>> python2.0. >>> >>> The compilation from source failed: >>> libtool -o libpython2.0.dylib -dynamic libpython2.0.a -framework >>> System -lcc_dynamic -arch_only ppc -U _environ >>> ld: can't use -U flags when -twolevel_namespace is in effect >>> libtool: internal link edit command failed >>> make[1]: *** [libpython2.0.dylib] Error 1 >>> make: *** [python] Error 2 >> >> Phew, 2.0 is really old, the last time that code was compiled was >> probably under OSX 10.0, >> maybe even Public Beta... >> >> What you could try is add -flat_namespace to the linker flags. I >> don't remember >> exactly where to set it for 2.0, but if you find the spot where the >> "-U _environ" is set that would be a good place to try it. >> >> Hmm, but I'm not sure whether that is enough, I seem to remember there >> was magic for linking the main application too. >> >> A wholly different idea: could you install MacOSX 10.1 plus the >> accompanying developer tools on a spare partition? I think there's a >> reasonable chance that 10.1 will be able to build Python 2.0 out of >> the >> box. > > The right solution, of course, is to just fix blender. Is that part > of blender open source yet? I can't imagine that too much of it could > depend on that particular version of Python. > > -bob From pecora at anvil.nrl.navy.mil Tue Oct 28 11:07:47 2003 From: pecora at anvil.nrl.navy.mil (Louis M. Pecora) Date: Tue Oct 28 11:07:44 2003 Subject: [Pythonmac-SIG] Plotting and Piddle - nice, simple plotting for Python 2.3 Message-ID: FYI: I've just installed and tested Piddle (http://piddle.sourceforge.net/) from Bob Ippolito's site (http://undefined.org/python/pimp/ ). It's a neat little plotting/drawing library that I used in Python 2.2 on system 9. Now it works on OS X with Bob's fine tuning. Easy to install. Thanks, Bob, for providing this useful package and bringing my plotting back on OS X. -- Lou Pecora email: Louis.M.Pecora@nrl.navy.mil Code 6340, Naval Research Laboratory, Washington, D.C. 20375, U.S.A. Voice (Me): 202-767-6002 FAX: 202-767-1697 == My comments are my own and do not reflect the views of the U.S. Navy. == == No Spamming or solicitations -- both are illegal at this site == Check out our Nonlinear Dynamics Web site: http://chaos-mac.nrl.navy.mil/ ---- Conferences ---------------------------------------------------------- * The Gordon Research Conference on Nonlinear Science 3-8 August 2003. See http://www.grc.uri.edu * The 8th Experimental Chaos Conference 2004, June 2004, Florence, Italy See http://experimentalchaosconference.org From just at letterror.com Tue Oct 28 16:18:03 2003 From: just at letterror.com (Just van Rossum) Date: Tue Oct 28 16:18:17 2003 Subject: [Pythonmac-SIG] ANN: iChat channel for MacPython and PyObjC Message-ID: There's a iChat channel called "MacPython" now. Hit cmd-G in iChat and type the channel name. See you there! Just From brownr at enel.ucalgary.ca Tue Oct 28 17:55:21 2003 From: brownr at enel.ucalgary.ca (Robb Brown) Date: Tue Oct 28 17:55:24 2003 Subject: [Pythonmac-SIG] Problems wrapping Message-ID: Thanks for the help some of you gave a month or so ago with my project to wrap dcmtk (a DICOM medical image transmission toolkit). I've figured out how to compile it as dynamic libraries on OS X. Python wrappers work better now. Unfortunately, there's still a problem. When certain functions are present, importing the module will hang Python. Commenting out these functions lets the module import and you can use what's left. How come this code hangs Python right when importing? Thanks, Robb _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From bob at redivi.com Tue Oct 28 18:16:13 2003 From: bob at redivi.com (Bob Ippolito) Date: Tue Oct 28 18:16:45 2003 Subject: [Pythonmac-SIG] ANN: PyInterpreter 0.3 In-Reply-To: <1F5B8F94-0916-11D8-8B4B-000A95686CD8@redivi.com> References: <1F5B8F94-0916-11D8-8B4B-000A95686CD8@redivi.com> Message-ID: I've just updated PyInterpreter to 0.3 On Oct 28, 2003, at 2:12 AM, Bob Ippolito wrote: > PyInterpreter is a set of PyObjC classes (and a nib) that makes it > easy to put an interactive Python interpreter into just about any > PyObjC application. It supports the following features: > Colored stdout / stderr > raw_input() / stdin.readline() support via modal dialog (a la > PythonIDE) Now it acts more like a real terminal and lets you type inline, no more modal dialog. It's scary, but it works! Note: don't ever try and have more than two PyInterpreter windows in the same application (that have stdin enabled).. You're asking for trouble :) Note: don't push the up/down arrows because they'll probably trigger history, you probably don't want this when typing.. I'll probably fix this somehow. > command history > completion (OS X 10.3 and later only) > > Feel free to use this in your own projects, I'm hoping to get this > into the PyObjC Examples tree sometime in the near future. > > See http://pythonmac.org/wiki/PyInterpreter for a screen shot, > download, and more information. From krjackson at lbl.gov Tue Oct 28 18:35:13 2003 From: krjackson at lbl.gov (Keith Jackson) Date: Tue Oct 28 18:35:41 2003 Subject: [Pythonmac-SIG] ext build problem Message-ID: <608FF4EE-099F-11D8-A96E-000A9577489A@lbl.gov> All, Once again I've run into the "_environ" problem while trying to build 4Suite. I'm using python2.3.2 built as a framework build. As part of trying to debug this, I've written a very simple test that shows the same behavior for me. I'd appreciate it if someone else could try this and see if they see the same behavior. Also, if I'm doing something dumb please let me know. ;) I will attach the setup.py file and the other files necessary to try this test. I sure would appreciate any help with this. I've been banging my head against this for a while and getting nowhere. thx, ---keith -------------- next part -------------- /* ---------------------------------------------------------------------------- * This file was automatically generated by SWIG (http://www.swig.org). * Version 1.3.19 * * This file is not intended to be easily readable and contains a number of * coding conventions designed to improve portability and efficiency. Do not make * changes to this file unless you know what you are doing--modify the SWIG * interface file instead. * ----------------------------------------------------------------------------- */ #define SWIGPYTHON #include "Python.h" /*********************************************************************** * common.swg * * This file contains generic SWIG runtime support for pointer * type checking as well as a few commonly used macros to control * external linkage. * * Author : David Beazley (beazley@cs.uchicago.edu) * * Copyright (c) 1999-2000, The University of Chicago * * This file may be freely redistributed without license or fee provided * this copyright message remains intact. ************************************************************************/ #include #if defined(_WIN32) || defined(__WIN32__) # if defined(_MSC_VER) # if defined(STATIC_LINKED) # define SWIGEXPORT(a) a # define SWIGIMPORT(a) extern a # else # define SWIGEXPORT(a) __declspec(dllexport) a # define SWIGIMPORT(a) extern a # endif # else # if defined(__BORLANDC__) # define SWIGEXPORT(a) a _export # define SWIGIMPORT(a) a _export # else # define SWIGEXPORT(a) a # define SWIGIMPORT(a) a # endif # endif #else # define SWIGEXPORT(a) a # define SWIGIMPORT(a) a #endif #ifdef SWIG_GLOBAL #define SWIGRUNTIME(a) SWIGEXPORT(a) #else #define SWIGRUNTIME(a) static a #endif #ifdef __cplusplus extern "C" { #endif typedef void *(*swig_converter_func)(void *); typedef struct swig_type_info *(*swig_dycast_func)(void **); typedef struct swig_type_info { const char *name; swig_converter_func converter; const char *str; void *clientdata; swig_dycast_func dcast; struct swig_type_info *next; struct swig_type_info *prev; } swig_type_info; #ifdef SWIG_NOINCLUDE SWIGIMPORT(swig_type_info *) SWIG_TypeRegister(swig_type_info *); SWIGIMPORT(swig_type_info *) SWIG_TypeCheck(char *c, swig_type_info *); SWIGIMPORT(void *) SWIG_TypeCast(swig_type_info *, void *); SWIGIMPORT(swig_type_info *) SWIG_TypeDynamicCast(swig_type_info *, void **); SWIGIMPORT(const char *) SWIG_TypeName(const swig_type_info *); SWIGIMPORT(swig_type_info *) SWIG_TypeQuery(const char *); SWIGIMPORT(void) SWIG_TypeClientData(swig_type_info *, void *); #else static swig_type_info *swig_type_list = 0; /* Register a type mapping with the type-checking */ SWIGRUNTIME(swig_type_info *) SWIG_TypeRegister(swig_type_info *ti) { swig_type_info *tc, *head, *ret, *next; /* Check to see if this type has already been registered */ tc = swig_type_list; while (tc) { if (strcmp(tc->name, ti->name) == 0) { /* Already exists in the table. Just add additional types to the list */ if (tc->clientdata) ti->clientdata = tc->clientdata; head = tc; next = tc->next; goto l1; } tc = tc->prev; } head = ti; next = 0; /* Place in list */ ti->prev = swig_type_list; swig_type_list = ti; /* Build linked lists */ l1: ret = head; tc = ti + 1; /* Patch up the rest of the links */ while (tc->name) { head->next = tc; tc->prev = head; head = tc; tc++; } if (next) next->prev = head; /**/ head->next = next; return ret; } /* Check the typename */ SWIGRUNTIME(swig_type_info *) SWIG_TypeCheck(char *c, swig_type_info *ty) { swig_type_info *s; if (!ty) return 0; /* Void pointer */ s = ty->next; /* First element always just a name */ do { if (strcmp(s->name,c) == 0) { if (s == ty->next) return s; /* Move s to the top of the linked list */ s->prev->next = s->next; if (s->next) { s->next->prev = s->prev; } /* Insert s as second element in the list */ s->next = ty->next; if (ty->next) ty->next->prev = s; ty->next = s; s->prev = ty; /**/ return s; } s = s->next; } while (s && (s != ty->next)); return 0; } /* Cast a pointer up an inheritance hierarchy */ SWIGRUNTIME(void *) SWIG_TypeCast(swig_type_info *ty, void *ptr) { if ((!ty) || (!ty->converter)) return ptr; return (*ty->converter)(ptr); } /* Dynamic pointer casting. Down an inheritance hierarchy */ SWIGRUNTIME(swig_type_info *) SWIG_TypeDynamicCast(swig_type_info *ty, void **ptr) { swig_type_info *lastty = ty; if (!ty || !ty->dcast) return ty; while (ty && (ty->dcast)) { ty = (*ty->dcast)(ptr); if (ty) lastty = ty; } return lastty; } /* Return the name associated with this type */ SWIGRUNTIME(const char *) SWIG_TypeName(const swig_type_info *ty) { return ty->name; } /* Search for a swig_type_info structure */ SWIGRUNTIME(swig_type_info *) SWIG_TypeQuery(const char *name) { swig_type_info *ty = swig_type_list; while (ty) { if (ty->str && (strcmp(name,ty->str) == 0)) return ty; if (ty->name && (strcmp(name,ty->name) == 0)) return ty; ty = ty->prev; } return 0; } /* Set the clientdata field for a type */ SWIGRUNTIME(void) SWIG_TypeClientData(swig_type_info *ti, void *clientdata) { swig_type_info *tc, *equiv; if (ti->clientdata == clientdata) return; ti->clientdata = clientdata; equiv = ti->next; while (equiv) { if (!equiv->converter) { tc = swig_type_list; while (tc) { if ((strcmp(tc->name, equiv->name) == 0)) SWIG_TypeClientData(tc,clientdata); tc = tc->prev; } } equiv = equiv->next; } } #endif #ifdef __cplusplus } #endif /*********************************************************************** * python.swg * * This file contains the runtime support for Python modules * and includes code for managing global variables and pointer * type checking. * * Author : David Beazley (beazley@cs.uchicago.edu) ************************************************************************/ #include "Python.h" #ifdef __cplusplus extern "C" { #endif #define SWIG_PY_INT 1 #define SWIG_PY_FLOAT 2 #define SWIG_PY_STRING 3 #define SWIG_PY_POINTER 4 #define SWIG_PY_BINARY 5 /* Flags for pointer conversion */ #define SWIG_POINTER_EXCEPTION 0x1 #define SWIG_POINTER_DISOWN 0x2 /* Exception handling in wrappers */ #define SWIG_fail goto fail /* Constant information structure */ typedef struct swig_const_info { int type; char *name; long lvalue; double dvalue; void *pvalue; swig_type_info **ptype; } swig_const_info; #ifdef SWIG_NOINCLUDE SWIGEXPORT(PyObject *) SWIG_newvarlink(void); SWIGEXPORT(void) SWIG_addvarlink(PyObject *, char *, PyObject *(*)(void), int (*)(PyObject *)); SWIGEXPORT(int) SWIG_ConvertPtr(PyObject *, void **, swig_type_info *, int); SWIGEXPORT(int) SWIG_ConvertPacked(PyObject *, void *, int sz, swig_type_info *, int); SWIGEXPORT(char *) SWIG_PackData(char *c, void *, int); SWIGEXPORT(char *) SWIG_UnpackData(char *c, void *, int); SWIGEXPORT(PyObject *) SWIG_NewPointerObj(void *, swig_type_info *,int own); SWIGEXPORT(PyObject *) SWIG_NewPackedObj(void *, int sz, swig_type_info *); SWIGEXPORT(void) SWIG_InstallConstants(PyObject *d, swig_const_info constants[]); #else /* ----------------------------------------------------------------------------- * global variable support code. * ----------------------------------------------------------------------------- */ typedef struct swig_globalvar { char *name; /* Name of global variable */ PyObject *(*get_attr)(void); /* Return the current value */ int (*set_attr)(PyObject *); /* Set the value */ struct swig_globalvar *next; } swig_globalvar; typedef struct swig_varlinkobject { PyObject_HEAD swig_globalvar *vars; } swig_varlinkobject; static PyObject * swig_varlink_repr(swig_varlinkobject *v) { v = v; return PyString_FromString(""); } static int swig_varlink_print(swig_varlinkobject *v, FILE *fp, int flags) { swig_globalvar *var; flags = flags; fprintf(fp,"Global variables { "); for (var = v->vars; var; var=var->next) { fprintf(fp,"%s", var->name); if (var->next) fprintf(fp,", "); } fprintf(fp," }\n"); return 0; } static PyObject * swig_varlink_getattr(swig_varlinkobject *v, char *n) { swig_globalvar *var = v->vars; while (var) { if (strcmp(var->name,n) == 0) { return (*var->get_attr)(); } var = var->next; } PyErr_SetString(PyExc_NameError,"Unknown C global variable"); return NULL; } static int swig_varlink_setattr(swig_varlinkobject *v, char *n, PyObject *p) { swig_globalvar *var = v->vars; while (var) { if (strcmp(var->name,n) == 0) { return (*var->set_attr)(p); } var = var->next; } PyErr_SetString(PyExc_NameError,"Unknown C global variable"); return 1; } statichere PyTypeObject varlinktype = { PyObject_HEAD_INIT(0) 0, (char *)"swigvarlink", /* Type name */ sizeof(swig_varlinkobject), /* Basic size */ 0, /* Itemsize */ 0, /* Deallocator */ (printfunc) swig_varlink_print, /* Print */ (getattrfunc) swig_varlink_getattr, /* get attr */ (setattrfunc) swig_varlink_setattr, /* Set attr */ 0, /* tp_compare */ (reprfunc) swig_varlink_repr, /* tp_repr */ 0, /* tp_as_number */ 0, /* tp_as_mapping*/ 0, /* tp_hash */ }; /* Create a variable linking object for use later */ SWIGRUNTIME(PyObject *) SWIG_newvarlink(void) { swig_varlinkobject *result = 0; result = PyMem_NEW(swig_varlinkobject,1); varlinktype.ob_type = &PyType_Type; /* Patch varlinktype into a PyType */ result->ob_type = &varlinktype; result->vars = 0; result->ob_refcnt = 0; Py_XINCREF((PyObject *) result); return ((PyObject*) result); } SWIGRUNTIME(void) SWIG_addvarlink(PyObject *p, char *name, PyObject *(*get_attr)(void), int (*set_attr)(PyObject *p)) { swig_varlinkobject *v; swig_globalvar *gv; v= (swig_varlinkobject *) p; gv = (swig_globalvar *) malloc(sizeof(swig_globalvar)); gv->name = (char *) malloc(strlen(name)+1); strcpy(gv->name,name); gv->get_attr = get_attr; gv->set_attr = set_attr; gv->next = v->vars; v->vars = gv; } /* Pack binary data into a string */ SWIGRUNTIME(char *) SWIG_PackData(char *c, void *ptr, int sz) { static char hex[17] = "0123456789abcdef"; int i; unsigned char *u = (unsigned char *) ptr; register unsigned char uu; for (i = 0; i < sz; i++,u++) { uu = *u; *(c++) = hex[(uu & 0xf0) >> 4]; *(c++) = hex[uu & 0xf]; } return c; } /* Unpack binary data from a string */ SWIGRUNTIME(char *) SWIG_UnpackData(char *c, void *ptr, int sz) { register unsigned char uu = 0; register int d; unsigned char *u = (unsigned char *) ptr; int i; for (i = 0; i < sz; i++, u++) { d = *(c++); if ((d >= '0') && (d <= '9')) uu = ((d - '0') << 4); else if ((d >= 'a') && (d <= 'f')) uu = ((d - ('a'-10)) << 4); d = *(c++); if ((d >= '0') && (d <= '9')) uu |= (d - '0'); else if ((d >= 'a') && (d <= 'f')) uu |= (d - ('a'-10)); *u = uu; } return c; } /* Convert a pointer value */ SWIGRUNTIME(int) SWIG_ConvertPtr(PyObject *obj, void **ptr, swig_type_info *ty, int flags) { swig_type_info *tc; char *c; static PyObject *SWIG_this = 0; int newref = 0; PyObject *pyobj = 0; if (!obj) return 0; if (obj == Py_None) { *ptr = 0; return 0; } #ifdef SWIG_COBJECT_TYPES if (!(PyCObject_Check(obj))) { if (!SWIG_this) SWIG_this = PyString_FromString("this"); pyobj = obj; obj = PyObject_GetAttr(obj,SWIG_this); newref = 1; if (!obj) goto type_error; if (!PyCObject_Check(obj)) { Py_DECREF(obj); goto type_error; } } *ptr = PyCObject_AsVoidPtr(obj); c = (char *) PyCObject_GetDesc(obj); if (newref) Py_DECREF(obj); goto cobject; #else if (!(PyString_Check(obj))) { if (!SWIG_this) SWIG_this = PyString_FromString("this"); pyobj = obj; obj = PyObject_GetAttr(obj,SWIG_this); newref = 1; if (!obj) goto type_error; if (!PyString_Check(obj)) { Py_DECREF(obj); goto type_error; } } c = PyString_AsString(obj); /* Pointer values must start with leading underscore */ if (*c != '_') { *ptr = (void *) 0; if (strcmp(c,"NULL") == 0) { if (newref) { Py_DECREF(obj); } return 0; } else { if (newref) { Py_DECREF(obj); } goto type_error; } } c++; c = SWIG_UnpackData(c,ptr,sizeof(void *)); if (newref) { Py_DECREF(obj); } #endif #ifdef SWIG_COBJECT_TYPES cobject: #endif if (ty) { tc = SWIG_TypeCheck(c,ty); if (!tc) goto type_error; *ptr = SWIG_TypeCast(tc,(void*) *ptr); } if ((pyobj) && (flags & SWIG_POINTER_DISOWN)) { PyObject *zero = PyInt_FromLong(0); PyObject_SetAttrString(pyobj,(char*)"thisown",zero); Py_DECREF(zero); } return 0; type_error: if (flags & SWIG_POINTER_EXCEPTION) { if (ty) { char *temp = (char *) malloc(64+strlen(ty->name)); sprintf(temp,"Type error. Expected %s", ty->name); PyErr_SetString(PyExc_TypeError, temp); free((char *) temp); } else { PyErr_SetString(PyExc_TypeError,"Expected a pointer"); } } return -1; } /* Convert a packed value value */ SWIGRUNTIME(int) SWIG_ConvertPacked(PyObject *obj, void *ptr, int sz, swig_type_info *ty, int flags) { swig_type_info *tc; char *c; if ((!obj) || (!PyString_Check(obj))) goto type_error; c = PyString_AsString(obj); /* Pointer values must start with leading underscore */ if (*c != '_') goto type_error; c++; c = SWIG_UnpackData(c,ptr,sz); if (ty) { tc = SWIG_TypeCheck(c,ty); if (!tc) goto type_error; } return 0; type_error: if (flags) { if (ty) { char *temp = (char *) malloc(64+strlen(ty->name)); sprintf(temp,"Type error. Expected %s", ty->name); PyErr_SetString(PyExc_TypeError, temp); free((char *) temp); } else { PyErr_SetString(PyExc_TypeError,"Expected a pointer"); } } return -1; } /* Create a new pointer object */ SWIGRUNTIME(PyObject *) SWIG_NewPointerObj(void *ptr, swig_type_info *type, int own) { PyObject *robj; if (!ptr) { Py_INCREF(Py_None); return Py_None; } #ifdef SWIG_COBJECT_TYPES robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, (char *) type->name, NULL); #else { char result[1024]; char *r = result; *(r++) = '_'; r = SWIG_PackData(r,&ptr,sizeof(void *)); strcpy(r,type->name); robj = PyString_FromString(result); } #endif if (!robj || (robj == Py_None)) return robj; if (type->clientdata) { PyObject *inst; PyObject *args = Py_BuildValue((char*)"(O)", robj); Py_DECREF(robj); inst = PyObject_CallObject((PyObject *) type->clientdata, args); Py_DECREF(args); if (inst) { if (own) { PyObject *n = PyInt_FromLong(1); PyObject_SetAttrString(inst,(char*)"thisown",n); Py_DECREF(n); } robj = inst; } } return robj; } SWIGRUNTIME(PyObject *) SWIG_NewPackedObj(void *ptr, int sz, swig_type_info *type) { char result[1024]; char *r = result; if ((2*sz + 1 + strlen(type->name)) > 1000) return 0; *(r++) = '_'; r = SWIG_PackData(r,ptr,sz); strcpy(r,type->name); return PyString_FromString(result); } /* Install Constants */ SWIGRUNTIME(void) SWIG_InstallConstants(PyObject *d, swig_const_info constants[]) { int i; PyObject *obj; for (i = 0; constants[i].type; i++) { switch(constants[i].type) { case SWIG_PY_INT: obj = PyInt_FromLong(constants[i].lvalue); break; case SWIG_PY_FLOAT: obj = PyFloat_FromDouble(constants[i].dvalue); break; case SWIG_PY_STRING: obj = PyString_FromString((char *) constants[i].pvalue); break; case SWIG_PY_POINTER: obj = SWIG_NewPointerObj(constants[i].pvalue, *(constants[i]).ptype,0); break; case SWIG_PY_BINARY: obj = SWIG_NewPackedObj(constants[i].pvalue, constants[i].lvalue, *(constants[i].ptype)); break; default: obj = 0; break; } if (obj) { PyDict_SetItemString(d,constants[i].name,obj); Py_DECREF(obj); } } } #endif #ifdef __cplusplus } #endif /* -------- TYPES TABLE (BEGIN) -------- */ static swig_type_info *swig_types[1]; /* -------- TYPES TABLE (END) -------- */ /*----------------------------------------------- @(target):= _foo.so ------------------------------------------------*/ #define SWIG_init init_foo #define SWIG_name "_foo" #include "foo.h" #ifdef __cplusplus extern "C" { #endif static PyObject *_wrap_test(PyObject *self, PyObject *args) { PyObject *resultobj; if(!PyArg_ParseTuple(args,(char *)":test")) goto fail; test(); Py_INCREF(Py_None); resultobj = Py_None; return resultobj; fail: return NULL; } static PyMethodDef SwigMethods[] = { { (char *)"test", _wrap_test, METH_VARARGS }, { NULL, NULL } }; /* -------- TYPE CONVERSION AND EQUIVALENCE RULES (BEGIN) -------- */ static swig_type_info *swig_types_initial[] = { 0 }; /* -------- TYPE CONVERSION AND EQUIVALENCE RULES (END) -------- */ static swig_const_info swig_const_table[] = { {0}}; #ifdef __cplusplus } #endif #ifdef __cplusplus extern "C" #endif SWIGEXPORT(void) SWIG_init(void) { static PyObject *SWIG_globals = 0; static int typeinit = 0; PyObject *m, *d; int i; if (!SWIG_globals) SWIG_globals = SWIG_newvarlink(); m = Py_InitModule((char *) SWIG_name, SwigMethods); d = PyModule_GetDict(m); if (!typeinit) { for (i = 0; swig_types_initial[i]; i++) { swig_types[i] = SWIG_TypeRegister(swig_types_initial[i]); } typeinit = 1; } SWIG_InstallConstants(d,swig_const_table); } -------------- next part -------------- #include #include "foo.h" extern char **environ; void test() { char *env; env = environ[0]; printf("environ[0]: %s\n", env); } -------------- next part -------------- void test(void); -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.py Type: application/octet-stream Size: 166 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031028/82ccd09a/setup-0001.obj -------------- next part -------------- Here's the transcript of my attempt at build this test. kjackson@Keith-Jacksons-Computer.local.(72)>python setup.py build running build running build_ext building 'foo' extension creating build creating build/temp.darwin-6.8-Power_Macintosh-2.3 gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c foo_wrap.c -o build/temp.darwin-6.8-Power_Macintosh-2.3/foo_wrap.o foo_wrap.c:170: warning: `SWIG_TypeDynamicCast' defined but not used foo_wrap.c:182: warning: `SWIG_TypeName' defined but not used foo_wrap.c:188: warning: `SWIG_TypeQuery' defined but not used foo_wrap.c:370: warning: `SWIG_addvarlink' defined but not used foo_wrap.c:423: warning: `SWIG_ConvertPtr' defined but not used foo_wrap.c:515: warning: `SWIG_ConvertPacked' defined but not used gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c foo.c -o build/temp.darwin-6.8-Power_Macintosh-2.3/foo.o creating build/lib.darwin-6.8-Power_Macintosh-2.3 gcc -Wl,-F. -bundle -framework Python build/temp.darwin-6.8-Power_Macintosh-2.3/foo.o build/temp.darwin-6.8-Power_Macintosh-2.3/foo_wrap.o -o build/lib.darwin-6.8-Power_Macintosh-2.3/foo.so ld: warning -prebind has no effect with -bundle ld: Undefined symbols: _environ error: command 'gcc' failed with exit status 1 From Jack.Jansen at cwi.nl Wed Oct 29 07:17:51 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 29 07:18:04 2003 Subject: [Pythonmac-SIG] Problems wrapping In-Reply-To: References: Message-ID: On 28 Oct 2003, at 23:55, Robb Brown wrote: > Thanks for the help some of you gave a month or so ago with my project > to wrap dcmtk (a DICOM medical image transmission toolkit). I've > figured out how to compile it as dynamic libraries on OS X. Python > wrappers work better now. Unfortunately, there's still a problem. > > When certain functions are present, importing the module will hang > Python. Commenting out these functions lets the module import and you > can use what's left. How come this code hangs Python right when > importing? See if you can find out what it does when it hangs. The first step would be to use "python -vv", which will trace all imports (and all places it looked before importing). The next step is to set the dyld debug environment variables (see "man dyld"), which will trace the dynamic loading of code. Then you could try to do a system call trace (see "man ktrace") while importing. Finally you could try running python under gdb, hitting control-C when it hangs and see what it's doing. -- Jack Jansen http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Wed Oct 29 07:23:46 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 29 07:23:54 2003 Subject: [Pythonmac-SIG] ext build problem In-Reply-To: <608FF4EE-099F-11D8-A96E-000A9577489A@lbl.gov> References: <608FF4EE-099F-11D8-A96E-000A9577489A@lbl.gov> Message-ID: On 29 Oct 2003, at 0:35, Keith Jackson wrote: > All, > Once again I've run into the "_environ" problem while trying to build > 4Suite. I'm using python2.3.2 built as a framework build. As part of > trying to debug this, I've written a very simple test that shows the > same behavior for me. I'd appreciate it if someone else could try this > and see if they see the same behavior. Also, if I'm doing something > dumb please let me know. ;) It's not you who's doing something dumb, it's Apple:-) _environ is defined in crt0, which means you don't have access to it in shared libraries or bundles. The workaround is to call _NSGetEnviron() to get at the environment pointer, see Modules/posixmodule.c for a way to do this in one place in your code that will make _environ available to all the rest of your shared library (or bundle). -- 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 king at dircon.co.uk Wed Oct 29 09:09:19 2003 From: king at dircon.co.uk (Nigel King) Date: Wed Oct 29 09:07:58 2003 Subject: [Pythonmac-SIG] ANN: iChat channel for MacPython and PyObjC In-Reply-To: Message-ID: > There's a iChat channel called "MacPython" now. Hit cmd-G in iChat and > type the channel name. See you there! Presumably one needs an AIM account to be active to do this? TIA -- Nigel From bob at redivi.com Wed Oct 29 09:34:17 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 29 09:34:46 2003 Subject: [Pythonmac-SIG] ANN: iChat channel for MacPython and PyObjC In-Reply-To: References: Message-ID: On Oct 29, 2003, at 9:09 AM, Nigel King wrote: >> There's a iChat channel called "MacPython" now. Hit cmd-G in iChat and >> type the channel name. See you there! > Presumably one needs an AIM account to be active to do this? AIM or .mac, I believe. -bob From brownr at ucalgary.ca Wed Oct 29 12:03:55 2003 From: brownr at ucalgary.ca (Robb Brown) Date: Wed Oct 29 12:03:58 2003 Subject: [Pythonmac-SIG] Problems wrapping In-Reply-To: Message-ID: Okay, this is Python 2.3.2, OS X 10.2.8, GCC 3.3. python -vv simply reports: >>> from dicom import * # trying dicom.so DYLD_PREBIND_DEBUG is the only DYLD debug variable I could find. When importing Python hangs before it can report anything. Running GDB on Python... >>> from dicom import * Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done ^C Program received signal SIGINT, Interrupt. 0x90034a68 in semaphore_wait_trap () Looks like the libraries are loading properly.... A bt shows: (gdb) bt #0 0x90034a68 in semaphore_wait_trap () #1 0x9000a3b8 in pthread_mutex_lock () #2 0x00713c64 in std::locale::classic() () #3 0x007134c0 in std::locale::locale() () #4 0x0070424c in std::basic_filebuf >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () #5 0x0070e090 in std::ios_base::Init::_S_ios_create(bool) () #6 0x0070e414 in std::ios_base::Init::Init() () #7 0x00736654 in __static_initialization_and_destruction_0(int, int) () #8 0x007366a8 in _GLOBAL__I__Z14DIMSE_echoUserP17T_ASC_Associationt20T_DIMSE_BlockingMode iPtPP10DcmDataset () #9 0x8fe16914 in __dyld_call_module_initializers_for_library () #10 0x8fe16690 in __dyld_call_module_initializers () #11 0x8fe10b54 in __dyld_link_in_need_modules () #12 0x8fe10590 in __dyld_bind_lazy_symbol_reference () #13 0x8fe01040 in __dyld_stub_binding_helper_interface () #14 0x00713cbc in std::locale::classic() () #15 0x007134c0 in std::locale::locale() () #16 0x0070424c in std::basic_filebuf >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () #17 0x0070e090 in std::ios_base::Init::_S_ios_create(bool) () #18 0x0070e414 in std::ios_base::Init::Init() () #19 0x00733b70 in __static_initialization_and_destruction_0(int, int) () #20 0x00736284 in _GLOBAL__I_ASC_BADPRESENTATIONCONTEXTID () #21 0x8fe16914 in __dyld_call_module_initializers_for_library () #22 0x8fe16690 in __dyld_call_module_initializers () #23 0x8fe10b54 in __dyld_link_in_need_modules () #24 0x8fe10590 in __dyld_bind_lazy_symbol_reference () #25 0x8fe01040 in __dyld_stub_binding_helper_interface () #26 0x0070424c in std::basic_filebuf >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () #27 0x0070e090 in std::ios_base::Init::_S_ios_create(bool) () #28 0x0070e414 in std::ios_base::Init::Init() () #29 0x00733a9c in __static_initialization_and_destruction_0(int, int) () #30 0x00733af0 in _GLOBAL__I__Z21ASC_initializeNetwork17T_ASC_NetworkRoleiiPP13T_ASC_Netwo rk () #31 0x8fe16914 in __dyld_call_module_initializers_for_library () #32 0x8fe16690 in __dyld_call_module_initializers () #33 0x8fe10b54 in __dyld_link_in_need_modules () #34 0x8fe10590 in __dyld_bind_lazy_symbol_reference () #35 0x8fe01040 in __dyld_stub_binding_helper_interface () #36 0x003e6c1c in std::basic_filebuf >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () #37 0x003f0a60 in std::ios_base::Init::_S_ios_create(bool) () #38 0x003f0de4 in std::ios_base::Init::Init() () #39 0x0041904c in __static_initialization_and_destruction_0(int, int) () #40 0x00419378 in _GLOBAL__I_ECC_Normal () #41 0x8fe16914 in __dyld_call_module_initializers_for_library () #42 0x8fe16690 in __dyld_call_module_initializers () #43 0x8fe10b54 in __dyld_link_in_need_modules () #44 0x8fe10590 in __dyld_bind_lazy_symbol_reference () #45 0x8fe01040 in __dyld_stub_binding_helper_interface () #46 0x00418db4 in __static_initialization_and_destruction_0(int, int) () #47 0x00418e24 in _GLOBAL__I__ZN9OFConsoleC2Ev () #48 0x8fe16914 in __dyld_call_module_initializers_for_library () #49 0x8fe16690 in __dyld_call_module_initializers () #50 0x8fe10b54 in __dyld_link_in_need_modules () #51 0x8fe12648 in __dyld__dyld_link_module () #52 0x90017268 in NSLinkModule () #53 0x100aeee8 in _PyImport_GetDynLoadFunc (fqname=0xe
, shortname=0x30
, pathname=0xbfffe6e0 "dicom.so", fp=0x30) at Python/dynload_next.c:77 #54 0x1009e7e8 in _PyImport_LoadDynamicModule (name=0x0, pathname=0xbfffe6e0 "dicom.so", fp=0xa0006cb8) at Python/importdl.c:42 #55 0x1009aa20 in load_module (name=0xbfffebe0 "dicom", fp=0xa0006cb8, buf=0xbfffe6e0 "dicom.so", type=48, loader=0xe) at Python/import.c:1708 #56 0x1009ba08 in import_submodule (mod=0x100f34e4, subname=0xbfffebe0 "dicom", fullname=0xbfffebe0 "dicom") at Python/import.c:2290 #57 0x1009b494 in load_next (mod=0x100f34e4, altmod=0x100f34e4, p_name=0xa0006cb8, buf=0xbfffebe0 "dicom", p_buflen=0xbfffebe0) at Python/import.c:2111 #58 0x1009d6fc in import_module_ex (name=0x0, globals=0x3, locals=0x28, fromlist=0xb17b0) at Python/import.c:1957 #59 0x1009c5a0 in PyImport_ImportModuleEx (name=0xc8814 "dicom", globals=0xa89c0, locals=0xa89c0, fromlist=0xb17b0) at Python/import.c:1998 #60 0x100685f4 in builtin___import__ (self=0xe, args=0x3) at Python/bltinmodule.c:45 #61 0x1000c334 in PyObject_Call (func=0xe, arg=0x3, kw=0x28) at Objects/abstract.c:1755 #62 0x10074e5c in PyEval_CallObjectWithKeywords (func=0x94e68, arg=0x8f420, kw=0x0) at Python/ceval.c:3346 #63 0x10072930 in eval_frame (f=0x594a0) at Python/ceval.c:1996 #64 0x10073ebc in PyEval_EvalCodeEx (co=0x8f420, globals=0x3, locals=0xffffffdc, args=0x594a0, argcount=0, kws=0x0, kwcount=366064, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2663 #65 0x10076d18 in PyEval_EvalCode (co=0xe, globals=0x3, locals=0x28) at Python/ceval.c:537 #66 0x100a9dcc in run_node (n=0x0, filename=0x3
, globals=0xd4d82, locals=0x594a0, flags=0x907) at Python/pythonrun.c:1239 #67 0x100a92e4 in PyRun_InteractiveOneFlags (fp=0x8f420, filename=0x576a0 "", flags=0xb18d0) at Python/pythonrun.c:731 #68 0x100a90c4 in PyRun_InteractiveLoopFlags (fp=0xc84b4, filename=0x95140 "", flags=0x100d90ec) at Python/pythonrun.c:664 #69 0x100aaa28 in PyRun_AnyFileExFlags (fp=0xa0000cdc, filename=0x100df7bc "", closeit=0, flags=0xbffff530) at Python/pythonrun.c:627 #70 0x100b5b58 in Py_Main (argc=-1610609444, argv=0x100d52f4) at Modules/main.c:415 #71 0x00001b04 in _start (argc=-1610609444, argv=0x100d52f4, envp=0x0) at /SourceCache/Csu/Csu-45/crt.c:267 #72 0x00001984 in start () DIMSE_echoUser seems to be one of the functions that cause the problem (comment out the function, no problems). This looks like the problem is in the dcmtk libraries... but they work fine if linked with a C++ executable. Thanks, Robb On Wednesday, October 29, 2003, at 05:17 AM, Jack Jansen wrote: > > On 28 Oct 2003, at 23:55, Robb Brown wrote: > >> Thanks for the help some of you gave a month or so ago with my >> project to wrap dcmtk (a DICOM medical image transmission toolkit). >> I've figured out how to compile it as dynamic libraries on OS X. >> Python wrappers work better now. Unfortunately, there's still a >> problem. >> >> When certain functions are present, importing the module will hang >> Python. Commenting out these functions lets the module import and >> you can use what's left. How come this code hangs Python right when >> importing? > > See if you can find out what it does when it hangs. The first step > would be to use "python -vv", which will trace all imports (and all > places it looked before importing). The next step is to set the dyld > debug environment variables (see "man dyld"), which will trace the > dynamic loading of code. Then you could try to do a system call trace > (see "man ktrace") while importing. Finally you could try running > python under gdb, hitting control-C when it hangs and see what it's > doing. > -- > Jack Jansen http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > _____________________________ Robb Brown Seaman Family MR Center Calgary, AB From fonnesbeck at mac.com Wed Oct 29 12:19:12 2003 From: fonnesbeck at mac.com (Christopher Fonnesbeck) Date: Wed Oct 29 12:19:25 2003 Subject: [Pythonmac-SIG] scrolling behaviour in MacPython Message-ID: <03F6A854-0A34-11D8-B3F3-000A956FDAC0@mac.com> Normally, in python you can scroll back in the command history by using the up arrow key. However, when I try and scroll in MacPython 2.3, I get strange characters rather than the previous commands: >>> ^[[A Any cure for this? -- Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g ) Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia From mwh at python.net Wed Oct 29 12:26:26 2003 From: mwh at python.net (Michael Hudson) Date: Wed Oct 29 12:26:29 2003 Subject: [Pythonmac-SIG] scrolling behaviour in MacPython In-Reply-To: <03F6A854-0A34-11D8-B3F3-000A956FDAC0@mac.com> (Christopher Fonnesbeck's message of "Wed, 29 Oct 2003 12:19:12 -0500") References: <03F6A854-0A34-11D8-B3F3-000A956FDAC0@mac.com> Message-ID: <2my8v4j6pp.fsf@starship.python.net> Christopher Fonnesbeck writes: > Normally, in python you can scroll back in the command history by > using the up arrow key. However, when I try and scroll in MacPython > 2.3, I get strange characters rather than the previous commands: > > >>> ^[[A > > Any cure for this? You need a readline module. I thought Jack's MacPython distribution came with one of them, though. Are you using that or the Apple installed Python 2.3 on Panther? Cheers, mwh -- Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jeff Raskin From bob at redivi.com Wed Oct 29 12:28:39 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 29 12:29:07 2003 Subject: [Pythonmac-SIG] scrolling behaviour in MacPython In-Reply-To: <03F6A854-0A34-11D8-B3F3-000A956FDAC0@mac.com> References: <03F6A854-0A34-11D8-B3F3-000A956FDAC0@mac.com> Message-ID: <55ED6C8E-0A35-11D8-B11C-000A95686CD8@redivi.com> On Oct 29, 2003, at 12:19 PM, Christopher Fonnesbeck wrote: > Normally, in python you can scroll back in the command history by > using the up arrow key. However, when I try and scroll in MacPython > 2.3, I get strange characters rather than the previous commands: > > >>> ^[[A > > Any cure for this? Install the readline module with PackageManager. If you have a "stock Panther" MacPython 2.3, then you need to download the "installer for 10.3" here: http://homepages.cwi.nl/~jack/macpython/download.html When you install, you'll have a PackageManager application at /Applications/MacPython-2.3 -- open that up and install readline. You should be good to go after that. -bob From bob at redivi.com Wed Oct 29 12:36:02 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 29 12:37:21 2003 Subject: [Pythonmac-SIG] scrolling behaviour in MacPython In-Reply-To: <55ED6C8E-0A35-11D8-B11C-000A95686CD8@redivi.com> References: <03F6A854-0A34-11D8-B3F3-000A956FDAC0@mac.com> <55ED6C8E-0A35-11D8-B11C-000A95686CD8@redivi.com> Message-ID: <5DE748FA-0A36-11D8-B11C-000A95686CD8@redivi.com> On Oct 29, 2003, at 12:28 PM, Bob Ippolito wrote: > > On Oct 29, 2003, at 12:19 PM, Christopher Fonnesbeck wrote: > >> Normally, in python you can scroll back in the command history by >> using the up arrow key. However, when I try and scroll in MacPython >> 2.3, I get strange characters rather than the previous commands: >> >> >>> ^[[A >> >> Any cure for this? > > Install the readline module with PackageManager. > > If you have a "stock Panther" MacPython 2.3, then you need to download > the "installer for 10.3" here: > http://homepages.cwi.nl/~jack/macpython/download.html > > When you install, you'll have a PackageManager application at > /Applications/MacPython-2.3 -- open that up and install readline. You > should be good to go after that. BTW, I just added this as a FAQ entry on the pythonmac.org wiki: http://pythonmac.org/wiki/FAQ -bob From drewmccormack at mac.com Wed Oct 29 12:39:58 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Wed Oct 29 12:40:46 2003 Subject: [Pythonmac-SIG] ANN: iChat channel for MacPython and PyObjC In-Reply-To: References: Message-ID: On Oct 29, 2003, at 3:34 PM, Bob Ippolito wrote: > > On Oct 29, 2003, at 9:09 AM, Nigel King wrote: > >>> There's a iChat channel called "MacPython" now. Hit cmd-G in iChat >>> and >>> type the channel name. See you there! >> Presumably one needs an AIM account to be active to do this? > > AIM or .mac, I believe. You can get a free iChat .mac account by signing up for a free .mac trial. Don't know if that also means you will be hounded for ever more to join .mac. Probably. Drew From bob at redivi.com Wed Oct 29 12:56:57 2003 From: bob at redivi.com (Bob Ippolito) Date: Wed Oct 29 12:57:23 2003 Subject: [Pythonmac-SIG] ANN: iChat channel for MacPython and PyObjC In-Reply-To: References: Message-ID: <49C16E01-0A39-11D8-B11C-000A95686CD8@redivi.com> On Oct 29, 2003, at 12:39 PM, Drew McCormack wrote: > > On Oct 29, 2003, at 3:34 PM, Bob Ippolito wrote: > >> >> On Oct 29, 2003, at 9:09 AM, Nigel King wrote: >> >>>> There's a iChat channel called "MacPython" now. Hit cmd-G in iChat >>>> and >>>> type the channel name. See you there! >>> Presumably one needs an AIM account to be active to do this? >> >> AIM or .mac, I believe. > You can get a free iChat .mac account by signing up for a free .mac > trial. Don't know if that also means you will be hounded for ever more > to join .mac. Probably. You can get a free AIM account (not a trial), from http://www.aim.com/ -- click "Get Started" under the "How do I start?" heading on the right sidebar. -bob From pecora at anvil.nrl.navy.mil Wed Oct 29 14:46:25 2003 From: pecora at anvil.nrl.navy.mil (Louis M. Pecora) Date: Wed Oct 29 14:47:01 2003 Subject: [Pythonmac-SIG] Re: PYTHONPATH on OS X In-Reply-To: <200310282102.h9SL2M417624@laplace.astro.cornell.edu> References: <200310282102.h9SL2M417624@laplace.astro.cornell.edu> Message-ID: >Hi Louis- > >I saw your MacPy post and thought I'd point out this URL. I have a >similar problem and just came across this via the Dr. Dobb's Python-URL >for this week: > >http://www.astro.washington.edu/owen/AquaEnvVar.html > >Hope it helps. If you are just using Python in a terminal window, >the usual unix approach of defining PYTHONPATH in your .cshrc works. >But for Python launched from the Finder, you have to play other games. Thanks, Tom. Much appreciated. I am using the IDE launched from the Finder so I had to (1) Create the directory .MacOSX, (2) Create the file Environment.plist, (3) Edit that file with the plist editor from the Apple development tools and add the PYTHONPATH variable with multiple paths defined and separated by colons. Careful if you do it this way since 'option' characters are not treated well, i.e. apparently not recognized in the actual file path. There's probably a work-around for the latter. Now that I have the Environment.plist I can actually use BBEdit to change it by choosing Open Hidden in the File menu. Creating the file from scratch would be tough since it's an XML file -- about which I know nuthin'. But easy to change once you see the layout. Jack Jensen has been looking for suggestions for a better way to do this. I thought about writing a Python script to do it, but time may not let me get to that right away. >Thanks for the pointer to Bob's packaging of Piddle. I've been >looking for simple plotting with Python on OS X for the last few >days; Bob must have added this since I last checked his site. Yeah, Piddle is a neat little package. Easy to build up your own plotting functions from some simple Piddle calls. I'm very happy someone is keeping it current. -- Cheers, Lou Pecora From Larry.A.Meyn at nasa.gov Wed Oct 29 15:00:22 2003 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed Oct 29 15:00:31 2003 Subject: [Pythonmac-SIG] Re: PYTHONPATH on OS X In-Reply-To: References: <200310282102.h9SL2M417624@laplace.astro.cornell.edu> Message-ID: <8794DF4C-0A4A-11D8-B3FA-000A95A06CF6@nasa.gov> Another option to set environment variable on OS X is a preference pane utility available at: http://www.rubicode.com/Software/RCEnvironment/ --Larry Meyn On Oct 29, 2003, at 11:46 AM, Louis M. Pecora wrote: >> Hi Louis- >> >> I saw your MacPy post and thought I'd point out this URL. I have a >> similar problem and just came across this via the Dr. Dobb's >> Python-URL >> for this week: >> >> http://www.astro.washington.edu/owen/AquaEnvVar.html >> >> Hope it helps. If you are just using Python in a terminal window, >> the usual unix approach of defining PYTHONPATH in your .cshrc works. >> But for Python launched from the Finder, you have to play other games. > > Thanks, Tom. Much appreciated. I am using the IDE launched from the > Finder so I had to (1) Create the directory .MacOSX, (2) Create the > file Environment.plist, (3) Edit that file with the plist editor from > the Apple development tools and add the PYTHONPATH variable with > multiple paths defined and separated by colons. Careful if you do it > this way since 'option' characters are not treated well, i.e. > apparently not recognized in the actual file path. There's probably a > work-around for the latter. Now that I have the Environment.plist I > can actually use BBEdit to change it by choosing Open Hidden in the > File menu. Creating the file from scratch would be tough since it's > an XML file -- about which I know nuthin'. But easy to change once > you see the layout. Jack Jensen has been looking for suggestions for > a better way to do this. I thought about writing a Python script to > do it, but time may not let me get to that right away. > >> Thanks for the pointer to Bob's packaging of Piddle. I've been >> looking for simple plotting with Python on OS X for the last few >> days; Bob must have added this since I last checked his site. > > Yeah, Piddle is a neat little package. Easy to build up your own > plotting functions from some simple Piddle calls. I'm very happy > someone is keeping it current. > > -- > > Cheers, > > Lou Pecora > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From krjackson at lbl.gov Wed Oct 29 15:13:16 2003 From: krjackson at lbl.gov (Keith Jackson) Date: Wed Oct 29 15:13:23 2003 Subject: [Pythonmac-SIG] ext build problem In-Reply-To: Message-ID: <54EE5F0C-0A4C-11D8-A96E-000A9577489A@lbl.gov> Jack, thanks for the answer. I'll look at the right _NSGetEnviron() call. This will work fine for my code. Is there a problem with using the "--bundle_loader" option to the linker to solve this problem when I don't have an easy way to modify the C code? If I understand correctly, I could modify the setup.py to add the bundle loader option, and then the bundle would be able to link to the _environ in the python inerpreter. thanks again for you help, --keith On Wednesday, October 29, 2003, at 04:23 AM, Jack Jansen wrote: > > On 29 Oct 2003, at 0:35, Keith Jackson wrote: > >> All, >> Once again I've run into the "_environ" problem while trying to build >> 4Suite. I'm using python2.3.2 built as a framework build. As part of >> trying to debug this, I've written a very simple test that shows the >> same behavior for me. I'd appreciate it if someone else could try >> this and see if they see the same behavior. Also, if I'm doing >> something dumb please let me know. ;) > > It's not you who's doing something dumb, it's Apple:-) > > _environ is defined in crt0, which means you don't have access to it > in shared libraries or bundles. The workaround is to call > _NSGetEnviron() to get at the environment pointer, see > Modules/posixmodule.c for a way to do this in one place in your code > that will make _environ available to all the rest of your shared > library (or bundle). > -- > Jack Jansen http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > From Jack.Jansen at cwi.nl Wed Oct 29 16:28:49 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 29 16:28:56 2003 Subject: [Pythonmac-SIG] Problems wrapping In-Reply-To: References: Message-ID: Whoaa... This looks like really funky C++ static initializer stuff. Frame 52 is the most recent one "in Python", it loads your extension module, presumably. Then we get static initializers calling other static initializers and so on (frames 49, 42, 32, 22), and it appears we've gotten into some infinite loop trying to initialize some streams stuff. I would have a closer look at > #40 0x00419378 in _GLOBAL__I_ECC_Normal () because somewhere there you seem to get into the infinite loop. On 29-okt-03, at 18:03, Robb Brown wrote: > > Looks like the libraries are loading properly.... > > A bt shows: > > (gdb) bt > #0 0x90034a68 in semaphore_wait_trap () > #1 0x9000a3b8 in pthread_mutex_lock () > #2 0x00713c64 in std::locale::classic() () > #3 0x007134c0 in std::locale::locale() () > #4 0x0070424c in std::basic_filebuf > >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () > #5 0x0070e090 in std::ios_base::Init::_S_ios_create(bool) () > #6 0x0070e414 in std::ios_base::Init::Init() () > #7 0x00736654 in __static_initialization_and_destruction_0(int, int) > () > #8 0x007366a8 in > _GLOBAL__I__Z14DIMSE_echoUserP17T_ASC_Associationt20T_DIMSE_BlockingMod > eiPtPP10DcmDataset () > #9 0x8fe16914 in __dyld_call_module_initializers_for_library () > #10 0x8fe16690 in __dyld_call_module_initializers () > #11 0x8fe10b54 in __dyld_link_in_need_modules () > #12 0x8fe10590 in __dyld_bind_lazy_symbol_reference () > #13 0x8fe01040 in __dyld_stub_binding_helper_interface () > #14 0x00713cbc in std::locale::classic() () > #15 0x007134c0 in std::locale::locale() () > #16 0x0070424c in std::basic_filebuf > >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () > #17 0x0070e090 in std::ios_base::Init::_S_ios_create(bool) () > #18 0x0070e414 in std::ios_base::Init::Init() () > #19 0x00733b70 in __static_initialization_and_destruction_0(int, int) > () > #20 0x00736284 in _GLOBAL__I_ASC_BADPRESENTATIONCONTEXTID () > #21 0x8fe16914 in __dyld_call_module_initializers_for_library () > #22 0x8fe16690 in __dyld_call_module_initializers () > #23 0x8fe10b54 in __dyld_link_in_need_modules () > #24 0x8fe10590 in __dyld_bind_lazy_symbol_reference () > #25 0x8fe01040 in __dyld_stub_binding_helper_interface () > #26 0x0070424c in std::basic_filebuf > >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () > #27 0x0070e090 in std::ios_base::Init::_S_ios_create(bool) () > #28 0x0070e414 in std::ios_base::Init::Init() () > #29 0x00733a9c in __static_initialization_and_destruction_0(int, int) > () > #30 0x00733af0 in > _GLOBAL__I__Z21ASC_initializeNetwork17T_ASC_NetworkRoleiiPP13T_ASC_Netw > ork () > #31 0x8fe16914 in __dyld_call_module_initializers_for_library () > #32 0x8fe16690 in __dyld_call_module_initializers () > #33 0x8fe10b54 in __dyld_link_in_need_modules () > #34 0x8fe10590 in __dyld_bind_lazy_symbol_reference () > #35 0x8fe01040 in __dyld_stub_binding_helper_interface () > #36 0x003e6c1c in std::basic_filebuf > >::basic_filebuf(__sFILE*, std::_Ios_Openmode, int) () > #37 0x003f0a60 in std::ios_base::Init::_S_ios_create(bool) () > #38 0x003f0de4 in std::ios_base::Init::Init() () > #39 0x0041904c in __static_initialization_and_destruction_0(int, int) > () > #40 0x00419378 in _GLOBAL__I_ECC_Normal () > #41 0x8fe16914 in __dyld_call_module_initializers_for_library () > #42 0x8fe16690 in __dyld_call_module_initializers () > #43 0x8fe10b54 in __dyld_link_in_need_modules () > #44 0x8fe10590 in __dyld_bind_lazy_symbol_reference () > #45 0x8fe01040 in __dyld_stub_binding_helper_interface () > #46 0x00418db4 in __static_initialization_and_destruction_0(int, int) > () > #47 0x00418e24 in _GLOBAL__I__ZN9OFConsoleC2Ev () > #48 0x8fe16914 in __dyld_call_module_initializers_for_library () > #49 0x8fe16690 in __dyld_call_module_initializers () > #50 0x8fe10b54 in __dyld_link_in_need_modules () > #51 0x8fe12648 in __dyld__dyld_link_module () > #52 0x90017268 in NSLinkModule () > #53 0x100aeee8 in _PyImport_GetDynLoadFunc (fqname=0xe
out of bounds>, shortname=0x30
, > pathname=0xbfffe6e0 "dicom.so", fp=0x30) at Python/dynload_next.c:77 > #54 0x1009e7e8 in _PyImport_LoadDynamicModule (name=0x0, > pathname=0xbfffe6e0 "dicom.so", fp=0xa0006cb8) at Python/importdl.c:42 > #55 0x1009aa20 in load_module (name=0xbfffebe0 "dicom", fp=0xa0006cb8, > buf=0xbfffe6e0 "dicom.so", type=48, loader=0xe) at > Python/import.c:1708 > #56 0x1009ba08 in import_submodule (mod=0x100f34e4, subname=0xbfffebe0 > "dicom", fullname=0xbfffebe0 "dicom") at Python/import.c:2290 > #57 0x1009b494 in load_next (mod=0x100f34e4, altmod=0x100f34e4, > p_name=0xa0006cb8, buf=0xbfffebe0 "dicom", p_buflen=0xbfffebe0) at > Python/import.c:2111 > #58 0x1009d6fc in import_module_ex (name=0x0, globals=0x3, > locals=0x28, fromlist=0xb17b0) at Python/import.c:1957 > #59 0x1009c5a0 in PyImport_ImportModuleEx (name=0xc8814 "dicom", > globals=0xa89c0, locals=0xa89c0, fromlist=0xb17b0) at > Python/import.c:1998 > #60 0x100685f4 in builtin___import__ (self=0xe, args=0x3) at > Python/bltinmodule.c:45 > #61 0x1000c334 in PyObject_Call (func=0xe, arg=0x3, kw=0x28) at > Objects/abstract.c:1755 > #62 0x10074e5c in PyEval_CallObjectWithKeywords (func=0x94e68, > arg=0x8f420, kw=0x0) at Python/ceval.c:3346 > #63 0x10072930 in eval_frame (f=0x594a0) at Python/ceval.c:1996 > #64 0x10073ebc in PyEval_EvalCodeEx (co=0x8f420, globals=0x3, > locals=0xffffffdc, args=0x594a0, argcount=0, kws=0x0, kwcount=366064, > defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2663 > #65 0x10076d18 in PyEval_EvalCode (co=0xe, globals=0x3, locals=0x28) > at Python/ceval.c:537 > #66 0x100a9dcc in run_node (n=0x0, filename=0x3
bounds>, globals=0xd4d82, locals=0x594a0, flags=0x907) at > Python/pythonrun.c:1239 > #67 0x100a92e4 in PyRun_InteractiveOneFlags (fp=0x8f420, > filename=0x576a0 "", flags=0xb18d0) at Python/pythonrun.c:731 > #68 0x100a90c4 in PyRun_InteractiveLoopFlags (fp=0xc84b4, > filename=0x95140 "", flags=0x100d90ec) at Python/pythonrun.c:664 > #69 0x100aaa28 in PyRun_AnyFileExFlags (fp=0xa0000cdc, > filename=0x100df7bc "", closeit=0, flags=0xbffff530) at > Python/pythonrun.c:627 > #70 0x100b5b58 in Py_Main (argc=-1610609444, argv=0x100d52f4) at > Modules/main.c:415 > #71 0x00001b04 in _start (argc=-1610609444, argv=0x100d52f4, envp=0x0) > at /SourceCache/Csu/Csu-45/crt.c:267 > #72 0x00001984 in start () -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Wed Oct 29 16:40:16 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Wed Oct 29 16:40:22 2003 Subject: [Pythonmac-SIG] ext build problem In-Reply-To: <54EE5F0C-0A4C-11D8-A96E-000A9577489A@lbl.gov> References: <54EE5F0C-0A4C-11D8-A96E-000A9577489A@lbl.gov> Message-ID: <7C4E2F4C-0A58-11D8-81E3-000A27B19B96@cwi.nl> On 29-okt-03, at 21:13, Keith Jackson wrote: > Jack, > thanks for the answer. I'll look at the right _NSGetEnviron() call. > This will work fine for my code. > > Is there a problem with using the "--bundle_loader" option to the > linker to solve this problem when I don't have an easy way to modify > the C code? If I understand correctly, I could modify the setup.py to > add the bundle loader option, and then the bundle would be able to > link to the _environ in the python inerpreter. Sounds like it could work. Let us know, -- 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 artelse at mohr-i.nl Wed Oct 29 16:54:50 2003 From: artelse at mohr-i.nl (Arthur Elsenaar) Date: Wed Oct 29 16:55:02 2003 Subject: [Pythonmac-SIG] Documentation in PM? Message-ID: <84F6CB86-0A5A-11D8-9AFC-000393825740@mohr-i.nl> Hi, wondering where the documentation download went in the 10.3 Package Manager. Jack? Thx, Arthur. From raf.verbruggen at club.worldonline.be Wed Oct 29 16:21:39 2003 From: raf.verbruggen at club.worldonline.be (raf.verbruggen@club.worldonline.be) Date: Wed Oct 29 17:04:29 2003 Subject: [Pythonmac-SIG] You have sent me a virus! Message-ID: <42608022689819.53282.X-MailerV8.60@club.worldonline.be> I permanently get Spam-Mails from you and inside is a virus!! You should remove these thing. Read the document, before another or my mailbox explode! Yours sincerely: raf.verbruggen@club.worldonline.be -------------- next part -------------- A non-text attachment was scrubbed... Name: Norton AntiVirus is verwijderd1.txt Type: plain/text Size: 122 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031029/c60963af/NortonAntiVirusisverwijderd1.bin From krjackson at lbl.gov Wed Oct 29 17:31:22 2003 From: krjackson at lbl.gov (Keith Jackson) Date: Wed Oct 29 17:31:28 2003 Subject: [Pythonmac-SIG] ext build problem In-Reply-To: <7C4E2F4C-0A58-11D8-81E3-000A27B19B96@cwi.nl> Message-ID: <9FC63DE0-0A5F-11D8-A96E-000A9577489A@lbl.gov> On Wednesday, October 29, 2003, at 01:40 PM, Jack Jansen wrote: > > On 29-okt-03, at 21:13, Keith Jackson wrote: > >> Is there a problem with using the "--bundle_loader" option to the >> linker to solve this problem when I don't have an easy way to modify >> the C code? If I understand correctly, I could modify the setup.py to >> add the bundle loader option, and then the bundle would be able to >> link to the _environ in the python inerpreter. > > Sounds like it could work. Let us know, > It works fine for building 4Suite. It also works for building a bunch of my own code. I tried it on a couple of modules that built fine without it, and they still work. Should this be in the LDSHARED variable in the python Makefile. That way all bundles would be built with the -bundle_loader option? This seems a lot easier then having all extension module writers ifdef their code to use environ. --keith From janssen at parc.com Wed Oct 29 21:27:10 2003 From: janssen at parc.com (Bill Janssen) Date: Wed Oct 29 21:28:37 2003 Subject: [Pythonmac-SIG] building Python 2.3.2 on Panther without frameworks? Message-ID: <03Oct29.182712pst."58611"@synergy1.parc.xerox.com> I can't seem to build 2.3 from source without the darn MacOSX frameworks getting into the act. I configure with ./configure --disable-toolbox-glue --disable-framework but still get lots of lines like this: gcc -g -bundle -bundle_loader python.exe build/temp.darwin-7.0.0-Power_Macintosh-2.3/_Qdmodule.o -L/usr/local/lib -o build/lib.darwin-7.0.0-Power_Macintosh-2.3/_Qd.so -framework Carbon What's going on here? How do I make it stop? Bill From janssen at parc.com Wed Oct 29 21:30:31 2003 From: janssen at parc.com (Bill Janssen) Date: Wed Oct 29 21:30:57 2003 Subject: [Pythonmac-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther Message-ID: <03Oct29.183038pst."58611"@synergy1.parc.xerox.com> When I install PIL 1.1.4 against the default /usr/bin/python on Panther (Mac OS 10.3), things seem to build and install fine. The little "coretest" program in PIL runs OK. However, when I fire up python, and try to "import Image", I get the following: % /usr/bin/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 Image Fatal Python error: Interpreter not initialized (version mismatch?) Abort % I've tried re-building python from source and re-installing PIL, with the same results. Any ideas? Bill From halloleo at myrealbox.com Wed Oct 29 21:48:12 2003 From: halloleo at myrealbox.com (leo) Date: Wed Oct 29 21:47:51 2003 Subject: [Pythonmac-SIG] Re: PYTHONPATH on OS X References: <200310282102.h9SL2M417624@laplace.astro.cornell.edu> <8794DF4C-0A4A-11D8-B3FA-000A95A06CF6@nasa.gov> Message-ID: <04b701c39e90$4330b290$a800000a@Odyssey.local> hi there just read the thing about ~/.MacOSX/environment.plist en passant... it's great! thanks, leo ----- Original Message ----- From: "Larry Meyn" To: "Louis Pecora" Cc: ; "Tom Loredo" Sent: Thursday, October 30, 2003 7:00 AM Subject: Re: [Pythonmac-SIG] Re: PYTHONPATH on OS X > Another option to set environment variable on OS X is a preference pane > utility available at: > http://www.rubicode.com/Software/RCEnvironment/ > > --Larry Meyn > > On Oct 29, 2003, at 11:46 AM, Louis M. Pecora wrote: > > >> Hi Louis- > >> > >> I saw your MacPy post and thought I'd point out this URL. I have a > >> similar problem and just came across this via the Dr. Dobb's > >> Python-URL > >> for this week: > >> > >> http://www.astro.washington.edu/owen/AquaEnvVar.html > >> > >> Hope it helps. If you are just using Python in a terminal window, > >> the usual unix approach of defining PYTHONPATH in your .cshrc works. > >> But for Python launched from the Finder, you have to play other games. > > > > Thanks, Tom. Much appreciated. I am using the IDE launched from the > > Finder so I had to (1) Create the directory .MacOSX, (2) Create the > > file Environment.plist, (3) Edit that file with the plist editor from > > the Apple development tools and add the PYTHONPATH variable with > > multiple paths defined and separated by colons. Careful if you do it > > this way since 'option' characters are not treated well, i.e. > > apparently not recognized in the actual file path. There's probably a > > work-around for the latter. Now that I have the Environment.plist I > > can actually use BBEdit to change it by choosing Open Hidden in the > > File menu. Creating the file from scratch would be tough since it's > > an XML file -- about which I know nuthin'. But easy to change once > > you see the layout. Jack Jensen has been looking for suggestions for > > a better way to do this. I thought about writing a Python script to > > do it, but time may not let me get to that right away. > > > >> Thanks for the pointer to Bob's packaging of Piddle. I've been > >> looking for simple plotting with Python on OS X for the last few > >> days; Bob must have added this since I last checked his site. > > > > Yeah, Piddle is a neat little package. Easy to build up your own > > plotting functions from some simple Piddle calls. I'm very happy > > someone is keeping it current. > > > > -- > > > > Cheers, > > > > Lou Pecora > > > > > > _______________________________________________ > > 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 drewmccormack at mac.com Thu Oct 30 00:04:44 2003 From: drewmccormack at mac.com (Drew McCormack) Date: Thu Oct 30 00:04:54 2003 Subject: [Pythonmac-SIG] ANN: iChat channel for MacPython and PyObjC In-Reply-To: <49C16E01-0A39-11D8-B11C-000A95686CD8@redivi.com> References: <49C16E01-0A39-11D8-B11C-000A95686CD8@redivi.com> Message-ID: <934CC33D-0A96-11D8-98CC-00039363BC02@mac.com> On Oct 29, 2003, at 6:56 PM, Bob Ippolito wrote: > > On Oct 29, 2003, at 12:39 PM, Drew McCormack wrote: > >> >> On Oct 29, 2003, at 3:34 PM, Bob Ippolito wrote: >> >>> >>> On Oct 29, 2003, at 9:09 AM, Nigel King wrote: >>> >>>>> There's a iChat channel called "MacPython" now. Hit cmd-G in iChat >>>>> and >>>>> type the channel name. See you there! >>>> Presumably one needs an AIM account to be active to do this? >>> >>> AIM or .mac, I believe. >> You can get a free iChat .mac account by signing up for a free .mac >> trial. Don't know if that also means you will be hounded for ever >> more to join .mac. Probably. > > You can get a free AIM account (not a trial), from http://www.aim.com/ > -- click "Get Started" under the "How do I start?" heading on the > right sidebar. > I should have pointed out that although the .mac account is a trial, the iChat account continues forever: it is not a trial. Drew From mwh at python.net Thu Oct 30 06:21:07 2003 From: mwh at python.net (Michael Hudson) Date: Thu Oct 30 06:21:12 2003 Subject: [Pythonmac-SIG] Re: PYTHONPATH on OS X In-Reply-To: <8794DF4C-0A4A-11D8-B3FA-000A95A06CF6@nasa.gov> (Larry Meyn's message of "Wed, 29 Oct 2003 12:00:22 -0800") References: <200310282102.h9SL2M417624@laplace.astro.cornell.edu> <8794DF4C-0A4A-11D8-B3FA-000A95A06CF6@nasa.gov> Message-ID: <2md6cfj7j0.fsf@starship.python.net> Larry Meyn writes: > Another option to set environment variable on OS X is a preference > pane utility available at: > http://www.rubicode.com/Software/RCEnvironment/ Or the EnvironmentPrefs example from PyObjC :-) Cheers, mwh -- Q: What are 1000 lawyers at the bottom of the ocean? A: A good start. (A lawyer told me this joke.) -- Michael Str?der, comp.lang.python From thefattestmanintheworld at yahoo.com Thu Oct 30 13:04:13 2003 From: thefattestmanintheworld at yahoo.com (fat man) Date: Thu Oct 30 13:04:56 2003 Subject: [Pythonmac-SIG] upgrading to OS 10.3 Message-ID: <20031030180413.97675.qmail@web41106.mail.yahoo.com> I'm a new mac user and currently have python installed on my OS 10.2 machine. I will soon be upgrading to 10.3 and was wondering if i might run into any problems upgrading (as 10.3 'includes' most of python). would it be necessary/best to remove python before upgrading? if so, how would i go about doing this (like i said i'm new to macs, i apologize if this is a rather novice question). would dragging the python folder to the trash be sufficient or does the installation of python on 10.2 change system files. thanks for any and all help on the issue. -r __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ From loredo at astro.cornell.edu Thu Oct 30 17:42:33 2003 From: loredo at astro.cornell.edu (Tom Loredo) Date: Thu Oct 30 17:42:39 2003 Subject: [Pythonmac-SIG] PackMan issues Message-ID: <200310302242.h9UMgXt20265@laplace.astro.cornell.edu> Hi folks- I love the package manager, but would like to raise the following issues (possible bug; feature requests): When I try to use PM at Bob I's pimp site, the list of packages is larger than the window. I can scroll down to see the bottom part of the list, but as soon as I release the scrollbar it immediately scrolls back up to the top of the list. Thus many of his packages are inaccessible. This is using MacPy2.3 on OS 10.2.6 on a G4 Quicksilver and on a G3 Powerbook. My G4 is at home with a dialup connection; my G3 I can bring to work with T3 access. Having one machine with a slow net connection is behind the following requests. First, I'd love to see package size information in the PM window. This way I can tell if it's realistic to download a package to my G4 over my dialup connection. Second, I'd love to see useful progress info on the download and installation. If I check "verbose," PM tries to produce this, but unfortuately the resulting text window update is too slow and I'll typically not see *any* of the progress lines until the download is complete, at which point the window happily shows me every status line from the start to 100%. Finally, I'd love for there to be a way to save a package locally in a way allowing it to be moved to another machine and installed via PM there. Perhaps I can just sync the site-packages directories on both machines, but I don't know if some of the packages have other side effects. Is this feasible? Ideally I'd like to grab the packages on my G3 at work, and install them on my G4 at home. I suppose I could do it directly with distutils, but it would be neat if PM could do this. Thanks, Tom Loredo From wtbridgman at radix.net Thu Oct 30 19:30:33 2003 From: wtbridgman at radix.net (W.T. Bridgman) Date: Thu Oct 30 19:30:49 2003 Subject: [Pythonmac-SIG] PackMan issues In-Reply-To: <200310302242.h9UMgXt20265@laplace.astro.cornell.edu> Message-ID: <70B3B81C-0B39-11D8-8894-0050E485FC7A@radix.net> Tom, I second this. I'm in a similar situation with fast connections at work and a slow one at home. I've tried PM a few times after it's initial release. One complaint is that it doesn't report the size of the package so you can tell if it's practical to update over a slow connection. I think I waited quite a while for the documentation package to install. I often retrieve the disk images & tarballs at work for building at home from sources. Also, I have root privileges on my home systems but only sudo limited access at work. Tom On Thursday, October 30, 2003, at 05:42 PM, Tom Loredo wrote: > > Hi folks- > > I love the package manager, but would like to raise the following > issues (possible bug; feature requests): > > When I try to use PM at Bob I's pimp site, the list of packages is > larger than the window. I can scroll down to see the bottom part of > the list, but as soon as I release the scrollbar it immediately scrolls > back up to the top of the list. Thus many of his packages are > inaccessible. This is using MacPy2.3 on OS 10.2.6 on a G4 Quicksilver > and on a G3 Powerbook. > > My G4 is at home with a dialup connection; my G3 I can bring to > work with T3 access. Having one machine with a slow net connection > is behind the following requests. > > First, I'd love to see package size information in the PM window. > This way I can tell if it's realistic to download a package to > my G4 over my dialup connection. > > Second, I'd love to see useful progress info on the download and > installation. If I check "verbose," PM tries to produce this, > but unfortuately the resulting text window update is too slow and > I'll typically not see *any* of the progress lines until the > download is complete, at which point the window happily shows > me every status line from the start to 100%. > > Finally, I'd love for there to be a way to save a package locally > in a way allowing it to be moved to another machine and installed > via PM there. Perhaps I can just sync the site-packages > directories on both machines, but I don't know if some of the > packages have other side effects. Is this feasible? Ideally > I'd like to grab the packages on my G3 at work, and install them > on my G4 at home. I suppose I could do it directly with distutils, > but it would be neat if PM could do this. > > Thanks, > Tom Loredo > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From wladimir at brandeis.edu Thu Oct 30 19:44:46 2003 From: wladimir at brandeis.edu (Wladimir Labeikovsky) Date: Thu Oct 30 19:44:51 2003 Subject: [Pythonmac-SIG] make packages w/o packman Message-ID: <6C9894B8-0B3B-11D8-BE87-00306575F888@brandeis.edu> hullo, could somebody point towards info on how to build external python packages for use with framework python? e.g. how to take the ,say, numeric sources from numpy.org and change, say, setup.py so that it builds and installs correctly against panther builtin python.... thanks!! w From bob at redivi.com Thu Oct 30 19:43:42 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 30 19:44:56 2003 Subject: [Pythonmac-SIG] PackMan issues In-Reply-To: <70B3B81C-0B39-11D8-8894-0050E485FC7A@radix.net> References: <70B3B81C-0B39-11D8-8894-0050E485FC7A@radix.net> Message-ID: <4698C07F-0B3B-11D8-8AA8-000A95686CD8@redivi.com> It would be great if you guys could update the pythonmac.org wiki with these comments.. the appropriate section is: http://pythonmac.org/wiki/NewPackageManager It's pretty well known that PackageManager is missing a lot of useful features, and we're trying to figure out what we need in the next version before we start writing it. -bob On Oct 30, 2003, at 7:30 PM, W.T. Bridgman wrote: > Tom, > > I second this. I'm in a similar situation with fast connections at > work and a slow one at home. > > I've tried PM a few times after it's initial release. One complaint > is that it doesn't report the size of the package so you can tell if > it's practical to update over a slow connection. I think I waited > quite a while for the documentation package to install. > > I often retrieve the disk images & tarballs at work for building at > home from sources. Also, I have root privileges on my home systems > but only sudo limited access at work. > > Tom > On Thursday, October 30, 2003, at 05:42 PM, Tom Loredo wrote: > >> >> Hi folks- >> >> I love the package manager, but would like to raise the following >> issues (possible bug; feature requests): >> >> When I try to use PM at Bob I's pimp site, the list of packages is >> larger than the window. I can scroll down to see the bottom part of >> the list, but as soon as I release the scrollbar it immediately >> scrolls >> back up to the top of the list. Thus many of his packages are >> inaccessible. This is using MacPy2.3 on OS 10.2.6 on a G4 Quicksilver >> and on a G3 Powerbook. >> >> My G4 is at home with a dialup connection; my G3 I can bring to >> work with T3 access. Having one machine with a slow net connection >> is behind the following requests. >> >> First, I'd love to see package size information in the PM window. >> This way I can tell if it's realistic to download a package to >> my G4 over my dialup connection. >> >> Second, I'd love to see useful progress info on the download and >> installation. If I check "verbose," PM tries to produce this, >> but unfortuately the resulting text window update is too slow and >> I'll typically not see *any* of the progress lines until the >> download is complete, at which point the window happily shows >> me every status line from the start to 100%. >> >> Finally, I'd love for there to be a way to save a package locally >> in a way allowing it to be moved to another machine and installed >> via PM there. Perhaps I can just sync the site-packages >> directories on both machines, but I don't know if some of the >> packages have other side effects. Is this feasible? Ideally >> I'd like to grab the packages on my G3 at work, and install them >> on my G4 at home. I suppose I could do it directly with distutils, >> but it would be neat if PM could do this. From janssen at parc.com Thu Oct 30 19:54:30 2003 From: janssen at parc.com (Bill Janssen) Date: Thu Oct 30 19:54:52 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 16:41:42 PST." Message-ID: <03Oct30.165434pst."58611"@synergy1.parc.xerox.com> Thanks. I'm thinking there are 3 possibilities: 1) The setup.py file for PIL isn't following the Python guidelines for such files (where are those guidelines, do you know?). 2) The Python guidelines for setup.py files are broken. 3) The /usr/bin/python on Panther is just broken (which would be too bad). Bill From bob at redivi.com Thu Oct 30 20:26:15 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 30 20:26:47 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.165434pst."58611"@synergy1.parc.xerox.com> References: <03Oct30.165434pst."58611"@synergy1.parc.xerox.com> Message-ID: <384EFF86-0B41-11D8-8AA8-000A95686CD8@redivi.com> On Oct 30, 2003, at 7:54 PM, Bill Janssen wrote: > Thanks. > > I'm thinking there are 3 possibilities: > > 1) The setup.py file for PIL isn't following the Python guidelines for > such files (where are those guidelines, do you know?). > > 2) The Python guidelines for setup.py files are broken. > > 3) The /usr/bin/python on Panther is just broken (which would be too > bad). 4) You have some other installation of PIL in your sys.path that it's finding? PIL works just fine in Panther with the version of Python included with 10.3. Did you tweak your PYTHONPATH for some reason? Do you have old 2.2 modules lying around? You won't get a version mismatch for anything built for Python 2.3. Modules that were built for MacPython 2.3 on Jaguar work just fine on the Panther installation of Python 2.3, barring other issues. This one is definitely your fault, I don't know what you did, but this isn't reproducible and it's basically impossible to compile a version mismatched Python module with a stock Panther+Xcode system (i.e. one with no other . -bob From bob at redivi.com Thu Oct 30 21:57:46 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 30 21:58:10 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.184644pst."58611"@synergy1.parc.xerox.com> References: <03Oct30.184644pst."58611"@synergy1.parc.xerox.com> Message-ID: <01220553-0B4E-11D8-8AA8-000A95686CD8@redivi.com> On Oct 30, 2003, at 9:46 PM, Bill Janssen wrote: > I'm glad to hear it can be compiled, but *I* still can't do it. I've > re-built Python from scratch in a different directory and re-installed > PIL, with the same results. I'm building with the new gcc 3.3 from > Xcode. > > PYTHONPATH is empty. Here's a script, you tell me what I'm doing > wrong. Do you have any kind of non default settings? UFS, NFS, etc. homedir? Have you tried turning off Fink? Is there an _imaging.so anywhere on your computer? Are you using OS X 10.3/Xcode 7B85? Can you compile/run other modules? What's wrong with the PIL that's in Jack's PackageManager, or mine? Both of them should work, though you may have to move them to the right place post-install. -bob From chris at cogdon.org Thu Oct 30 22:16:05 2003 From: chris at cogdon.org (Chris Cogdon) Date: Thu Oct 30 22:16:15 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.184644pst."58611"@synergy1.parc.xerox.com> References: <03Oct30.184644pst."58611"@synergy1.parc.xerox.com> Message-ID: <90A0C719-0B50-11D8-B114-000A95E3823E@cogdon.org> On Oct 30, 2003, at 18:46, Bill Janssen wrote: >> This one is definitely your fault, I don't know what you did, but this >> isn't reproducible and it's basically impossible to compile a version >> mismatched Python module with a stock Panther+Xcode system (i.e. one >> with no other . > > Bob, I'm not trying pick a fight, I'm just trying to figure out what's > wrong and fix it. There's at least one bug in PIL's setup.py file, but > I don't think that's the problem. > > I'm glad to hear it can be compiled, but *I* still can't do it. I've > re-built Python from scratch in a different directory and re-installed > PIL, with the same results. I'm building with the new gcc 3.3 from > Xcode. I think Bob is saying that there might be an 'old PIL' kicking around that python is picking up. I think it's doubtful, given the sys.path you've showed us. But... doubtful = still possible. Try this: [chris@onca chris]$ python2 Python 2.2.2 (#1, Nov 19 2002, 11:24:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module ( 'Image' ) (, '/usr/lib/python2.2/site-packages/PIL/Image.py', ('.py', 'r', 1)) This isn't on my Mac, obviously, but the result of find_module might tell us something. Bob... can you try the above, too ? -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From janssen at parc.com Thu Oct 30 22:34:02 2003 From: janssen at parc.com (Bill Janssen) Date: Thu Oct 30 22:34:31 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 18:57:46 PST." <01220553-0B4E-11D8-8AA8-000A95686CD8@redivi.com> Message-ID: <03Oct30.193407pst."58611"@synergy1.parc.xerox.com> > Do you have any kind of non default settings? UFS, NFS, etc. homedir? I'm not sure what a setting is, much less what the default ones are. My homedir is on an NFS-mounted UFS partition, though. Never bothered me with Jaguar. > Have you tried turning off Fink? Not sure what you mean -- fink has no active processes on this machine. And /sw isn't on my path or sys.path anywhere. > Is there an _imaging.so anywhere on your computer? Yes, several. But only one on the sys.path for /usr/bin/python. That's the one I built (and re-built, and re-built, and ...) from source. Don't blame these unless you can tell me why Python is finding them instead of the "right" one. /Library/Python/2.3/PIL/_imaging.so /private/tmp/Imaging-1.1.4/build/lib.darwin-7.0.0-Power_Macintosh-2.3/_imaging.so /sw/lib/python2.3/site-packages/PIL/_imaging.so /Temporary Items/Imaging-1.1.3/build/lib.darwin-6.6-Power Macintosh-2.2/_imaging.so /Temporary Items/Imaging-1.1.4/build/lib.darwin-7.0.0-Power_Macintosh-2.3/_imaging.so /usr/lib/python2.2/site-packages/PIL/_imaging.so /usr/local/lib/python2.3/site-packages/PIL/_imaging.so > Are you using OS X 10.3/Xcode 7B85? Yes. > Can you compile/run other modules? Well, the only other one I've tried is Medusa, but that's Python-only. Can you suggest a candidate? > What's wrong with the PIL that's in Jack's PackageManager, or mine? > Both of them should work, though you may have to move them to the right > place post-install. I'm working with a secure application, and need to build from source -- internal guidelines. Hmmm, that gives me the bright idea of trying "python -v". What's FixTk? Bill % python -v # installing zipimport hook import zipimport # builtin # installed zipimport hook # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site.py import site # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/os.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/os.py import os # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/os.pyc import posix # builtin # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.py import posixpath # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/posixpath.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/stat.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/stat.py import stat # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/stat.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/UserDict.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/UserDict.py import UserDict # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/UserDict.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.py import copy_reg # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/copy_reg.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/types.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/types.py import types # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/types.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/warnings.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/warnings.py import warnings # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/warnings.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/linecache.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/linecache.py import linecache # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/linecache.pyc 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 Image # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/Image.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/Image.py import Image # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/Image.pyc # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/FixTk.pyc matches /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/FixTk.py import FixTk # precompiled from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/FixTk.pyc Fatal Python error: Interpreter not initialized (version mismatch?) Abort % Bill From janssen at parc.com Thu Oct 30 22:37:05 2003 From: janssen at parc.com (Bill Janssen) Date: Thu Oct 30 22:37:31 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 19:16:05 PST." <90A0C719-0B50-11D8-B114-000A95E3823E@cogdon.org> Message-ID: <03Oct30.193708pst."58611"@synergy1.parc.xerox.com> Here's mine: % /usr/bin/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 imp >>> imp.find_module('Image') (, '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/Image.py', ('.py', 'U', 1)) >>> I'm beginning to suspect FixTk, though. Unfortunately, I can "import FixTk" with no errors. Bill From bob at redivi.com Thu Oct 30 22:44:48 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 30 22:45:47 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.193407pst."58611"@synergy1.parc.xerox.com> References: <03Oct30.193407pst."58611"@synergy1.parc.xerox.com> Message-ID: <9315DADA-0B54-11D8-8AA8-000A95686CD8@redivi.com> On Oct 30, 2003, at 10:34 PM, Bill Janssen wrote: >> Have you tried turning off Fink? > > Not sure what you mean -- fink has no active processes on this > machine. And /sw isn't on my path or sys.path anywhere. I mean not run the shell script that sets up the fink environment variables. -bob From chris at cogdon.org Thu Oct 30 22:46:54 2003 From: chris at cogdon.org (Chris Cogdon) Date: Thu Oct 30 22:47:00 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.193708pst."58611"@synergy1.parc.xerox.com> References: <03Oct30.193708pst."58611"@synergy1.parc.xerox.com> Message-ID: On Oct 30, 2003, at 19:37, Bill Janssen wrote: > Here's mine: > > % /usr/bin/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 imp >>>> imp.find_module('Image') > ( '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PIL/Image.py', mode 'U' at 0x603e0>, > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PIL/Image.py', ('.py', 'U', 1)) >>>> > > I'm beginning to suspect FixTk, though. Unfortunately, I can "import > FixTk" with no errors. The '-v' option gave more complete results... thanks for the tip. Yes, I was just about to say 'aha, it's FixTk' that's the problem. But, you thought of that, too, and ruled it out. Dammit. Can you give me an easy problem, please? :) -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From janssen at parc.com Thu Oct 30 22:56:58 2003 From: janssen at parc.com (Bill Janssen) Date: Thu Oct 30 22:57:30 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 19:44:48 PST." <9315DADA-0B54-11D8-8AA8-000A95686CD8@redivi.com> Message-ID: <03Oct30.195708pst."58611"@synergy1.parc.xerox.com> > I mean not run the shell script that sets up the fink environment > variables. Just tried this with a clean build: no help. Bill From bob at redivi.com Thu Oct 30 23:01:58 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 30 23:02:22 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.195708pst."58611"@synergy1.parc.xerox.com> References: <03Oct30.195708pst."58611"@synergy1.parc.xerox.com> Message-ID: On Oct 30, 2003, at 10:56 PM, Bill Janssen wrote: >> I mean not run the shell script that sets up the fink environment >> variables. > > Just tried this with a clean build: no help. try this: >>> import imp >>> imp.find_module('_imaging') (, '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/PIL/_imaging.so', ('.so', 'rb', 3)) >>> import _imaging From halloleo at myrealbox.com Thu Oct 30 23:03:29 2003 From: halloleo at myrealbox.com (leo) Date: Thu Oct 30 23:04:17 2003 Subject: [Pythonmac-SIG] gui toolkit for python on os x: is wxPython the winner? and how do i install it? References: <03Oct30.165434pst."58611"@synergy1.parc.xerox.com> <384EFF86-0B41-11D8-8AA8-000A95686CD8@redivi.com> Message-ID: <07d201c39f64$1add69d0$a800000a@Odyssey.local> hi there on my mac i want to built small to medium GUI apps with python: i) what's the best toolkit: tkinter, wxPython or what? stability, ease of use and runtime portability between mac and windows are the main criteria. ii) i asked this question in comp.lang.python before and it looked like wxPython is the generally recommendation. but does wxPython works on os x? and where do i get the wxWindows lib for macs? thanks, leo From halloleo at myrealbox.com Thu Oct 30 23:07:10 2003 From: halloleo at myrealbox.com (leo) Date: Thu Oct 30 23:06:48 2003 Subject: [Pythonmac-SIG] wxPython the perfect GUI toolkit on mac os x? References: <6C9894B8-0B3B-11D8-BE87-00306575F888@brandeis.edu> Message-ID: <07dc01c39f64$75ca3d00$a800000a@Odyssey.local> hi there on my mac i want to built small to medium GUI apps with python: i) what's the best toolkit: tkinter, wxPython or what? stability, ease of use and runtime portability between mac and windows are the main criteria. ii) i asked this question in comp.lang.python before and it looked like wxPython is the generally recommendation. but does wxPython works on os x? and where do i get the wxWindows lib for macs? thanks, leo From janssen at parc.com Thu Oct 30 23:22:17 2003 From: janssen at parc.com (Bill Janssen) Date: Thu Oct 30 23:22:38 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 20:01:58 PST." Message-ID: <03Oct30.202218pst."58611"@synergy1.parc.xerox.com> About what I'd expect: % 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 imp >>> imp.find_module('Image') (, '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/Image.py', ('.py', 'U', 1)) >>> imp.find_module('_imaging') (, '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/_imaging.so', ('.so', 'rb', 3)) >>> import _imaging Fatal Python error: Interpreter not initialized (version mismatch?) Abort % From janssen at parc.com Thu Oct 30 23:24:26 2003 From: janssen at parc.com (Bill Janssen) Date: Thu Oct 30 23:24:59 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 20:01:58 PST." Message-ID: <03Oct30.202433pst."58611"@synergy1.parc.xerox.com> Fink has a patch for PIL 1.1.4, which fixes the setup.py problem. I applied it and re-built, but have the same problem. I wonder if this is a gcc problem; the version I built (python 2.3, PIL 1.1.4) with gcc 2.95.x under Jaguar still works. Bill From bob at redivi.com Thu Oct 30 23:27:29 2003 From: bob at redivi.com (Bob Ippolito) Date: Thu Oct 30 23:27:55 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.202218pst."58611"@synergy1.parc.xerox.com> References: <03Oct30.202218pst."58611"@synergy1.parc.xerox.com> Message-ID: <89EC623E-0B5A-11D8-8AA8-000A95686CD8@redivi.com> On Oct 30, 2003, at 11:22 PM, Bill Janssen wrote: > About what I'd expect: > > % 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 imp >>>> imp.find_module('Image') > ( '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PIL/Image.py', mode 'U' at 0x60460>, > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PIL/Image.py', ('.py', 'U', 1)) >>>> imp.find_module('_imaging') > ( '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PIL/_imaging.so', mode 'rb' at 0x605e0>, > '/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/PIL/_imaging.so', ('.so', 'rb', 3)) >>>> import _imaging > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > % what's the output of: otool -Lv /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages/PIL/_imaging.so From janssen at parc.com Thu Oct 30 23:51:17 2003 From: janssen at parc.com (Bill Janssen) Date: Thu Oct 30 23:51:55 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 20:27:29 PST." <89EC623E-0B5A-11D8-8AA8-000A95686CD8@redivi.com> Message-ID: <03Oct30.205124pst."58611"@synergy1.parc.xerox.com> % otool -Lv /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/_imaging.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/_imaging.so: Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) time stamp 1067389093 Tue Oct 28 16:58:13 2003 /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.0.0) time stamp 1064385339 Tue Sep 23 23:35:39 2003 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0) time stamp 1064354548 Tue Sep 23 15:02:28 2003 % From gherman at darwin.in-berlin.de Fri Oct 31 02:58:32 2003 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Fri Oct 31 02:58:17 2003 Subject: [Pythonmac-SIG] ANN: emkey 0.2 - a simple post-processing tool for Keynote documents Message-ID: <05D63686-0B78-11D8-BD19-00039345C610@darwin.in-berlin.de> Hi, I've released emkey 0.2, a simple post-processing tool for Keynote documents. As of now it might be particularly useful for people using Python code on Keynote slides, but it's easy to imagine additional features. Please see the full Readme for this first release below. Regards, Dinu emkey ===== Summary ------- emkey is an EmPy-based post-processing tool for Apple Keynote documents. Overview -------- emkey is a simple command-line tool for post-processing Apple Keynote documents. It currently imports external text snippets on single slides and can apply syntax color highlighting to them if these are Python source code. Basics ------ emkey works on the APXL [1]_ presentation file of a Keynote [2]_ document. Before using it you create a normal Keynote presentation document. EmPy [3]_ tags like ``@load("fibo.py", colored=1)`` on a slide will then be expanded during post-processing by emkey with the content of the respective file, with syntax highlighting for Python code if desired. The tool makes one backup of the APXL file before modifying it, and allows to revert to this backup after post-processing. History ------- :0.2: first release Requirements ------------ There are no special requirements for running emkey, except a Python interpreter 2.x [4]_, EmPy 3.x (3.3 included), copyrighted by Erik Max Francis and PyFontify (0.5 included), copyrighted by Just van Rossum. Licence ------- emkey is released under the GPL - see the included file, "GPL.txt". The included EmPy and PyFontify modules are licensed under the LGPL and the Python License, respectively. Download -------- The emkey distribution, including one Keynote sample document is available from: http://python.net/~gherman/emkey.html Notes ------ Thanks to Erik Max Francis and Just van Rossum who have kindly allowed to include EmPy and PyFontify respectively into the emkey distribution. Note, that there is no installation procedure by which you might risk to overwrite an existing EmPy or PyFontify. **Be careful when using emkey on Keynote documents! Remember to revert to the original version before re-editing the document with Keynote, again!** Future ------ In principle one could extend this tool to provide further kinds of post-processing capabilities on Keynote files, which, of course, needs intimate knowledge of the APXL files. Links ----- .. [1] http://developer.apple.com/technotes/tn2002/tn2067.html .. [2] http://www.apple.com/keynote .. [3] http://www.alcyone.com/software/empy .. [4] http://www.python.org Author ------ Dinu Gherman, http://python.net/~gherman/Contact.html, 2003-10-31 From janssen at parc.com Thu Oct 30 21:46:34 2003 From: janssen at parc.com (Bill Janssen) Date: Fri Oct 31 05:26:39 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Thu, 30 Oct 2003 17:26:15 PST." <384EFF86-0B41-11D8-8AA8-000A95686CD8@redivi.com> Message-ID: <03Oct30.184644pst."58611"@synergy1.parc.xerox.com> > This one is definitely your fault, I don't know what you did, but this > isn't reproducible and it's basically impossible to compile a version > mismatched Python module with a stock Panther+Xcode system (i.e. one > with no other . Bob, I'm not trying pick a fight, I'm just trying to figure out what's wrong and fix it. There's at least one bug in PIL's setup.py file, but I don't think that's the problem. I'm glad to hear it can be compiled, but *I* still can't do it. I've re-built Python from scratch in a different directory and re-installed PIL, with the same results. I'm building with the new gcc 3.3 from Xcode. PYTHONPATH is empty. Here's a script, you tell me what I'm doing wrong. Bill % tar xvfz /Temporary\ Items/Imaging-1.1.4.tar.gz Imaging-1.1.4/README Imaging-1.1.4/CHANGES-114 Imaging-1.1.4/CONTENTS Imaging-1.1.4/BUILDME Imaging-1.1.4/setup.py Imaging-1.1.4/Setup.in Imaging-1.1.4/Makefile.pre.in Imaging-1.1.4/selftest.py Imaging-1.1.4/doctest.py Imaging-1.1.4/libImaging/Makefile.win Imaging-1.1.4/libImaging/ImConfig.h.win Imaging-1.1.4/libImaging/Imaging.h Imaging-1.1.4/libImaging/ImDib.h Imaging-1.1.4/libImaging/ImPlatform.h Imaging-1.1.4/libImaging/Quant.h Imaging-1.1.4/libImaging/QuantHash.h Imaging-1.1.4/libImaging/QuantHeap.h Imaging-1.1.4/libImaging/QuantDefines.h Imaging-1.1.4/libImaging/QuantTypes.h Imaging-1.1.4/libImaging/Access.c Imaging-1.1.4/libImaging/Antialias.c Imaging-1.1.4/libImaging/Bands.c Imaging-1.1.4/libImaging/Blend.c Imaging-1.1.4/libImaging/Chops.c Imaging-1.1.4/libImaging/Convert.c Imaging-1.1.4/libImaging/ConvertYCbCr.c Imaging-1.1.4/libImaging/Copy.c Imaging-1.1.4/libImaging/Crc32.c Imaging-1.1.4/libImaging/Crop.c Imaging-1.1.4/libImaging/Dib.c Imaging-1.1.4/libImaging/Draw.c Imaging-1.1.4/libImaging/Effects.c Imaging-1.1.4/libImaging/Except.c Imaging-1.1.4/libImaging/File.c Imaging-1.1.4/libImaging/Fill.c Imaging-1.1.4/libImaging/Filter.c Imaging-1.1.4/libImaging/Geometry.c Imaging-1.1.4/libImaging/GetBBox.c Imaging-1.1.4/libImaging/Histo.c Imaging-1.1.4/libImaging/Matrix.c Imaging-1.1.4/libImaging/Negative.c Imaging-1.1.4/libImaging/Offset.c Imaging-1.1.4/libImaging/Pack.c Imaging-1.1.4/libImaging/Palette.c Imaging-1.1.4/libImaging/Paste.c Imaging-1.1.4/libImaging/Point.c Imaging-1.1.4/libImaging/Quant.c Imaging-1.1.4/libImaging/QuantHash.c Imaging-1.1.4/libImaging/QuantHeap.c Imaging-1.1.4/libImaging/RankFilter.c Imaging-1.1.4/libImaging/Storage.c Imaging-1.1.4/libImaging/Unpack.c Imaging-1.1.4/libImaging/UnpackYCC.c Imaging-1.1.4/libImaging/Bit.h Imaging-1.1.4/libImaging/Gif.h Imaging-1.1.4/libImaging/Jpeg.h Imaging-1.1.4/libImaging/Lzw.h Imaging-1.1.4/libImaging/Raw.h Imaging-1.1.4/libImaging/Zip.h Imaging-1.1.4/libImaging/BitDecode.c Imaging-1.1.4/libImaging/EpsEncode.c Imaging-1.1.4/libImaging/FliDecode.c Imaging-1.1.4/libImaging/GifDecode.c Imaging-1.1.4/libImaging/GifEncode.c Imaging-1.1.4/libImaging/HexDecode.c Imaging-1.1.4/libImaging/JpegDecode.c Imaging-1.1.4/libImaging/JpegEncode.c Imaging-1.1.4/libImaging/LzwDecode.c Imaging-1.1.4/libImaging/MspDecode.c Imaging-1.1.4/libImaging/PackDecode.c Imaging-1.1.4/libImaging/PcdDecode.c Imaging-1.1.4/libImaging/PcxEncode.c Imaging-1.1.4/libImaging/PcxDecode.c Imaging-1.1.4/libImaging/RawDecode.c Imaging-1.1.4/libImaging/RawEncode.c Imaging-1.1.4/libImaging/SunRleDecode.c Imaging-1.1.4/libImaging/TgaRleDecode.c Imaging-1.1.4/libImaging/XbmDecode.c Imaging-1.1.4/libImaging/XbmEncode.c Imaging-1.1.4/libImaging/ZipDecode.c Imaging-1.1.4/libImaging/ZipEncode.c Imaging-1.1.4/libImaging/coretest.c Imaging-1.1.4/libImaging/configure Imaging-1.1.4/libImaging/ImConfig.h.in Imaging-1.1.4/libImaging/Makefile.in Imaging-1.1.4/_imaging.c Imaging-1.1.4/decode.c Imaging-1.1.4/encode.c Imaging-1.1.4/display.c Imaging-1.1.4/map.c Imaging-1.1.4/outline.c Imaging-1.1.4/path.c Imaging-1.1.4/_imagingtk.c Imaging-1.1.4/_imagingft.c Imaging-1.1.4/PIL.pth Imaging-1.1.4/PIL/__init__.py Imaging-1.1.4/PIL/ArgImagePlugin.py Imaging-1.1.4/PIL/BdfFontFile.py Imaging-1.1.4/PIL/BmpImagePlugin.py Imaging-1.1.4/PIL/ContainerIO.py Imaging-1.1.4/PIL/CurImagePlugin.py Imaging-1.1.4/PIL/DcxImagePlugin.py Imaging-1.1.4/PIL/EpsImagePlugin.py Imaging-1.1.4/PIL/ExifTags.py Imaging-1.1.4/PIL/FliImagePlugin.py Imaging-1.1.4/PIL/FontFile.py Imaging-1.1.4/PIL/FpxImagePlugin.py Imaging-1.1.4/PIL/GbrImagePlugin.py Imaging-1.1.4/PIL/GdImageFile.py Imaging-1.1.4/PIL/GifImagePlugin.py Imaging-1.1.4/PIL/GimpGradientFile.py Imaging-1.1.4/PIL/GimpPaletteFile.py Imaging-1.1.4/PIL/IcoImagePlugin.py Imaging-1.1.4/PIL/Image.py Imaging-1.1.4/PIL/ImageChops.py Imaging-1.1.4/PIL/ImageColor.py Imaging-1.1.4/PIL/ImageDraw.py Imaging-1.1.4/PIL/ImageEnhance.py Imaging-1.1.4/PIL/ImageFile.py Imaging-1.1.4/PIL/ImageFileIO.py Imaging-1.1.4/PIL/ImageFilter.py Imaging-1.1.4/PIL/ImageFont.py Imaging-1.1.4/PIL/ImageGrab.py Imaging-1.1.4/PIL/ImageOps.py Imaging-1.1.4/PIL/ImagePalette.py Imaging-1.1.4/PIL/ImagePath.py Imaging-1.1.4/PIL/ImageSequence.py Imaging-1.1.4/PIL/ImageStat.py Imaging-1.1.4/PIL/ImageTk.py Imaging-1.1.4/PIL/ImageTransform.py Imaging-1.1.4/PIL/ImageWin.py Imaging-1.1.4/PIL/ImImagePlugin.py Imaging-1.1.4/PIL/ImtImagePlugin.py Imaging-1.1.4/PIL/IptcImagePlugin.py Imaging-1.1.4/PIL/JpegImagePlugin.py Imaging-1.1.4/PIL/McIdasImagePlugin.py Imaging-1.1.4/PIL/MicImagePlugin.py Imaging-1.1.4/PIL/MpegImagePlugin.py Imaging-1.1.4/PIL/MspImagePlugin.py Imaging-1.1.4/PIL/OleFileIO.py Imaging-1.1.4/PIL/PaletteFile.py Imaging-1.1.4/PIL/PalmImagePlugin.py Imaging-1.1.4/PIL/PcdImagePlugin.py Imaging-1.1.4/PIL/PcfFontFile.py Imaging-1.1.4/PIL/PcxImagePlugin.py Imaging-1.1.4/PIL/PdfImagePlugin.py Imaging-1.1.4/PIL/PixarImagePlugin.py Imaging-1.1.4/PIL/PngImagePlugin.py Imaging-1.1.4/PIL/PpmImagePlugin.py Imaging-1.1.4/PIL/PsdImagePlugin.py Imaging-1.1.4/PIL/PSDraw.py Imaging-1.1.4/PIL/SgiImagePlugin.py Imaging-1.1.4/PIL/SunImagePlugin.py Imaging-1.1.4/PIL/TarIO.py Imaging-1.1.4/PIL/TgaImagePlugin.py Imaging-1.1.4/PIL/TiffImagePlugin.py Imaging-1.1.4/PIL/TiffTags.py Imaging-1.1.4/PIL/WalImageFile.py Imaging-1.1.4/PIL/WmfImagePlugin.py Imaging-1.1.4/PIL/XbmImagePlugin.py Imaging-1.1.4/PIL/XpmImagePlugin.py Imaging-1.1.4/PIL/XVThumbImagePlugin.py Imaging-1.1.4/Doc/index.html Imaging-1.1.4/Doc/PIL.ArgImagePlugin.html Imaging-1.1.4/Doc/PIL.BdfFontFile.html Imaging-1.1.4/Doc/PIL.BmpImagePlugin.html Imaging-1.1.4/Doc/PIL.ContainerIO.html Imaging-1.1.4/Doc/PIL.CurImagePlugin.html Imaging-1.1.4/Doc/PIL.DcxImagePlugin.html Imaging-1.1.4/Doc/PIL.EpsImagePlugin.html Imaging-1.1.4/Doc/PIL.FliImagePlugin.html Imaging-1.1.4/Doc/PIL.FontFile.html Imaging-1.1.4/Doc/PIL.FpxImagePlugin.html Imaging-1.1.4/Doc/PIL.GbrImagePlugin.html Imaging-1.1.4/Doc/PIL.GdImageFile.html Imaging-1.1.4/Doc/PIL.GifImagePlugin.html Imaging-1.1.4/Doc/PIL.GimpGradientFile.html Imaging-1.1.4/Doc/PIL.GimpPaletteFile.html Imaging-1.1.4/Doc/PIL.IcoImagePlugin.html Imaging-1.1.4/Doc/PIL.ImageChops.html Imaging-1.1.4/Doc/PIL.ImageColor.html Imaging-1.1.4/Doc/PIL.ImageDraw.html Imaging-1.1.4/Doc/PIL.ImageEnhance.html Imaging-1.1.4/Doc/PIL.ImageFile.html Imaging-1.1.4/Doc/PIL.ImageFileIO.html Imaging-1.1.4/Doc/PIL.ImageFilter.html Imaging-1.1.4/Doc/PIL.ImageFont.html Imaging-1.1.4/Doc/PIL.ImageGrab.html Imaging-1.1.4/Doc/PIL.Image.html Imaging-1.1.4/Doc/PIL.ImageOps.html Imaging-1.1.4/Doc/PIL.ImageSequence.html Imaging-1.1.4/Doc/PIL.ImageStat.html Imaging-1.1.4/Doc/PIL.ImageTk.html Imaging-1.1.4/Doc/PIL.ImageTransform.html Imaging-1.1.4/Doc/PIL.ImageWin.html Imaging-1.1.4/Doc/PIL.ImImagePlugin.html Imaging-1.1.4/Doc/PIL.ImtImagePlugin.html Imaging-1.1.4/Doc/PIL.IptcImagePlugin.html Imaging-1.1.4/Doc/PIL.JpegImagePlugin.html Imaging-1.1.4/Doc/PIL.McIdasImagePlugin.html Imaging-1.1.4/Doc/PIL.MicImagePlugin.html Imaging-1.1.4/Doc/PIL.MpegImagePlugin.html Imaging-1.1.4/Doc/PIL.MspImagePlugin.html Imaging-1.1.4/Doc/PIL.PaletteFile.html Imaging-1.1.4/Doc/PIL.PcdImagePlugin.html Imaging-1.1.4/Doc/PIL.PcfFontFile.html Imaging-1.1.4/Doc/PIL.PcxImagePlugin.html Imaging-1.1.4/Doc/PIL.PixarImagePlugin.html Imaging-1.1.4/Doc/PIL.PngImagePlugin.html Imaging-1.1.4/Doc/PIL.PpmImagePlugin.html Imaging-1.1.4/Doc/PIL.PsdImagePlugin.html Imaging-1.1.4/Doc/PIL.SgiImagePlugin.html Imaging-1.1.4/Doc/PIL.SunImagePlugin.html Imaging-1.1.4/Doc/PIL.TarIO.html Imaging-1.1.4/Doc/PIL.TgaImagePlugin.html Imaging-1.1.4/Doc/PIL.TiffImagePlugin.html Imaging-1.1.4/Doc/PIL.WalImageFile.html Imaging-1.1.4/Doc/PIL.WmfImagePlugin.html Imaging-1.1.4/Doc/PIL.XbmImagePlugin.html Imaging-1.1.4/Doc/PIL.XpmImagePlugin.html Imaging-1.1.4/Doc/PIL.XVThumbImagePlugin.html Imaging-1.1.4/Doc/pythondoc.css Imaging-1.1.4/Scripts/pilconvert.py Imaging-1.1.4/Scripts/pildriver.py Imaging-1.1.4/Scripts/pilfile.py Imaging-1.1.4/Scripts/pilfont.py Imaging-1.1.4/Scripts/pilprint.py Imaging-1.1.4/Images/lena.gif Imaging-1.1.4/Images/lena.ppm Imaging-1.1.4/Images/lena.jpg Imaging-1.1.4/Images/courB08.bdf Imaging-1.1.4/Images/courB08.pbm Imaging-1.1.4/Images/courB08.pil Imaging-1.1.4/Sane/README Imaging-1.1.4/Sane/sanedoc.txt Imaging-1.1.4/Sane/_sanemodule.c Imaging-1.1.4/Sane/sane.py Imaging-1.1.4/Sane/demo.py Imaging-1.1.4/Scripts/README Imaging-1.1.4/Scripts/bdf2pil.py Imaging-1.1.4/Scripts/enhancer.py Imaging-1.1.4/Scripts/explode.py Imaging-1.1.4/Scripts/gifmaker.py Imaging-1.1.4/Scripts/image2py.py Imaging-1.1.4/Scripts/painter.py Imaging-1.1.4/Scripts/player.py Imaging-1.1.4/Scripts/viewer.py Imaging-1.1.4/Scripts/thresholder.py Imaging-1.1.4/Tk/tkImaging.c Imaging-1.1.4/Tk/install.txt Imaging-1.1.4/Tk/booster.txt Imaging-1.1.4/Tk/pilbitmap.txt % cd Imaging-1.1.4/libImaging/ % ./configure creating cache ./config.cache checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for ranlib... ranlib checking for ar... ar checking MACHDEP... darwin7 checking for jpeg_destroy_compress in -ljpeg... no checking for deflate in -lz... yes checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for inline... inline checking whether byte ordering is bigendian... yes checking size of char... 1 checking size of short... 2 checking size of int... 4 checking size of long... 4 checking size of float... 4 checking size of double... 8 checking for working const... yes checking for prototypes... yes checking for unistd.h... yes checking for getpagesize... yes checking for working mmap... yes updating cache ./config.cache creating ./config.status creating Makefile creating ImConfig.h % make gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o coretest.o coretest.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Storage.o Storage.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Access.o Access.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Except.o Except.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Antialias.o Antialias.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Bands.o Bands.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Blend.o Blend.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Chops.o Chops.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Convert.o Convert.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o ConvertYCbCr.o ConvertYCbCr.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Copy.o Copy.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Crop.o Crop.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Crc32.o Crc32.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Dib.o Dib.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Draw.o Draw.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Effects.o Effects.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o File.o File.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Fill.o Fill.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Filter.o Filter.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Geometry.o Geometry.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o GetBBox.o GetBBox.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Histo.o Histo.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Matrix.o Matrix.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Negative.o Negative.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Offset.o Offset.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Pack.o Pack.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Palette.o Palette.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Paste.o Paste.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Point.o Point.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Quant.o Quant.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o QuantHash.o QuantHash.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o QuantHeap.o QuantHeap.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o RankFilter.o RankFilter.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o Unpack.o Unpack.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o UnpackYCC.o UnpackYCC.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o BitDecode.o BitDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o EpsEncode.o EpsEncode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o FliDecode.o FliDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o GifDecode.o GifDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o GifEncode.o GifEncode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o HexDecode.o HexDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o JpegDecode.o JpegDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o JpegEncode.o JpegEncode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o LzwDecode.o LzwDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o MspDecode.o MspDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o PackDecode.o PackDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o PcdDecode.o PcdDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o PcxDecode.o PcxDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o PcxEncode.o PcxEncode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o RawDecode.o RawDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o RawEncode.o RawEncode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o SunRleDecode.o SunRleDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o TgaRleDecode.o TgaRleDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o XbmDecode.o XbmDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o XbmEncode.o XbmEncode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o ZipDecode.o ZipDecode.c gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c -o ZipEncode.o ZipEncode.c rm -f libImaging.a ar cr libImaging.a Storage.o Access.o Except.o Antialias.o Bands.o Blend.o Chops.o Convert.o ConvertYCbCr.o Copy.o Crop.o Crc32.o Dib.o Draw.o Effects.o File.o Fill.o Filter.o Geometry.o GetBBox.o Histo.o Matrix.o Negative.o Offset.o Pack.o Palette.o Paste.o Point.o Quant.o QuantHash.o QuantHeap.o RankFilter.o Unpack.o UnpackYCC.o BitDecode.o EpsEncode.o FliDecode.o GifDecode.o GifEncode.o HexDecode.o JpegDecode.o JpegEncode.o LzwDecode.o MspDecode.o PackDecode.o PcdDecode.o PcxDecode.o PcxEncode.o RawDecode.o RawEncode.o SunRleDecode.o TgaRleDecode.o XbmDecode.o XbmEncode.o ZipDecode.o ZipEncode.o ranlib libImaging.a ranlib: file: libImaging.a(Dib.o) has no symbols ranlib: file: libImaging.a(JpegDecode.o) has no symbols ranlib: file: libImaging.a(JpegEncode.o) has no symbols gcc -o coretest coretest.o libImaging.a -lz -lm % cd .. % which python /usr/bin/python % python setup.py build running build running build_py creating build creating build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/__init__.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ArgImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/BdfFontFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/BmpImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ContainerIO.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/CurImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/DcxImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/EpsImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ExifTags.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/FliImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/FontFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/FpxImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/GbrImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/GdImageFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/GifImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/GimpGradientFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/GimpPaletteFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/IcoImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/Image.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageChops.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageColor.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageDraw.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageEnhance.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageFileIO.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageFilter.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageFont.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageGrab.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageOps.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImagePalette.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImagePath.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageSequence.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageStat.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageTk.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageTransform.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImageWin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/ImtImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/IptcImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/JpegImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/McIdasImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/MicImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/MpegImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/MspImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/OleFileIO.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PaletteFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PalmImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PcdImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PcfFontFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PcxImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PdfImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PixarImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PngImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PpmImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PsdImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/PSDraw.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/SgiImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/SunImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/TarIO.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/TgaImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/TiffImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/TiffTags.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/WalImageFile.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/WmfImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/XbmImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/XpmImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 copying PIL/XVThumbImagePlugin.py -> build/lib.darwin-7.0.0-Power_Macintosh-2.3 running build_ext building '_imaging' extension creating build/temp.darwin-7.0.0-Power_Macintosh-2.3 gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c decode.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/decode.o gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c encode.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/encode.o gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c _imaging.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/_imaging.o gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c outline.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/outline.o gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c path.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/path.o gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c display.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/display.o gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c map.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/map.o gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.0.0-Power_Macintosh-2.3/_imaging.o build/temp.darwin-7.0.0-Power_Macintosh-2.3/decode.o build/temp.darwin-7.0.0-Power_Macintosh-2.3/encode.o build/temp.darwin-7.0.0-Power_Macintosh-2.3/map.o build/temp.darwin-7.0.0-Power_Macintosh-2.3/display.o build/temp.darwin-7.0.0-Power_Macintosh-2.3/outline.o build/temp.darwin-7.0.0-Power_Macintosh-2.3/path.o -LlibImaging -L/sw/lib -lImaging -lz -o build/lib.darwin-7.0.0-Power_Macintosh-2.3/_imaging.so building '_imagingft' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -IlibImaging -I/sw/include/freetype2 -I/System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c _imagingft.c -o build/temp.darwin-7.0.0-Power_Macintosh-2.3/_imagingft.o gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.0.0-Power_Macintosh-2.3/_imagingft.o -L/sw/lib -lfreetype -o build/lib.darwin-7.0.0-Power_Macintosh-2.3/_imagingft.so % printenv PATH /bin:/usr/bin:/usr/ucb:/usr/lib:/etc:/usr/etc:/sbin:/local/emacs-21.4alpha/bin:/usr/X11R6/bin % /usr/bin/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 Image Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Image >>> % which python /usr/bin/python % python setup.py install running install running build running build_py running build_ext running install_lib creating /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/__init__.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/_imaging.so -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/_imagingft.so -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ArgImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/BdfFontFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/BmpImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ContainerIO.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/CurImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/DcxImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/EpsImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ExifTags.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/FliImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/FontFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/FpxImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/GbrImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/GdImageFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/GifImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/GimpGradientFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/GimpPaletteFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/IcoImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/Image.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageChops.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageColor.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageDraw.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageEnhance.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageFileIO.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageFilter.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageFont.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageGrab.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageOps.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImagePalette.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImagePath.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageSequence.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageStat.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageTk.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageTransform.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImageWin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/ImtImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/IptcImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/JpegImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/McIdasImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/MicImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/MpegImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/MspImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/OleFileIO.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PaletteFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PalmImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PcdImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PcfFontFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PcxImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PdfImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PixarImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PngImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PpmImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PsdImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/PSDraw.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/SgiImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/SunImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/TarIO.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/TgaImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/TiffImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/TiffTags.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/WalImageFile.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/WmfImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/XbmImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/XpmImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-7.0.0-Power_Macintosh-2.3/XVThumbImagePlugin.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/__init__.py to __init__.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ArgImagePlugin.py to ArgImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/BdfFontFile.py to BdfFontFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/BmpImagePlugin.py to BmpImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ContainerIO.py to ContainerIO.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/CurImagePlugin.py to CurImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/DcxImagePlugin.py to DcxImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/EpsImagePlugin.py to EpsImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ExifTags.py to ExifTags.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/FliImagePlugin.py to FliImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/FontFile.py to FontFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/FpxImagePlugin.py to FpxImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/GbrImagePlugin.py to GbrImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/GdImageFile.py to GdImageFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/GifImagePlugin.py to GifImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/GimpGradientFile.py to GimpGradientFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/GimpPaletteFile.py to GimpPaletteFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/IcoImagePlugin.py to IcoImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/Image.py to Image.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageChops.py to ImageChops.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageColor.py to ImageColor.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageDraw.py to ImageDraw.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageEnhance.py to ImageEnhance.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageFile.py to ImageFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageFileIO.py to ImageFileIO.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageFilter.py to ImageFilter.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageFont.py to ImageFont.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageGrab.py to ImageGrab.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageOps.py to ImageOps.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImagePalette.py to ImagePalette.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImagePath.py to ImagePath.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageSequence.py to ImageSequence.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageStat.py to ImageStat.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageTk.py to ImageTk.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageTransform.py to ImageTransform.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImageWin.py to ImageWin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImImagePlugin.py to ImImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/ImtImagePlugin.py to ImtImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/IptcImagePlugin.py to IptcImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/JpegImagePlugin.py to JpegImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/McIdasImagePlugin.py to McIdasImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/MicImagePlugin.py to MicImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/MpegImagePlugin.py to MpegImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/MspImagePlugin.py to MspImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/OleFileIO.py to OleFileIO.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PaletteFile.py to PaletteFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PalmImagePlugin.py to PalmImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PcdImagePlugin.py to PcdImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PcfFontFile.py to PcfFontFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PcxImagePlugin.py to PcxImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PdfImagePlugin.py to PdfImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PixarImagePlugin.py to PixarImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PngImagePlugin.py to PngImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PpmImagePlugin.py to PpmImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PsdImagePlugin.py to PsdImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/PSDraw.py to PSDraw.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/SgiImagePlugin.py to SgiImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/SunImagePlugin.py to SunImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/TarIO.py to TarIO.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/TgaImagePlugin.py to TgaImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/TiffImagePlugin.py to TiffImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/TiffTags.py to TiffTags.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/WalImageFile.py to WalImageFile.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/WmfImagePlugin.py to WmfImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/XbmImagePlugin.py to XbmImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/XpmImagePlugin.py to XpmImagePlugin.pyc byte-compiling /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL/XVThumbImagePlugin.py to XVThumbImagePlugin.pyc creating /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL.pth % printenv PYTHONPATH % which python /usr/bin/python % 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/PIL'] >>> import Image Fatal Python error: Interpreter not initialized (version mismatch?) Abort % From aparente at adobe.com Fri Oct 31 12:44:01 2003 From: aparente at adobe.com (Alexandre Parenteau) Date: Fri Oct 31 12:44:17 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct30.184644pst.58611@synergy1.parc.xerox.com> Message-ID: > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort Sorry if I jump in a discussion I didn;t really follow, but I just wanted to say that I have this problem quite often when somehow I mix the /Library/Frameworks/Python with the /System/Library/Frameworks/Python on Panther (10.3). On Panther, Python comes installed as a Framework. So it is especially important for python modules to be compiled with the same framework it is going to be used against. You can try a 'otool -l module.so', it will tell you which frameworks was used. Alex. > % > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From rowen at cesmail.net Fri Oct 31 15:07:22 2003 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Oct 31 15:06:03 2003 Subject: [Pythonmac-SIG] Re: wxPython the perfect GUI toolkit on mac os x? References: <6C9894B8-0B3B-11D8-BE87-00306575F888@brandeis.edu> <07dc01c39f64$75ca3d00$a800000a@Odyssey.local> Message-ID: In article <07dc01c39f64$75ca3d00$a800000a@Odyssey.local>, "leo" wrote: > hi there > > on my mac i want to built small to medium GUI apps with python: > > i) what's the best toolkit: tkinter, wxPython or what? stability, ease of > use > > and runtime portability between mac and windows are the main criteria. > > ii) i asked this question in comp.lang.python before and it looked like > wxPython is the generally recommendation. but does wxPython works on os x? > and where do i get the wxWindows lib for macs? I've been using Tkinter. It's very easy to use, powerful and very flexible, but it's not perfect. In particular: - The aqua version of Tk has a number of minor cosmetic bugs; the X version is fine but results in a less Mac-like application -- especially the handling of menus and cut and paste (plus Apple's X11 has a few cosmetic bugs of its own, at least in the version that runs on Jaguar). - The defaults for the Windows version of Tk are apparently not very nice; you'll want to change them for a Windows-like appearance. - No multi-column-list widget (though PMW offers something in this line). When I looked at wxPython, I was unhappy with the extra complexity (for instance needing to specify magic integer constants to access menu items). Also, at the time it was lacking some things such as a powerful Canvas widget (though it has apparently has a nice multi-column list widget). That was awhile ago and maybe canvases are better now. Certainly I have read several reports from folks who switched from Tkinter to wxPython, and after the initial learning curve were quite glad they did. -- Russell From janssen at parc.com Fri Oct 31 16:07:33 2003 From: janssen at parc.com (Bill Janssen) Date: Fri Oct 31 16:07:59 2003 Subject: [Pythonmac-SIG] Re: [Image-SIG] PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Fri, 31 Oct 2003 09:44:01 PST." Message-ID: <03Oct31.130739pst."58611"@synergy1.parc.xerox.com> > Sorry if I jump in a discussion I didn;t really follow, but I just wanted to > say that I have this problem quite often when somehow I mix the > /Library/Frameworks/Python with the /System/Library/Frameworks/Python on > Panther (10.3). That does seem to somehow be the problem. What's the difference between the two, and can I just delete one of them? Bill From kevino at tulane.edu Fri Oct 31 18:14:16 2003 From: kevino at tulane.edu (Kevin Ollivier) Date: Fri Oct 31 18:31:39 2003 Subject: [Pythonmac-SIG] wxPython the perfect GUI toolkit on mac os x? In-Reply-To: <07dc01c39f64$75ca3d00$a800000a@Odyssey.local> References: <6C9894B8-0B3B-11D8-BE87-00306575F888@brandeis.edu> <07dc01c39f64$75ca3d00$a800000a@Odyssey.local> Message-ID: Hi Leo, On Oct 30, 2003, at 8:07 PM, leo wrote: > hi there > > on my mac i want to built small to medium GUI apps with python: > > i) what's the best toolkit: tkinter, wxPython or what? stability, ease > of > use > > and runtime portability between mac and windows are the main criteria. > > ii) i asked this question in comp.lang.python before and it looked like > wxPython is the generally recommendation. but does wxPython works on > os x? > and where do i get the wxWindows lib for macs? > As Russell pointed out, wxPython is a bit more complex and may require to you read through C++ docs, though they are some of the clearest and well-maintained C++ docs I've ever read. =) (Also, the new version in development plans on removing some of the current complexities, like IDs for event bindings, Python-specific docs, and maybe even Python-like property getting/setting) However, in my experience it is also the best tool out there for building cross-platform applications that have native look and feel. (If not the only toolkit to truly do so.) There are a large number of controls available that work on Windows, Mac and Linux. The wxWindows libs come with the wxPython installer package, available from wxPython.org. BTW, there is no wxPython installer yet for the version of Python included in Panther, but it will still work with Jack's Framework installer that is used for Jaguar. (We hope to have a wxPython installer for Panther's Python in a week or so, we didn't have pre-release copies of Panther so we couldn't prepare the package in advance!) Kevin From Jack.Jansen at cwi.nl Fri Oct 31 18:43:00 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 31 18:43:08 2003 Subject: [Pythonmac-SIG] upgrading to OS 10.3 In-Reply-To: <20031030180413.97675.qmail@web41106.mail.yahoo.com> References: <20031030180413.97675.qmail@web41106.mail.yahoo.com> Message-ID: On 30-okt-03, at 19:04, fat man wrote: > I'm a new mac user and currently have python installed > on my OS 10.2 machine. I will soon be upgrading to > 10.3 and was wondering if i might run into any > problems upgrading (as 10.3 'includes' most of > python). would it be necessary/best to remove python > before upgrading? if so, how would i go about doing > this (like i said i'm new to macs, i apologize if this > is a rather novice question). You don't have to delete it, the two live happily side-by-side, but it may be wiser to do so, so you don't get confused. I added uninstallation instructions to the MacPython website, could you please (a) try to find them, and (b) try to follow them, and report back what I did wrong? Thanks, -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen at cwi.nl Fri Oct 31 18:43:59 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Fri Oct 31 18:44:03 2003 Subject: [Pythonmac-SIG] make packages w/o packman In-Reply-To: <6C9894B8-0B3B-11D8-BE87-00306575F888@brandeis.edu> References: <6C9894B8-0B3B-11D8-BE87-00306575F888@brandeis.edu> Message-ID: <195F8889-0BFC-11D8-A514-000A27B19B96@cwi.nl> On 31-okt-03, at 1:44, Wladimir Labeikovsky wrote: > hullo, > could somebody point towards info on how to build external python > packages for use with framework python? > > e.g. how to take the ,say, numeric sources from numpy.org and change, > say, setup.py so that it builds and installs correctly against panther > builtin python.... For Numeric: download, unpack, "python setup.py". For some other packages the procedure is more involved, that's why PackMan handles source packages too. -- 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 janssen at parc.com Fri Oct 31 18:54:26 2003 From: janssen at parc.com (Bill Janssen) Date: Fri Oct 31 18:54:54 2003 Subject: [Pythonmac-SIG] wxPython the perfect GUI toolkit on mac os x? In-Reply-To: Your message of "Fri, 31 Oct 2003 15:14:16 PST." Message-ID: <03Oct31.155436pst."58611"@synergy1.parc.xerox.com> PyGTK (http://www.daa.com.au/~james/software/pygtk/) is a very nice toolkit based on the Gimp/Gnome toolkit, which works on MacOS X, Windows, and Linux/Unix in general. I tend to like the API structure of GTK+, so I like this toolkit, which mirrors it closely. It also has a *real* text widget (full styled text, embedded widgets, editing, etc.) which is a rarity in toolkits. Bill From janssen at parc.com Fri Oct 31 19:06:32 2003 From: janssen at parc.com (Bill Janssen) Date: Fri Oct 31 19:07:01 2003 Subject: [Pythonmac-SIG] Re: PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Wed, 29 Oct 2003 18:30:31 PST." <03Oct29.183038pst."58611"@synergy1.parc.xerox.com> Message-ID: <03Oct31.160636pst."58611"@synergy1.parc.xerox.com> Thanks to some kind folks on the MacPython ichat channel last night, we tracked the problem down further. The build process is for some reason creating an _imaging.so file with the following names in it: % otool -Lv /Library/Python/2.3/PIL/_imaging.so /Library/Python/2.3/PIL/_imaging.so: Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0) time stamp 1067389093 Tue Oct 28 16:58:13 2003 /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.0.0) time stamp 1064385339 Tue Sep 23 23:35:39 2003 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0) time stamp 1064354548 Tue Sep 23 15:02:28 2003 % For some reason, the first line "Python.framework..." is wrong (don't ask me how I know -- I was told). By applying another magic incantation, % install_name_tool -change Python.framework/Versions/2.3/Python \ /System/Library/Frameworks/Python.framework/Versions/2.3/Python things get fixed, and the Image module loads properly. It seems to me that this means there's a bug somewhere in gcc 3.3 as deployed on MacOS 10.3. Something's putting that bad name in there. Bill From aparente at adobe.com Fri Oct 31 19:24:53 2003 From: aparente at adobe.com (Alexandre Parenteau) Date: Fri Oct 31 19:25:55 2003 Subject: [Pythonmac-SIG] Re: PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: <03Oct31.160636pst.58611@synergy1.parc.xerox.com> Message-ID: Hi, > Thanks to some kind folks on the MacPython ichat channel last night, > we tracked the problem down further. The build process is for some > reason creating an _imaging.so file with the following names in it: > > % otool -Lv /Library/Python/2.3/PIL/_imaging.so > /Library/Python/2.3/PIL/_imaging.so: > Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current > version 2.3.0) > time stamp 1067389093 Tue Oct 28 16:58:13 2003 > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.0.0) > time stamp 1064385339 Tue Sep 23 23:35:39 2003 > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 71.0.0) > time stamp 1064354548 Tue Sep 23 15:02:28 2003 > % > > For some reason, the first line "Python.framework..." is wrong (don't > ask me how I know -- I was told). By applying another magic > incantation, If you link a python module using 'Python.framework/Versions/2.3/Python', it means that the Python framework is going to be searched inside (in order): ~/Library /Library /System/Library So if you compile PIL, and then launch it on a machine which has a Python inside both /Library, and /System/Library, then you'd better use /usr/local/bin/python, else /usr/bin/python is going to load /System/Library/Frameworks/Python, but the python module is going to load /Library/Frameworks/Python. Jack, what are the guidelines for linking a Python module ? I see Apple's Panther Python is using /System/Library/Frameworks/Python.framework/Versions/2.3/Python. And you seem to be using /Library/Frameworks/Python.framework/Versions/2.3/Python. This should work (I think), but do we need to be that explicit ? Shouldn't 'Python.framework/Versions/2.3/Python' be better so the extension can be used in both Frameworks (?). The mystery of Python loading... Thanks, Alex. > > % install_name_tool -change Python.framework/Versions/2.3/Python \ > /System/Library/Frameworks/Python.framework/Versions/2.3/Python > > things get fixed, and the Image module loads properly. > > It seems to me that this means there's a bug somewhere in gcc 3.3 as > deployed on MacOS 10.3. Something's putting that bad name in there. > > Bill > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Alexandre Parenteau Computer Scientist Core Technologies, AGM Adobe Systems, Inc. 408-536-6166 From janssen at parc.com Fri Oct 31 20:16:50 2003 From: janssen at parc.com (Bill Janssen) Date: Fri Oct 31 20:17:18 2003 Subject: [Pythonmac-SIG] Re: PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Fri, 31 Oct 2003 16:24:53 PST." Message-ID: <03Oct31.171651pst."58611"@synergy1.parc.xerox.com> > If you link a python module using 'Python.framework/Versions/2.3/Python', it > means that the Python framework is going to be searched inside (in order): > > ~/Library > /Library > /System/Library > What does "searched inside" mean? What is "the Python framework"? Who is linking this module using 'Python.framework/Versions/2.3/Python' (and how do I make them stop :-?). Bill From janssen at parc.com Fri Oct 31 20:20:42 2003 From: janssen at parc.com (Bill Janssen) Date: Fri Oct 31 20:21:08 2003 Subject: [Pythonmac-SIG] Re: PIL 1.1.4 breaks Python 2.3 on Mac OS X 10.3 Panther In-Reply-To: Your message of "Fri, 31 Oct 2003 16:24:53 PST." Message-ID: <03Oct31.172046pst."58611"@synergy1.parc.xerox.com> One of the things I did when trying to figure out this problem was to build and install Python 2.3 from source under /usr/local, so I do have two Python's: /usr/bin/python and /usr/local/bin/python. Can I just remove any Python files under /Library to get rid of this duplicate framework version? Bill From janssen at parc.com Wed Oct 29 02:24:39 2003 From: janssen at parc.com (janssen) Date: Tue Nov 4 00:22:33 2003 Subject: [Pythonmac-SIG] PIL 1.1.4 and Python 2.3 on Mac OS X 10.3? Message-ID: <20031029072439.07E821BE55A@wolfe.parc.com> I've just upgraded my Mac to 10.3, and I'm trying to install PIL 1.1.4 under /usr/bin/python, which is now 2.3. Build seems to go alright. But no soap -- I keep getting the following error: % /usr/bin/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 Image Fatal Python error: Interpreter not initialized (version mismatch?) Abort % Anyone know the issue? Bill