Re: Basic question about speed/coding style/memory

Discussion in 'Python' started by Chris Angelico, Jul 21, 2012.

  1. On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers <> wrote:
    > Block
    > #----------------------------------
    > if statemente_true:
    > doSomething()
    > else:
    > doSomethingElseInstead()
    >
    > #----------------------------------


    This means, to me, that the two options are peers - you do this or you do that.

    > versus this block:
    > #----------------------------------
    > if statement_true:
    > doSomething()
    > return
    >
    > doSomethingElseInstead()
    >
    > #----------------------------------


    This would be for an early abort. Don't bother doing most of this
    function's work, just doSomething. Might be an error condition, or
    perhaps an optimized path.

    Definitely for error conditions, I would use the second option. The
    "fail and bail" notation keeps the entire error handling in one place:

    def func(x,y,z):
    if x<0:
    y+=5
    return
    if y<0:
    raise PEBKAC("There's an idiot here somewhere")
    # ... do the rest of the work

    Note the similarity between the control structures. Raising an
    exception immediately terminates processing, without polluting the
    rest of the function with an unnecessary indentation level. Early
    aborting through normal function return can do the same thing.

    But this is purely a matter of style. I don't think there's any
    significance in terms of processing time or memory usage, and even if
    there is, it would be dwarfed by considerations of readability. Make
    your code look like what it's doing, and let the execution take care
    of itself.

    ChrisA
     
    Chris Angelico, Jul 21, 2012
    #1
    1. Advertising

  2. Chris Angelicoæ–¼ 2012å¹´7月21日星期六UTC+8下åˆ5時04分12秒寫é“:
    > On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers &lt;&gt; wrote:
    > &gt; Block
    > &gt; #----------------------------------
    > &gt; if statemente_true:
    > &gt; doSomething()
    > &gt; else:
    > &gt; doSomethingElseInstead()
    > &gt;
    > &gt; #----------------------------------
    >
    > This means, to me, that the two options are peers - you do this or you dothat.
    >
    > &gt; versus this block:
    > &gt; #----------------------------------
    > &gt; if statement_true:
    > &gt; doSomething()
    > &gt; return
    > &gt;
    > &gt; doSomethingElseInstead()
    > &gt;
    > &gt; #----------------------------------
    >
    > This would be for an early abort. Don't bother doing most of this
    > function's work, just doSomething. Might be an error condition, or
    > perhaps an optimized path.
    >
    > Definitely for error conditions, I would use the second option. The
    > &quot;fail and bail&quot; notation keeps the entire error handling in oneplace:
    >
    > def func(x,y,z):
    > if x&lt;0:
    > y+=5
    > return
    > if y&lt;0:
    > raise PEBKAC(&quot;There's an idiot here somewhere&quot;)
    > # ... do the rest of the work
    >

    This is the caller responsible style when passing parameters to
    functions.


    Checking types of parameters both in the caller and the callee
    does slow down a little bit.



    > Note the similarity between the control structures. Raising an
    > exception immediately terminates processing, without polluting the
    > rest of the function with an unnecessary indentation level. Early
    > aborting through normal function return can do the same thing.
    >
    > But this is purely a matter of style. I don't think there's any
    > significance in terms of processing time or memory usage, and even if
    > there is, it would be dwarfed by considerations of readability. Make
    > your code look like what it's doing, and let the execution take care
    > of itself.
    >
    > ChrisA
     
    88888 Dihedral, Jul 23, 2012
    #2
    1. Advertising

  3. Chris Angelicoæ–¼ 2012å¹´7月21日星期六UTC+8下åˆ5時04分12秒寫é“:
    > On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers &lt;&gt; wrote:
    > &gt; Block
    > &gt; #----------------------------------
    > &gt; if statemente_true:
    > &gt; doSomething()
    > &gt; else:
    > &gt; doSomethingElseInstead()
    > &gt;
    > &gt; #----------------------------------
    >
    > This means, to me, that the two options are peers - you do this or you dothat.
    >
    > &gt; versus this block:
    > &gt; #----------------------------------
    > &gt; if statement_true:
    > &gt; doSomething()
    > &gt; return
    > &gt;
    > &gt; doSomethingElseInstead()
    > &gt;
    > &gt; #----------------------------------
    >
    > This would be for an early abort. Don't bother doing most of this
    > function's work, just doSomething. Might be an error condition, or
    > perhaps an optimized path.
    >
    > Definitely for error conditions, I would use the second option. The
    > &quot;fail and bail&quot; notation keeps the entire error handling in oneplace:
    >
    > def func(x,y,z):
    > if x&lt;0:
    > y+=5
    > return
    > if y&lt;0:
    > raise PEBKAC(&quot;There's an idiot here somewhere&quot;)
    > # ... do the rest of the work
    >

    This is the caller responsible style when passing parameters to
    functions.


    Checking types of parameters both in the caller and the callee
    does slow down a little bit.



    > Note the similarity between the control structures. Raising an
    > exception immediately terminates processing, without polluting the
    > rest of the function with an unnecessary indentation level. Early
    > aborting through normal function return can do the same thing.
    >
    > But this is purely a matter of style. I don't think there's any
    > significance in terms of processing time or memory usage, and even if
    > there is, it would be dwarfed by considerations of readability. Make
    > your code look like what it's doing, and let the execution take care
    > of itself.
    >
    > ChrisA
     
    88888 Dihedral, Jul 23, 2012
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. calmar
    Replies:
    11
    Views:
    909
    calmar
    Feb 21, 2006
  2. Jan Riechers
    Replies:
    6
    Views:
    184
    88888 Dihedral
    Jul 23, 2012
  3. Andrew Berg
    Replies:
    0
    Views:
    108
    Andrew Berg
    Jul 21, 2012
  4. Jan Riechers
    Replies:
    0
    Views:
    112
    Jan Riechers
    Jul 21, 2012
  5. Andrew Berg
    Replies:
    0
    Views:
    120
    Andrew Berg
    Jul 21, 2012
Loading...

Share This Page