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?

@David,

`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`
consequences.

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
same?

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).

@Chris,

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 <report@bugs.python.org>wrote:

>
> R. David Murray <rdmurray@bitdance.com> 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 webbrowser.open(), which makes it clear you
> are opening it in the webbrowser (and opening the webbrowser if needed).
>  shutil.open 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 <report@bugs.python.org>
> <http://bugs.python.org/issue3177>
> _______________________________________
>