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 <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.
Why would you parse the error message when you already have the file name? try: f = open(filename) except IOError as err: print(filename) I'm trying to think of a case where you might be making a call to open but you don't know the filename. I thought it might be if you pass a file descriptor, but in that case the filename attribute seems to be set to None. > 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. When I want to raise something in the stdlib, I just raise: # let's say I add a kurtosis function raise StatisticsError('not enough data points for kurtosis') Under Christopher's proposal, I have to: * look up the central registry; * find the next ID unused number; * register it to my library and error message; * use the relevent errno and the same error message in my code: # something like this? raise StatisticsError('not enough data points for kurtosis', errno=926361) and while I'm doing that, one of the faster and more productive core devs have come along and used that errno before I could merge my patch, so now I have to change the errno. And then if I decide to improve the error message, what now? Do I have to register a new errno? What if the error message is variable? Expected at least 4 data points, but got 2. And the benefit of this is ... what? I'd like to see the real-world concrete benefit that couldn't be more easily accomplished by using a separate try...except around *only* the call to kurtosis: try: k = kurtosis(data) except StatisticsError: # This can only mean one thing: not enough data. k = None I'm sorry to anyone who likes to use a single try around many computations: try: xm = mean(ydata) ym = mean(ydata) xsd = stdev(xdata) ysd = stdev(ydata) except StatisticsError as err: # How do I distinguish which call failed? but supporting that is not something I'm prepared to do until either I need that functionality myself or somebody provides a really compelling use-case, not just "it would be cool if..." :-) -- Steven _______________________________________________ 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/NE443NATMWLVZK2QS5BO6EM3DDDPXL2D/ Code of Conduct: http://python.org/psf/codeofconduct/