homepage

>> [...] 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.