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:
ValueError()() should be the same as raise ValueError() but with an extra call level.
and raise should be deprecated.
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
1. saves keywords and 2. can be passed as callables. since there's no lambda: raise, 2 is a new feature. On 2020-07-05 1:15 a.m., Steven D'Aprano wrote:
On Sun, Jul 05, 2020 at 12:48:08AM -0300, Soni L. wrote:
ValueError()() should be the same as raise ValueError() but with an extra call level.
and raise should be deprecated.
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.
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 2020-07-05 1:15 a.m., Steven D'Aprano wrote:
On Sun, Jul 05, 2020 at 12:48:08AM -0300, Soni L. wrote:
ValueError()() should be the same as raise ValueError() but with an extra call level.
and raise should be deprecated.
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.
On 2020-07-05 10:03 a.m., MRAB wrote:
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?
just call it.
What would be the replacement for:
raise ex from None
and so forth?
no idea. just don't use that anymore?
I prefer the clarity of knowing that it's raising an exception and not just calling. Calls usually return.
On 2020-07-05 1:15 a.m., Steven D'Aprano wrote:
On Sun, Jul 05, 2020 at 12:48:08AM -0300, Soni L. wrote:
ValueError()() should be the same as raise ValueError() but with an > extra call level.
and raise should be deprecated.
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.
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MFNOEE... Code of Conduct: http://python.org/psf/codeofconduct/
On Sun, Jul 05, 2020 at 10:10:01AM -0300, Soni L. wrote:
What would be the replacement for:
raise ex from None
and so forth?
no idea. just don't use that anymore?
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
On 2020-07-05 14:10, Soni L. wrote:
On 2020-07-05 10:03 a.m., MRAB wrote:
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?
just call it.
Wouldn't that just conflate raise with re-raise?
What would be the replacement for:
raise ex from None
and so forth?
no idea. just don't use that anymore?
[snip]
On 2020-07-05 12:58 p.m., MRAB wrote:
On 2020-07-05 14:10, Soni L. wrote:
On 2020-07-05 10:03 a.m., MRAB wrote:
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?
just call it.
Wouldn't that just conflate raise with re-raise?
raise x vs except: raise? just except foo: foo()
What would be the replacement for:
raise ex from None
and so forth?
no idea. just don't use that anymore?
[snip]
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