This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregcouch
Recipients
Date 2005-10-31.22:01:20
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=131838

Breaking applications that use webbrowser does not help
application writers.  It would be much more useful to me, as
an application writer, if the webbrowser module gave an
error saying it couldn't contact a web browser, rather than
the new behavior of hanging my application.  You have yet to
address this common use case.

Running the webbrowser in the background is a contract that
the webbrowser module can't break and still be called the
webbrowser module.  I agree that the 2.4.2 version is a
practical hack that should be fixed, but the CVS webbrower
almost fixes it while breaking existing applications.  Since
adding an & is so bad (the web browser is already confirmed
to exist and to be executable), the CVS webbrower could be
changed to use the subprocess module instead of os.system,
and the original webbrowser contract could be preserved.  

The wrong display or wrong xhost/xauth permissions are not a
problem because the python GUI application that calls
webbrowser would have failed to start up in the first place
if those problems existed. Starting the web browser in the
background only needs to confirm that the web browser
actually started up.
History
Date User Action Args
2007-08-23 14:35:48adminlinkissue1338995 messages
2007-08-23 14:35:48admincreate