Allows webbrowser.open call in the Unix version of python running on Mac OS X to open a url in Internet Explorer.  Presently, a call to webbrowser.open on this platform either runs a terminal-based browser, such as lynx, if available, or fails.

The patch is a context diff against version 1.27 of webbrowser, which appears to be the latest version in CVS.  It adds a MacOSX browser class and a test for Mac OS X systems running the Unix version of python.  I have tested it successfully several times on my Mac OS X system.

I included:

    assert url not in "'"

from the 1.27 version in the MacOSX open method, even though the method calls os.popen rather than os.system to launch the browser.  It seemed likely os.popen would raise similar security concerns.

Logged In: YES 
user_id=322368

I have submitted a new patch which adds the following functionality:
-Uses default browser selected in System Preferences if no browser specified.
-Allows user to choose any of the following installed browsers:  OmniWeb, iCab, Netscape, Opera, Internet Explorer, links, lynx, w3m.
-Tests for OS X running without window server as well as Darwin without OS X.  (Note that even without this test, use of the module without the window server did not crash Python, but instead generated the following error message:  "KCGErrorFailure:  initCGDisplayState: No display interlock.")
-Opens url in new window with open_new function or method, if the browser supports this behavior.
-Adds support for the Unix Dillo browser.

Logged In: YES 
user_id=45365

Steven,
there's a few problems with your patch that I'd like you to fix before I check it in (or convince me:-):
- There's references to dillo that seem unrelated, could you take them out?
- I'm not sure your code correctly handles the case of the Internet Config module being available on OSX. Does it?
- The trick with running ps to see whether the finder is there is only half a solution (the finder may be running but you may still not have access to the window manager, for instance when you're ssh'd to someone else's machine) and it's expensive and error prone too. How about trying to send a noop appleevent to the finder and seeing whether that works?
- You can probably get rid of the KCGErrorFailure messages by adding a 2>/dev/null the the applescript command.

Logged In: YES 
user_id=45365

Steven,
I asked for clarification on various things in your patch on Feb 6, but you haven't replied yet, and I don't want to accept the patch as-is. I've set the state of the patch to "pending", so you now have 14 days to reply if you feel like doing so (otherwise sourceforge will close the patch).