[Python-ideas] Arguments to exceptions

Paul Moore p.f.moore at gmail.com
Thu Jul 6 05:58:43 EDT 2017

On 6 July 2017 at 02:53, Jeff Walker <jeff.walker00 at yandex.com> wrote:
> Could you please expand on these statements:
>>  the idea doesn't actually solve the problem it is intended to
> Specifically Ken started by saying that it should not be necessary to parse the
> messages to get the components of the message. He then gave an example
> where he was able to access the components of the message without parsing
> the message. So how is it that he is not solving the problem he intended to solve?

Just to add my perspective here, his proposed solution (to modify
BaseException) doesn't include any changes to the derived exceptions
that would need to store the components. To use the (already
over-used) NameError example, Ken's proposal doesn't include any
change to how NameError exceptions are raised to store the name
separately on the exception.

So *as the proposal stands* it doesn't allow users to extract
components of any exceptions, simply because the proposal doesn't
suggest changing exceptions to *store* those components.

>>  His solution can't work
> Again, he gave an example where he was able to access the components of the
> message without parsing the message. Yet you claim his solution cannot work.
> Is his example wrong?

Yes. Because he tries to extract the name component of a NameError,
and yet that component isn't stored anywhere - under his proposal or
under current CPython.

>>  He hasn't demonstrated that there is a real problem
> You yourself admitted that parsing a message to extract the components is
> undesirable. Ken and others, including myself, gave examples where this was
> necessary. Each example was given as either being a real problem or
> representative of a real problem. Are we all wrong?

He's given examples of use cases. To that extent, Steven is being a
touch absolute here. However, there has been some debate over whether
those examples are valid. We've had multiple responses pointing out
that the code examples aren't restricting what's in the try block
sufficiently tightly, for example (the NameError case in particular
was importing a file which, according to Ken himself, had potentially
*thousands* of places where NameError could be raised). It's possible
that introspecting exceptions is the right way to design a solution to
this particular problem, but it does go against the normal design
principles that have been discussed on this list and elsewhere many
times. So, to demonstrate that there's a problem, it's necessary to
address the question of whether the code could in fact have been
written in a different manner that avoided the claimed problem.

That's obviously not a black and white situation - making it easier to
write code in a certain style is a valid reason for suggesting an
enhancement - but the debate has edged towards a stance of "this is
needed" (as in, the lack of it is an issue) rather than "this would be
an improvement". That's not what Ken said, though, and we all bear a
certain responsibility for becoming a little too entrenched in our

As far as whether Steven's (or anyone's) comments are too negative, I
think the pushback is reasonable. In particular, as far as I know Ken
is not a first-time contributor here, so he's almost certainly aware
of the sorts of concerns that come up in discussions like this, and
with that context I doubt he's offended by the reception his idea got
(indeed, his responses on this thread have been perfectly sensible and
positive). I do think we need to be more sensitive with newcomers, and
Chris Angelico's idea of a "falsehoods programmers believe about
python-ideas" collection may well be a good resource to gently remind
newcomers of some of the parameters of discussion around here.

You also say
> but it can be fun and educational to discuss the ideas

Indeed, very much so. I've certainly learned a lot about language and
API design from discussions here over the years. But again, that's the
point - the biggest things I've learned are about how *hard* good
design is, and how important it is to think beyond your own personal
requirements. Most of the "negative" comments I've seen on this list
have been along those lines - reminding people that there's a much
wider impact for their proposals, and that benefits need to be a lot
more compelling than you originally thought. That's daunting, and
often discouraging (plenty of times, I've been frustrated by the fact
that proposals that seem good to be are blocked by the risk that
someone might have built their whole business around a corner case
that I'd never thought of, or cared about). But it's the reality and
it's an immensely valuable lesson to learn (IMO).


More information about the Python-ideas mailing list