Don’t import inside of PyObjC actions

Bob Ippolito came to my rescue today. I started using Cheetah for some template work, and it turns out that doing:

from Cheetah.Template import Template

from within your action is bad. (Bus Error bad, not simple exception bad.) So, if you’re using PyObjC, make sure you do your imports at the module level, not in a given block of code.
Update: Bob tracked it down. Don’t import Cheetah inside of an action, because it will import PyObjC’s WebKit (thinking that it’s getting WebWare’s WebKit) and importing PyObjC’s WebKit inside of an action has some issue at present. So, go ahead and do imports wherever you want again, as long as it doesn’t involve WebKit ๐Ÿ™‚

4 thoughts on “Don’t import inside of PyObjC actions”

  1. Note that this does work in every other case I’ve ever seen. I suspect that some of the “deep hacks” in Cheetah and/or bugs in Python cause this.. but I haven’t fully diagnosed it yet.

  2. I have traced the problem. It is a two-parter:

    (1) There is a module namespace conflict:
    WebWare has a package named WebKit
    PyObjC has a package named WebKit

    (2) Cheetah.Servlet checks to see if WebWare’s WebKit is available, and ends up importing PyObjC’s WebKit.

    (3) For whatever reason, it is not safe to import the WebKit wrapper from inside of an action (unless it’s already imported, of course).

    So apparently it’s more or less undefined behavior if you have both WebWare and PyObjC installed! Fun ๐Ÿ™‚

  3. but each class have it’s module name. even if you overwrite WebWare module (class) with PyObjC one, they will never be the same type, with same module name.

  4. Clearly you don’t understand what I meant.

    WebKit is a top level Python package in WebWare
    WebKit is a top level Python package in PyObjC

    “import WebKit” can ONLY import one or the other, if both are installed. It’s ambiguous as to which comes first on sys.path (depends on the order pth files were iterated, presumably).

    This is a problem.

Comments are closed.