On Sun, Apr 12, 2020 at 1:37 AM Soni L. fakedme+py@gmail.com wrote:
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.
You can't add 0.5 to a Python integers, because there's a remote chance that you'll get OverflowError trying to convert it to float. Some other language, in which all integers are signed 32-bit values, doesn't have this problem, as it effectively forces you to handle overflows all the time. Is that better than Python?
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.
You haven't yet proven that this is a problem. You haven't demonstrated that your solution is, in any way, better than simply subclassing the exceptions. Your proposal requires that every level in the call stack explicitly handle exception scoping and that every exception raising site magically know whether to scope the exception or not; Python *already* allows the raise site to choose to use a subclass of the exception type, which is a far more useful mechanism.
Your proposal is heavy on magic and very light on actually-usable recommendations.
I'm done here.
ChrisA