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 <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/NE443NATMWLVZK2QS5BO6EM3DDDPXL2D/
Code of Conduct: http://python.org/psf/codeofconduct/
