> After reading several web pages and mailing list threads, I've learned
> that the webbrowser module does not really support opening local
> files, even if I use a file:// URL designator. In most cases,
> webbrowser.open() will indeed open the default web browser, but with
> Python 2.6 on my Fedora 10 system, it opens a text editor instead. On
> Python 2.5, it opens the default web browser.
>
> This is a problem because my Python script creates a local HTML file
> and I want it displayed on the web browser.
>
> So is there any way to force webbrowser.open() to always use an actual
> web browser?
I had some discussions with the Python documentation writers that led
to the following note being included in the Python 3.1 library
documentation for webbrowser.open: "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." The discussions suggested that this lack of
support and portability was actually always the case and that the
webbrowser module is simply not meant to handle file URLs. I had taken
advantage of the accidental functionality to generate HTML reports and
open them, as well as to open specific documentation pages from within
a program.
You can control which browser opens the URL by using webbrowser.get to
obtain a controller for a particular browser, specified by its
argument, then call the open method on the controller instead of the
module.
For opening files reliability and the ability to pick a particular
program (browser or otherwise) to open it with you might have to
resort to invoking a command line via subprocess.Popen.
> I had some discussions with the Python documentation writers that led to the
> following note being included in the Python 3.1 library documentation for
> webbrowser.open: "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."
Then they should have renamed the API. I appreciate that they're
finally documenting this, but I still think it's a bunch of baloney.
> You can control which browser opens the URL by using webbrowser.get to
> obtain a controller for a particular browser, specified by its argument,
> then call the open method on the controller instead of the module.
How can I know which controller (application) the system will use when
it opens an http URL? I depend on webbrowser.open('http') to choose
the best web browser on the installed system. Does webbrowser.get()
tell me which application that will be?
> For opening files reliability and the ability to pick a particular program
> (browser or otherwise) to open it with you might have to resort to invoking
> a command line via subprocess.Popen.
But that only works if I know which application to open.
--
Timur Tabi
Linux kernel developer at Freescale
> On Wed, Jan 27, 2010 at 12:29 PM, Mitchell L Model
> <MLM...@comcast.net> wrote:
>
>> I had some discussions with the Python documentation writers that
>> led to the
>> following note being included in the Python 3.1 library
>> documentation for
>> webbrowser.open: "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."
>
> Then they should have renamed the API. I appreciate that they're
> finally documenting this, but I still think it's a bunch of baloney.
I agree, but I am pretty sure that, based on the discussions I had
with the Python
documenters and developers, that there's no hope of winning this
argument.
I suppose that since a file: URL is not, strictly speaking, on the
web, that it
shouldn't be opened with a "web" browser. It's just that the "web"
part of
"web browser" became more or less obsolete a long time ago since there
are so many more ways of using browsers and so many more things they can
do then just browse the web. So if you interpret the name "webbrowser"
to mean
that it browses the web, as opposed to files, which means going
through some
kind of server-based protocol, the module does what it says. But I
still like
the idea of using it to open files, especially when I want the file to
be opened
by its associated application and not a browser.
>
>> You can control which browser opens the URL by using webbrowser.get
>> to
>> obtain a controller for a particular browser, specified by its
>> argument,
>> then call the open method on the controller instead of the module.
>
> How can I know which controller (application) the system will use when
> it opens an http URL? I depend on webbrowser.open('http') to choose
> the best web browser on the installed system. Does webbrowser.get()
> tell me which application that will be?
webbrowser.get() with no arguments gives you the default kind of
browser controller, just as if you had used webbrowser.open()
directly.
>
>> For opening files reliability and the ability to pick a particular
>> program
>> (browser or otherwise) to open it with you might have to resort to
>> invoking
>> a command line via subprocess.Popen.
>
> But that only works if I know which application to open.
Aha. You could use subprocess to specify the application from within
your Python code,
but not to indicate "the user's default browser", unless the platform
has a command for that.
On OS X, for instance, the command line:
open file.html
opens file.html with the application the user has associated with html
files, whereas
open -a safari file.html
will open it with Safari even if the user has chosen Firefox for html
files. There's
stuff like this for Windows, I suppose, but hardly as convenient. And
I think that
Linux environments are all over the place on this, but I'm not sure.
webbrowser.get() returns a control object of the default class for the
user's environment --
the one that means "use the default browser" so it won't help.
But anything with a URL is (or should be regarded as being) on the
Web. It may not be anything more than a local resource and thus have
no universal or common meaning - someone else may not be able to
resolve the URL to a file at all, or it may resolve to a different
file - but it's part of the Web as observed by one party.
Paul