On 3 July 2017 at 20:46, Jeff Walker <jeff.walke...@yandex.com> wrote: > I think you are fixating too much on Ken's example. I think I understand > what he > is saying and I agree with him. It is a problem I struggle with routinely. It > occurs in > the following situations:
Possibly. I hadn't reread the original email. Having done so, I'm confused as to how the proposal and the example are related. The proposal makes no difference unless the places where (for example) NameError are raised are changed. But the proposal doesn't suggest changing how the interpreter raises NameError. So how will the proposal make a difference? I'd understood from the example that Ken's need was to be able to find the name that triggered the NameError. His proposal doesn't do that (unless we are talking about user-raised NameError exceptions, as opposed to ones the interpreter raises - in which case why not just use a user-defined exception? So I'm -1 on his proposal, as I don't see anything in it that couldn't be done in user code for user-defined exceptions, and there's nothing in the proposal suggesting a change in how interpreter-raised exceptions are created. > 1. You are handling an exception that you are not raising. This could be > because > Python itself is raising the exception, as in Ken's example, or it could > be raised > by some package you did not write. > 2. You need to process or transform the message in some way. Then yes, you need to know the API presented by the exception. Projects (and the core interpreter) are not particularly good at documenting (or designing) the API for their exceptions, but that doesn't alter the fact that exceptions are user-defined classes and as such do have an API. I'd be OK with arguments that the API of built in exceptions as raised by the interpreter could be improved. Indeed, I thought that was Ken's proposal. But his proposal seems to be that if we add a ___str__ method to BaseException, that will somehow automatically improve the API of all other exceptions. To quote Ken: > However, if more than one argument is passed, you get the string > representation > of the tuple containing all the arguments: > > >>> try: > ... raise Exception('Hey there!', 'Something went wrong.') > ... except Exception as e: > ... print(str(e)) > ('Hey there!', 'Something went wrong.') > > That behavior does not seem very useful, and I believe it leads to people > passing only one argument to their exceptions. Alternatively, I could argue that code which uses print(str(e)) as its exception handling isn't very well written, and the fact that people do this is what leads to people passing only one argument to their exceptions when creating them. Look, I see that there might be something that could be improved here. But I don't see an explanation of how, if we implement just the proposed change to BaseException, the user code that Ken's quoting as having a problem could be improved. There seems to be an assumption of "and because of that change, people raising exceptions would change what they do". Frankly, no they wouldn't. There's no demonstrated benefit for them, and they'd have to maintain a mess of backward compatibility code. So why would they bother? Anyway, you were right that I'd replied to just the example, not the original proposal. I apologise for that, I should have read the thread more carefully. But if I had done so, it wouldn't have made much difference - I still don't see a justification for the proposed change. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/