Re: raise None

On Monday, January 4, 2016 at 11:23:24 AM UTC+5:30, Rustom Mody wrote: > On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > > > If I could have the traceback continue into the C code and tell me the > > > line of C

Re: raise None

On Mon, Jan 4, 2016 at 2:48 PM, Steven D'Aprano wrote: > On Mon, 4 Jan 2016 02:31 pm, Chris Angelico wrote: > >> On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: >>> On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano >>> wrote:

Re: raise None

On Mon, 4 Jan 2016 02:31 pm, Chris Angelico wrote: > On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: >> On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano >> wrote: >>> But I think it is a real issue. I believe in beautiful tracebacks that >>> give

Re: raise None

On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano wrote: > But I think it is a real issue. I believe in beautiful tracebacks that give > you just the right amount of information, neither too little nor two much. > Debugging is hard enough with being given more information than

Re: raise None

On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: > On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano wrote: >> But I think it is a real issue. I believe in beautiful tracebacks that give >> you just the right amount of information, neither too little

Re: raise None

On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > If I could have the traceback continue into the C code and tell me the > line of C code that raised the exception, *that's* what I'd choose. If you are serious about believing this would be a good thing, you can open a ticket on the bug tracker

Re: raise None

Am 31.12.15 um 16:35 schrieb Steven D'Aprano: But I think it is a real issue. I believe in beautiful tracebacks that give you just the right amount of information, neither too little nor two much. Debugging is hard enough with being given more information than you need and having to decide what

Re: raise None

On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > If I could have the traceback continue into the C code and tell me the > > line of C code that raised the exception, *that's* what I'd choose. > > If you are serious

Re: raise None

On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > If I could have the traceback continue into the C code and tell me the > > line of C code that raised the exception, *that's* what I'd choose. > > If you are serious

Re: raise None

On Mon, 04 Jan 2016 16:19:51 +1100, Steven D'Aprano wrote: > (1) reminding people that the part of the code which determines the > existence of an error need not be the part of the code which actually > calls raise [...] Do chained exceptions scratch your itch? I don't have experience with

Re: raise None

code and native code. Compare: Well, not quite. What I'm really doing is two-fold: (1) reminding people that the part of the code which determines the existence of an error need not be the part of the code which actually calls raise; and (2) suggesting a tiny change to the semantics of raise which

Re: raise None

On Monday, January 4, 2016 at 9:02:16 AM UTC+5:30, Chris Angelico wrote: > On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: > > On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano > > wrote: > >> But I think it is a real issue. I believe in beautiful tracebacks that give >

Re: raise None

On Monday, January 4, 2016 at 11:42:51 AM UTC+5:30, Dan Sommers wrote: > > I'm saddened but not astonished at just how much opposition there is > > to point (1) ... > > I'll echo the sentiment that we're all adults here, and my opinion that > if you're reading tracebacks, then you want as much

Re: raise None

On 31.12.2015 21:18, Ben Finney wrote: > As best I can tell, Steven is advocating a way to obscure information > from the traceback, on the assumption the writer of a library knows that > I don't want to see it. How do you arrive at that conclusion? The line that raises the exception is exactly

Re: raise None

On 31 December 2015 at 04:07, Steven D'Aprano wrote: > On Thu, 31 Dec 2015 12:44 pm, Ben Finney wrote: > >> Steven D'Aprano writes: >> >>> Traceback (most recent call last): >>> File "spam", line 19, in this >>> File "spam", line 29, in that >>>

Re: raise None

On 31 Dec 2015 15:54, "Chris Angelico" wrote: > > On Fri, Jan 1, 2016 at 2:35 AM, Steven D'Aprano wrote: > >> If the user > >> can see the stack trace and work back to the point where they passed > >> something in to your function then how does the extra

Re: raise None

ass values that can be passed around and raised when required. It's entirely up to the developer to choose whether this non-traditional idiom makes sense for their functions or not. Sometimes it will, and sometimes it won't. The only new part here is the idea that we could streamline the code i

Re: raise None

On Thu, 31 Dec 2015 11:19 pm, Oscar Benjamin wrote: > On 31 December 2015 at 04:07, Steven D'Aprano wrote: [...] >> As an implementation detail, exposing it to the user (in the form of a >> line in the stacktrace) doesn't help debugging. At best it is neutral >> (the user

Re: raise None

. I save an irrelevant level in the traceback, but only at the cost of an extra line of code everywhere I call the argument checking function. But suppose we allowed "raise None" to do nothing. Then I could rename _validate to _if_error and write this: def spam(a, b): raise _if_

Re: raise None

On Fri, Jan 1, 2016 at 2:35 AM, Steven D'Aprano wrote: >> If the user >> can see the stack trace and work back to the point where they passed >> something in to your function then how does the extra level hurt? > > It hurts precisely because it is one extra level. I

Re: raise None

Hi there, >>> At worst it actively misleads the user into thinking that there >>> is a bug in _validate. Is this "user" a software user or another programmer? If a software user, then some hint about why the _validate found unacceptable data might benefit the user's ability to adjust inputs

Re: raise None

On 31.12.2015 01:09, Steven D'Aprano wrote: > Obviously this doesn't work now, since raise None is an error, but if it did > work, what do you think? I really like the idea. I've approached a similar problem with a similar solution (also experimented with decorators), but the tracebacks

Re: raise None

On 31/12/2015 23:27, Ben Finney wrote: Chris Angelico writes: On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney wrote: Given how very often such decisions make my debugging tasks needlessly difficult, I'm not seeing how that's a desirable feature.

Re: raise None

Oscar Benjamin writes: > Exactly. The critical technique is looking at the traceback and > splitting it between what's your code and what's someone else's. > Hopefully you don't need to look at steves_library.py to figure out > what you did wrong. However if you do

Re: raise None

Chris Angelico writes: > On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney wrote: > > Given how very often such decisions make my debugging tasks > > needlessly difficult, I'm not seeing how that's a desirable feature. > > What Steven's actually advocating

Re: raise None

On Fri, Jan 1, 2016 at 10:36 AM, Mark Lawrence wrote: > On 31/12/2015 23:27, Ben Finney wrote: >> >> Chris Angelico writes: >> >>> On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney >>> wrote: Given how very often such

Re: raise None

On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney wrote: > Oscar Benjamin writes: > >> Exactly. The critical technique is looking at the traceback and >> splitting it between what's your code and what's someone else's. >> Hopefully you don't need

Re: raise None

On Fri, Jan 1, 2016 at 10:27 AM, Ben Finney wrote: > Chris Angelico writes: > >> On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney >> wrote: >> > Given how very often such decisions make my debugging tasks >> > needlessly

Re: raise None

Ben Finney : > Chris Angelico writes: >> What Steven's actually advocating is removing a difference between >> Python code and native code. > > Sure, but his proposal is to move in the direction of *less* debugging > information. > > If I could have

Re: raise None

ZeroDivisionError as err: tb = err.__traceback__ tb = raise ex.with_traceback(tb) But suppose we allowed "raise None" to do nothing. Then I could rename _validate to _if_error and write this: def spam(a, b): raise _if_error(a, b) ... and have the benefits of &qu

Re: raise None

: ... > > > I think this is a win for debuggability. (Is that a word?) But it's a bit > annoying to do it today, since you have to save the return result and > explicitly compare it to None. If "raise None" was a no-op, it would feel > more natural to just say raise _validat

Re: raise None

On Thu, 31 Dec 2015 12:44 pm, Ben Finney wrote: > Steven D'Aprano writes: > >> Traceback (most recent call last): >> File "spam", line 19, in this >> File "spam", line 29, in that >> File "spam", line 39, in other >> File "spam", line 5, in _validate >> ThingyError:

Re: raise None

for blam in _validate(a, b): > raise blam > > which leaves you open to gatheroing them all up instead of aborting on the > first complaint. Are you sure? I would have expected that raising the first exception would exit the loop. >>I think this is a win for debuggability

raise None

line of code everywhere I call the argument checking function. But suppose we allowed "raise None" to do nothing. Then I could rename _validate to _if_error and write this: def spam(a, b): raise _if_error(a, b) ... and have the benefits of "Don't Repeat Yourself" wit

Re: raise None

Steven D'Aprano <st...@pearwood.info> writes: > def _validate(a, b): > if condition(a) or condition(b): return TypeError > ... > Obviously this doesn't work now, since raise None is an error, but if it did > work, what do you think? Never occurred to me. But in some

Validation in Python (was: raise None)

Steven D'Aprano writes: > I have a lot of functions that perform the same argument checking each > time: Not an answer to the question you ask, but: Have you tried the data validation library “voluptuous”? Voluptuous, despite the name, is a Python data validation

Re: raise None

On Thu, Dec 31, 2015 at 11:09 AM, Steven D'Aprano wrote: > I have a lot of functions that perform the same argument checking each time: > > def spam(a, b): > if condition(a) or condition(b): raise TypeError > if other_condition(a) or something_else(b): raise

Re: raise None

): File "spam", line 19, in this File "spam", line 29, in that File "spam", line 39, in other File "spam", line 5, in _validate ThingyError: ... and this is the case of a bad argument to other: Traceback (most recent call last): File "spam&

Re: raise None

Steven D'Aprano writes: > Traceback (most recent call last): > File "spam", line 19, in this > File "spam", line 29, in that > File "spam", line 39, in other > File "spam", line 5, in _validate > ThingyError: ... > > and the reader has to understand the internal

Re: raise None

l failure indications. So thing on that line, how about this: for blam in _validate(a, b): raise blam which leaves you open to gatheroing them all up instead of aborting on the first complaint. I think this is a win for debuggability. (Is that a word?) But it's a bit annoying to do it to

Re: raise None

ty. (Is that a word?) But it's a bit annoying to do it today, since you have to save the return result and explicitly compare it to None. If "raise None" was a no-op, it would feel more natural to just say raise _validate() and trust that if _validate falls out the end and returns None, th