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 pboddie
Date 2005-09-23.16:30:52
SpamBayes Score
Marked as misclassified
Currently, in Python's standard library, there is   
apparently no coherent, cross-platform way of getting   
the user's environment to "open" files or resources   
(ie. show such files in browsers, editors) when   
requested by a Python program. There is an   
os.startfile function which works for Windows, but no   
equivalent function for other desktop environments -   
the webbrowser module seems to employ alternative   
mechanisms in choosing and running external   
programs and presumably does not seek to provide   
general support for non-URL resources anyway.  
Since desktop environments like KDE and GNOME   
provide mechanisms for running browsers and editors   
according to the identified type of a file or resource,   
just as Windows "runs" files or resources, it is   
appropriate to have a module which accesses these   
mechanisms. Attached is a simple module which   
seeks to support KDE, GNOME and Windows - the   
latter using the existing os.startfile support - and   
which could be extended to support other desktop   
environments such as Mac OS X, XFCE, CDE (along   
with others deemed important and feasible enough to   
Note that this approach is arguably better than that   
employed by the webbrowser module since most   
desktop environments already provide mechanisms   
for configuring and choosing the user's preferred   
programs for various activities, whereas the   
webbrowser module makes relatively uninformed   
guesses (eg. opening Firefox on a KDE desktop   
configured to use Konqueror as the default browser).   
Note also that the startfile function is arguably   
misplaced in the os module; thus, this functionality is   
supplied as a new module rather than as a patch to   
the os module, and the name of the function is  
"open" (like in the webbrowser module) rather than  
"startfile" which is a fairly Windows specific term. One 
could also envisage the desktop module residing 
within the os package to avoid top-level namespace 
Recent discussion in the comp.lang.python thread  
"Open PDF" covering this issue can   
be found here:  
Date User Action Args
2007-08-23 15:43:59adminlinkissue1301512 messages
2007-08-23 15:43:59admincreate