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. Advertisements

  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. Advertisements

  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. Advertisements

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. Ham

    I need speed Mr .Net....speed

    Ham, Oct 28, 2004, in forum: ASP .Net
    Replies:
    6
    Views:
    2,589
    Antony Baula
    Oct 29, 2004
  2. efiedler
    Replies:
    1
    Views:
    2,399
    Tim Ward
    Oct 9, 2003
  3. bugbear
    Replies:
    8
    Views:
    564
    Roedy Green
    Jul 20, 2005
  4. Replies:
    2
    Views:
    2,473
    Howard
    Apr 28, 2004
  5. calmar
    Replies:
    11
    Views:
    1,363
    calmar
    Feb 21, 2006
  6. Ken Varn
    Replies:
    0
    Views:
    759
    Ken Varn
    Apr 26, 2004
  7. BCFD36
    Replies:
    29
    Views:
    817
    BCFD36
    Jan 13, 2012
  8. Jan Riechers
    Replies:
    6
    Views:
    262
    88888 Dihedral
    Jul 23, 2012
Loading...