cascading python executions only if return code is 0

Frank Cui ycui at outlook.com
Sun Dec 22 17:14:13 EST 2013



> Date: Sun, 22 Dec 2013 14:27:35 -0800
> Subject: Re: cascading python executions only if return code is 0
> From: rantingrickjohnson at gmail.com
> To: python-list at python.org
> 
> On Sunday, December 22, 2013 12:37:04 PM UTC-6, Frank Cui wrote:
> > I have a requirement where I need to sequentially execute
> > a bunch of executions, each execution has a return code.
> > the followed executions should only be executed if the
> > return code is 0. is there a cleaner or more pythonic way
> > to do this other than the following ?
> >
> > if a() == 0:
> >     if b() == 0:
> >         c()
> 
> Hello Frank.
> 
> I kindly request that you be more specific when asking
> questions. Both your question and your example code contain
> too many ambiguities.
> 
> I'm still not sure what exact outcome you wish to achieve,
> the only certainty is that you wish to perform a linear
> execution of "N" members with later executions being affected
> by earlier executions.
> 
> Whether you want executions to proceed on failure or proceed
> on success is unclear. Here are a few explicit pseudo code
> examples that would have removed all ambiguities:
> 
>     if fails(a()):
>         if fails(b()):
>             c()
> 
>     if succeeds(a()):
>         if succeeds(b()):
>             c()
> 
> Or if you prefer a purely OOP approach:
> 
>     a.foo()
>     b.foo()
>     if a.failed:
>         if b.failed:
>             c.foo()
> 
>     a.foo()
>     b.foo()
>     if a.succeeded:
>         if b.succeeded:
>             c.foo()
> 
> or you could simplify using a logical one liner:
> 
>     if !a() and !b() then c()
>     if a() and b() then c()
> 
> Of course you could use the "all" function
> 
>     if all(a(), b()):
>         c()
>     if not any(a(), b()):
>         c()
> 
> But this "all" depends whether you're testing for success or
> testing for failure, and that point is a distant third from
> my desperate need of understanding your semantics of "what"
> values are *true* and "what" values are *false*.
> 
> I think (sadly) more time is spent attempting to interpret
> what an OP is asking rather than attempting to provide a
> solution to the problem the OP is suffering, and whilst any
> problem solving adventure is likely to improve our
> intelligence, fumbling about attempting to decode
> ambiguities is indeed time that could have been better spent
> IF ONLY the speaker (or writer) had put a small bit more
> effort into the question.
> 
> Look Frank, nobody is perfect, we all need to improve our
> skills here or there. So don't be offended that my
> statements are, well,... "frank".
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Hi Rick,
Thanks for pointing out. I accept your advice and will try to make the questions clearer and more straightforward to interpretate . I already took the suggestion of using exception-based handling over the return code.
As to testing whether the previous function fails or succeeds, this doesn't really matter in the sense that I already mentioned a return code of 0. 
ThanksFrank 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20131222/d4de19e2/attachment.html>


More information about the Python-list mailing list