On Fri, May 01, 2020 at 06:59:01PM -0700, Andrew Barnert wrote:
> >> 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)
That's not a very convincing example, because surely if you are logging
the error, or reporting it to the user, you need the entire error
message. As a user, what am I to make of this?
/tmp/z
when you could show me this instead?
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/z'
I might also argue that this is a poorly designed parse_config function
for many reasons, but it's obvious to me that you intended it as only a
toy example to match my toy example, not real-world code.
But that's the thing, there are many things which seem compelling when
you only look at toy examples, but in real-world code they become less
useful. For example, in a real-world config system, you probably have
"read_config" try a series of multiple file names, in some specified
order, rather than fail, and the config function itself logs the errors
if you need them logged. Even if none of them are available, you ought
to return default settings rather than fail.
(I've used applications that die if a config file isn't readable, and
they are horrible to use. But I digress.)
In the standard library, my quick and dirty grep has found a few uses
for err.filename in the stdlib:
- ten cases testing that it is set correctly;
- one place where it appears to be copied from one exception to another;
and unless I've missed anything, that's it. Take from that what you
will.
So in the spirit of always being open to learning something new, have
you personally used the err.filename attribute, and if so, under what
circumstances was it useful to you?
[...]
> At any rate, it’s a bit silly to relitigate this change.
Was that what I was doing? Whew, thank goodness you told me, now I can
cancel the PEP I was writing to deprecate and remove that feature!
*wink*
But seriously... unless it is your position that every functional change
made to the language and stdlib is by definition optimal, and therefore
beyond question, I don't think it is "silly" to revist a change made a
decade ago and see whether it actually turned out to be as useful as we
hoped, *before* using that change as an example of a successful language
feature that ought to be copied.
YAGNI is a genuine principle, and I cannot tell you how many times I've
started custom exceptions and loaded them up with information that I
surely would need to extract programmatically, only to discover that all
I really needed was to read the error message. So please forgive me if
I'm a bit cautious about the suggestion that we must load exceptions up
with more information.
> 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.
Since the filename attribute can be None, you still have to deal with
the case where the filename is missing. (Even if it is rarer than it
used to be.)
> 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.
Since I've never been in a position where I needed to extract the file
name from an exception, at least not as far as I can remember, I don't
think I would care if it was missing or not. YMMV.
> >> 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 every obscure OS error should be given its own exception. It is good
that the most common ones have been, like FileNotFoundError, but for
rarer and more exotic exceptions, it isn't worth the bloat of adding 50
exception subclasses which most people will never experience in their
entire lifetime. So for those, a standard errno works great and I don't
think it is a problem to be fixed.
In fact, I don't think it was a problem as such, it is just that
separate exceptions for common failures was *even better*.
> 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.
I'm not commenting on Ram's proposal here. I'm commenting on the
subthread where Christopher proposed a central registry of error
numbers.
If you take Christopher's proposal as one of those suggestions to "fix
all the exceptions to be reasonably distinguishable and to make their
relevant information more accessible" (your words), as I did, then I am
explicitly disagreeing with your comment than nobody has ever had a
problem with that.
"Make exceptions better" is one of those over-generic feel-good things
that everyone can agree on. Who would want them to be worse? But when
you get down to details, if the way we make exceptions "reasonably
distinguishable" is with a central registry of error numbers, then I
need to be convinced that it is (1) useful and (2) workable in practice.
Hmmm... maybe it could be workable... let me think about that...
--
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/34YXJWU5WWU43QHZX3NEZPLZTT4PLKOS/
Code of Conduct: http://python.org/psf/codeofconduct/
