Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.003 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'nested': 0.07; 'subject:code': 0.07; '22,': 0.09; 'executed': 0.09; 'executes': 0.09; 'logic': 0.09; 'way:': 0.09; 'def': 0.12; 'a()': 0.16; 'a():': 0.16; 'b()': 0.16; 'b():': 0.16; 'builtins': 0.16; 'c():': 0.16; 'chained': 0.16; 'cleaner': 0.16; 'cui': 0.16; 'guys,': 0.16; 'pythonic': 0.16; 'succinct': 0.16; 'travis': 0.16; 'subject:python': 0.16; 'discussions': 0.16; 'followed': 0.16; 'wrote:': 0.18; 'code.': 0.18; 'hey': 0.18; 'proposed': 0.22; 'separate': 0.22; 'to:name:python-list@python.org': 0.22; 'sort': 0.25; 'script': 0.25; 'header:In-Reply-To:1': 0.27; 'received:172.16': 0.29; 'am,': 0.29; 'dec': 0.30; 'list:': 0.30; 'gives': 0.31; 'code': 0.31; 'are.': 0.31; 'bunch': 0.31; 'coded': 0.31; 'you\x92re': 0.31; 'stuff': 0.32; 'run': 0.32; 'style': 0.33; 'could': 0.34; 'something': 0.35; 'definition': 0.35; 'late': 0.35; 'requirement': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'done,': 0.36; 'should': 0.36; 'skip:- 20': 0.37; 'list': 0.37; 'step': 0.37; 'auto;': 0.38; 'sometimes': 0.38; 'message-id:@gmail.com': 0.38; 'depends': 0.38; 'e.g.': 0.38; 'same.': 0.38; 'todo': 0.38; 'to:addr:python-list': 0.38; 'little': 0.38; 'functional': 0.39; 'itself': 0.39; 'to:addr:python.org': 0.39; 'how': 0.40; 'commands': 0.60; 'break': 0.61; 'header:Message-Id:1': 0.63; 'more': 0.64; 'different': 0.65; 'charset:windows-1252': 0.65; 'frank': 0.68; 'calibri;': 0.84; 'situations,': 0.84; '2013,': 0.91; 'capture': 0.91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=T5rm9vjiOvSZMKZiNgGluP1PWW1HWQ/agkkE7tRmG48=; b=BuWoBQhFzQPSywIgYbz/VncEHSGidaAVtI9p8F35nMxAvT02HZZJWxXdEIXRIlUYbR HROkCCPJ4k4vAmiJ8baWs8bTVvHXbxA071isFOJWvSUuYEAmbAET/2/P0ycGFIIID/MP JiULAFkVhr4uoWKgXh/HQxMRa373qtr2X2efUAUdUCNK/YWyq3996hQ2GR8v8YAC1cQH HRN+RU6IpMB5XunJ6w1LVWrGKwPjCCWQT0oBuv/w5nFgLS1xrdRE9Xx2N/r4RWNGjXUj kk2ZRJKV7lhrNkBnloHSMvHyBWgxgTjbwRyJo63fmqVCWgo5y6eBrt19NPVr08YY9QsM l7cQ== X-Received: by 10.68.204.4 with SMTP id ku4mr46986988pbc.66.1388097172865; Thu, 26 Dec 2013 14:32:52 -0800 (PST) From: Travis Griggs Content-Type: multipart/alternative; boundary="Apple-Mail=_A8A4D333-5A93-4815-BE53-B1960970DEE7" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: cascading python executions only if return code is 0 Date: Thu, 26 Dec 2013 14:32:50 -0800 References: To: "python-list@python.org" In-Reply-To: X-Mailer: Apple Mail (2.1827) X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 153 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1388097652 news.xs4all.nl 2916 [2001:888:2000:d::a6]:34120 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:62753 --Apple-Mail=_A8A4D333-5A93-4815-BE53-B1960970DEE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 22, 2013, at 10:37 AM, Frank Cui wrote: > hey guys, >=20 > 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 ?=20 >=20 > if a() =3D=3D 0: > if b() =3D=3D 0: > c() I know I=92m a little late to the game on this one. Good answers and = interesting discussions (and sometimes not). In some situations, I might = do something like the following. It depends on just how many functions = your cascading, and how arbitrary or pluggable those are. If your model is that you have a sort of todo list of functions to = execute (more than 3 or so), you might want to separate the definition = of that run list from the logic that executes them. Given something = like: def a(): print(=91Aye=92) return 0 def b(): print(=91Bee=92) return 0 def c(): print(=92See=92) return 0 def d(): print(=91Dee=92) return 1 def e(): print(=91Eee=92) return 1 You do the nested if as you original proposed or the chained or as also = proposed. Or you could put the commands in a list: script =3D [ a, b, c, d, e] This gives you a nice succinct list of stuff that needs to be done, not = to different if you=92d just coded it with no or logic, e.g. a b c d e Refactoring/evolving them then feels the same. To run the script we could do it the good ol=92 C'ish way: for step in script: if step() !=3D 0: break But we have more functional style stuff via builtins which can capture = that pattern: ranToEnd =3D all(step() =3D=3D 0 for step in script) So IF you=92re use case lends itself to separation of the =93list of = stuff to do=94 and the =93logic to execute said list=94, then=85 this = approach might be appealing. Travis Griggs --Apple-Mail=_A8A4D333-5A93-4815-BE53-B1960970DEE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 22, 2013, at 10:37 AM, 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() =3D=3D = 0:
    if b() =3D=3D 0:
    =     c()

I know = I=92m a little late to the game on this one. Good answers and = interesting discussions (and sometimes not). In some situations, I might = do something like the following. It depends on just how many functions = your cascading, and how arbitrary or pluggable those = are.

If your model is that you have a sort of = todo list of functions to execute (more than 3 or so), you might want to = separate the definition of that run list from the logic that executes = them. Given something like:

def = a():
  print(=91Aye=92)
  return = 0

def b():
  = print(=91Bee=92)
  return = 0

def c():
  = print(=92See=92)
  return = 0

def d():
  = print(=91Dee=92)
  return = 1

def e():
  = print(=91Eee=92)
  return 1

You = do the nested if as you original proposed or the chained or as also = proposed. Or you could put the commands in a = list:

script =3D [
  = a,
  b,
  c,
  = d,
  e]

This gives you a nice = succinct list of stuff that needs to be done, not to different if you=92d = just coded it with no or logic, = e.g.

a
b
c
d
<= div>e

Refactoring/evolving them then feels the = same.

To run the script we could do it the good = ol=92 C'ish way:

for step in = script:
  if step() !=3D 0:
    = break

But we have more functional style = stuff via builtins which can capture that = pattern:

ranToEnd =3D all(step() =3D=3D 0 for = step in script)

So IF you=92re use case lends = itself to separation of the =93list of stuff to do=94 and the =93logic = to execute said list=94, then=85 this approach might be = appealing.

Travis = Griggs


= --Apple-Mail=_A8A4D333-5A93-4815-BE53-B1960970DEE7--