On May 1, 2020, at 16:32, Steven D'Aprano <st...@pearwood.info> wrote:
>
> 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)
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.
_______________________________________________
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/EESMDX2YO5KAIQQVVSSNKSTKTOYMSNH2/
Code of Conduct: http://python.org/psf/codeofconduct/
