Hobs <hobsonl...@gmail.com> 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 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 <rep...@bugs.python.org>wrote: > > R. David Murray <rdmur...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue3177> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3177> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
