On 6 July 2017 at 02:53, Jeff Walker <jeff.walker00@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 positions. 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). Paul