On 2020-04-11 10:46 a.m., Eric V. Smith wrote:
On 4/11/2020 9:38 AM, Soni L. wrote:

On 2020-04-11 10:27 a.m., Eric V. Smith wrote:
tl;dr: I show how the goal of Soni L's exception spaces can be addressed today, via less intrusive means. (Assuming I understand their proposal, that is.)

what's the point of having standard types if you're not supposed to use them because they mask bugs?

what if you end up with a nested call to your own library and catch it at the wrong place? (or, indeed, someone else also uses this technique but somewhere along the way a built-in exception is being caught)

you're just delaying the issue/shifting it around, instead of solving it once and for all.

You show no examples where your proposal addresses those issues but mine doesn't.

Your responses sound like the only thing you're interested in is having your proposal accepted, not in the problem that needs to be solved. The fact that you don't address some of my points (for example: changes to intermediate libraries, which your proposal requires) just reinforces this impression. As such, I'm going to drop out of this discussion.

yes, I absolutely do want my proposal accepted. I'd think anyone coming up with a proposal would want that. but that's not the point I'm trying to make.

in current python, you can't safely handle exceptions, *because* of the remote chance of them being raised *by the wrong thing/for the wrong reason*.

rust doesn't have that problem, as it effectively forces you to handle exceptions all the time, and is constantly wrapping and unwrapping exceptions in exceptions and whatnot.

I'm not saying rust has the best solution. I don't like how it's so explicit about error handling. sometimes letting it bubble up is great. but rust doesn't have the problem of exception handling being inherently dangerous, context-sensitive, and destructive to application logic. python's exception handling is effectively a form of dynamic scoping, as defined by wikipedia: "In some languages, however, "part of a program" refers to "portion of run time (time period during execution)", and is known as dynamic scope.".

this is the whole problem.

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/L5UDJMCLMQGPPSGK3OY65OJ3GFYIZI2T/
Code of Conduct: http://python.org/psf/codeofconduct/