«
»

Upgrading to Snow Leopard Part 5: The Python Gripes


OK, a few gripes. Maybe I’m just being dumb here. If so, please correct me. But I have some serious gripes about the way Python is running on Snow Leopard.

1. Many Carbon routines aren’t part of the 64 bit Python. These aren’t routines that were part of the UI routines that are 32 bit only. (At least I don’t think they are) Thus no Carbon.File, which I use in several scripts (such as my recent alias resolver)

2. Many new 10.6 Cocoa additions that make up for Carbon routines don’t appear to be part of PyObjC. So for example, I can’t appear to get Python + PyObjC to recognize any of the new additions to NSURL. Seriously, tell me if you can get URLByResolvingBookmarkData:options:relativeToURL:bookmarkDataIsStale:error: working.

Maybe I’m just missing something obvious. But I’ve been playing around with this for several days and am getting exceedingly annoyed. The problem is that the old macfs routines were depreciated with the directive to use Carbon.File, which now doesn’t work. But the alternatives don’t work either.

Now you can rebuild Python for 32bit. I’m honestly not at all sure how to run the Apple version as 32 bit.

Edit: A bit of a hack. Apparently Python 2.5 is still part of Snow Leopard (whether by default or just because I upgraded to SL I can’t say). Thus you can run it as 32 bit for those programs requiring Carbon.File until things get updated. Still, quite a pain.

Related posts:

  1. Upgrading to Snow Leopard Part 1: Python
  2. Upgrading to Snow Leopard Part 2: Minor Tips
  3. Upgrading to Snow Leopard Part 4: MySQL
  4. Upgrading to Snow Leopard Part 7: One Month Later
  5. Upgrading to Snow Leopard Part 3: MacPorts
  6. Complaining about Snow Leopard
  7. Upgrading to Snow Leopard Part 6: 64bit vs. 32bit
  8. On Supporting Snow Leopard

This entry was posted on 2009/09/02, 10:41 am and is filed under Python. You can follow any responses to this entry through RSS 2.0. Both comments and pings are currently closed.

  1. #1 by has on 2009/09/03 - 3:31 pm

    Carbon.File contains Carbon FSSpec wrappers, and FSSpec is deprecated in 32-bit and gone in 64-bit. Given that Python’s Carbon modules are 1. of minority interest and 2. deprecated anyway, I’m guessing the simplest path to 64-bit support was taken, i.e. ditch anything that doesn’t build as it is. (I’m surprised that any Python/Mac modules should be included in 64-bit, as the simplest way to do a 64-bit Python build would be to leave the Mac-specific extensions out entirely.)

    As for running in 32-bit, I suspect the only way to do it reliably is by using ‘arch -i386 /path/to/python’, where the path points to the python executable in the Python.app bundle hidden in the Python framework (pointing to /usr/bin/python didn’t work for me, probably as that’s just a stub).

  2. #2 by clark on 2009/09/03 - 3:33 pm

    I personally wouldn’t mind that Carbon.File was removed had the new Cocoa routines replacing Carbon.File been part of the PyObjC install in SL. Right now if you want to manipulate aliases, for instance, you’re out of luck short of calling C.

    As I mentioned in my other post, arch -arch i386 /usr/bin/python worked fine for me. (I just retested in case I was misrecalling)

    BTW – thanks for visiting. I think Appscript is the best thing to happen to Applescripting, although part of me is thinking that for some scripts I may just break down and write in Obj-C + Appscript rather than Python.

  3. #3 by has on 2009/09/04 - 1:19 pm

    > I personally wouldn’t mind that Carbon.File was removed had the new Cocoa routines replacing Carbon.File been part of the PyObjC install in SL. Right now if you want to manipulate aliases, for instance, you’re out of luck short of calling C.

    I don’t know what the situation is with PyObjC – you’d need to ask Ronald about that. If you really need to use Carbon.File functions, consider patching the C source and building it as an independent extension yourself – that’s what I did with the original Carbon.AE module.

    > As I mentioned in my other post, arch -arch i386 /usr/bin/python worked fine for me. (I just retested in case I was misrecalling)

    Try it with a ‘display dialog’ command to the osax module; if it works for you, something’s probably borked at my end.

  4. #4 by clark on 2009/09/05 - 9:46 am

    BTW – I’m getting weird errors on stderr with both the regular appscript module and the osax module. This is with the standard Python build for SL.

    SystemFlippers: didn’t consume all data for psn ID 0 (pBase = 0x1010abaf4, p = 0x1010abafc, pEnd = 0x1010abb04)

    It’s only for some calls but happens quite regularly. This is when I run it from TextMate (which is how I tend to run most of my scripts). Interestingly with the #!/usr/bin/python bang at the top and then run from the shell I get an error:

    Traceback (most recent call last):
    File “get_order.py”, line 7, in
    sa = osax.ScriptingAddition()
    File “build/bdist.macosx-10.6-universal/egg/osax.py”, line 65, in __init__
    NotImplementedError: aem.ae.getappterminology isn’t available in 64-bit processes.

    I just tried using the arch technique and I get the same error.

    If I don’t use the osax module then everything is fine, although I sometimes still get those stderr messages.

  5. #5 by has on 2009/09/08 - 11:34 am

    SystemFlippers: didn’t consume all data for psn ID 0 (pBase = 0×1010abaf4, p = 0×1010abafc, pEnd = 0×1010abb04)

    That’s OS X’s endian twiddling code emitting those warnings. Not entirely sure if it’s due to dodginess in my code or Apple’s, though it seems to be harmless (if irritating).

    I just tried using the arch technique and I get the same error.

    Thought it might. See the workaround described in my first post.

Comments are closed.