Éric Araujo <mer...@netwok.org> added the comment: >> [...] 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.
You are right, I was confusing the layers! Good then. > So, the failure cases are: > (1) Platform doesn't support this feature -> raise NotImplemented Actually the exception is NotImplementedError. Its doc says that it’s to be used in a method that is intended to be overriden in subclasses, but I think it’s not wrong to > (2) Target file doesn't exist > (3) Target file is inaccessible > (4) No application is associated with the file type in question I think that instead of mapping error codes to custom exceptions, which is fragile and not trivial to maintain, we should just catch stderr and raise something like OSError(stderr). [Victor] >> It's better to not define the function if the platform doesn't support the >> feature. That’s easy to do if we can say detect the availability of a function in the libc, but here the function would depend on a program which could get removed or added between two calls to the function, so we have no choice. ---------- dependencies: -Finding programs in PATH, adding shutil.which _______________________________________ 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
