Fun indeed. Given that I'm not using WebWare, it would most definitely be picking up PyObjC's WebKit. Maybe there's something to be said for Java's package naming conventions :)

The py2app issue I was having was far less exciting. Cheetah seems to like dumping templates into /tmp and it drops in an __init__.py to pretend that /tmp is a package, and then imports from that package. It seems like there's gotta be a better way. Something to investigate tomorrow...

I wouldn't expect you to add Cheetah-specific stuff to py2app. It shouldn't need to do anything *that* magical. What I like about Cheetah is that it's concise (unlike TAL), is pleasant to work with (subjective to be sure, but I don't like ClearSilver's syntax), is reasonably performant, and strikes a nice balance between functionality and separation of concerns.

With the sleuthing you've done, I should be able to come up with something that works well for my needs.

Kevin

Bob Ippolito wrote:


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). Now this issue I will have to look further into.

---
So apparently it's more or less undefined behavior if you have both WebWare and PyObjC installed! Fun :)


-bob





_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to