report at bugs
Apr 23, 2012, 8:25 AM
Post #14 of 36
Hobs <hobsonlane [at] gmail> added the comment:
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
`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
`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 [at] bugs>wrote:
> R. David Murray <rdmurray [at] bitdance> 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
> 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 [at] bugs>
Python tracker <report [at] bugs>
Python-bugs-list mailing list