This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author cvrebert
Recipients Arfrever, Roman.Evstifeev, benjamin.peterson, cool-RR, cvrebert, eric.araujo, ganadist, giampaolo.rodola, rosslagerwall, vstinner
Date 2012-04-01.06:31:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
>> (2) Target file doesn't exist
>> (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)

It runs counter to the goal of a cross-platform API if *all* the errors are platform-specific. I grant that a generic API cannot wrap *every* possible error, but (2) and (4) are amongst the most common+obvious failure modes and are (FWICT) explicitly reported by all 3 native interfaces. If we don't consolidate them, we'll basically be condemning non-trivial users to copying (or writing themselves, probably inferiorly) a chunk of boilerplate recipe code, and if we're fine with that, then why bother having (this in) the std lib at all?

I don't think the handling code for them would be particularly fragile/onerous; we're talking a mere ~2 constants per platform, all tied to pretty-unlikely-to-change native interfaces. For context, here would be (AFAICT; I only have a Mac ATM) the constants in question:

Windows: function return value:

xdg-open (*nix): exit code:

Mac OS X: exit code 1 w/ stderr output:
"The file XXX does not exist."
"No application knows how to open XXX."
Date User Action Args
2012-04-01 06:31:36cvrebertsetrecipients: + cvrebert, vstinner, giampaolo.rodola, benjamin.peterson, eric.araujo, ganadist, Arfrever, cool-RR, rosslagerwall, Roman.Evstifeev
2012-04-01 06:31:36cvrebertsetmessageid: <>
2012-04-01 06:31:35cvrebertlinkissue3177 messages
2012-04-01 06:31:34cvrebertcreate