bob.ippoli.to
Bob Ippolito (@etrepum) on Haskell, Python, Erlang, JavaScript, etc.
«

Python on Mac OS X 10.4 (Tiger)

»

Mac OS X 10.4 (Tiger) ships with Python 2.3.5.

  • Built as a framework (./configure --enable-framework) and installed to /System/Library/Frameworks/Python.framework.

  • Has "faked" unix-style organization by way of symlinks. This is new in Tiger, but I'm not sure why they bothered. It's not really very useful to do it this way because building against these things directly is probably going to fail anyway. Especially because Mac OS X typically requires different linker options than other GCC platforms. The correct way, of course, is to use distutils or at least read values from Python's Makefile, which also works on other platforms. Some people are stubborn and like to do things the wrong way, and this is only going to make them think it's acceptable to do it that way. It's not.

    • /usr/lib/libpython2.3.dylib -> Python.framework/Versions/2.3/Python
    • /usr/include/python2.3 -> Python.framework/Versions/2.3/include/python2.3
    • /usr/lib/python2.3 -> Python.framework/Versions/2.3/lib/python2.3

  • The site-packages folder is symlinked to /Library/Python/2.3/site-packages. This differs from Mac OS X 10.3 (Panther)'s Python 2.3.0, which was symlinked to /Library/Python/2.3. However, it is now consistent with ~/Library/Python/2.3/site-packages.

  • Ships with a proprietary closed-source CoreGraphics extension, which is a SWIG wrapper plus magic private API hackery on top of Apple's framework of the same name. Mac OS X 10.3 also shipped with this extension. I'm not sure whether there's any meaningful difference between the two, since it's not well documented and it's not open source.

  • Ships with a "unicode" build of wxPython 2.5.3. Mac OS X 10.3 did not ship with any wxPython or wxWidgets. I'm not sure whether this is good or bad, wxPython development moves pretty fast and the current Mac version isn't quite up to snuff yet.

  • Ships with TclTkAqua, so Python has a working Tkinter out of the box. Tkinter is also a little weird on Mac OS X, but development of this stuff moves slowly enough, so this was almost definitely a good idea.

  • Tiger pretends to have GNU libreadline, but it's really BSD libedit. Python isn't fooled, so it still ships without readline support.

The packages in pythonmac packages intended for Mac OS X 10.3's Python 2.3.0 are compatible with Tiger's Python 2.3.5, but you must install the TigerPython23Compat package before they will work. This package simply adds a .pth file that adds /Library/Python/2.3 as a site directory.

Using the Python 2.4.1 installer works almost exactly as you'd expect it to on Tiger, with two exceptions:

  • Extensions won't build properly out of the box until you install the TigerPython24Fix package from pythonmac packages, because Apple's headers are anal about POSIX (non-)compliance (rdar:4075943).

  • There's a regression such that at least one of Mac OS X 10.4's math functions gives incorrect results. This effects Python 2.4's float/long comparisons and conversions. This is a pretty serious bug, and I expect it to be fixed in 10.4.1, whenever that is. Python 2.4's test.test_long fails due to this bug.

    Specifically, the bug is caused because modf will return "fractional parts" of >= 1.0 for some input values (rdar:4069461). If you're doing anything important with floating point, I suggest waiting for 10.4.1 or at least verifying your results elsewhere. Off-by-one errors can get out of hand pretty quickly. A really quick test of this bug is:

    >>> 9007199254740991.0 == 9007199254740991L
False

    Obviously not the answer I was hoping for. modf is probably not very commonly used, but it definitely throws up warning flags that they'd cause a regression like this and not have a test suite that reproduces it. As far as I know, I was the first/only person to report this bug. It was reported on March 28th, which I guess was just too late to incorporate a fix.