Author Hobson.Lane
Recipients Arfrever, Hobson.Lane, Roman.Evstifeev, benjamin.peterson, cvrebert, eric.araujo, ganadist, giampaolo.rodola, larry, pitrou, r.david.murray, rosslagerwall, smarnach, tebeka
Date 2012-05-29.02:18:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CACZ_Doe3V5YcnqeWTN6gqCLtkEAHBiMe2dw=8BpCiq_pZm6rOw@mail.gmail.com>
In-reply-to <1338073216.15.0.878325428161.issue3177@psf.upfronthosting.co.za>
Content
Then they or we can add Konqueror, etc to the options that are 'try'ed for
the 'view' option. Worst case they get a terminal cat of the file instead
of an error message or unintended action (like running a script). What
exactly are you proposing to do when execute is False? That's exactly what
the augmented launch function would do when the "open" or "view" option is
chosen. Anything else for the other options like "edit" or "email" is just
gravy (for application developers targeting the 90% of platforms that we
could easily anticipate).

Gnome/KDE Xdg-open, Android "Share", Windows Open, already do implement
more than we need. Like your "execute" flag, I'm suggesting we bypass all
that unpredictable open() stuff and allow the application developer to
chose what happens when they launch a file. It would allow the app
developer to stay out of the tug-of war between PC manufacturers, OS
manufacturers, and Internet service providers trying to set "preferred
applications" and steering customers to their products.

But clearly you have passion for the boolean execute flag, and you probably
have more experience with python standard libraries than I do, so go for
it. I like your "execute" option. Just thought you'd like to extend it to
include other options. I'm happy with my cross-platform home-rolled
launch() function for my apps that can't afford to leave launch() actions
up to chance.

On Sat, May 26, 2012 at 4:00 PM, Larry Hastings <report@bugs.python.org>wrote:

>
> Larry Hastings <larry@hastings.org> added the comment:
>
> > In Linux we could `try` nautilus then Mozilla
> > (file://.../containing_folder) then fall back to a shell
> > `cd && ls` if no browser is available, raising NotImplemented
> > if all else fails... until someone implements for that
> > user's platform particulars.
>
>  Designing a cross-platform API based on abilities provided by only one of
> those platforms, then waiving your hand and saying , is poor cross-platform
> API design.  OS X is 11 years old, GNOME is 13, KDE is 16, and none of the
> above appear to be in a hurry to add this feature.  And even on Windows,
> which has had this feature for 17 years (IIRC it was introduced with
> Windows 95)... it is hardly ever used.  99.999% of the time you simply want
> to "open" the file using the user's preferred app.
>
> Since Windows users already have an API to access this extra functionality
> on their platform (os.startfile) I assert that the cross-platform API
> should only expose the functionality that's available across platforms.
>  Hence my proposal for "execute".
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3177>
> _______________________________________
>
History
Date User Action Args
2012-05-29 02:18:40Hobson.Lanesetrecipients: + Hobson.Lane, tebeka, pitrou, larry, giampaolo.rodola, benjamin.peterson, eric.araujo, ganadist, Arfrever, r.david.murray, cvrebert, rosslagerwall, smarnach, Roman.Evstifeev
2012-05-29 02:18:39Hobson.Lanelinkissue3177 messages
2012-05-29 02:18:37Hobson.Lanecreate