Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #62541 > unrolled thread

cascading python executions only if return code is 0

Back to article view | Back to comp.lang.python

Contents

  cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 15:37 -0300
    Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 14:17 -0500
      Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-22 19:31 +0000
        Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 15:05 -0500
          Re: cascading python executions only if return code is 0 Cameron Simpson <cs@zip.com.au> - 2013-12-23 08:39 +1100
            Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 16:53 -0500
              Re: cascading python executions only if return code is 0 Cameron Simpson <cs@zip.com.au> - 2013-12-23 09:11 +1100
              Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-22 22:10 -0500
              Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:22 +1100
              Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 03:43 +0000
              Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:45 +1100
              Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 03:54 +0000
              Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:59 +1100
      RE: cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 16:10 -0300
      Re: cascading python executions only if return code is 0 Ned Batchelder <ned@nedbatchelder.com> - 2013-12-22 14:49 -0500
        Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-23 00:08 +0000
      RE: cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 16:35 -0300
        Re: cascading python executions only if return code is 0 Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-23 13:30 +1300
    Re: cascading python executions only if return code is 0 Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-22 14:27 -0800
      RE: cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 19:14 -0300
      Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 09:51 +1100
      Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-22 23:02 +0000
        Re: cascading python executions only if return code is 0 Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-22 15:57 -0800
          Re: cascading python executions only if return code is 0 Ned Batchelder <ned@nedbatchelder.com> - 2013-12-23 07:27 -0500
          Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 12:44 +0000
    Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-23 00:25 +0000
      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 20:24 -0500
        Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 12:35 +1100
        Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-23 13:33 +1100
          Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:09 +1100
          Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 23:57 -0500
            Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 16:09 +1100
            Re: cascading python executions only if return code is 0 Ethan Furman <ethan@stoneleaf.us> - 2013-12-23 04:45 -0800
              Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-23 10:10 -0500
                Re: cascading python executions only if return code is 0 Ethan Furman <ethan@stoneleaf.us> - 2013-12-23 08:00 -0800
                  Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-26 20:37 -0500
                    Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 12:44 +1100
                    Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-26 21:20 -0500
                    Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 13:27 +1100
                      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-26 23:29 -0500
                        Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 15:40 +1100
                        Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-27 11:15 -0500
                          Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-27 11:42 -0500
                            Re: cascading python executions only if return code is 0 Rustom Mody <rustompmody@gmail.com> - 2013-12-27 22:39 +0530
                            Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-28 08:24 +1100
                            Re: cascading python executions only if return code is 0 pecore@pascolo.net - 2013-12-28 00:59 +0100
                              Re: cascading python executions only if return code is 0 Gene Heskett <gheskett@wdtv.com> - 2013-12-27 19:12 -0500
                    Re: cascading python executions only if return code is 0 Tim Chase <python.list@tim.thechases.com> - 2013-12-26 20:50 -0600
                    Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-27 15:39 +1100
                      Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 15:45 +1100
                      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-27 00:05 -0500
                        Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 16:15 +1100
                          Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-27 00:41 -0500
                    Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-27 18:00 +0000
                    Re: cascading python executions only if return code is 0 Grant Edwards <invalid@invalid.invalid> - 2013-12-30 17:36 +0000
                Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-24 04:05 +1100
                  Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-23 11:03 -0800
                    Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-24 06:12 +1100
                    RE: cascading python executions only if return code is 0 Nick Cash <nick.cash@npcinternational.com> - 2013-12-23 19:31 +0000
                    Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-24 14:41 +1100
                      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-23 22:58 -0500
                Re: cascading python executions only if return code is 0 Peter Otten <__peter__@web.de> - 2013-12-23 18:45 +0100
            Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 13:20 +0000
          Re: cascading python executions only if return code is 0 Ethan Furman <ethan@stoneleaf.us> - 2013-12-23 04:38 -0800
          Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-23 10:12 -0500
            Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-24 04:13 +1100
          Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 15:22 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#62541 — cascading python executions only if return code is 0

[Multipart message — attachments visible in raw view] — view raw

hey guys,
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()
Thanks for your input.
frank 		 	   		  

[toc] | [next] | [standalone]

#62542

In article <mailman.4500.1387739297.18130.python-list@python.org>,
 Frank Cui <ycui@outlook.com> wrote:

> hey guys,
> 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()
> Thanks for your input.
> frank 		 	   		  

Yup!  Just do:

a() or b() or c()

The "or" operation has what's known as "short-circuit" semantics.  That 
means, if the first operand is true, it doesn't evaluate the second 
operand.  Just make sure that a(), b(), and c() all return something 
which is true if they succeed and false otherwise.

[toc] | [prev] | [next] | [standalone]

#62546

On 22/12/2013 19:17, Roy Smith wrote:
> In article <mailman.4500.1387739297.18130.python-list@python.org>,
>   Frank Cui <ycui@outlook.com> wrote:
>
>> hey guys,
>> 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()
>> Thanks for your input.
>> frank 		 	   		
>
> Yup!  Just do:
>
> a() or b() or c()
>
> The "or" operation has what's known as "short-circuit" semantics.  That
> means, if the first operand is true, it doesn't evaluate the second
> operand.  Just make sure that a(), b(), and c() all return something
> which is true if they succeed and false otherwise.
>

Really? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62549

In article <mailman.4504.1387740695.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> On 22/12/2013 19:17, Roy Smith wrote:
> > In article <mailman.4500.1387739297.18130.python-list@python.org>,
> >   Frank Cui <ycui@outlook.com> wrote:
> >
> >> hey guys,
> >> 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()
> >> Thanks for your input.
> >> frank 		 	   		
> >
> > Yup!  Just do:
> >
> > a() or b() or c()
> >
> > The "or" operation has what's known as "short-circuit" semantics.  That
> > means, if the first operand is true, it doesn't evaluate the second
> > operand.  Just make sure that a(), b(), and c() all return something
> > which is true if they succeed and false otherwise.
> >
> 
> Really? :)

I believe what Mark is so elegantly trying to say is, "Roy is a dufus 
and got that backwards".  You need to return something which is false to 
make the next one in the chain get executed.

$ cat or.py 
def a():
    print "a"
    return 0

def b():
    print "b"
    return 1

def c():
    print "c"
    return 0

a() or b() or c()


$ python or.py
a
b

[toc] | [prev] | [next] | [standalone]

#62555

On 22Dec2013 15:05, Roy Smith <roy@panix.com> wrote:
> In article <mailman.4504.1387740695.18130.python-list@python.org>,
>  Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> 
> > On 22/12/2013 19:17, Roy Smith wrote:
> > > In article <mailman.4500.1387739297.18130.python-list@python.org>,
> > >   Frank Cui <ycui@outlook.com> 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()
> > >
> > > Yup!  Just do:
> > >
> > > a() or b() or c()
> > >
> > > The "or" operation has what's known as "short-circuit" semantics.  That
> > > means, if the first operand is true, it doesn't evaluate the second
> > > operand.  Just make sure that a(), b(), and c() all return something
> > > which is true if they succeed and false otherwise.
> > 
> > Really? :)
> 
> I believe what Mark is so elegantly trying to say is, "Roy is a dufus 
> and got that backwards".  You need to return something which is false to 
> make the next one in the chain get executed.
> 
> $ cat or.py 
> def a():
>     print "a"
>     return 0
> 
> def b():
>     print "b"
>     return 1
> 
> def c():
>     print "c"
>     return 0
> 
> a() or b() or c()
> 
> 
> $ python or.py
> a
> b

Yeah.

Roy's code _depends_ upon the return value being equivalent to False.

A better approach would be:

  a() == 0 and b() == 1 and c() == 0

i.e. to explicitly check each return code against the expected/desired
value instead of relying on some flukey coincidental property of
the (arbitrary) numeric value returned.

Better still is the suggestion elsewhere in the thread to make the functions
raise exceptions on error instead of returning a number.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

[toc] | [prev] | [next] | [standalone]

#62556

In article <mailman.4512.1387748397.18130.python-list@python.org>,
 Cameron Simpson <cs@zip.com.au> wrote:

> Roy's code _depends_ upon the return value being equivalent to False.

Yes.  You view this as a flaw.  I view it as a feature :-)

> A better approach would be:
> 
>   a() == 0 and b() == 1 and c() == 0
> 
> i.e. to explicitly check each return code against the expected/desired
> value instead of relying on some flukey coincidental property of
> the (arbitrary) numeric value returned.

You're assuming it's arbitrary.  I'm saying do it that way by design.  

> Better still is the suggestion elsewhere in the thread to make the functions
> raise exceptions on error instead of returning a number.

Possibly.  But, I think of exceptions as indicating that something went 
wrong.  There's two possible things the OP was trying to do here:

1) He intends that all of the functions get run, but each one can only 
get run if all the ones before it succeed.  In that case, I agree that 
the exception pattern makes sense.

2) He intends that each of the functions gets tried, and the first one 
that can return a value wins.  If that's the case, the "or" chaining 
seems more natural.

[toc] | [prev] | [next] | [standalone]

#62557

On 22Dec2013 16:53, Roy Smith <roy@panix.com> wrote:
> In article <mailman.4512.1387748397.18130.python-list@python.org>,
>  Cameron Simpson <cs@zip.com.au> wrote:
> > Roy's code _depends_ upon the return value being equivalent to False.
> 
> Yes.  You view this as a flaw.  I view it as a feature :-)

When I write functions which return a boolean indicating success/failure,
I try to make that boolean be "true" for success.

Now, I do take the point that these functions seem to take the
unix-exit-code convention that zero is success (leaving the many
values of "non-zero" to indicate flavours of failure as desired,
as we have many types of exceptions).

Or, possibly, that a non-zero return indicates the number of errors
encountered; I do that myself for things like option or file parsing,
where I explicitly want to parse of much of a command line (or
whatever) as possible before rejecting things; few things annoy me
as much as a command that barfs about the first usage error and
aborts instead of barfing multiple times and aborting. Unless it
is a command that does the same and then fails to recite a usage
message after the barf. (Yes, almost every GNU command on the planet:
I'm looking at you!)

However, in this count-of-errors scenario I tend to try to return
a list of errors, not a count.

But regardless, I consider code that goes:

  a() or b() or c()

as a test for _success_ of a(), b() and c() in succession to be
misleading at best. When I write that above incantation it is a
test for failure: try this, or try that, or finally try this other
thing.

> > A better approach would be:
> > 
> >   a() == 0 and b() == 1 and c() == 0
> > 
> > i.e. to explicitly check each return code against the expected/desired
> > value instead of relying on some flukey coincidental property of
> > the (arbitrary) numeric value returned.
> 
> You're assuming it's arbitrary.  I'm saying do it that way by design.  

The counter example the above is based upon deliberately returned
1 for success from b(), IIRC. Different design.

The OP was unclear about his/her design rationale.

> > Better still is the suggestion elsewhere in the thread to make the functions
> > raise exceptions on error instead of returning a number.
> 
> Possibly.  But, I think of exceptions as indicating that something went 
> wrong.

I think of failure as "something went wrong".
Yes, I'll grant there are shades of intent here.

> There's two possible things the OP was trying to do here:
> 
> 1) He intends that all of the functions get run, but each one can only 
> get run if all the ones before it succeed.  In that case, I agree that 
> the exception pattern makes sense.

His cascading if-statement in the OP suggested this to me.

> 2) He intends that each of the functions gets tried, and the first one 
> that can return a value wins.  If that's the case, the "or" chaining 
> seems more natural.

I'm pretty sure that wasn't his intent, again based on my recollection
of the OP. But I still dislike "a() or b() or c()" as a test for
chained success; I think it is a bad idiom.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

I must construct my own System, or be enslaved to another Man's.
        - William Blake

[toc] | [prev] | [next] | [standalone]

#62579

On Mon, 23 Dec 2013 09:11:25 +1100, Cameron Simpson <cs@zip.com.au>
declaimed the following:

>
>Now, I do take the point that these functions seem to take the
>unix-exit-code convention that zero is success (leaving the many
>values of "non-zero" to indicate flavours of failure as desired,
>as we have many types of exceptions).
>
	Having spent 22 years with VMS, 0 -> success is still a problem to me.
Odd result codes (aka True) were 1-success/3-information, even results
(False) were 0-warning/2-error/4-fatal

"""
 Each condition code corresponds to a system message. The command
interpreter saves the condition code as a 32-bit longword defined as the
reserved global symbol $STATUS. The condition code stored in $STATUS is a
hexadecimal number conforming to the format of an OpenVMS message code:

    Bits 0--2 contain the severity level of the message.
    Bits 3--15 contain the number of the corresponding message.
    Bits 16--27 contain a number for the software component, or facility,
that generated the message.
    Bits 28--31 contain internal control flags. 
"""

(Boolean testing only examined bit 0)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#62584

On Mon, Dec 23, 2013 at 2:10 PM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
>         Having spent 22 years with VMS, 0 -> success is still a problem to me.
> Odd result codes (aka True) were 1-success/3-information, even results
> (False) were 0-warning/2-error/4-fatal

Having spent a similar amount of time with Unix, C, and various APIs,
I'm quite used to 0 meaning success and nonzero meaning error.

ChrisA

[toc] | [prev] | [next] | [standalone]

#62587

On 23/12/2013 03:22, Chris Angelico wrote:
> On Mon, Dec 23, 2013 at 2:10 PM, Dennis Lee Bieber
> <wlfraed@ix.netcom.com> wrote:
>>          Having spent 22 years with VMS, 0 -> success is still a problem to me.
>> Odd result codes (aka True) were 1-success/3-information, even results
>> (False) were 0-warning/2-error/4-fatal
>
> Having spent a similar amount of time with Unix, C, and various APIs,
> I'm quite used to 0 meaning success and nonzero meaning error.
>
> ChrisA
>

Another C thing to complain about, with functions like malloc the status 
code and value returned are one and the same thing, except that NULL is 
failure in this case.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62588

On Mon, Dec 23, 2013 at 2:43 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> Another C thing to complain about, with functions like malloc the status
> code and value returned are one and the same thing, except that NULL is
> failure in this case.

How's that a problem? Python has the same:

memory.get(1234)

will return a bit of memory, or None if it can't get any. Not
materially different. Remember, C doesn't have exceptions. In C++, the
'new' operator will throw an exception if it can't provide memory.

ChrisA

[toc] | [prev] | [next] | [standalone]

#62589

On 23/12/2013 03:45, Chris Angelico wrote:
> On Mon, Dec 23, 2013 at 2:43 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> Another C thing to complain about, with functions like malloc the status
>> code and value returned are one and the same thing, except that NULL is
>> failure in this case.
>
> How's that a problem? Python has the same:

Remembering to check it?

>
> memory.get(1234)

You learn something new every day or April 1st come early?

>
> will return a bit of memory, or None if it can't get any. Not
> materially different. Remember, C doesn't have exceptions. In C++, the
> 'new' operator will throw an exception if it can't provide memory.
>
> ChrisA
>


-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62590

On Mon, Dec 23, 2013 at 2:54 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> memory.get(1234)
>
>
> You learn something new every day or April 1st come early?

memory = {1:"Foo", 12:"Bar", 123:"Quux"}

ChrisA

[toc] | [prev] | [next] | [standalone]

#62547

[Multipart message — attachments visible in raw view] — view raw

sorry, but what if I need to have different parameters in these functions ?

> To: python-list@python.org
> From: breamoreboy@yahoo.co.uk
> Subject: Re: cascading python executions only if return code is 0
> Date: Sun, 22 Dec 2013 19:31:21 +0000
> 
> On 22/12/2013 19:17, Roy Smith wrote:
> > In article <mailman.4500.1387739297.18130.python-list@python.org>,
> >   Frank Cui <ycui@outlook.com> wrote:
> >
> >> hey guys,
> >> 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()
> >> Thanks for your input.
> >> frank 		 	   		
> >
> > Yup!  Just do:
> >
> > a() or b() or c()
> >
> > The "or" operation has what's known as "short-circuit" semantics.  That
> > means, if the first operand is true, it doesn't evaluate the second
> > operand.  Just make sure that a(), b(), and c() all return something
> > which is true if they succeed and false otherwise.
> >
> 
> Really? :)
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask 
> what you can do for our language.
> 
> Mark Lawrence
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
 		 	   		  

[toc] | [prev] | [next] | [standalone]

#62548

On 12/22/13 2:10 PM, Frank Cui wrote:
> sorry, but what if I need to have different parameters in these functions ?

Frank, welcome to the group.  Common convention is to put your response 
below the exiting message, so that the conversation continues down the page.

(See my answer below... :)

>
>
>  > To: python-list@python.org
>  > From: breamoreboy@yahoo.co.uk
>  > Subject: Re: cascading python executions only if return code is 0
>  > Date: Sun, 22 Dec 2013 19:31:21 +0000
>  >
>  > On 22/12/2013 19:17, Roy Smith wrote:
>  > > In article <mailman.4500.1387739297.18130.python-list@python.org>,
>  > > Frank Cui <ycui@outlook.com> wrote:
>  > >
>  > >> hey guys,
>  > >> 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()
>  > >> Thanks for your input.
>  > >> frank
>  > >
>  > > Yup! Just do:
>  > >
>  > > a() or b() or c()
>  > >
>  > > The "or" operation has what's known as "short-circuit" semantics. That
>  > > means, if the first operand is true, it doesn't evaluate the second
>  > > operand. Just make sure that a(), b(), and c() all return something
>  > > which is true if they succeed and false otherwise.
>  > >
>  >
>  > Really? :)
>  >
>  > --
>  > My fellow Pythonistas, ask not what our language can do for you, ask
>  > what you can do for our language.
>  >
>  > Mark Lawrence
>  >
>  > --
>  > https://mail.python.org/mailman/listinfo/python-list
>
>

The most Python-natural way to deal with your problem would be to have 
these functions not return status codes at all.  Instead, have them 
raise an exception if something goes wrong.   Then you can invoke them 
most naturally:

     a()
     b()
     c()

Execution will continue as long as no exceptions are raised.  If you 
need to deal with the failure case also, then:

     try:
         a()
         b()
         c()
     except Exception as e:
         # do something here

Depending on how you want to deal with failures, you'd probably use your 
own subclass of Exception, but this is the general idea.

Return codes can be awkward, especially in Python which has exception 
integrated so fully into the language, library, and culture.

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#62564

On Sun, 22 Dec 2013 14:49:43 -0500, Ned Batchelder wrote:

> On 12/22/13 2:10 PM, Frank Cui wrote:
>> sorry, but what if I need to have different parameters in these
>> functions ?
> 
> Frank, welcome to the group.  Common convention is to put your response
> below the exiting message, so that the conversation continues down the
> page.

Ideally responses should be *interleaved* between parts of the quoted 
message, rather than just dumped at the end. The idea is that it's a 
conversation:

    Fred said:
    -> How do I exfoliate my monkey?

    Get a friend to hold it down while you rub it all over 
    with Extra Strength Monkey Exfoliating Cream. When you 
    are done, give it a banana as a reward.

    -> Once I have my exfoliated monkey, how do I convince
    -> others that it is my child?

    Dress it in children's clothes, and make sure you tell 
    people that he or she has a very sensitive artistic 
    personality, and that is why you allow it to climb the
    walls.


sort of thing. This also gives the writer the opportunity to trim out 
parts of the irrelevant text which is no longer relevant to the 
conversation, although it is considered polite to give some indication, 
usually [snip] or [...], that you have done so.

See Wikipedia's article on posting styles for more information:

http://en.wikipedia.org/wiki/Posting_styles



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#62550

[Multipart message — attachments visible in raw view] — view raw

> To: python-list@python.org
> From: ned@nedbatchelder.com
> Subject: Re: cascading python executions only if return code is 0
> Date: Sun, 22 Dec 2013 14:49:43 -0500
> 
> On 12/22/13 2:10 PM, Frank Cui wrote:
> > sorry, but what if I need to have different parameters in these functions ?
> 
> Frank, welcome to the group.  Common convention is to put your response 
> below the exiting message, so that the conversation continues down the page.
> 
> (See my answer below... :)
> 
> >
> >
> >  > To: python-list@python.org
> >  > From: breamoreboy@yahoo.co.uk
> >  > Subject: Re: cascading python executions only if return code is 0
> >  > Date: Sun, 22 Dec 2013 19:31:21 +0000
> >  >
> >  > On 22/12/2013 19:17, Roy Smith wrote:
> >  > > In article <mailman.4500.1387739297.18130.python-list@python.org>,
> >  > > Frank Cui <ycui@outlook.com> wrote:
> >  > >
> >  > >> hey guys,
> >  > >> 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()
> >  > >> Thanks for your input.
> >  > >> frank
> >  > >
> >  > > Yup! Just do:
> >  > >
> >  > > a() or b() or c()
> >  > >
> >  > > The "or" operation has what's known as "short-circuit" semantics. That
> >  > > means, if the first operand is true, it doesn't evaluate the second
> >  > > operand. Just make sure that a(), b(), and c() all return something
> >  > > which is true if they succeed and false otherwise.
> >  > >
> >  >
> >  > Really? :)
> >  >
> >  > --
> >  > My fellow Pythonistas, ask not what our language can do for you, ask
> >  > what you can do for our language.
> >  >
> >  > Mark Lawrence
> >  >
> >  > --
> >  > https://mail.python.org/mailman/listinfo/python-list
> >
> >
> 
> The most Python-natural way to deal with your problem would be to have 
> these functions not return status codes at all.  Instead, have them 
> raise an exception if something goes wrong.   Then you can invoke them 
> most naturally:
> 
>      a()
>      b()
>      c()
> 
> Execution will continue as long as no exceptions are raised.  If you 
> need to deal with the failure case also, then:
> 
>      try:
>          a()
>          b()
>          c()
>      except Exception as e:
>          # do something here
> 
> Depending on how you want to deal with failures, you'd probably use your 
> own subclass of Exception, but this is the general idea.
> 
> Return codes can be awkward, especially in Python which has exception 
> integrated so fully into the language, library, and culture.
> 
> -- 
> Ned Batchelder, http://nedbatchelder.com
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Thanks for informing the rules. 		 	   		  

[toc] | [prev] | [next] | [standalone]

#62565

Frank Cui wrote:
> 
> Someone else wrote:
>  >
>  > Frank, welcome to the group. Common convention is to put your response
>  > below the exiting message, so that the conversation continues down 
> the page.
>
> Thanks for informing the rules.

He forgot to mention the most important rule,
which is:

DON'T quote the entire message you're replying to!

Only quote small pieces of it, like I did above,
just enough to establish context. Then put your
reply to that point under the quoted text.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#62558

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".

[toc] | [prev] | [next] | [standalone]

#62559

[Multipart message — attachments visible in raw view] — view raw

> Date: Sun, 22 Dec 2013 14:27:35 -0800
> Subject: Re: cascading python executions only if return code is 0
> From: rantingrickjohnson@gmail.com
> To: python-list@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 

 		 	   		  

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web