homepage

On the newly-released macOS Sierra 10.12.5, the default web browser which is meant to returned by webbrowser.get() gives an error. Specifically:
 >>> import webbrowser
 >>> br = webbrowser.get()
 >>> br.open("http://python.org")
 0:33: execution error: "http://python.org" doesn’t understand the "open location" message. (-1708)
 False
 >>> ### but this works
 >>> br = webbrowser.get("safari")
 >>> br.open("http://python.org")
True

A few more details:
 - I believe this worked correctly under previous macOS versions (but I don't currently have access to any such machines). 
 - This behaviour is identical under 3.6.1 and 2.7.13 (untested elsewhere)
 - Behaviour first noticed under Jupyter notebook -- see https://github.com/jupyter/notebook/issues/2438 

The same behaviour also happens under Apple's system Python 2.7.10.
Perhaps this implies a macOS bug or deliberate behaviour change? (I couldn't find anything obviously appropriate in the list of security fixes for 10.12.5.)

changing lines 594 and 623 in webbrowser.py (python 2.7.13) to avoid the broken 'open location' seems to solve the problem in idle .
script = 'do shell script "open %s"' % url.replace('"', '%22')

This seems to be a bug in the `osascript` application in the latest macOS 10.12.5:
$ osascript <<EOF
> open location "http://python.org"
> EOF
0:33: execution error: "http://python.org" doesn’t understand the "open location" message. (-1708)

The same applies for latest build: 
Python 3.7.0a0 (heads/master:128641d17e, May 22 2017, 09:40:08)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)] on darwin
I can try to work on that.

Rudi, Andrew I missed your replaces.
This, indeed, looks like osascript bug. I don't think it's backward incompatible change, especially between 10.12.4 and 10.12.5 which would completely broke default behavior.

We should check whether the osascript regression is fixed in the most recent 10.12.6 Developer Preview and, if not, open a RADAR (Apple bug report).

The alternative to filing a RADAR is to just use the open command instead of osascript (basically what's suggested in msg293950 but directly using subprocess.check_call(["/usr/bin/open", ...]) instead of involving osascript).
For 3.7 it might be useful to drop usage of osascript altogether although that would result in some loss of functionality (/usr/bin/open cannot control if the URL should open in a new window or not).

This indeed appears to be a bug in osascript, the scriptlet still works when using the AppleScript Editor application, which means the AppleScript environment itself and browser scripting support still work.

Yes, it's a weird bug. see http://www.andrewjaffe.net/blog/2017/05/python-bug-hunt.html for more of the story so far.
I have already filed a radar, and I hope this will get fixed at Apple, but it's a bug we need to live with for a while one way or the other.
(For what it's worth, among other things the current implementation relies on the officially deprecated os.popen() which has nothing to do with this problem but I guess this could be taken as an opportunity to change...)

I'll also note that my bug report (radar) has been marked as "DUPLICATE OF 31898264 (OPEN)". So Apple is aware of the bug, and possibly not completely ignoring it. However, the opacity of the system is such that there is no way to get any further information (even though we know the bug number).

FWIW: The bug in osascript is still present in the current 10.12.6 beta (build 16G8c)

Good news! Apple appears to have fixed the osascript regression in the most recent macOS 10.12.6 public beta (version 2). So I'm going to mark this issue as "pending fixed" until the official release of 10.12.6.

There is a potential workaround that could be used so that way macOS 10.12.5 works. It turns out that, with osascript, if you catch the error and try again, it works.
$ osascript <<EOF
> try
> open location "http://apple.com"
> on error
> open location "http://apple.com"
> end try
> EOF

Thanks for the suggestion but, by the time we have released the next maintenance updates for all actively maintained Python versions, 10.12.6 will have long been released and, once it has been, any need to support the broken 10.12.5 release is dead.

10.12.6 is out and the bug appears to be fixed...