Feature suggestion -- return if true

[Chris Angelico]

On Wed, Apr 13, 2011 at 12:42 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> The indentation for return and raise is the next coded line.  List comps and
> gen exps are basically uber-functions, and regardless of how you categorize
> them when they finish it is easy to see where control goes to next because
> of indentation.  With this idea flow can leave the function with no
> indentation clue, making it easy to miss (assuming, of course, it's not some
> bright syntax highlighted color).

So if I have a function that can early-abort, I should indent after that?

def foo(param):
    resource=malloc(50000) # Shtarker, zis is Python! We don't malloc here!
    if not resource: return 0
    resource[param]=5
    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]=5
        del resource
        return 1

or, flipping that the other way around:

    if resource:
        resource[param]=5
        del resource
        return 1
    return 0

but both of these are grossly inferior to:

def foo(param):
    resource=generate_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