Message157216
| Author |
cvrebert |
| Recipients |
Roman.Evstifeev, benjamin.peterson, cool-RR, cvrebert, eric.araujo, ganadist, giampaolo.rodola, rosslagerwall, vstinner |
| Date |
2012年03月31日.17:51:04 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1333216265.49.0.971968767396.issue3177@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> The alternative is to call Popen(['xdg-open', etc.]) and check if we get ENOENT, but I don’t know if this would be non-ambiguous (for example, do we get ENOENT if xdg-open exists but not the file?).
It's unambiguous. Python itself never opens the target file, it just passes the filepath string along to the xdg-open command. If Popen raises EnvironmentError, then xdg-open could not be executed. If the target file is nonexistent, then xdg-open will exit with status 2 (see aforelinked manpage). Entirely different error mechanisms.
> A related question: what to do when we’re not on Windows nor Mac and xdg-open doesn’t exist? Raise NotImplemented?
Seems reasonable to me.
So, the failure cases are:
(1) Platform doesn't support this feature -> raise NotImplemented
(2) Target file doesn't exist
(3) Target file is inaccessible
(4) No application is associated with the file type in question
OS X and xdg-open report (2) and (4), does Windows?
OS X reports (3) indirectly/vaguely [generic exit status 1 w/ possibly unstable error message]; don't know what Windows and xdg-open do here. |
|