Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25731 > unrolled thread

Re: Basic question about speed/coding style/memory

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Basic question about speed/coding style/memory Chris Angelico <rosuav@gmail.com> - 2012-07-21 19:04 +1000
    Re: Basic question about speed/coding style/memory 88888 Dihedral <dihedral88888@googlemail.com> - 2012-07-23 14:48 -0700
    Re: Basic question about speed/coding style/memory 88888 Dihedral <dihedral88888@googlemail.com> - 2012-07-23 14:48 -0700

#25731 — Re: Basic question about speed/coding style/memory

On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers <janpeterr@freenet.de> 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

[toc] | [next] | [standalone]

#25930

Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道：
> On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers <janpeterr@freenet.de> 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
> 
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

[toc] | [prev] | [next] | [standalone]

#25932

Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道：
> On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers <janpeterr@freenet.de> 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
> 
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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web