Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It sounds as if you want something like..</p> <pre><code>if result = some_function(arg1, arg2): return result </code></pre> <p>This is very deliberately not possible in Python. It's too common a typo to write <code>if a = b</code> instead of <code>if a == b</code>, and allowing this mixes assignment with flow-control. If this is necessary, split it into two lines:</p> <pre><code>x = some_function() if x: print "Function returned True" </code></pre> <p>A more practical example of this is..</p> <pre><code>result = re.match("a", "b") if result: print result.groups() </code></pre> <p>(more correctly, you should do <code>if result is not None:</code> in this case, although the above works)</p> <p>In your specific case ("to verify that my internal functions return successfully"), it sounds like you should use exceptions. If everything is fine, just return whatever you wish. If something goes badly, raise an exception.</p> <p>Exceptions in Python aren't like many other languages - for example, they are used internally flow control (such as the <a href="http://docs.python.org/library/exceptions.html#exceptions.StopIteration" rel="nofollow noreferrer">StopIteration</a> exception)</p> <p>I'd consider the following <em>far</em> more Pythonic than using return codes:</p> <pre><code>#!/usr/bin/env python2.6 def some_function(arg1, arg2): if arg1 + arg2 &gt; 5: return "some data for you" else: raise ValueError("Could not complete, arg1+arg2 was too small") </code></pre> <p>Then, you can call the function in a single line:</p> <pre><code>return some_function(3, 2) </code></pre> <p>This either returns the value, or raises an exception, which you could handle the exception somewhere sensible:</p> <pre><code>def main(): try: result = some_function(3, 5) except ValueError, errormsg: print errormsg sys.exit(1) else: print "Everything is perfect, the result was {0}".format(result) </code></pre> <p>Or if this case is actually an error, simply let halt the application with a nice stack trace.</p> <p>Yes, it's much longer than one line, but the idea behind Python is brevity, but explicitness and readability.</p> <p>Basically, if the function can no longer continue, raise an exception. Handle this exception either where you can recover from the problem, or present the user with an error message.. <em>unless</em> you are writing a library, in which case leave the exception to run up the stack to the calling code</p> <p>Or, in poem form:</p> <pre>$ python -m this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!</pre> <p>Finally, it might be worth reading over <a href="http://www.python.org/dev/peps/pep-0008/" rel="nofollow noreferrer">"PEP 8"</a>, the style guide for Python. It may answer some of your questions, such as "Are one-liner if statements 'pythonic'?"</p> <blockquote> <p>Compound statements (multiple statements on the same line) are generally discouraged.</p> <p>Yes:</p> <pre><code>if foo == 'blah': do_blah_thing() do_one() do_two() do_three() </code></pre> <p>Rather not:</p> <pre><code>if foo == 'blah': do_blah_thing() do_one(); do_two(); do_three() </code></pre> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload