Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #20870 > unrolled thread

webbrowser.open always opens up Safari on Lion

Back to article view | Back to comp.lang.python

Contents

  webbrowser.open always opens up Safari on Lion Leo <sdl.web@gmail.com> - 2012-02-26 09:33 +0800
    Re: webbrowser.open always opens up Safari on Lion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-26 03:36 +0000
      Re: webbrowser.open always opens up Safari on Lion Leo <sdl.web@gmail.com> - 2012-02-26 14:23 +0800
        Re: webbrowser.open always opens up Safari on Lion Cameron Simpson <cs@zip.com.au> - 2012-02-26 18:04 +1100
          Re: webbrowser.open always opens up Safari on Lion Leo <sdl.web@gmail.com> - 2012-02-26 15:29 +0800
        Re: webbrowser.open always opens up Safari on Lion Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-26 07:12 +0000

#20870 — webbrowser.open always opens up Safari on Lion

Hello,

On Lion and with its stock python version 2.7.1 r271:86832,
webbrowser.open('file://localhost/nonexistingfile') always opens up
Safari. Is this a bug?

Leo

[toc] | [next] | [standalone]

#20872

On Sun, 26 Feb 2012 09:33:15 +0800, Leo wrote:

> Hello,
> 
> On Lion and with its stock python version 2.7.1 r271:86832,
> webbrowser.open('file://localhost/nonexistingfile') always opens up
> Safari. Is this a bug?

What part of this do you think is the bug, and why? What part of the 
behaviour actually experienced contradicts the documented behaviour of 
webbrowser.open()?

http://docs.python.org/library/webbrowser.html

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#20874

On 2012-02-26 11:36 +0800, Steven D'Aprano wrote:
> What part of this do you think is the bug, and why? What part of the 
> behaviour actually experienced contradicts the documented behaviour of 
> webbrowser.open()?
>
> http://docs.python.org/library/webbrowser.html

If you have the default browser set to Chrome, it still opens up Safari.

Leo

[toc] | [prev] | [next] | [standalone]

#20875

On 26Feb2012 14:23, Leo <sdl.web@gmail.com> wrote:
| On 2012-02-26 11:36 +0800, Steven D'Aprano wrote:
| > What part of this do you think is the bug, and why? What part of the 
| > behaviour actually experienced contradicts the documented behaviour of 
| > webbrowser.open()?
| >
| > http://docs.python.org/library/webbrowser.html
| 
| If you have the default browser set to Chrome, it still opens up Safari.

On the suppostion that "the default browser" is actually multiple
settings, one for each of several URL (URI?) schemes, what do these two
shell commands do for you? From a shell prompt in a Terminal:

  open file://localhost/nonexistingfile
and 
  open http://www.python.org/

Do they both open Chome for you?
-- 
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

DRM doesn't inconvenience pirates ¿ indeed, over time it trains
law-abiding users to become pirates out of sheer frustration.
- Charles Stross

[toc] | [prev] | [next] | [standalone]

#20877

On 2012-02-26 15:04 +0800, Cameron Simpson wrote:
> On the suppostion that "the default browser" is actually multiple
> settings, one for each of several URL (URI?) schemes, what do these two
> shell commands do for you? From a shell prompt in a Terminal:
>
>   open file://localhost/nonexistingfile
> and 
>   open http://www.python.org/
>
> Do they both open Chome for you?

The first one prints: The file /nonexistingfile does not exist.
No browser is opened.

The second one opened Chrome.

Leo

[toc] | [prev] | [next] | [standalone]

#20876

On Sun, 26 Feb 2012 14:23:43 +0800, Leo wrote:

> On 2012-02-26 11:36 +0800, Steven D'Aprano wrote:
>> What part of this do you think is the bug, and why? What part of the
>> behaviour actually experienced contradicts the documented behaviour of
>> webbrowser.open()?
>>
>> http://docs.python.org/library/webbrowser.html
> 
> If you have the default browser set to Chrome, it still opens up Safari.


That would only be a bug if it occurs with http:// URLs. The 
documentation clearly says:

    Note that on some platforms, trying to open a filename using 
    this function, may work and start the operating system’s associated
    program. However, this is neither supported nor portable.


Since you are providing a file:// URL, then the behaviour is unspecified, 
and no, it is not a bug. Arguably it is a bug that file:// URLs work at 
all.

However, I would guess that if you have a patch to fix this behaviour to 
something more reasonable (but what?) then it might be approved.

Feel free to raise a ticket on the bug tracker. Personally, I'd put it 
down as a feature request rather than a bug.



-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web