On May 1, 2020, at 16:32, Steven D'Aprano
On Fri, May 01, 2020 at 12:28:02PM -0700, Andrew Barnert via Python-ideas wrote:
On May 1, 2020, at 09:24, Christopher Barker
wrote: Maybe it's too late for this, but I would love it if ".errno or similar" were more standardized. As it is, every exception may have it's own way to find out more about exactly what caused it, and often you are left with parsing the message if you really want to know. I don’t think there are many cases where a standardized .errno would help—and I think most such cases would be better served by separate exceptions. With OSError, errno was a problem to be fixed, not an ideal solution to emulate everywhere. You do often need to be able to get more information, and that is a problem, but I think it usually needs to be specific to each exception, not something generic. Does code often need to distinguish between an unpacking error and an int parsing error? If so, you should be able to handle UnpackingError and IntParsingError, not handle ValueError and check an .errno against some set of dozens of new builtin int constants. If not, then we shouldn’t change anything at all. As for parsing the error message, that usually comes up because there’s auxiliary information that you need but that isn’t accessible. For example, in 2.x, to get the filename that failed to open, you had to regex .args[0], and that sucked. Why would you parse the error message when you already have the file name?
try: f = open(filename) except IOError as err: print(filename)
try: config = parse_config() except IOError as err: print(filename) You can’t get the local variable out of some other function that you called, even with frame hacking. At any rate, it’s a bit silly to relitigate this change. All of the new IOError subclasses where a filename is relevant have had a filename attribute since 3.0, so this problem has been solved for over a decade. If you really prefer the 2.x situation where sometimes those exception instances had the filename and sometimes not, you’ll need a time machine.
It seems like every year or two, someone suggests that we should go through the stdlib and fix all the exceptions to be reasonably distinguishable and to make their relevant information more accessible, and I don’t think anyone ever has a problem with that,
I do!
Christopher's proposal of a central registry of error numbers and standardised error messages just adds a lot more work to every core developer for negligible or zero actual real world benefit.
You’re replying to a message saying “errno was a problem to be fixed, not an ideal solution to emulate” and likewise having to parse errors. And you’re insisting that you disagree because adding errno and standardizing messages so they could be parsed would be a problem for maintainers as well as for users. Sure, you’re right, but that’s not in any way an argument against Ram’s proposal, or against the paragraph you quoted; if anything, it’s an argument *for* it.