Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
Hello, On May 3, 2005, at 11:09 AM, Wolfgang Keller wrote: has anyone already wrapped the getxattr(), setxattr(), removexattr(), listxattr() functions on MacOS 10.4 for Python? I took a stab at it today. Hey, I had asked _whether_ someone has done it, I didn't ask you _to_ _do_ _it_! ;-) Get the xattr package from pythonmac packages http://pythonmac.org/ packages/ Shame on me, I don't even have MacOS X.4 yet. *drvvf* I don't expose getxattr, etc. as public API, because the options they take don't translate well to Python. Public API is simply an xattr type that you can wrap over a path or fd, and then it's used in a dict-like way. That's _exactly_ the way it should be done. :-) Dumb question: How about integrating it officially in the Macpython distribution, so that all file objects on MacOS X.4 automatically have an xattr dict? Best regards, Wolfgang Keller -- P.S.: My From-address is correct ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PyOXIDE wishes?
Since this thread came up again, I'll take the liberty of adding my own $0.02 (I just joined the list recently): - in addition to reviewing recent threads that covered IDEs, please review threads that describe newbie impressions of MacPython. For example, Troy Rollins's views are quite important IMHO. I've followed MacPython for years, but haven't jumped in since I can't afford the productivity hit. A really good IDE makes a huge difference. - given the wide variety of free IDEs, perhaps its time for a paid one to enter the mix? Presumably that would allow more features in less time. For example, there's now a commercial editor for Perl on the Mac: Affrus from Late Night Software. (I know Mark; he's a great guy, but he didn't pay me to write this! Nor have I tried the product, though his Script Debugger for AppleScript is great.) ... for maximum reach, the IDE could have a dual license, e.g. free for shipping free software, commercial otherwise. There will be *some* complaints from both side, but still may be the best way to crank out the features. - robustness is more important than features! It's fun to add features, but for commercial developers, a few crashes may suffice to move on to something else. Test-driven development seems like a good fit here. - as others have said, please include some real information on your website. People want to have confidence that there's a serious effort to create a real product not just a quick hack for the fun of it. - without reviewing any of the great suggestions in previous threads, here are a few items on my priority list: * never crash * tight integration with Text Wrangler (free) and BBEdit (paid); let them worry about syntax highlighting and otherwise making a cool (if imperfect) editor * a real debugger: single step, breakpoints, step in/out, examine variables in a GUI, change values and continue running * the debugger should allow debugging of code that uses wxPython. And PyObjC to the extent that's possible (probably can't step into the ObjC part) and desirable (does XCode suffice?). * super convenient display of Python help, e.g. command-dbl-click on any keyword to jump right to relevent information about it (e.g. params for a function); perhaps option-dbl-click for a different bit of info (if there are 2 logical targets) -- note that you can probably add this to TextWrangler/BBEdit via AppleEvents and a script menu and/or a plug-in * did I mention never crash? - one thing Text Wrangler and BBEdit may not do: command completion. Wonder if it could be done as a plugin, or even via AppleEvents - and, one FUTURE: real outlining. That's also been mentioned in recent threads. I'll just add that Frontier is now open source, with an active group of developers. So, anyone can see how it works. (And, Radio UserLand has had a free trial version forever AFAIK.) Note that UserTalk (Frontier's native scripting language) is very much in the spirit of Python (e.g. uses indentation instead of curly braces). And, Frontier allows embedded AppleScript or any other OSA language (or did on OS 9; I haven't check on X). And, there's now an effort to integrate Python. http://www.scriptweb.org/FrontierAsOpenSource.html isn't quite up to date but points to the Yahoo Groups list and such. ... Is that long enough for a first post? cheers, Scott PreFab.com, ScriptWeb.org, etc. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
Wolfgang Keller [EMAIL PROTECTED] writes: [xattr co] Dumb question: How about integrating it officially in the Macpython distribution, so that all file objects on MacOS X.4 automatically have an xattr dict? Are these functions in any way standard (eg. does FreeBSD have them?). If so, they should probably be detected at configure time. Another question is if empty xattr dicts should appear on platforms with no support for them. Cheers, mwh -- MARVIN: Do you want me to sit in a corner and rust, or just fall apart where I'm standing? -- The Hitch-Hikers Guide to the Galaxy, Episode 2 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Adding missing modules in py2app
I noticed that py2app systematically leaves out some extension modules when I build an application package. I don't really blame it, as they reside in a directory that is only added to sys.path when some other module is imported, but I am looking for a way to tell py2app to include them nevertheless. At first I though the package option would do this, but after some experimentation and an inspection of the examples, it seems that it will only add Python packages (as it does with distutils in general). ext_modules is not what I want either, the modules are already built and installed, I just want them to be included. Is there some other approach that I could try? Konrad. -- - Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] - ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
On 5/4/05, Michael Hudson [EMAIL PROTECTED] wrote: Wolfgang Keller [EMAIL PROTECTED] writes: [xattr co] Dumb question: How about integrating it officially in the Macpython distribution, so that all file objects on MacOS X.4 automatically have an xattr dict? Are these functions in any way standard (eg. does FreeBSD have them?). If so, they should probably be detected at configure time. I don't believe FreeBSD has them, but the SELinux project has them for ACLs, though they are poorly documented. They may also exist in other file systems, such as ReiserFS. Also, the concept exists on Solaris as well. The trick is that on Solaris and SELinux they're purely an ACL issue as far as I know. I believe Tiger is the first OS to fully deploy an abstract meta-data infrastructure in the FS. While ReiserFS has it, from what I'm told, it's not widely deployed. Another question is if empty xattr dicts should appear on platforms with no support for them. Yes, they should appear empty, and I would imagine, throw an Exception on any attempt to set them. Chris -- | Christopher Petrilli | [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Some Mac packages for downloading
Konrad, Wanted to say thanks. Not packages I;d use every day :~) (more into engineering modeling) but it looks like things are starting to come together more in the Mac+Python community. Together with what Jack started and Bob is doing now, your work is a real contribution. Maybe at some point we might be able to pull together a more centralized repository for the less build first Python Mac users. I know other software engineers on Mac that are reluctant to get into Python yet, and though Apple is doing what they see fit it is not enough to encourage more widespread use. I've just gotten started in the Mac and Python environment (in my retirement), but if there is someway I might be able to help I'll give it a shot. At the moment I'm amusing myself with class design pattern methodology. Did more assembler, Fortran and C in my career, and this is a real joy. Anyway, thank you, Lee C On May 4, 2005, at 8:45 AM, [EMAIL PROTECTED] wrote: I have started a small collection of Mac packages at http://dirac.cnrs-orleans.fr/MacPackages/ At the moment there is netCDF, ScientificPython, MMTK, and nMOLDYN. netCDF is also available from the netCDF Web site (I sent them my package, they liked it and plan to provide Mac packages themselves in the future). I also keep a copy of Numeric 23.7 around, just in case Bob updates his and I can't follow quickly enough. Konrad. -- - Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] - ___ 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
[Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 from source. I guess if I were zen-ful about Mac packages I'd be able to figure out the necessary changes from the download...but I'm not. Could anyone help me know what I need to change? Thanks Gary ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 17:15, Gary Poster wrote: Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 from source. I guess if I were zen-ful about Mac packages I'd be able to figure out the necessary changes from the download...but I'm not. Could anyone help me know what I need to change? You could get it from Fink, or at least take a look at the Fink info file to see how they build it. However, I suppose that a straight build from the Python sources will yield just what you want, it's probably the Framework build that requires special action. Konrad. -- - Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] - ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
On May 4, 2005, at 6:38 AM, Wolfgang Keller wrote: On May 3, 2005, at 11:09 AM, Wolfgang Keller wrote: has anyone already wrapped the getxattr(), setxattr(), removexattr(), listxattr() functions on MacOS 10.4 for Python? I took a stab at it today. Hey, I had asked _whether_ someone has done it, I didn't ask you _to_ _do_ _it_! ;-) Get the xattr package from pythonmac packages http://pythonmac.org/ packages/ Shame on me, I don't even have MacOS X.4 yet. *drvvf* I don't expose getxattr, etc. as public API, because the options they take don't translate well to Python. Public API is simply an xattr type that you can wrap over a path or fd, and then it's used in a dict-like way. That's _exactly_ the way it should be done. :-) Dumb question: How about integrating it officially in the Macpython distribution, so that all file objects on MacOS X.4 automatically have an xattr dict? Since that would be a feature addition, it wouldn't be able to integrate until Python 2.5 at the earliest. I don't really see the need to add platform-specific things to the file object though. No other platforms do it, and even the HFS stuff you can do with files needs to be done with Carbon.File, etc. In any case, I'd rather take all of the Mac specific stuff *out* of the Python standard library than put more in. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
Hi - However, I suppose that a straight build from the Python sources will yield just what you want, it's probably the Framework build that requires special action. That is correct. I built 2.4 from source and had to do a bit of command-line jiggling to get the Framework build instead of the vanilla Unix variety. - Craig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PyOXIDE wishes?
On May 4, 2005, at 7:17 AM, Scott Lawton wrote: - given the wide variety of free IDEs, perhaps its time for a paid one to enter the mix? Presumably that would allow more features in less time. For example, there's now a commercial editor for Perl on the Mac: Affrus from Late Night Software. (I know Mark; he's a great guy, but he didn't pay me to write this! Nor have I tried the product, though his Script Debugger for AppleScript is great.) I don't think you have to worry about anyone here buying a Perl IDE :) If I had the time I'd write an IDE, but I have too many other things going on. ... for maximum reach, the IDE could have a dual license, e.g. free for shipping free software, commercial otherwise. There will be *some* complaints from both side, but still may be the best way to crank out the features. Wing is like this, but you have to apply for a free license, and it's X11 only. - robustness is more important than features! It's fun to add features, but for commercial developers, a few crashes may suffice to move on to something else. Test-driven development seems like a good fit here. I agree. - without reviewing any of the great suggestions in previous threads, here are a few items on my priority list: * a real debugger: single step, breakpoints, step in/out, examine variables in a GUI, change values and continue running * the debugger should allow debugging of code that uses wxPython. And PyObjC to the extent that's possible (probably can't step into the ObjC part) and desirable (does XCode suffice?). Wing has both of these, last I checked, because it Does The Right Thing and runs the client code in a separate process, and the debugger hooks are done over TCP (or maybe a pipe, but probably TCP). When doing it the right way, it doesn't matter which GUI framework you're using. Xcode (gdb really) can step into the C or Objective-C part of any program, but that's not going to do you much good. When you're coding in PyObjC, you're probably using Apple's frameworks, which are closed source, so stepping into Objective-C code isn't really going to do you any good. However, Xcode doesn't have a public API for debugger plugins (yet?) so nobody outside of Cupertino can currently, reasonably, write a Python debugger plugin. Among other reasons, this makes Xcode mostly unsuitable for Python development unless all you want is a text editor. * super convenient display of Python help, e.g. command-dbl- click on any keyword to jump right to relevent information about it (e.g. params for a function); perhaps option-dbl-click for a different bit of info (if there are 2 logical targets) -- note that you can probably add this to TextWrangler/BBEdit via AppleEvents and a script menu and/or a plug-in Well, in a plugin you can do anything.. but this is pretty hard to do in general unless you're running the Python code at the time. - one thing Text Wrangler and BBEdit may not do: command completion. Wonder if it could be done as a plugin, or even via AppleEvents Xcode does this for any code, just by throwing everything it sees into the completion dictionary. It would be trivial for them to add similar support to Text Wrangle, since it is written in Cocoa and NSTextView has completion built-in. It could also be a plugin, I guess, but it would be easier for them to do on their own. If you take a look at PyObjC's PyInterpreter example, it implements completion, and it's not very hard. You can play with the completion, even in TextEdit... just type a partial word and hit opt-esc and it will complete against the dictionary. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Adding missing modules in py2app
On May 4, 2005, at 8:41 AM, [EMAIL PROTECTED] wrote: I noticed that py2app systematically leaves out some extension modules when I build an application package. I don't really blame it, as they reside in a directory that is only added to sys.path when some other module is imported, but I am looking for a way to tell py2app to include them nevertheless. At first I though the package option would do this, but after some experimentation and an inspection of the examples, it seems that it will only add Python packages (as it does with distutils in general). ext_modules is not what I want either, the modules are already built and installed, I just want them to be included. Is there some other approach that I could try? Modify sys.path in your setup script. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 11:15 AM, Gary Poster wrote: Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 from source. I guess if I were zen-ful about Mac packages I'd be able to figure out the necessary changes from the download...but I'm not. Could anyone help me know what I need to change? Building Python 2.4.1 *on* Tiger has no issues, because I fixed that before Python 2.4.1 was released. Python 2.4.1 built on Panther, and moved over to Tiger, *does* have issues, and that's what TigerPython24Fix takes care of (along with another issue that's only relevant to the framework installer package). -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 12:04 PM, Craig Amundsen wrote: However, I suppose that a straight build from the Python sources will yield just what you want, it's probably the Framework build that requires special action. That is correct. I built 2.4 from source and had to do a bit of command-line jiggling to get the Framework build instead of the vanilla Unix variety. Where a lot of command-line jiggling means typing: ./configure --enable-framework make sudo make frameworkinstall instead of: ./configure make sudo make install -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
The trick is that on Solaris and SELinux they're purely an ACL issue as far as I know. I believe Tiger is the first OS to fully deploy an abstract meta-data infrastructure in the FS. While ReiserFS has it, from what I'm told, it's not widely deployed. Not entirely true, BeOS pioneered file metadata infrastructure, as well as multi-fork files, but OS X may well be the first mainstream OS to do so. --Dethe Why is Virtual Reality always posited in terms of space, when time is the only real commodity left? --Rich Gold ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
On 5/4/05, Dethe Elza [EMAIL PROTECTED] wrote: The trick is that on Solaris and SELinux they're purely an ACL issue as far as I know. I believe Tiger is the first OS to fully deploy an abstract meta-data infrastructure in the FS. While ReiserFS has it, from what I'm told, it's not widely deployed. Not entirely true, BeOS pioneered file metadata infrastructure, as well as multi-fork files, but OS X may well be the first mainstream OS to do so. Not to nit-pick, but multi-fork and metadata have existed on the Mac since HFS's introduction in, I believe 1985/1986 timeframe. BeOS took it much much further, but even the Mac was based on the meta-data ideas that existed in the Star and Alto designs. In many ways, we're still trying to get to the 1970s. Chris -- | Christopher Petrilli | [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
On 4-mei-2005, at 18:00, Bob Ippolito wrote: That's _exactly_ the way it should be done. :-) Dumb question: How about integrating it officially in the Macpython distribution, so that all file objects on MacOS X.4 automatically have an xattr dict? Since that would be a feature addition, it wouldn't be able to integrate until Python 2.5 at the earliest. I don't really see the need to add platform-specific things to the file object though. No other platforms do it, and even the HFS stuff you can do with files needs to be done with Carbon.File, etc. In any case, I'd rather take all of the Mac specific stuff *out* of the Python standard library than put more in. Agreed. What's needed is an easy interface for adding 3th party packages to an installation, something like the CPAN interface of Perl. That makes it possible to develop python-the-language seperately from packages without inconveniencing the user too much. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 12:19 PM, Bob Ippolito wrote: On May 4, 2005, at 11:15 AM, Gary Poster wrote: Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 from source. I guess if I were zen-ful about Mac packages I'd be able to figure out the necessary changes from the download...but I'm not. Could anyone help me know what I need to change? Building Python 2.4.1 *on* Tiger has no issues, because I fixed that before Python 2.4.1 was released. Python 2.4.1 built on Panther, and moved over to Tiger, *does* have issues, and that's what TigerPython24Fix takes care of (along with another issue that's only relevant to the framework installer package). Thanks for the reply. Building 2.4.1 on Tiger has issues for me, at least. Here is the problem I'm seeing. After running the following: tar xvzf Python-2.4.1.tgz cd Python-2.4.1 ./configure --prefix=/Users/gary/tmp/ make I then get this output from make: ...snip successful builds... gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include - DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o Modules/posixmodule.c: In function `posix_lchown': Modules/posixmodule.c:1352: warning: implicit declaration of function `lchown' Modules/posixmodule.c:5998:25: sys/statvfs.h: No such file or directory Modules/posixmodule.c: At top level: Modules/posixmodule.c:6001: error: parameter `st' has incomplete type Modules/posixmodule.c: In function `posix_fstatvfs': Modules/posixmodule.c:6047: error: storage size of `st' isn't known Modules/posixmodule.c:6052: warning: implicit declaration of function `fstatvfs'Modules/posixmodule.c:6047: warning: unused variable `st' Modules/posixmodule.c:6063:25: sys/statvfs.h: No such file or directory Modules/posixmodule.c: In function `posix_statvfs': Modules/posixmodule.c:6074: error: storage size of `st' isn't known Modules/posixmodule.c:6078: warning: implicit declaration of function `statvfs' Modules/posixmodule.c:6074: warning: unused variable `st' make: *** [Modules/posixmodule.o] Error 1 The same recipe didn't cause this problem on Panther/gcc 3.x yesterday. Any ideas? Thanks Gary ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 2:15 PM, Gary Poster wrote: On May 4, 2005, at 12:19 PM, Bob Ippolito wrote: Building Python 2.4.1 *on* Tiger has no issues, because I fixed that before Python 2.4.1 was released. Python 2.4.1 built on Panther, and moved over to Tiger, *does* have issues, and that's what TigerPython24Fix takes care of (along with another issue that's only relevant to the framework installer package). Thanks for the reply. Building 2.4.1 on Tiger has issues for me, at least. ... In the put the finger in the dike approach, actually modifying Modules/posixmodule.c, adding the following two lines at line 5991 (or anywhere earlier, of course) at least lets make install run to completion and more-or-less build: #undef HAVE_FSTATVFS #undef HAVE_STATVFS ...except that Tk appears to be pretty unhappy and I keep on getting /usr/include/AvailabilityMacros.h:101:6: #error MAC_OS_X_VERSION_MAX_ALLOWED must be = MAC_OS_X_VERSION_MIN_REQUIRED all over the place. argh. Can anyone else who upgraded verify this behavior? The only things that I figure might possibly be affecting me (relatively) uniquely are packages from fink...I guess I'll try retreating from fink entirely next, expecially if no one else can duplicate. :-( Gary ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 2:15 PM, Gary Poster wrote: On May 4, 2005, at 12:19 PM, Bob Ippolito wrote: On May 4, 2005, at 11:15 AM, Gary Poster wrote: Hi. I found Bob Ippolito's TigerPython24Fix but that's only for a framework Python 2.4.1--I need to build a non-Framework Python 2.4.1 from source. I guess if I were zen-ful about Mac packages I'd be able to figure out the necessary changes from the download...but I'm not. Could anyone help me know what I need to change? Building Python 2.4.1 *on* Tiger has no issues, because I fixed that before Python 2.4.1 was released. Python 2.4.1 built on Panther, and moved over to Tiger, *does* have issues, and that's what TigerPython24Fix takes care of (along with another issue that's only relevant to the framework installer package). Thanks for the reply. Building 2.4.1 on Tiger has issues for me, at least. Here is the problem I'm seeing. After running the following: tar xvzf Python-2.4.1.tgz cd Python-2.4.1 ./configure --prefix=/Users/gary/tmp/ make I then get this output from make: ugly stuff snipped Try setting the MACOSX_DEPLOYMENT_TARGET environment variable to 10.4. Anything you build on Tiger isn't going to work prior to that anyway, so setting this can't hurt anything. I tried building 2.4.1 again and it worked just fine: % sw_vers ProductName:Mac OS X ProductVersion: 10.4 BuildVersion: 8A428 % cc --version powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061) ... % echo $MACOSX_DEPLOYMENT_TARGET 10.4 If you set this, and it still doesn't work, there's something else wrong with your configuration that I can't reproduce, so you're on your own if that is the case. I'm not really sure why you're trying not to build a framework Python in the first place, there's no particularly good reason why you'd want a non-framework Python around. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
Hi all, Probably one for Bob, but there's an unpleasant disagreement between Py23Compat and Python 2.4 on where the LaunchServices, OSA, and other new 2.4 modules are located: the former installs them in individual directories of the same name under site-packages, the later keeps them at the top level of plat-mac/Carbon. This means scripts written on Python 2.3 break on 2.4 and vice-versa when importing any of these modules. What's the fix? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
On May 4, 2005, at 3:21 PM, has wrote: Probably one for Bob, but there's an unpleasant disagreement between Py23Compat and Python 2.4 on where the LaunchServices, OSA, and other new 2.4 modules are located: the former installs them in individual directories of the same name under site-packages, the later keeps them at the top level of plat-mac/Carbon. This means scripts written on Python 2.3 break on 2.4 and vice-versa when importing any of these modules. What's the fix? This is not a bug, you need to write your code such that it accommodates for both: try: from LaunchServices import Launch, LaunchServices except ImportError: from Carbon import Launch, LaunchServices -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] AddressBook wrapper
The AddressBook wrapper doesn't appear to expose the constants kABShowAsPerson (0), kABShowAsCompany (1), or kABShowAsMask (7). --Dethe Life is extinct on other planets. Thier scientists were more advanced than ours. --Mark Russell ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
Bob wrote: Probably one for Bob, but there's an unpleasant disagreement between Py23Compat and Python 2.4 [which] means scripts written on Python 2.3 break on 2.4 and vice-versa when importing any of these modules. What's the fix? This is not a bug, Maybe not, but it's hardly good design either. Any time I wish for gratuitous complexity or broken-by-design-ness I can easily use Perl or AppleScript instead. :p try: from LaunchServices import Launch, LaunchServices except ImportError: from Carbon import Launch, LaunchServices I figured that, but I'd rather hoped a more elegant solution might be forthcoming at source. Is there a good reason why they couldn't both agree on a common location, or at least provide the relevant aliases in 2.4 to preserve Python's much-vaunted backwards compatibility? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
On May 4, 2005, at 4:50 PM, has wrote: Bob wrote: Probably one for Bob, but there's an unpleasant disagreement between Py23Compat and Python 2.4 [which] means scripts written on Python 2.3 break on 2.4 and vice-versa when importing any of these modules. What's the fix? This is not a bug, Maybe not, but it's hardly good design either. Any time I wish for gratuitous complexity or broken-by-design-ness I can easily use Perl or AppleScript instead. :p try: from LaunchServices import Launch, LaunchServices except ImportError: from Carbon import Launch, LaunchServices I figured that, but I'd rather hoped a more elegant solution might be forthcoming at source. Is there a good reason why they couldn't both agree on a common location, or at least provide the relevant aliases in 2.4 to preserve Python's much-vaunted backwards compatibility? This is *FORWARDS* compatibility, not backwards. Forwards compatibility is always messy. You have three options: 1) Work around it 2) Require Python 2.4 3) Require the non-standard-library components even on 2.4 Pick one, there's nothing that can be done about it. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
Hello, Dumb question: How about integrating it officially in the Macpython distribution, so that all file objects on MacOS X.4 automatically have an xattr dict? Are these functions in any way standard (eg. does FreeBSD have them?). If so, they should probably be detected at configure time. I don't believe FreeBSD has them, but the SELinux project has them for ACLs, though they are poorly documented. They may also exist in other file systems, such as ReiserFS. Also, the concept exists on Solaris as well. Basically _every_ modern file system has extended attributes. The trick is that on Solaris and SELinux they're purely an ACL issue as far as I know. The irony is that it seems that currently _no_ OS that supports extended attributes allows the user to actually use them. Because there's no UI. I believe Tiger is the first OS to fully deploy an abstract meta-data infrastructure in the FS. Most definitely not. In fact MacOS X actually seems to be (one of) the last OSes which supports user-definable extended attributes. As I've been told, OS/400 had even a real filebase including relations etc. for decades. VMS had EAs for decades as well. XFS is probably th eoldest unix filesystem with EAs. OS/2's HPFS has them since it existed etc... BeOS was/is apparently the only OS that allowed end user to actually use extended attributes. Through its Tracker. While MacOS X.4 doesn't (provide a UI to user-defined extended attributes). Still. BTW: How many years after Jobs generated all hype bubbles to drag Amelio away from Be, hype bubbles which extremely ressembled those that MS created around Chicago in order to FUD users and companies away from OS/2...? It's been so long ago I can't even remember it. Another question is if empty xattr dicts should appear on platforms with no support for them. Yes, they should appear empty, and I would imagine, throw an Exception on any attempt to set them. Exactly. And, imho, the API (a dict) should be identical on all platforms that support EAs, not just on MacOS X. Best regards Wolfgang Keller -- P.S.: My From-address is correct ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS 10.4: getxattr() etc. for Python?
On May 4, 2005, at 5:10 PM, Wolfgang Keller wrote: Basically _every_ modern file system has extended attributes. Another question is if empty xattr dicts should appear on platforms with no support for them. Yes, they should appear empty, and I would imagine, throw an Exception on any attempt to set them. And, imho, the API (a dict) should be identical on all platforms that support EAs, not just on MacOS X. My implementation is open source and liberally licensed. Anyone who cares about extended attributes on other platforms can feel free to submit a patch or fork the code (if I become unresponsive to patches or something). I don't have care about this feature for other platforms, so I'm not going to write that code. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
Bob wrote: I figured that, but I'd rather hoped a more elegant solution might be forthcoming at source. Is there a good reason why they couldn't both agree on a common location, or at least provide the relevant aliases in 2.4 to preserve Python's much-vaunted backwards compatibility? This is *FORWARDS* compatibility, not backwards. Forwards compatibility is always messy. Touché. ;) 1) Work around it On my todo list. (Requiring 2.4 isn't an option as casual Python users are more likely to be using the stock 2.3.5 and won't want to upgrade just on my account.) Still, can't blame my hoping there might've been a better solution... language warts are always unhappy things, Python warts doubly so. Pity Apple decided to stuff Python.framework into /System instead of /Library, otherwise having Py23Compat install into plat-mac/Carbon might not have been out of the question. I don't suppose Apple would be interested in including these modules (in the correct location) in future Tiger updates...? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
On May 4, 2005, at 6:13 PM, has wrote: Bob wrote: I figured that, but I'd rather hoped a more elegant solution might be forthcoming at source. Is there a good reason why they couldn't both agree on a common location, or at least provide the relevant aliases in 2.4 to preserve Python's much-vaunted backwards compatibility? This is *FORWARDS* compatibility, not backwards. Forwards compatibility is always messy. Touché. ;) 1) Work around it On my todo list. (Requiring 2.4 isn't an option as casual Python users are more likely to be using the stock 2.3.5 and won't want to upgrade just on my account.) Still, can't blame my hoping there might've been a better solution... language warts are always unhappy things, Python warts doubly so. Pity Apple decided to stuff Python.framework into / System instead of /Library, otherwise having Py23Compat install into plat-mac/Carbon might not have been out of the question. I don't suppose Apple would be interested in including these modules (in the correct location) in future Tiger updates...? Apple did everything the right way. Why on earth should they put System stuff anywhere but? ... and god I hope they don't start mangling their Python 2.3 distribution *mid-release* to look Python 2.4-ish. This problem wouldn't have existed if these modules weren't part of the standard library and/or they weren't part of the Carbon namespace. Ripping them out or replacing them altogether with something generated in a more modern way is probably the right thing to do, eventually, but so far nobody has cared enough to deal with it. In any case, basically all Mac OS X APIs (LaunchServices included) are better wrapped with PyObjC. The stuff in Carbon is either becoming deprecated or being wrapped by higher-level Objective-C or CoreFoundation-style APIs, both of which PyObjC is much more appropriate for. It's really just a question of when PyObjC's header- parsing capabilities will be able to wrap CoreFoundation-style stuff quickly and correctly. Fortunately Apple isn't shipping PyObjC with Mac OS X, so we actually have the opportunity to implement these things before they become frozen in time. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 7:15 PM, Gary Poster wrote: On May 4, 2005, at 3:29 PM, Bob Ippolito wrote: I'm not really sure why you're trying not to build a framework Python in the first place, there's no particularly good reason why you'd want a non-framework Python around. I'm a Zope developer. I often have multiple Pythons around, one (or sometimes more) for each large project. Framework builds help nothing for Zope, and friends have scared me off from using them except to replace the main Apple Python (which I just did sucessfully with your MacPython and TigerPython24Fix--thanks!). Maybe that's misplaced fear, but working among developers on other platforms, its (mildly) convenient if our buildouts all use the same buildout dance. Well, you don't build your own on Windows, do you? I don't see why you should have to build one on your Mac either. Framework builds are almost entirely self-contained (except for the /usr/local/bin symlinks), similar to a typical Windows install. In other words, why should you need to build Python 2.4.1 when there is already one built and available? I could understand if you were working off of some modified Python or off CVS HEAD or something.. but it seems like you're spending more time than you should have to. As far as friends scaring you off.. I dunno, maybe they didn't know what they were doing when they tried it, or they were bitten by some problem that has been solved long since. The only incompatibility with framework builds is that stupid extensions that don't use distutils in their build procedure aren't going to work out of the box, but they're probably not going to work out of the box anyway because Mac OS X's linker takes different options. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] building non-Framework Python 2.4.1 on Tiger
On May 4, 2005, at 7:30 PM, Bob Ippolito wrote: As far as friends scaring you off.. I dunno, maybe they didn't know what they were doing when they tried it, or they were bitten by some problem that has been solved long since. The only incompatibility with framework builds is that stupid extensions that don't use distutils in their build procedure aren't going to work out of the box, but they're probably not going to work out of the box anyway because Mac OS X's linker takes different options. -bob On a slightly related note, can I add third-party python modules to the framework using the standard Unix install process. For example, I'm using to installing Python modules on Linux using: python setup.py install or occasionally ./configure;make;make install I've installed your python2.4.1 on Tiger and the fix (just yesterday so I think I got the updated fix). I've installed a number of the packages your or someone else already built (Numeric, PyOpenGL, etc.), but what do I do if I want a module someone hasn't built. Dave smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PyOXIDE wishes?
How many editors have mechanisms that allow retrofitting such functionality? Other than Emacs, I couldn't name any. Hey, once you've named Emacs, there's no need to name any others :-). Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] getting/setting system volume in OS X with python?
Hello list, I've been developing a curses-based music player in python for the last couple of years (http://www.bearhome.net/mpy3) and it is getting pretty good these days. I have added keybindings to control volume in linux using the ossaudiodev module found in python. I wanted to do the same thing under OS X which I am now trying to fully support. After some digging, it looked to me like Carbon.Snd was the ticket. However, I can't find any documentation on this module; I did some digging in Apple provided docs, and was able to get a semi-working, semi-broken version of volume control going (mutes one ear, controls the volume of the other), but I am not sure this will do it. My questions are: 1. Does anyone have a good idea how to go about doing this best on OS X? I am not going to be able to support OS 9 (too many unix dependencies) so if there is a cleaner way to do it than Carbon I would be interested. 2. Is there anywhere to get better docs on things like ae*, Carbon.*, etc? It seems like python for mac is incredibly powerful but arcane, and between no documentation and no doc strings I have a hard time figuring out what I can do with it. Please include me in the replies since I am not a subscriber to this list (yet ;) ). Thanks, -- Erik ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] getting/setting system volume in OS X with python?
On May 4, 2005, at 9:51 PM, Erik Osheim wrote: I've been developing a curses-based music player in python for the last couple of years (http://www.bearhome.net/mpy3) and it is getting pretty good these days. I have added keybindings to control volume in linux using the ossaudiodev module found in python. I wanted to do the same thing under OS X which I am now trying to fully support. After some digging, it looked to me like Carbon.Snd was the ticket. However, I can't find any documentation on this module; I did some digging in Apple provided docs, and was able to get a semi-working, semi-broken version of volume control going (mutes one ear, controls the volume of the other), but I am not sure this will do it. My questions are: 1. Does anyone have a good idea how to go about doing this best on OS X? I am not going to be able to support OS 9 (too many unix dependencies) so if there is a cleaner way to do it than Carbon I would be interested. The best way to do it on OS X is to use CoreAudio, but none of that is wrapped in Python. You can, however, find an Objective-C framework that wraps what you need (MTCoreAudio should be able to do it, but there might be something easier) and just call into that with PyObjC. There are a couple other ways, but they're all really, really old and deprecated and they often behave pretty strangely. 2. Is there anywhere to get better docs on things like ae*, Carbon.*, etc? It seems like python for mac is incredibly powerful but arcane, and between no documentation and no doc strings I have a hard time figuring out what I can do with it. The first thing you should do is look for another way to do it, with PyObjC or some POSIX API (but probably PyObjC). There's a very straightforward translation between Objective-C and Python, so you use Apple's Cocoa docs when developing with PyObjC. If there is no way to do what you need with just PyObjC, you should consider just writing a little Objective-C wrapper that does what you need to do (calling into Carbon, CoreFoundation etc.), and call into that from PyObjC. Use the Apple documentation. Unfortunately this does require knowing C, but the ONLY documentation and the ONLY supported APIs are for C and Objective-C. Most of the time, in my experience, it's just quicker to write and debug the code (i.e. QuickTime related stuff) in Objective-C and call into it from PyObjC. If you still feel the need to try and do it with pure Python, then read the Apple documentation for the relevant function(s) in C, and then guess at how it would be done from Python. Everything in Carbon.* is automatically generated, but there are a bunch of special cases and the rules are a bit strange. These modules would sooner go away than become documented. Don't be surprised if there's a bug in the wrapper or some function call sequence is impossible because the wrapper won't let you pass NULL somewhere, etc. Writing code using undocumented modules that may be broken is no fun. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] getting/setting system volume in OS X with python?
You could use Applescript to do it too. But PyObjC is really a wonderful tool.On 4-May-05, at 8:35 PM, Bob Ippolito wrote:On May 4, 2005, at 9:51 PM, Erik Osheim wrote: I've been developing a curses-based music player in python for thelast couple of years (http://www.bearhome.net/mpy3) and it is gettingpretty good these days. I have added keybindings to control volume inlinux using the ossaudiodev module found in python.I wanted to do the same thing under OS X which I am now trying tofully support. After some digging, it looked to me like Carbon.Snd wasthe ticket. However, I can't find any documentation on this module; Idid some digging in Apple provided docs, and was able to get asemi-working, semi-broken version of volume control going (mutes oneear, controls the volume of the other), but I am not sure this will doit.My questions are:1. Does anyone have a good idea how to go about doing this best on OSX? I am not going to be able to support OS 9 (too many unixdependencies) so if there is a cleaner way to do it than Carbon Iwould be interested. The best way to do it on OS X is to use CoreAudio, but none of that is wrapped in Python. You can, however, find an Objective-C framework that wraps what you need (MTCoreAudio should be able to do it, but there might be something easier) and just call into that with PyObjC.There are a couple other ways, but they're all really, really old and deprecated and they often behave pretty strangely. 2. Is there anywhere to get better docs on things like ae*, Carbon.*,etc? It seems like python for mac is incredibly powerful but arcane,and between no documentation and no doc strings I have a hard timefiguring out what I can do with it. The first thing you should do is look for another way to do it, with PyObjC or some POSIX API (but probably PyObjC). There's a very straightforward translation between Objective-C and Python, so you use Apple's Cocoa docs when developing with PyObjC.If there is no way to do what you need with just PyObjC, you should consider just writing a little Objective-C wrapper that does what you need to do (calling into Carbon, CoreFoundation etc.), and call into that from PyObjC. Use the Apple documentation. Unfortunately this does require knowing C, but the ONLY documentation and the ONLY supported APIs are for C and Objective-C. Most of the time, in my experience, it's just quicker to write and debug the code (i.e. QuickTime related stuff) in Objective-C and call into it from PyObjC.If you still feel the need to try and do it with "pure Python", then read the Apple documentation for the relevant function(s) in C, and then guess at how it would be done from Python. Everything in Carbon.* is automatically generated, but there are a bunch of special cases and the rules are a bit strange. These modules would sooner go away than become documented. Don't be surprised if there's a bug in the wrapper or some function call sequence is impossible because the wrapper won't let you pass NULL somewhere, etc. Writing code using undocumented modules that may be broken is no fun.-bob___Pythonmac-SIG maillist - Pythonmac-SIG@python.orghttp://mail.python.org/mailman/listinfo/pythonmac-sig --- Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] getting/setting system volume in OS X with python?
I was thinking specifically of AppleScript and SoundManager when I said There are a couple other ways, but they're all really, really old and deprecated and often behave strangely. On May 4, 2005, at 11:07 PM, Robert Brown wrote: You could use Applescript to do it too. But PyObjC is really a wonderful tool. On 4-May-05, at 8:35 PM, Bob Ippolito wrote: On May 4, 2005, at 9:51 PM, Erik Osheim wrote: I've been developing a curses-based music player in python for the last couple of years (http://www.bearhome.net/mpy3) and it is getting pretty good these days. I have added keybindings to control volume in linux using the ossaudiodev module found in python. I wanted to do the same thing under OS X which I am now trying to fully support. After some digging, it looked to me like Carbon.Snd was the ticket. However, I can't find any documentation on this module; I did some digging in Apple provided docs, and was able to get a semi-working, semi-broken version of volume control going (mutes one ear, controls the volume of the other), but I am not sure this will do it. My questions are: 1. Does anyone have a good idea how to go about doing this best on OS X? I am not going to be able to support OS 9 (too many unix dependencies) so if there is a cleaner way to do it than Carbon I would be interested. The best way to do it on OS X is to use CoreAudio, but none of that is wrapped in Python. You can, however, find an Objective-C framework that wraps what you need (MTCoreAudio should be able to do it, but there might be something easier) and just call into that with PyObjC. There are a couple other ways, but they're all really, really old and deprecated and they often behave pretty strangely. 2. Is there anywhere to get better docs on things like ae*, Carbon.*, etc? It seems like python for mac is incredibly powerful but arcane, and between no documentation and no doc strings I have a hard time figuring out what I can do with it. The first thing you should do is look for another way to do it, with PyObjC or some POSIX API (but probably PyObjC). There's a very straightforward translation between Objective-C and Python, so you use Apple's Cocoa docs when developing with PyObjC. If there is no way to do what you need with just PyObjC, you should consider just writing a little Objective-C wrapper that does what you need to do (calling into Carbon, CoreFoundation etc.), and call into that from PyObjC. Use the Apple documentation. Unfortunately this does require knowing C, but the ONLY documentation and the ONLY supported APIs are for C and Objective-C. Most of the time, in my experience, it's just quicker to write and debug the code (i.e. QuickTime related stuff) in Objective-C and call into it from PyObjC. If you still feel the need to try and do it with pure Python, then read the Apple documentation for the relevant function(s) in C, and then guess at how it would be done from Python. Everything in Carbon.* is automatically generated, but there are a bunch of special cases and the rules are a bit strange. These modules would sooner go away than become documented. Don't be surprised if there's a bug in the wrapper or some function call sequence is impossible because the wrapper won't let you pass NULL somewhere, etc. Writing code using undocumented modules that may be broken is no fun. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig --- Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada ___ 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
