🌐 Mailman 3 March 2006 - Pythonmac-SIG - python.org

How to get MacOS X version?
by Russell E. Owen March 30, 2006

March 30, 2006

How can I get the version of MacOS X within a python program? (e.g. 10.4.5 -- something that is recognizable, rather than the kernel version). In theory I can get it from gestalt, but I haven't figured out how to do it via the Carbon package, or even if it's possible. Any hints? -- Russell P.S. I'm going to be trying to figure out the same thing for unix and even Windows. I think I know how to do those, but if you happen to know or have sample code, that'd be great.

2 2

Re: [Pythonmac-SIG] How to get MacOS X version?
by Kent Quirk March 29, 2006

March 29, 2006

-----Original Message----- From: pythonmac-sig-bounces(a)python.org [mailto:pythonmac-sig-bounces@python.org] On Behalf Of Russell E. Owen Sent: Wednesday, March 29, 2006 1:55 PM How can I get the version of MacOS X within a python program? (e.g. 10.4.5 -- something that is recognizable, rather than the kernel version). <snip> P.S. I'm going to be trying to figure out the same thing for unix and even Windows. I think I know how to do those, but if you happen to know or have sample code, that'd be great. ----------- On Windows, you can use sys.getwindowsversion, which will return something that looks like: (5, 1, 2600, 2, 'Service Pack 2') The first 3 values define the windows version; the fourth is generated by python code as a general NT vs CE vs ME identifier. Here's some sample code (table data cheerfully borrowed from the Inno Setup installer tool on Windows). ########################## import sys win_versions = { '4.0.950':'Windows 95', '4.0.1111':'Windows 95 OSR 2 & OSR 2.1', '4.0.1212':'Windows 95 OSR 2.5', '4.1.1998':'Windows 98', '4.1.2222':'Windows 98 Second Edition', '4.9.3000':'Windows Me', '4.0.1381':'Windows NT 4.0', '5.0.2195':'Windows 2000', '5.1.2600':'Windows XP', '5.2.3790':'Windows Server 2003', } version = win_versions["%d.%d.%d" % sys.getwindowsversion()[:3]] print version ########################## Note that this tool does NOT identify 64-bit versions of Windows (they'll show up as either XP or Server 2K3). I don't know how you'd do that.

1 0

F2PY, F90, and Mac os x Tiger: linking problem
by Louis Wicker March 28, 2006

March 28, 2006

All: last year (twice) I posted a question on several groups looking for an answer about an error with trying linking F2PY with XLF 8.1 on Mac OS X Tiger. I have been busy with other developments, but I thought I would post that it is now working (after I finally gave a couple things a try). 1. Thanks to Bob Ippolito for the suggestion about the Xcode not being in sync with the Tiger install. That solved the __mh_header problem. 2. I got the hello.f example work with the following command line with XLF: f2py --fcompiler=ibm -c -m hello hello.f -L/opt/ibmcmp/xlf/8.1/lib - lxlf90 -lxlopt -lxl -lxlfmath I was getting an error message with out directly linking in the xlf libs when I tried to import the shared object file hello.so, ImportError: Failure linking new module: hello.so: Symbol not found: __xlfBeginIO pretty sure not all those libs are needed - but anyway. regards, Lou ------------------------------------------------------------------------ ---- | Dr. Louis J. Wicker | Research Scientist, National Severe Storms Lab | 1313 Halley Cir, Norman, OK 73069 | E-mail: Louis.Wicker(a)noaa.gov | HTTP: www.nssl.noaa.gov/~lwicker | Phone: (405) 366-0416 | Fax: (405) 366-0472 | | | Two wrongs don't make a right, but three left's do... ------------------------------------------------------------------------ ---- | | "The contents of this message are mine personally and | do not reflect any position of the Government or NOAA." | ------------------------------------------------------------------------ ----

1 0

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51
by daniel＠brightfire.com March 28, 2006

March 28, 2006

> ----- Original Message ----- > From: "Ronald Oussoren" <ronaldoussoren(a)mac.com> > To: daniel(a)brightfire.com > Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51 > Date: Tue, 28 Mar 2006 09:38:11 +0200 > > Sigh, the universal python build already runs on 10.3.9 and > supports ppc and i386. I don't have a PPC64 box so cannot even try > to support this. Supporting this in the main build would also > require more special casing because ppc64 processes can only use a > small part of the OSX ABI. > > Ronald Not saying it should, I was just making the point that FAT binaries can be constructed in more than even two ways. So it seems the numpy build is treating the 'arch' flags as command line options that can be logically combined and not as seperate binary build selectors as it should. Sorry for trying to help. I am approriately chastised now.

2 1

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51
by daniel＠brightfire.com March 28, 2006

March 28, 2006

> ----- Original Message ----- > From: "Bob Ippolito" <bob(a)redivi.com> > To: daniel(a)brightfire.com > Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51 > Date: Mon, 27 Mar 2006 17:44:13 -0800 > > > > On Mar 27, 2006, at 5:10 PM, daniel(a)brightfire.com wrote: > > >> From: Christopher Barker <Chris.Barker(a)noaa.gov> > >> To: pythonmac-sig(a)python.org > >> Subject: Re: [Pythonmac-SIG] Installing numpy 0.9.6 problems > >> Date: Mon, 27 Mar 2006 09:50:33 -0800 > > > >> Ronald Oussoren wrote: > > > >>> I'd prefer to have 1 installer for python on OSX, that makes > >>> support a lot easier. > > > >> And we would like to by able to use Py2App to build apps that will > >> run under both 10.3.9 and 10.4.* > > That will work as long as the apps don't include anything that > strongly links to 10.4 specific features (e.g. xattr). We've taken > steps to make sure that the right thing happens with Python > itself, but the onus is on third party extensions to also do the > right thing when relevant. For most libraries, there shouldn't be > an issue. > > > But shouldn't we be able to build -ppc, -i386, and even -ppc64 > > with gcc 4.0 and then use 'lipo' to paste them to together and > > let the loader sort them out at run-time? Does the loader on > > 10.3 know enough to pick '-arch ppc' even with other in there or > > am I assuming too much? I'd test it myself, but my G5 1.8 Dual > > has died and my Quad hasn't arrived yet since I am out of town > > for the week ;-(. > > ppc64 is definitely not going to work. You'd need a vanilla unix > build with no Mac specific stuff to do ppc64, because it only > really can talk to libSystem. I understand--just making a point that the kernel checks the header of the binary to determine how to have it loaded and by which dynamic linker. May be I am stating the obvious, but that, and not combining then with 'lipo' is my assesment of the incorrect configuration of the numpy build 'recipe' > I don't know what you're talking about with regard to "loader". If > you're asking whether 10.3 can run universal binaries, then sure > -- Mac OS X has always had support for fat mach-o files, it's just > the toolchain that's changed such that you can reasonably make > them now. Well I sacrificed recision for brevity. So...I meant the appropriate dynamic linker for the binary as I mentioned above--I was just trying to be terse. Correct me if I am wrong, but still glossing over some details and simplifying, the kernel checks the header of the binary to determine which dynamic linker to use to load the binary's segments. Then they are loaded/overlayed into the process space according to their type by the appropriate linker/segment loader/thing. 'dylibs' are loaded with the timing of the loading depending upon the binding choice, pre-binding being no longer possible in 10.4 and just-in-time being the recommendation now as I recall. So it's just some drudgery to compile for both formats, use 'lipo' to combine them and we have a universal app. Right? Not trying trivialize the work involved--just stating that I think the tools are there and its possible. Daniel > -bob >

1 0

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51
by daniel＠brightfire.com March 28, 2006

March 28, 2006

>From: Christopher Barker <Chris.Barker(a)noaa.gov> >To: pythonmac-sig(a)python.org >Subject: Re: [Pythonmac-SIG] Installing numpy 0.9.6 problems >Date: Mon, 27 Mar 2006 09:50:33 -0800 >Ronald Oussoren wrote: >> I'd prefer to have 1 installer for python on OSX, that makes >> support a lot easier. >And we would like to by able to use Py2App to build apps that will >run under both 10.3.9 and 10.4.* >-Chris But shouldn't we be able to build -ppc, -i386, and even -ppc64 with gcc 4.0 and then use 'lipo' to paste them to together and let the loader sort them out at run-time? Does the loader on 10.3 know enough to pick '-arch ppc' even with other in there or am I assuming too much? I'd test it myself, but my G5 1.8 Dual has died and my Quad hasn't arrived yet since I am out of town for the week ;-(. Daniel

3 2

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
by Alex Martelli March 28, 2006

March 28, 2006

> Without any experience with "eggs" (I believe that they are another > Phillip Eby brainstorm?), can I suggest that a standard command-line Yep, they are. > Is there a specification for the "egg" format? http://peak.telecommunity.com/DevCenter/PythonEggs They're zipfiles containing additional metadata, though it's hard to find all details and formalspecs on the site... Alex

1 0

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
by Bob Ippolito March 28, 2006

March 28, 2006

On Mar 27, 2006, at 4:57 PM, Christopher Barker wrote: > Christopher Barker wrote: > >> Then yes, that's a great idea. I am, as we e-speak, reworking >> those pages with a different structure now. I'm no web designer, >> but it should give us something that someone can make prettier if >> they want. > > First I added a link to the packages page at the top of the main > pythonmac.org page. > > I've enclosed a simple rearrangement of the pythonmac.org/packages > page. What I've done is create a separate page for each supported > build. As the packages built for 10.3 will also work on 10.4, I > double listed them, so that a 10.4 user could just go to that page, > and see everything that they can use. > > I also put a link in to download the python builds themselves, why > not be able to get it all from one place? > > Ultimately, we really should have some little semi-automated tool > that would make it easy to add a new package to the list, updated > the page. For now, doing by hand is not too big a deal, and I > don't' want to mess with tools before we settle on a page layout. > > The pages are enclosed as a zip file. Ii hope anyone who is > interested will give feedback. Cool, I'll take a look at this probably tomorrow. The package list is currently automated using a dumb little script.. check this: # the input data http://pythonmac.org/packages/packages.txt # the script http://undefined.org/python/packages.py.txt -bob

1 0

[ann] Appscript Installer 1.3 released
by has March 27, 2006

March 27, 2006

Hi all, Appscript updates are now available at: http://freespace.virgin.net/hamish.sanderson/appscript.html This release adds Intel Mac support [1] and changes the license from LGPL to MIT. Many thanks to Ben Artin for providing Intel compatibility patches. If anyone has any problems, please let me know. has [1] Re. Python 2.4.x on Intel Macs: I'll make up a binary appscript installer once the universal Python 2.4.2 installer is officially released. Meantime you should be able to build from source. -- http://freespace.virgin.net/hamish.sanderson/

4 6

Re: [Pythonmac-SIG] [ann] Appscript Installer 1.3 released
by Christopher Barker March 27, 2006

March 27, 2006

Bill Janssen wrote: >> It is officialy released, even if Bill hasn't updated the download >> page at python.org yet. Are we really ready to call it the "official" version to use? I just had a colleague try it, then he asked me how to get wxPython and numpy working with it. I don't think there is a wxPython build for it yet (will the one for 2.4.1 work?) And he couldn't get numpy to build and install right. I didn't try to debug that for him, instead I suggested to just use 2.4.1 for a while longer. If the new universal build is it now, we need to update pythonmac.org/packages with some information about what packages will work with it, and start building new universal packages! I know I need: wxPython numpy matplotlib At the very least, so I'll help with those, though wxPython is beyond my skills. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

4 4