Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=P5EC9JxBtBh6xP1Cc+DzjBuLL6uwEAB75j7HYQdqznVM/0nK6Z5kxAzt2Bh3/FyfBC GFmbVXXKVujruCerdOSrz5qL7aioBnzk9rYOcBeckSOH9zgrfadQBeds9XAF1mHH21/M Msp4TiWbTQgwJMeCFwhqAYun5w6dUVyQ0CW6Y=
MIME-Version: 1.0
In-Reply-To: <4DA50D89.3090706@stoneleaf.us>
References: <8abff237-5ccd-4eb6-85c8-cdc9e87520b7@bl1g2000vbb.googlegroups.com> <mailman.233.1302568099.9059.python-list@python.org> <87k4eze4dl.fsf@mithlond.arda> <BANLkTikrmLzySDVUNZhAWZR-JSB58r6tdA@mail.gmail.com> <BANLkTinz=JhS6z5orBPj2ZK+2z3kXFfa6Q@mail.gmail.com> <4DA4DB0F.8040509@stoneleaf.us> <1302650129.8890.0.camel@localhost.localdomain> <mailman.295.1302651485.9059.python-list@python.org> <4da4e856$0$29986$c3e8da3$5496439d@news.astraweb.com> <4DA50D89.3090706@stoneleaf.us>
Date: Wed, 13 Apr 2011 13:00:53 +1000
Subject: Re: Feature suggestion -- return if true
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.300.1302663656.9059.python-list@python.org>
Lines: 62
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:3111

On Wed, Apr 13, 2011 at 12:42 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
> The indentation for return and raise is the next coded line. =A0List comp=
s and
> gen exps are basically uber-functions, and regardless of how you categori=
ze
> them when they finish it is easy to see where control goes to next becaus=
e
> of indentation. =A0With this idea flow can leave the function with no
> indentation clue, making it easy to miss (assuming, of course, it's not s=
ome
> bright syntax highlighted color).

So if I have a function that can early-abort, I should indent after that?

def foo(param):
    resource=3Dmalloc(50000) # Shtarker, zis is Python! We don't malloc her=
e!
    if not resource: return 0
    resource[param]=3D5
    del resource
    return 1

Now, this pattern of "attempt to acquire resource, return if unable
to" is probably better recoded as "acquire resource and have it throw
an error if it can't"; but if you're eyeballing for control-flow
changes, a called function throwing an error is even less obvious than
an if: return.

Where should the indentation go?

As I understand it, Python uses indents the way C uses braces - to
delimit blocks of code. The only reason to indent in foo() above would
be if the if has an else:

    if not resource: return 0
    else:
        resource[param]=3D5
        del resource
        return 1

or, flipping that the other way around:

    if resource:
        resource[param]=3D5
        del resource
        return 1
    return 0

but both of these are grossly inferior to:

def foo(param):
    resource=3Dgenerate_resource()
    resource.dosomething(param,5)
    return 1

However, what's to tell you that generate_resource() will throw a
KaosError if Siegfried is around?

(Oh, and apologies to all for picking a different comedy source for my
references. Sometimes even a python has to get smart...)

Chris Angelico