On May 1, 2020, at 09:24, Christopher Barker <python...@gmail.com> 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. But the fix was to add a .filename to all of the relevant exceptions, and now it’s great. If you need to be able to get the failing string for int(s) raising a ValueError today, you have to regex .args[0], and that sucks. Do people actually need to do that? If so, there should be a .string or something that carries that information; an .errno won’t help. 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, it’s just that nobody’s ever willing to volunteer to survey every place a builtin or stdlib raises, list them all, and work out exactly what should be changed and where. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CZP5RDQGWAXS4QQ3BHVNRT4VBXVP2Z3Z/ Code of Conduct: http://python.org/psf/codeofconduct/
