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 Hobson.Lane
Recipients Arfrever, Hobson.Lane, Roman.Evstifeev, benjamin.peterson, cvrebert, eric.araujo, ganadist, giampaolo.rodola, pitrou, r.david.murray, rosslagerwall, vstinner
Date 2012-04-23.15:25:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Does no one like "os.startfile" as a home for this? Besides myself and the
original 2008 proposer, of course. Can anyone explain to us newbies why
it's a bad idea to have the cross-platform module do things identically
across platforms?


`shutils.wmopen` locks you into never implementing the shell application
launching option (`gui`=False in my crude implementation) that so many
projects need. Each project currently implements it in their own
nonstandard way (e.g. Mercurial and Bazaar), sometimes with not so `nice`

You're right that only launching from Linux/Mac shell requires manual
selection of an app, but that's exactly the inconvenience that I was hoping
to solve. Many Ubuntu GUI apps use extensions and MIME-types (associated
with extensions) to recognize their files rather than probing magic
headers. Why shouldn't their shell apps be allowed a standard way to do the

If I implemented *exactly* os.startfile() functionality across the 3 major
platforms, would that be enough to interest the community in an
os.startfile() refinement rather than a new shutils.launch()? I'd drop the
distracting `gui` option to make it completely identical, if that helps.
Or, if the community preferred I could *add* the `gui` option to
startfile() across the board so that even Windows users could have the
option of choosing to edit a file within their shell (if they've installed
such an editor, of course).


Thanks for the tip on where to find low level exception information in
Windows. Sounds like a good idea to try to be as identical to
os.startfile() as possible. But that's why I thought the `operation` option
would be attractive to the community.

I'll test on windows (unless someone else chimes in with Windows
experience) and see what I can learn about exceptions and what it would
take to make os.startfile() truly OS-agnostic, all the way down to each
exception raised.

`gui` allows the user to chose to launch a shell-based text editor (emacs,
vi/vim, nano, $EDITOR, based on user settings). It standardizes what bzr,
hg and other popular cross-platform python projects that launch shell
editors do already.

On Mon, Apr 23, 2012 at 10:12 PM, R. David Murray <>wrote:

> R. David Murray <> added the comment:
> Launch is far better than open for this, I think.  If someone can come up
> with an even better name, that would be good.  But I would not like to use
> open for this function, because it does not behave like other open
> functions.
> The one exception I know of is webbrowser.  Webbrowser uses open, but the
> recommended way to call it is, which makes it clear you
> are opening it in the webbrowser (and opening the webbrowser if needed).
> would convey no such connotation, to my mind.  (Only windows
> does extension based application opening from the *shell* as far as I know.)
> Perhaps 'wmopen' (for Window Manager Open)?
> ----------
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2012-04-23 15:25:01Hobson.Lanesetrecipients: + Hobson.Lane, pitrou, vstinner, giampaolo.rodola, benjamin.peterson, eric.araujo, ganadist, Arfrever, r.david.murray, cvrebert, rosslagerwall, Roman.Evstifeev
2012-04-23 15:25:01Hobson.Lanelinkissue3177 messages
2012-04-23 15:25:00Hobson.Lanecreate