On Wed, Apr 13, 2011 at 12:42 PM, Ethan Furman <et...@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
--
http://mail.python.org/mailman/listinfo/python-list
