exception instance call should raise exception
ValueError()() should be the same as raise ValueError() but with an extra call level. and raise should be deprecated.
On Sun, Jul 05, 2020 at 12:48:08AM -0300, Soni L. wrote:
Proposals that are given without justification should be rejected without justification: "No they shouldn't." If you feel like giving reasons for these changes other than "because I, Soni, say so", then I will consider the merits of those reasons before agreeing or disagreeing with the proposal. -- Steven
On 2020-07-05 13:39, Soni L. wrote:
1. saves keywords and 2. can be passed as callables.
since there's no lambda: raise, 2 is a new feature.
How would you re-raise an exception? What would be the replacement for: raise ex from None and so forth? I prefer the clarity of knowing that it's raising an exception and not just calling. Calls usually return.
On Sun, Jul 05, 2020 at 10:10:01AM -0300, Soni L. wrote:
So your plan is to make Python less useful, less powerful, and be unable to do things that it can do now? Sounds great! Not. If you want a callable that raises: def throw(exception, *args): raise exception(*args) func = lambda x: throw(ValueError, 'bad value') if x < 0 else x+1 Problem solved. The best part of this is that this function is 100% backwards compatible all the way back to Python 1.0, and you don't have to wait until Python 3.10 or 3.11 to use it. -- Steven
Your original proposal appears to want this behavior: class BaseException: def __call__(self): raise self That could be expanded to something like: class BaseException: def __call__(self, *args): if not args: raise self if len(args) > 1: TypeError(f"{self} expects at most one argument")() # this adds yet another call level raise self from args[0] @staticmethod def reraise(): raise Why, though? One would usually want to raise the exception at the same call level of the invalid operation, not an extra one. Also, the raise statement makes it clear that something went wrong, and is easily recognized by static code analysers.
On Sun, Jul 05, 2020 at 12:48:08AM -0300, Soni L. wrote:
Proposals that are given without justification should be rejected without justification: "No they shouldn't." If you feel like giving reasons for these changes other than "because I, Soni, say so", then I will consider the merits of those reasons before agreeing or disagreeing with the proposal. -- Steven
On 2020-07-05 13:39, Soni L. wrote:
1. saves keywords and 2. can be passed as callables.
since there's no lambda: raise, 2 is a new feature.
How would you re-raise an exception? What would be the replacement for: raise ex from None and so forth? I prefer the clarity of knowing that it's raising an exception and not just calling. Calls usually return.
On Sun, Jul 05, 2020 at 10:10:01AM -0300, Soni L. wrote:
So your plan is to make Python less useful, less powerful, and be unable to do things that it can do now? Sounds great! Not. If you want a callable that raises: def throw(exception, *args): raise exception(*args) func = lambda x: throw(ValueError, 'bad value') if x < 0 else x+1 Problem solved. The best part of this is that this function is 100% backwards compatible all the way back to Python 1.0, and you don't have to wait until Python 3.10 or 3.11 to use it. -- Steven
Your original proposal appears to want this behavior: class BaseException: def __call__(self): raise self That could be expanded to something like: class BaseException: def __call__(self, *args): if not args: raise self if len(args) > 1: TypeError(f"{self} expects at most one argument")() # this adds yet another call level raise self from args[0] @staticmethod def reraise(): raise Why, though? One would usually want to raise the exception at the same call level of the invalid operation, not an extra one. Also, the raise statement makes it clear that something went wrong, and is easily recognized by static code analysers.
participants (4)
-
MRAB -
Soni L. -
Steven D'Aprano -
Tiago Illipronti Girardi